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