Het grote ZFS topic

[Geckx]

webbier schreef op dinsdag 08 oktober 2013 @ 22:18:
[...]


Het is al een aantal keer in het forum langs gekomen hoe je dit kunt oplossen.

FireDrunk in "Het grote ZFS topic"

Als ik de FreeBSD portstree wil installeren krijg ik volgende error:

"ERROR: install script does not exist for service system-portstree"

Als ik de (latest) wil installeren klaagt hij dat ik geen internet connection heb om remote te downloaden....

Daardoor kan ik de stappen van FireDrunk dus niet uitvoeren..
"-bash: cd: /usr/ports/sysutils/spindown: No such file or directory"

[ Voor 11% gewijzigd door Geckx op 12-10-2013 11:28 ]

[FireDrunk]

Welke versie van ZFSguru heb je?

[Geckx]

de laatste nieuwe. 0.2.0 beta 8 met 9.1-006

[FireDrunk]

Misschien is de service kapot, want dat zou wel moeten werken volgens mij, misschien kan CiPHER er iets over zeggen.

[Verwijderd]

Check je DM.

[Johnnygo]

Ik heb een probleem met mijn zfsguru installatie.
Ik heb een esxi server draaien met de op het moederbord aanwezige sata poorten doorgezet naar de vm waar zfsguru op draait. Aan het begin werkte dit perfect. Ik heb een pool aangemaakt, en die was benaderbaar via het netwerk.
Tussendoor is de esxi server uit geweest, en zijn de schijven met de zfs pool los geweest van het moederbord. Nu heb ik de schijven weer op het moederbord geprikt, en esxi weer gestart. Maar nu kan zfsguru de schijven niet meer vinden. In het syslog zie ik de volgende foutmelding staan:

Running ipoib_init_module (0xffffffff80b21300)
ahci0: <Intel Panther Point AHCI SATA controller> port 0x4038-0x403f,0x4030-0x4033,0x4028-0x402f,0x4024-0x4027,0x4000-0x401f mem 0xfd4fe800-0xfd4fefff irq 19 at device 0.0 on pci3
ahci0: AHCI controller reset failure
device_attach: ahci0 attach returned 6
ahci0: <ASMedia ASM1061 AHCI SATA controller> port 0x5038-0x503f,0x5030-0x5033,0x5028-0x502f,0x5024-0x5027,0x5000-0x501f mem 0xfd3fec00-0xfd3fedff irq 19 at device 0.0 on pci11
ahci0: AHCI controller reset failure
device_attach: ahci0 attach returned 6
Trying to mount root from zfs:BootDisk/zfsguru/9.1-006 [rw]...
ahci0: <Intel Panther Point AHCI SATA controller> port 0x4038-0x403f,0x4030-0x4033,0x4028-0x402f,0x4024-0x4027,0x4000-0x401f mem 0xfd4fe800-0xfd4fefff irq 19 at device 0.0 on pci3
ahci0: AHCI controller reset failure
device_attach: ahci0 attach returned 6
ahci0: <ASMedia ASM1061 AHCI SATA controller> port 0x5038-0x503f,0x5030-0x5033,0x5028-0x502f,0x5024-0x5027,0x5000-0x501f mem 0xfd3fec00-0xfd3fedff irq 19 at device 0.0 on pci11
ahci0: AHCI controller reset failure
device_attach: ahci0 attach returned 6

De schijven zijn nu helemaal niet beschikbaar. Maar in de bios kan ik ze wel gewoon zien. En als ik andere schijven op het moederbord prik, dan werken die wel gewoon onder een standaard linux (geen esxi / vm) installatie. Ik heb in de tussentijd geen instellingen in de bios veranderd. Alleen heb ik tijdelijk andere schijven aan het moederbord gehad. Wat kan nu het probleem zijn?

[]Byte[]

Ik probeer ZFSguru in Fusion te starten.
T/m aanmaken van de pool en installatie ging het goed, maar na de reboot staat in de linker bovenhoek alleen de | / - \ (sterretje) rond te tollen.
Iemand een idee?

[Verwijderd]

@Byte: zolang je die 'cursor' ziet bewegen dus - \ | / - etc. dan is de bootcode bezig. De bootcode is niet erg efficient. De nieuwe bootcode in FreeBSD 10 is veel sneller/beter. Maar het kan dus zijn dat het lang duurt maar wel werkt. Kun je dat uittesten? Wat voor pool configuratie heb je gemaakt? Je hebt het formatteren ook via ZFSguru gedaan?

@Johnnygo: kan zijn dat je in ESXi het 'doorgeven' opnieuw moet doen. Dit soort dingen heb ik vaker gehoord van mensen. Ik gebruik zelf geen ESXi, maar hoogstwaarschijnlijk heb je nergens last meer van als je ESXi overslaat en bare metal ZFSguru installeert. Maar probeer eens met het vt-d doorgeven te kloten, kan zijn dat het dan opeens weer wel werkt omdat er een andere interrupt wordt gepakt of wat dan ook.

Eventueel kun je de truc toepassen om MSI en MSI_X uit te schakelen. Hoe je dat doet kun je met google vinden; moet je wat dingen in /boot/loader.conf of /boot/device.hints stoppen zodat MSI en MSI-X interrupts worden uitgeschakeld. Ik zou dat alleen doen als het zonder niet lukt om het werkend te krijgen. Wat raar zou zijn omdat je zegt dat voordat je dingen hebt veranderd het wel gewoon goed werkte.

[FireDrunk]

[trollmodus]
Zelfs in FreeBSD 10.0 is booten takke-takke traag
[/trollmodus]

[syl765]

Gelukkig hoef je de FreeBSD machines niet vaak meer te booten als ze een maal draaien.

Gr

[Verwijderd]

FireDrunk schreef op zondag 13 oktober 2013 @ 19:55:
Zelfs in FreeBSD 10.0 is booten takke-takke traag

Waar doel je dan precies op? De 10-40 seconden boottime vanaf dat de kernel geladen is? Of doel je op het eerste gedeelte, waarbij je ronddraaiende cursor ziet en de kernel wordt ingeladen en de kernel modules? Dat gedeelte zou sneller moeten zijn in de FreeBSD 10 bootcode (mits je ook daarmee je disks hebt geformatteerd natuurlijk). De verbeteringen zijn betere cache management, waardoor niet onnodig vaak hetzelfde stuk moet worden ingelezen zoals nu het geval is. Zo heb ik begrepen.

Boot tijd is verder niet zo cruciaal voor een server. Je wilt alleen geen gezeik tijdens de boot. De bootcode kan nog verder worden verbeterd in dit verband.

Dat je van RAID-Z1/2/3 kunt booten is sowieso een unieke feature van FreeBSD. Dus dat het trager gaat dan normaal is wellicht begrijpelijk gezien de complexiteit en de beperkte ruimte van de bootcode. Het is eigenlijk een mini-ZFS engine (512B + 4K + 200K).

Maar ook met gewoon UFS is FreeBSD geen ster in boottijden. Maar daar ligt natuurlijk niet de prioriteit bij een server OS wat normaliter vele maanden zo niet jaren uptime kent. FreeBSD scoorde altijd hoog in de lijstjes van langste systemen die zonder interrupties (restarts) continu beschikbaar zijn.

[]Byte[]

Verwijderd schreef op zondag 13 oktober 2013 @ 19:47:
@Byte: zolang je die 'cursor' ziet bewegen dus - \ | / - etc. dan is de bootcode bezig. De bootcode is niet erg efficient. De nieuwe bootcode in FreeBSD 10 is veel sneller/beter. Maar het kan dus zijn dat het lang duurt maar wel werkt. Kun je dat uittesten? Wat voor pool configuratie heb je gemaakt? Je hebt het formatteren ook via ZFSguru gedaan?

Traag?
Ik mag hopen dat ie na ruim een half uur toch wel eens klaar mag zijn. (bij mijn post om 19:25 draaide die al ff. nu nog steeds)
Traag is 1, maar dit...
Het lijkt er op dat ie in zijn bootcode blijft hangen.

Ik heb een RAID-Z2 gemaakt van 10 disks (1 GB per stuk)
Alles via de ZFSguru webinterface.

[ Voor 4% gewijzigd door ]Byte[ op 13-10-2013 20:32 ]

[FireDrunk]

Verwijderd schreef op zondag 13 oktober 2013 @ 20:20:
[...]

Waar doel je dan precies op? De 10-40 seconden boottime vanaf dat de kernel geladen is? Of doel je op het eerste gedeelte, waarbij je ronddraaiende cursor ziet en de kernel wordt ingeladen en de kernel modules? Dat gedeelte zou sneller moeten zijn in de FreeBSD 10 bootcode (mits je ook daarmee je disks hebt geformatteerd natuurlijk). De verbeteringen zijn betere cache management, waardoor niet onnodig vaak hetzelfde stuk moet worden ingelezen zoals nu het geval is. Zo heb ik begrepen.

Boot tijd is verder niet zo cruciaal voor een server. Je wilt alleen geen gezeik tijdens de boot. De bootcode kan nog verder worden verbeterd in dit verband.

Dat je van RAID-Z1/2/3 kunt booten is sowieso een unieke feature van FreeBSD. Dus dat het trager gaat dan normaal is wellicht begrijpelijk gezien de complexiteit en de beperkte ruimte van de bootcode. Het is eigenlijk een mini-ZFS engine (512B + 4K + 200K).

Maar ook met gewoon UFS is FreeBSD geen ster in boottijden. Maar daar ligt natuurlijk niet de prioriteit bij een server OS wat normaliter vele maanden zo niet jaren uptime kent. FreeBSD scoorde altijd hoog in de lijstjes van langste systemen die zonder interrupties (restarts) continu beschikbaar zijn.

Mijn server draait native FreeBSD 10-CURRENT en boot in *denk ik* een seconde of 50-60. Dit is van een Crucial M500 SSD.
Mijn Windows 8 laptop met UEFI doet dat in 7-10 seconden... En die heeft meer devices te laden...

En dan heb ik het over power on to ready

En al die verhalen over lange uptimes vind ik maar klets, dan heb je geen fatsoenlijk patch management en life cycle management in je datacenter... Bovendien is het goed om tijdens maintenance weekends af en toe de servers te rebooten, dan weet je tenminste of ze nog opkomen. Beter *dan* een failure dan op een moment dat het je niet uitkomt...

Bij een server met een uptime van 800 dagen, denk ik meteen... Wat een pruts beheerder, die patcht nooit de kernel.

[ Voor 13% gewijzigd door FireDrunk op 13-10-2013 20:37 ]

[Verwijderd]

offtopic:
Oh daar heb je wel een punt in hoor. Toch kan een kaal en gestript oud UNIX systeem nog prima inzetbaar zijn na vele jaren zonder (kernel-)patches. Als je complexe software gaat draaien neemt de kans op vulnerabilities natuurlijk ook sterk toe.

Maar jouw 50-60 seconden vind ik wel lang. Langer dan bij mij met ik denk 25 seconden. Met Windows vergelijken is leuk, maar een Windows installatie boot vaak geeneens op een ander systeem, terwijl dat bij FreeBSD en Linux enzo toch wel zou moeten werken. Dus dat is al niet eerlijk vergelijken. Bovendien is het natuurlijk logisch dat een desktopsysteem meer belang heeft bij snelle boottijden dan een server. De prioriteiten liggen hier anders.

]Byte\[ schreef op zondag 13 oktober 2013 @ 20:30:
Het lijkt er op dat ie in zijn bootcode blijft hangen.
Ik heb een RAID-Z2 gemaakt van 10 disks (1 GB TB? per stuk)
Alles via de ZFSguru webinterface.

Je boot dus van de RAID-Z2. Het is in dit geval niet de beste optie door van 10 disks te booten. Wat je veel beter kunt doen is de disks zo partitioneren dat je een gedeelte vrijhoudt voor een aparte pool om van te booten. Als je een SSD hebt is dat nog beter, dan kun je daar ZFSguru op installeren in een partitie, volgende partitie L2ARC cache voor je pool en volgende partitie misschien SLOG.

Heb je niet de beschikking over een SSD, partitioneer je disks dan zoals bijvoorbeeld:
- freebsd-boot partitie (heb je altijd)
- 16GB partitie voor systeem/boot
- 934GB partitie voor 'tank' pool

In dit geval heb je eigenlijk twee echte partities. Eentje van 16GB voor de kleine pool waar je ZFSguru op installeert. Verder ruimte voor services en meerdere installaties en de swapfile.

Je kunt alle disks op deze manier partitioneren. Je kunt dan een 'systeem' ZFS pool maken via de web-interface en dan RAID1 (mirror) kiezen en dan meerdere disks selecteren. Bijvoorbeeld 6 van de 10 disks. Je houdt dan 4 van de 10 over voor misschien andere dingen, zoals een dedicated swap partitie of misschien dingen voor later.

Vervolgens maak je een 'tank' data ZFS pool van alle grote partities op alle 10 de disks. Daar zet je dan je data op, maar je boot er niet van. Dat laatste is de truc; want je kunt nu veel sneller booten van een mirror en van een kleine partitie. Zo hoeft de bootcode minder te zoeken en gaat het zaakje veel sneller.

[ Voor 54% gewijzigd door Verwijderd op 13-10-2013 20:57 ]

[]Byte[]

Euhh... die disken van 1 GB klopt!
Het gaat mij nu ff om de functionele test en het gevoel er bij krijgen.
Wat is dan makkelijker om dat te testen met Fusion?
Ik volg ZFS nu al een tijdje met belangstelling en ga deze week hardware bestellen om als nieuwe server in te kunnen richten met ZFSguru.
Ben er alleen nog niet uit welk mainboard ik ga nemen.
zal 16 of 32 GB RAM worden met 11 of gelijk vol met 16 disken van 4TB.
en een 3 of 4 poort LAGG naar de switch.
En, JA en komen ook 2 SSD's in voor de mirror-partities, SLOG en L2ARC.
Heb jij nog een goeie tip voor welk MB? (liefst eentje met IPMI (supermicro?))

[]Byte[]

Hehe... Ik heb 'm aan de gang!
Heb nu 2 * 10 GB opgesplitst in 4-2-4 GB
4 GB boot_mirror
2 GB slog_mirror
2*4 GB l2arc_stripe
en verder 10 * 1 GB in RAID-Z2 voor data_pool
Boot gaat nu ook normaal lekker snel.
[update]
hmmm... zie nu als ik de cache en log -devices wil aangeven, dat ik daar iets niet goed heb gedaan...
/me ]Byte[ mompeld iets van: back to the drawing board...
[update 2]
Werkt!

Vraagje:

Is onderstaande representatief? (lijkt mij wat aan de hoge kant)
Ik heb 'm in Fusion draaien op mijn MacBook Pro waar ik een 750 GB SSD in heb zitten.

ZFSguru 0.2.0-beta8 (9.1-004) pool benchmark
Pool : datapool1 (9.88G, 0% full)
Test size : 64 GiB
normal read : 372 MB/s
lzjb read : 3 GB/s
lzjb write : 2 GB/s
gzip read : 3 GB/s
gzip write : 2 GB/s
I/O bandwidth : 32 GB/s

[ Voor 36% gewijzigd door ]Byte[ op 14-10-2013 11:14 ]

[FireDrunk]

Hoe bedoel je representatief? Als je lokaal op een SSD test krijg je natuurlijk andere resultaten dan je ooit met disks gaat krijgen. Ook al maak je meerdere disks aan via een virtualisatie laag, het is nooit representatief ten opzichte van de werkelijkheid met conventionele schijven.

Enige wat representatief is, is de interface

[]Byte[]

FireDrunk schreef op maandag 14 oktober 2013 @ 12:32:
Enige wat representatief is, is de interface

lol...
Ik doelde ook eigenlijk op de lzjb en gzip van 2/3 GB/s

[update]
De "normal read : 372 MB/s" is nog wel redelijk representatief.
Buiten de virtualisatie om haal ik 400 MB/s schrijven en 530 MB/s lezen. (op een filesize van 90 GB)

[ Voor 28% gewijzigd door ]Byte[ op 14-10-2013 13:17 ]

[FireDrunk]

Nope, ook dat is niet representatief omdat je aan het virtualiseren bent.

[Kek]

Even een korte vraag; wat is te prefereren.

een klein aantal grote schijven (3x 4gb) of een groter aantal kleine schijven (6x2tb) en wat heeft z'n voor en nadelen..

alvast dank

[Bigs]

Kek schreef op maandag 14 oktober 2013 @ 15:40:
Even een korte vraag; wat is te prefereren.

een klein aantal grote schijven (3x 4gb) of een groter aantal kleine schijven (6x2tb) en wat heeft z'n voor en nadelen..

alvast dank

Een groter aantal kleinere schijven bieden meer IOPS en een kortere rebuild tijd bij het falen van een schijf. Een kleiner aantal grotere schijven is mogelijk voordeliger en stelt je in staat om meer opslagcapaciteit te creëren in hetzelfde chassis.

[FireDrunk]

Meer schijven zijn vaak duurder, zowel in aanschaf als in verbruikskosten.
Voor meer schijven heb je meer aansluitingen nodig, dus vaak een duurder moederbord, of een duurdere kast.

Beste is om zo groot mogelijke schijven te nemen in mijn ogen. 3TB schijven zijn momenteel prijs/GB het goedkoopst, maar 4TB schijven liggen er maar een paar euro naast.

4TB schijven verbruiken (verhoudingsgewijs) minder stroom (watt/GB), en zijn daardoor weer wat goedkoper in verbruikskosten.
Dus als je server 24/7 aan staat zou ik voor 4TB schijven gaan, staat hij lang niet altijd aan, kan je beter voor 3TB schijven gaan.

[Bigs]

FireDrunk schreef op maandag 14 oktober 2013 @ 15:50:
Meer schijven zijn vaak duurder, zowel in aanschaf als in verbruikskosten.
Voor meer schijven heb je meer aansluitingen nodig, dus vaak een duurder moederbord, of een duurdere kast.

Beste is om zo groot mogelijke schijven te nemen in mijn ogen. 3TB schijven zijn momenteel prijs/GB het goedkoopst, maar 4TB schijven liggen er maar een paar euro naast.

4TB schijven verbruiken (verhoudingsgewijs) minder stroom (watt/GB), en zijn daardoor weer wat goedkoper in verbruikskosten.
Dus als je server 24/7 aan staat zou ik voor 4TB schijven gaan, staat hij lang niet altijd aan, kan je beter voor 3TB schijven gaan.

Het is natuurlijk maar net wat doel je hebt.. ik heb zelf een array met 12x600GB SAS schijven als opslag voor virtualisatie. Die zou ik kunnen vervangen door 2x4TB SATA schijven, maar dan verwacht ik niet dat het nog lekker loopt (al kun je door het toevoegen van SSD's er met ZFS natuurlijk nog behoorlijke prestaties uit trekken). Verder moet je er niet aan denken dat een van die twee schijven faalt; het kan zo 3 dagen duren voordat je resilver klaar is en dan moet je maar hopen dat de andere schijf in de tussentijd niet ook faalt. Nee ik zie absoluut voordelen in de keuze voor spindels.

De backup opslag voor de 12x600GB array is trouwens wel het eerder genoemde setje 3TB schijven. Daar gaat prijs en opslagruimte wel weer voor prestaties.

[FireDrunk]

3 dagen resilveren? hoe kom je daar bij? Ik doe hier een scrub in een uur of 8.

  scan: scrub in progress since Mon Oct 14 11:21:10 2013
        8.73T scanned out of 9.14T at 389M/s, 0h18m to go
        0 repaired, 95.58% done

En dat is al je data lezen en verifieren, terwijleen resilver dat niet eens hoeft... Zolang je genoeg geheugen en CPU power overhebt kan je toch tegen een aardige snelheid resilveren...

Ik heb ooit eens 10*2TB gehad, waar ik 2 schijven tegelijk resilverde en dat duurde echt maar een paar uur (8-10).

3 Dagen is echt overdreven, of je moet het hebben over een systeem wat echt live nog een hoop andere dingen moet doen...

[analog_]

Het is mijn beurt vandaag:

code:

root@troy:~# zpool status slc
  pool: slc
 state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
        repaired.
  scan: resilvered 675K in 0h0m with 0 errors on Fri Aug  9 06:37:59 2013
config:

        NAME                                              STATE     READ WRITE CKSUM
        slc                                               DEGRADED     0     0     0
          mirror-0                                        ONLINE       0     0     0
            ata-SSDSA2SH032G1GN_INTEL_CVEM001000H2032HGN  ONLINE       0     0     0
            ata-SSDSA2SH032G1GN_INTEL_CVEM9485007C032HGN  ONLINE       0     0     0
          mirror-1                                        ONLINE       0     0     0
            ata-SSDSA2SH032G1GN_INTEL_CVEM001000RE032HGN  ONLINE       0     0     0
            ata-SSDSA2SH032G1GN_INTEL_CVEM952200WN032HGN  ONLINE       0     0     0
          mirror-2                                        DEGRADED     0     0     0
            ata-SSDSA2SH032G1GN_INTEL_CVEM001000RH032HGN  FAULTED      1    30     1  too many errors
            ata-SSDSA2SH032G1GN_INTEL_CVEM95260087032HGN  ONLINE       0     0     0
          mirror-3                                        ONLINE       0     0     0
            ata-SSDSA2SH032G1GN_INTEL_CVEM0010018H032HGN  ONLINE       0     0     0
            ata-SSDSA2SH032G1GN_INTEL_CVEM952600JY032HGN  ONLINE       0     0     0

errors: No known data errors

Het zijn Intel SLC ssds die vrij weinig cycles erop zitten (1/5 tot 1/3 van spec'ed writes). Het zou kunnen dat tijdens een stof afveeg actie er een hotswap bracket is losgeklikt (kamergenoot ). Twijfel tussen clearen of direct vervangen, rebuild tijd is irrelevant voor de strategie (3min).

zpool version waarschuwing is mijn keuze voor portability (OI/NexentaStor).

[ Voor 10% gewijzigd door analog_ op 14-10-2013 23:17 ]

[]Byte[]

Vraagje:
Ik weet dat en 3 soorten dedup zijn:
file-, block- en byte-level dedup.
Volgens de ZFS-Wiki zou byte-level het meest gebruikt worden (?? = extreem CPU intensief).
Voor zover ik weet (heb zelf ervaring met HP EVA's, StorOnce, DataDomain, VMAX etc.) dacht ik altijd dat juist block-level dedup het meest gebruikt werd.
Ik heb niet echt kunnen vinden welke dedup er door ZFS gebruikt wordt.
Als er al block-level gebruikt wordt in ZFS, kan je dan zelf de block-size bepalen?

[Bigs]

Volgens mij gebruikt ZFS block-level dedup, wat ook het meest logisch is voor ZFS.

Deze blog post van 1 november 2009 spreekt in ieder geval over block level dedup:

https://blogs.oracle.com/bonwick/entry/zfs_dedup

ZFS provides block-level deduplication because this is the finest granularity that makes sense for a general-purpose storage system. Block-level dedup also maps naturally to ZFS's 256-bit block checksums, which provide unique block signatures for all blocks in a storage pool as long as the checksum function is cryptographically strong (e.g. SHA256).

De blockgrootte is gelijk aan de record size, wat voglens mij weer losstaat van de variabele block size Het heeft een hoog niet druk maken, het werkt zoals het bedoeld is gehalte. Overigens moet je niet blindelings dedup aanzetten op je pool, in mijn ervaring is het slechts in klein aantal situaties voordelig.

[FireDrunk]

Wat Bigs zegt klopt helemaal, ZFS doet Block-level dedup, en dat is absoluut niet iets wat je zomaar aan wil zetten. Het kost bergen geheugen

[]Byte[]

Bigs schreef op dinsdag 15 oktober 2013 @ 09:06:
Overigens moet je niet blindelings dedup aanzetten op je pool, in mijn ervaring is het slechts in klein aantal situaties voordelig.

"Klein aantal situaties" is wat kort door de bocht.
Maar het is zeker niet geschikt voor alles.
Ik heb het zelf ooit meegemaakt bij een klant waar ik DataDomain's had geïmplementeerd, ze na mijn vertrek ook nog (heavy use) databases op de DD hadden gezet...
En hun zich dan maar afvragen waarom ze problemen hadden?

Je moet vooral kijken naar repeterende data.
Uitstekend te gebruiken voor relatief 'statische' data als back-ups, archivering en andere niet I/O intensieve data.
Databases op een dedup zetten is vragen om problemen.

FireDrunk schreef op dinsdag 15 oktober 2013 @ 09:12:
Het kost bergen geheugen

Dan stoppen we er gewoon een paar repen extra bij!
16 of 32 GB maakt dan ook niet veel meer uit in de kosten.

[FireDrunk]

Als je echt grote volumes gaat doen (4-8TB+) moet je eerder aan 64GB gaan denken.

[Bigs]

Ook voor backups was dedup bij ons niet rendabel. Ik ging er vanuit dat het wel voordeel zou bieden aangezien we een grote hoeveelheid backups van sterk op elkaar lijkende machines hadden (en geen snapshots gebruikten, maar rdiff backups). Uiteindelijk viel de winst tegen (factor 2) en zoals FireDrunk al zegt zijn de geheugeneisen echt extreem. Ik ga een backup opslag server niet uitrusten met 64GB geheugen.

Nu gebruiken we snapshots+compressie en hebben we zonder iets bijzonders te hoeven doen toch 50% besparing.

[ Voor 0% gewijzigd door Bigs op 15-10-2013 09:48 . Reden: compressratio bleek nog hoger te zijn ]

[]Byte[]

FireDrunk schreef op dinsdag 15 oktober 2013 @ 09:33:
Als je echt grote volumes gaat doen (4-8TB+) moet je eerder aan 64GB gaan denken.

Hmmm.... dat is wel heel veel.
Dan moet in de keuze van mainboard wel ff nader bekijken...
Ik zal mij hier eens wat verder in moeten verdiepen als dit echt zo extreem memory-hungry is.
Ik zat te denken aan iets van 9*4TB in een pool met RAID-Z1
Ik ben nu nog even een testje aan het draaien in Fusion.
Ik heb er op dit moment 300 files van 1 GB in staan, op een pool van 10 GB, en zie nu nog geen extreem memory verbruik.
De I/O's op disklevel vallen ook nog redelijk mee. (< 60 iops) tijdens het intensief aanmaken van de files.

[FireDrunk]

Je kan natuurlijk 2 of 4 snelle SSD's als swap in zetten voor het geval dat als je er echt een ander moederbord voor moet kopen.

Je kan 32GB nemen en 64GB aan snelle swap (2*128GB Seagate 600 Pro's ofzo welke je ook voor ZIL/L2ARC kan gebruiken). Je verdeelt een deel voor ZIL en L2ARC en een deel voor Swap.

Denk dat dat wel kan.

[]Byte[]

Ik moet nog een MB, CPU en RAM gaan bestellen. Ben er alleen nog niet over uit welke...
Heb nu een Ri-vier RV-3316-01A, 2 * M1015 en 9 * 4TB HD's in bestelling staan.
Maar het komt goed uit.
Ik heb nog een 120GB Vertex 3 en een 128 GB Samsung 840 op de plank liggen.
Tnx voor de tip!

[update]
Heb je misschien ook een link voor me waar ik meer info kan vinden over de (on)mogelijkheden van de dedup in ZFS?
Waar wordt bijv. de hash-database opgeslagen?
Zijn er beperkingen t.a.v. aantal of grootte van files?
Wat zijn de DO's en DON'T's...
Wat zijn de exacte sizing-req's?
Als ik kijk naar OpenDedup heb ik 25 bytes per chunk nodig.
Dat is makkelijk rekenen... volumesize/chunk-size*25 bytes = xxx RAM
Dit heb ik bij de dedup van ZFS nog niet kunnen vinden.

[ Voor 47% gewijzigd door ]Byte[ op 15-10-2013 13:54 ]

[Trunksmd]

over ECC: ik ben een beetje laat met commentaar, maar hier stond nog een interessante discussie. Zeker als je vanaf een usb stick boot, lijkt ECC toch wel zo handig te zijn.

http://forums.freenas.org...on-ecc-ram-and-zfs.15449/

Ik moet zeggen dat ik zelf ook maar een servertje op een AMD e350 draai. Ik weet niet hoever je zou moeten gaan als amateur thuis gebruikertje.

[FireDrunk]

http://www.oracle.com/tec...ze-zfs-dedup-1354231.html

Ik bedenk mij net (nu jij de vraag stelt, waar staat de DDT) dat je beter een grote L2ARC kan bouwen dan een grote Swap drive. DDT's kunnen prima in L2ARC opgeslagen worden, en dat is veel beter dan in swap.

Een mirror van SSD's als L2ARC zal dus prima werken.

Als ik even lomp reken heb je voor 2TB aan unieke data 5GB nodig aan RAM alleen voor de DDT's, maar dat is mijn best guess en alleen correct als ik de formules goed begrijp. 9*4TB in RAIDZ betekend plaats voor 36TB data. Als dit dus allemaal unieke blocks zouden zijn, zou je DDT ongeveer 30GB zijn.

Met een vlotte L2ARC en 32GB RAM kan je dat denk ik wel redelijk performant krijgen. Bedenk wel dat voor echte snelheid de hele DDT in RAM moet staan.

Een van de don'ts:

Bedenk ook *heel* goed, dat als die hardware ooit crasht, je die pool alleen kan mounten op een systeem met genoeg RAM / Swap / L2ARC om die DDT in te lezen, want zonder die DDT kan je pool niet gemount worden. In het geval van error recovery moet je dus beschikken over net zo'n dikke server.

[ Voor 54% gewijzigd door FireDrunk op 15-10-2013 19:02 ]

[analog_]

Ik was dus tijdens mijn uitval erachter gekomen dat machine op basis van Debian wheezy de USB sticks op ext4 inmiddels corrupt zijn geworden (niet geheel onverwacht na een jaar of twee). Ik had nu een Debian + ZoL + ofed van alioth (google) en opensm uit de standaard repo met uit svn gecompileerde scst.

Nu ga ik overstappen naar Ubuntu 12.04 wat een recente btrfs brengt welke hopelijk de USB stick een langer leven gunt. Daarnaast weer ZoL maar nu met het LIO scsi subsysteem ipv. scst. Mellanox en opensm zijn weer van de partij maar het mooie zou zijn dat alles uit standard repo kan komen. Performance wise zou dit ook mijn 200MB/s plafond probleem kunnen oplossen over IB. Ook is het niet mogelijk om infiniband via LIO aan te spreken op kernels uit de debian stable stal

SSD is cleared maar gaat weer op z'n kop, zal dus een 7 disk raidz3 volume worden.

[ Voor 6% gewijzigd door analog_ op 16-10-2013 04:21 ]

[FireDrunk]

Waarom 12.04 en niet 13.04?

[BCC]

Aangezien ik niet veel zin heb op van USB stick te booten: kan ik ook op mijn twee schijven een partitie maken van een paar honderd MB, daar EXT2 op zetten en dan vanaf een standaard EXT2 Mirror booten? Of gaat dat niet als ik ook ZFS op de schijven wil?

[Verwijderd]

FireDrunk schreef op dinsdag 15 oktober 2013 @ 18:58:
http://www.oracle.com/tec...ze-zfs-dedup-1354231.html

Ik bedenk mij net (nu jij de vraag stelt, waar staat de DDT) dat je beter een grote L2ARC kan bouwen dan een grote Swap drive. DDT's kunnen prima in L2ARC opgeslagen worden, en dat is veel beter dan in swap.

Een mirror van SSD's als L2ARC zal dus prima werken.

Als ik even lomp reken heb je voor 2TB aan unieke data 5GB nodig aan RAM alleen voor de DDT's, maar dat is mijn best guess en alleen correct als ik de formules goed begrijp. 9*4TB in RAIDZ betekend plaats voor 36TB data. Als dit dus allemaal unieke blocks zouden zijn, zou je DDT ongeveer 30GB zijn.

Met een vlotte L2ARC en 32GB RAM kan je dat denk ik wel redelijk performant krijgen. Bedenk wel dat voor echte snelheid de hele DDT in RAM moet staan.

Een van de don'ts:

Bedenk ook *heel* goed, dat als die hardware ooit crasht, je die pool alleen kan mounten op een systeem met genoeg RAM / Swap / L2ARC om die DDT in te lezen, want zonder die DDT kan je pool niet gemount worden. In het geval van error recovery moet je dus beschikken over net zo'n dikke server.

Goede link. Voor alle volledigheid en liefhebbers eeen kleine aanvulling. Iedere entry in de DDT kost een bepaalde hoeveelheid geheugen. Dit hangt mede af van de implementatie. Ik denk dat alles op basis van Illumos bijv 376 bytes kost. Eerdere OpenSolaris versies kosten bijvoorbeeld 320 bytes. Maar dat is niet alles. DDT entries worden als ZAP opgeslagen. ZAP objecten zijn metadata. Metadata wordt gecached in de ARC. Maar dat kost ook ruimte, aantal bytes hangt af van de implementatie. Als je te weinig RAM hebt om de volledige DDT tabel in de ARC te laten passen en denkt dat ruimte gebruik te kunnen compenseren met een L2ARC bedenk goed dat die entries ook weer RAM kosten. De laatste factor is de zfs record size, standaard 128k. Maar dit is variabel, van min 512 bytes tot max wat je hebt in gesteld per ZFS of ZVOL. Met veel kleine files kan je dus meer blocks hebben dan je storage gedeeld 128k. En kost je DDT meer dan verwacht. Zoals Firedrunk al waarschuwde zelfs met een voldoende grote L2ARC, die je al wel moet hebben toegevoegd als vdev aan je zpool, kan je met te weinig ram alsnog je zpool niet inlezen. Hoe ga je je zpool importeren als je L2ARC kapot is? Je kan de L2ARC niet vervangen want je hebt zpool nog niet geimporteerd. Ouch! Gelukkig kan je zelfs op een single socket E5 al 512 GB prikken. Even sparen en dan kan je je zpool toch weer lezen. Dedup is niet fire and forget als compressie. Het vereist echt zorgvuldige planning alvorens dit in te schakelen. Veel mensen ervaren waardeloze dedup ratio's. Dit kan komen door een te grote ZFS/ZVOL record size. Stem dit af op de bron, bijv 8k voor je NTFS iSCSI vol. Dit lijkt niet een handige zet want een kleinere record size levert meer DDT entries op en dat kost weer meer ram. Echter in dit geval kan het resulteren in hogere dedup ratios. Multimedia bestanden lenen zich ook slecht voor dedup, wat is de kans de twee jpgs hetzelfde block van 128k hebben?
Wat ik vaak zie is dat mensen totaal geen gebruik maken van zfs clones. Eigenlijk is dat ook een vorm van dedup. Zeker voor vm's kan dit handig zijn. Helaas is de NFS client van ESX nog versie 3 en kan je niet nested ZFS fs exporteren. Wel kan je meerdere NFS exports maken en die als losse datastores mounten maar dat schaalt niet in ESX (max 32 dacht ik). Je kan dus niet makelijk 100 vdi clones maken. Met dedup zou je mits alles goed is ingesteld hier wel een behoorlijke winst kunnen halen.
Dedup kan een besparing van de opslag ruimte opleveren maar vereist echt planning en testen. Maak maar een vm een stop je test data erin en kijk wat je voor resultaat behaalt alvorens het in gebruik te nemen.

Zo kan je checken hoeveel ruimte alles kost.
remdiag@oistor1:/rpool2# uname -a
SunOS oistor1 5.11 illumos-14162:b876bad2811a i86pc i386 i86pc Solaris
remdiag@oistor1:/rpool2# echo ::sizeof ddt_entry_t | mdb -k
sizeof (ddt_entry_t) = 0x178
remdiag@oistor1:/rpool2# echo ::sizeof arc_buf_hdr_t | mdb -k
sizeof (arc_buf_hdr_t) = 0xb0

[Bigs]

Nuttige info tweakone. Je snijdt eenzelfde punt aan als wat ik al eerder las, namelijk het probleem met inladen van te grote DDT's op systemen met te weinig RAM/L2ARC. Het is toch zo dat de DDT, als niet in de (L2)ARC past, gewoon direct van de pool gelezen word? M.a.w. ongeacht de grootte van je RAM of de aanwezigheid van een werkende L2ARC zou je naar mijn idee de pool altijd moeten kunnen importeren.

[Bigs]

Nu ik dit topic weer een tijdje volg zie ik toch wel weer potentie om ons dure iSCSI SAN in de toekomst te vervangen door een ZFS oplossing. Een van de belangrijke eisen is dan wel redundant uitgevoerde controllers, oftewel 2 servers gekoppeld aan je JBOD (of bijvoorbeeld een Supermicro SBB). Zou zo'n opstelling in FreeBSD mogelijk zijn, inclusief automatische failover en iSCSI multipath (active/passive)? Of zit je dan vast aan Nexenta (als die dat uberhaupt ondersteunt)?

Als ik het zelf moet gaan bouwen met FreeBSD ben ik onder aan de streep trouwens waarschijnlijk net zoveel kwijt als met een nieuw off-the-shelf SAN (IBM V7000 of Dell Equalogic PS4100) dat in 1x perfect werkt

[Verwijderd]

Bigs schreef op woensdag 16 oktober 2013 @ 21:56:
Nuttige info tweakone. Je snijdt eenzelfde punt aan als wat ik al eerder las, namelijk het probleem met inladen van te grote DDT's op systemen met te weinig RAM/L2ARC. Het is toch zo dat de DDT, als niet in de (L2)ARC past, gewoon direct van de pool gelezen word? M.a.w. ongeacht de grootte van je RAM of de aanwezigheid van een werkende L2ARC zou je naar mijn idee de pool altijd moeten kunnen importeren.

Dedup is niet echt mijn ding. Ik heb iets te vroeg gepost. Je kan je zpool wel importeren zelfs met ontbrekende L2ARC...
zpool import -N <pool name>
Je pool zal worden ingelezen maar de ZFS en ZVOL's zijn niet gemount en kosten dus geen ram. Je kan nu selectief stukken mounten, wat dan wel ram gaat kosten.
Je kan de zpool denk ik ook wel standaard importe met te weinig ram/swap mits deze schoon is geexporteerd. Na een crash heb je denk ik wel een probleem omdat ZFS dan opzoek gaat naar niet afgeronde transacties en dan zal denk ik de DDT tabel worden opgebouwd. Ik zal eens kijken de komende dagen wat ik in de code vind, want misschien klets ik wel aangaande het laatste. De rest van mijn post klopt wel. Beter iets te voorzichtig dan roepen dat alles kan en dan uiteindelijk niet blijkt kunnen.

[Verwijderd]

Bigs schreef op woensdag 16 oktober 2013 @ 22:32:
Nu ik dit topic weer een tijdje volg zie ik toch wel weer potentie om ons dure iSCSI SAN in de toekomst te vervangen door een ZFS oplossing. Een van de belangrijke eisen is dan wel redundant uitgevoerde controllers, oftewel 2 servers gekoppeld aan je JBOD (of bijvoorbeeld een Supermicro SBB). Zou zo'n opstelling in FreeBSD mogelijk zijn, inclusief automatische failover en iSCSI multipath (active/passive)? Of zit je dan vast aan Nexenta (als die dat uberhaupt ondersteunt)?

Als ik het zelf moet gaan bouwen met FreeBSD ben ik onder aan de streep trouwens waarschijnlijk net zoveel kwijt als met een nieuw off-the-shelf SAN (IBM V7000 of Dell Equalogic PS4100) dat in 1x perfect werkt

Er zijn veel factoren die deze keuze beinvloeden

• Bereidheid van de opdrachtgever om uberhaubt iets anders dan van een bekende SAN leverancier te kopen
• Hoeveel storage en hoeveel iops? Bij sommige merken betaal ook nog een buitensporige premie voor ssd's. Of ipv korting bij meer storage moet je weer een premie betalen je hebt immers een groter probleem.
• Is er de continue expertise om een zelf oplossing te supporten? Wat gebeurt er als de ontwikkelaar van het systeem weggaat?

De enige ZFS HA oplossing is RSF-1 dat verkoopt nexenta ook.
ZFS kan niet meer worden afgedaan als hype of niet enterprise ready. Het is nog niet af maar zeker in te zetten in grote omgevingen. Kijk ook naar alle bedrijven die hun product in meer of mindere maten baseren op ZFS. Oracle, Joyent, Delphix, Nexenta etc.
Leuk is om een zelfbouw systeem neer te zetten en dat te vergelijken met een demo model een bekend merk. Dan kan je je eigen workload vergelijken tussen de verschillende oplossingen. ZFS is toch anders en laat zich niet altijd even makkelijk vergelijken met andere oplossingen. Synthetische benches zijn niet zaligmakend. ZFS heeft een ieder geval een feature wat niet heeft (BTRFS is niet productie klaar) en dat is de checksumming. Is het nodig? JA! JA! Wij hebben eens een leuke test gedaan om de noodzaak hiervan aan te tonen. Wij hebben een Lefthand een heleboel luns laten exporteren en toen via een ZFS head daarvan een zpool gemaakt en die weer geexporteerd naar een test farm. De vraag was of we ooit een checksum failure tegen zouden komen. De data stond immers op super betrouwbare storage. In twee maanden kwamen we drie errors tegen. Die allemaal werden gecorrigeerd door ZFS. Waar kwamen ze vandaan? Geen idee, wel weet ik dat ZFS ze detecteerd en verhelpt. Dat heeft die klant voor ZFS doen kiezen. En sterker nog die klant heeft een stuk processing weg gehaald bij vmware en naar Illumos verplaatst. Die klant heeft zeker een risico genomen maar financieel heeft hij enorm bespaart op licentie kosten en hardware. Maar de opdrachtgever moet zich er comfortabel bij voelen. Sommige hebben een probleem wat ze niet kunnen betalen en kiezen dan voor zelfbouw. Vooral de wetenschap doet dit vaak.

[]Byte[]

Verwijderd schreef op woensdag 16 oktober 2013 @ 23:18:
[...] Wij hebben een Lefthand een heleboel luns laten exporteren en toen via een ZFS head daarvan een zpool gemaakt en die weer geexporteerd naar een test farm.

Ik heb zelf geen ervaring met Lefthand, wel met NetApp, HP EVA's en EMC's VMAX-series.
Hoe groot heb je die LUN's gemaakt?
En hoe heb je de sizing van de ZFS-head bepaald?
Nu kan ik mij voorstellen dat dit waarschijnlijk geen extreem zwaar systeem geweest zal hoeven zijn geweest omdat het hier een test-farm bedroeg.
Hebben jullie ook de dedup getest in die periode? Want dat is een aanzienlijk memory-hungry proces.
Alles gekoppeld aan FC neem ik aan?

[Verwijderd]

]Byte\[ schreef op donderdag 17 oktober 2013 @ 16:10:
[...]

Ik heb zelf geen ervaring met Lefthand, wel met NetApp, HP EVA's en EMC's VMAX-series.
Hoe groot heb je die LUN's gemaakt?

300GB net als de fysieke disks

En hoe heb je de sizing van de ZFS-head bepaald?

Ervaring. Er is een X8iets van SM met twee xeon 56iets toen gebruikt met 128GB. En twee dual intel 10Gbit nics. En afhankelijk van de test/benchmark zijn enkele SSD's, een SLOG en een vergelijkbare JBOB toegevoegd

Nu kan ik mij voorstellen dat dit waarschijnlijk geen extreem zwaar systeem geweest zal hoeven zijn geweest omdat het hier een test-farm bedroeg.

Nou het heeft allemaal behoorlijk op zijn donder gehad. Daar zijn echt heel veel kilowatts verstookt! Maar de ZFS head die wel veel meer cpu had dan de Lefthand kon wel 4x10Gbit verwerken. Echt indrukwekkend. De enige tweak waren de jumbo frames, met een mtu van 1500 lukt het niet.

Hebben jullie ook de dedup getest in die periode? Want dat is een aanzienlijk memory-hungry proces.
Alles gekoppeld aan FC neem ik aan?

Nee dat zat er helaas niet in. De data leende zich daar niet voor, allemaal image data. Geen FC maar iSCSI. Ik vertelde deze case omdat je dat zelf wil gaan inzetten. En nogmaals ik weet weinig van dedup, ik ken ook weinig succes verhalen.

Als je echt een ultra snel san wil moet je IB nemen. Grote clusters gebruiken het als fabric, maar ook diverse traders. Moderne trading systemen moeten het hebben van snelle en voorspelbare latency. IB heeft een veel lagere latency dan FC of Ethernet en een veel hogere bandbreedte. Ook de overhead is veel lager. iSCSI en NFS op 10Gbit kosten heel veel CPU. IB met RDMA haalt enorm veel van de overhead weg. Ik weet ook van postproduction bedrijven die IB gebruik als gecombineerd NAS en SAN. Wederom alleen voor de liefhebber.

[Wiebeltje]

Geckx schreef op zaterdag 12 oktober 2013 @ 11:24:
[...]
Als ik de FreeBSD portstree wil installeren krijg ik volgende error:

"ERROR: install script does not exist for service system-portstree"

Als ik de (latest) wil installeren klaagt hij dat ik geen internet connection heb om remote te downloaden....

Daardoor kan ik de stappen van FireDrunk dus niet uitvoeren..
"-bash: cd: /usr/ports/sysutils/spindown: No such file or directory"

Is er al een oplossing voor dit probleem? Ik kom precies het zelfde tegen namelijk (ook dezelfde versie van ZFSguru).

[Verwijderd]

In de 9.1-006 versie zit een bug in de portstree services die portsnap aanroepen om de portstree te downloaden en te installeren. Portsnap heeft een beveiliging voor non-interactive scripts. Als het goed is, zijn daarvoor workarounds ingebouwd in de installatiescripts. Maar die kan ik niet vinden in de tarball package voor 9.1-006. Dus dat is denk ik een fout/defect in de portstree service voor 9.1-006.

Je kunt het vrij simpel zelf installeren:
- system-portstree-latest service downloaden en installeren via GUI (bij install krijg je error over internet toegang)
- inloggen op SSH en root worden met 'su'
- voer uit: /services/system-portstree-latest/service_install.sh

In 9.2-001 (komende build) zou dit uiteraard opgelost moeten zijn.

[HyperBart]

Iemand ervaring met het installeren van NUT voor UPS'en?

Ik had hier graag mijn VM veiliggesteld als de elektriciteit uitvalt. Deze VM is mijn NAS/SAN voor ESXi. Dat alle VM's die er boven draaien dan crashen kan me weinig boeien, mijn data moet vooral veilig zijn weggeschreven.

Ik ging net even in de services pagina en wou nut installeren, maar krijg de melding:

This service is currently not installed and is also not available for your current system version (9.1-006) and platform (amd64). Only available for:

Nut (X) 1 60.3 MiB 9.1-005 stable 9.1-RELEASE amd64

Trucje om dit te omzeilen?

[Verwijderd]

Zelf Nut installeren van de portstree (ten tijde van 9.1-005 was deze denk ik brak/broken). Of je wacht op 9.2-001 die morgen (?) zou moeten uitkomen.

[Sleepie]

Ik heb net 6 disks toegevoegd aan mijn bestaande ZFSguru machine.
Met behulp van de ZFSGuru interface netjes de disks kunnen formateren, en een nieuwe (tweede) pool 'tank2' aangemaakt. Tot hiertoe allemaal prima.

Echter, nu ik de machine reboot, boot hij opeens van de nieuwe pool 'tank2' (wat uiteraard mislukt, er staat immers niets op).
Hij moet gewoon weer van het SSDtje booten wat hiervoor in de machine zit.

Hoe kan ik dit fixen?

Edit:
Door via het BIOS bootmenu gewoon de SSD te kiezen boot de machine.
Nu nog even zoeken naar een permanente fix, zonder dat ik telkens het bootmenu moet gebruiken.
Hoe kan ik dat doen in ZFSguru/FreeBSD?

[ Voor 19% gewijzigd door Sleepie op 21-10-2013 17:33 ]

[DennusB]

Sleepie schreef op maandag 21 oktober 2013 @ 17:25:
Ik heb net 6 disks toegevoegd aan mijn bestaande ZFSguru machine.
Met behulp van de ZFSGuru interface netjes de disks kunnen formateren, en een nieuwe (tweede) pool 'tank2' aangemaakt. Tot hiertoe allemaal prima.

Echter, nu ik de machine reboot, boot hij opeens van de nieuwe pool 'tank2' (wat uiteraard mislukt, er staat immers niets op).
Hij moet gewoon weer van het SSDtje booten wat hiervoor in de machine zit.

Hoe kan ik dit fixen?

Edit:
Door via het BIOS bootmenu gewoon de SSD te kiezen boot de machine.
Nu nog even zoeken naar een permanente fix, zonder dat ik telkens het bootmenu moet gebruiken.
Hoe kan ik dat doen in ZFSguru/FreeBSD?

Niet, je moet in de BIOS de prio's aangeven per schijf/RAID-set.

[ESteg]

Verwijderd schreef op zondag 20 oktober 2013 @ 19:08:
Of je wacht op 9.2-001 die morgen (?) zou moeten uitkomen.

Over uitkomen gesproken: Jason gaf in de State of the Project aan dat beta9 in de zomer gereleased zou worden... het beste van de zomer hebben we inmiddels wel gehad. Is beta9 echt aanstaande?

[Kortfragje]

een update van mijn kant (niet aan toe gekomen ivm nare omstandigheden in familie sfeer). Dankzij alle tips en af en toe lurken op dit topic heb ik ondertussen een 12.04 Ubuntu server met ZoL draaien (naar tevredenheid).

De keuze voor Ubuntu was omdat ik er ook een gevirtualiseerde firewall op heb draaien (IpFire, het host OS heeft geen toegang tot de netwerkadapters en het systeem heeft een 3e eth adapter voor host os LAN toegang).

Het geheel ziet er als volgt uit (waarbij in ogenschouw genomen moet worden dat de 2e pool in principe tijdelijk is..)

Het geheel draait op een C2d 6750 met 8 GB ram (alle schijven connected via onboard sata)

Ik ben van plan een howto / samenvatting op mijn blog te zetten binnenkort hoe ik alles aan de gang heb gekregen.

code:

zpool status -v
  pool: zfspool
 state: ONLINE
  scan: scrub repaired 0 in 10h12m with 0 errors on Tue Oct 15 06:37:13 2013
config:

    NAME        STATE     READ WRITE CKSUM
    zfspool     ONLINE       0     0     0
      raidz2-0  ONLINE       0     0     0
        2tb1    ONLINE       0     0     0
        2tb2    ONLINE       0     0     0
        2tb3    ONLINE       0     0     0
        2tb4    ONLINE       0     0     0
        2tb5    ONLINE       0     0     0

errors: No known data errors

  pool: zfspool2
 state: ONLINE
  scan: scrub repaired 0 in 1h6m with 0 errors on Mon Oct 14 18:56:30 2013
config:

    NAME        STATE     READ WRITE CKSUM
    zfspool2    ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        1tb1    ONLINE       0     0     0
        1tb2    ONLINE       0     0     0

errors: No known data errors

> zpool list
NAME       SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
zfspool   9.06T  7.12T  1.94T    78%  1.00x  ONLINE  -
zfspool2   928G   303G   625G    32%  1.00x  ONLINE  -

Het plan nu is om mijn backup server up te graden (zoals ook al het idee was). Wat ik wil doen is het volgende in RAID-z3 te zetten.

code:

Asrock Z77Pro4-M (8*SATA)
Intel Core i3 2120T Boxed
16 GB DDR3
7*2TB WD Green
Coolermaster ACLY 450 Watt (+3.3V@30A, +5V@35A, +12V1@18A, +12V2@16A, -12V@1.0A, +5VSB@2.5A)

De vraag is, kan ik dan hierna beter de Z3 configuratie als primaire opslag met een Z2 backup gebruiken, andersom of maakt het niet uit?

(mocht iemand nog een suggestie hebben voor een goede case, mijn huidige is een Coolermaster Centurion 5)

[Mystic Spirit]

Wat ik niet zo goed begrijp is waarom je voor je primaire en je back-up config een ander RAID niveau wil gebruiken. Het enige wat ik zou kunnen bedenken is dat back-up op een andere locatie staat en je er niet makkelijk of snel bij kunt, waardoor je een hogere redundantie wilt.

Ik zou de Z3 of Z2 dus niet laten wegen in mijn keuze om te bepalen voor back-up of primair, maar vooral de prestaties van de machine. Gezien het verschil in configuratie zou ik zo niet weten wat beter presteert.

[FireDrunk]

ESteg schreef op maandag 21 oktober 2013 @ 17:48:
[...]


Over uitkomen gesproken: Jason gaf in de State of the Project aan dat beta9 in de zomer gereleased zou worden... het beste van de zomer hebben we inmiddels wel gehad. Is beta9 echt aanstaande?

Om maar weer eens lekker te bashen: Ik heb dat geloof ik bij elke beta van de afgelopen 2 jaar gevraagd, en ze zijn nog nooit op tijd geweest.

Don't keep your hopes up.. Het is een beetje Blizzard stijl: It's done, when it's done...

[FREAKJAM]

Zou iemand mijn volgende post op het freenas forum willen doorlezen en mijn zfs vragen kunnen beantwoorden?

Ik ben van plan 3x4tb (WD Red WD40EFRX) te gebruiken in een RAIDZ opstelling, maar ben er niet zeker van of dat wel de juiste keuze is.

"I'm aware that running 3 disks of 4TB is not the best/safest option. I want to run RAIDZ. My case is a Bitfenix Phenom Micro ATX, so i'm not able to stuff the case with tons of hard disks. (Phenom Micro-ATX can be outfitted with up to five 3.5" HDDs or six 2.5" SSDs.). I will not be storing critical data on the NAS, most of it will be media, so running everything in a RAIDZ setup (meaning that if 2 disks will fail I will loose everything, is a risk i'm willing to take)"

En:

1. If 3x4tb in RAIDZ is really not the way to go, what setup should i use? Maybe4x4TB in RAIDZ2?
2. Reading mixed stories bout running ZIL/L2ARC on the same SSD. Is it safe to run ZIL/L2ARC on the same SSD?

[Bigs]

Als je backups maakt zit je altijd goed

[Xudonax]

Even compleet off-topic, maar die Bitfenix Prodigy M ziet er tof uit! Ik zit zelf met mijn NAS in een "gewone" Bitfenix Prodigy, maar die M is leuk om mijn "droom X79 systeem" in/op te bouwen

[FREAKJAM]

Hij is nu een tijdje officieel leverbaar Ik heb trouwens de opvolger van de Phenom, de Phenom Micro ATX een maand geleden in pre-order geplaatst bij casekings.de en hij is vandaag verstuurd. Ik had in eerste instantie de Prodigy M besteld, maar toen een week later de nieuwe Phenom was aangekondigd had ik mijn keuze snel gemaakt. Vond de Phenom M toch net iets mooier plus hij kan net iets meer storage kwijt.

[ Voor 44% gewijzigd door FREAKJAM op 22-10-2013 12:19 ]

[FireDrunk]

FREAKJAM schreef op dinsdag 22 oktober 2013 @ 10:25:
Zou iemand mijn volgende post op het freenas forum willen doorlezen en mijn zfs vragen kunnen beantwoorden?

Ik ben van plan 3x4tb (WD Red WD40EFRX) te gebruiken in een RAIDZ opstelling, maar ben er niet zeker van of dat wel de juiste keuze is.

"I'm aware that running 3 disks of 4TB is not the best/safest option. I want to run RAIDZ. My case is a Bitfenix Phenom Micro ATX, so i'm not able to stuff the case with tons of hard disks. (Phenom Micro-ATX can be outfitted with up to five 3.5" HDDs or six 2.5" SSDs.). I will not be storing critical data on the NAS, most of it will be media, so running everything in a RAIDZ setup (meaning that if 2 disks will fail I will loose everything, is a risk i'm willing to take)"

En:

1. If 3x4tb in RAIDZ is really not the way to go, what setup should i use? Maybe4x4TB in RAIDZ2?
2. Reading mixed stories bout running ZIL/L2ARC on the same SSD. Is it safe to run ZIL/L2ARC on the same SSD?

1) Dat verhaal met die seagate schijven heeft te maken met de Expander, niet met de LSI controller. SATA achter Expanders is altijd giswerk.
2) De xTB disk vs xGB RAM regel is onzin, die geld alleen bij *enterprises*. Ik heb hier 16TB op 8GB RAM in mijn NAS en dat werkt prima.
3) ZIL en L2ARC kunnen prima op dezelfde SSD, kost een klein beetje performance, maar het werkt prima.
4) Aantal NIC's is maar wat je denkt nodig te hebben.. Als je pfSense gaat draaien lijkt mij dat 2 wel handig is?
5) Geen dedicated GPU, en maar 3*4TB en je dan afvragen of dat met 360W kan, dat kan zelfs nog met een flinke PicoPSU

[FREAKJAM]

Thanks FireDrunk, like always

1) Als jij een model harddrive zou adviseren, welke zou jij me dan op dit moment adviseren?
2) Ik wou 8GB in eerste instantie reserveren voor ZFS. Moet lukken dan.
3) Duidelijk
4) 2 NICS idd handig. NIC 1 voor WAN, NIC 2 voor LAN.
5) Duidelijk

Welke hdd-setup in welke raid-vorm zou jij me aanraden als je rekening houdt met het feit dat ik waarschijnlijk maar 5 schijven max kwijt kan?

[Dadona]

Je wil RAIDZ draaien, beseft dat er dan maar één mag wegvallen en wil het risico nemen. En vervolgens vraag je of je toch niet RAIDZ2 moet draaien. Mja...

Of RAIDZ op zich afdoende is hangt een beetje van je manier van werken af. De waarde van de data op zich valt blijkbaar wel een beetje mee. Ik heb een tijd lang, in een soortgelijke situatie, RAIDZ echt alleen als een vangnet gebruikt. Meestal leven schijven wel een tijdje, hoewel er altijd eentje voortijdig ermee kan stoppen. De extra schijf (voor RAIDZ2) heb ik dan ook niet aangeschaft, maar het geld in gedachten gereserveerd.
Het geld zou ik dan in een nieuwe array steken (die afhankelijk van de tussenliggende periode) relatief goedkoop zou kunnen uitvallen (grotere schijven / prijsdaling). De data zou ik dan simpelweg kopiëren en geen tijd verknallen met resilver acties.

En voor de belangrijkere data kies ik niet voor redundante schijven, maar redundante opstellingen. Dus twee schijven in 'raid0' en dan nog een keer twee schijven in 'raid0' in een andere machine.

[FREAKJAM]

Ik weet dat RAIDZ2 gewoon beter is, maar stiekem is het toch weer een extra investering om een extra schijf aan te schaffen die je netto niet kunt gebruiken. Drie keer 4TB in RAIDZ of 4 keer 4TB in RAIDZ2 geeft beiden netto net zoveel data (8TB), vandaar

Ik vraag me af of het dan niet "overkill" is om 4 schijven in RAIDZ2 te draaien als je niet te maken hebt met critical data (lees films en series).

[ Voor 23% gewijzigd door FREAKJAM op 22-10-2013 12:58 ]

[Dadona]

RAIDZ is ook al een investering die je netto niet kunt gebruiken. Het gaat om het risico en voor mij zou RAIDZ2 met vier schijven overkill zijn.

[ Voor 23% gewijzigd door Dadona op 22-10-2013 13:04 ]

[matty___]

Misschien wel leuk om al vast te zien wat er voor leuks in FreeBSD 10 te wachten staat. Kwam dit net tegen op de current mailinglist (http://svnweb.freebsd.org/changeset/base/256880):

Merge GEOM direct dispatch changes from the projects/camlock branch.

When safety requirements are met, it allows to avoid passing I/O requests
to GEOM g_up/g_down thread, executing them directly in the caller context.
That allows to avoid CPU bottlenecks in g_up/g_down threads, plus avoid
several context switches per I/O.

[hoop technische uitleg]

This change more then twice increases peak block storage performance on
systems with manu CPUs, together with earlier CAM locking changes reaching
more then 1 million IOPS (512 byte raw reads from 16 SATA SSDs on 4 HBAs to
256 user-level threads).

[base_]

RAID is geen backup, het verhoogt alleen de beschikbaarheid. Voor niet kritische data is RAIDZ2 op 4 hdd's overkill, vooral omdat je zowiezo een aparte backup moet maken.

[FREAKJAM]

Dan hou ik het lekker bij RAIDZ1. Ik ga een oudere 2TB harddrive wellicht alleen gebruiken voor mijn ESXi snapshots van mijn andere VM's.

Dank voor de snelle reacties.

[Geckx]

Iemand die al een oplossing heeft voor de foute weergave in opslagcapaciteit als je zfsguru mapped als netwerkschijf?



Totaal aan opslag moet eerder rond de 12TB liggen (6x3TB in RAIDZ2) en er staat ongeveer voor 3TB aan data op dus dat hij volledig leeg is klopt natuurlijk ook niet..

[Verwijderd]

Klopt opzich wel, omdat je je data in sub-filesystems hebt. Je kunt met een smb.conf variabele (custom command) wel de gerapporteerde diskspace aanpassen, dat heb ik zelf nog niet geprobeerd.

Kijk ook maar hoe ZFS je datagebruik rapporteert. Je ziet dat het filesystem wat je hebt gedeeld bijna niets in gebruik heeft, hooguit REFER. De gebruikte data wordt gerekend onder de sub-filesystems.

[Geckx]

Klopt. Wat zfsguru als "Avail" bestempeld is wat windows uitleest.
Bij "Refer" geeft zfsguru wel mooi weer wat er opgeslagen is.

Jammer dat dit niet eenvoudig in te stellen is dat hij de subfilesystems gewoon optelt en een totaal kan weergeven in de vorm van xxx / xxx.

In dit geval is de 8.21TB dus wel correct in de zin van "wat er overschiet als vrije ruimte", enkel het totaal moet aangepast worden.

[ Voor 8% gewijzigd door Geckx op 22-10-2013 19:03 ]

[Verwijderd]

Kun je deze suggestie eens proberen:
http://stanislavs.org/rep...samba-shared-zfs-volumes/

Als je hulp nodig hebt graag via DM.

[Durandal]

Bigs schreef op dinsdag 22 oktober 2013 @ 11:08:
Als je backups maakt zit je altijd goed

Dat is altijd zo'n dooddoener.
We kennen allemaal de waarde van backups, maar vaak is backups maken gewoon niet mogelijk. Ik zou b.v. niet weten waar/hoe ik mijn media bibliotheek zou moeten backuppen. Kan het moeilijk op een usb stickie zetten.
RaidZ2, and that's it.

Onvervangbare data wordt uiteraard wel gebackupped.

[]Byte[]

FireDrunk schreef op dinsdag 22 oktober 2013 @ 12:28:
[...] Als je pfSense gaat draaien lijkt mij dat 2 wel handig is?

Hangt een beetje af van wat je belasting gaat doen.
Ga je je NAS in een eigen VLAN proppen, is 2 zeker geen overbodige luxe.
Zelf heb ik er 3 NIC's in zitten in 1 LAGG-trunk. Alles is geconfigureerd in VLAN's (2 * WAN en 7 interne VLAN's)
Je moet dan natuurlijk wel een manageble switch hebben waarmee je VLAN's kan maken.
Heb je 1 WAN en 1 LAN zou je in principe voldoende moeten kunnen volstaan met 1 NIC. (tenzij je een hi-speed internetaansluiting hebt (van bijv. Wisper.nl) van 600 Mbit+)

[]Byte[]

Durandal schreef op woensdag 23 oktober 2013 @ 03:07:
[...]
We kennen allemaal de waarde van backups, maar vaak is backups maken gewoon niet mogelijk. Ik zou b.v. niet weten waar/hoe ik mijn media bibliotheek zou moeten backuppen.
[...]
Onvervangbare data wordt uiteraard wel gebackupped.

Het is niet alleen de vraag hoe te backuppen, maar vooral ook hoe terug te krijgen!
Backuppen om het backuppen, zonder daar een goede restore tegenover te zetten is kansloos.
In principe is alles te backuppen.
Verder heb je ook nog een kosten aspect. Externe backups op bijv. tape zijn exponentieel duurder dan 'gewoon online' op disk laten staan.
Ik zeg altijd maar zo, het internet is de grootste backup die je kan hebben.
Je moet wat dat betreft alleen de 'onvervangbare data' extra veilig te stellen.

Ik wacht nu alleen nog op mijn twee M1015's die morgen binnen komen en dan kan ik mijn doosje verder in elkaar zetten en afbouwen.
Vandaag ook een MB en 10 WD's gehaald die straks netjes in een RAID-Z2 gaan.
Mijn oude QNAP's gaan als extra back-up fungeren.
Eentje gaat er extern. (een kleine 15 km hemelsbreed vanaf mijn woonplaats)
Hij heeft glasvezel in zijn meterkast liggen en heeft wat dat betreft bandbreedte voldoende.
De bulk sync doe ik hier, en de rest gaat via een VPN naar de andere QNAP.

[GioStyle]

GioStyle schreef op vrijdag 04 oktober 2013 @ 21:49:
Wat kan je verwachten van een raidz2 (6x 3TB), 4GB geheugen, realtek nic qua reads/writes met een CIFS share? Ik haal 45MB/s write en 55MB/s read. CPU-load staat tijdens tranfers op 1.0, wat volgens mij inhoudt single core op 100% load. Klopt dit? Dan betekent het ook gelijk dat het niet sneller gaat tenzij ik de processor vervang?

Als ik dd gebruik dan haal ik rond de 315 MB/s write en rond de 290 MB/s read.

Alles werkt behalve wanneer ik veel data ga overpompen, op een gegeven moment kapt de realtek nic er mee. NAS wordt onbereikbaar, heen foutmeldingen, console blijft aanspreekbaar, nic uit en dan weer aanzetten reset het probleem. Zijn realtek nics gewoon bagger of kan het ergens anders aan liggen?

Ik gebruik trouwens FreeNAS, laatste versie.

[0xDEADBEEF]

GioStyle schreef op donderdag 24 oktober 2013 @ 00:02:
[...]


Alles werkt behalve wanneer ik veel data ga overpompen, op een gegeven moment kapt de realtek nic er mee. NAS wordt onbereikbaar, heen foutmeldingen, console blijft aanspreekbaar, nic uit en dan weer aanzetten reset het probleem. Zijn realtek nics gewoon bagger of kan het ergens anders aan liggen?

Ik gebruik trouwens FreeNAS, laatste versie.

Als je een vrij PCI-e-slot over hebt zou ik er een gigabit-kaartje in stoppen: http://tweakers.net/categ...xNkXQYmlqaAWUNLc3NgdK1tQA

[base_]

Durandal schreef op woensdag 23 oktober 2013 @ 03:07:
[...]

Dat is altijd zo'n dooddoener.
We kennen allemaal de waarde van backups, maar vaak is backups maken gewoon niet mogelijk. Ik zou b.v. niet weten waar/hoe ik mijn media bibliotheek zou moeten backuppen. Kan het moeilijk op een usb stickie zetten.
RaidZ2, and that's it.

Onvervangbare data wordt uiteraard wel gebackupped.

Ok laat ik even kort door de bocht gaan: belangrijke data MOET je zowiezo backuppen, en wat betreft storage op welke RAID dan ook: de inhoud kan met 1 verkeerde actie van hardware, software of gebruiker gewoon direct kwijt zijn. Een backup kan altijd, en wat betreft veiligheid van je data kan je beter geen RAID (of zelfs RAID-0) storage draaien i.c.m. met een goede backup als welke RAID met parity/mirror zonder backup. Voor kritische data raad ik zelfs een backup met archivering/versioning aan.... RaidZ2 klinkt leuk maar zorg dan in ieder geval voor ECC geheugen en een UPS met fatsoenlijke power shutdown (en SSD's met powerfail buffer indien je SSD's gebruikt) als je data je lief is zonder backup...

[Verwijderd]

RaidZ2 klinkt leuk maar zorg dan in ieder geval voor ECC geheugen en een UPS met fatsoenlijke power shutdown (en SSD's met powerfail-safe buffer capacitors indien je SSD's gebruikt)

Om tegen welke gevaren te beschermen precies?

[Dadona]

Los van dat het wat ongedefinieerd is snap ik de, vermoedelijke, strekking wel. Met RAIDZ2 investeer je meer geld in redundantie op het vlak van schijven, terwijl je nog altijd op de andere vlakken geen 'redundantie' hebt ingevoerd.
Een reden dat RAID niet hetzelfde is als een backup is omdat je daarvoor echt naar een volledig redundante opstelling moet gaan. Je kunt snapshots enz. maken om tegen je eigen fouten te beschermen. Maar dan nog heb je een probleem als de voeding ermee stopt en in de val wat meeneemt. Je hebt nog steeds een probleem als de SSD een kritieke positie inneemt en je je daar totaal niet tegen beschermt (geen super cap). Enz.
RAID is een investering in één enkel type hardware, dat wellicht de hoogste kans op falen heeft. Maar met RAIDZ is de kans inmiddels, mogelijk, teruggezakt naar een niveau dat al onder het kans niveau van andere componenten is gevallen.

[Kortfragje]

Het verhaal over ECC en UPS heeft mijn aandacht getrokken en hopelijk kan ik het enigszins samenvatten hier...

In principe is het zo dat er in een UFS / NTFS gebaseerd file system corruptie / falen op kan treden op verschillende niveaus (gezien en ongezien). Met name : 1 HDD, 2 HDD <-> Mobo connectie , 3 RAM. Sommige problemen zijn te spotten (bijv dmv SMART errors) terwijl anderen onzichtbaar zijn (bit rot).

ZFS zou in theorie het falen op niveau 1 en 2 op moeten vangen, en in het geval van ECC ram ook op niveau 3.

Op het Freenas forum is een discussie ( hier ) aan de gang waar mensen het erover hebben dat ze complete pools kwijt geraakt zijn door corruptie in RAM en / of unexpected power failure. De link tussen power failure en pool corruptie is mij nog niet duidelijk echter. Deze publicatie wordt steeds aangehaald als de onderbouwing waarom ECC noodzakelijk zou zijn.

Hoewel de kans klein is vertekent dat het beeld wel enorm. Indien je geen ECC gebruikt zou het gebruik van ZFS de absolute kans op corruptie enorm verminderen (niveau 1 en 2), maar de impact van corruptie (niveau 3) afgezet tegen de impact bij single disk storage enorm verhogen (dan verlies je slechts een aantal files).

Mijn vraag is dan ook is dit echt zo, loop je een dergelijk risico bij het niet gebruiken van ECC?

If so, wat zou een goed ECC compatible setje van moederbord + CPU zijn?

[Habana]

Grappig, het gaat van dooddoener naar ECC geheugen, wat er enkel voor zorgt dat fout weggeschreven bitjes worden gecorrigeerd, uiteindelijk is en blijft het de vraag hoeveel denk je te willen investeren in het veilig stellen van je data, wat zeer zeker geen dooddoener is.

[jadjong]

ECC zie ik alleen voordeel bij wanneer er 100 clients aan een fileserver hangen. Dan kan het falen van een enkel onderdeel problemen geven bij 100 gebruikers. Thuis is de verhouding server:client vaak niet meer dan 1:4. Dan is het nuttiger om overal ECC toe te passen, als je daar geld voor over hebt.

[Bigs]

Ik zou niet zeggen dat je een acuut risico loopt als je geen ECC gebruikt, maar het verkleint de kans op corruptie door geheugenfouten wel. Het neemt echter niet 100% van de fouten weg zoals hier eerder ook al gezegd werd.

Hoe een complete pool zou kunnen verdwijnen door een geheugenfout is mij niet duidelijk, dat wordt in die thread ook niet toegelicht. Er zijn natuurlijk altijd complexe hardware fouten die zoiets kunnen veroorzaken en je kunt er niet vanuit gaan dat je met ECC ineens veilig bent want er zijn nog veel meer factoren die meespelen.

[Kortfragje]

Eens, het blijft een kansspelletje, de kansen veranderen echter nogal als je je hele pool kwijt kan raken (nogmaals geen idee of dit reeel is..).

Maar om iets constructiefs toe te voegen aan de ecc discussie:

End-to-end Data Integrity for File Systems: A ZFS Case Study
http://research.cs.wisc.e...zfs-corruption-fast10.pdf


5 In-memory data integrity in ZFS
In the last section we showed the robustness of ZFS to disk corruptions. Although ZFS was not specifically designed to tolerate memory corruptions, we still would like to know how ZFS reacts to memory corruptions, i.e., whether ZFS can detect and recover from a single bit flip in data and metadata blocks. Our fault injection experiments indicate that ZFS has no precautions for memory corruptions: bad data blocks are returned to the user or written to disk, file system operations fail, and many times the whole system crashes.
This section is organized as follows. First, we briefly describe ZFS in-memory structures. Then, we discuss the test methodology and workloads we used to conduct the analysis. Finally, we present the experimental results and our observations.

....

In summary, ZFS fails to detect and recover from many corruptions. Checksums in the page cache are not used to protect the integrity of blocks. Therefore, bad data blocks are returned to the user or written to disk. Moreover, corrupted metadata blocks are accessed by ZFS and lead to operation failure and system crashes.

[ Voor 4% gewijzigd door Kortfragje op 24-10-2013 13:09 ]

[Bigs]

Elk file system is gevoelig voor geheugenfouten, ZFS pretendeert ook niet dat het daar beter mee omgaat dan de concurrentie. Het gevaar schuilt volgens sommigen in het feit dat ZFS data automatisch corrigeert aan de hand van de checksum en dan dus foute data wegschrijft naar de disk, maar of dat waar is en hoe dat precies in zijn werk gaat weet ik niet.

Kortfragje schreef op donderdag 24 oktober 2013 @ 13:07:
Eens, het blijft een kansspelletje, de kansen veranderen echter nogal als je je hele pool kwijt kan raken (nogmaals geen idee of dit reeel is..).

[..]

Daarom ben ik wel benieuwd naar een bron die aantoont dat dat reëel is. ZFS slaat alle metadata redundant op dus die raakt niet zomaar corrupt. Ook hier verwacht ik niet dat het risco groter is dan bij andere bestandssystemen.

[Keiichi]

Bigs schreef op donderdag 24 oktober 2013 @ 13:26:
Daarom ben ik wel benieuwd naar een bron die aantoont dat dat reëel is. ZFS slaat alle metadata redundant op dus die raakt niet zomaar corrupt. Ook hier verwacht ik niet dat het risco groter is dan bij andere bestandssystemen.

Als de metadata die gegenereerd wordt corrupt is en naar verschillende plaatsen weggeschreven wordt, heb je overal corrupte data. Lijkt mij dan.

[Kortfragje]

Precies, dat zegt het artikel :

In summary, ZFS fails to detect and recover from many corruptions. Checksums in the page cache are not used to protect the integrity of blocks. Therefore, bad data blocks are returned to the user or written to disk. Moreover, corrupted metadata blocks are accessed by ZFS and lead to operation failure and system crashes.

Maar het blijft kansberekening en koffiedik kijken...

[Bigs]

Keiichi schreef op donderdag 24 oktober 2013 @ 13:33:
[...]


Als de metadata die gegenereerd wordt corrupt is en naar verschillende plaatsen weggeschreven wordt, heb je overal corrupte data. Lijkt mij dan.

Ok helder, maar dat geldt voor elk bestandssysteem toch? Bovendien is de kans op een onbruikbare pool hierdoor wel heel klein.

Afijn, blij dat ik overal ECC geheugen gebruik

[FireDrunk]

Kortfragje schreef op donderdag 24 oktober 2013 @ 13:41:
Precies, dat zegt het artikel :

[...]


Maar het blijft kansberekening en koffiedik kijken...

Uh, je zal de servers die in een datacenter ECC meldingen geven de kost moeten geven. Wij hadden in een DC van 300 bakken toch bijna elke week a 2 weken wel een bak met ECC errors (meestal single bit, maar soms ook multiple bit).

Single bit word gecorrigeerd en daarna gelogd, double bit, is einde verhaal.

De kans dat het bij je thuisserver voorkomt is inderdaad klein, maar als je een heel DC vol hebt, is 1 corrupte ZFS pool per twee weken toch zonde....

[Kortfragje]

Jah ik las ook de volgende statistiek:

http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf
According to this study a DIMM has an 8% chance per year of getting a correctable error.


Let wel, hier betrof het ECC. En de overweging dat dit alleen voorkomt bij schrijven gaat uiteraard niet op als je regelmatig een scrub draait ...

Was toch al van plan nieuwe hardware aan te schaffen en heb nu de volgende hardware besteld (helaas in het VK, dus de keuze in componenten is beperkt om het zacht uit te drukken).

code:

Athlon II X3 450 3.2GHz
ASUS M5A97 LE R2.0 AMD 970 (Socket AM3+) 
Kingston 8 GB KVR1333D3E9S/8G ECC 1333MHz 240-pin Unbuffered DIMM

[ Voor 44% gewijzigd door Kortfragje op 24-10-2013 17:21 . Reden: Statistiek was erg slecht, link naar originele paper ]

[Bigs]

Hmm een processor met Unbuffered ECC geheugen ondersteuning voor € 39. Geen slechte deal

pricewatch: AMD Athlon II X3 450 Boxed

[ Voor 40% gewijzigd door Bigs op 24-10-2013 15:45 ]

[BCC]

Kortfragje schreef op donderdag 24 oktober 2013 @ 15:38:
De overweging dat dit alleen voorkomt bij schrijven gaat uiteraard niet op als je regelmatig een scrub draait ...

Volgens mij mag hij ook een lesje statistiek

[Verwijderd]

Oh jee de ECC discussie weer. Dat wordt weer puinruimen....

Dit doet me veel denken aan de Google-studie, die het grote publiek ook tot verkeerde conclusies aanstuurt. Zo denken veel mensen aan de hand van deze studie dat hardeschijven en hoge temperatuur prima samengaat. Wat ze daarbij vergeten is dat de schijven op continu temperatuur worden gehouden in een datacenter en die situatie totaal niet vergelijkbaar is met de situatie waar consumenten mee te maken krijgen.

Kortfragje schreef op donderdag 24 oktober 2013 @ 13:07:
Maar om iets constructiefs toe te voegen aan de ecc discussie:

End-to-end Data Integrity for File Systems: A ZFS Case Study
http://research.cs.wisc.e...zfs-corruption-fast10.pdf

De titel zegt eigenlijk al genoeg, maar ontgaat vast veel mensen. Het gaat hier niet om het meten van permanente corruptie maar om tijdelijke corruptie die later weer gecorrigeerd kan worden. Kortom, het gaat om het falen van de End-to-End data integrity. Dat verlies je als je geen ECC RAM hebt.

OOK MET NIET-ECC GEHEUGEN KAN ZFS CORRUPTIE CORRIGEREN veroorzaakt door memory bit flips. Dit heb ik persoonlijk getest onder FreeBSD met defecte RAM latjes. Bij het vervangen van het foute RAM met goed RAM en het draaien van een scrub, wordt de corruptie weer gecorrigeerd en zijn de md5-checksums daarna weer in orde.

Dit is iets wat niet wordt geadresseerd in die studie, die eigenlijk alleen over End-to-End data integrity gaat. Dat is voornamelijk belangrijk voor bedrijven, professionele servers die geen fouten kunnen maken. Voor consumenten is het veel minder erg: een artifact tijdens het streamen van een film bijvoorbeeld. Maar de volgende keer is dat weer weg. Het gaat hier dus niet om permanente corruptie.

Permanente corruptie door ECC bitflips blijft mogelijk, vooral in niet-redundante configuraties. Maar de kans is niet zo heel erg groot. Bovendien geldt dit voor defecte RAM-reepjes met tienduizenden fouten in MemTest, laat staan de enkele bitflip zo nu en dan wat normaal is.

Sterker nog. Als je ECC wilt voor je ZFS server, dan betekent dit automatisch dat je ECC op al je desktops/workstations moet nemen want daar is ECC-bescherming veel belangrijker, omdat ZFS van nature al deels beschermd is maar je workstations juist helemaal geen bescherming hebben. Je workstations hebben ECC dus harder nodig dan je ZFS server. Daarom dat ik ooit zei: pas als je workstations allemaal ECC hebben is het ook leuk voor je ZFS server. Maar thuisgebruikers die persé ECC willen en zich anders niet veilig voelen, maken zich eigenlijk druk om niets IMO.

[Dadona]

Misschien handig om de reacties niet zozeer te ruimen, maar in een eigen topic te gooien. Iedere keer steekt het weer voor even even de kop op.

[Kortfragje]

Ah jah, dank voor het antwoord, dat was mijn vraag idd. Dus het corrupt worden van hele pools door dergelijke fouten kan ook naar het rijk der fabelen verwezen worden?

(hoewel het misschien voor een thuisgebruiker overdreven is, wordt ecc in best practices ook aangeraden en mn data is me die 30 pond wel waard )

Misschien iets om te te voegen aan de start post idd als het steeds weer terugkomt? Misschien een korte faq? (begreep dat de vraag over WD res vs WD greens en het disablen van TLER ook steeds terug kwamen?)

[ Voor 68% gewijzigd door Kortfragje op 24-10-2013 21:45 ]

[Habana]

Dadona schreef op donderdag 24 oktober 2013 @ 19:58:
Misschien handig om de reacties niet zozeer te ruimen, maar in een eigen topic te gooien. Iedere keer steekt het weer voor even even de kop op.

haha..Helemaal niet zo erg dat CiPHER moet puinruimen.. hij was zelf begonnen om 11.15uur

[Verwijderd]

Megareply over ZFS + ECC en corruptie

Ik bedoelde met 'puinruimen' niet dat ik reacties zou verwijderen of verplaatsen - ze zijn immers on-topic over ZFS - maar juist dat ik weer dezelfde argumenten moet herhalen als ik al eerder heb gedaan. Die studie is al een paar keer eerder in dit topic aan bod geweest.

Maar natuurlijk zou het in de startpost thuishoren. Nu ga ik die binnenkort herschrijven en nieuwe topics openen, dus het kan nog even wachten hoop ik.

En verder is de discussie ook niet afgerond. De tests die ik heb gedaan zijn ook niet uitgebreid genoeg om er superveel over te zeggen. Maar dat ZFS met een paar RAM bitflips op zijn bek gaat vind ik sterk overtrokken. Een beetje corruptie kan ZFS juist prima hebben.

Nog even wat aanvullingen:

Dus het corrupt worden van hele pools door dergelijke fouten kan ook naar het rijk der fabelen verwezen worden?

Dat vind ik erg moeilijk want het zou zeker theoretisch mogelijk kunnen zijn dat in heel specifieke omstandigheden met (meervoudige?) RAM corruptie je een pool om zeep kunt helpen. Veel aannemelijker is het dat in een zeldzaam geval je een enkele file als corrupt ziet binnen de 'zpool status -v' output en je dus 1 file kwijt bent, afhankelijk van hoeveel redundancy je hebt.

Metadata is nog eens extra beveiligd met copies=2 en beide kopiën hebben ook weer redundantie (RAID-Z123/mirror) dus bij RAID-Z2 heb je minimaal 4 sources van metadata en voor cruciale metadata nog véél meer.

hoewel het misschien voor een thuisgebruiker overdreven is, wordt ecc in best practices ook aangeraden

Als je goedkoop een optie hebt voor ECC geheugen zoals bij het ASRock Avoton bordje wat onlangs in dit topic (of DIY RAID NAS topic) aan bod is gekomen, dan zou ik zelf ook ECC pakken natuurlijk. Het is zeker wel een plus. Eigenlijk zouden alle computersystemen ECC RAM moeten hebben; errorcorrectie wordt immers bijna overal toegepast binnen computertechnologie dus waarom niet voor je RAM? 1/8e of 1/16e meer kosten. Bij SSDs zie je ook dat 1/16e wordt opgeofferd voor RAID4/RAID5 bitcorrectie; dat is de reden dat SSDs als 120GB ipv 128GB en 240GB ipv 256GB worden verkocht (dit staat los van GB versus GiB). Het verschil is precies 1/16e wat voor RAID5 wordt gebruikt. Je hebt dan de opslag van 15 'disks' ofwel NAND dies (een chip of package kan meerdere dies bevatten; meestal 2).

Ik reageer vooral dat ECC bijna als must-have wordt gezien omdat anders je pool op springen staat. Dat is echt niet zo. Maar wil je nog dat extra beetje betrouwbaarheid, wat je nog niet hebt afgedekt, dan is de ECC optie leuk. Vooral als je je workstations ook ECC geeft, omdat zij natuurlijk de data aanleveren aan ZFS. Als ZFS het al corrupt in zijn handen krijgt gaan alle beveiligingen natuurlijk niet werken. Dus ECC op je workstations enzo is zeker wel een overweging. Vooral als je maar één of twee systemen hebt die regelmatig schrijven naar je ZFS NAS.

Overigens zou Kabini (zeg maar de moderne opvolger van AMD Brazos; goedkoop mobo met onboard CPU met laag TDP) ook ECC ondersteunen en zou dus uitstekend zijn voor een low-end instap ZFS NAS met toch extra hoge betrouwbaarheid.

Maar ik heb hier zelf belangrijke data op een systeem zonder ECC en ik maak me er niet druk om. Het leuke is ook: je gaat RAM corruptie merken omdat je onverklaarbaar checksum errors ziet. Die kunnen van je disk komen (zoals de NCQ-write bij Samsung F4EG die zo'n write dan niet uitvoert) maar zeker ook van RAM bitflips.

Dit heb ik dus ondervonden bij mijn tests. Bij een scrub zal door de RAM bit flips een heleboel data gecorrumpeerd worden. Maar van de 4-disk RAID-Z altijd maar op één plaats. Dus bij een volgende scrub met goed geheugen wordt alle corruptie veroorzaakt door RAM bitflips keihard ook weer gecorrigeerd. Dus een enkele bitflip ben ik niet zo heel bang voor.

Wel is het zo, dat een fout tijdens het maken van de checksum problematisch is. Je file zou dan onafhankelijk van redundancy altijd als corrupt worden aangemerkt, terwijl eigenlijk alleen de checksum corrupt is. Maar dan zie je dus keihard een corrupte file in zpool status -v. En dat is ook zo fijn van ZFS: als er problemen zijn met je disks of systeem of RAM dan merk je dat in de output. Alle corruptie wordt vroeg of laat ontdekt. En de corruptie blijft vrijwel altijd beperkt tot enkele bestanden. Het feit dat je weet om welke bestanden het gaat maakt ook dat je je er fijner door voelt. Silent corruption en oh kut opeens mn trouw-fotoalbum corrupt, dat wil je niet meemaken. Maar daar heb je natuurlijk ook backups voor.

Maar wat nu als die silent corruption keihard doorstroomt naar je backup? Ah ha... dacht je goed voor elkaar te hebben met je backup en RAID5 maar dan nog keihard corrupt. Daarom draai je dus ZFS! Weten wanneer corruptie optreedt is superhandig. Zo kun je bij corruptie eens een MemTest cycle draaien om er achter te komen dat je RAM opeens corrupt is. Dat komt zeker voor bij anderen en ook bij mijzelf.

Ok helder, maar dat geldt voor elk bestandssysteem toch?

Nee. Andere filesystems gebruiken vrijwel geen RAM. Ze hebben RAM nodig voor read-ahead (8*16/32/64K meestal) en een kleine write buffer (enkele megabytes) en command queue en nog wat filesystem-specifieke meuk. Je kunt 1e en 2e generatie filesystems (alles behalve ZFS/Btrfs/ReFS) gebruiken op systemen met superweinig RAM, zoals 64MB ofzo.

Maar indirect is het verbruik hoger: de VFS (Virtual FileSystem) laag van het operating system wat swap en filesystem cache aanstuurt, verbruikt meer dan het filesystem zelf. Dit kan zo groot groeien als de grootte van de RAM. Een 128GB bestand inlezen op een systeem met 128GB geheugen zal ervoor zorgen dat vrijwel al het geheugen in gebruik is, voornamelijk met (delen van) dat bestand dus.

Bij ZFS ligt het heel anders. ZFS heeft zijn eigen cache-infrastructuur; de ARC (Adaptive Replacement Cache). Adaptive omdat het zich aanpast aan de workload, dus het probeert slim te zijn en de belangrijkste data voor zowel korte als lange termijn in de cache te houden. Replacement Cache omdat het de traditionele VFS-laag vervangt en dus buiten deze laag om werkt. Of althans het deelt niet de reguliere cache-infrastructuur die gebruikt wordt bij traditionele filesystems (FAT/NTFS/Ext2/3/4/UFS/HFS).

Mijn (concluderende) reactie op jouw quote is dus: ZFS verbruikt (direct) véél meer RAM dan andere filesystems, dus het heeft ook een hogere kans op het 'vangen' van RAM bitrot. Dat is best fijn eigenlijk, want zo bescherm je dus 50-90% van je RAM gedeeltelijk tegen de zeldzame RAM bitflip. Dan zie je bij een scrub ooit een keer dat er een checksum error is op een willekeurige disk zonder verklaring.

Desktopsystemen zoals Windows hebben bij RAM bitflips een hogere kans om appliaties te laten crashen, en bijvoorbeeld blauwe schermen te veroorzaken. Bij servers met ZFS is het vooral ZFS die de RAM bitflips opvangt, ipv de appliaties.

[base_]

Kan en doet ZFS bij een checksum error bepalen of dit een geheugen error of een disk error is? Ik kan me voorstellen dat e.e.a. opnieuw gelezen wordt maar als dit in hetzelfde (misschien defecte) geheugengebied geladen wordt dit niet veel zal oplossen.

[FireDrunk]

Een bitflip in geheugen wordt zonder ECC niet opgemerkt, bij het verifieren van de checksum (voor/na disk activiteit) weet ZFS dus nooit waar het vandaan komt. ZFS zal het corrigeren en melden, maar geen actie ondernemen.

Als elke applicatie zich gaat bemoeien met wat er moet gebeuren als er hardware fouten zijn, zijn we ver van huis als er iets mis gaat dunkt me.

(Overigens is een bitflip niets anders dan een 0 die een 1 wordt of een 1 die een 0 wordt. ZFS kan daarom nooit zien wat er precies mis gaat...)

@CiPHER:

Ik ben het op zich eens met je post, maar wat nog niet genoemd is, is dat de bitflip ook in programma code kan komen. Neem bijvoorbeeld een paar functies van de ZPL laag. Als daar op het verkeerde moment een bitflip in komt, kan je pool zeker wel kapot gaan. Er staat vast in een aantal functies dat de vaste recordsize 128K moet zijn, stel dat er in de Integer die dat getal vasthoudt een bitflip gebeurd, en het getal wordt opeens 96K.

Dan gaat er een hoop stuk...

Ik ben het helemaal met je eens, maar er is meer in je geheugen dan alleen data, er is ook nog zoiets als programma code.