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

• Frawly veterán

  #5164

  #5162 BoB

  2018-04-20 08:05:38

  Ú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

  #5162 BoB

  #5162 BoB

  "850-es Samuk a kernelben trim-tiltólistán vannak, így mountoláskor a discard paramétert NEM szabad használni. "

  A discard és az fstrim ugyanazt csinálja. Az a különbség hogy előbbi esetén a trim azonnal végrehajtódik, míg utóbbinál időnként van lefuttatva. Ez miért volt probléma? Azért mert a trim a SATA 3.1-es szabványig csak és kizárólag unqueued volt, ami azt jeletni hogy azonnal végre kellett hajtani és amíg az végbement minden más I/O blokkolva volt. Ezért sok fájl törlése esetén teljesítmény vesztés volt. Ez kiküszöbölhető volt a néha futtatott trim-el. Ez az fstrim.

  Ez miatt bejött a queued trim (amit egyébként a samsung egyes SSD-ihez firmware frissítéssel juttatott el). Setjhető, itt a trim már úgy fut hogy közben nem blokkolj a meghajtót. Ez a Native Command Queueing (NCQ) ATA protokoll kiterjesztéssel működik. Arról van szó tömören, hogy az OS küldözgeti az ATA parancsokat, de a meghajtó dönti el azokat milyen sorrendben hajtja végre.

  NCQ-t akkor használ a kernel, ha a meghajtó azt mondja neki hogy ismeri. A probléma az volt egyes samsung meghajtók esetén, hogy azt mondta tudja közben a valóságban meg nem tudta. Jött a discard/fstrim (tökmindegy), és azzal a hibák. A discard-nál azonnal mert azzal már nem is bootolt a gép, míg ugye fstrim nem folyamatosan megy így nem volt olyan feltűnő. Azonban ha kiadtad konzolban, jött a hiba ugyanúgy.

  Ezért volt hirtelen megoldás ha ilyenkor kiszedték a discard-ot az fstab-ból.

  https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/1449005

  Jelenleg a 4.16-os kernelben bizonyos SSD-k esetén a queued trim van tiltva. Ettől még "hagyományosan", azaz i/o blokkoló módon továbbra is működik a trim, tökmindegy hogy discard vagy fstrim-el:

  /* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Micron_M5[15]0_*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M550*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*MX100*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Samsung SSD 840*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Samsung SSD 850*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "FCCT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },

  https://github.com/torvalds/linux/blob/v4.16/drivers/ata/libata-core.c#L4552

  Egyetlen SSD van, aminél teljesen le van tiltva:
  /* devices that don't properly handle TRIM commands */
{ "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, },

  Nem tudom ez mennyire volt érthető, de összefoglalva:
  Sasmung akármilyen SSD-nél is lehet discard-ot használni, nincs tiltva. Más kérdés hogy ugyanúgy mint eddig, ez mennyire preferált.

  Valóban pontatlanul fejeztem ki magam. Samu 8XX sorozaton is megy a discard TRIM, de mivel a kernel nem alkalmaz queue-t, azért azonnal végrehajtódik, ami teljesítményproblémákhoz vezethet. Ezért nem érdemes használni. Viszont abban igazad lehet, hogy ettől még lehet használni, és érdemes is lehet olyankor, ha pl. FAT32-es partíciót akarsz TRIM-elni, azt jelenleg az fstrim még nem támogatja.

  Az fstrim-ről meg azért gondolom, hogy hatékonyabb, mint a discard TRIM, mert hiába discardol a kernel, lefuttatva az fstrim-et hosszabban végigtrimeli a partíciókat, azaz talál még trimelni valót. Használom mindkettőt MX300-as SSD-n, az nincs a kernelben sem queued TRIM-es tiltólistán.

  Júbájgön: a systemd-s fstrim-szolgáltatás használata könnyebb és felhasználó/kezdőbarátabb, mint cron-ba belebarmolni, ami vagy fog menni, vagy nem.

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