Het grote ZFS topic

[FireDrunk]

Mijn Fibre Channel verhaal is helaas met een domper afgelopen. De developer van FreeBSD die de CAM/CTL laag gemaakt heeft vertelde mij dat de mpt driver nooit geschikt is gemaakt voor CTL. De driver bevat wat vlarden van target code, maar is nooit werkend gekregen. Om dit werkend te krijgen zal er een flinke rewrite van de target code moeten gebeuren in de mpt driver...

Dus tot zo ver mijn FC avontuur

[]Byte[]

Hoe zit het dan met de (vermeende) 'success-stories' met de isp driver?
Of mis ik hier de spijker?
* ]Byte[ zal er binnenkort eens echt tijd in steken zodra die beschikbaar is...

Als ik hier kijk, lijken ze het werkend te hebben.
Verschil is alleen dat ik een Qlogic 2432 (4 Gb) HBA heb en hun een 2532 (8 Gb) gebruiken.

* ]Byte[ duikt vanavond eerst eens een glaskabeltje op...

[ Voor 44% gewijzigd door ]Byte[ op 17-12-2013 11:12 ]

[FireDrunk]

Qlogic schijnt echt de enige te zijn die hun target support goed op orde hebben op BSD... Dat was ook wat de CTL Developer zelf zei: Snelste oplossing, koop een setje Qlogic adapters

[]Byte[]

FireDrunk schreef op dinsdag 17 december 2013 @ 11:38:
Qlogic schijnt echt de enige te zijn die hun target support goed op orde hebben op BSD... Dat was ook wat de CTL Developer zelf zei: Snelste oplossing, koop een setje Qlogic adapters

Dan is er dus nog hoop voor mij!

[FireDrunk]

Hij had het wel over de 8Gb varianten, geen idee of het drivermodel nog steeds werkt op de 4Gb adapaters.
Heb het hem gevraagd, want nu denk ik erover om een paar Qlogics te kopen.

Wil toch echt wel graag FC op ZVOL's hebben

[Panzy]

Ik houd dit topic nu al enige tijd in de gaten en heb ondertussen veel gelezen over ZFS. Ik ben een server aan het bouwen en twijfel erover om ZFS te gaan draaien. Ik moet zeggen dat vooral het auto-checksummen van alle data mij aanspreekt, waardoor je dus bevestigt kan krijgen dat de integriteit in orde is. Wat ik mij nu afvraag is, hoe vaak komt het bij diegenen die ZFS draaien in de praktijk nu voor dat er fouten gevonden/gerepareerd worden, tijdens gewoon gebruik en tijdens scrubs?

Wat ik tegen heb op ZFS is dat het zo'n groot allesomvattend systeem is. Een simpele disk met een normaal filesystem druk je gewoon in een ander systeem als het nodig is. Ook dat het niet goed supported is onder Linux vind ik lastig. Is er geen goede manier om checksumming op normale filesystems zoals ext3/4 te gebruiken? Dat zie ik dan in combinatie met hardware RAID en een backup als ideale oplossing.

[FireDrunk]

Support onder Linux is prima, je kan je disk zo uit BSD prikken en in Linux gebruiken en andersom.

Checksumming op een filesystem met een onderliggende RAID engine is nutteloos.

De RAID engine overschrijft namelijk keihard je checksum data als het denkt dat dat nodig is. Waardoor het hele checksumming gedeelte nutteloos word.

[]Byte[]

Panzy schreef op dinsdag 17 december 2013 @ 12:26:
[...]
Ik ben een server aan het bouwen en twijfel erover om ZFS te gaan draaien.

Niet twijfelen... Gewoon DOEN!
Wij slepen je er wel doorheen.

[SparC-EHV]

Niet twijfelen... Gewoon DOEN!
Wij slepen je er wel doorheen.

[Panzy]

FireDrunk schreef op dinsdag 17 december 2013 @ 12:29:
Support onder Linux is prima, je kan je disk zo uit BSD prikken en in Linux gebruiken en andersom.

Checksumming op een filesystem met een onderliggende RAID engine is nutteloos.

De RAID engine overschrijft namelijk keihard je checksum data als het denkt dat dat nodig is. Waardoor het hele checksumming gedeelte nutteloos word.

Ok dus het werkt goed op Linux, dat is al weer een voordeel.

Hoezo kom je erbij dat checksumming op een RAID array nutteloos is? Het filesystem (Ext3/4) weet zelf niet dat het op een RAID array staat, als het dan zelf automatisch checksums kan opslaan van blocks wanneer deze worden opgeslagen, en deze checksums ook kan controlleren wanneer de blocks uitgelezen worden (zoals ZFS) zie ik niet hoe een RAID controller hier invloed op heeft, aangezien deze als het goed is niks veranderd aan de data op de array. Dit zou moeten werken als je bijvoorbeeld met ZFS een vdev in single disk mode op een hardware RAID array zet. Er is dan geen mogelijkheid om de checksum mismatches te corrigeren, (geen redundance) maar wel om te zien welke files (of andere onderdelen van het filesystem) dus fubar zijn.

Zo begrijp ik het tenminste.

En dan vraag ik me nog steeds af hoe vaak jullie bijvoorbeeld tijdens een scrub een corrupted file tegen komen (dus een block met een checksum mismatch) die dan uiteraard gefixed wordt door ZFS.

[]Byte[]

Omdat je dan een checksum hebt op een diskblock waarvan jij niet weet of het garbage is of niet.
Schrijft ie om wat voor reden een garbage block weg, heb jij een checksum op een garbage block en niet op de file!
Bij ZFS wordt een checksum getrokken van de file, die checksum wordt op een ander volume weggeschreven dan waar de file staat. Wordt die file dan met garbage weggeschreven, zal dat bij de read van de file gedetecteerd worden door de checksum en live gerepareerd worden.
(voor zover ik nu de plank niet (ver) misgeslagen heb... )

En dan vraag ik me nog steeds af hoe vaak jullie bijvoorbeeld tijdens een scrub een corrupted file tegen komen (dus een block met een checksum mismatch) die dan uiteraard gefixed wordt door ZFS.

Als altijd alles goed gaat.... Nooit!
Ik weet niet zeker meer of het hier was of niet, maar iemand heeft het ooit in een lab-omgeving een ZFS-head tussen de storage-backend (van Lefthand) en de servers gezet. Na 3 maanden had de scrub toch een (paar) error(s) gedetecteerd.

En dan heb je het niet over el-cheapo storage wat de meeste hier thuis gebruiken.

Dus JA, het kan altijd gebeuren.

[ Voor 35% gewijzigd door ]Byte[ op 17-12-2013 14:53 ]

[]Byte[]

Als ik een ZIL aanmaak en die toeken aan een bestaande pool waar nog geen ZIL op zit, wordt dan automatisch alsnog checksums gemaakt van de bestaande files?

[Mystic Spirit]

Panzy schreef op dinsdag 17 december 2013 @ 13:06:
[...]


Ok dus het werkt goed op Linux, dat is al weer een voordeel.

-KNIP-
En dan vraag ik me nog steeds af hoe vaak jullie bijvoorbeeld tijdens een scrub een corrupted file tegen komen (dus een block met een checksum mismatch) die dan uiteraard gefixed wordt door ZFS.

Ik ben ook nog redelijk nieuw in het hele ZFS verhaal, maar tot nog toe geen corruptie. Ik heb het ook nog maar een maand draaien en 1 scrub gedaan. Ik weet nog niet hoe ik kan zien of er automatisch files zijn gerepareerd Ik heb voor de kerstdagen in de planning om eens verder te kijken en leren, maar omdat mijn setup nog zo nieuw is, verwacht ik eigenlijk nog geen corruptie.

[Panzy]

Het filesystem weet zelf toch in welk filesystem block hij een file heb staan en welke blocks garbage zijn. Hoe de hardware het vervolgens fysiek neerpleurt dat staat hier volgens mij helemaal los van en brengt zijn eigen onafhankelijke problemen met zich mee.

Er zijn filesystems naast ZFS die checksumming hebben (Btrfs, NILFS, ReFS) maar niet zoals ik het zou willen zien, namelijk zoals in ZFS. In ZFS zou het mogelijk moeten zijn om een scan (scrub) uit te voeren en te kunnen zien in welke blocks (en dus welke files) er een bitflip heeft plaatsgevonden. Volgens mij kan dit helaas niet met de andere filesystems, alhoewel er addons zijn voor Ext en verschillende scripts die hetzelfde proberen te doen.

@Mystic Spirit
Zeer bedankt voor je bijdrage, dat is precies wat ik wilde weten. Ik hoop dat meer mensen waaronder ook degenen die het al langer gebruiken hun resultaten kunnen delen hier, waardoor we een inzicht krijgen in hoe vaak er dus dingen (bit rot, silent corruption, UBER, etc) mis gaan op onze fysieke data setups.

[ Voor 18% gewijzigd door Panzy op 17-12-2013 15:15 ]

[]Byte[]

Panzy schreef op dinsdag 17 december 2013 @ 14:52:
[...]Er zijn filesystems naast ZFS die checksumming hebben (Btrfs, NILFS, ReFS) maar niet zoals ik het zou willen zien, namelijk zoals in ZFS.

Dan heb je precies hier DE reden om over te stappen naar ZFS!

[Panzy]

]Byte\[ schreef op dinsdag 17 december 2013 @ 14:58:
[...]

Dan heb je precies hier DE reden om over te stappen naar ZFS!

Het zit er inderdaad wel in dat ik over ga stappen op ZFS, maar dat neemt niet weg dat ik liever een ouderwets simpel filesystem zou gebruiken dat dan wel auto checksumming ondersteunt . Mischien is NILFS het wel, dat ziet er heel interessant uit maar doet geloof ik net niet exact wat ik wil, het komt overall wel meer in de buurt dan ZFS in elk geval.

[FireDrunk]

Het filesystem weet zelf toch in welk filesystem block hij een file heb staan en welke blocks garbage zijn. Hoe de hardware het vervolgens fysiek neerpleurt dat staat hier volgens mij helemaal los van en brengt zijn eigen onafhankelijke problemen met zich mee.

Dat is nou juist het allergrootste verschil met ZFS. ZFS weet *EXACT* waar alles op disk staat en verwacht ook dat het zo blijft zonder dat er iemand anders met zijn tengels aan zit.

Bij hardware RAID worden alle devices samengevoegd tot 1 logisch device, hierdoor weet ZFS niet meer welke *individuele* disks een kopie van de data bevatten.

ZFS is namelijk *ZO* slim dat het als er corruptie plaatsvind, de data van een andere schijf kan trekken en dat ene bitje weer kan resetten met de goede data. Juist omdat ZFS dit kan controleren via zijn checksums.

Als je ZFS op hardware RAID legt, kan ZFS niet meer bij de onderliggende reserve hardeschijven (dit laat de RAID controller niet toe, en bovendien is het onderwater geen ZFS meer...).

Hierdoor kan ZFS dus bij bitrot en/of corruptie geen reserverblocks meer aanspreken om de desbetreffende corruptie op te lossen.

Dat is de grote kracht van RAIDZ op ZFS. Het is zowel een RAID5 implementatie (je kan fysiek falen van een harde schijf opvangen door middel van parity), maar het is meer. Het kan namelijk individuele bitjes en sectoren recoveren van de onderliggende reserver schijven, op het niveau van een filesystem.

Dit is uniek in de enterprise wereld (op btrfs na )

[Durandal]

]Byte\[ schreef op dinsdag 17 december 2013 @ 14:36:Wordt die file dan met garbage weggeschreven, zal dat bij de read van de file gedetecteerd worden door de checksum en live gerepareerd worden.
(voor zover ik nu de plank niet (ver) misgeslagen heb... )

Ja, toch nog een keer terugkomen op het (zgn) automatisch repareren van corrupte data.
Een paar weken terug was er hier op het forum n.a.v. uitspraken van mensen die in de code hadden gekeken sprake van dat dit namelijk niet in ZFS zou zitten, en nu zie ik weer allerlij aannames dat dat wel zou gebeuren. Toch niet onbelangrijk zou ik denken.
Voor de duidelijk graag wat antwoorden van de mensen die het hebben uitgezocht.

1) Als ZFS een corrupt data block ontdekt tijdens het lezen, corrigeert hij dat dan direct en automatisch terug naar disk?
1b) Zowel op BSD en onder Linux?

2) Als ZFS een corrupt metadata block ontdekt tijdens het lezen, corrigeert hij dat dan direct en automatisch terug naar disk?
2b) Zowel op BSD en onder Linux?

(NB: ik heb het dus niet over corrigeren tijdens scrubs, dat zou overal werken)

[FireDrunk]

Durandal schreef op dinsdag 17 december 2013 @ 15:52:
[...]

Ja, toch nog een keer terugkomen op het (zgn) automatisch repareren van corrupte data.
Een paar weken terug was er hier op het forum n.a.v. uitspraken van mensen die in de code hadden gekeken sprake van dat dit namelijk niet in ZFS zou zitten, en nu zie ik weer allerlij aannames dat dat wel zou gebeuren. Toch niet onbelangrijk zou ik denken.
Voor de duidelijk graag wat antwoorden van de mensen die het hebben uitgezocht.

1) Als ZFS een corrupt data block ontdekt tijdens het lezen, corrigeert hij dat dan direct en automatisch terug naar disk?
1b) Zowel op BSD en onder Linux?

2) Als ZFS een corrupt metadata block ontdekt tijdens het lezen, corrigeert hij dat dan direct en automatisch terug naar disk?
2b) Zowel op BSD en onder Linux?

(NB: ik heb het dus niet over corrigeren tijdens scrubs, dat zou overal werken)

1) Ja, mits er redundante kopien aanwezig zijn (door middel van mirrors of RAIDZ(1/2)).
2) Ja, omdat ook de metadata gechecksummed word. Er word dan door middel van de checksum van de data geverifieerd of de checksum van de metadata valide is/was en afhankelijk van welke checksum correct registreert word een van beide gecorigeerd (metadata of data), Zijn beide stuk (metadata checksum klopt niet en data checksum klopt niet EN er zijn niet genoeg dittoblocks, krijg je een kapotte file).
2b) Ja, de Linux implementatie is in dit opzicht niet anders.

Je NB klopt niet helemaal: voorbeeldje:

Je hebt een mirror van 2 schijven. Op 1 van de schijven is bitrot aan de gang op sector X welke dezelfde data bevat als sector X op de tweede schijf.
Op het moment dat ZFS een request vanuit het OS krijgt om deze data te lezen, kiest het willekeurig (of afhankelijk van load) een schijf om de data van te lezen. Kiest ZFS disk 2, zal er niets getecteerd worden, omdat zowel de data als de checksum correct bevonden worden.

Tijdens een scrub werkt dit anders, dan word *ALLE* data van beide schijven gelezen en geverifieerd. In het geval van een mirror zou ZFS de kapotte data dus wel vinden, en corrigeren vanuit de andere schijf.

[ Voor 18% gewijzigd door FireDrunk op 17-12-2013 16:03 ]

[]Byte[]

Durandal schreef op dinsdag 17 december 2013 @ 15:52:
[...]
Een paar weken terug was er hier op het forum n.a.v. uitspraken van mensen die in de code hadden gekeken sprake van dat dit namelijk niet in ZFS zou zitten, en nu zie ik weer allerlij aannames dat dat wel zou gebeuren. Toch niet onbelangrijk zou ik denken.

Misschien dat CiPHER hier nog wel een reactie op kan geven als ie hier is.
Als er dan iemand iets over kan zeggen is hij het wel.

[jadjong]

]Byte\[ schreef op dinsdag 17 december 2013 @ 14:42:
Als ik een ZIL aanmaak en die toeken aan een bestaande pool waar nog geen ZIL op zit, wordt dan automatisch alsnog checksums gemaakt van de bestaande files?

Je hebt altijd een ZIL, het enige wat je kan doen is die van de pool-disk verplaatsen naar een SSD.

[FireDrunk]

En dat noem je een SLOG (Seperate LOG), daar wordt dan de ZIL op geschreven. Dat heeft niets te maken met de checksums, dat mechanisme zit daar een paar laagjes onder. De ZIL bevat sync writes die normaal in een transaction group naar disk geschreven zouden worden.

Tijdens een normale synced write kan je filesystem pas verder gaan als deze synced writes gedaan zijn (omdat de applicatie dat persé wil). Als dit ook nog eens random writes zijn, word dat hele boeltje natuurlijk erg traag en het werkt nogal het transactionele systeem van ZFS tegen (het groeperen van meerdere random writes in grote groepen writes, waardoor alles sequentieel weggeschreven kan worden.)

De synced writes worden dus naar de ZIL geschreven, terwijl de transaction group waar de ZIL in zit nog steeds groeit (en niet naar disk geflushed word). Hierdoor kan je ook al heb je synced writes in de transaction group zitten, toch grote transaction groeps maken die een hoge performance halen door sequentieel te schrijven.

De checksum berekening vind plaats bij het committen van de transaction group. De ZIL is dan allang beschreven. De writes in de ZIL zelf worden voor zover ik weet niet voorzien van een checksum. De ZIL word in principe ook nooit teruggelezen, tenzij er een echte power failure (of kernel panic) geweest is. De writes zitten immers nog gewoon in de transaction group. Alleen bij een power failure krijg je een replay / redo van de ZIL (er worden nieuwe transaction groups gemaakt met de data uit de ZIL en deze worden gecommit naar disk). En op dat moment worden er weer checksums berekend.

De checksum validatie gebeurt bij reads, niet (zomaar) bij writes. In een transaction group kunnen ook reads zitten, en ten tijde van het afhandelen van deze reads word het hele checksum mechanisme doorlopen, en word daarna de data pas teruggeleverd aan de applicatie.

@Jadjong, het is niet eens verplicht om dat naar een SSD te doen, je kan dat zelfs naar een gewone disk doen of beter gezegd, naar elk block device wat beschikbaar is... Of dat verstandig is, is natuurlijk een tweede

Vroegah, kon je dus bijvoorbeeld 6 langzame 5400RPM disks in een RAIDZ2 pool stoppen en daar een 10/15k SAS disk als SLOG naast zetten.... Goedkoper dan een SSD

[ Voor 8% gewijzigd door FireDrunk op 17-12-2013 20:37 ]

[Q]

FireDrunk schreef op dinsdag 17 december 2013 @ 09:06:
Mijn Fibre Channel verhaal is helaas met een domper afgelopen. De developer van FreeBSD die de CAM/CTL laag gemaakt heeft vertelde mij dat de mpt driver nooit geschikt is gemaakt voor CTL. De driver bevat wat vlarden van target code, maar is nooit werkend gekregen. Om dit werkend te krijgen zal er een flinke rewrite van de target code moeten gebeuren in de mpt driver...

Dus tot zo ver mijn FC avontuur

Dat is heel jammer, maar op het gevaar af iets heel onbetamelijken en obvious te suggereren:

Linux? Debian Wheezy?

Hoe is 't met driver support voor dat platform?

////////////////////////////////////

Misschien leuk:

Heb nu 3xM1015 + quad port gigabit in een X9SCM-F en alles lijkt te werken, alle SAS backplanes werken ook. Ik kan nu 24 disks aansluiten.

[ Voor 16% gewijzigd door Q op 18-12-2013 00:22 ]

[Panzy]

FireDrunk schreef op dinsdag 17 december 2013 @ 15:45:
[...]

Dat is nou juist het allergrootste verschil met ZFS. ZFS weet *EXACT* waar alles op disk staat en verwacht ook dat het zo blijft zonder dat er iemand anders met zijn tengels aan zit.

Dit is uniek in de enterprise wereld (op btrfs na )

Ik ben hiervan op de hoogte en realiseer het me, maar bedankt voor je verhaal. Wat ik echter probeer te zeggen, bij een hardware RAID array weet ZFS toch ook exact waar de data staat, namelijk in block x op array 1. Wat maakt het uit of het nou een array of een single disk is, er kan met allebij evenveel mis gaan, namelijk in het ergste geval total loss van de device. Als je dus auto error correction wil hebben moet je redundancy hebbben door middel van een extra disk OF door middel van een volledige extra hardware RAID array (wat natuurlijk omslachtig en belachelijk is in de praktijk, maar even voor de beeldvorming)

Daarom om terug te komen op mijn eerdere post, zie ik als het voor mij ideale systeem, een hardware RAID array met een simpel single disk checksumming filesystem wat hetzelfde doet als ZFS doet wanneer je het op 1 enkele disk zou zetten (zonder copies), namelijk alles checksummen en bij elke read verifieren of de data klopt maar niet corrigeren want dat kan ie dan niet. (Of lul ik nu?)

Op deze manier heb je dus redundancy (hw RAID) en error detection (checksums). Als er dan ooit een error opduikt kan je de betreffende file eenvoudig terughalen uit je backup.

Waarom zo? Omdat het simpel en overzichtelijk is. En voor thuis is dat wel zo handig vind ik.

[ Voor 12% gewijzigd door Panzy op 18-12-2013 01:19 ]

[FireDrunk]

Waarom is dat simpeler dan ZFS de RAID te laten doen? Het is echt sterk af te raden, dus als het geen expliciete voordelen heeft behalve voor jou "overzichtelijk", waarom zou je dan?

@Q, mooie build! Pas wel op met te temperatuur van die kaartjes als ze zo dicht op elkaar zitten, er zijn best wat mensen waarbij die dingen bloedheet worden.

Linux is zeker een optie, ik wil dat ook nog wel een keer proberen. In dat geval word het SCST, daar zou MPT support in zitten. Ik zal zo eens en VM maken en kijken of ik wat drivers kan vinden om het te onderzoeken.

[ Voor 50% gewijzigd door FireDrunk op 18-12-2013 08:20 ]

[]Byte[]

FireDrunk schreef op woensdag 18 december 2013 @ 06:45:
Waarom is dat simpeler dan ZFS de RAID te laten doen? Het is echt sterk af te raden, dus als het geen expliciete voordelen heeft behalve voor jou "overzichtelijk", waarom zou je dan?

Wat is de definitie van "overzichtelijk"??
Naar mijn idee wordt het er maar minder overzichtelijk op. RAID op RAID.... Nah.... niet doen!
Als je dan ooit een probleem krijg weet je straks tenminste helemaal niet meer te vinden wanneer je een probleem hebt.

Wat dat betreft:
KIS - Keep it Simple
KISS - Keep It Stupid Simple

Complexiteit bouwen kan iedereen... Het daarna onderhouden, dat gaat dan de uitdaging worden!

[]Byte[]

L2ARC-vraag:

Ik dacht altijd dat de L2ARC-devices gestriped zouden worden.
Zo heb ik een gpt/l2arc en gpt/l2arc2 partities die op twee verschillende SSD's staan die aan mijn HDD-pool zijn toegewezen.

Als ik met een 'zfs iostat hdd_pool1 5' kijk, schrijft ie om en om tussen de twee partities.

code:

                      capacity     operations    bandwidth
pool               alloc   free   read  write   read  write
-----------------  -----  -----  -----  -----  -----  -----
hdd_pool1          1.02T  35.2T      0     40      0   297K
  raidz2           1.02T  35.2T      0     40      0   297K
    gpt/hdd_dsk_0      -      -      0     12      0  74.4K
    gpt/hdd_dsk_1      -      -      0     11      0  71.2K
    gpt/hdd_dsk_2      -      -      0     11      0  68.0K
    gpt/hdd_dsk_3      -      -      0     10      0  62.4K
    gpt/hdd_dsk_4      -      -      0     11      0  67.2K
    gpt/hdd_dsk_5      -      -      0     11      0  66.4K
    gpt/hdd_dsk_6      -      -      0     11      0  66.4K
    gpt/hdd_dsk_7      -      -      0     10      0  64.0K
    gpt/hdd_dsk_8      -      -      0     12      0  71.2K
    gpt/hdd_dsk_9      -      -      0     11      0  70.4K
logs                   -      -      -      -      -      -
  mirror            424K  3.97G      0      0      0      0
    gpt/slog           -      -      0      0      0      0
    gpt/slog2          -      -      0      0      0      0
cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      1  12.8K  4.90K
  gpt/l2arc2       34.1G  25.9G      0      0      0      0
-----------------  -----  -----  -----  -----  -----  -----

cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      0      0      0
  gpt/l2arc2       34.1G  25.9G      0      0  12.8K  4.90K
-----------------  -----  -----  -----  -----  -----  -----

cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      1      0  5.20K
  gpt/l2arc2       34.1G  25.9G      0      0      0      0
-----------------  -----  -----  -----  -----  -----  -----

cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      0      0      0
  gpt/l2arc2       34.1G  25.9G      0      0  12.8K  5.10K
-----------------  -----  -----  -----  -----  -----  -----

cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      2      0  5.20K
  gpt/l2arc2       34.1G  25.9G      0      0      0      0
-----------------  -----  -----  -----  -----  -----  -----

cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      0      0      0
  gpt/l2arc2       34.1G  25.9G      0      0      0  5.20K
-----------------  -----  -----  -----  -----  -----  -----

cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      2      0  5.40K
  gpt/l2arc2       34.1G  25.9G      0      0      0      0
-----------------  -----  -----  -----  -----  -----  -----

cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      0      0      0
  gpt/l2arc2       34.1G  25.9G      0      0      0  4.90K
-----------------  -----  -----  -----  -----  -----  -----

cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      2      0  4.90K
  gpt/l2arc2       34.1G  25.9G      0      0      0      0
-----------------  -----  -----  -----  -----  -----  -----

cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      0      0      0
  gpt/l2arc2       34.1G  25.9G      0      0      0  5.20K
-----------------  -----  -----  -----  -----  -----  -----

cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      1      0  5.10K
  gpt/l2arc2       34.1G  25.9G      0      0      0      0
-----------------  -----  -----  -----  -----  -----  -----

Als ik dit gedrag bekijk lijkt dit meer op een Round-Robin dan op een striped.

[FireDrunk]

Ik denk dat dit komt omdat je niet tegen de write limiet van de L2ARC aan komt. Standaard is dat 8MB/s ofzo en als je de sysctl vfs.zfs.l2arc_feed_again aan hebt, kan het volgens mij beter gaan.

L2ARC tuning is een lastig verhaal en er zijn een hoop blogposts over.

Kern is: By default word de L2ARC niet met maximale snelheid beschreven, om de SSD's te sparen (als die constant met 500MB/s staan te knallen zijn ze vrij snel door hun maximale write cycles heen).

Dit is wel te tunen, maar dat vergt wel enige inlezen.

[]Byte[]

FireDrunk schreef op woensdag 18 december 2013 @ 10:52:
Dit is wel te tunen, maar dat vergt wel enige inlezen.

Tnx. Ik heb weer wat huiswerk...
Write cycles...? Garantie!
Als ik maar de goede bronnen heb om in te lezen, maakt het mij niet zoveel uit.
Als ik ZFS bij klanten wil implementeren, wil ik gewoon weten hoever ik er mee kan gaan.
Ik zeg altijd: Weet waar de mogelijkheden liggen, maar weet nog beter waar de kwaliteiten eindigen...

* ]Byte[ zit nog te wachten op CHiPER's workshop... [hint]

[update]
Hmmm... Staat zo te zien al goed...

code:

[root@zfsguru ~]# sysctl vfs.zfs.l2arc_feed_again 
vfs.zfs.l2arc_feed_again: 1
[root@zfsguru ~]#

[ Voor 12% gewijzigd door ]Byte[ op 18-12-2013 11:33 ]

[FireDrunk]

[root@NAS ~]# sysctl -a | grep vfs.zfs.l2arc
vfs.zfs.l2arc_write_max: 8388608
vfs.zfs.l2arc_write_boost: 8388608
vfs.zfs.l2arc_headroom: 2
vfs.zfs.l2arc_feed_secs: 1
vfs.zfs.l2arc_feed_min_ms: 200
vfs.zfs.l2arc_noprefetch: 1
vfs.zfs.l2arc_feed_again: 1
vfs.zfs.l2arc_norw: 1

is volgens mij de default, je kan de write en de write boost verhogen, en de headroom ook wat verhogen, dat zal je L2ARC wat sneller vullen. Bedenk wel, je L2ARC word in principe pas gevuld als je ARC vol is.

[]Byte[]

Oke. Die is mij dan duidelijk.
Dat is dat dezelfde 8M waar je het over had. (?)
Daar zit ik met writes van 5 kB tot soms 24 MB op de pieken (ben er nu een paar VM's af aan het moven naar de QNAP's zodat ik ZFSguru kan rebooten...) nog niet echt in de 'probleem-zone'
(alhoewel ik met 24 MB/s al wel over de 8 MB heen ben - maargoed ik weet ook nog niet hoe ik die sysctl -waarden moet interpreteren)

code:

cache                  -      -      -      -      -      -
  gpt/l2arc        34.2G  25.8G      0      1      0  5.10K
  gpt/l2arc2       34.1G  25.9G      0      0      0      0
-----------------  -----  -----  -----  -----  -----  -----

Is die 68 GB in L2ARC een indicatie dat mijn 32 GB al 'vol' zou zitten
* ]Byte[ moet op zoek naar een nieuw MB....

[FireDrunk]

Het is 8MB per seconde aanleveren, dus als jij een transaction group timeout hebt van 5 seconden kan je in die ene transaction wel 40MB aan L2ARC data hebben zitten.

[]Byte[]

FireDrunk schreef op woensdag 18 december 2013 @ 12:43:
Het is 8MB per seconde aanleveren, dus als jij een transaction group timeout hebt van 5 seconden kan je in die ene transaction wel 40MB aan L2ARC data hebben zitten.

Natuurlijk.... Hoe ken ik nu zo....
snurkmomentje...

'zfs-stats' en 'zfs-mon' geven overigens ook een leuke bron aan informatie.

[Q]

FireDrunk schreef op woensdag 18 december 2013 @ 06:45:
@Q, mooie build! Pas wel op met te temperatuur van die kaartjes als ze zo dicht op elkaar zitten, er zijn best wat mensen waarbij die dingen bloedheet worden.

Linux is zeker een optie, ik wil dat ook nog wel een keer proberen. In dat geval word het SCST, daar zou MPT support in zitten. Ik zal zo eens en VM maken en kijken of ik wat drivers kan vinden om het te onderzoeken.

Bedankt, ik had inderdaad opgemerkt dat die kaarten pittig heet worden. Ik heb er toen bij het testen meteen een ventilator boven gemonteerd. Ik hoop dat je misschien met Linux je FC droom kunt verwezenlijken. Ik ga nu zelf voor old-school quad-gigabit in bonding. Ik ben benieuwd in hoeverre dat schaalt.

[ Voor 11% gewijzigd door Q op 18-12-2013 13:37 ]

[Bigs]

]Byte\[ schreef op woensdag 18 december 2013 @ 11:01:
[...]

Write cycles...? Garantie!

[...]

Euh dat zou ik wel even nakijken voordat je gekke dingen gaat doen Ik heb laatst een paar Intel SSD's van IBM aangeschaft en daar zat een extra papier in de doos waar ze nog even wezen op het feit dat de garantie volgens de voorwaarden vervalt als de gespecificeerde write endurance opgebruikt is.

[FireDrunk]

Oppassen daarmee inderdaad...

[]Byte[]

Hmmmm... Goed punt....
Maarja... aan de andere kant...
Dan moet je wel zo belachelijk veel data naar de SSD's pompen wil je daar tegenaan lopen.
Tegen die tijd zijn de SSD's waarschijnlijk ook wel afgeschreven.
Je moet wel extreem veel data schijven wil je binnen de 2 of 3 jaar door de write endurance heen zijn.
En voor zakelijke klanten zou ik denk ik toch sneller naar SLC's kijken.

[update]
leuk artikeltje over write endurance lifetime...

[ Voor 12% gewijzigd door ]Byte[ op 18-12-2013 14:52 ]

[FireDrunk]

Pas op hoor, voor virtual machines gaat het erg hard... Als je structureel 8MB/s schrijft een dag lang, zit je op 675GB... Maal 365 dagen = 240TB per jaar... Dan zit je bij veel SSD's al aan de endurance.

[Bigs]

]Byte\[ schreef op woensdag 18 december 2013 @ 14:41:
Hmmmm... Goed punt....
Maarja... aan de andere kant...
Dan moet je wel zo belachelijk veel data naar de SSD's pompen wil je daar tegenaan lopen.
Tegen die tijd zijn de SSD's waarschijnlijk ook wel afgeschreven.
Je moet wel extreem veel data schijven wil je binnen de 2 of 3 jaar door de write endurance heen zijn.
En voor zakelijke klanten zou ik denk ik toch sneller naar SLC's kijken.

[update]
leuk artikeltje over write endurance lifetime...

Ware het niet dat SLC SSD's nauwelijks meer verkocht worden voor mainstream servers. Een MLC SSD als de Intel DC S3700 is voor de meeste loads al voldoende en anders heb je b.v. de Optimus SAS SSD (ook MLC, 10 volledige random drive writes per dag).

[jacovn]

Q schreef op woensdag 18 december 2013 @ 13:33:
[...]


Bedankt, ik had inderdaad opgemerkt dat die kaarten pittig heet worden. Ik heb er toen bij het testen meteen een ventilator boven gemonteerd. Ik hoop dat je misschien met Linux je FC droom kunt verwezenlijken. Ik ga nu zelf voor old-school quad-gigabit in bonding. Ik ben benieuwd in hoeverre dat schaalt.

Ja zo heet dat fouten optreden zelfs.

Ik heb er een 140 mm fan boven gehangen die relatief langzaam draait en dan gaat het goed.

[]Byte[]

FireDrunk schreef op woensdag 18 december 2013 @ 15:21:
Pas op hoor, voor virtual machines gaat het erg hard... Als je structureel 8MB/s schrijft een dag lang, zit je op 675GB... Maal 365 dagen = 240TB per jaar... Dan zit je bij veel SSD's al aan de endurance.

I get the point.

Dit gaat een mooi monitoringklusje worden voor zabbix. (ik heb de zabbix_agentd al draaien)
Al is het alleen al voor het zien wat er gebeurt om een inschatting te maken op de lange termijn.
Als ik dan toch een ander MB moet hebben, kan ik gelijk ook de Addonics-kaart van FireDrunk er in zetten.
Dan heb ik er 4 in stripe ipv de huidige 2...
Als je dan tegen de write endurance aanloop, ben je zeker de nodige jaren verder.

[Q]

jacovn schreef op woensdag 18 december 2013 @ 15:50:
[...]

Ja zo heet dat fouten optreden zelfs.

Ik heb er een 140 mm fan boven gehangen die relatief langzaam draait en dan gaat het goed.

Same experience. Ik heb in twee servers een highpoint kaart zitten en die koel ik beiden ook met een extra ventilator. Een van de kaarten is er vanwege de hitte ook een keer uitgeklapt (hoop gepiep) en dat kostte me bijna een array. Daarna nooit meer last van gehad.

Wel interessant punt om even uit te zoeken of de M1015 of LSI versie ergens de mogelijkheid biedt om de temperatuur uit te lezen. Volgens mij kan dit niet.

Ik zie eigenlijk ook niet waar en hoe je extra temperatuur sensors kunt kopen die je op bv usb kunt aansluiten.

[ Voor 9% gewijzigd door Q op 18-12-2013 17:36 ]

[Xudonax]

Je krijgt vaak temperatuur sensoren als je een wat "luxere" fancontroller of frontpanel aanschaft, maar niets wat je direct via USB oid kunt uitlezen wat ik weet. Is het trouwens niet handiger om sensoren te kopen die je op de SMBus kunt aansluiten via mPCIe of iets dergelijks? Dan heb je kans dat Linux (of *BSD) ze via ACPI kan inzien en gebruiken lijkt me

[Geckx]

Sinds de update naar 9.2-001 werkt spindown niet meer op mijn M1015.

Reden is dat ik de latest-portstree niet meer kan installeren en dus geen /usr/ports/sysutils/spindown kan ophalen...

Via webconfig heeft het eigenlijk nooit gewerkt, dus op aanraden van C!PHER via putty gedaan, dat lukte prima. Maar in de nieuwe versie dus niet meer..

Ik krijg volgende error:

http://sdrv.ms/19Tl8KG

Ruimte nog meer dan 3,5GB dus dat is het ook niet...

Iemand met hetzelfde probleem of een fix?

[FireDrunk]

Klinkt als een vol filesystem (log bijvoorbeeld) of een quota wat geraakt wordt. Daar al eens naar gekeken?

[Geckx]

Hoe kan ik dat nagaan?

df -h zie ik wel dit:
Maar dit is normaal dacht ik..

code:

devfs                            1.0k    1.0k      0B   100%    /dev

Quota's en dergelijke gebruik ik niet bij mijn weten.

[ Voor 51% gewijzigd door Geckx op 18-12-2013 22:10 ]

[Xudonax]

"hint: use df -h and df -i" staat er in je foutmelding

Kijk even met df -h hoeveel ruimte er nog vrij is op de plek waar je latest-portstree (/usr/ports ?) wilt installeren. Waarschijnlijk moet je kijken naar de beschikbare ruimte op /.

[Geckx]

Daar is 3,6GB vrij

[FireDrunk]

Welk commando gebruik je om de ports tree te downloaden?

[Geckx]

Downloaden is via webconfig, installeren via:

/services/system-portstree-latest/service_install.sh

[ Voor 6% gewijzigd door Geckx op 18-12-2013 22:59 ]

[FireDrunk]

Hmm, dat is niet de laatste portstree, dat is de service... Daar zit je probleem, een gare service (zoals zovelen in zfsguru )

Maar goed, daar kan ik je niet bij helpen...

[ Voor 19% gewijzigd door FireDrunk op 18-12-2013 23:05 ]

[Geckx]

achja, jammer. Misschien toch eens tijd voor een reinstall.

[ Voor 74% gewijzigd door Geckx op 18-12-2013 23:10 ]

[FireDrunk]

_{Geen zfsguru gebruiken...}

[Verwijderd]

Nou zeg.. dat is ook wat overtrokken. Bij andere platforms heb je geeneens een portstree. In 9.2 werkt de system-portstree servive niet; dat is gefixed in 10.0. Ik dacht echter dat de -latest service wel werkte. In de screenshot van Geckx is juist dat bovenste gedeelte weggelaten waar het om draait.Dus dat geeft me niet zoveel aanwijzingen.

Quick fix:
mkdir /usr/ports
portsnap fetch
portsnap extract
cd /usr/ports/sysutils/spindown
make install clean

[Geckx]

Ik zal dat straks eens proberen C!PHER.

Die laatste 2 heb ik wel al gedaan, lukt niet in huidige situatie want hij vindt de directory sysutils niet onder ports.
Misschien als ik ze manueel aanmaak eerst.

Bedankt voor de tip!

[ Voor 10% gewijzigd door Geckx op 19-12-2013 07:20 ]

[FireDrunk]

@CiPHER, het was ook sarcastisch

@ Geckx, Die laatste twee kunnen ook pas als je de portstree gedownload hebt door middel van de eerste twee commando's.

[]Byte[]

Zou het een 'best practice' zijn om je L2ARC disabled te zetten op backup-shares?
Ik heb op mijn ZFS een TimeMachine gemaakt met een quota van 2 TB op mijn hdd_pool. So far so good...
Maar om de write endurance te ontzien dacht ik 'm maar disabled te zetten.

Volgende stap is Dedup... (here goes memory-hungry process....)

[ Voor 11% gewijzigd door ]Byte[ op 19-12-2013 10:44 ]

[FireDrunk]

Dat kan je inderdaad doen, of hem op "Metadata Online" zetten, dan kan je nog lekker snel door de directories browsen.

Dedup zou ik echt niet aanzetten voor systemen waar performance belangrijk is. Alleen voor backup volumes is het inderdaad interresant in mijn ogen. (of je moet echt een monster van een systeem neerzetten.)

[Pantagruel]

Q schreef op woensdag 18 december 2013 @ 17:31:
[...]


Same experience. Ik heb in twee servers een highpoint kaart zitten en die koel ik beiden ook met een extra ventilator. Een van de kaarten is er vanwege de hitte ook een keer uitgeklapt (hoop gepiep) en dat kostte me bijna een array. Daarna nooit meer last van gehad.

Wel interessant punt om even uit te zoeken of de M1015 of LSI versie ergens de mogelijkheid biedt om de temperatuur uit te lezen. Volgens mij kan dit niet.

Ik zie eigenlijk ook niet waar en hoe je extra temperatuur sensors kunt kopen die je op bv usb kunt aansluiten.

Ik kan me niet voor de geest halen dat je de temp van een M1015 uit kon lezen (en of de HBA zelf wel een sensor aan boord heeft). De HBA word idd heet, maar wat je zegt, een goed gericht fan en de problemen zijn verholpen. Mijn M1015's leven onder een 12 cm low cfm fan.

Mbt de USB temp sensor:een blogje mbt 'El-Cheapo' Ebay USB temp sensor gebruik onder linux, of de vlieger voor *bsd op gaat durf ik niet te zeggen.

Misschien bied je moederbord wel een aansluiting aan voor een temp probe (onboard sensor header) en kun je deze op t koellichaam van de HBA bevestigen.

[ Voor 5% gewijzigd door Pantagruel op 19-12-2013 11:06 ]

[]Byte[]

FireDrunk schreef op donderdag 19 december 2013 @ 10:47:
(of je moet echt een monster van een systeem neerzetten.)

Het is een i7 - 3770
Die krijgt het zweet (nog) niet op zijn rug van het werken.

[ Voor 52% gewijzigd door ]Byte[ op 19-12-2013 11:13 ]

[FireDrunk]

Mja, dannog... Dedup kost je 99/100 keer gewoon echt een bak performance...

[]Byte[]

Ik weet het.
Ik heb ervaring de Data Domain's.
Heb er eens een paar bij een klant geïmplementeerd.
Toen ik weg al een paar maanden weg was, was er een beheerder die dacht, "dit ga ik ook maar op de live productie-data en databases zetten"
En hun zich maar afvragen waarom het niet meer vooruit te branden was en een paar keer corrupte databases hadden...
* ]Byte[ dacht alleen "neer knuppelen die gast..."

[FireDrunk]

Corruptie is dan wel weer een beetje jammer

[]Byte[]

Als je je dan bedenkt dat dit een omgeving is met een paar duizend concurrent users...
Dat had dus wel 'enige impact' zullen we maar zeggen.

[ Voor 95% gewijzigd door ]Byte[ op 19-12-2013 11:25 ]

[Panzy]

FireDrunk schreef op woensdag 18 december 2013 @ 06:45:
Waarom is dat simpeler dan ZFS de RAID te laten doen? Het is echt sterk af te raden, dus als het geen expliciete voordelen heeft behalve voor jou "overzichtelijk", waarom zou je dan?

Omdat ZFS nogal complex is en er softwarematig heel wat gebeurt onder de kap wat ik niet zo maar even kan volgen. Beetje de vergelijking van een moderne Audi met allerlei sensoren en geavanceerde controlesystemen wat het neusje van de zalm zou moeten zijn en een 30 jaar oude Toyota. Puntje bij paaltje zal de Audi ondanks alle geavanceerdheid gewoon kapot lopen binnen niet al te lange tijd en voor duizenden euro's reparatie nodig hebben terwijl de Toyota nog steeds vrolijk rondrijdt ergens in Afrika. De vergelijking slaat natuurlijk nergens op maar het is wel het idee wat ik krijg bij ZFS.

Ik sta echt op het punt om ZFS te installeren gewoon puur vanwege het gebrek aan wat anders, maar elke keer komen er weer verhalen zoals hierboven van Byte naar voren over 'corruptie', dat ik denk van waar doe ik het voor.

[matty___]

Panzy schreef op donderdag 19 december 2013 @ 12:01:
[...]


Omdat ZFS nogal complex is en er softwarematig heel wat gebeurt onder de kap wat ik niet zo maar even kan volgen. Beetje de vergelijking van een moderne Audi met allerlei sensoren en geavanceerde controlesystemen wat het neusje van de zalm zou moeten zijn en een 30 jaar oude Toyota. Puntje bij paaltje zal de Audi ondanks alle geavanceerdheid gewoon kapot lopen binnen niet al te lange tijd en voor duizenden euro's reparatie nodig hebben terwijl de Toyota nog steeds vrolijk rondrijdt ergens in Afrika. De vergelijking slaat natuurlijk nergens op maar het is wel het idee wat ik krijg bij ZFS.

Ik sta echt op het punt om ZFS te installeren gewoon puur vanwege het gebrek aan wat anders, maar elke keer komen er weer verhalen zoals hierboven van Byte naar voren over 'corruptie', dat ik denk van waar doe ik het voor.

Dan ga jij het lekker op een raidcontroller zetten en hou ons op de hoogte van je bevindingen

[]Byte[]

Waar je het voor doet?
Juist om het VOORKOMEN van corruptie!
De 'beperkingen' van de HW RAID worden hier door ZFS juist afgevangen.
Het is net als met je brandverzekering.... Je betaald 'm ieder jaar weer, ondanks je 'm (hoop ik) nooit nodig zal hebben.
Om 1 simpele reden. De kosten zijn niet te overzien als je huis om wat voor reden toch afbrand.

[FireDrunk]

Inderdaad, ZFS is geen Audi, het is een Caterpiller mijntruck... Traag in verhouding tot een Audi, maar als je stenen gaat versjouwen durf ik te wedden dat ik er meer per uur verhuis met een Caterpiller dan met een Audi...

Hardware RAID onder ZFS draaien is een beetje als fietsbanden op een Caterpiller leggen.

[Panzy]

Hoe draaien grote data centers? Niet op ZFS meestal maar op Fibre Channel oplossingen van IBM, HP, LSI, etc. SAS heeft zover ik weet altijd een zekere checksum beveiliging wat hardwarematig door het hele SCSI systeem heen geweven zit. Dit werkt gewoon simpel en overzichtelijk en daarom hebben ze waarschijnlijk ook geen ZFS nodig. Dat ze overal een 1:1 backup van hebben geloof ik ook niet want dat zou nooit uitkunnen qua kosten voor een hoop applicaties. Waar of niet waar?

Het is cool om te zien dat ZFS wel steeds meer wordt ingezet maar als je dan ook maar 1 verhaal hoort over data corruptie i.c.m. ZFS dan denk ik toch echt bij mezelf, waar doe je het dan voor want ZFS is juist gemaakt zodanig dat dat absoluut ONMOGELIJK zou moeten zijn, één enkel geval waar het dan toch gebeurt is er gewoon 1 teveel vind ik.

Toch ga ik ZFS draaien, waarschijnlijk in single-disk mode op een hardware RAID5 (omdat ik die heb en omdat het kan). Omdat ZFS dus alle fouten zou moeten kunnen detecteren gaan we exact zien hoeveel er allemaal mis gaat binnen de hardware array. En als er dan dingen mis gaan zien we gelijk in hoeverre ZFS in staat is om toch online te blijven ondanks fouten op het opslagmedium, iets wat voor andere filesystems al bewezen is dat het geen probleem vormt. Ik zorg uiteraard met deze setup wel voor een goede backup.

[ Voor 8% gewijzigd door Panzy op 19-12-2013 12:55 ]

[A1AD]

Panzy schreef op donderdag 19 december 2013 @ 12:50:
Toch ga ik ZFS draaien, waarschijnlijk in single-disk mode op een hardware RAID5 (omdat ik die heb en omdat het kan). Omdat ZFS dus alle fouten zou moeten kunnen detecteren gaan we exact zien hoeveel er allemaal mis gaat binnen de hardware array. Ik zorg uiteraard met deze setup wel voor een goede backup.

ZFS heeft redundantie nodig (RaidZ of mirror) om eventuele fouten te kunnen herstelen...

[Panzy]

A1AD schreef op donderdag 19 december 2013 @ 12:55:
[...]


ZFS heeft redundantie nodig (RaidZ of mirror) om eventuele fouten te kunnen herstelen...

Klopt, daarom kunnen de fouten als het goed is dus ook alleen ontdekt worden. Herstellen moet dan handmatig via een backup. File deleten, file terugplaatsen.

[matty___]

Panzy schreef op donderdag 19 december 2013 @ 12:50:
Hoe draaien grote data centers? Niet op ZFS meestal maar op Fibre Channel oplossingen van IBM, HP, LSI, etc. \

En hadden ze een SUN/Oracle oplossing staan dan was het wel ZFS geweest.

Je gaat bewust kiezen voor het scenario waar IEDEREEN het je afraad inclusief de fabrikant. Je gaat het testen met iets waarvoor het nooit ontworpen is (hoe goed is ZFS op een single disk array op een HW controller)

[ Voor 28% gewijzigd door matty___ op 19-12-2013 13:06 ]

[matty___]

Panzy schreef op donderdag 19 december 2013 @ 12:57:
[...]


Klopt, daarom kunnen de fouten als het goed is dus ook alleen ontdekt worden. Herstellen moet dan handmatig via een backup. File deleten, file terugplaatsen.

De fout wordt altijd herkent alleen kun je het zelfstandig herstellen vergeten

[Panzy]

matty___ schreef op donderdag 19 december 2013 @ 13:07:
[...]

De fout wordt altijd herkent alleen kun je het zelfstandig herstellen vergeten

Waarom kun je dat vergeten?

[matty___]

Panzy schreef op donderdag 19 december 2013 @ 13:12:
[...]


Waarom kun je dat vergeten?

Het herstellen van een block werkt alleen als je een kopie ergens hebt. Dus een vdev in raidz of mirroring.

Anders is het heel het bestand vervangen. Volgens mij krijg je met zpool status wel een overzicht van de bestanden die corrupt zijn.

[Panzy]

Ok dat is prima dan, ik bedoel ook dat ik dan heel het bestand vervang vanaf een backup.

Uiteraard ga ik ervan uit dat mijn o zo perfecte hardware geen fouten kan maken, maar ik ben heel benieuwd wat de praktijk gaat laten zien.

[matty___]

Panzy schreef op donderdag 19 december 2013 @ 13:27:
Ok dat is prima dan, ik bedoel ook dat ik dan heel het bestand vervang vanaf een backup.

Uiteraard ga ik ervan uit dat mijn o zo perfecte hardware geen fouten kan maken, maar ik ben heel benieuwd wat de praktijk gaat laten zien.

Verder is het natuurlijk wel interessant wat er gebeurt als je het array rebuild, het groter dan wel kleiner maakt.

Wellicht dat het auto repair ook werkt als je het aantal copies op 2 zet. Gaat je write snelheid wel naar beneden omdat fysiek 2 keer geschreven wordt maar het scheelt je wel het terug zetten van data

[Panzy]

matty___ schreef op donderdag 19 december 2013 @ 13:29:
[...]

Verder is het natuurlijk wel interessant wat er gebeurt als je het array rebuild, het groter dan wel kleiner maakt.

Wellicht dat het auto repair ook werkt als je het aantal copies op 2 zet. Gaat je write snelheid wel naar beneden omdat fysiek 2 keer geschreven wordt maar het scheelt je wel het terug zetten van data

Copies heb ik over nagedacht maar dat ga ik niet doen, kost me teveel ruimte op mijn dure RE schijven. Ik neem aan dat er niet veel fouten gaan komen, dus dan is het prima handmatig te doen. En als de halve array corrupt raakt of eruit klapt weet ik dat het tijd wordt voor wat anders

Wat er gebeurd bij het rebuilden van de array, als het goed is merkt ZFS alleen dat de snelheid omlaag gaat. Het groter of kleiner maken vraag ik me af hoe ZFS daar op reageert, dat is net alsof opeens een disk van capaciteit veranderd. Je zou dit kunnen testen door een dd image te maken van een disk met ZFS, en vervolgens die image naar een grotere disk te pompen.

Trouwens, werkt ZFS binnen partities op een schijf zoals andere file systems of neemt hij de hele schijf over? In het geval van partities, kun je dan de ZFS partitie resizen?

[ Voor 7% gewijzigd door Panzy op 19-12-2013 13:50 ]

[matty___]

Panzy schreef op donderdag 19 december 2013 @ 13:45:


Trouwens, werkt ZFS binnen partities op een schijf zoals andere file systems of neemt hij de hele schijf over? In het geval van partities, kun je dan de ZFS partitie resizen?

In FreebBSD draait het prima in GPT partities. Het vergroten werkt volgens mij zonder problemen maar het verkleinen heb ik zo mijn bedenkingen.

[syl765]

@Panzy

Hoe draaien grote data centers? Niet op ZFS meestal maar op Fibre Channel oplossingen van IBM, HP, LSI, etc.

Houd er wel rekening mee dat de meeste data centers al een hele infrastuctuur hebben draaien.
Dit zet je niet zo maar even om. Tevens komt ZFS nu pas echt op gang doordat ZFS nu toch wel redelijk volwassen is. Mochten grote datacenters een nieuwe investering moeten doen in nieuwe opslag kan ik mij niet voorstellen dat men ZFS totaal niet meeneemt in een eventuele oplossing.
Of de keuze voor ZFS word gemaakt hangt van veel meer factoren af, zoals management, lopende deals, verhoudingen met huidige hardware leveranciers en je lokale IT afdeling.
Als je de afgelopen jaren flink geinvesteerd hebt in je IT personeel om ze op het nivo van netapp specialist te krijgen, dan zul je toch niet zo gauw voor ZFS gaan kiezen.

Trouwens, werkt ZFS binnen partities op een schijf zoals andere file systems of neemt hij de hele schijf over? In het geval van partities, kun je dan de ZFS partitie resizen?

Over de partities: lees even het volgende stukje.
http://www.freebsddiary.org/zfs-with-gpart.php

Het resizen zou theoretisch wel kunnen denk ik, maar je zal alle partities van je vdev moeten vergroten. Daarna kun je de pool vergroten, of als autoexpand aan staat zal zfs deze ruimte vanzelf zien en de pool uitbreiden.

gr
Johan

[ Voor 23% gewijzigd door syl765 op 19-12-2013 14:06 ]

[]Byte[]

Panzy schreef op donderdag 19 december 2013 @ 12:50:
Hoe draaien grote data centers? Niet op ZFS meestal maar op Fibre Channel oplossingen van IBM, HP, LSI, etc.

ZFS is een filesystem... FC is (net als SATA, SAS, SCSI, IB) de infrastructuur om storage te koppelen aan de servers!

[]Byte[]

matty___ schreef op donderdag 19 december 2013 @ 13:58:
[...]
Het vergroten werkt volgens mij zonder problemen maar het verkleinen heb ik zo mijn bedenkingen.

Euhhhh.... Hoe zeker weet je dat?
Voor zover mij bekend kan je een (ZFS) RAID-array (nog) niet extenden.
Volgens mij zit die support er nog niet in.

[Panzy]

]Byte\[ schreef op donderdag 19 december 2013 @ 14:16:
[...]

ZFS is een filesystem... FC is (net als SATA, SAS, SCSI, IB) de infrastructuur om storage te koppelen aan de servers!

Ja maar bij de FC oplossing van een bepaalde fabrikant hoort toch meestal ook een proprietary file system zoals GPFS bijvoorbeeld

[FireDrunk]

]Byte\[ schreef op donderdag 19 december 2013 @ 14:23:
[...]

Euhhhh.... Hoe zeker weet je dat?
Voor zover mij bekend kan je een (ZFS) RAID-array (nog) niet extenden.
Volgens mij zit die support er nog niet in.

Als de disks groter worden, kan ZFS gewoon de nieuwe ruimte gebruiken. Wat ZFS *niet* kan is een extra disk toevoegen aan een VDEV. (4 disk RAIDZ naar 5 disk RAIDZ).

Panzy schreef op donderdag 19 december 2013 @ 14:25:
[...]


Ja maar bij de FC oplossing van een bepaalde fabrikant hoort toch meestal ook een proprietary file system zoals GPFS bijvoorbeeld

En dat betekend automatisch dat dat filesystem checksumming bevat? Nee dus...

[Panzy]

Nee maar de hardware bevat dan toch al checksumming?

[Durandal]

Panzy schreef op donderdag 19 december 2013 @ 14:56:
Nee maar de hardware bevat dan toch al checksumming?

Waar zouden al die checksums dan moeten worden opgeslagen?

[Panzy]

Durandal schreef op donderdag 19 december 2013 @ 15:32:
[...]

Waar zouden al die checksums dan moeten worden opgeslagen?

Naar wat ik heb begrepen hebben SCSI schijven 520 byte sectoren i.p.v. 512 byte. De hardware slaat daar dan de checksum in op van het data block. Ik heb dit alleen gelezen en claim absoluut niet hier verstand van te hebben, mischien iemand die er meer van weet?

[FireDrunk]

Alle hardeschijven hebben inderdaad low level ECC. Dat helpt lang niet altijd als het gaat om bitrot. Soms vallen er zoveel bitjes om dat de hoeveelheid ECC data gewoonweg niet genoeg is om de data te herstellen.

Op dat moment ben je gewoon die sector kwijt en word er geprobeerd deze sector te herstellen.

In ZFS *ZIET* deze fouten (doordat de highlevel checksum van het hele block niet meer klopt) en gaat proberen deze sector te herstellen met data van een andere schijf of locatie.

Het enige waaraan je dit bij een SCSI schijf zit, is de current pending en de reallocated sector waardes in SMART. Verder NERGENS.

Is de rapportage van Sectoren dus bij SAS net zo goed als bij ZFS? Nee, ZFS ziet veel meer (veel grotere checksums (256byte tegenover 8 byte op een disk).

Is de reparatie van Sectoren bij SAS net zo goed als bij ZFS? Nee, er word alleen maar een individuele sector geprobeerd te repareren, lukt dit niet, pech. ZFS restored de oude data vanaf een redundante kopie.

Ook hardware RAID controllers restoren *GEEN* individuele sectoren, omdat ze *GEEN* inhoudelijk checksum kennis hebben van de disk.

[Q]

Dit is een punt wat wel vaker naar voren is gekomen. Maar ik vraag me toch af hoe de grotere storage vendors het geregeld hebben met het risico van bitrot.

We kennen de risico's van 'reguliere' RAID adapters, maar met SAN oplossingen draait er zo enorm veel shit op zo'n platform, daar kan je dat echt niet hebben. Bitrot in een transactie systeem is dodelijk.

Toch draaien die systemen niet op ZFS. Hoe heeft de wereld ooit kunnen bestaan zonder ZFS? Of zijn de risico's toch niet zo groot? De datasets worden natuurlijk wel veel groter dan 'vroegah' waardoor bitrot risico's bij schijven opeens meer gaan tellen. Maar dan nog...

[]Byte[]

Panzy schreef op donderdag 19 december 2013 @ 14:25:
[...]
Ja maar bij de FC oplossing van een bepaalde fabrikant hoort toch meestal ook een proprietary file system zoals GPFS bijvoorbeeld

Kan... Hoeft niet.
Hangt er vanaf wat voor storage systeem je aanschaft.
Neem nu bijv. HP EVA's, dat is 'niets meer' dan blocklevel storage. Dus leg je daar je eigen filesystem op.
Neem je een NAS-head van bijv. een VMX van EMC.... Die gedraagt zich weer als NAS, en daar ligt hun eigen filesystem op.

[DrFlash]

Q schreef op donderdag 19 december 2013 @ 16:23:
Dit is een punt wat wel vaker naar voren is gekomen. Maar ik vraag me toch af hoe de grotere storage vendors het geregeld hebben met het risico van bitrot.

We kennen de risico's van 'reguliere' RAID adapters, maar met SAN oplossingen draait er zo enorm veel shit op zo'n platform, daar kan je dat echt niet hebben. Bitrot in een transactie systeem is dodelijk.

Toch draaien die systemen niet op ZFS. Hoe heeft de wereld ooit kunnen bestaan zonder ZFS? Of zijn de risico's toch niet zo groot? De datasets worden natuurlijk wel veel groter dan 'vroegah' waardoor bitrot risico's bij schijven opeens meer gaan tellen. Maar dan nog...

ZFS is niet de enige met dit mechanisme, de andere bekendste zijn WAFL (netapp) en btrfs (oracle)

[BCC]

Q schreef op donderdag 19 december 2013 @ 16:23:
Toch draaien die systemen niet op ZFS. Hoe heeft de wereld ooit kunnen bestaan zonder ZFS? Of zijn de risico's toch niet zo groot? De datasets worden natuurlijk wel veel groter dan 'vroegah' waardoor bitrot risico's bij schijven opeens meer gaan tellen. Maar dan nog...

Regelmatige backups naar tape robots.

[FireDrunk]

Het schijnt dat WAFL helemaal geen eigen filesystem is, maar alleen een aantal hacks in bestaande filessystems waardoor ze copy on write doen... (ergens gelezen, geen idee waar...)

https://communities.netap...2/08/is-wafl-a-filesystem

[ Voor 21% gewijzigd door FireDrunk op 19-12-2013 16:44 ]

[Panzy]

Mischien als op een SAN een schijf uberhaupt maar 1 keer een fout geeft dat hij meteen vervangen wordt. De betere SAS error detectie zorgt er waarschijnlijk voor dat ALLE fouten opgemerkt worden en dat het absoluut onmogelijk is dat een schijf incorrecte data terugstuurt naar het netwerk. Er is natuurlijk redundancy en de schijven die gebruikt worden zijn van dusdanig hoge kwaliteit dat de kans op fouten heel erg klein is waardoor je niet constant met schijven aan het jongleren bent. En ze zullen ook wel preventief vervangen worden na een vastgesteld aantal draaiuren.

[Geckx]

Verwijderd schreef op woensdag 18 december 2013 @ 23:28:
Nou zeg.. dat is ook wat overtrokken. Bij andere platforms heb je geeneens een portstree. In 9.2 werkt de system-portstree servive niet; dat is gefixed in 10.0. Ik dacht echter dat de -latest service wel werkte. In de screenshot van Geckx is juist dat bovenste gedeelte weggelaten waar het om draait.Dus dat geeft me niet zoveel aanwijzingen.

Quick fix:
mkdir /usr/ports
portsnap fetch
portsnap extract
cd /usr/ports/sysutils/spindown
make install clean

Dit heeft het gefixed.

Erg bedankt!

[Verwijderd]

Q schreef op donderdag 19 december 2013 @ 16:23:
Dit is een punt wat wel vaker naar voren is gekomen. Maar ik vraag me toch af hoe de grotere storage vendors het geregeld hebben met het risico van bitrot.

Vrij simpel: veel geld ertegenaan smijten. Grofweg kun je twee routes kiezen:

• De 'domme' route, dure hardware met weinig softwarematige intelligentie
• De 'slimme' route, goedkope hardware met intelligente software.

RAID is van oudsher bedoeld om de 'slimme' route te spelen: goedkope disks - vandaar ook 'Inexpensive' in de afkorting van RAID - gekoppeld met slimme software die uiteindelijk een betrouwbaar opslagvolume presenteert aan de gebruiker. Hoewel RAID goed met disk failures kan omgaan, is het niet ontworpen om goed bestand te zijn tegen bad sectors. Het probleem van uBER bad sectors die niet fysiek beschadigd zijn maar simpelweg te weinig errorcorrectie voorhanden hebben, kan RAID weinig tegen beginnen. Een disk met bad sector wordt eigenlijk als een hele disk failure gezien.

Dus hoe los je dat probleem - bitrot - nu op?

De 'domme' route is het gebruik van dure disks met 10^-16 uBER waardoor deze een factor 100 minder bad sectors genereren dan consumentenschijven die 10^-14 uBER specificatie meekrijgen.

De 'slimme' route is een 3e generatie filesystem gebruiken; waaronder dus ReFS (Microsoft), Btrfs (Linux) en ZFS (Solaris/BSD/Linux).

Panzy schreef op donderdag 19 december 2013 @ 12:01:
Omdat ZFS nogal complex is en er softwarematig heel wat gebeurt

Bij traditioneel RAID is dat ook zo, alleen zijn het dan afzonderlijke lagen die niets van elkaar afweten. Dergelijke complexiteit kan leiden tot problemen. ZFS is van de grond opgebouwd waarbij de belangrijke delen ook beperkt zijn in complexiteit en omvang van de broncode. Maar je hebt zeker een punt dat complexiteit een vijand is van betrouwbaarheid. Een complex systeem kan jarenlang superbetrouwbaar werken en door een vaag issue wat maar heel zelden getriggered wordt keihard op zijn bek gaan. Gelukkig heeft ZFS al heel wat jaartjes liefde ontvangen om die bugs eruit te halen. Maar ik heb corrupte ZFS pools meegemaakt onder FreeBSD, toen ZFS nog niet officiëel in de tree zat.

Ik sta echt op het punt om ZFS te installeren gewoon puur vanwege het gebrek aan wat anders, maar elke keer komen er weer verhalen zoals hierboven van Byte naar voren over 'corruptie', dat ik denk van waar doe ik het voor.

Dat verhaal van corruptie is waarschijnlijk corruptie op applicatie-niveau. Daartegen kun je je wapenen met snapshots en sync writes.

ZFS gebruiken in combinatie met Hardware RAID is min of meer de enige manier om ZFS op zijn bek te krijgen. Met name onveilige write-back is enorm gevaarlijk. Het probleem is dat een dergelijke Hardware RAID controller een superbelangrijke beveiliging om zeep helpt: de FLUSH CACHE commando's worden uitgeschakeld; anders zou de interne 1GB writeback nog niet tot een megabyte gevuld kunnen worden. Maar dat uitschakelen betekent wel dat de bescherming die ZFS gebruikt om de integriteit te bewaken wordt verstoord.

[Panzy]

Verwijderd schreef op donderdag 19 december 2013 @ 18:35:
[...]
ZFS gebruiken in combinatie met Hardware RAID is min of meer de enige manier om ZFS op zijn bek te krijgen. Met name onveilige write-back is enorm gevaarlijk. Het probleem is dat een dergelijke Hardware RAID controller een superbelangrijke beveiliging om zeep helpt: de FLUSH CACHE commando's worden uitgeschakeld; anders zou de interne 1GB writeback nog niet tot een megabyte gevuld kunnen worden. Maar dat uitschakelen betekent wel dat de bescherming die ZFS gebruikt om de integriteit te bewaken wordt verstoord.

Bedankt voor de uitgebreide post weer, 1 ding snap ik alleen niet:

Kun je mij vertellen hoe ZFS kan weten dat het op een RAID array staat en daardoor commando's gaat uitschakelen? Mijn computer weet namelijk niet beter dan dat het gewoon een HDD is, wel knap dat ZFS daar omheen kan kijken.

[]Byte[]

Panzy schreef op donderdag 19 december 2013 @ 17:12:
Mischien als op een SAN een schijf uberhaupt maar 1 keer een fout geeft dat hij meteen vervangen wordt.

Überhaupt bij de eerste fout... Lijkt mij niet. Want zelfs een controller-failover zal een (recoverable) error op de disk genereren. Ook voor recoverable errors geldt ook: thresholds!
Voor HP's weet ik het zeker... Die hanteren redelijke thresholds, en afhankelijk van het type error wordt er een alarm gegenereerd (of niet).
Zo zullen de thresholds voor hard-errors aanzienlijk lager liggen als voor soft-errors.
Verder is de 1 van de eerste vragen van de leverancier als je je storing aanmeld (als de disk nog responsive is): Wat is de firmwareversie van de disk?
Reactie 1: UPGRADEN!

[Q]

Heb vorige maand data corruptie (parity errors) gehad op een MSA P2000 G3 entry level SAN (failover non-critical SAN) van HP. Inderdaad: firmwares upgraden. Van zowel het SAN als de disks. De meest waarschijnlijke oorzaak was een missende critical disk update die ik had gemist... Alle data corrupt en disks en luns opnieuw aangemaakt, van scratch moeten beginnen met data repliceren.

SANs zijn gaaf maar ok bar griezelig. Je moet firmwares blijven updaten vanwege dit soort critical issues, en dan maar hopen dat die nieuwe updates geen nieuwe critical issues introduceren.

[Panzy]

Mooi kut dat, en daar betaal je dan hoeveel voor? Doe dan maar ZFS idd haha. Zou HP aanklagen ofzo, gewoon blijven volhouden dat je firmware up to date was.