Am acest grup ZFS format din două unități Samsung 870 QVO de 1 TB, pe care le folosesc de aproximativ un an pentru a stoca imagini de la invitați ca ZVOL.În acest timp, am creat/am încurcat cu/am distrus numeroase instanțe VM; acest pool a văzut destul de multă activitate pe disc.
Aseară, în timp ce mă uitam la performanța I/O pe disc pe una dintre VM-urile, mi-am dat seama că nu mai tăiasem niciodată aceste SSD-uri. Neștiind cu adevărat la ce să mă aștept, am oprit VM-urile și am alergat zfs trim pe piscina.
În general, întreaga operațiune a durat 16 ore (!) pentru a fi finalizată. Pentru referință, iată ce gstat -pdo trebuia să spun în acel timp (ieșire tipică, cu valori medii peste 10 secunde):
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d o/s ms/o %ocupat Nume
11 45 0 0 0,0 27 292 84,9 18 8497 114,3 0 82,9 101,0| ada0
12 37 0 0 0,0 26 283 92,1 11 6547 189,1 0 84,2 100,6| ada1
În orice caz, am lăsat-o cu răbdare să meargă până la capăt.
Apoi, azi mai devreme și cu toate VM-urile încă oprite, am decis să rulez zfs trim din nou. Raționamentul meu a fost că, deoarece nu a existat nicio activitate semnificativă pe acel pool de la ultimul TRIM și cu majoritatea blocurilor nealocate presupuse recuperate de controlerul SSD prima dată, ar fi mult mai rapid de data aceasta.
Ei bine, intuiția mea a fost greșită: acest TRIM funcționează acum de aproximativ 5 ore și conform starea zpool -t, este puțin peste 30% gata. Deci, aparent, mă uit la o durată generală de rulare similară (~16 ore, da sau primi).
Este de așteptat acest comportament? Pentru că, dacă este, atunci evident că îmi lipsește ceva despre cum funcționează TRIM.
Note:
- Sunt conștient de deficiențele seriei QVO (bliț MLC pe 4 biți, cantitate notoriu de mică de cache pseudo-SLC), așa că nu mă așteptam la nicio performanță nebună de la început.
- Poate că este ceva în neregulă cu configurarea mea (cablu SATA prost, etc.) dar totuși, asta nu explică de ce sistemul nu pare să beneficieze de rulările TRIM anterioare pe același pool.
