[linux] Re: hardware advies gevraagd

Paul Slootman paul+nospam op wurtel.net
Wo Sep 13 21:36:10 CEST 2006


On Wed 13 Sep 2006, Hans van der Made wrote:

> > Sowieso wat een verhaaltje van Microsoft voor waarde heeft in een linux
> > omgeving vind ik op z'n minst wat twijfelachtig.
> 
> Het verhaal ging over pc-hardware, iets waar ook Microsoft(-klanten) mee
> te maken hebben. Denk je dat Microsoft niets zinnigs te melden heeft op
> dit vlak? Ze hebben (server-)klantjes zat met storage-wensen...

Ja, met typische windows access patterns. Het is niet voor niets dat
windows in een virtual machine op linux sneller draait dan windows
native op dezelfde hardware; linux is nou eenmaal slimmer met disken...

Ik heb toch maar gekeken wat ze te melden hadden... Na 7 minuten klikken
door die presentatie _eindelijk_ op de pagina waar je het over had:

On Tue 12 Sep 2006, nllgg op ukemi.com wrote:
> 
> > 2) storage. liefst via deze linux server. 2x 12x 250GB is zo'n 6 TB, 
> > maar dat zal wel groeien naar zo'n 10 TB en dan moet het maar genoeg zijn.
> 
> Hoewel ik onvoldoende kritisch heb gekeken om er wat zinnigs over te zeggen,
> leek onderstaande presentatie argumenten aan te dragen tegen het gebruik van
> grote (nearline) SATA-disken in RAID5. Iets met een bepaalde Unrecoverable
> Error Rate en de kans dat je daar last van krijgt:

- The UER for SATA products is 1 in 10^14 bits read

Even snel omgerekend betekent dat dat na het lezen van 10TB vanaf SATA
disken je (gemiddeld) een zo'n unrecoverable error zou krijgen. Da's dus
na elke 20 x een 500GB disk helemaal lezen. Mag ik dat heel erg in
twijfel trekken?  Op de door mij eerder genoemde storage bak met 24 x
400GB SATA die momenteel een uptime van 20 dagen heeft, zegt
/proc/diskstats dat 3390705872 sectors gelezen zijn (a 512 bytes). Da's
al ongeveer 1/7de van die 10^14 bits. Hiervoor had ie een uptime van een
kleine 300 dagen, met dezelfde load. Da's 15 x zo lang. Dan zou die al 2
x een UER gehad moeten hebben. En nee, er waren geen errors geweest die
door de raid stiekem gefixt waren, dat wordt gemonitored.
(Terzijde: WD RE SATA disken hebben een spec van < 1 in 10^15,
hetzelfde wat de presentatie claimt voor SAS, zie
http://wdc.com/en/library/sata/2879-701176.pdf)

Ze zeggen ook zelf:

...
- This means there is a 20% probability of an Unrecoverable Error during
  the rebuild. [bij 5x500GB disken]

Overigens zit daar ook een schreeuwende fout in: voor een raid5 rebuild
met 5 disken hoeft er niet 5 x 500GB gelezen te worden, maar 4 x 500GB
lezen en 1 x 500GB schrijven. Vrij "basic" kennis... wat klopt er dan
nog meer niet aan het verhaal, vraag ik mij.

Daarna gaan ze praten over non-standaard sector sizes; blijkbaar willen
ze daarmee buiten de disk firmware om checks gaan doen. Nu hebben
verschillende disken en -fabrikanten al verschillende _hardware_ sector
sizes, juist hierom. Daarnaast is het echt de vraag of je in PC-hardware
iets kan vinden die non-standaard sector sizes ondersteunt, als je
tenminste niet tig duizend euro voor je storage subsystem wilt
neertellen. Da's allemaal leuk voor "echte" enterprise storage, maar
voor een beetje "normale" server met < 50TB ofzo niet relevant.
Wat die geneuzel over hoe te bepalen welke LBA sector nou stuk is kan ik
ook niet echt plaatsen, moest er blijkbaar technisch uit zien.
(Op werk is er ook een NAS van IBM, de DS4100 die SATA gebruikt...
Dus _niet_ SAS. Die is _stukken_ trager dan de storage bak met 24 disken
:-)

Dus je argument "Het verhaal ging over pc-hardware" gaat niet echt op,
want de presentatie is juist een aanbeveling om enterprise storage te
gebruiken met SAS disken, maar desnoods kan SATA ook wel mits je RAID1
of RAID6 gebruikt, yadayada.

Daarbij wordt voorbij gegaan aan de features die linux MD tegenwoordig
kent, zoals write intent bitmaps en check van de RAID set. De write
intent bitmaps geven aan, na een evt. crash / stroomstoring, welke
sectors geupdate zijn, zodat bij een 5 x 500GB raid5 maar een minimiem
gedeelte gesynct hoeft te worden. Online checks (of scrubbing, zo je
wilt) leest alle data (dus van _alle_ disken) en controleert (a) of
alles wel te lezen is, en (b) of de parity block nog klopt.
Niks zo vervelend als het vervangen van een disk uit een RIAD5 set en
dan pas erachter komen dat een paar sectors op een van de andere disken,
die al jaren niet meer gelezen is (denk aan een file als /etc/protocols
:-), ook niet te lezen is; je resync is dan mislukt...  Indien een read
error plaatsvindt, dan zal (bij een recente kernel) de data berekenen en
een write van de bad sector doen, waardoor de disk kans krijgt om of de
sector gewoon te fixen (wat meestal gebeurt), of de sector te vervangen
door een spare.
Geval (b) is meer tegen ongedetecteerde data corruptie. Of ik dat ooit
tegen zal komen... (afkloppen)


Dus mijn vermoedens zijn bevestigd, het verhaal voegt weinig toe (en
heeft wel een kwartier van mijn leven gekost die ik niet meer terug
krijg :)


Paul Slootman



More information about the Linux mailing list