rr7r schreef op donderdag 25 oktober 2012 @ 10:12:
Het verrast mij eigenlijk wel wat CiPHER zegt over bad sectors, hoewel ik hem/haar zonder meer geloof gezien z'n deskundigheid en mijn gebrek er aan. De enige momenten met 1> TB schijven met minimaal 2000 bedrijfsuren dat ik bad sectors had was na bijv. stroomuitval of een fysieke klap. Ik schrijf een schijf met bad sectors eigenlijk altijd direct af, ook gezien het prestatieverlies dat je veelal ook ziet bij een dergelijke schijf.
Prestatieverlies is vrijwel nihil. Het zijn dan een paar sectoren die wanneer sequentiëel ingelezen worden die ene 'bad sector' op een andere plek staat en de schijf dus één seek extra moet doen. Dat ga je echt niet merken tenzij je schijf vol zit met bad sectors. Bedenk dat een 2TB schijf al zo'n 4 miljard tot 500 miljoen sectoren heeft, afhankelijk van de sectorsize (512B of 4KiB).
Wat jij vertelt over een oorzaak die leidt tot bad sectors; is de klassieke bad sector die we allemaal kennen. dit zijn sectoren die ook wanneer ze worden overschreven met nieuwe data, die vervolgens niet meer kunnen uitlezen. Dit kan zijn omdat dat plekje beschadigd is of al was vanuit de fabriek en in dit geval tast dit de betrouwbaarheid van de rest van de schijf niet aan en is het gewoon een goed functionerende schijf.
Echter, het kan ook zijn dat er bijvoorbeeld stofdeeltjes zijn vrijgekomen in de luchtarme behuizing van de hardeschijf en dat deze met de sneldraaiende mechanische onderdelen voor extra schade zorgen en dus kan voorkomen dat je continu nieuwe schade aan het maken bent. Zo'n schijf moet je natuurlijk afschrijven die is fysiek defect.
Wat veel onbekender is, is een 'bad sector' die enkel onleesbaar is omdat er onvoldoende ECC bitcorrectie aanwezig is. Voor 512 byte sectoren is er slechts 50 bytes beschikbaar (bovenop de 512 bytes) voor ECC bitcorrectie. Voor 4K sectoren is er 100 bytes beschikbaar en wordt deze verdeeld over de sector in plaats van alle ECC aan het einde van de sector te plaatsen. In mijn ogen kiezen de hardeschijffabrikanten er telkens voor om nét genoeg ECC te gebruiken, maar eigenlijk is meer zeker wenselijk.
Wat heeft ECC nu te maken met bad sectors? Tegenwoordig, heel veel.
Een hardeschijf kan eigenlijk niet meer lezen wat het heeft opgeslagen. Er zitten heel veel bitfouten in. De hardeschijf moet dus vertrouwen op ECC om zijn eigen data correct terug te kunnen lezen. Daar begint het gelazer natuurlijk al, want aangezien de datadichtheid blijft toenemen maar de ECC bitcorrectie gelijk blijft, wordt de kans dat een sector meer bitfouten heeft dan corrigeerbaar is, steeds groter. Kortom: te weinig ECC betekent een grotere kans op een sector die wel kan worden uitgelezen, maar de gegevens falen de ECC check. Om die reden wilden bedrijven ook schijven met een grotere sectorsize, zoals 520 bytes ipv 512 bytes. Die 8 extra bytes worden dan als 'application-level' ECC gebruikt. Best wel vieze hack maar het geeft aan dat het gewoon een probleem is.
Dit type bad sector komt steeds vaker voor bij moderne schijven met hoge datadichtheid (2TB+ schijven zeg maar). Dit kenmerkt zich doordat de sector zelf fysiek prima in orde is. Zodra je hem overschrijft, is het probleem opgelost. In tegenstelling tot een 'echte' bad sector, wordt deze sector niet omgewisseld met een reservesector. Je ziet in de SMART output dus wel Current Pending Sector op 1 staan bijvoorbeeld, maar Reallocated Sector Count is en blijft 0 - ook wanneer je de bad sector overschrijft. In dat geval verdwijnt de Pending Sector gewoon en is elk 'bewijs' vernietigt in de SMART logs alsof het nooit gebeurd is.
Half jaar terug een systeem voor familielid gemaakt met WD EARX schijven. Na een maand hadden de helft van de schijven pending sectoren. Echter, deze bevonden zich allemaal buiten de plekken die het ZFS bestandssysteem in gebruik had. Omdat die plekken sinds uit de fabriek geweest te zijn nog niet zijn overschreven, zijn ze al zoveel gedegradeerd dat voor een tiental sectoren het aantal bitfouten hoger is dan de ECC bitcorrectie kan corrigeren. Dan worden het dus bad sectors zonder fysiek beschadigd te zijn.
En nu dat 'ratelen'. Dat is normaal! Althans, als andere schijven van dat exacte type (inclusief firmware) dat óók doen. Zo heb ik sinds kort nieuwe Seagate 7200.14 3TB schijven die direct nadat ik ze van stroom had voorzien flink aan background scanning gingen doen. 7,3 watt stroomverbruik in 'idle'; nou die was dus niet idle dat kun je goed horen en ook voelen. Dat is wat de schijf aan background surface scans doet juist om 'weak sectors' op te sporen en opnieuw te schrijven. Zo verkomt de schijf dat die sectoren een tijd later in bad sectors veranderen, maar dit is natuurlijk niet waterdicht. Hetzelfde doe je eigenlijk al normaliter omdat als je de hardeschijf gebruikt je ook die sectoren leest en als de schijf merkt dat die sector niet lekker is (waarvoor het meerdere methoden gebruikt) dan kan het besluiten die uit voorzorg om te wisselen.
Het kan wel zijn dat de schijf van de topicstarter een afwijkend geluid geeft, wat althans andere modellen van hetzelfde type niet hebben. In dat geval zou ik hem wel willen omwisselen, alhoewel schijven anders kunnen gaan klinken. Bij mijn oudere schijven (ik heb er een boel) kun je goed horen dat de ene anders klinkt dan de andere vooral qua seekgeluiden. Bij een nieuwe verse schijf zou ik dit niet zo snel verwachten.
Windows met een NTFS bestandssysteem kan daar toch helemaal niet mee omgaan?
Windows loopt ook erg achter met filesystems. Bedenk dat Microsoft al eerder heeft geprobeerd bitcorrectie toe te voegen om te beschermen tegen bad sectors met Drive Extender 2.0; die uiteindelijk gecancelled werd. Dit betreft Windows Home Server. Het is natuurlijk pijnlijk dat je als topsoftwarebedrijf ter wereld geen software in huis hebt om computerdata veilig op te slaan op moderne opslagmedia. Wha?
Pas nu is Microsoft er met ReFS wat voorlopig nog heftig in ontwikkeling is volgens mij, maar uiteindelijk zullen ook de consumenten hiervan gebruik kunnen maken. Hetzelfde gebeurde eerder met NTFS waarbij alleen Windows NT (het is dus ook NT FileSystem) beschikte over dit nieuwe filesystem, en consumenten tot Windows XP moesten wachten (Win2000 was zakelijk) totdat ook zij hun ouderwetse FAT filesystem konden inruilen voor een destijds modern Journaling filesystem. Destijds was het probleem dat FAT inconsistent kan worden als de hardeschijf plots zijn stroom verliest. Dat zag je dus ook: Win95,98 en ME kon je tijdens het opstarten vaak die scandisk tegen en dat skipten dan veel mensen en dan kreeg je directories met enge japanse tekens enzo... leuk.
Maar hetzelfde gebeurt nu dus weer. Een filesystem mag niet aannemen dat alle sectoren altijd opvraagbaar zijn. Een opslagapparaat is niet langer iets wat OF alle data toegankelijk heeft OF helemaal niets en dus stuk. Steeds vaker doen schijven het prima maar door hun inherente eigenschappen van weinig bitcorrectie en toch erg hoge datadichtheid dat af en toe een sector onleesbaar kan worden. Je filesystem moet dat kunnen hebben! Sterker nog, NTFS en FAT en alle andere legacy filesystems..
weten geeneens of data corrupt is of niet. Die disk checks kunnen zien dat bepaalde metadata in elk geval niet met elkaar overeenkomt. Maar dat blijft gerommel en gewoon geen veilig systeem. Je moet iets hebben wat WEET of de data klopt of niet, en zo niet moet het een redundante bron hebben voor die data. Dat betekent dus: checksums.
Ergo: de noodzaak voor ZFS, Btrfs of ReFS wordt steeds groter en eigenlijk is dit iets wat bepaalde sectoren liever stil willen houden, in elk geval totdat ze hun zaakjes op orde hebben en zelf een goed functionerende oplossing hebben. Echter, ZFS is er nu al, en is gewoon volwassen en stabiel en superbruikbaar. Dat is hét voordeel van ZFS; het eerst volwassen next-gen filesystem wat wél goed werkt met moderne hardware. Vandaar dat ik ook in mijn signature sloth heb gequote:
Je wil in 2012 gewoon een filesystem als ZFS als je data je lief is.
.
:strip_icc():strip_exif()/u/91995/th_flcl.jpg?f=community)