SSD bad blocks + EeePC 901 ?

Merevlemezek, vezérlők

Adott egy EeePC 901, van benne egy 4 GB-os és egy 16 GB-os SSD meghajtó. 2-3 hónap után a 16 GB-os SSD meghibásodott, ezt garanciálisan ki is cserélték.

Azóta feltelepítettem erre a 16 GB-os háttértárra egy Debian-t, ext3 fájlrendszerrel. 2 hét sem telt el, most a Grub "Error 25"-tel elszáll. Ha pedig a a badblocks-ot futtatom ezen az új háttértárolón is talál hibát, pedig a garanciális csere után is lefuttattam, és akkor nem talált még semmit.

Én csinálok valamit rosszul? Milyen fájlrendszer való az SSD-re?

Hasonló tapasztalatok a témával kapcsolatban?

  • 3107 megtekintés

( doc | 2009. 01. 26., h – 08:41 )

a naplozo filerendszer nem feltetlenul tesz jot neki...
ha folyamatosan irja a journalt, gyorsan ki fog nyiffanni - ahogy azt lathattad is

A Debian EeePC-hez való telepítője a következő fájlrendszereket ajánlja fel telepítéskor:

  • Ext3 naplózó fájlrendszer
  • Ext2 fájlrendszer
  • ReiserFS naplózó fájlrendszer
  • JFS naplózó fájlrendszer
  • FAT16 fájlrendszer
  • FAT32 fájlrendszer
  • cserehely
  • RAID fizikai kötet

Ezek közül egyik sem igazán jó SSD-re, ha jól sejtem.

Gyorsan megnéztem, mi van a feleségem Eee PC-jén: ext2. Ez nem meglepetés, mert én választottam. Plusz reltime opció. Ez érdekes, mert erről nem tudtam, az Intrepid telepítő csinálta így csendben és okosan. Azt hiszem a reltime ugyanúgy megfelel a célnak, mint a noatime.
--
CCC3

( royal v | 2009. 01. 26., h – 09:02 )

Az elso szerias eee701-ben hibatlanul mukodik a 4GB. Azota kaptam ra arra, hogy a tobbi gepemben is kicserelem a HDD-t SSD-re. Eddig mindig a Transcend 32GB vagy 64GB 2.5" SATA SSD-t hasznaltam es ext3 kerult rajuk, de meghibasodas meg egyikkel sem volt, pedig igen intenziv hasznalatban vannak...

+1

Nekem is elso generacios 701-es 4G SSD-s eee pc-m van. Az eredeti OS csak par percig volt rajta, aztan hamar felkerult ra a gentoo. reiserfs-t hasznalok a belso ssd-n, ezen van a root fs, es meg semmi problema nem volt vele. Vettem hozza plusz egy 16G SDHC kartyat, azon most ext4 van (elotte talan ext3 vagy reiserfs volt, mar nem emlekszem pontosan), /var/tmp, /usr/portage, /usr/src van rajta, meg nehany nagyobb filet azon tarolok, plusz van rajta egy swap particio. Az SDHC kartyaval sincs semmi baj. Napi 8 oraban hasznalom a gepet, ezen dolgozok.
Mindenki szeret azzal ijesztgetni, hogy az ssd csak korlatozott szamu irast bir ki, de ha utannaszamolsz, akkor kiderul, hogy ehhez tobb ev intenziv hasznalat kell.

( nmarci | 2009. 01. 27., k – 07:36 )

Ha valakit érdekel, a meghibásodott meghajtók azonosítója a következő: 


$ hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
	Model Number:       ASUS-PHISON SSD                         
	Serial Number:      SOQ2780090          
	Firmware Revision:  TST2.04P
Standards:
	Supported: 5 4 
	Likely used: 6
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   31522176
	LBA    user addressable sectors:   31522176
	device size with M = 1024*1024:       15391 MBytes
	device size with M = 1000*1000:       16139 MBytes (16 GB)
Capabilities:
	LBA, IORDY(cannot be disabled)
	Standby timer values: spec'd by Vendor, no device specific minimum
	R/W multiple sector transfer: Max = 1	Current = 0
	DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	Power Management feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	CFA feature set
	   *	Mandatory FLUSH_CACHE
Integrity word not set (found 0x0000, expected 0xd8a5)

a másiké pedig: 


$ hdpram -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
	Model Number:       ASUS-PHISON SSD                         
	Serial Number:      soq1482260          
	Firmware Revision:  TST2.04L
Standards:
	Likely used: 4
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	bytes/track: 32256	bytes/sector: 512
	CHS current addressable sectors:   16514064
	LBA    user addressable sectors:   31522176
	device size with M = 1024*1024:       15391 MBytes
	device size with M = 1000*1000:       16139 MBytes (16 GB)
Capabilities:
	LBA, IORDY(may be)(cannot be disabled)
	Buffer size: 1.0kB	bytes avail on r/w long: 4
	Standby timer values: spec'd by Vendor
	R/W multiple sector transfer: Max = 1	Current = 0
	DMA: mdma0 mdma1 mdma2 udma0 *udma1 udma2 udma3 udma4 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns

( _Franko_ v | 2009. 01. 27., k – 11:07 )

Az SSD disk nem folyamatos munkára való... továbbá érdemes egy csomó könyvtárt tmpfs-re tenni (/tmp, /var/run, /var/log, stb), mivel sok olyan hely van, amit gyakran ír az oprendszer. Továbbá az atime és a diratime felesleges, ki kell kapcsolni (noatime és nodirtime), mivel az SSD disk kibír 5-10e írási ciklust, ki lehet számolni, meddig bírja, ha egy fix helyen lévő inode rendszeresen frissül...

Szóval óvatosan az SSD diskekkel... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

MLC: 10-100 ezer írási ciklus
SLC: 100 ezer - 1 millió írási ciklus

Az olcsó cuccok nagy része MLC (Multi Level Cell, egy cella jellemzően 2 bitnyi infomációt tárol), ezek lassabbak SLC (Single Level Cell) társaiknál és tízed annyi írást bírnak ki, de jellemzően kétszeres adatsűrűséggel rendelkeznek.

Namost ha van egy meghajtód, teszem azt 100GB, napi írási mennyiséged mondjuk 1 GB, és el vannak osztva az írások a teljes meghajtón, akkor mennyi ideig bírja egy 100 ezer írási ciklusú élettartammal számolva? 100 nap amígy egyszer végírod és ezt kell beszorozni 100 ezerrel... :D Szóval sok-sok év.
A gond nem itt van. A gond ott van, hogy:
- nincs wear leveling (terhelés elosztás a lemezen).
- részleges wear leveling van (pl. csak a lemez elején, ahol a FAT táblák találhatóak).
- van wear leveling, de úgy sz*r az egész, ahogy van.
- más vezérlőelektronikai gond.
- hibás memóriachip.

Az intel akar bevezetni egy olyan megoldást, hogy nem az írási ciklusok számát adják meg, hanem, hogy mennyi adat írása után megy tönkre, ebből kiszámolhatod, hogy az átlag napi terheléssel hány napig tudod használni.

azt szeretnem hozza tenni, hogy tokeletes wear levelling szerintem nincs, en azt gondolnam mindegyiket ki lehet jatszani blokkok kelloen cseles sorrendben valo irasaval. az mas kerdes, hogy a cseles sorrend eltalalasara jo esetben szinte 0 az esely. akkor lehet tokeletes a wear levelling, ha pl. a 32 gigas ssd-n igazabol 64gb flash van (de legalabbis sokkal tobb), es ebbol mindig csak a 32 gigat enged latni.

- Use the Source Luke ! -

A tökéletes wear leveling akkor lenne, ha laponként nyilván tartaná, hogy hányszor volt írva és elosztaná, aztán, ha egy memórialap elhasználódott, akkor egyszerűen letiltaná, vagyis csökken a meghajtó hasznos mérete. Amúgy az ssd-k pendrive-ok, memóriakártyák tartalékolnak néhány százalékot ilyen célra.
Én úgy gondolom, hogy nem szabadna olyan patternek lennie, ami kijátssza a wear levelinget.
Ha minden jól van megcsinálva, akkor egy MLC SSD-nek is minimum 15-20 év élettartammal kellene rendelkeznie. Ilyen szempontból érdemes megnézni az intel új meghajtóit!

a wear levelling algoritmus ismereteben azert valoszinu lehet ugy irni blokkokat, hogy mindig ugyanazt a fizikai blokkot irja (de legalabbis csak egy kis reszhalmazat az osszes blokknak). jo nem biztos, mert ha valami hardveres veletlenszam generatort is hasznal az algoritmus akkor nehezebb.

- Use the Source Luke ! -

te csinalsz magadbol hulyet (nem eloszor). en utananeztem, es arra jutottam, hogy par tartalek blokkal nem lehet tokeletes wear levellinget csinalni (sok tartalek blokkal meg siman). lehet nagyon jot csinalni, de ha nincs nagyon sok tartalek blokk akkor a modszer ismereteben bizonyara at lehet verni az algoritmust (es igy egyenkent hamar megolni blokkokat). ha ezt meg tudod cafolni, linkeld (vagy ird le) a konkret algoritmust, vagy a cafolatot nagy vonalakban mert erdekelne - ilyet azonban persze nem tudsz, a google 10000 valasza teljesen ertekelhetetlen, mert 99-100% szemet. mondjuk en legalabb reverse engineerelgettem wear levelling algoritmust mp3 lejatszoban (igaz, messze nem fejeztem be, de mas messzebb jutott), igy legalabb valami minimalis sejtesem van a dolgok mukodeserol veled szemben.

tudom trolloknak nem valaszolok, neked sem azert valaszoltam mert barmi ertelme van (erdemi valaszt toled nem varok), hanem mert benned esetleg meg latnek nemi fantaziat, mert meg fiatal vagy - de lehet, hogy naiv vagyok.

szerk: a biztonsag kedveert pontositok. az allitas tehat: ha nincs sok tartalek blokk, akkor 0-nal nagyobb esellyel (hogy az esely pontosan mekkora az wear levelling algoritmustol fugg) tetszoleges szamu blokkot hamar ki lehet nyirni (szerk: hamar=legalabb 1MB/ora - de akar ennek tobbszorosevel is, mivel sok flash chiphez egyszerre nyul a vezerlo - sebesseggel lehetne kb. novelni a badblockokat). ha van sok tartalek blokk (tehat modnjuk megannyi mint a hivatalos kapacitas) akkor ez lehetetlen.

- Use the Source Luke ! -

- részleges wear leveling van (pl. csak a lemez elején, ahol a FAT táblák találhatóak).

Szerintem ez lesz a megoldás. SD kártyáknál figyelhető meg, hogy ez első néhány megabájtot sokkal lassabban lehet csak írni, mint a kártya többi részét. Föltehetőleg ott működik csak a wear-leveling.
Ez egyben azt is jelenti, hogy ha a kártyára 2 FAT partíciót rakunk, akkor a 2. ugyanolyan hamar tönkremegy majd, mint pl. az ext3.

Hm... én a WikiPedia oldalán egy nagyságrenddel kevesebb írási ciklust olvastam legutóbb: "Limited write (erase) cycles: Flash-memory cells will often wear out after 1,000 to 10,000 write cycles for MLC, and up to 100,000 write cycles for SLC", neked mi a forrásod a 10-100e írási ciklusra?

Elméletben igazad van, gyakorlatban láttam már bekapcsolt atime és diratime mellett megdöglött SSD-t. Kevéssé hiszem, hogy az olcsó SSD gyors és hatékony wear leveling megoldással rendelkezik... akkor pedig jóval előbb megdöglik, mint ahogy az várható lenne.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

lehet, hogy elírták a wikipédian :D Most komolyan, a 10.000 a nevetséges kategória egy flash memória chipnél. van olyan, amelyik 10.000.000-t tud, de lehet, hogy van trűkközés.

amúgy szakdolgozatomban kifogásolták azt, hogy a wikipédia nem hivatkozási alap. A memóriachipek adatlapjait kell megnézni, ha abban is 10 és 100 ezer van, akkor rosszul emlékeztem.

http://en.wikipedia.org/wiki/Flash_memory
ez hoz példát egy samsung nand mlc flash memóriachipre, ami csak 5-10 ezret tud... siralmas. valószínűleg alsó kategóriás pendrive-okba pakolnak ilyet, de ennél alacsonyabb értéket nem találtam (bár csak gyorsan végpásztáztam a szememmel), de a többi emlékem stimmel, attól függ, hogy nand vagy nor flash memóriáról beszélünk-e.

Alapvetően a NAND és a NOR a különbség. Találtam egy 2002-es tanulmányt, az ezt írja:
"NOR flash dominates the market in memory capacity ranging between 1 and 16 Mbytes, while NAND flash is used in capacity ranges between 8 to 128 Mbytes. This again stresses the roles of NOR devices as a code-storage media and NAND devices as ideal for data storage--NAND has its strongest market presence in the memory card market (CompactFlash, Secure Digital, PC Cards, and MMC)."

A NAND egy nagyságrenddel kevesebbszer írható, mint a NOR. A kérdés az, hogy a mostani 16-32-64GBájtos SSD tárakban NAND vagy NOR van... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

A kérdés az, hogy a mostani 16-32-64GBájtos SSD tárakban NAND vagy NOR van...

szerintem nand, mert az olcsobb, illetve tudtommal a nor-ban az a poen, hogy bitenkent (vagy byteonkent) cimezheto, nand-nal viszont a legkisebb olvashato egyseg a page (par kbyte) es a legkisebb irhato a blokk (mondjuk 128 page). nor pl. a compactflash kartyakban volt. de mindjart jon valami nagy szakerto (mint pl. replaced) aki elkuld anyamba, anelkul, hogy a kerdeshez erdemi informaciot szolgaltatna.

szerk: na a kep alapjan pl. az eeepc ssd-je biztos, hogy nand flashes (lasd K9LAG08U0A)

- Use the Source Luke ! -

( noss | 2009. 01. 27., k – 17:55 )

Wear levelling
lehet szoftveresen (speciális file-rendszerrel) és sok adathordozónál (memóriakártyák, SSD-k) hárdveresen.
kérdés, h mennyire megbízható egy-egy ilyen megoldás...