Új szerver esetén SSD tesztnek van értelme?

 ( pista_ | 2018. június 6., szerda - 22:05 )

Hi!

Új szerver érkezését követően hagyományos merevlemez esetén badblock-ot szoktam ráengedni, hogy lehetőleg még az elején kiderüljön, ha valamelyik disk-el baj van.
Ma érkezett egy Dell szerver, amiben SSD-k csücsülnek. A kérdés az, hogy van itt értelme a badblock-nak?

Vagy esetleg egyéb programmal kellene ellenőrizni?

Minden észrevételt, javaslatot szívesen fogadok.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A teszt csak az azt kozvetlenul megelozo állapot feltarasara alkalmas, a közvetlenül utána következőre már nem, sőt maga a teszt is siettetheti, vagy kivalthatja a hibás allapotot, ami esetleg nelkule még nem feltétlen következne be.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ez így vagyon. Sajna már láttunk olyat, amit "gyári hibásnak" tituláltak. Ilyenkor azért hálás az ember, hogy azt a közel 1 napot rászánta....

+1

Én úgy szoktam, hogy élesbe állítom, és monitorozom a smart adatokat.
Ha hibát találok, akkor garicsere.
A nagy lemez szám, és a RAID (vagy ceph) miatt egy-két lemez kiesése nem tűnik fel a rendszernek, csak nekem. :)
Általában gari időn belül kijönnek a hibák, és dell (_alapesetben_) vita nélkül küldi a cserét.

---
"A megoldásra kell koncentrálni nem a problémára."

Szerintem van. A teszt miatti max 2-3 write cycle nem szabad hogy élettartamban számítson, egy legalább 3000, de szerverben inkább 30000 ciklusra tervezett SSD-nek. A mai SSD-kben szinte mindig van gyári hibás flash blokk, amit a vezérlő saját belső defect management-je nyilvántart és az LBA mappelésből kihagy. Ideális esetben a kezdeti defect listát a gyári QA teszt során feltöltik. Régen a smart-ban a gyári hibás blokkok száma látszott a gyári új SSD-knél is. Aztán győzött a marketing-osztály és azóta 0-ról indul a defective block count.

A lényeg, hogy ne éles adat alatt derüljön ki, ha a gyári QA esetleg 1-2 hibás blokkot kihagyott. Nehéz persze 100%-os fedést csinálni, a sok reserved flash miatt, illetve - nyilván - használat közben is keletkezhetnek új hibás blokkok, de ez ritka.

Én mondjuk nem badblocks-szal szoktam tesztelni, hanem openssl enc-el valami pszeudorandom streamet előállítok, azzal végig dd-zem, aztán vissza cmp. Trim nélkül ugyanez megismételve 2-3-szor különböző openssl jelszóval, hogy eltérő stream legyen, és a wear levelling a tartalék flash blokkokat is legalább egyszer használatba vegye. Az openssl enc megadott jelszóval pontosan reprodukálható streamet eredményez - az ellenőrzéshez ez kell. Viszont elég random ahhoz, hogy az eredményt ne tudja elcsalni semmiféle tömörítés vagy deduplikáció amit az SSD vezérlője csinálhat.
---
Régóta vágyok én, az androidok mezonkincsére már!

Badblockot végig lehet rajta küldeni, nem árt meg neki, SSD-n úgyis villámgyorsan lefut. Bár SSD-nél inkább a SMART értékeket kell nézni, esetleg lefuttatatni rajta egy SMART öntesztet smartctl-lel. Meg fontos, hogy meggyőződj fdisk-kel vagy cfdiskkel, vagy hasonlóval, hogy a partíciók eltolása rendben legyen (ennek automatán jónak kéne lennie, 2048-cal osztható szektorban kéne alapból kezdődnie a partícióknak) meg hogy menjen a TRIM (vagy discard paraméterrel mountolni, vagy engedélyezni az fstrim systemd service-t). Illetve arra kell még figyelni, hogy a TRIM-et LVM esetén az lvm.conf-ban is engedélyezni kell, meg akkor is, ha dmcrypt-et használsz majd az SSD-ken (utóbbit nem érdemes helyette inkább az SSD beépített hardveres öntitkosítását ajánlott használni).


No keyboard detected... Press F1 to run the SETUP

Nincs semmilyen okból. A raid tömb inicializálása pont ezt teszi amúgy is és minden ssd és hdd alaposan tesztelt.

Ezt elvégzik helyetted a gyárban, és kiolvasható a SMART adatokból, része a minőségbiztosításnak.

felesleges, még hdd esetében is