Használok SSD-ket storage-ban és azt figyeltem meg, hogy .... kell őket meghibásodás miatt cserélni mint a merevlemezeket.

Hardver

lényegesen ritkábban
4% (15 szavazat)
ritkábban
5% (17 szavazat)
nagyjából ugyanolyan időközönként (nincs különbség)
6% (23 szavazat)
gyakrabban
3% (11 szavazat)
lényegesen gyakrabban
1% (4 szavazat)
Nem használok SSD-t storage-ban.
68% (252 szavazat)
Egyéb, leírom.
13% (47 szavazat)
Összes szavazat: 369

( mauzi v | 2015. 10. 30., p – 11:07 )

Amikor beletenyereltünk egy-két szériahibás sorozatba, akkor pocsék volt a tapasztalat. Akkor jegeltük a témát kb 1 évre, viszont az azóta beszerzett SSD-kkel semmi bajunk nem volt.

Mostanság Intel DC S3500, S3700-akat használunk. Mennek.
Low-end környezetben Samsung 850 Pro-van. Az is megy, pedig azon nincs supercapacitor, és már láttunk unexpected powerloss-t.

A használati időszak egyébként még nem túl reprezentatív. (2-3 év SSD versus 20+ év HDD)

S3700 eseteben szinte biztos vagyok ebben, de megha igazad is lenne, es teljesen mas fw van pont ezeken is, akkor is marad a kerdes: a firmware hogy befolyasolja azt, hogy a supercap elfolyik, vagy hogy maga a PCB-n lesz fizikai problema? ugyanis ez szokta okozni az SSD-k halalat (termeszetesen a NAND halal is sokszor, de 10DWPD-s driveoknal nem gondolnam, hogy ettol felni kene)

A kérdésed az volt, hogy " mi a kulonbseg az "utcarol" vett Intel S3500/S3700 sorozat, es a HP/EMC/IBM altal rebrandelt kozott" - erre volt válasz. Az elektronikai kialakításban is lehet különbség, ugyanis a megrendelő is beleszólhat abba, hogy melyik PCB verzióra milyen minőségi paraméterekkel rendelkező alkatrészek kerüljenek.

Nem "teljesen más" az a firmware, de biztos, hogy a vendor ID-n kívül is megpiszkálnak ezt-azt bennük. Valószínűleg egyszerűen kényelmesebb az R&D-nek így megoldani jónéhány problémát, mintha a storage processor szoftverében kéne workaroundokat csinálni.
Command timeout-ok és a hibakezelési viselkedés pl majdnem biztos, hogy módosítva van.
Arról nem beszélve, hogy több beszállítótól veszik a diszkeket, egyszerűbb mindenkitől pont ugyanúgy viselkedő firmware-t kérni, mint az SP-ből támogatni a vendorok apró eltéréseit.

De egyébként ilyet észre lehet venni a consumer SSD-knél is. Pl Samsung SSD-k retail és OEM firmware-je különbözik. A smart adatokon rögtön látszik, hogy másmilyenek, teljesítményben is szokott különbség lenni.
---
Régóta vágyok én, az androidok mezonkincsére már!

( junior013 | 2015. 10. 30., p – 11:05 )

Csak most kezdtem használni storage-ban, de eddig még nem kellett másban sem hiba miatt cserélnem (kopp-kopp), úgyhogy ez-irányú tapasztalat még nincs.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

( smalla | 2015. 10. 30., p – 11:45 )

Van két pár tárolónk EMC és 3PAR. Az EMC ben minimális flash van, azokat nem kellet cserélni, pedig cacheként funkcionál. Lassan 5 éves lesz, szóval jól bírja. (Ellenben a HDD-kel, amikből egy kb 2 hetente elpukkant átlagban. 400+ diszkről beszélünk.) Aztán ott a 3PAR, a HPsok azt mondják, hogy az országban jelenleg a legnagyobb - már nem sokáig -, abban még nem kellett diszket (se hdd, se ssd) cserélni, 160db flash diszk van összesen. És lassan nélkül 3 éves lesz a diszkek fele. Én nem tudom mitől függ a meghibásodási ráta, de mindenesetre érdekes.

Meg az MTBF-től. :) Nekem volt 20db 300G-s SCSI diszkes szerverpakkom, kb. akkor halt meg az első, amikor 50k+ óráig jutottak. A diszkre 1M óra MTBF volt megadva, szóval kb stimmelt a halálozás. 400+ diszknél meg hát izé. Ha egy rackben vannak akkor ott van rázkódás bőven, de azért a heti 2 durva.

( Fisher v | 2015. 10. 30., p – 14:14 )

Még nincs elég mintám (se darabra, se időre nézve).

( zeller | 2015. 10. 31., szo – 20:05 )

Intel szerver alaplapnál jött szembe olyan, hogy a RAID-vezérlő szépen kihajította (néhány perc eltéréssel) a négy SSD-t a RAID10-es tömbből - amit nagyon nem lájkoltam anno... Pláne, hogy egy reboot után IP-konzolon simán össze lehetett újra rakni a tömböt azokból az SSD-kből, amit előtte hibásnak jelzett a kontroller (még a fájlrendszert is helyrekalapálta rajta az fsck - igaz, nagyjából fölöslegesen, mert a rajta lévő adatbázis mindenképp mehetett a kukába...)

Úgyhogy nem minden "megdöglött" jelzés valós. (Aztán lett a nem intel SSD-k helyett intel, és azokkal meg nem volt gond ugyanabban a gépben...)

Hasonló tapasztalatom volt Kingston E50-el. 2x haltak el párban ~fél év alatt. Egyik alkalommal az egyikről lehetett adatot visszahozni, másik alkalommal egyikről sem. Igazi élmény volt...

Másodszor már Intel SSD-ket szereltem vissza, azokkal azóta nem volt baj (több, mint fél éve).

Az én esetemben _semmi_ baja nem volt az ssd-nek, csak épp volt valami firmware bug, ami miatt x bájt adat kiírása után hibásnak látta a kontroller az ssd-t, és erről csak reboot-tal lehetett lebeszélni. És ugye a stripe+mirror okán gyakorlatilag egyszerre érték el a diszkek ezt a határértéket - úgy háromhetente... A cseréig kétheti rendszerességgel éjjel kellett egy mysql átborítást csinálni a fürt másik gépére, remélve, hogy nem hullik szét az egész, aztán a passzív node-ot reboot, és utána további reménykedéssel tekinteni a jövőbe, hogy behozza a reboot alatti lemaradását. Általában sikerült - ha nem, akkor hajnalig tartó, kellően odafigyelős recovery következett.

( XMI | 2015. 10. 31., szo – 23:57 )

Kicsit off, mert nem teljesen "storage"-ről van szó, hanem sima IBM blade-ekről, de rendelhető volt hozzájuk egy 50GB-os (SATA) SSD típus (fru-t most hirtelen nem tudnám előbányászni). Ezek úgy hullottak, mint a legyek, sőt talán végül mind elpusztult. Sajnos némelyik a garanciális időn túl, viszont így volt alkalmunk belenézni. A hiba oka minden esetben a supercap volt, ami kifolyt. Egyik esetben konkrétan lyukat mart az alumínium házra. A kondi cseréjével meg lehetett javítani őket, de nem sok értelme volt. Valami nagyon ócska lassú (talán SSTC) kontroller volt benne, a másik érdekesség pedig, hogy az 50GB-os user kapacitáshoz 128GB MLC flash-t építettek bele.
---
Régóta vágyok én, az androidok mezonkincsére már!

Hát azért a flash gyártási költsége annyira nem olcsó, hogy csak úgy ok nélkül utánadobálják a usernek. Ami írsz, annak akkor volna értelme, ha a fejlesztési költség lényegesen meghaladná a gyártási költséget (pl nagyon kis szériát csinálnak). A pendrive/SD kártya tipikusan pont a másik véglet, annyira tömegtermék, hogy megéri akár drága fejlesztés is (pl TLC flash), hogy minden darabon pár centet megspóroljanak.

A pendrive-okban azért lehet lényegesen nagyobb flash a user kapacitásnál, mert konkrétan a gyártási selejtet harvestelik. A hibás blockok letiltása után ennyi marad. Ha egy 32GB-os flashből 2GB-os terméket csináltak, akkor képzelheted milyen szinten lehet selejtes a flash.

Az IBM SSD-ben ennek teljesen más oka van. A kontrollernek mindig kell valamennyi tartalékterület, hogy a flash erase block fragmentációval tudjon valamit kezdeni (és ez ne járjon 256x-os write amplificationnel és ne essen le teljesítmény kb HDD-szintre). A helyzetet rontja, ha nem megy a trim. Illetve nyilván az időközben erasefail/programfail-essé vált blokkokat is kell valahonnan pótolni.
Ha ennek több, mint 60%-os tartalékterület kellett (normális SSD-knél tipikusan 7-13%), az a kontrollerről mond el valamit. Illetve arról is, hogy nem tudták megoldani, hogy a SAS HBA-n átmenjen a trim.
---
Régóta vágyok én, az androidok mezonkincsére már!