Een heel FS kwijtraken met ZFS is dan ook heel moeilijk. Omdat ZFS
nooit actieve data overschrijft kun je eigenlijk bijna altijd terug naar de situatie waarin je zat voordat er iets mis ging. "Gewoon" de vorige uberblock opzoeken die actief maken in plaats van de huidige, waar dus iets mis mee is gegaan.
fsck kan in veel gevallen het filesystem weer consistent maken omdat ext2 ontworpen is met bitrot in gedachten en ext3 en ook ext4 erven die on-disk structuur. In 1990-1999 kwamen badblocks nog meer voor dan nu en dat zie je in het ontwerp van ext2 heel erg sterg terug met 8 of meer backup superblocks.
ZFS heeft 128 uberblocks.
Leuk dat ZFS ontworpen is om on-disk altijd consistent te zijn maar hoe willen ze dat doen? verborgen raid5 draaien?
Nee, door dus nooit actieve data te overschrijven. Ze schrijven je data naar een andere plek, en verwijzen daar dan naar. Dit is ook hoe snapshots werken: op dat moment wordt de 'oude' data gewoon niet aangemerkt als 'oud', en dus is een snapshot maken dus performancetechnisch zelfs sneller dan geen snapshot maken. (Uiteraard helpt 't niet in de hoeveelheid vrij storage).
zoals ik al zei houd een HDD geen log bij en met checksums verifieer je alleen dat er iets mis is. Het kwaad is dan al geschied en mijn ZFS buurman is dan zijn storage pools aan het nakijken welke HDD die moet bestellen en op welke schijf nou die error werkelijk zit terwijl ik een spare in mijn server druk en mijn raid5 herbouw terwijl mijn andere raid5 en raid0 gewoon doordraaien alsof er niks is gebeurd.
Bijna. Met de checksums alleen kun je inderdaad je data niet reconstrueren, maar alleen constateren dat de data kapot is. En daarom is 't dus zo mooi dat de checksums bij ZFS in het FS (cq de Volume Manager) verwerkt zitten. In het geval van single-disk ZFS is, bij bitrot, inderdaad nog steeds je data kapot. (Maar in dat geval pretendeert 't ook niets te beschermen natuurlijk). In het geval van een RAID 1 (die dus door de ZFS volume manager gedaan wordt) kan aan de hand van die checksum gecontroleerd worden of de data die net van disk is gelezen nog klopt. Zo niet kan de data van de andere disk gehaald worden. De kans dat twee disks op dezelfde plek bitrot vertonen is vrij klein. De andere disk kan nu gehealed worden.
Bij RAID-Z met meerdere disks kan een soortgelijk truukje uitgehaald worden. Doordat ZFS weet wat de data zou moeten zijn (adhv die checksum) kan, als blijkt dat er ergens bitrot is ontstaan, de data gereconstrueerd worden aan de hand van de resterende data. Dat is in dat geval een kwestie van 'stel dat disk 1 kapot was, klopt dit dan met de checksum? Nee. Ok stel disk 2, ...' etc. Een 'normale' RAID 5 kan dat helemaal niet eens detecteren, en bij een rebuild van je array in deze situatie zul je complete onzin naar disk schrijven omdat de parity niet klopt met de data.
Overigens geeft ZFS ook netjes aan welke disks errors hebben gehad:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| [marco@helene ~]$ zpool status
pool: rpool
state: ONLINE
scrub: scrub completed after 0h9m with 0 errors on Sat Oct 31 01:32:36 2009
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s0 ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0
errors: No known data errors |
Zolang jij dus weet welke disk waar zit trek je 'm er zo uit.
Ik ben misschien wat traditioneel maar ik houd mijn fysieke storage, en filesystems liever gescheiden. Ik geef toe dat het idee van storagepools zoals ZFS het doet geweldig is en zeker nut heeft maar in mijn geval is de complexiteit en mischien ook wel het all-in-one principe gewoon overkill.
Maar 't is juist die geintegreerdheid waardoor ZFS kan doen wat 't doet.
Als je tientallen tot duizenden schijfen beheert in een grote NAS array over verschillende servers is ZFS echt een verademing maar voor een enkele server is de simpele m-n mapping die LVM biedt meer als voldoende.
LVM is juist heel onhandig. Snapshots zijn wmb een van de belangrijkste features van Volume Managers, en dat is in LVM heel slecht gedaan imo. Je moet een snapshot een maximumgrootte geven, en als die grootte (in termen van verschil met de live-data) overschreden wordt gaat 't over de zeik. Zoals ik al zei, in ZFS is een snapshot bijna gewoon een kwestie van de oude data niet aanmerken als oud. LVM snapshots zijn eigenlijk alleen bruikbaar om een point-in-time backup te maken, en daarna de snapshot onmiddelijk weer weg te gooien. ZFS snapshots kun je zo lang laten bestaan als je wilt.
Dus raid=backup? Zoals ik ook hierboven al opmerkte moet de hoeveelheid error-correction info dan toch flink oplopen. Met een simpele checksum zoals md5 of CRC32 kun je alleen fouten opsporen om ze dan ook werkelijk te kunnen repareren heb je met een 2 disk set gewoon domweg 50% error-checking info nodig om 1 disk-fail te kunnen overleven. Dat is gewoon een raid1. En hoewel de hoeveelheid info afneemt tot 12,5% bij een 8 disk raid5 neemt ook de kans dat een disk crashed toe waardoor je weer je error-correction info zelf moet gaan error-checken zoals met raid6 wordt gedaan. Kortom ook die buurman zal data kwijt zijn met ZFS
Dus nee helaas ook op dit punt is ZFS niks meer dan software-raid waar ik niks op tegen heb maar ZFS kan geen wonderen verrichten en is beperkt tot dezelfde wiskunde van error-correction info.
Nee, RAID is geen backup. Als die hele doos in de fik vliegt kan ZFS ook je data niet meer restoren natuurlijk. Maar ZFS doet wel self-healing van je data, zoals ik boven al uitlegde, omdat 't gewoon meer weet. Het gebruikt, om je data te restoren, dus parity (of een mirror, voor de restore) én checksums (voor de constatering dat data gerestored moet worden).
Zoals ik zelf ook al zei is de instabiliteit van ZFS onder Linux aan de algemene instabiliteit van FUSE te danken. Had SUN ZFS onder een GPLv2 compatible licence uitgegeven dan had diezelfde ZFS code zo copy-paste in de Linux kernel gekunt en was het vast zeer stabiel geweest net zoals onder (open)Solaris.
Eens. Ik weet alleen niet wie ik moet beschuldigen hierin. Linux omdat ze GPL gekozen hebben, GNU omdat de GPL zo anal is of Sun omdat ze CDDL gekozen hebben.
Kortom: Ook met ZFS heb je nog steeds een backup server nodig en dan zijn simpele md5 hashes voldoende.
ZFS hasht zelfs met SHA256 als je dat wilt, en de uberblock is altijd SHA256 omdat die zo belangrijk is.
[
Voor 5% gewijzigd door
CyBeR op 05-04-2010 21:52
]
All my posts are provided as-is. They come with NO WARRANTY at all.
:strip_icc():strip_exif()/u/147640/van_hitomi_small_1_noborder.jpg?f=community)
). Een gewone fsck loopt even het journaal na, brengt veranderingen aan en is klaar.
/u/34216/avatar-60x60.png?f=community){kind=avatar}
/u/8/oog3.png?f=community)
Mischien leuk voor laptop gebruikers maar op de desktop en server is dat vragen om data-verlies en dat was ook precies wat er gebeurde. En ja ik weet wie het was, onze Tso die nu leuk verwacht dat alle programma's maar sync's gaan doen. Nee dankje, ik pak wel ext3 die heeft zich teminste bewezen. Ext4 pak ik wel met Debian Squeeze.:strip_icc():strip_exif()/u/4167/bacall8.jpg?f=community)
:strip_icc():strip_exif()/u/46486/RayBan.jpg?f=community)
:strip_icc():strip_exif()/u/141741/crop5dd6aa7923c3f_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/267901/crop65df6ef259fc8.jpg?f=community)
/u/1176/crop635f8931b2b68_cropped.png?f=community)
:strip_icc():strip_exif()/u/79614/Family-Guy-Victory-is-Ours.jpg?f=community)
:strip_exif()/u/77058/tick.gif?f=community)
:strip_icc():strip_exif()/u/27686/got.jpg?f=community)
