-
Fototrend
Linux kezdőknek - érdemes beleolvasni, mielőtt kérdezel
Új hozzászólás Aktív témák
-
Köszönöm a válaszokat! Azt gondoltam, hogy már mindenre is létezik külön distro, akkor erre is.
Ezekszerint találtam egy piaci rést![;]](//cdn.rios.hu/dl/s/v1.gif)
Marad a szöszölés... -
CPT.Pirk
Jómunkásember
válasz
ubyegon2
#104413
üzenetére
2.6.27-es kernelt mutatnak a képeken, az 2008-as. Jó eséllyel be sem bootol mai hardveren.
Ha ezt ma kéne csinálni, fognék egy mai disztrót, feltenném penre, aztán kapna 1-2 teszt progit mint pl. Geekbench meg Unigine Superposition, betennék pár monitor cuccot mondjuk a KDE rendszereszközök RnR pluginjával, meg kapna egy memtest86+ beépülőt és meg lenne oldva a stressz teszt és hőmérséklet figyelés.
tibi:
-
válasz
CPT.Pirk
#104411
üzenetére
14 éves, na bumm. Emiatt akár jó is lehet:
Anélkül hogy Internetre csatlakoznék, töltögetnék, telepítenék.
Az már csak hab a tortán ha van benne CPU/GPU stresszelő.
Amúgy maradnak a penetration testing iso-k, Parrot, Caine és társai.Tibikomám
Látod, hogy belenyúltam! Én se gondoltam volna, hogy tőlem hallasz múzeális szoftverekről! -
#104412
tordaitibi
veterán
CPT.Pirk
#104411
-
#104409
tordaitibi
veterán
cigam
#104406
válasz
cigam
#104406
üzenetére
Nem tudok ilyet de nekem ha kéne,
bármelyik telepítő pendrájvra +1 partíció és appimage szoftverek.
Itt a System monitoring alatt mondjuk eléggé szegényes a kínálat.
[link]
Cpu stresszre meg ha jól tudom vannak cli megoldások, szkriptet írni és csak futtatni szintén erről a másodpartícióról.Te 11258x többet tudsz pl. nálam Linuxból, dobj össze egy ilyen tesztdisztrót
Kali az csak hálózati behatolás és biztonsági teszteket tud? Nincs benne rendszerteszt is?
Nagyon régen használtam még BackTrack volt a neve.
Kapitánynak sajmos igaza van,
Windowsos portable létezik minden ilyen feladatra és egy winpe vagy Hbcd-iso bebozoolva simán futtaja mindegyiket.
Nekem egész gyűjteményem van ilyenből, Aida 32-64bit, Furmark, Cpu-z Gpu-info, HWmonitor stb-stb. -
-
Nem véletlen kérdeztem rá, hogy olyan specializált distro, amiben alapból benne vannak ezek az eszközök. Csak indítom a rendszert, és már ki is írja is a HW főbb paramétereit, pl. conky-val a desktopra, vagy önálló programként, bárhogyan. Anélkül hogy Internetre csatlakoznék, töltögetnék, telepítenék.
Az már csak hab a tortán ha van benne CPU/GPU stresszelő. -
Érintőlegesen olvastam az XLibréről, nem mindenki elégedett a Wayland ötletével.
-
CPT.Pirk
Jómunkásember
válasz
cigam
#104399
üzenetére
Az Xwaland az továbbra is működni fog, szóval a programokat ez nem érinti. Ez csak annyi, hogy a Gnome környezetet már nem lehet majd X11-en futtatni.
A watch paranccsal tudsz kimeneteket figyelni, de magát a hőmérséklet alapján a venti állítást azt a biosnak kellene csinálnia, függetlenül az OS-től. Nem tudom friss bioszt használsz-e.
hcl: na passz, olyasmit sosem csináltam.
-
-
válasz
CPT.Pirk
#104398
üzenetére
Itt volt az ideje, kérdés hogy a programok is felfejlődtek hozzá? Ha jól rémlik régebben pl. gparted csak x11-en volt hajlandó elindulni. Most is van/lesz benne valamilyen x11 emulátor?
---
Létezik HW figyelő/tesztelő live rendszer?
Konkrétan az a bajom hogy az integrált VGA felmelegszik ~80 fokra, és ezért(?) a CPU órajelét visszaveszi 0.4GHz-re. De a hűtőventillátort meg alapon"felejti", meg sem próbálja kifújni a meleget. -
#104396
hcl
titán
fekete.puma
#104395
válasz
fekete.puma
#104395
üzenetére
A virtuális gép milyen alapokon van? EFI vagy BIOS?
-
#104393
csixy
addikt
fekete.puma
#104391
csixy
addikt
válasz
fekete.puma
#104391
üzenetére
A telepítő melyik verzióját idítottad? Lehet, hogy nem UEFI módban, hanem Legacy, azaz BIOS üzemmódvan idítottad és a hagyományos módon akar indulni mint régen az MBR-es telepítés. Csakhogy ez a telepítő ebben az esetben is GPT partíciós táblás HDD-vel, avagy SSD-vel szeretne működni. Ebben az esetben van szükség a Master Boot Record szerepét helyettesítő bios_grub jelzővel ellátott 1MiB-es formázatlan partícióra, csak a te telepítőd 8Mib-es nagyságút szeret használni. Tehát ez egy hagyományos MBR-szerű telepítés Legacy , avagy BIOS módban GPT-s lemezre.Telepítéskor ugyanúgy a /dev/sda-ba kell küldeni a grubot és ekkor a bios_grub partícióba fogja írni a Grub2 core.img álományt , ez veszi át az MBR szerepét a GPT-s lemezen. Ezen már annyi primer partíciót csinálhatsz amennyit akarsz 4-től sokkal többet.
-
#104392
ubyegon2
félisten
fekete.puma
#104391
válasz
fekete.puma
#104391
üzenetére
Szerintem manuális partcionálással érdemes csinálni, én is csak azzal tudom majd. Kijelölöd az EFI-t neki és csinálsz egy /-t Btrfs-re, videón is ezt csinálja az ember, mondjuk fura, mert nem a manual particionálást választotta előtte vagy csak nem vettem észre!
-
Dißnäëß
nagyúr
válasz
Dißnäëß
#104387
üzenetére
Látható, hogy a feloldás után az lsblk beteszi a virtuálisan létrejött /dev/mapper-es alias-okat az őalattuk lévő tényleges eszközhöz. (Ábrázolásban a fizikai alatt van a logikai a könnyebb megértés végett, de beszédben úgy mondjuk, az eszköz felett van a titkosított réteg és afölött a fájlrendszer az adatokkal). De ez míg nincs feloldva semmi, nem is látható, sőt, header hiányában még csak nem is sejthető. Persze, Ti mostmár tudjátok
de úgyis átalakítom az egészet a napokban, szóval mindegy is.Műxik szépen.
Na jó étvágyat !
-
#104389
ubyegon2
félisten
fekete.puma
#104386
válasz
fekete.puma
#104386
üzenetére
Azt írja, hogy hozzon létre egy 8MB-os formázatlan particíót bios-grub jelzővel.
Ez érdekes, mert az oldalán lévő videóban a 100MB EFI-t kattintotta be az ember, nem volt szó külön 8MB particióról. No mindegy, kíváncsivá tett a dolog, ha hazaértem, meg is nézem. Melyik verziót töltötted le, a minimalt vagy a normált? A zram megléte nem sok vizet zavar egyelőre... -
Dißnäëß
nagyúr
válasz
cigam
#104382
üzenetére
Nem, mert adatot vesztenék és féltem őket.
De ki tudod próbálni Magad is:
1. hozz létre egy NTFS partíciót egy pendrive-on, vagy egy random fájlon, amit felveszel loop device-ként meghajtónak a tesztre.2. nézd meg, hol ér véget és adj egy ide mutató (vagy ennél későbbre) offset-et a cryptsetup luksFormat-nak (most már csak cryptsetup Format azt hiszem), így csak az emögötti részt titkosítod le vele. Az offset-et 512bájt többszöröseként kell megadni, szóval egy számológép kellhet..
mire eljutsz X gigára vagy terára, attól függ, honnantól szeretnéd titkosítani a diszket. Ugyanitt a luksFormat-nál adod meg, hogy --header és tedd ki egy külön fájlba (pl. root-ba, vagy tesztnél mindegy is), így a konténer elejére ő már nem fogja odarakni azt. 3. Linux reboot és/vagy a létrehozott titkosított helyett luksClose-al zárd le, mintha fel sem oldottad volna és akkor nem kell reboot. Bár luksFormat csak létrehoz úgyis, felnyitni nem nyitja azonal úgy emlékszem.. Mindegy is. Legyen zárva, innentől ez eltűnik a szemed elől, header hiányában semmi sem fogja mutatni a létezését.
4. Az NTFS partíciót BÁRMILYEN oprendszerből és BÁRMILYEN programmal lazán ráhúzod a mögötte lévő "üres" területre. Azért idézőjel, mivel üresnek látja minden program, miközben Te tudod, hogy ott egy LUKS konténer, amit fel tudsz nyitni, mert tudod, hol kezdődik, Nálad a kulcs és Nálad a header fájl is.
Bármelyik hiányában (offset mértéke, amit luksOpen-nek megadsz), kulcs vagy header, buktad az adatot. Szóval amiatt, mert nem látszik a feloldatlan partíció, bármikor bármilyen tool-al üres helyet látsz a helyén, innentől már gyerekjáték egy NTFS resize.
Amúgy hülyeséget írok, ehhez nem kell zártnak lennie. Particionáló tool-ok a felnyitott konténert nem veszik számításba (lásd üres Gparted képem), csak a fizikai diszket nézik, ott meg üreset lát, ergo így is engedi ráhúzni az NTFS-t, mivel ez neki üres hely. Ami aztán okoz rendesen galibát, ha írsz is utána erre az NTFS-re (SSD esetén pedig ahogy beindul a TRIM a titkosított régióra is, mivel fölé húztál egy rahedli üres NTFS szabad helyet, valszeg másodpercek-percek alatt szétkúrja az egészet, míg ha nem húzod fölé az NTFS-t, nem fogja bántani a kontroller, mert nem kap olyan TRIM parancsot az OS-től, hogy ott nincs adat. (Azt sem kapja, hogy van adat. Nem kap arra a régióra vonatkozóan semmit, ergo békén hagyja).
-
Dißnäëß
nagyúr
válasz
sh4d0w
#104380
üzenetére
Nem tudom mi vicces, én nem rúgtam Beléd...
Nem azon múlik egy LUKS régió (nevezük konténernek, nevezéktan most másodlagos) felismerése, hogy ismeri-e a fájlrendszert a Windows vagy sem, mert a GPT particiós tábla - mint ilyen - univerzális, azaz egy BSD, egy Linux, egy Windows, de lehet még valami bármi egyéb hülyeség is ugyanúgy ismerni fogja ezt és a benne lévő partíciók adatait, geometriáit, darabszámát. Csak a fájlrendszer kérdőjel bennük, ez valóban oprendszer függő, Windows csak a határokat látja, az ismeretlen beltartalomra ugat egy unformatted-et, viszont a Linuxok kezelői is ugyanezt látják. Hogy miért ?
Amit írsz a header-ről az igaz, csakhogy nálam a konténer header-je le van választva róla és máshonnan tölti be azt a rendszer a boot folyamat során, amit kihúzok a gépből amikor otthagyom. A kicsit is óvatosabb titkosítást érdemes ezzel indítani, mivel a header-ben tárolódik lényegében minden esszenciális adat a mögötte levő további adatok eléréséhez, ergo ha a header hiányzik, nem visszafejthető az adat még kulccsal sem. (Nekem nincs header backup-om, de van rá mód, ha sérülésnek lenne kitéve az adathordozó eleje).
A luks ad arra lehetőséget, hogy a header-t külön fájlba tegyük a konténerről leválasztva, így innentől a tényleges titkosított partíción vagy diszken valójában már csak a színtiszta betitkosított és emiatt randomnak tűnő "adatszemét" fog látszani, udisks, lsblk, blkid és minden más számára is, de még jobbat mondok, még a cryptsetup számára is (!), mivel header hiányában a büdös életbe fel nem oldja senki még kulccsal sem. Nem tudja, hol kezdődik a régió, mivel lehet offset-elni is azt X megával-gigával (nem tettem), nem tudja, milyen titkosítás típussal, kulcsok párja is itt tárolódik... minden hiányzik és autofelismerést maga a kriptográfia akadályozza. Nincs header, nincs visszafejtés, annak annyi.Ezért fordulhat elő az, amit látsz, hogy a gparted-em így néz ki és azt jelenti felénk, amit mutattam, miközben fel van nyitva a HDD és van rajta némi adat. A gparted ugyanis nem listázza be a felnyitott LUKS konténer tartalmát az őt tartalmazó fizikai (vagy logikai) meghajtóhoz, hanem csak azt nézi, mi van a tényleges meghajtón, az lsblk pedig kényelemből megteszi ezt nekünk, ha már feloldottuk.
No.
Bejöttem egy Rocky 9.5 Live ISO-ról, mintha külső avatatlan szem lennék, mondjuk betörő, aki felkarolta és elfutott a géppel és a haverja IT-s és nézegeti, mi van a gépen. Linux-al, mert "az pró".
Látható, hogy a 4db Seagate-en az égvilágon semmit nem lát, eddig ugyanaz, mint a parted. Vakon van. De hát miért is látna Header nincs, GPT nincs, semmi sincs, egy vacak bit nincs, ami értelmes adat számára, így aztán "üres, pucér" diszk. Windows erre ugat, hogy lehet inicializálni, én meg mondom, hogy *nyád azaz nem, mert a SAS kontrollert komplett kikapcsoltam Device Managerben.
Dettó. Lehet particionálni, akármi.De ha hexa editorral esne neki valaki bármilyen low vagy nemlow level módszerrel, akkor sem fog mit látni a csomó "hülyeségen" kívül.
Természetesen blkid az üresnek hitt drive-on használhatatlan, semmit nem mond, a cryptsetup pedig onnan tudja, hogy hova kell nyúlnia header-höz (majd onnan a tényleges adat részhez), hogy megmondom neki, hogy
1. hol találja a kulcsot
2. hol találja a header-t
3. mi a felnyitandó HDD (wwn alapján /dev/disk/by-id/wwn-...)
4. és ha van esetleg offset, még annak mértékét is megmondom.. különben előző pontok hiába pipa, elbukik a kinyitás és marad a nagy semmi nézése.
Azt látom, többen nem értitek, remélem így tisztább.
(Szól cigam-nak is, no offense, Neked mindjárt külön)
Ha visszamegyek a normál rendszerembe mindjárt, ami feloldja /etc/crypttab-ból a drive-okat, látni fogjátok, hogy az ottani lsblk mindegyik seagate alá beköti a /dev/mapper-ben felvett, anno megadott alias-t, hogy a feloldott rendszer tulaja lássa, mi tartozik mihez.
Ezt egy ismeretlen, feloldás nélkül, a büdös életbe nem fogja látni.
De adok szívesen egy pendrive-ot, amire teszek ki Nektek adatot, előtte LUKS titkosítom header nélkül, próbálgassátok. Vagy még jobb, csinálok egy image-et, amit loop device-ként tudtok mount-olni és lehet nézni, mizu.
Neeeem, nem vagytok se Ti mazochisták, sem én.Értsétek meg a pofonegyszerű logikát: nincs header - nincs felismerés.
Csakis célzottan, egzakt rámutatással (ami infónak birtokában vagyok nyilván) lehet felnyitni cryptsetup-al az ilyen tárolót, én pedig pont így teszek, mert ilyenre csináltam.
És pont ez a felismerhetetlenség az, ami okozott bennem egy kezdeti törpölést, hogy akkor mi van SSD és TRIM esetén, de a választ megkaptam.
Na megyek vissza és kérdezzetek még, ha szeretnétek, kicsit nyűgös az 1080p, a 4K meg vibrál ezen a live-on
-
-
#104385
hcl
titán
fekete.puma
#104381
válasz
fekete.puma
#104381
üzenetére
Miért lenne ebből Cinnamon csinálva? Konvencionális elrendezés van csinálva. Tök nem úgy működik,mint egy Cinnamon.
A tabletemen az XFCE is hasonlóra van megoldva.
-
#104384
ubyegon2
félisten
fekete.puma
#104383
válasz
fekete.puma
#104383
üzenetére
Bár úgy lenne..
Ha ez a Big Linux, akkor viszont rossz hírem van, BTRFS-t még nem kezdtem el megismerni, így ezek a subvol valamik is csak ismerősek, de manuálisan nem tudnék velük mit kezdeni! Nyilván elsők között a particionálást érdemes rutinná tenni. Szóval ebben nem tudok segíteni, sorry!! -
válasz
Dißnäëß
#104379
üzenetére
Ne rohogtesd korbe magad. A Windows a sajat filerendszerein kivul semmi mast nem ismer, persze, hogy allokalatlannak mondja - es akkor jojjon nehany parancs, amivel siman eszre kell venni a LUKS kontenert:
udisks, lsblk, blkid, cryptsetup
Minden LUKS kontenernek standard headerje van, hexdumppal siman kinyerheto a header informacio es minden modern Linux disztribucio - ha maskor nem, hat mount idejen - detektalja azt. A kepeiden szereplo lemez valoszinuleg nincs mountolva, de ha megteszed, akkor latni fogod, hogy LUKS kontener.
Mondjuk a lenyegen nem valtoztat, mert ha nincs mountolva, nem lesz ra trim.
-
Dißnäëß
nagyúr
válasz
sh4d0w
#104377
üzenetére
Már hogy venné észre akármilyen random Linux ?
Ugyanazt a mozit nézzük ?
Egyik HDD-m a négyből, ez a nyers drive nézete (nem a /dev/mapper-es felnyitott ekvivalenséé értelemszerűen). Ez full disk encryption LUKS-al. Amit LUKS-ban lehet amúgy offset-elni, hogy ne a legelső szektornál indítsa, ergo akkor csak kevesebbet titkosít le belőle. Se kontroller, se más OS, se emberfia meg nem mondja, mi az a random szemét ...
A Windows ugyanezt látja és amikor a SAS kontrollert bekapcsolom (mert le van tiltva eszközkezelőben), detektálja mind a 4 HDD-t és megkérdezi, hogy inicializálja-e őket, mert tök szüzek. Nyilván cancel, különben száll minden, hiszen nem szüzek..Spéci szoftver is akkor tudja nagyjából megtippelni, hogy bármivel is titkosított a drive (úgy egyáltalán), ha a header-je rajta van az elején. Nálam ez sincs, külön vettem, akárcsak a kulcsokat, de ez mindegy is.. a header-t is tartalmazó nyers LUKS titkosított drive is tök láthatatlan azon OS-ek számára (mind számára), amik rajta kívül állnak. Lehet egy NSA-nek van féltve őrzött tool-ja ilyenek kinyitására, minthogy minden opensource kripto- és szteganográfiai projektben ott vannak (lásd backdoor), de most ezzel komolyan nem foglalkoznék mélyebben, meg ha vki rájönne, hogy van ilyen, az nagyot durranna.
Az, hogy Te hozol létre egy normál GPT partíciós táblát és azon belül egy formázatlan akármilyen partíciót, majd azt titkosítod LUKS-al, vagy mással, engedi magát detektálni - értelemszerűen, de itt szó nincs erről és nem is utaltam rá. A Windows partícióim között ott éktelenkedik a szintén LUKS-os linux gyökerem, evidens, hogy egy nemtitkosított táblában látszik, még label is adható neki, nem csak a típusa, hogy az ott adat lesz, ha tudod a jelszót..
Ember legyen, aki a telibe titkosított HDD-ről felnyalt "random adatszemétről" megmondja, hogy valódi fájlrendszer van felette értelmes adattal, pláne úgy, hogy nem írtam végig dd-vel nullákkal a /dev/mapper eszközt a mindennapi ajánlások ellenére, magyarul az alatta lévő rétegen sem írta random szarral tele a diszket a LUKS, csak ahova tényleg kitett adatot a felette lévő felnyitott rétegben (amiben olyan fájlrendszer van nyilván, amit csak akarunk, teljes értékű eszköznek látszik). Ergo, kívülről nézve egy editorból nagyjából random szemét és előző tulajtól származó további szemét és nullák váltják egymást.
Ha ugyanezt megcsinálod egy SSD-vel, addig fogja tudni a kontroller, hogy mely részein van értelmes adat, amíg a titkosítást létrehozó oprendszer erről árulkodik neki bármit is (mivel a LUKS is tud discard-ot, a biztonság rovására, de azért az sem úgy megy, mint a filmekben).
Ahogy bootolsz másik OS-el, a másik OS azt fogja jelenteni a kontrollernek, hogy "üres diszk" és amint létrehozol rajta egy partíciót (kicsit vagy telibe, mindegy), egy fájlrendszerrel, azonnal indul a trim parancsok kiadása és az SSD megtudja, hol van adat és mi a free space, utóbbit már szabadítja is fel.
Hja, csak közben belerondíthat az ott lévő "random szemétbe" ami nagyonis rendezett, semmi random, csak annak látszik. Ez HDD-n nem fordulhat elő, mivel csak akkor nyúl a fej ezen részekre, ha konkrét access érkezik ide, nem pedig üresjáratban is dolgozgat a háttérben és írogat felül cellákat, blokkokat, page-eket, akármiket, mert úgy hiszi hogy dolgozhat vele.
Amikor a Samsung SSD Magician is Overprovisioning-et állít be, lényegében egy formattálatlan nyers partíciót hoz létre a meglévők közé, jelezve ezzel OS-nek (és az meg az alatta lévő SSD vezérlőnek TRIM által), hogy az ott üres terület, lehet vele játszani. Holott fizikailag ki tudja milyen randomszemét van azokban a cellákban is, de az SSD onnantól simán felülírogatja őket, pakolgat ide-oda-amoda, wear leveling dolgozik, Neked meg ugrik a titkosított részed.
Mire ezeket bepötyögtem, megerősítettek, hogy csak úgy működik a dolog, ha nincs átfedés a látható - mondjuk - NTFS partíció és a mellé tett (láthatatlan) LUKS konténer között.
A működési elv: ha a fájlrendszer töröl egy inode-ot (vagy típustól függően hasonló logikai alapegységet), akkor a TRIM parancsot küldi az SSD-nek és informálja arról, hogy az ahhoz az inode-hoz társított adatblokkot felszabadíthatja. Mivel egy NTFS fájlrendszer nem menedzseli azokat a blokkjait egy SSD-nek, amik titkosítottak, nem is fogja azt mondani az SSD-nek, hogy szabadítsa fel azokat, kivéve ha kiterjesztem átméretezéssel az NTFS partíciót arra a területre is.
Magyarul, amíg a látható NTFS (vagy egyéb) és a láthatatlan titkosított adat egymás mellett vannak logikailag, nem lesz gond. Ha a látható átlapolódik részben vagy egészben a láthatatlanra, SSD esetén TRIM miatt kinyírja azonnal a láthatatlan titkosított részt ezzel, mert annak vezérlője a területtel elkezd "játszani", felszabadíthatónak tekinti onnantól, míg HDD esetén eljátszható simán, hogy egy NTFS partíciót kiterjesztünk rá a titkosított területre és amíg nem írunk rá, illetve arra a területre (amire nincs ráhatásunk), addig az nem is lesz bántva. Értelme nem sok, max fóbia-paranoia esetén, hisz veszélyeztetjük NTFS írás esetén a titkosított, ott és akkor üresnek látott területet, de mint megoldás működik.
Jót beszélgettünk.
-
válasz
Dißnäëß
#104371
üzenetére
Teljesen mindegy, hogyan fogalmazol, az ott egy titkositott kontener lesz es nem nyul hozza a trim, amig nem nyitod meg es kifejezetten nem adsz utasitast arra, hogy az is trimmelesre keruljon.
A LUKS kontenerek igenis detektalhatok, tehat akarmilyen masik Linuxot futtatsz, legyen az live vagy telepitett, eszre fogja venni.
-
válasz
Dißnäëß
#104371
üzenetére
Olvasd el még1x a válaszokat. A TRIM nem az egész lemezen fut le, hanem csak az adott partíción. Ha nincs felcsatolva, nem fogja módosítani (fájlokat törölni!), egyetlen szektor státuszát sem fogja módosítani.
Amikor kiadsz egy törlés parancsot, az SSD csak felveszi egy listában, hogy x,y, és z szektorok felszabadultak. Ha jön egy TRIM parancs, akkor fogja ezt a listát, és és mindent nulláz rajta.
Úgy képzeld el, hogy két listája van a szab területről, egy piszkos, és egy tiszta. A TRIM kitisztítja a piszkos területeket, és átteszi őket a tiszta listára.Ha nincs felcsatolva a titkosított(vagy bármely másik) fájlrendszer, hogyan tudna bármilyen OS beletörölni, hogy legyenek rajta új törölt ("piszkos") szektorok?!
A háttérkép ficamokat miért ide kell posztolni?!
-
válasz
Dißnäëß
#104371
üzenetére
Sok érdekes dolgot vetettél fel, sajna a LUKS és társai nekem sötét ló. Amúgy a Live Linux nem fogja trimmelni a külső meghajtót, de még a belsőt se. Alapból teljesen más a külső SSD-k kezelése, de nem is csak a Linuxtól függ. Ha a header megváltozik, az egyértelmű helyzet, de akkor viszont meg már az a biztonsági kockázat, ha fenn marad a régi.
Szerintem ásd bele magad ezekbe, mert tuti ott a válasz is valahol:
Frequently Asked Questions Cryptsetup/LUKS
Enable TRIM on external LUKS encrypted drive
Tetszik az előbbi Cinnamonos desktop képe, csak nem valami NER-es jómunkásember yachtja látható rajta!?
Nekem csak a T-REX van most a desktopon...innen tudom, hogy a négy hasonló rendszer közül melyiken vagyok.
-
#104372
hcl
titán
fekete.puma
#104370
válasz
fekete.puma
#104370
üzenetére
Gnome. Szétkiegészítőzve, így normális OS-ként működik
-
#104371
Dißnäëß
nagyúr
tordaitibi
#104357
Dißnäëß
nagyúr
válasz
tordaitibi
#104357
üzenetére
Szerintem szétszórja. Miért ne tenné ?
Konténer itt nincs. Még partíció sem.
Tehát mégegyszer:
- Live linux
- LUKS titkosítom offset-et megadva neki az SSD második felét (vagy még hátrébbtól)
- megnyitom, lesz egy /dev/mapper/akármim és ezen partíció, majd adatok rá
- reboot, live linux usb kiBárhova viszed az SSD-t, semmi meg nem fogja mondani, hogy titkosított adat van a "második felén". Az ott kívülről random adat, nem megmondható, hogy micsoda, pláne ha még a header is máshova van téve.
Windows usb be, vagy másik Linux, mindegy.
SSD elejére feltelepít.
Bootol, minden szupi.Lejelenti az SSD-nek egy ponton a trim támogatás miatt, hogy mi az, amit ő foglal és értelmes adat. A többi mehet a levesbe.
Kontroller megkapja ezt az infót és azonnal úgy tekintheti, hogy minden egyéb, ahol nincs ezen OS által lejelentett területen adat, szemét, ergo a cellákba írhat, felszabadíthatja azokat, akármi.
Magyarul, szétcseszheti a titkosított részt akár.
Vagy nem
Erre irányul a kérdésem.
-
-
#104367
hcl
titán
tordaitibi
#104363
válasz
tordaitibi
#104363
üzenetére
Nagyon. 4TB-os SSD 40k körül van...
@fekete.puma : Ez egy 8.generációs cucc, nem mostanában tervezem cserélni
Ez m.2 SSD. Az eddig használt T430-ban a 4 magos i7 mellett SATA SSD volt Amúgy nem, ez laptop, van ugyan rajta KVM, lehetne rajta gép is, de minek? Amin a videovágós VM is van, az egy KVM host (az a NAS-om is), az is 8. genes i5-8500, 32GB RAM-mal, 2x4TB winyó ZFS tükörben, meg egy 32GB SATA SSD-ről fut. Mind a kettőn Debian Testing van
(Ami fizikai gép itthon van, az vagy Testing, vagy Alpine) -
#104366
ubyegon2
félisten
tordaitibi
#104357
válasz
tordaitibi
#104357
üzenetére
Nem nagyon lenne műlödőképes ssd ha ezt így csinálná.
Vagy mégiscsak!
Nem nagyon érdemes belemenni, most hirtelen nem is ugrik be, de itt is külön vehetjük a user meg az OS meg a controller szerepét. Utóbbi egy vagy két dologért felel ráadásul, most hirtelen meg se mondom, melyik vakegér szaladgál cellákat törölgetni és melyik a blokkokat rendezgetni.Kb ez a zanzája:
"Az SSD legkisebb egysége a lap, amely több memóriacellából áll, és általában 4 KB méretű. Az SSD-n több lapot egy blokkba foglalnak össze. A blokk az SSD-k legkisebb hozzáférési egysége. Jelenleg többnyire 128 oldalt egyesítenek egy blokkba; így egy blokk 512 KB-ot tartalmaz." (ez így lefordítva kicsit értelmetlen, de most már mindegy, szóval ne zavarjon, ha úgy is szerepel valami, mint a legkisebb egysége és úgy is, mint a legkisebb hozzáférési egysége)
Az adatok írása/olvasása a blokkokban/ból történik, fura is lenne, ha a layout felépítése ellenére neked 1M méretű képet egy helyre akarna pakolni. De miért is tenné? Gyakorlatilag ugyanannyi idő neki elérni a blokkokat, akárhol is vannak.
Gyakorlatilag minden szétszórva, mint anno a HDD-n, csak ez itt nem számít töredezettségnek, de egy vakegérke mindig szaladgál, így van amelyik rendszerhasználat alatt is dolgozik és van amelyik csak akkor, ha hallja, hogy nem mozog semmi.
csixy komám ezt most értelmesebben leírta, mint én!
-
#104365
csixy
addikt
tordaitibi
#104357
csixy
addikt
válasz
tordaitibi
#104357
üzenetére
Pedig szétszórja, szétsz@rja mint a ventillátor a Móriczka viccel a cukrászdában. Persze hogy tudnia kell, hogy mit hova tesz, ... és mégis ez a működése lényege. De ezt mi nem látjuk, Mert "kettős könyvelés" van. Ez eddig a hardver és a vezérlő rétege. Ezen a háborgó kavargó fortyogó trutymó óceánon úszkál a mi flottánk a partíciós táblánkkal és a partícióinkkal és az állományainkkal. Szürreális dominójáték. Csak azt lehet remélni, hogy , amikor semmilyen írási-olvasási-törlési-trimmelési művelet nem történik a flotta szintjén , akkor az alap trutyi óceán is kussol és nem csinál semmit. ... Szerintem. Ezek miatt érdeklődöm a slaxos ramba töltős rendszerek iránt. Az az igazi immutable rendszer nekem.
-
#104364
ubyegon2
félisten
tordaitibi
#104363
válasz
tordaitibi
#104363
üzenetére
Ha nagyon akarod szétpattintom bár fel van sziloplasztozva a monitor hátuljára.
Ha egyszer lesz kedved, szétpattinthatnád, de jól olvashatóan fotózd ám le a NAND-ot meg a controllert meg ha még van benne valami. Ha egyáltalán van rajta valami írsá, számsor.
Vagy mennyire kamu?
Ez a piros csoda mennyire kamu?
Szerinted? 4TB külső SSD 12rugóért? Sokszor valami kisebb méretű SD Card van beapplikálva egy NYÁK-ra, de behazudja kiolvasáskor a rendszernek, hogy 4TB, csak ha majd írsz rá, akkor áll meg 128gigánál. Szerintem ezt ne próbáld be. Aliról szoktak sokan venni 16TB-os SSD-ket 8-10000 pénzekért. Az a durva, hogy ezeket sokszor fel is rakják ide az apróra, ha valaki jelenti őket, akkor meg azt rúgják sejhajon, mert hát nem is hamisítvány! -
#104363
tordaitibi
veterán
ubyegon2
#104360
válasz
ubyegon2
#104360
üzenetére
Ha nagyon akarod szétpattintom bár fel van sziloplasztozva a monitor hátuljára.
Az Intenso ami nekem van az most 43ropi.
És akkor [ez miből van összerakva...?] Vagy mennyire kamu?
Komolyan mondom rendelek egyet, 12ezerért már az ajándék ha egyáltalán működik. -
DRAM cache-sel szerelt SSD-re gondolsz? Amúgy PCIe NVMe esetén jóval kevésbé hiányzik a DRAM cache, ráadásul itt már bőven pótolja a NAND-on belül beállított saját cache vagy a host memory buffer, ezért is csak a jóval drágább NVMe SSD-ken van DRAM cache. Legjobb példa erre a Samsung 980 és a 980 Pro, előbbi csak HMB-s, de sokkal olcsóbb. Volt anno. Amúgy meg normál Linux használatnál nincs is sok jelentősége a DRAM cache-nek, de a parasztvakító szekvenciális sebességnek se nagyon. Nem véletlenül szerelik a használtüzleti notikat adott modellkategórián belüli alkatrészekkel, de jóval lassabb szekvenciális sebességre programozott controllerrel, igaz ez főleg a melegedés kivédése miatt van. Van pár kivétel persze, ahol az energiafogyasztás csökkentésével tudták megoldani az óvatosabb melegedést és a szekvenciális sebesség maradt ugyanakkora, mint a konzumer kiadásnál. Ilyen a SK Hynix PC801 például, ami a rohadt drága SK Hynix Platinum P41 OEM verziója. Épp egy ilyenre vadászok megint, mert ami volt, azt beraktam családon belüli gépbe, de saját Dell Latitude-ban se tudtam rendesen letesztelni, mert csak x2-es PCIe 4.0 csatlakozó volt benne. A mostani Zbookban is van két M.2 PCIe hely, de fogalmam sincs, melyik milyen, most valami ezeréves Samsung OEM van benne, az tuti csak PCIe 3.0.
-
#104361
fekete.puma
tag
hcl
#104358
fekete.puma
tag
A gyorsabb SSD időtállóbb, ha gépet cserélnél pár éven belül.
Nekem most az asztaliban I5 3470-es proci van, érzem már ennél is, hogy nem asz igazi.
Laptop esetén gyengébbre vagy kicsit erősebbre biztos nem váltanék.
Azért nyugtass meg, hogy nem azon a laptopon vágsz videót VirtualBox-ban teljes megelégedéssel? -
#104360
ubyegon2
félisten
tordaitibi
#104350
válasz
tordaitibi
#104350
üzenetére
Ennyiért ingyé vót
Egy Intenso? Ha úgy nézed, hogy kidobtál az ablakon egy huszast, de az SSD meg ingyér van, akkor úgy OK! Ha még le is írja az eladó, hogy van valami érdekes nyűgje...gondolom nem zavart, hogy fogalmad sincs, mi okozza ezt a leállást és bármikor végleg megnyekkenhet! Engem pont az zavar egy ilyen eszközben, ha nem tudom, mi miért történik. Anno 1,92TB Samsung PM883-at vettem használtan, rohadt drága volt, de benne volt az árában az is, hogy sose megy tönkre és amikor M.2-es platformra váltottam, majd ugyanannyiért el tudtam adni szintén az aprón. Nincs kedved szétszedni, hogy megnézzük, milyen NAND meg controller van benne? -
válasz
Petya XT
#104348
üzenetére
Lehet szóba is került már ez az Intenso SSD-d, a Kingstonra emlékszem inkább. Nem egy kategória volt a kettő régen sem, de az Intenso ugyanúgy lehet teljesen jó, mint ahogy kukaszökevény, ennél a zsákbamacskajelleg az idegesítő. Gyakorlatilag kínai dzsunkaSSD mintájára történik a gyártás, amit találnak a hardverpiacon, abból összeforrasztják az eszközt és ezek az esetek többségében működnek is.
Nekem is volt/van tartalékba sok régi 120GB meg 250GB SSD-m, többnyire használtan vettem ezeket, jók ezek, mert ha kell családban is régebbi notikba hirtelen, van mihez nyúlni. Viszont soha nem voltam olyan bátor, hogy Intensot vegyek!
NVMe SSD-ket is egy ideje az apróról veszem, ami meg a használtüzleti notikkal jön, mind elrakom, mindig jól jöhet. El még nem pusztult SSD-m, valami Kingston Fury 120GB rosszalkodott minap, de gyorsan ki is cseréltem legelső újonnan vett SSD-mre, Intel 520 120GB, no ez rohadt drága volt anno, igaz kb sose fog tönkremenni. Az ócskább SSD okán lehet olyan funkció, ami nem kerül bele, vagy minden típusú SSD-n ugyanazokat a beállításokat használja az adott rendszer?
Szerintem ilyen ócskább/nem ócskább alapon nem szelektál a rendszer! A spécibb SSD tulajdonságokkal nem is foglalkozik, beazonosítja, hogy Sata meg milyen NAND van benne, nagyjából ennyi.Ha a Linux Mint upgrade-elt verzió, akkor úgy érthető, ha már nem egy eredeti állapot van a systemd.service résznél. Régebben én is variáltam ezekkel telepítés után, mert mindig van, amiket ki kell lőni, vagyis inkább érdemes, mivel sok időt elvisznek a bootból. Viszont mióta EFI boot van, nem foglalkozom vele, úgyis sok a bootidő.
-
#104358
hcl
titán
fekete.puma
#104355
válasz
fekete.puma
#104355
üzenetére
Így van. Szóval csomót spóroltam, a drágább SSD-val se lenne gyorsabb... és egy Debian így is megy mint állat.
-
#104357
tordaitibi
veterán
Dißnäëß
#104346
válasz
Dißnäëß
#104346
üzenetére
Paraszti logikámmal arra jutottam amit itt le is írtak.
1 konténer az 1 fájl, akkor is ha 1 tera nagyságú.
Azaz tudja a vezérlő, mégha 4k "szektor" méretet is használ, vagy a 2 bármelyik hatványát hogy ezek 1 fájlhoz tartoznak.
Szép lenne ha egy pl. 1M méretű jpg képet vagy az oprendszer fájljait szétszórná a nand területen csak épp nem jegyezné meg hogy melyiket hova is tette.
Nem nagyon lenne műlödőképes ssd ha ezt így csinálná. -
válasz
Dißnäëß
#104346
üzenetére
sh4d0w és cigam kolléga lényegretörően megválaszolta(hamarabb is észrevehettem volna), de itt valóban elég speciális helyzet van, ezért kb ennyi a lényeg:
Solid state drive users should be aware that, by default, TRIM commands are not enabled by the device-mapper, i.e. block-devices are mounted without the discard option unless you override the default.
For a LUKS2 device, TRIM support can be enabled by using the
--allow-discards --persistentoptions when opening it. Theallow-discardsflag will be written into the LUKS2 header and the option will be automatically used whenever the LUKS2 device is opened.
-
#104354
hcl
titán
tordaitibi
#104350
válasz
tordaitibi
#104350
üzenetére
Nézd meg, nem-e állítja le az energiagazdálkodás
@fekete.puma : Én is cache-s m.2-es 1TB-t akartam az új gépbe, de végülis rájöttem, hogy elég az olcsóbb is egy PCIe 3.0-s gépbe (Lenovo T480), szóval... tök elég.
-
#104353
Petya XT
senior tag
fekete.puma
#104352
Petya XT
senior tag
válasz
fekete.puma
#104352
üzenetére
Olyan régi gépeim vannak, hogy nincs hová betenni. Nincs olyan csatlakozó a gépeimben. A legfiatalabb 12 éves.
Egy napszámos már szinte megkeres ennyit egy nap, közmunkázni tetszik? Ilyet úriember nem kérdez.
Egyébként nem. -
fekete.puma
tag
válasz
Petya XT
#104351
üzenetére
Egy 500GB M.2 SSD ami hoz egy jobbnak mondható sebességet Max olvasási sebesség: 5000 MB/s Max írási sebesség: 4000MB/s Intenso 14.4K, WD 17.4K.
Ez olyan sok? 3K különbségért biztos nem az olcsóbbikat venném.
Egy napszámos már szinte megkeres ennyit egy nap, közmunkázni tetszik? -
Petya XT
senior tag
válasz
cigam
#104349
üzenetére
Ez sem teljesen igaz minden disztróra. Nálam hetente lefutott a LUKS-os lemezeken is, köztük a rendszerlemezen is. Lekopogom, soha nem volt probléma. Volt manuális TRIM is. Sokat kérdezgettem, itt is, hogy ez most oké, vagy nem oké, honnan tudja a vezérlő, hogy mit kell pucolni. Valami biztonsági dolog miatt nem javasolták, egyébként működött nálam, ha jól emlékszem a fstrim.timer is aktív volt. Ez LM volt. Már nem tudom melyik verzió. Mondjuk egy VC felcsatolt konténerre kíváncsi lennék, hogy ott mi a helyzet.
Tibi:
Az annyiért nagyon jó vásár volt! Brutál árakat láttam ma.... -
#104350
tordaitibi
veterán
Petya XT
#104348
válasz
Petya XT
#104348
üzenetére
Másfél éve megy nálam egy 2TB Intenso, itt vettem a HA.-n használtan 20ezer kemény magyar forintért.
Háttértár, eddig egy szavam nem lehet rá.
Annyi a nyűgje ha 1-2 óráig nem kell, azaz nem nyúlok hozzá, akkor gondolkodik kb. 1-másfél másodpercet, és utána minden gyors megint.
Emiatt adta el az első tulaja, és ezt korrekten le is írta.
Ennyiért ingyé vót -
Petya XT
senior tag
válasz
ubyegon2
#104335
üzenetére
Intenso SSD. Ezt megkaptam kemény 4500 forintért, volt 128 GB-os verzió más gyártótól 20000 forintért is, amikor ezt vettem. Nekem annyi a lényeg, hogy menjen, nem igazán értek hozzá, rám egyébként is jellemző, hogy alsópolcos vásárló vagyok, mert nem nagyon van zsé. Számítástechnikára, telefonra stb. meg csak a legvégső esetben költök, akkor is a legolcsóbb megoldást választom, vagy a használt dolgokat. Nem tudom emlékszel e a Kingston SSD-mre, amin 71 TB írt adatt van. A mai napig hajtom, TV alatt brandben. Majd megpusztul egyszer, addig menjen csak.
Ma volt a MédiaMarkt-ban. Nézegettem az SSD árakat, tátottam a pofám rendesen. 8 ezer forint alatt nem is volt SSD(persze a legkisebb 128-as), de volt 70 ezer forintért is. De annyi féle volt, hogy ráhagytam, felét nem is ismertem, azt sem tudom, hogy milyen foglalatba valóak, ilyen pálcika izék voltak. Volt ott 2 TB-os 2,5-es, hát nem semmi áruk volt. Ez van akkor, ha minden géped a jura korból maradt meg, elszaladt mellettem ez az egész hardver vonal.Tehát ez kb adott. Érdekes az fstab, mert mintha rémlene pár évvel ezelőttről, hogy egész biztosan volt pl. discard bejegyzés. Ez, ha jól emlékszem egy frissített rendszer volt, lehet az kavart be neki. Volt ezen a gépen Endevahúr, meg Manjaro is, ott szerintem nem volt ez probléma, de lemezképben megvannak a rendszerek, ha visszaállítom valaha, ránézek. Tényleg soványabbnak tűnik az fstab. Az ócskább SSD okán lehet olyan funkció, ami nem kerül bele, vagy minden típusú SSD-n ugyanazokat a beállításokat használja az adott rendszer?
-
Dißnäëß
nagyúr
válasz
ubyegon2
#104339
üzenetére
Van ugye a Veracrypt, Truecrypt, LUKS stb.
Honnan tudja az SSD vezérlő hogy egy adott logikai szektor üres lett ? Vagy hogy az ott lévő adat "szemét" ?
Az OS lejelenti neki discard-al ?
Oké.És ha egy SDD-n egy LUKS titkosított partíciót hozok létre a 2. felére, egy Live Linuxról, az első felére pedig telepítek egy másik OS-t, amit be-bootolok, az discard-ozni fogja a második felén lévő (rejtett, nemlátott) OS-t, azaz a trim, akár OS-é, akár garbage collection, kinyírja a LUKS-os partíciót csak mert nem az őt ténylegesen feloldó-használó OS-el boot-olok be ?
-
-
válasz
cigam
#104341
üzenetére
Azért elég sokan cserélnek/vesznek új SSD-t a gépükbe, notebookba. "Mit kell ahhoz érteni, rendelek egy super M.2-es SSD-t mert az kell bele!
Sok hülye okoskodik, hogy picit nem árt érteni is az SSD-khez." Megjött az SSD! Juhúúú....de jaj istenem valami baj van, semmi nem ismeri fel, pedig jó helyre csatlakoztattam!
brühühü...mi lehet a baj??? Rohaggyonmegabót átbasztak!!!! Juj gyerünk az SSD topikba!Gondolom sejted mi lehet a probléma a nagymellényen kívül!?
Érdemes nézegetni az SSD topikokat, milyen kérdések merülnek fel állandóan.
-
válasz
csixy
#104342
üzenetére
Ez jó, tesztelni pont megfelel
Pl. a tabletre, bár nem hinném, hogy kevesebbet kér, mint egy Alpine. -
csixy
addikt
Hajrá! Telepíteni sem kell tulajdonképp. Live módon fut. Elég egy pendrájra feltenni. Számtalan sok módon bootolható. Az sb modulok mellett van egy config fájl, ezen előre beállítható sok minden (nekem a magyar billenytűzetet nem sikerült előre beállítani). Viszont pont a config fájl miatt, mely a /run/memory/data/ mappában utólag is olvasható, belépés után egyből célszerű a passwd parancsot használni. Én a ventoy grub menüjét, vagy egy telepített linux gyökerébe másolva a /etc/grub.d/40_custom file szerkesztésével és egy sudo update-grub csatakiáltás után a telepített linux grub menüjével szoktam bootoltatni.
-
válasz
ubyegon2
#104340
üzenetére
Nem is cserélek olajat a lakótelep közepén! Más szerelni való meg nincs az autón
fekete.puma
Amúgy az, hogy régen az OS adta ki a TRIM parancsot, nem jelenti azt, hogy azóta is csak úgy működhet. A vezérlő chip simán rendet tarthatna. Az M.2 csak példa volt, hogy igen is megoldható házon belül, nem kell várni külső parancsra. -
válasz
cigam
#104336
üzenetére
Én pl. azon csodálkozom, hogy miért nem oldja meg házon belül, ahogy az M.2 csatolós eszközök esetében.
Érdekes lenne, de mivel ez egy ősrégi PATA/SATA utasítás és az OS-ek kompetenciája, így ebbe a gyártók nem fognak belenyúlni értelemszerűen.
A PCIe NVMe SSD-k TRIM-melést viszont már nem az OS végzi, hanem az eszköz vezérlője.
De mint említettem is többször, nem nagy gond, ha nem foglalkozik vele a user SATA esetén, mert még mindig ott a garbage collection, ami nevéből adódóan tisztogatja a már törölt adatokkal terhelt blokkokat.
De egyébként az SSD is egy hardver, mint a VGA meg a többi. Ha rengeteget foglalkozik a topik a VGA-k vezérlésével, miért lenne gond az SSD-k vezérlése, optimalizálása? A VGA is olyan eszköz, hogy nem kell ismernem a működését, felrakom a rendszert, aztán az használja okosan a megjelenítésért felelős hardvert. Nem? De!
Én csak arra utaltam imént, hogy gondolkodjunk okos pingvinként, ne hátbalőtt tapírként!
Ne üldözzük a gép egyik fontos elemének megismerhetőségi lehetőségét egy Kezdők OS-sel foglalkozó topikjából. -
válasz
ubyegon2
#104334
üzenetére
Ahhoz, hogy eljussak A-ból B-be, nincs szükségem arra, hogy tudjam hogyan működik a karburátor(pláne, ha elektromos autót vezetek
). A többség nem érteni szeretné, csak használni.
Természetesen nem árt, ha tisztában van azzal, hogy pl. az SSD hogyan működik, mit is csinál a TRIM. Én pl. azon csodálkozom, hogy miért nem oldja meg házon belül, ahogy az M.2 csatolós eszközök esetében. -
válasz
Petya XT
#104331
üzenetére
Csak az jött vissza, hogy /mnt/Archívum meghajtóm nem támogatja a discard funkciót
Manual fstrim előtt akár le is csatolhatod a HDD-t, bár elméletileg úgy volt, hogy a libata tartalmazta a nonrotate kitételt is, így a hagyományos merevlemezeket nem vette figyelembe.
Ott gyanús lett, hogy itt valami nem jó.
Valami tényleg gyanús, de ha telepítéskor default az ütemezett fstrim, akkor nem tudom, mi inaktiválta!? Mondjuk nem árt telepítés után ellenőrizni, hogy aktív-e, mert pár éve épp Kapitány jelezte, hogy a Manjaron kicsit elfelejtették berakni az fstrim.service-t az aktív ütemezetten lefutó feladatok közé.
De jellemzően vagy az online vagy az ütemezett TRIM minden disztrón alapból aktiválva van.
Lényegében egy jó SSD-t csak be kell szerelni, telepíteni rá és használni...Intenso SSD az más tészta. Annál csak a gyártás idején készült összeszerelő üzem dokumentációja tartalmazhatja, milyen komponensekből áll.
-
#104334
ubyegon2
félisten
fekete.puma
#104332
válasz
fekete.puma
#104332
üzenetére
Igen függ a tárhely méretétől meg a végrehajtott műveletektől.
Ezt nem a user számára látható szabad tárhelyre értettem, pont itt esett szó róla a napokban. Gyakorlatilag az 1terás tárhelyen nincs szabad hely a meghajtón, de a rendszer és a programok csak félterát foglalnak el, az az SSD vezérlőjének pontosan egy féltera szabad helyet jelent, míg a usernek nullát.Egy tesztere azért kíváncsi lennék, hogy a hét végére heti TRIM esetén ez valójában mit jelent.
Ezt kb akkor tippelheted meg, ha vasárnap 23:50-kor futtatsz egy manual fstrim parancsot, no kb annyi lenne a hétfő nulla órakor lefutott ütemezett fstrim eredménye. De nem érdemes nézegetni, az SSD nem kopik, a NAND-ok elhasználódása meg olyan ütemben történik, hogy mire elfogy a TBW-ben jelzett érték, már háromszor is lecseréled a tárhelyet. Amúgy meg a TBW marketingérték, csak a garancia miatt határozza meg a gyártó. Ha írsz rá 600TB-ot, ami a standard TBW egy TLC NAND SSD-nél, akkor sem történik semmi, csak megszűnik a garancia, ha egyébként még az évben meghatározott gariidőn belül van az eszköz.itt a Samsung 860 EVO 1TB Sata SSD adatlapja és a TBW értéke:
TBW 600TB (conforms 600TB per TB capacity)
[link]Ugyanez az SSD industrial kiadásban már más TBW-vel rendelkezik, pedig ugyanaz a NAND és a controler is benne! Nyilván van plusz védelem is, de ez a NAND használatot nem különösebben befolyásolja.
1.4PB (conforms 1458.3TB per TB capacity)
[link]Ilyenkor mindig letolnak, hogy Linuxos topikban SSD-ről írok, pedig szerintem nem árt, ha mindenki ismeri a működésüket és az elhasználódásukat. Elvégre erre az eszközre telepítjük a Linuxunkat is!
-
fekete.puma
tag
válasz
ubyegon2
#104327
üzenetére
Igen függ a tárhely méretétől meg a végrehajtott műveletektől.
pl VirtualBox esetén ha kevés a hely, törölni kell az előzőket 10-et töröl a héten az már 200-250GB körüli, mellette videóvágás és az adatmozgatások ha sokat hajt végre.
Egy tesztere azért kíváncsi lennék, hogy a hét végére heti TRIM esetén ez valójában mit jelent. -
Petya XT
senior tag
válasz
ubyegon2
#104330
üzenetére
Úgy tűnt fel, hogy manuálisan szerettem volna lefuttatni, miután kipucoltam az APT-ot, meg szemetet biztonsági mentés előtt. Csak az jött vissza, hogy /mnt/Archívum meghajtóm nem támogatja a discard funkciót, ami egy HDD, így érthető. Az SSD-hez meg sem próbált hozzányúlni, pedig a / kapcsolóval az EFI-t és a rendszerpartición is le kellett volna futnia. Ott gyanús lett, hogy itt valami nem jó.
-
válasz
Petya XT
#104328
üzenetére
Ezek a mai FSTAB-ok tényleg nem raknak már be különböző opciókat, anno volt amelyikban a default opció volt, de egyes disztrók a discard-ot is berakták. Szerintem egyelőre ne variálj azok az Intenso SSD-n, az a biztos!
No de hogyan tűnt fel neked, hogy nem megy a TRIM?
Még régen ilyenre szerkesztettem az FSTAB-ot, de ma már rá se nézek: ez épp egy 2016-ban telepített Mint Rosa Cinnamon disztró, de mindben ugyanez az FSTAB volt
ubyegon@ubymint-rosa ~ $ cat /etc/fstab# /etc/fstab: static file system information.## Use 'blkid' to print the universally unique identifier for a# device; this may be used with UUID= as a more robust way to name devices# that works even if disks are added and removed. See fstab(5).## <file system> <mount point> <type> <options> <dump> <pass># / was on /dev/sda1 during installationUUID=94b359d7-74f2-4adf-ae6e-77dfc652d5cd / ext4 discard,noatime,errors=remount-ro 0 1# swap was on /dev/sdb7 during installationUUID=efb3da91-6ce9-4955-b6e4-1ef0cf1fe220 none swap sw 0 0UUID=929741bd-5267-468e-bac2-673258cf3a99 /media/TORRENTEK ext4 noatime,nosuid,nodev,nofail 0 2UUID=0b26696b-8d0d-4432-8595-9f2d49145952 /media/Data noatime,nosuid,nodev,nofail 0 2#tmpfs to .cachetmpfs /home/ubyegon/.cache tmpfs noatime,nodev,nosuid,size=400M 0 0# Modification for SSDtmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0#tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0#tmpfs /var/spool tmpfs defaults,noatime,mode=1777 0 0tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0 -
#104329
growler
őstag
fekete.puma
#104325
growler
őstag
válasz
fekete.puma
#104325
üzenetére
A jobb/érthetőbb/testre-szabottabb válaszért érdemes lehet az
AI-nak feltett kérdéseinket "finomhangolni" [link] -
Petya XT
senior tag
-
#104327
ubyegon2
félisten
fekete.puma
#104325
válasz
fekete.puma
#104325
üzenetére
Ez az AI válasz használhatóbbnak tűnik!
Nyilván akkor érvényesek ezek a megállapítások, ha relatíve kevés hely van a meghajtón ill emellett kevés az overprovisioning is! Egyébként home usernek bőven elég a beállított ütemezett TRIM is a default heti ütemezéssel, de ezt is át lehet állítani napi lefutásra, ha szükséges.Az a kérdés is felmerült anno, hogy lehet-e discard beállítva és emellett aktív ütemezett TRIM is. Persze, max ha valaki hétfőn nulla órakor épp TRIM-melteti discard-dal az SSD-t, addig nem indul el az ütemezett fstrim.
-
#104326
ubyegon2
félisten
fekete.puma
#104321
válasz
fekete.puma
#104321
üzenetére
Folyamatos trim-nek discard esetén mi a hátránya?
Amit growler írt, csak annyit mutat, hogy az AI valóban összeszedett régi valós infókat, de normál használat esetén nincs hátrány. Említi a Samsung SSD-ket az AI, ami ezeréve valóban érintette a Samsung SSD-k néhány tipusát és még jó pár más SSD-t is. Itt az volt a gond, hogy a vezérlő sorbaállított TRIM használatakor azonnal hajtotta végre a parancsot vagy nem megfelelően priorított, így nagy és folyamatos I/O műveleteknél belassulást okozhatott a TRIM, de ezek a műveletek mondjuk videóvágás, szerkesztés és ehhez hasonló műveletek.
Anno az SSD blacklist felsorolta az érintett SSD-ket a ibata-core.c fájlban, de ebben a SSD blogban is szóba került ez a téma, ami már 10 éve íródott, ebből is látszik, hogy elég régi téma ez.
Ez a téma tökéletes bizonyítéka az AI válasz használhatóságára egyébként. Gyakorlatilag teljesen félrevezeti az egyszerű usert.
Az nem igaz, hogy az SSD ettől belassulhat, legfeljebb az adott nagy terheléssel járó I/O művelet alatt, az adatvesztés is akkor lehet érvényes, egyébként nem.
Ahogy látom, azért a biztonság kedvéért a devices that don't properly handle queued TRIM command alá felsorolnak újabb Sata Samsung eszközöket is. De ezt is leírják egyébként:
As defined, the DRAT (Deterministic Read After Trim) and RZAT * (Return Zero After Trim) flags in the ATA Command Set are * unreliable in the sense that they only define what happens if * the device successfully executed the DSM TRIM command. TRIM * is only advisory, however, and the device is free to silently * ignore all or parts of the request. * * Whitelist drives that are known to reliably return zeroes * after TRIM.Egyszóval, aki ezt a topikot olvassa, nyugodtan használhatja FSTAB-ba szerkesztve a
discardparancsot. -
-
#104324
growler
őstag
fekete.puma
#104321
growler
őstag
válasz
fekete.puma
#104321
üzenetére
A perplexity.ai szerint még ez is:
"A folyamatos TRIM (discard) használatának SSD-n több hátránya lehet:
Teljesítménycsökkenés, lassulás: Ha a TRIM parancsot azonnal, folyamatosan végrehajtja a rendszer (discard opció), akkor egyszerre sok TRIM művelet fut le, ami I/O lassulásokat okozhat. Ez főleg akkor jelentkezik, ha a TRIM műveletek a fájlműveletekkel egy időben történnek, mivel a meghajtó nem tudja optimálisan ütemezni a törléseket, így az SSD lassabbá válhat
.
Fokozottabb elhasználódás: Az azonnali TRIM végrehajtás miatt az SSD vezérlője nem tudja hatékonyan összevonni és optimalizálni a törlési műveleteket, ami több írási ciklust és így gyorsabb kopást eredményezhet. Ez a folyamatos discard használata esetén a meghajtó élettartamának csökkenéséhez vezethet
.
Adatvesztési kockázat bizonyos SSD-ken: Egyes Samsung SSD-k esetében a discard opció használata adatvesztést okozhat, ezért a kernel kikényszeríti az azonnali TRIM végrehajtást, ami tovább rontja a teljesítményt és az élettartamot."
. -
#104323
growler
őstag
fekete.puma
#104321
growler
őstag
válasz
fekete.puma
#104321
üzenetére
"Folyamatos trim-nek discard esetén mi a hátránya?"
Az adat-visszaállítás lehetőségét elfelejtheted. -
#104322
fekete.puma
tag
fekete.puma
tag
Ránéztem a sajátomra előző és a mostani.
/ ext4 defaults 0 1/ ext4 errors=remount-ro 0 1Amennyi Linux annyi féle.
-
válasz
Petya XT
#104318
üzenetére
Ezeket akkor láttad gondolom, mert csak a -v az kevés! Valami cél kell neki, vagy a / vagy -a, --all, etc.
Az viszont érdekes, ha nem volt engedélyezve az fstrim.service. Default heti ütemezésű.
Egyelőre hagyd úgy, ahogy az előbb mutatta a kimeneted és az abban jelzett nap után megnézzük, lefutott-e. Intenso lévén kicsit azért bizakodni is kell, hogy működjön addig.
-
Petya XT
senior tag
válasz
ubyegon2
#104316
üzenetére
Manuálisan futtattam, és nem ment.
sudo fstrim -v. Most sem vagyok biztos benne, bár manuálisan már le bírtam futtatni. De valami nem klappol, ez tény. A systemd fstrim.timer az nem volt engedélyezve. Játszottam a discard-dal az fstabban, de végül azt is kivettem. Most egyáltalán nem tudom, hogy oké lesz e.
-
Petya XT
senior tag
válasz
growler
#104314
üzenetére
sima SATA, ránéztem az fstrim.timer-re, nem is volt aktív...valamiért. Ilyet sem csinált még....
Most elméletileg rendben van.
● fstrim.timer - Discard unused filesystem blocks once a weekLoaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: enabled)Active: active (waiting) since Wed 2025-06-11 18:51:23 CEST; 2min 39s agoTrigger: Mon 2025-06-16 01:05:05 CEST; 4 days leftTriggers: ● fstrim.serviceDocs: man:fstrimjún 11 18:51:23 LNMI22D9020XT systemd[1]: Started fstrim.timer - Discard unused filesystem blocks once a week.~ -
CPT.Pirk
Jómunkásember
válasz
Rowon
#104310
üzenetére
Pls srácok, erre van az https://prohardver.hu/tema/linux_felhasznalok_off_topikja/friss.html
Linux felhasználók offtopicja, használjátok. Dobjatok egy linket rá, ha új téma van aztán biztosan megyünk oda is beszélgetni róla.
-
Arra nem emlékszem!
Tegnap is ki lehetett még állítva? Munkahelyi teendők miatt tegnap fél 2-re tudtam csak odaérni. A három monitoroson játszottam durván egy percet, mert a pixelmennyiség, az irányítás, meg a perifériás látómezőben forgó pálya valahogy összezavarta a szürkeállományomat. WASD + egér irányítás már nagyon be van nálam égve. -
Warton
őstag
válasz
mcwolf79
#104275
üzenetére
Mivel játszom, nálam 3 disztró jött számításba: Nobara, CachyOS és PikaOS.
Ilyen nincs, mindegyik disztro képes játékra, én Manjaros és linuxMintes gépet használok játékra, amik azért elég alap disztrónak számítanak."Tudom,hogy most jön majd az "úgyis user error"szöveg, de lehet köpködni a Windows-t, meg hogy kémkedik,meg fos, de ez legalább működik."
User error, sajnos a nemtudást bünteti a linux, ez van. Valószínűleg nem az OS-sel van baj. Valami nem jól van beállítva, vagy elállítódott, hiányzik valami csomag stb.
Amúgy magamra ismertem, én is így gondolkodtam pár éve, de nem szabad feladni, nyomni kell, aztán egy idő után a windows lesz furcsa.
-
Jó napot!
Volt-e valaki az idei BRSZK-n? Volt ám ilyen gép is!
-
#104301
hcl
titán
tordaitibi
#104298
válasz
tordaitibi
#104298
üzenetére
Az egy másik dimenzió
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Marad a szöszölés...
Látható, hogy a 4db Seagate-en az égvilágon semmit nem lát, eddig ugyanaz, mint a parted. Vakon van. De hát miért is látna 
Dettó. Lehet particionálni, akármi.
brühühü...mi lehet a baj??? Rohaggyonmegabót átbasztak!!!! Juj gyerünk az SSD topikba!
Új hozzászólás Aktív témák
A topik célja: Segítségnyújtás a Linux disztribúciókkal még csak ismerkedők számára. A szerveres kérdések nem ebbe a topicba tartoznak.
Kérdés előtt olvasd el a topik összefoglalóját!
Haladó Linuxos kérdések topikja.
Linux felhasználók OFF topikja
Milyen program ami... [link]
Shell script kérdésekkel látogassatok el a topikjába
- Vélemény Ubuntu 20.04 LTS
- Vélemény Linux Mint Debian Edition 4
- Tudástár MX-Linux 19
- Bemutató Linux a mindennapokban: Manjaro KDE
- Bemutató Linux a mindennapokban
- Hír Zöld utat adott a nyílt forráskódú Linux meghajtóknak az NVIDIA
- Hír A Steam Play hozza el a Windowsra írt játékokat Linuxra
- Hír Hova jut a világ? Linuxot kínál a Windows Store!
- Bomba ár! Dell Latitude E7250 - i7-5GEN I 8GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
- Csere-Beszámítás!AMD Asztali számítógép PC Játékra! R5 5600/ RX 6700XT 12GB / 16GB DDR4 / 500GB SSD
- Telefon felvásárlás!! Apple Watch Series 6/Apple Watch Series 7/Apple Watch Series 8
- AZONNALI SZÁLLÍTÁSSAL Eladó Windows 8 / 8.1 Pro
- 125 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 9 7945HX, RTX 4070
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged