Új hozzászólás Aktív témák

• Frawly veterán

  #5213

  #5212 BoB

  2018-05-11 16:43:13

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Frawly

  veterán

  #5212 BoB

  #5212 BoB

  Nem megy a queued trim mert a kernelben le van tiltva, ahogy a legutóbbi hosszabb írásomban írtam, de látom hasztalan volt

  Mégegyszer: a discard nem a queued trim-et állítja be, hanem alapvetően a trim-et, ha a meghajtó tudja azt akkor azt. Ugyanaz mint az fstrim csak folyamatosan megy.

  Szerk. Vargalex éppen megelőzött

  Ilyen értelemben nem ugyanaz. Igazából ugyanazt mondjuk, csak a kifejezéseket használtam pontatlanul.

  Ha nagyon a mélyére nézünk, TRIM-ből csak egy van. Ezt lehet kétféleképpen is kettébontani, attól függően, hogy milyen időbeli beosztásban van végrehajtva.

  Az egyik a folyamatos TRIM (discard) a másik az időszakos (fstrim). Ez a felbontás Windows alatt is él, a Windows kernel (Win7 és attól felfelé) folyamatos TRIM-et alkalmaz (menet közben TRIM-el, mikor valami törlésre kerül, azzal együtt a TRIM parancsot is kiküldi), míg egy-két SSD-gyártónak és defrag progit fejlesztő szoftvercégnek van időszakos TRIM-es megoldása (ami viszont megy XP-n, Vistán is, ha a meghajtó és a driver tudja a TRIM-et).

  Egy másik bontásban meg van a queued TRIM (a kiküldött TRIM parancsok későbbre ütemezve, kötegelve futnak) és a sima TRIM, aminek egyrészt ilyen terminológia miatt a felülete nem göcsörtös, és a TRIM parancsok valós időben hajtódnak végre, nem ütemeződnek kötegelt végrehajtásra.

  Ezeket párokat keresztben is lehet párosítani, négyféle kombinációban. Kivéve, ha nem megy a queued TRIM, mert a kernelben tiltva van. Igazából még mindig áll, amit mondtam. A discard TRIM-et nem tanácsos használni feketelistás meghajtókon, mert nem kötegelve futnak, hanem azonnal hajtódnak végre valós időben egyenként, és ettől belassulhat a meghajtó. fstrim-nél ez mindegy, ahogy írtátok, „kevésbé zavaró”.

  Egyébként meg azt a mai napig nem sikerült megfejtenem, hogy az fstrim első futtatásra miért végez sokára, akkor is, ha trimmelt meghajtón fut. A 2-3., stb. futásnál már 0 mp. alatt végez. Majd egy reboot, és újra az első futtatásra mintha újra végigtrimmelné az SSD üres szektoraihoz tartozó cellákat.

  Pont a queued TRIM miatt vettem anno Crucial MX300-at. Két fontos szempont volt, tudjon ATA-jelszavazható hardveres AES öntitkosítást a meghajtó, és ne legyen feketelistán a meghajtó queued TRIM ügyében. A Samsung 840, 850 emiatt esett ki, öntitkosítást tud, de a queued TRIM tiltva van. Kiderült, hogy felesleges volt aggódni, mert csak fstrim-et használva is normálisan trimelődik a meghajtó, és nem baj, ha nem használjuk a discard paramétert.

  Igazából pedig a feketelistás meghajtók is tudnák, de firmwarehiba miatt okozna a használata anomáliát, ezért van a kernelben szoftveres úton letiltva. Ami duplán meglepő, hogy az illető SSD-k gyártói nem akarják ez ellen a firmware-t patchelni. Tudom, a Linux marginális platform, 0%-os részesedés, a kutya nem használja, mert csak a Windows a tuti. Az néha kísérletezik vele, akinek nincs pénze Mac-re vagy Windows licencre, de előbb-utóbb ők is letörlik, és ChromeOS-t vagy Androidot tesznek fel.

  A másik, amit nem értek, hogy az fstrim miért nem támogat minden fájlrendszert. Olyan egyszerűt pl. mint a különböző altípusú FAT fájlrendszerek. A discard támogatja, az fstrim nem. Így ha valaki ilyen fájlrendszert akar trimmelni, feketelistás meghajtón is használni kell a discard TRIM-et.

Új hozzászólás Aktív témák