Hirdetés

  2. Fórumok
  3. OS, alkalmazások
  4. Arch Linux
Keresés
  • Téma összefoglaló
    Utoljára frissítve: 2019-02-28 11:06

    Mobilarena

    Arch Linux topik

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

  • #5162 BoB Topikgazda Frawly #5159
    Új Válasz #5162
    Ú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
    Privát üzenet küldése

    BoB

    Topikgazda

    válasz Frawly #5159 üzenetére

    "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.

  • #5161 #63718632 törölt tag Frawly #5159
    Új Válasz #5161
    Ú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

    #63718632

    törölt tag

    válasz Frawly #5159 üzenetére

    A trimmelés systemd státuszát hogyan tudom lekérdezni? Vagy be sincs kapcsolva default?

  • #5160 ubyegon2 félisten Frawly #5159
    Új Válasz #5160
    Ú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
    Privát üzenet küldése

    ubyegon2

    félisten

    válasz Frawly #5159 üzenetére

    Volt valami gyanúm, mikor láttam, hogy Samuról van szó, ezek szerint benne lenne e 850-es a blacklist-ban?

    Szerintem gyakorlatiasabb heti cron-ba tenni a fstrim-et, mert az ember úgyis elfelejti előbb-utóbb lefuttatni manuálisan.

    Hosszú távú tapasztalatom alapján az fstrim-es megoldás amúgy is hatékonyabb TRIM, mint a discard-os.

    Hogy mi van? Te látóasszony vagy esetleg más különleges képességed volna? :D Rögvest kieszem az SSD-t ebből a halott laptopból, ha ezt élő ember meg tudja állapítani, hatékonyabb a ló*szt, ha mégis, az csak véletlen és ezt gondolod, de ez a tapasztalat dolog még nekem is erős volt, pedig szoktam nagyokat mondani néha. ;]

    KDE plasma6-ost már fogod használni? :)

    Mondjuk ki nyíltan, hogy az online trim, amit a vezérlő irányít az oprendszer utasításainak megfelelően, jóval hatékonyabb, mint egy adott időben végrehajtásra kerülő kényszerített trim.

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