Filsystem till stor partition (5TB+) Ubuntu

XFS är bra val, är det filsystem som jag sätt absolut bäst prestanda på. Positivt är även att det har online defragmentering samt alltid är consistent, dock med nackdelen att man kan tappa data vid plötslig omstart/avbrott. Men du hade ju UPS så det bör vara lugnt. Tyvärr går det inte minska en XFS partition vilket kan ge en del problem om man ångrar sin partitionering.

Värt att nämna om EXT3 är att det går åt en hel del ram (eller swap) vid en fsck, jag har en 8TB array med EXT3 som inte är rolig att köra fsck på. Tar långtid samt behöver ett tiotal GB i swap för att den ens ska köra klart.

Håller på att utvärdera ZFS just nu, får se hur det står sig mot XFS.

Ungefär hur lång tid tar det att göra fsck på din 8TB array ext3?

Jag vågar knappt tänka tanken!

Minns faktiskt inte, längre än man orkar vänta ;O)
Men inte extremt länge någon timme kanske, beror ju på prestanda på maskinen förstås.

Bara nån timme? Så det tog inte flera dagar med din hårdvara?

Mitt instinktiva men helt oefterforskade svar blir: ja, det beror på både mängd data och uppdelningen. Jobbet fsck gör består ju i att verifiera alla pekare till datablock som finns i inode-tabellerna så ju fler block som lagrats på disken desto längre tid tar det.

petabyte, hur många GB har du på din raid?

NakedApe, så det betyder att själva datat inte kontrolleras, bara metadatat kontrolleras av en fsck?

Fsck har ingen möjlighet att skilja på "rätt" eller "fel" data (t.ex. vid flippad bit) eftersom den inte vet vad det rätta egentligen är.

Det enda stora filsystemet idag (så vitt jag vet och som används i stor skala) som har dataintegritetskontroller är ZFS.

Datamängden har betydelse, men inte p.g.a. att den måste checksummas (något som vi redan konstaterat inte görs på ext*) utan på grund av att det är fler inodes/pekare som måste kontrolleras.

Jo, det är faktiskt just dataintegriteten som kontrolleras här, kontrollern läser in data och kontrollerar att CRC stämmer samt vanligtvis skriver tillbaka datablocken. Detta för att undvika ett "vanligt" problem med större RAID-arrayer där man, när en disk kraschar, upptäcker att det uppstått bit-röta i andra block och rebuildprocessen ('resilvering' i ZFS-terminologi) misslyckas eftersom den inte kan återskapa korrekt data.
ZFS sköter detta automatiskt i bakgrunden och är ett av de stora argumenten för ZFS gentemot hårdvaru-RAID.

Har du mer info om det här? Det var ju massa sysadmins som förklarade att fsck, som jag trodde var så säkert, inte alls var säkert med tanke på silent corruption och andra trevligheter. Jag trodde även att HW-raid måste vara det säkraste och det bästa eftersom det är så dyrt och har dedikerad hårdvara, tills sysadmins förklarade att HW-raid inte alls är säkert, med tanke på silent corruption och såna "småproblem". Då undrar jag hur säkert detta är? Var kan man läsa mera?

Normala implementationer av RAID-1/5/6 skriver inga CRC checksummor själva. Dock så har hårddiskar mer eller mindre alltid någon egen form av feldetekering/felkorrigering.

RAID lever på att hårddiskarna själva "klagar" (d.v.s. rapporterar när det blir fel vid läsning, S.M.A.R.T. fel) eller att kontrollern helt enkelt märker att det inte går att läsa.

När man "scrubbar" en vanlig RAID så läser man in blocken från alla diskarna och kollar om de stämmer eller inte, t.ex. att blocken är lika i fallet med RAID-1 eller att pariteten stämmer för RAID-5/6.

Observera att om diskarna i en RAID-1 (med två diskar) eller RAID-5 inte "klagar" men det fortfarande upptäcks ett fel (inte samma data på båda diskarna för RAID-1; pariteten stämmer inte för RAID-5) så kan felet vanligtvis inte heller fixas, då man helt enkelt inte vet vilken/vilka av diskarna som är de "felaktiga".

För vanlig RAID så måste du åtminstonde ha "en disk mer än antalet fel" för att reparera sådana fel.

Dock så är det oerhört sällan att vissa bit-ar flippar på hårddisken och hårddiskens egna checksummor inte hittar dem. Det är mycket troligare att hårddisk-kontrollern eller annat bit-flippar och därmed får kontrollern felaktig data även om datat på den magnetiska skivan "stämmer".

RAIDZ (och ZFS's spegling) har ett teoretiskt sett mycket starkare skydd än vanlig RAID-1/5/6. Några av de vanligaste argumenten för RAIDZ:

- Varje block som läses "garanteras" att vara korrekt. ZFS checksummar alla blocken och vid läsning jämförs checksumman med det beräknade checksumman för blocket i fråga. Stämmer inte checksummorna så läses paritetsblocket in också (osäker på om den annars gör det), och man försöker att avgöra vilken av diskarna som gav den felaktiga datan. Vanlig RAID "garanterar" endast av blocken läses korrekt om den/dem felaktiga länken/länkarna själv/själva "klagar" (i.e. vanligtvis den/dem "trasiga" hårddisken/hårddiskarna). (se nedan)

- ZFS skyddar mycket högre upp i hierarkin. Bit-flippar när datan transporteras från disk-kontrollern till RAM-minnet skyddas inte av vanlig RAID... eller om disk-kontrollern i sig är trasig och flippar bittarna själv. ZFS med RAIDZ garanterar mer eller mindre att "datan i RAM-et som skrevs till diskarna läses tillbaka i RAM-et exakt som det såg ut förut".

- Inga "write-holes" (inte helt relevant för diskussionen kanske).

P.g.a av att en RAIDZ-X med N diskar alltid måste läsa från minst (N - X) diskar (d.v.s. (N - 1) diskar för RAIDZ-1) så stryps antalet IOPS i en RAIDZ array effektivt till detsamma som för endast en enda disk. Vanliga RAID har inte detta "problem" då den endast behöver läsa små block från en enda disk (d.v.s inte läsa heller stripen).

Bra information. Tack.

Upptäckte denna länk som jag vill dela med mig:
http://storagemojo.com/2007/09/19/cerns-data-corruption-resea...

Det verkar som om 1 byte på 3 x 10^7 (1 byte på dvs 30MB) är korrupt, i en undersökning gjord utav CERN. Detta rapporteras i en av länkarna ovan, här är den:
http://indico.cern.ch/getFile.py/access?contribId=3&sessionId...

Men 1 byte fel på 30MB låter lite väl högt. Kan det verkligen stämma??? Så illa kan det väl inte vara???

Jag har inte läst igenom hela artikeln utan endast ögnat igenom den, men det verkar som de aldrig gick in i detalj på vad exakt som gav fel (icke-trivialt att avgöra det).

Att ett par magnetiska-bitar (vi kan tänka oss att det fungera så även om det egentligen inte gör det ) flippar och hårddiskens ECC/CRC inte detekterar felet är ur en teoretisk synvinkel väldigt osannolik, och borde endast hända om det ändå tidigare hade dykt upp andra tecken på att disken börjar bli dålig (d.v.s. att ECC/CRC upptäckte andra bit-flippar tidigare och loggade till S.M.A.R.T.).

1 byte på 30 MB i genomsnitt (observera att det är mycket troligt att en liten mängd diskar/datorer egentligen representerar 99% av felen; kikade som sagt inte nogrannt på undersökningen) låter som om det vore en siffra för "alla sorters fel" tillsammans (d.v.s. dåliga kontrollers, bit-flippar när data transporteras mellan komponenterna, bit-flippar i RAM, etc).

Jag använde uttrycket CRC eftersom jag inte kunde påminna mig den korrekta termen för paritetsdistributionen (slarv/lathet) och menade givetvis bara RAID5/6 och likaså bara fel som kan korrigeras av redundansen. Jag förenklade för att göra klart att "scrub" inte är detsamma som "fsck" och att medan fsck inte kollar integritet så gör en scrub det (ändå verkar det som om saddam lyckades missförstå ).

Att ZFS skydd är mycket mer komplett håller jag också helt med om, det var mer för att belysa en av ZFS många fördelar.

Sedan kan saddam posta hur många länkar som helst till skräckscenarion om bit errors på hårddiskar, jag tar ingen som pratar om disk-korruption utan att köra ECC i sin maskin på allvar.

EDIT: Givetvis har du också rätt i att läsning av korrupt data som inte genererar ett fel från disken är något som traditionell RAID är dåligt rustad att hantera.

Ah, då förstår jag hur du menar. Jag blev lite förvirrad ett tag!

Men som du säger, så verkar ECC vara viktigt. Jag har börjat fundera på det nyligen. Men som jag förstått så är ECC error rates mycket lägre än för diskar, det inträffar mera sällan vilket man kan se om man läser länken jag postade. Det är ett av skälen till att jag inte riktigt brytt mig om ECC RAM. Men om man nu kör ZFS, då kanske det är lika bra att satsa på ECC också, så har man täckt in så mycket som möjligt. Vad säger ni om ECC? Eller... jag skapar en ny tråd om detta, så inte denna tråd spårar ur.