OT: prodlevy při přenosu dat z disku
Pavel Troller
patrol na sinus.cz
Sobota Prosinec 8 08:03:27 CET 2018
Zdravím,
> On Fri, Dec 07, 2018 at 02:17:45PM +0100, Slavomir Skopalik wrote:
> >...
> > Prvnich par dnu vse OK, potom prudky propad vykonu, pak se situace
> > stabilizovala
> >...
>
> Nemám zkušenost s Windows na SSD. Jedu na tom Linux. Ale pokud se vam
> po case propada vykon, tak me napada, ze by nemusel OS vedet o tom, ze
> ma pod sebou SSD, anebo nejakou chybou neposila povely discard na
> uvolnovana mista na SSD. U W10 je to asi nepravdepodobne.
>
> Napr. na Linuxu je nutne pri pripojeni filesystemu, ktery ma pod sebou
> SSD nastavit volbu discard. Pokud neni pod nim primo blokove zarizeni,
> ale LVM, musi se discard zapnout i v LVM, pokud je mezitim jeste
> dm_crypt, musi se i ten instruovat, aby discard propoustel az dolu
> k zarizeni. Proste vsechny vrstvy to musi vedet.
> Jakmile mazu soubor, tak musi probublat discard az do SSD, aby radic
> v SSD vedel, ze misto se uvolnilo a mohl ho vyuzit na optimalizace pri
> wear levelingu na flash.
To je zajímavé. Vy skutečně zapínáte volbu discard při mountu partition
na SSD ? Totiž, viz man 8 fstrim:
Running fstrim frequently, or even using mount -o discard, might
negatively affect the lifetime of poor-quality SSD devices. For
most desktop and server systems a sufficient trimming frequency
is once a week.
Takže já to řeším zápisem v crontab:
# Perform fstrim every sunday morning (at 02:07)
7 2 * * 0 /sbin/fstrim -a
Zdraví Pavel
>
> Pokud by se radic v SSD nedozvedel, co se uvolnuje, bude si nakonec
> myslet, ze je obsazen cely uzivatelsky prostor a na presunovani bloku
> (pri vyrovnavani urovne opotrebeni bloku) by mu zbyl pouze nejaky
> rezervni prostor a muze klesnout vykon. (Prehazuje bloky o kterych si
> mysli, ze jsou obsazene a prepisuje je zbytecne do jinych...)
>
Další informace o konferenci Hw-list