Het grote ZFS topic

[damanseb]

Eagleman7 schreef op donderdag 28 november 2013 @ 20:32:
Ik moet zelf even testen wat er dan het beste werkt voor mijn situatie, thanks voor de info

Krijg ik nog problemen met deze kabels en de raid controller, of gaat dit gewoon werken?

Als je met een ZFS SAN opzet aan de gang wilt zorg dan dat je controller gewoon passthru/jbod ondersteund.. (deze zijn vaak nog goedkoper ook dan controllers met raid firmware)
ZFS houd niet van hardware raid omdat je met hardware raid een tussenlaag creert waar ZFS geen invloed op heeft..
ZFS voorziet zelf in failover/data integriteit d.m.v. raidzX of mirror met checksums en om dit dubbel uit te voeren door het boven op een hardware raid te zetten werkt enkel nadelig..
Voer je pool gewoon raw devices en ZFS weet er wel raad mee.

[damanseb]

Durandal schreef op woensdag 27 november 2013 @ 13:17:
Wat is er mis met dd-wrt?
Je kan toch gewoon ftp.server(.lan) en cloud.server(.lan) voor je verschillende virtuele machines gebruiken als je dat wil. Niet eens een domein naam nodig.

Hoe los je trouwens 2 FTP servers op dezelfde poort op verschillende virtuele machines op, als ze hetzelfde IP hebben?

/Offtopic
Als je de mogelijkheid hebt tot glasvezel..
Voor mijn KPN glasvezel aansluiting (alles-in-een) 100mbit betaal ik momenteel 68 euro per maand.
Als mijn contract is afgelopen stap ik over op een zakelijke provider waarbij ik voor een tientje meer per maand (78 euro) dezelfde mogelijkheden (tv, telefoon, internet) heb PLUS een complete router met een subnetje van 8 IP adressen.. (weg met die achterlijke experia meuk, yay!)
Probleem opgelost

Zoniet.. Niet.. Beter slechts een FTP server draaien en binnen het onderliggende OS remote locaties mounten (nfs/cifs/whatever) en e.v.t. deze diverse locaties aanbieden op basis van logins..
Ja, ja.. vroegah dumpsites gedraait voor 0day FXPers, wat een gekloot met NAT was dat
Een en dezelfde FTP server met verschillende (virtuele) home directories werkt dan het beste, eindgebruiker merkt het verschil niet..

BTW, sorry voor de ketting aan posts, ben normaal niet zo'n kletskous maar hoop er mee iemand tot dienst te kunnen zijn..

[ Voor 23% gewijzigd door damanseb op 28-11-2013 22:57 ]

[Mystic Spirit]

Ik ben nog wat aan het herinrichten met ZFSguru en heb wat nieuwe filesystems gemaakt om daar files uit andere filesystems heen te verplaatsen. Nu heb ik er een aantal acties op zitten door te verplaatsen, maar wat opvalt is dat het vrij lang duurt. Is een move van het ene filesystem naar de ander op dezelfde pool geen aanpassing van links naar de files, maar een echte verplaatsing? Daar lijkt het wel op als ik kijk naar hoe lang het duurt.

Verder vroeg ik mij nog af of ik compressie voor een bepaald filesystem achteraf aan kan zetten en er dan automatisch een actie plaatsvindt om alle data die al in het filesystem staat te comprimeren. Of moet ik daar een handmatige actie voor doen?

[Neptunus]

damanseb schreef op donderdag 28 november 2013 @ 21:20:
[...]

Hiervoor heb ik een HOWTO bijgehouden en ben meer dan bereid deze te delen als iemand interesse heeft..

Kom maar op!

[Verwijderd]

Mystic Spirit:

Filesystems in ZFS werken ongeveer zoals drive letters bij Windows. Stel je hebt een hardeschijf met twee partities C: en D: en je verplaatst bestanden van C: naar D: toe. In dat geval moet het bestand daadwerkelijk worden gelezen en geschreven, ook al bevindt deze zich op dezelfde schijf. Hij wordt naar een andere LBA locatie (partitie-ruimte) geschreven en daarna wordt de oude locatie dereferenced.

Verplaats je bestanden binnen een filesystem, dan gaat het wel snel omdat alleen de verwijzing wordt aangepast maar de data zelf blijft staan waar hij is.

Nu een leuke truc: stel je hebt een Samba share op Windows genaamd X: en in werkelijkheid is dat ZFS filesystem tank/share. Nou heb je binnen de 'share' filesystem nog meer filesystems, zoals tank/share/download en tank/share/belangrijk. Vanuit Windows gezien heb je gewoon een X: en daarin zie je mapjes download en belangrijk staan. Zou je nu van mapje download naar mapje belangrijk verplaatsen, dan stuur je dit als commando naar de ZFS server. Het verplaatsen kost dan tijd omdat je van filesystem A naar filesystem B gaat verplaatsen. Echter, dit gebeurt wel op de server! Je doet dit dus wel tegen maximale lokale performance; de data gaat in dit geval niet via de gigabit server. Dit werkt alleen als je verplaatst binnen dezelfde Samba-share en je binnen die share dus verschillende filesystems hebt.

Tot slot: compressie, copies=2, dedupe en andere attributen worden pas actief voor nieuw geschreven data. Bestaande data wordt niet aangepast. Wil je bestaande data comprimmeren, dan zul je het mapje moeten kopiëren en dan de oude locatie verwijderen. Zoals:
zfs create tank/newshare
zfs set compression=lz4 tank/newshare
cp -Rp /tank/share/* /tank/newshare/
zfs destroy tank/share
zfs rename tank/newshare tank/share

Bovenstaand voorbeeld maakt /tank/newshare aan en verplaatst alles van /tank/share naar /tank/newshare en daarna wordt newshare weer share en gooi je de oude bestanden weg.

[EnerQi]

Mystic Spirit schreef op vrijdag 29 november 2013 @ 08:08:
Verder vroeg ik mij nog af of ik compressie voor een bepaald filesystem achteraf aan kan zetten en er dan automatisch een actie plaatsvindt om alle data die al in het filesystem staat te comprimeren. Of moet ik daar een handmatige actie voor doen?

Compressie werkt alleen bij nieuwe files. Om 'm te laten werken op bestaande data zul je een copy/past actie moeten uitvoeren (verplaatsen van bestanden )

[Eagleman7]

damanseb schreef op donderdag 28 november 2013 @ 22:14:
[...]


Als je met een ZFS SAN opzet aan de gang wilt zorg dan dat je controller gewoon passthru/jbod ondersteund.. (deze zijn vaak nog goedkoper ook dan controllers met raid firmware)
ZFS houd niet van hardware raid omdat je met hardware raid een tussenlaag creert waar ZFS geen invloed op heeft..
ZFS voorziet zelf in failover/data integriteit d.m.v. raidzX of mirror met checksums en om dit dubbel uit te voeren door het boven op een hardware raid te zetten werkt enkel nadelig..
Voer je pool gewoon raw devices en ZFS weet er wel raad mee.

Klopt

Ik had al het een en ander gelezen over ZFS.

Dus die specifieke kabels en de IBM M1015 (wordt geflashed naar IT Mode) gaan dus geen problemen geven?

Welke raid/hba controller gebruik jij?

[Mystic Spirit]

Geeft weer een stukje inzicht. Het verplaatsen deed ik gelukkig gewoon met het commando move, dus ging idd tegen maximale interne performance. Voor de hoeveelheid data was het vlot, maar toch lang in vergelijking met een verplaatsing binnen een filesystem.

Ik ga dan nu nog even een filesystem aanmaken met compressie om te kijken hoeveel voordeel ik daaruit kan halen. Ik ga daarbij voor de standaard g-zip (6) compressie.

Is het eigenlijk mogelijk om een filesystem te renamen? Ik kan een filesystem wel ergens mounten zie ik, maar renamen heb ik volgens mij geen opties voor.

[Verwijderd]

zfs rename tank/share tank/sharerenamed

[Mystic Spirit]

Dat scheelt dan kan ik mijn grootste directory in dit filesystem laten staan en deze renamen. Scheelt toch weer wat kopieertijd!

[joopworst]

Neptunus schreef op vrijdag 29 november 2013 @ 08:28:
[...]


Kom maar op!

Ik wil m ook graag zien! Ga zelf ook ZFS server bouwen met 10GbE. Ik kan door het aanbod van OSen de bomen door het bos niet meer zien. Met Linux ben ik het meest vertrouwt.

[FireDrunk]

@Damanseb, Heb je ook concrete resultaten van die verschillen met zfs_prefetch uit en aan? Ben wel benieuwd

Weet iemand of dit ook effect heeft op VDEV cache? of werkt dat weer op een andere laag?

[ Voor 5% gewijzigd door FireDrunk op 29-11-2013 10:56 ]

[darth.75]

darth.75 schreef op woensdag 20 november 2013 @ 17:04:
Weet niet of ik hier moet zijn of in het DIY RAID NAS topic, dus als ik verkeerd zit, graag verplaatsen

Ik heb de afgelopen 2 weken het hele topic van voor tot achter doorgelezen, maar heb nog wat vragen:

Ik heb nu een WHS met 4 schijven:

• 320 GB (512B sectors)
• 640 GB (512B sectors)
• 1,5 TB en (512B sectors)
• 2 TB (4kB sectors)

Zitten in een grote pool van zo'n 4 TB, waarvan ik (inclusief folder duplication) zo'n 2,5 TB gebruik (vooral films, muziek enzo, maar ook wat kostbaarder bestanden als foto's en homevids). Ik wil overstappen naar een ZFS systeem (waarschijnlijk FreeNAS) en daarbij zo min mogelijk investeren, maar wel maximale veiligheid en een interessant upgrade pad. Ik denk nu aan het volgende:

Pool 1 = 8 GB USB stick met OS
Pool 2 = Datatank met 640 en 1,5 TB in mirror (640 GB effectief) + 2x 3TB disk + 1x 2 TB disk in Z1 (4 TB effectief)
Pool 3 = Downloadpool met 320 GB in stripe

Ik wil daarmee het volgende bereiken:

• Op termijn de 2 TB in de Z1 pool vervangen door een ander 3 TB exemplaar. De 2 TB kan dan naar de mirror en de 640 kan dan de downloadschijf worden.
• Een aparte downloadpool, zodat de grote datatank kan downspinnen als ik 's nachts download.
• Een aparte downloadpool, zodat als de schijf crasht de rest van mijn data niet geraakt wordt.
• Installatie van Sabnzbd, CouchPotato e.d op de USB stick.

Ik vraag mij af of mijn denkrichting een beetje klopt. Zo ja, dan wil ik op een oude laptop iets vergelijkbaar in elkaar knutselen (maar dan met partities), zodat ik wat kan testen. Bevalt alles dan is de volgende stap het kopen van hardware. Zie ik nog iets over het hoofd?

niemand?

[mkroes]

De complete configuratie van het OS tot Multi Path IO op iSCSI niveau..
Hiervoor heb ik een HOWTO bijgehouden en ben meer dan bereid deze te delen als iemand interesse heeft..

Laat maar eens lezen, ben wel benieuwd.. Ik ben nog steeds aan het kl....en met ongeveer een zelfde setup alleen dan hyper-v.

[Mystic Spirit]

darth.75 schreef op vrijdag 29 november 2013 @ 19:33:
[...]


niemand?

Je denk richting is goed. Eventueel kun je ervoor kiezen zoveel mogelijk van de 1,5+ TB schijven in een RAIDZ1 pool te zetten en overgebleven ruimte te gebruiken om partities met kleinere schijven te mirroren. Kost je wel performance in het begin, maar je houdt er meer effectieve ruimte van over.

[syl765]

@dart.75

Je kunt het beste een pool opbouwen met dezelfde vdev configuratie.
Dus of een pool met mirrors, of een pool bestaande uit vdev's met raidz(x)

Het mixen van verschillende vdev configuratie's gaat ten kosten van je performance.

Gr
Johan

[damanseb]

FireDrunk schreef op vrijdag 29 november 2013 @ 10:56:
@Damanseb, Heb je ook concrete resultaten van die verschillen met zfs_prefetch uit en aan? Ben wel benieuwd

Weet iemand of dit ook effect heeft op VDEV cache? of werkt dat weer op een andere laag?

Nee sorry, ik heb die benchmarks wel gedraait maar niet bijgehouden..
Wat ik me zo kan herinneren was 30% minder sequentieel voor 10% tot 15% meer random..

Ik zag eerst vrij hoge sequentiele waardes, waarschijnlijk omdat ik met mirrors werk.
Maar voor virtuele machines hecht ik meer waarde aan random dan sequentieel dus ik was wel bereid om op sequentieel in te leveren..

De instelling zelf zegt al een beetje wat het doet: prefetch
(als anticipatie op sequentieel lezen alvast de opvolgende blocks inlezen)
Uiteraard gaat dit ten koste van je bandbreedte als je slechts dat enkele (random) blockje wil uitlezen.

Voor zover ik weet is de prefetch instelling alleen van toepassing op je data vdevs. (hdds)
Instellingen gerelateerd aan L2ARC beginnen vaak ook met l2arc_<instelling>

@hier onder: ah ok, nee sorry, ben ik niet mee bekend verder dan wat ik hierboven reeds heb vermeld..

[ Voor 12% gewijzigd door damanseb op 29-11-2013 22:25 ]

[FireDrunk]

De tweede vraag was ook meer in het algemeen, en niet specifiek voor jou

VDEV cache is een soort readahead die per vdev geld, daarmee kan je zorgen dat er meer data in 1 keer van een disk opgevraagd word. Goed voor sequentiele snelheden, wat slechter voor random acties.

[damanseb]

Bij deze de HOWTO voor een SAN met ZFS en iSCSI..

Op basis van Ubuntu 12.04 LTS Linux, ZFS en SCST voor iSCSI

http://www.sebstyle.nl/san.htm

Het is een enkele HTML file die je ook kan downloaden om op je eigen computer offline te lezen..
(als je engels kan tenminste want ik heb hem niet in het nederlands geschreven)

N.B. Het Multi Path I/O (MPIO) gedeelte, in dit geval voor (round-robin) loadbalancing, heb je wellicht niet nodig als je 10gbE gaat gebruiken

[ Voor 17% gewijzigd door damanseb op 30-11-2013 01:16 ]

[Durandal]

damanseb schreef op zaterdag 30 november 2013 @ 01:07:
Bij deze de HOWTO ..

Effe offtopic, maar waar heb je die how-to mee gemaakt? Of heb je de html met de hand geschreven? Ik zoek nog iets snels dat in die richting komt.

Psst, dit soort vraagjes kun je in het vervolg het beste via Direct Messaging stellen.

[ Voor 15% gewijzigd door Verwijderd op 30-11-2013 09:58 ]

[FireDrunk]

Toch maar 3 stuks Emulex Dual Port 4Gb Fibre Channel adapters besteld, dus binnenkort maar eens mijn ESXi cluster op ZVOL's hangen

[DRAFTER86]

Vraagje,ik ben van plan om binnenkort de eerste ZFS stapjes te zetten met 3x1TB in RAIDZ1.
Voor mij is dat voorlopig voldoende, en het gaat mij vooral om data integrity.
Nu hoort bij dat laatst natuurlijk een fatsoenlijk offsite backup.
Dus ik vroeg mij af, moet het backup filesystem eenzelfde raid-level hebben als mijn data?
Of kan ik ook een non-redundant ZFS filesystem gebruiken, en worden de checksums dan weer gecheckt (en ge-repaired indien nodig) als ik mijn backup send/receive?

[Verwijderd]

redundantie hoeft niet nee, maar het is wel fijn voor je backup. Dan kun je heel mooi langdurige snapshots gebruiken zodat je incremental backups maakt. Als je dat mooi opzet kun je bijvoorbeeld voor elke week terug in de tijd hoe je data op dat moment was.

Zolang je primaire server en backup beide ZFS draaien heb je het voordeel van checksum bescherming, zeker als je ZFS send/receive gebruikt. Dan heb je ook goede bescherming tegen silent corruption die naar je backup zou kunnen vloeien - wat een groot probleem kan zijn indien je geen ZFS zou gebruiken.

[DRAFTER86]

Verwijderd schreef op zaterdag 30 november 2013 @ 11:11:
redundantie hoeft niet nee, maar het is wel fijn voor je backup. Dan kun je heel mooi langdurige snapshots gebruiken zodat je incremental backups maakt. Als je dat mooi opzet kun je bijvoorbeeld voor elke week terug in de tijd hoe je data op dat moment was.

Zolang je primaire server en backup beide ZFS draaien heb je het voordeel van checksum bescherming, zeker als je ZFS send/receive gebruikt. Dan heb je ook goede bescherming tegen silent corruption die naar je backup zou kunnen vloeien - wat een groot probleem kan zijn indien je geen ZFS zou gebruiken.

Maar, nu ik er nog even over nadenk, hoe werkt dat dan?
Stel er valt een bitje om op mijn backup server, die merkt dat wel aan de hand van de checksum maar kan het niet repareren.
Mijn primaire server heeft dat block data misschien wel helemaal niet meer...?
Of zie ik iets over het hoofd?

[Verwijderd]

Als je geen redundantie over hebt en je hebt een bad sector bijvoorbeeld of corruptie, dan raakt dat ene bestand waarover het betreft ontoegankelijk. Je kunt precies zien welk bestand in de zpool status -v output. ZFS zelf raakt niet snel corrupt omdat zelfs zonder redundantie (enkele disk) je metadata beschermd is door ditto blocks (copies=2 zeg maar).

[syl765]

@damabseb

Leuke en handige howto.
Wat mij echter opvalt is dat met zpool status het lijkt alsof jou SLOG device geen mirror is.
Waarbij je de SLOG wel aanmaakt als mirror.
Ik heb een soortgelijke config maar ik werk met FreeBSD en mijn zpool status laat duidelijk zien dat mijn SLOG een mirror is. Mijn cache is geen mirror en dat ziet er hetzelfde uit als jou SLOG.
Misschien zijn dit de verschillen tussen zfs op linux en FreeBSD.
Maar even checken kan geen kwaad aangezien je duidelijk de keuze gemaakt hebt voor een mirror.

code:

san ~ # uname -a
FreeBSD san.thuis.lan 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r256314: Fri Oct 11 16:58:45 CEST 2013     [e-mail]:/usr/obj/usr/src/sys/KRNL  amd64


san ~ # zpool status
  pool: storage
 state: ONLINE
  scan: resilvered 0 in 0h0m with 0 errors on Tue Oct 15 10:09:38 2013
config:

        NAME            STATE     READ WRITE CKSUM
        storage         ONLINE       0     0     0
          mirror-0      ONLINE       0     0     0
            gpt/disk00  ONLINE       0     0     0
            gpt/disk01  ONLINE       0     0     0
          mirror-1      ONLINE       0     0     0
            gpt/disk02  ONLINE       0     0     0
            gpt/disk03  ONLINE       0     0     0
          mirror-2      ONLINE       0     0     0
            gpt/disk04  ONLINE       0     0     0
            gpt/disk05  ONLINE       0     0     0
          mirror-3      ONLINE       0     0     0
            gpt/disk06  ONLINE       0     0     0
            gpt/disk07  ONLINE       0     0     0
        logs
          mirror-4      ONLINE       0     0     0
            gpt/slog00  ONLINE       0     0     0
            gpt/slog01  ONLINE       0     0     0
        cache
          gpt/cache00   ONLINE       0     0     0
          gpt/cache01   ONLINE       0     0     0

errors: No known data errors

Gr
Johan

[damanseb]

@Johan: je hebt gelijk, als ik een zpool status doe geeft hij bij mij ook aan dat het een mirror betreft..
Ik denk dat het regeltje per ongeluk verloren is gegaan in het kopieren/plakken

[matty___]

syl765 schreef op zaterdag 30 november 2013 @ 12:29:
@damabseb


[code]

san ~ # uname -a
FreeBSD san.thuis.lan 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r256314: Fri Oct 11 16:58:45 CEST 2013 [e-mail]:/usr/obj/usr/src/sys/KRNL amd64

Zo een config hebben en kijk je naar de hostname

[syl765]

@matty__

Geloof niet altijd alles wat je leest...
Dit is het san op de zaak.
Echter om het domein te maskeren even verandert.
Thuis ziet een zpool status er een stuk droeviger uit...

Gr
Johan

[martinvw]

damanseb schreef op zaterdag 30 november 2013 @ 15:00:
@Johan: je hebt gelijk, als ik een zpool status doe geeft hij bij mij ook aan dat het een mirror betreft..
Ik denk dat het regeltje per ongeluk verloren is gegaan in het kopieren/plakken

@damanseb ik heb met veel plezier je howto doorgelezen, ik neig ernaar om ook voor ZFS on Linux te gaan. Ik was nog benieuwd hoe je je linux boot (sda1/sdb1) linux lvm (sda2/sdb2) ingesteld hebt, zit daar software raid overheen? Mocht dat te offtopic worden mag je me ook wel een DM / mail sturen.

[damanseb]

m4rt1nvw schreef op zondag 01 december 2013 @ 19:56:
[...]

@damanseb ik heb met veel plezier je howto doorgelezen, ik neig ernaar om ook voor ZFS on Linux te gaan. Ik was nog benieuwd hoe je je linux boot (sda1/sdb1) linux lvm (sda2/sdb2) ingesteld hebt, zit daar software raid overheen? Mocht dat te offtopic worden mag je me ook wel een DM / mail sturen.

Je hebt DM uitstaan..

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sda2[0] sdb2[1]
      39029632 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      261952 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Dat is correct..
Tijdens installatie software raid aangemaakt met ruimte over voor later toe te voegen ZIL partities.
Waarbij md0 de /boot partitie (256M) bevat en md1 de LVM partitie (40G) met root (32G) en swap (8G)

[FireDrunk]

Waarom gebruik je MD als je ZFSonLinux wil doen?

[darth.75]

syl765 schreef op vrijdag 29 november 2013 @ 22:13:
@dart.75

Je kunt het beste een pool opbouwen met dezelfde vdev configuratie.
Dus of een pool met mirrors, of een pool bestaande uit vdev's met raidz(x)

Het mixen van verschillende vdev configuratie's gaat ten kosten van je performance.

Gr
Johan

Mystic Spirit schreef op vrijdag 29 november 2013 @ 22:12:
[...]

Je denk richting is goed. Eventueel kun je ervoor kiezen zoveel mogelijk van de 1,5+ TB schijven in een RAIDZ1 pool te zetten en overgebleven ruimte te gebruiken om partities met kleinere schijven te mirroren. Kost je wel performance in het begin, maar je houdt er meer effectieve ruimte van over.

Dank jullie. Heb nog wat aanvullend zitten googlen en kwam deze opmerking ook tegen. Ga nu voor twee mirrors (een van 1,5 TB en 2 TB en een van 2x3TB). Dan heb ik effectief zo'n 4,5 TB en dat is voorlopig genoeg. Kan ik tzt nog keer uitbreiden met 3 of 4 TB schijf voor 500 GB extra en nog weer later nog een 3 of 4 TB schijf erbij voor dan 2x 2x 3TB = 6 TB en ik kan dan ook de 1,5 en 2 TB schijven ook nog gebruiken. Tegen die tijd heb ik dan 7,5 TB opslag en dat is echt meer dan zat.

Nu nog ff klooien om snapshots aan de gang te krijgen in Nas4Free (kreeg FreeNAS niet virtueel aan de praat). Maar bovenal om te snappen wat er gebeurt en hoe ik een restore doe. Bovendien wil ik die snapshots op een externe disk opslaan. Dus dat wordt nog wat avondjes aanklooien en googlen

Dan kijken of ik die scratch disk kan toevoegen en als ik dan de functionaliteit van mijn WHS heb gekopieerd, kunnen de harde waren worden afgeschaft.

Dank in ieder geval voor ondersteunen van de denkrichting.

[Mystic Spirit]

Snapshots op een externe schijf opslaan, klinkt mij een beetje vreemd in de oren. Het hele idee van maken van snapshots is dat het nauwelijks ruimte kost. Waarom wil je dat op een externe schijf doen?

[syl765]

Je kan de snapshots zenden naar een andere pool.

@mystic spirit.
Wat heb je aan je snapshots als je pool er niet meer is.
Een ongeluk komt nooit alleen, en zeker in IT land is murphy's law geen onbekende.
Snapshots zijn geen backup....., wel zijn ze erg handig om terug te kunnen vallen op oude data, maar het is geen backup.
Een backup maak je op een ander medium. In het geval van zfs kan dit een andere pool zijn.

Gr
Johan

[damanseb]

FireDrunk schreef op maandag 02 december 2013 @ 13:33:
Waarom gebruik je MD als je ZFSonLinux wil doen?

Kort door de bocht.. Het is zoals je zelf al aangeeft: ZFSonLINUX en niet ZFSonLINUXonZFS

ZFS draait bovenop het OS, de een van de ander afhankelijk maken is vragen om narigheid imho.
Mocht er namelijk iets aan de hand zijn met mijn ZFS pool wil ik nog wel gewoon bij het OS kunnen om het te kunnen repareren.

Mijn ZFS pool is puur en alleen voor opslag welke ik exporteer via iSCSI..
Als ik dan toch twee SSDs heb om het ZIL te mirroren kan ik net zo goed het OS ook mirroren..
En daar is linux software raid prima voor geschikt.

SSD--OS--ZFS--|--ZIL
     MD       |----POOL--(HDD/HDD)(HDD/HDD)(HDD/HDD)(HDD/HDD)--iSCSI
SSD--OS--ZFS--|--ZIL

Mocht een van de SSDs het begeven is er niets aan de hand..

[ Voor 12% gewijzigd door damanseb op 02-12-2013 22:33 ]

[darth.75]

Mystic Spirit schreef op maandag 02 december 2013 @ 20:14:
Snapshots op een externe schijf opslaan, klinkt mij een beetje vreemd in de oren. Het hele idee van maken van snapshots is dat het nauwelijks ruimte kost. Waarom wil je dat op een externe schijf doen?

Misschien denk ik helemaal verkeerd, maar ik maak nu regelmatig een (incrementele) backup van de écht belangrijke data (foto's, homevideo's enz.) op een gewone externe schijf die ik off-site bewaar.

Ik heb niet de luxe van een tweede server ergens off-site. Moet ik dat dan niet met snapshots doen, maar op een andere wijze? Heb me daar overigens nog niet zo enorm in verdiept. Eerst de basics van opzetten en delen van bestanden.

[Unicron]

Verwijderd schreef op dinsdag 29 maart 2011 @ 20:53:
[color=#009]Hoe werken bad sectors en SMART?[/color]

Bij redundante pools zoals RAID1 of RAID5/6/7 gaat ZFS zijn ballen laten zien. Onleesbare sector? Haha, zielig schijfje, zal ik jou eens van jouw probleempje afhelpen? Hier heb je de gegevens die in de bad sector stond. Dat weet ik omdat ik van een redundante bron lees: RAID ofwel ditto copies. Dus wat doen we? We overschrijven de bad sector met de data die daar hoorde te staan. Dat gebeurt direct na de eerste timeout. Het probleem is dan gelijk opgelost: door het overschrijven van de bad sector zal deze ofwel verdwijnen ofwel worden omgewisseld. Dit alles zonder dat de gebruiker of applicatie ooit problemen ondervindt. Bovendien kun je zien dat dit gebeurt doordat ZFS een read error aangeeft in de status output.

Ik gebruik al ruim 5 jaar ZFS op mijn Ubuntu NAS, eerst via FUSE en nu ZFSonLinux (0.6.2). Mijn configuratie is een 10 disk RaidZ2. Sinds een tijdje heb ik een disk waarvan de nodige sectoren onleesbaar zijn en wat keurig te zien is in de dmesg output:

code:

[  224.060343] ata3.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x0
[  224.064213] ata3.00: irq_stat 0x40000008
[  224.068138] ata3.00: failed command: READ FPDMA QUEUED
[  224.072078] ata3.00: cmd 60/f0:00:75:79:2d/00:00:14:00:00/40 tag 0 ncq 122880 in
[  224.072083]          res 41/40:00:e0:79:2d/00:00:14:00:00/40 Emask 0x409 (media error) <F>
[  224.079990] ata3.00: status: { DRDY ERR }
[  224.083933] ata3.00: error: { UNC }
[  224.100103] ata3.00: configured for UDMA/133
[  224.100122] sd 2:0:0:0: [sdc] Unhandled sense code
[  224.100127] sd 2:0:0:0: [sdc]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  224.100134] sd 2:0:0:0: [sdc]  Sense Key : Medium Error [current] [descriptor]
[  224.100143] Descriptor sense data with sense descriptors (in hex):
[  224.100148]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[  224.100171]         14 2d 79 e0
[  224.100184] sd 2:0:0:0: [sdc]  Add. Sense: Unrecovered read error - auto reallocate failed
[  224.100194] sd 2:0:0:0: [sdc] CDB: Read(10): 28 00 14 2d 79 75 00 00 f0 00
[  224.100216] end_request: I/O error, dev sdc, sector 338524640
[  224.104200] ata3: EH complete

Ik was ook in de veronderstelling dat ZFS dit keurig zou melden als read error en vervolgens met behulp van de raidz2 redundantie de boel goed zou terug schijven. Ten eerste zie ik geen read error en het terug schrijven gebeurt ook niet!
Na het nodige zoekwerk op internet vind ik inderdaad meldingen dat het terugschrijven alleen gebeurd bij een checksum error en niet bij een read error (zie https://github.com/zfsonlinux/zfs/issues/1256). Ook betwijfel ik of ZFS wel exact dezelfde sector zou schrijven in geval van een checksum error vanwege het COW mechanisme. Als ik de source code bekijk zou dit weleens kunnen kloppen, maar gezien de complexiteit van de code ben ik daar niet 100% zeker van. Als ik met hdparm de kapotte sector met nullen overschrijf is na een scrub deze sector nog steeds gevuld met nullen. ZFS geeft trouwens wel gewoon altijd de juiste data, want dit kan ik controleren omdat ik md5 hashes heb van alle bestanden
Het verhaal uit de tweede openingspost is dus volgens mij niet helemaal correct

Het irritante is dus dat ik een berg sectoren heb die volgens SMART pending voor reallocation zijn, maar dit zal niet gebeuren als er niet wordt geschreven naar deze sectoren. Echt self-healing noem ik dit niet, meer het echte probleem 'unreadible sectoren' verdoezelen. Ik zou het liefst zien dat ZFS deze exacte sectoren overschrijft met de correcte data zodat de disk ze kan reallocaten.

Ik wil eigenlijk nog steeds eens met een virtuele machine wat testjes doen om te kijken wanneer en wat zfs nu echt doet bij errors als ik bewust wat sectoren om laat vallen. Dit is sneller en een stuk veiliger dan op echte data op mijn 10 disken.

[ Voor 10% gewijzigd door Unicron op 02-12-2013 22:10 ]

[Verwijderd]

Zoals behlendorf in diezelfde issue thread meldt:

I can assure you it is working as intended. Which isn't to say there isn't room for improvement because it was designed with the Solaris SCSI layer behavior in mind and not Linux's. They differ significantly in some regards. There are at least three legitimate cases to consider.

- A hard persistent read error. The sector will never be readable again and will not be remapped by the drive until the sector is rewritten.
- A soft read error. The sector error was transient and subsequent attempts will return the correct data.
- No read error but incorrect data was returned, the invalid checksum case.

Right now ZFS treats all read errors as soft read errors. The data will get reconstructed on the fly but not rewritten

En hier schuilt denk ik het verschil. In FreeBSD gaan er volgens mij wél writes naar de disks enkel voor read-acties. Althans dat is het gedrag wat ik meerdere keren heb ervaren, met gstat maar ook in een geval met een ontbrekende schijf waar in hoog tempo write errors opliepen (naar vele K dus duizenden) - enkel door read acties. De tests die ik deed zijn echter al ouder, voornamelijk rond de 7-CURRENT tijdperk, nog voordat ZFS officieel in de tree zat geloof ik. Maar dit gedrag zou te testen zijn met de geom_nop provider die read/write errors can simuleren.

Maar mijn punt is dus dat het mogelijk niet van toepassing is op de implementatie van Linux (en mogelijk ook Solaris) maar niet op de implementatie die FreeBSD biedt. Wellicht dat dit feit ook vermeld kan worden in de tekst die je noemt.

Het irritante is dus dat ik een berg sectoren heb die volgens SMART pending voor reallocation zijn, maar dit zal niet gebeuren als er niet wordt geschreven naar deze sectoren. Ik zou het liefst zien dat ZFS deze exacte sectoren overschrijft met de correcte data zodat de disk ze kan reallocaten.

Simpel zat: schijf je pool vol met nullen. dd if=/dev/zero of=zerofile bs=1M &

Niet doen als je Root-on-ZFS draait, dan zou ik het handmatig doen. Maargoed, hierna verwijder je het bestand en als het goed is zijn vrijwel alle pending sectors dan eventjes weg. Opzich is dit niet nodig; de pending sectors worden vanzelf weer 'goed' zodra ze weer in gebruik worden genomen naar verloop van tijd.

[Mystic Spirit]

syl765 schreef op maandag 02 december 2013 @ 21:14:
Je kan de snapshots zenden naar een andere pool.

@mystic spirit.
Wat heb je aan je snapshots als je pool er niet meer is.
Een ongeluk komt nooit alleen, en zeker in IT land is murphy's law geen onbekende.
Snapshots zijn geen backup....., wel zijn ze erg handig om terug te kunnen vallen op oude data, maar het is geen backup.
Een backup maak je op een ander medium. In het geval van zfs kan dit een andere pool zijn.

Gr
Johan

Die logica volg ik wel, maar dan back-up je alles inclusief de snapshots die je hebt. Dat is zou ik ook doen, maar alleen een snapshot back-uppen lijkt me raar.

alle slechte dingen komen (zeker in IT land) in drieën

[Unicron]

Verwijderd schreef op maandag 02 december 2013 @ 22:35:
Zoals behlendorf in diezelfde issue thread meldt:

[...]

En hier schuilt denk ik het verschil. In FreeBSD gaan er volgens mij wél writes naar de disks enkel voor read-acties. Althans dat is het gedrag wat ik meerdere keren heb ervaren, met gstat maar ook in een geval met een ontbrekende schijf waar in hoog tempo write errors opliepen (naar vele K dus duizenden) - enkel door read acties. De tests die ik deed zijn echter al ouder, voornamelijk rond de 7-CURRENT tijdperk, nog voordat ZFS officieel in de tree zat geloof ik. Maar dit gedrag zou te testen zijn met de geom_nop provider die read/write errors can simuleren.

Maar mijn punt is dus dat het mogelijk niet van toepassing is op de implementatie van Linux (en mogelijk ook Solaris) maar niet op de implementatie die FreeBSD biedt. Wellicht dat dit feit ook vermeld kan worden in de tekst die je noemt.

Ik had inderdaad de reactie van behlendorf gelezen. Het ging mij meer om enige referentie bij mijn punt te hebben. Ik geloof inderdaad best dat het gedrag is zoals ontworpen, maar of dit ook optimaal is in bepaalde situaties vraag ik mij af.

Het lijkt mij toch onwaarschijnlijk dat FreeBSD iets anders doet dan ZoL, omdat als ik de code in vdev_raidz.c vergelijk van FreeBSD en ZoL ik geen verschillen zie in de functie vdev_raidz_io_done. Voor zover ik begrijp wordt hier besloten wat te doen in geval van read/checksum errors.
Ik zou puur uit interesse voor ZFS graag begrijpen hoe ZFS nu precies handelt in verschillende use cases betreft read/checksum errors gezien deze informatie niet of nauwelijks te vinden is met google. Misschien dat iemand hier al eens wat tests heeft gedraaid

[...]

Simpel zat: schijf je pool vol met nullen. dd if=/dev/zero of=zerofile bs=1M &

Niet doen als je Root-on-ZFS draait, dan zou ik het handmatig doen. Maargoed, hierna verwijder je het bestand en als het goed is zijn vrijwel alle pending sectors dan eventjes weg. Opzich is dit niet nodig; de pending sectors worden vanzelf weer 'goed' zodra ze weer in gebruik worden genomen naar verloop van tijd.

Dit is inderdaad een oplossing, maar iets wat ik liever niet al te snel doe met disk met belangrijke data.

[syl765]

@Mystic Spirit

Die logica volg ik wel, maar dan back-up je alles inclusief de snapshots die je hebt. Dat is zou ik ook doen, maar alleen een snapshot back-uppen lijkt me raar.

Klopt je hebt een kopie van je data, maar dat heb je zonder ZFS ook dus daar verandert niet zo veel.
Echter kun je de snapshots incremental versturen met behoud van de checksums en dit zorgt dus voor een backup met een bijna 100% data intergriteits garantie.

Op mijn storage heb ik heel veel veranderingen, mijn dagelijkste snapshots zijn toch al snel een 50 tot 60 GB groot. Dit komt door de vele veranderingen in een aantal hele grote bestanden.
Dus in mijn geval is een snapshot niet goedkoop qua data.
Op de dure pool (15k sas schijven) om het zo maar even te noemen heb ik 1 snapshot, op mijn goedkope pool (4 TB sata disks) hou ik een backup strategie bij voor de dagelijkse weekelijkse enz backups.
Deze staat in een ander kantoor op een andere locatie.

Voor een thuis situatie is het lastig backuppen als je een pool van 10 of meer TB hebt.
Je zou dan aan een offsite backup kunnen denken. En anders heeft de AIVD vast nog wel een kopietje...

alle slechte dingen komen (zeker in IT land) in drieën

Ik heb het zelfs in vieren zien komen

Soms kunnen de zaken zo tegen zitten dat het lijkt alsof het gewoon zo moet zijn. Je krijgt dan het gevoel dat je ertegen verzetten geen zin heeft, en dat je het maar gewoon moet laten gebeuren.

gr
Johan

[ Voor 13% gewijzigd door syl765 op 03-12-2013 09:33 ]

[]Byte[]

Heeft iemand goede ervaringen met Bonnie++? (het is voor mij iig de eerste keer)

Ik heb nl. sterk fluctuerende getallen binnen 1 testreeks.
Vooral de latency's geven opvallende resultaten zien op zowel de hdd als ook op de ssd-pool.

Een paar voorbeelden van de ssd-pool:
Seq. Output (block) varieert tussen de 5563 us tot 91217 us
Seq. Create (read) varieert tussen de 107 us tot 26842 us

Er zit ook eigenlijk helemaal geen enkele structuur in de output waar een lijn in te ontdekken is.
Het lijkt wel een bos vlooien die rond springen. (rood, bruin, groen... alles door elkaar)

(mijn test is: $> bonnie++ -m ZFSguru-SSD -u root -x 10 -d /ssd_pool1/share/crap/ -s 1024 -r 512 -n 100 | bon_csv2html > result_ssd.html)

[ Voor 14% gewijzigd door ]Byte[ op 03-12-2013 20:25 ]

[Laurian]

Gevraagd: advies voor een ZFS beginner.

Ik heb de volgende schijven:
4 x 2TB WD GREEN van 3 jaar oud (waarvan 1 met 29 slechte sectoren)
2 x 3TB WD GREEN van 2 jaar oud
2 x 4TB WD RED van 1 maand oud
1 x SSD 120GB
1 x SSD 240GB

Daarop moet komen:
- 3 TB aan cruciale privé foto's en video's, documenten.
- 8 TB aan films, series, etc
- 3 TB aan backups van andere PC's, virtuele machines, etc.
- toekomstvast voor +- 4 TB extra

Ik ben op zoek naar een manier om het e.e.a. betrouwbaar en energiezuinig en snel opslaan.
Betrouwbaar: foto's, homevideo, e.d. gaan ook in de cloudbackup, maar dat duurt erg lang om te downloaden. Dus ik wil graag bescherming tegen falen.
Energiezuinig: Dus als iemand een film draait, wil ik die eigenlijk meteen helemaal op de SSD hebben zodat de drives weer in slaap kunnen. Een 6-schijf raidz2 is leuk, maar vraagt ook om 6 draaiende schijven.
Snel: Het moet in ieder geval een teaming netwerkverbinding (2 x 1GB) vol kunnen maken.

Ben van plan om het met ubuntu server + ZFSLinux te doen. Heb er wat experimenten mee gedaan.
Ik overweeg nu:
ZPOOL SAFE:
2x een mirror van de 2TB schijven.

ZPOOL FAST:
- RAIDZ van 4 schijven (mis ik 2 TB)
- RAID0 met een vdev 2x3TB en een vdev 2x4TB schijven

Wat ik jammer vindt is dat als ik de ZPOOL FAST maak, dat ik daarna moeilijk meer terug kan. Ik zie geen commando's om een VDEV uit een pool te halen of om geleidelijk te herbalanceren. Ik overweeg om nog om maximaal twee 3TB of 4TB schijven bij te kopen. Ook zit ik nog te kijken of ik niet door partities te gebruiken het e.e.a. op kan vangen.

Wat zouden jullie doen? Adviezen?

[darth.75]

Mystic Spirit schreef op maandag 02 december 2013 @ 22:37:
[...]

Die logica volg ik wel, maar dan back-up je alles inclusief de snapshots die je hebt. Dat is zou ik ook doen, maar alleen een snapshot back-uppen lijkt me raar.

alle slechte dingen komen (zeker in IT land) in drieën

Misschien snap ik het jargon dan nog niet helemaal. Ik dacht dat snapshots "foto's" waren van je filesystems op bepaalde momenten. En dat je die snapshots een bepaalde periode kon bewaren. Dit staat dan neem ik aan allemaal in je pool? Vervolgens dacht ik: haal de snapshots naar je externe schijf en klaar. Maar blijkbaar iets te makkelijk gedacht?

Hoe maken jullie je backups dan?

[Unicron]

Ik heb een korte test gedaan door moedwillig wat data corruptie te veroorzaken op een nieuw gecreëerde raidz2 pool om te achterhalen wanneer fouten nou echt zichtbaar worden. Deze test is gedaan op Ubuntu 12.04 LTS (up-to-date) en ZoL 6.0.2.

De stappen

code:

- create three files of 1GB
    dd if=/dev/urandom of=disk1.zfs bs=1G count=1
    dd if=/dev/urandom of=disk2.zfs bs=1G count=1
    dd if=/dev/urandom of=disk3.zfs bs=1G count=1
- create raidz2 pool using the three disks
    sudo zpool create -m /mnt/testpool testpool raidz2 /home/test/disk1.zfs /home/test/disk2.zfs /home/test/disk3.zfs
- create 10M testfile in /mnt/testpool
    sudo dd if=/dev/urandom of=testfile bs=1M count=10
- create md5sum for verification
    md5sum testfile > md5.txt
- just to be sure the pool is healthy scrub it
    sudo zpool scrub testpool
    sudo zpool status
- corrupt one of the three disks
    dd bs=1024k count=32 conv=notrunc if=/dev/zero of=disk1.zfs
- export and import pool to flush caches
    sudo zpool export testpool
    sudo zpool import -d /home/test/ testpool
- check pool status
    sudo zpool status        -> a few checksum errors show up probably because I also corrupted metadata that is used on import
- recalculate md5sum of testfile to make zfs read the corrupted data
    md5sum testfile          -> still okay
- check zpool status
    sudo zpool status        -> no increase of checksum errors!
- Scrub the pool
    sudo zpool scrub testpool
    sudo zpool status        -> now all the checksum errors show up
- check md5sum
    md5sum testfile          -> still okay

Wat ik hieruit concludeer is dat checksum errors in het zpool status commando voornamelijk alleen worden geupdate tijdens een scrub en niet tijdens het normaal lezen van de data.
Dit wordt ook gemeld in https://groups.google.com/forum/#!topic/zfs-fuse/ql47lJl4zcQ en is blijkbaar het correcte gedrag. Blijkbaar ben ik niet de enige persoon die dacht dat de checksum counter altijd werd bijgewerkt. Persoonlijk lijkt het mij toch ook handig om te zien hoeveel fouten er op treden als je de pool gewoon gebruikt. Iemand die dit ook een wil proberen op FreeBSD om te kijken of het gedrag hetzelfde is?

[Verwijderd]

@unicron

Wat FireDrunk en ik al eerder getest hadden onder BSD is dat ZFS bij RAID-Z en zonder cache (na export + import) geen redundancy inleest tijdens normale read access.

Ik dacht eerder dat ZFS dat wel zou doen omdat RAID-Z - doordat het zoveel op RAID3 lijkt - toch alle disks in één I/O betrekt. De redundancy erbij trekken lijkt dan bijna 'gratis' te zijn. Waarom ZFS dit niet doet is mij een raadsel, want zo kun je met een klein beetje extra rekenwerk gelijk een 'gratis scrub' erbij krijgen bij normale read access. Want dat is wat je bedoelt neem ik aan?

[syl765]

@darth.75

Kijk hier eens.
http://breden.org.uk/2008...fileserver-zfs-snapshots/
http://breden.org.uk/2008...ckups-from-zfs-snapshots/

Gr
Johan

[Mystic Spirit]

darth.75 schreef op dinsdag 03 december 2013 @ 21:24:
[...]


Misschien snap ik het jargon dan nog niet helemaal. Ik dacht dat snapshots "foto's" waren van je filesystems op bepaalde momenten. En dat je die snapshots een bepaalde periode kon bewaren. Dit staat dan neem ik aan allemaal in je pool? Vervolgens dacht ik: haal de snapshots naar je externe schijf en klaar. Maar blijkbaar iets te makkelijk gedacht?

Hoe maken jullie je backups dan?

Back-ups maken doe je door een back-up taak te schedulen voor een bepaalde map of je kan natuurlijk een complete pool back-uppen. Snapshots zijn vooral bedoeld om terug te kunnen gaan naar een bepaalde status waarin je pool zich op een gegeven moment bevond. Dat is vooral handig als files worden overschreven die niet overschreven hadden moeten worden, of files gedelete die niet gedelete hadden moeten worden. Een snapshot is in die zin dus geen vervanging van een back-up alhoewel je wel een snapshot naar een externe schijf zou kunnen schrijven en dan heb je feitelijk ook een back-up. Het is alleen een beetje verwarrend als je het door elkaar gebruikt.

[Unicron]

Verwijderd schreef op dinsdag 03 december 2013 @ 21:45:
@unicron

Wat FireDrunk en ik al eerder getest hadden onder BSD is dat ZFS bij RAID-Z en zonder cache (na export + import) geen redundancy inleest tijdens normale read access.

Ik dacht eerder dat ZFS dat wel zou doen omdat RAID-Z - doordat het zoveel op RAID3 lijkt - toch alle disks in één I/O betrekt. De redundancy erbij trekken lijkt dan bijna 'gratis' te zijn. Waarom ZFS dit niet doet is mij een raadsel, want zo kun je met een klein beetje extra rekenwerk gelijk een 'gratis scrub' erbij krijgen bij normale read access. Want dat is wat je bedoelt neem ik aan?

Niet helemaal. Als eerste zou ik graag altijd een melding zien van een leesfout scrub of niet. Ten tweede zou ik graag zien dat dan gelijk de data op disk wordt bijgewerkt (Beter gelijk repareren dan wachten tot een scrub wanneer mogelijk teveel is omgevallen om nog te kunnen recoveren).

Je zegt ook dat er geen redundancy ingelezen wordt bij een normale read access. Dit zou best kunnen, maar het feit blijft dat ZFS wel degelijk weet dat er een checksum error heeft plaats gevonden, want anders zou er niet de correcte data kunnen worden terug gegeven. Of het zou zo moeten zijn dat disk1 niet wordt gebruikt en alleen disk2 en disk3 tijdens mijn test, maar ik verwacht eigenlijk dat de checksumming over alle disks is verspreid en dat alle 3 de disks worden gebruikt om de data terug te halen (zoals bij RAID5).

[darth.75]

syl765 schreef op dinsdag 03 december 2013 @ 21:54:

[...]

Mystic Spirit schreef op dinsdag 03 december 2013 @ 21:54:

[...]

Wordt beetje bij beetje wijzer. Dank voor de links. Interessant leesvoer, maar dan wel voor morgen. Neem het nu allemaal niet meer zo op, merk ik. Wel leuke hobby . Maar tegelijkertijd wil het wel allemaal snappen voordat mijn "echte" data erop gaat natuurlijk.

[ Voor 44% gewijzigd door darth.75 op 03-12-2013 22:49 ]

[Verwijderd]

Unicron schreef op dinsdag 03 december 2013 @ 22:15:
Niet helemaal. Als eerste zou ik graag altijd een melding zien van een leesfout scrub of niet.

Als een leesactie faalt, dan krijg je dat op ZFS te zien. Als er data wordt retourneert die niet conform de checksum is, dan wordt een checksum error gegenereerd. Ik weet niet of daar verschillen tussen zit met FreeBSD versus Linux ZFS-support.

Ten tweede zou ik graag zien dat dan gelijk de data op disk wordt bijgewerkt (Beter gelijk repareren dan wachten tot een scrub wanneer mogelijk teveel is omgevallen om nog te kunnen recoveren).

Als een bad checksum wordt gedetecteert wordt dat gecorrigeerd. De vraag is of dat via CoW gebeurt en dus of dezelfde (Current Pending) sector wordt overschreven of niet. Ik dacht eerst van wel, maar het zou zeker kunnen van niet. Comments invited.

Je zegt ook dat er geen redundancy ingelezen wordt bij een normale read access.

Niet bij mirror omdat die als striping probeert te lezen; beste sequential read access van alle RAID1 implementaties die ik heb gezien op mechanische hardeschijven. Maar dat betekent dus dat mirroring geen redundancy inleest. Bij RAID-Z dacht ik van wel, blijkt kennelijk niet zo te zijn.

Dit zou best kunnen, maar het feit blijft dat ZFS wel degelijk weet dat er een checksum error heeft plaats gevonden, want anders zou er niet de correcte data kunnen worden terug gegeven.

Bij normale read-access zou corruptie in normale data wél gecorrigeerd worden, de vraag was alleen of dat ook voor de redundancy goldt. Nee dus. Als dat wel zo was, zou read-access hetzelfde betekenen als een scrub mits je al je data af en toe leest. Zou geweldige bonus zijn, maar helaas. Wellicht een leuke feature voor de toekomst. Liefst als tunable waarbij alleen voor RAID-Z familie het standaard geactiveerd wordt. Daarbij kost het - met name voor hardeschijven ipv SSD - bijna geen performance.

Het is mij niet duidelijk in hoeverre ZFS kenmerken verschillen per platform (Solaris, BSD, Linux). Maar dat er verschillen kunnen zijn lijkt mij evident. Testen is leuk, maar ik heb momenteel weinig tijd. Als jullie een test willen doen is dat heel fijn, liefst onder meerdere OS. Als je dat serieus wilt aanpakken, zou ik een nieuw topic daarvoor openen hier op OT. Dan zou ik dat ook van mijn support voordien.

[damanseb]

@Unicron & CiPHER:
Ik vermoed dat ZFS er helemaal niets mee doet maar dit overlaat aan onderliggende lagen (kernel, smart,whatever) en uiteindelijk de beheerder.
Persoonlijk zie ik daar de logica wel van in.

Wellicht is de mentaliteit van de ontwikkelaars wat betreft kapotte sectoren gewoon anders dan die van de meeste van ons..
Hobby mentaliteit: Acceptabel risico.. Gewoon reallocaten en klaar.. geld groeit me niet op de rug weetje!
Enterprise mentaliteit: Onacceptabel risico, gelijk vervangen die HDD!
Laten we eerlijk wezen dit verschil in mentaliteit is niet geheel onrealistisch.
Zelf denk ik er namelijk ook nog wel eens te makkelijk over.
Wat is nou 1 of 10 bad sectors op een paar miljard.. makkelijk te relativeren maar defect is defect.

Echter, als ik een HDD test en ik vind bad sectors voor ik hem in gebruik neem dan RMA ik hem.
En sectoren gaan over het algemeen niet zomaar kaput..
Gebeurt dit wel tijdens gebruik dan is dit over het algemeen een goeie indicatie dat je de complete schijf moet gaan vervangen..
Reallocation kan immers ook maar een beperkt aantal keren gebeuren.
Zodoende zou ik liever de errors blijvend terug zien komen zodat ik zelf actie kan ondernemen dan dat er word 'opgelapt' achter de schermen tot op het punt dat dit niet meer gaat en je nog verder van huis bent.

Sector reallocation kan je imho dan ook niet zomaar als selfhealing bestempelen.
Reallocation is namelijk eerder 'patchen' (een heet mes op een open wond) dan 'healen'..
Healen doe je door een schijf met bad sectors te vervangen.

my 2 cents

[ Voor 4% gewijzigd door damanseb op 04-12-2013 23:50 ]

[Verwijderd]

En sectoren gaan over het algemeen niet zomaar kaput..

Dan begrijp je het hele probleem niet.

Het probleem is niet fysiek beschadigde sectoren (die worden omgewisseld -> Reallocated Sector Count). Het probleem is onleesbare sectoren door te weinig errorcorrectie - ook wel met uBER aangeduid. Dit zijn Current Pending Sectoren die - wanneer overschreven - simpelweg verdwijnen. Deze worden niet omgewisseld omdat de sectoren zelf prima in orde zijn.

Hardeschijffabrikanten geven op hoe vaak zoiets gebeurt - zeg maar een bad sector zonder fysieke schade. Consumentenschijven doen met 10^-14 gemiddeld een bad sector per dag als je 24/7 operatie doet gemiddeld @ 100% duty cycle. Enterpriseschijven doen tot 10^-16 en hebben dus tot 100 keer minder vaak last van dit probleem.

Omdat door de toegenomen datadichtheid de kans op dergelijke bad sectors veel groter is geworden, wordt doorgaans met schijven groter dan 1TB aangeraden om óf enterpriseschijven óf extra redundancy te nemen. RAID5 is alleen om deze reden al niet veilig genoeg meer. Vandaar ook het artikel: Why RAID 5 stops working in 2009.

[A1AD]

Prachtige OP, ik heb even geen zin om 383 pagina's door te spitten dus de kans dat hier al over gesproken is is groot....
Ik heb gisteren op het freenas forum horror verhalen gelezen door het niet gebruiken van ECC ram. Een slechte non-ecc module zou zomaar je pool kunnen defect maken incl. je snapshot replications omdat deze de foute bestanden gewoon mee overneemt. Er werd zelf gezegd dat door die defecte module je de pool volledig naar de eeuwige jachtvelden kan scrubben.

Hebben de non ecc gebruikers nu een vals gevoel van veiligheid of hoe zit het nu juist?

[Bigs]

A1AD schreef op donderdag 05 december 2013 @ 08:30:
Prachtige OP, ik heb even geen zin om 383 pagina's door te spitten dus de kans dat hier al over gesproken is is groot....
Ik heb gisteren op het freenas forum horror verhalen gelezen door het niet gebruiken van ECC ram. Een slechte non-ecc module zou zomaar je pool kunnen defect maken incl. je snapshot replications omdat deze de foute bestanden gewoon mee overneemt. Er werd zelf gezegd dat door die defecte module je de pool volledig naar de eeuwige jachtvelden kan scrubben.

Hebben de non ecc gebruikers nu een vals gevoel van veiligheid of hoe zit het nu juist?

Er is al veel over ECC gesproken hier, ik raad je aan om via de zoekfunctie bovenin dit topic even te doorzoeken op ECC dan kom je wel wat informatie tegen. Volgens mij is de strekking: ECC is niet essentieel en voorkomt ook niet alle corruptie, maar als je data belangrijk is altijd doen.

[FireDrunk]

In orde van grootte (ongeveer):

Offsite backup, lokale backup, RAID level backup, snapshots, copies=2 (ongeveer). En DAARNA komen pas hardware oplossingen als ECC.

Simpel gezegd, ik heb liever RAIDZ / Mirror dan ECC zonder RAIDZ/Mirror.

De vergelijking is natuurlijk een beetje krom, maar ik hoop dat je de strekking begrijpt.

Als je het *echt* gek wil maken, zijn er ook nog oplossingen als HAST / CARP.

[A1AD]

FireDrunk schreef op donderdag 05 december 2013 @ 08:53:
In orde van grootte (ongeveer):
Offsite backup, lokale backup, RAID level backup, snapshots, copies=2 (ongeveer). En DAARNA komen pas hardware oplossingen als ECC.

Ja ik heb een off site backup onder de vorm van zfs replication. Ik heb even geen tijd om de bron terug op te zoeken maar volgens de mannen daar biedt dit dus geen veiligheid tegen corrupte ram. De corruptie zou gewoon mee worden gerepliceerd.

_{Nu weet ik ook wel dat ze daar graag overdrijven heel voorzichtig zijn}

[]Byte[]

A1AD schreef op donderdag 05 december 2013 @ 09:18:
[...]
De corruptie zou gewoon mee worden gerepliceerd.

Klopt. hetzelfde geldt ook voor virussen. Ook die worden dus net zo snel mee gerepliceerd.
Voor de 'korte termijn restore-acties' zou je kunnen overwegen om snapshots te maken zodat je vanuit de snapshot snel files kan terugzetten.
Maar ook die hebben hun beperkingen, en zeker wanneer je snapshots gaat committen.

[A1AD]

]Byte\[ schreef op donderdag 05 december 2013 @ 12:53:
[...]
Klopt.

Hoe kan ik mij dan het beste beveiligen tegen bad ram. ECC is momenteel geen optie.
Ik maak om de zoveel maand een manuele backup van de belangrijkste data op losse schijven. Dit neemt veel tijd in beslag en hoopte dat dit niet meer nodig zou zijn eens de zfs replication zijn werk deed.

Ik kan elke maand rsyncen naar een remote site. Indien de pool corrupt geraakt net voor de rsync taak is alles alsnog verloren.
Is rysnc dan een betere keuze voor de backups, gezien het ram verhaal, tov zfs replication? Kan je je pool uberhaupt wel beveiligen dmv backups tegen bad ram...

Ik zoek dus een automatische backup strategie die niet alleen uitval van de nas/schijven voorziet maar ook corruptie van de data.

_{Waarom moest ik weer zo nodig het freenas forum lezen...}

[]Byte[]

ECC is eigenlijk de enige optie, maar voor jou op dit moment geen optie.
100% je er tegen kunnen beveiligen is een utopie.
Je kan alleen wel het risico verlagen.
Echter, omdat ZFS zo zwaar tegen je RAM aanhangt, en je RAM ook geen BBU (Battery BackUp) heeft, gaat dit heel lastig worden.
Dan zou je het memory moeten kunnen splitsen en ook replicatie op je memory toepassen met alle checks / failsafe's erbij.
Maar dan heb je vervolgens weer een andere SPOF.... je mainboard / CPU.
Dus hoever wil je gaan?

Je zou anders legio aan checks moeten inbouwen in RAM, (L2)ARC, ZIL en op je ZFS-store waarbij ik het vermoeden heb dat dit zijn doel voorbij zal schieten / de performance drastisch negatief zal beïnvloeden.
Maar hiervoor begeef ik mij op onbekend terrein en kan CiPHER je alles over vertellen.

Tav je backups....
1 * per maand???
Daarvan krijg ik jeuk op plekken waar het niet thuis hoort....

Ik maak iedere 6 uur een snapshot (4* per dag dus) en die worden 2 weken bewaard.
Backups lopen dagelijks met een rsync naar mijn QNAP van de belangrijkste data. (home-shares, foto's, video's etc. - als ik veel data heb gewijzigd (bijv. nieuwe foto's heb geplaatst) wil ik wel eens een rsync tussendoor draaien)
Software en andere brokken data die op internet verkrijgbaar zijn backup ik per definitie NIET.
Als er iets mis gaat en ik zou ze opnieuw nodige hebben, ga ik ze wel eerst downloaden.
(Internet is mijn grootste backup-bron :-) )

De verschillende MySQL-databases laat ik lekker op de achtergrond syncen naar een andere MySQL die ook op mijn QNAP draait.
Als er om wat voor reden de ..... uitbreekt, heb ik altijd nog wel mijn informatie beschikbaar.

Waar ligt voor mij het risico-punt?
6 uur vwb de snapshots, en 24 uur bij de rsync.
Fikt mijn NAS (of mijn hele huis) helemaal uit en is het ook niet meer te reanimeren.... Dan ben ik max 24 uur kwijt (1 QNAP staat buiten de deur), en dat is voor mij wel te overzien.
Dan is de meeste data nog wel redelijk makkelijk te her-produceren.

Je moet jezelf eens de vraag stellen "Wat mis ik als ik 1 maand data kwijt ben?"

[A1AD]

]Byte\[ schreef op donderdag 05 december 2013 @ 14:56:
Je moet jezelf eens de vraag stellen "Wat mis ik als ik 1 maand data kwijt ben?"

Je begrijpt mij verkeerd, ik maak +- elke 4 uur (hangt van het de data af) een snapshot welke onmiddellijk wordt gerepliceerd naar men remote storage.
Echter maak ik om de zoveel tijd nog eens een manuele backup op losse schijven. Die maandelijkse rsync (naar een extra remote site) zou dit dan vervangen omdat ik de snapshot repicaties niet kan vertrouwen in het geval van een bad ram.

Edit: mijn backups zitten wel goed. ik maak mij meer zorgen over mijn ram

Edit2: Als ik het goed begrijp is ECC een vereiste voor ZFS.

[ Voor 25% gewijzigd door A1AD op 05-12-2013 16:21 ]

[]Byte[]

Ohhhh.... dan had ik je idd verkeerd begrepen.
Vereiste is een groot woord.... Wenselijk? Ja!
Kost wel wat meer, maar geeft wel wat meer 'rust' en kan de nodige extra problemen voorkomen.

[Ultraman]

A1AD schreef op donderdag 05 december 2013 @ 15:54:
Edit2: Als ik het goed begrijp is ECC een vereiste voor ZFS.

ECC is zeker geen vereiste voor ZFS, die kan namelijk prima zonder functioneren, net als vrijwel elk ander filesystem.

Als je echter meer zekerheid wilt dat je data niet corrupt raakt door bijvoorbeeld een bitflip in RAM, dan wil je ECC hebben. Voor mijn server die 24/7 aan staat heb ik er voor gekozen om ECC te gebruiken. De kosten voor ECC RAM waren niet veel meer dan gewoon RAM, gecombineerd met het beetje extra zekerheid die het mij geeft heeft dat mij doen besluiten om het te gebruiken.
Tegenwoordig zou ik het ook graag in mijn desktop en laptop zien, maar helaas is dat niet de realiteit.

Anyhoe... je kunt gewoon ZFS gebruiken zonder RAM met ECC functionaliteit. Of je het nodig hebt hangt voornamelijk af van de eisen die je stelt aan je opslag.

[FireDrunk]

ECC helpt bij het gebruik van ZFS, maar is zoals Ultraman zegt zeker geen vereiste. In terminologie moet je dat zeker uit elkaar houden.

ECC kan Single Bit Errors opvangen, en kan Double Bit Errors detecteren.
Wil dat zeggen dat je geheugen nooit meer fouten maakt? Nee helemaal niet, geheugen kan 10000-den fouten in een paar seconden genereren en dan rent ECC ook heel hard weg.

[DRAFTER86]

Maar, is het RAM de laatste niet 'geverifieerde' schakel?
Ik bedoel, ZFS vangt/detecteert bitrot, netwerkverkeer heeft voor zover ik weet ook altijd checksums/parity checks?
Kijk, als het RAM de laatste bron van corrupte data is, dan is het het misschien wel waard.
Uiteraard moet je dan ook al je clients van ECC voorzien, wat in de praktijk misschien lastig is (smartphones...).

[FireDrunk]

De laatste zou ik niet durven zeggen, maar wel een van de laatste... Het is een simpele kosten/baten analyse. Als jij (meer) end-to-end integriteitscontrole wil, dan kan je voor ECC kiezen.

Is het de heilige graal? nope.

[FREAKJAM]

FreeNAS 9.2.0-RC Available

[BCC]

3x4tb en 128gb Ssd besteld :)!

[ilovebrewski]

Heeft er al iemand ervaring met Nas4free of ZFSguru als vm onder Windows server 2012 R2?
En of dit sowieso wel mogelijk is.

[Verwijderd]

Alles is mogelijk; maar waarom niet andersom? Ik vind het zelf het mooiste als ZFS directe disk toegang heeft. Als je Windows Server draait vanwege de services en configuratiemogelijkheden, dan lijkt me dat het virtualiseren hiervan minder problematisch is dan het virtualiseren van ZFS en de fysieke disks.

[duiveltje666]

Vraagje :
Ik probeer een raidz aan te maken met 3 disks ( Waarvan 1 uit een oude array) , dit lukt echter niet ivm die oude disk . Hoe los ik dit op? Opnieuw formatten en zerowriten hebben niet geholpen

[Kompaan]

duiveltje666 schreef op zaterdag 07 december 2013 @ 16:29:
Vraagje :
Ik probeer een raidz aan te maken met 3 disks ( Waarvan 1 uit een oude array) , dit lukt echter niet ivm die oude disk . Hoe los ik dit op? Opnieuw formatten en zerowriten hebben niet geholpen

zpool labelclear <dev>

[Verwijderd]

zpool create -f .....
of
zpool labelclear -f <dev>

Kortom, gebruik de -f (force) flag om disks die onderdeel zijn van een pool te overschrijven. Normaliter behoor je eerst de pool te destroyen, dus het gebruik van de -f flag is meer een botte en ruwe methode. Het voorkomen van user error staat hierbij natuurlijk voorop. Jij moet als gebruiker zelf afstand doen van je data. Dus importeren en destroyen van je oude pool is min of meer hoe het 'hoort'. Voordat je de disks voor een andere taak gaat gebruiken.

[Ultimation]

Ik voel mij echt een mongool dat ik dit moet vragen maar, ik kom er echt niet uit.

Wanneer ik in Ubuntu een share van ZFSGuru probeer te mounten via de console moet ik een password opgeven die er niet is.

[ Voor 7% gewijzigd door Ultimation op 07-12-2013 17:05 ]

[Verwijderd]

ZFSguru beta8 maakt gebruik van guest-access shares, dus moet je ook met guest inloggen. Als je met een gebruiker inlogt, dient ook het wachtwoord te kloppen (smbpasswd -a <username>). In beta9 kun je dit heerlijk via de GUI instellen. Beta9 gaat overigens erg goed en komt deze maand uit.

[FireDrunk]

Ultimation schreef op zaterdag 07 december 2013 @ 17:05:
Ik voel mij echt een mongool dat ik dit moet vragen maar, ik kom er echt niet uit.

Wanneer ik in Ubuntu een share van ZFSGuru probeer te mounten via de console moet ik een password opgeven die er niet is.

Watvoor share, een NFS share of een Samba share?

[Ultimation]

Ik word gek. Ik wil een x-aantal Samba shares in Ubuntu automounten vanaf ZFSGuru:

//ZFSGuru/share /media/share smbfs guest,uid=1001,iocharset=utf8 0 0

Nu ben ik niet zeker van de UID, die zal wel anders zijn.

[FireDrunk]

probeer eens als type cifs ipv smbfs.

[Ultimation]

Nu mount error (13) permission denied. UID?

[Verwijderd]

Kijk ook eens in de logs op de server.

tail -n 25 /var/log/samba/log.smbd
tail -n 25 /var/log/samba/log.<IPADDRESS>

[mcied]

Ik heb een zfs server gemaakt, nu zit ik alleen met een probleempje.

Ik kom met de kopieersnelheid vanuit windows niet boven de 85MB/seconde. naar mijn idee moet dit naar gigabit snelheden dus 110MB/s kunnen.

Dit is met 1 Bestand van 10 GB

Als ik de benchmark in zfsguru uitvoer is die snel genoeg:

ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark
Pool : DATA (10.9T, 44% full)
Test size : 64 GiB
normal read : 293 MB/s
normal write : 235 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 : 25 GB/s

Het is op deze manier aangesloten

Windows pc: Realtek PCIe GBE Family-controller ------

NETGEAR WNDR3700 ---------- TP-link GB-switch -------

ZFSGURU Nas: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet

[ItsValium]

Twee realtek nic's met twee hops ertussen, dan is 85 MB/s niet slecht hoor, controleer sowieso even driverversies van je netwerkkaarten, de settings op je switchen (manueel alles op 1gbit full duplex forceren om even te testen) ...

[ilovebrewski]

Verwijderd schreef op zaterdag 07 december 2013 @ 15:28:
Alles is mogelijk; maar waarom niet andersom? Ik vind het zelf het mooiste als ZFS directe disk toegang heeft. Als je Windows Server draait vanwege de services en configuratiemogelijkheden, dan lijkt me dat het virtualiseren hiervan minder problematisch is dan het virtualiseren van ZFS en de fysieke disks.

Vanwege meer ervaring met Windows is dit inderdaad mij voorkeur. Ik merk dat ik echt te weinig ervaring heb in de basis Freebsd om het zo in te stellen zoals je hier aangeeft. Hoewel er een hoop ondersteuning is probeer ik niet te veel basis vragen te stellen
Vindt het leuk om te proberen, maar soms wil je gewoon dat het werkt als je klaar bent . Zeker als je een vrouw thuis hebt die er ook gebruik van maakt .

Binnenkort is mijn nieuwe hardware binnen voor een tweede systeem en misschien dat ik het beide wel probeer en dan de keuze maak.

[A1AD]

Ik had dit gepost in het esx topic maar het lijkt me hier beter passen.

Ik test momenteel een esx5.5 host met een freenas 9.2 guest. Er zijn 3 disken doorgegeven via RDM met de nieuwe SATA controller.

Buiten de vele storm interrupts krijg ik na een weekje de volgende warning:

"WARNING: The volume backup (ZFS) status is ONLINE: One or more devices are configured to use a non-native block size. Expect reduced performance.Replace affected devices with devices that support the configured block size, or migrate data to a properly configured pool."

zpool status

pool: backup
state: ONLINE
status: One or more devices are configured to use a non-native block size.
Expect reduced performance.
action: Replace affected devices with devices that support the
configured block size, or migrate data to a properly configured
pool.
scan: scrub repaired 0 in 1h38m with 0 errors on Sat Dec 7 17:38:39 2013
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
gptid/fa2903b3-5aab-11e3-9d66-00505682d90e ONLINE 0 0 0
block size: 512B configured, 4096B native
gptid/facf8c55-5aab-11e3-9d66-00505682d90e ONLINE 0 0 0
block size: 512B configured, 4096B native
gptid/fb7094c6-5aab-11e3-9d66-00505682d90e ONLINE 0 0 0
block size: 512B configured, 4096B native

errors: No known data errors

Waarom krijg ik die warning nu pas..

[Verwijderd]

Wat fijn die gptid's van FreeNAS

glabel status
diskinfo -v /dev/gptid/fa2903b3-5aab-11e3-9d66-00505682d90e
diskinfo -v /dev/ada4 (pas aan naar aanleiding van glabel status output)
diskinfo -v /dev/gpt/<labelnaam> (pas aan naar aanleiding van glabel status output)
dmesg | grep ada4 (pas aan)

Kun je die info posten?

[A1AD]

Verwijderd schreef op zaterdag 07 december 2013 @ 19:52:
Kun je die info posten?

glabel status:

glabel status
Name Status Components
ufs/FreeNASs3 N/A ada0s3
ufs/FreeNASs4 N/A ada0s4
ufsid/529188b0e01869d0 N/A ada0s1a
ufs/FreeNASs1a N/A ada0s1a
ufs/FreeNASs2a N/A ada0s2a
gptid/fa2903b3-5aab-11e3-9d66-00505682d90e N/A ada1p2
gptid/facf8c55-5aab-11e3-9d66-00505682d90e N/A ada2p2
gptid/fb7094c6-5aab-11e3-9d66-00505682d90e N/A ada3p2

diskinfo -v /dev/gptid/fa2903b3-5aab-11e3-9d66-00505682d90e

/dev/gptid/fa2903b3-5aab-11e3-9d66-00505682d90e
512 # sectorsize
1498154343936 # mediasize in bytes (1.4T)
2926082703 # mediasize in sectors
0 # stripesize
2147549184 # stripeoffset
3096383 # Cylinders according to firmware.
15 # Heads according to firmware.
63 # Sectors according to firmware.
01000000000000000001s0 # Disk ident.

diskinfo -v /dev/ada1p2

512 # sectorsize
1498154343936 # mediasize in bytes (1.4T)
2926082703 # mediasize in sectors
0 # stripesize
2147549184 # stripeoffset
3096383 # Cylinders according to firmware.
15 # Heads according to firmware.
63 # Sectors according to firmware.
01000000000000000001 # Disk ident.

diskinfo -v /dev/gpt/<labelnaam> > hier volg ik je niet..

dmesg | grep ada1

ada1 at ahcich1 bus 0 scbus3 target 0 lun 0
ada1: <VMware Virtual SATA Hard Drive 00000001> ATA-6 SATA 2.x device
ada1: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 1430799MB (2930277168 512 byte sectors: 15H 63S/T 16383C)
ada1: Previously was known as ad6
ada1 at ahcich1 bus 0 scbus3 target 0 lun 0
ada1: <VMware Virtual SATA Hard Drive 00000001> ATA-6 SATA 2.x device
ada1: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 1430799MB (2930277168 512 byte sectors: 15H 63S/T 16383C)
ada1: Previously was known as ad6
ada1 at ahcich1 bus 0 scbus3 target 0 lun 0
ada1: <VMware Virtual SATA Hard Drive 00000001> ATA-6 SATA 2.x device
ada1: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 1430799MB (2930277168 512 byte sectors: 15H 63S/T 16383C)
ada1: Previously was known as ad6
GEOM_ELI: Device ada1p1.eli created.
GEOM_ELI: Device ada1p1.eli destroyed.
GEOM_ELI: Detached ada1p1.eli on last close.
ada1 at ahcich1 bus 0 scbus3 target 0 lun 0
ada1: <VMware Virtual SATA Hard Drive 00000001> ATA-6 SATA 2.x device
ada1: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 1430799MB (2930277168 512 byte sectors: 15H 63S/T 16383C)
ada1: Previously was known as ad6
GEOM_ELI: Device ada1p1.eli created.

[Verwijderd]

Ah oke. Je disks zijn gewoon 512B sectorsize. Het punt is volgens mij gewoon dat je disks hebt die fysiek 4K sectoren hebben, maar je pool is gemaakt met ashift=9 dus niet optimaal voor je disks.

Verder geen probleem, hooguit iets lagere performance. Aangezien je RAID0/striping draait en geen RAID-Z heb je hier vrijwel geen last van.

[A1AD]

Verwijderd schreef op zaterdag 07 december 2013 @ 20:33:
Ah oke. Je disks zijn gewoon 512B sectorsize. Het punt is volgens mij gewoon dat je disks hebt die fysiek 4K sectoren hebben, maar je pool is gemaakt met ashift=9 dus niet optimaal voor je disks.

Verder geen probleem, hooguit iets lagere performance. Aangezien je RAID0/striping draait en geen RAID-Z heb je hier vrijwel geen last van.

Volgens mij heb ik dat nergens kunnen instellen bij het aanmaken van de pool in freenas. Deze disken heb ik uit mijn vorige nas gerecupereerd waar ook steeds freenas op draaide. Op het oude systeem nooit deze warning gezien. 98% zeker dat dit toen ook ashift=9 was.

[Verwijderd]

Volgens mij kun je dit tegenwoordig in FreeNAS wel instellen? Als je pool al wat 'ouder' is, is het natuurlijk logisch dat deze ashift=9 default ingesteld werd. FreeNAS was daar niet zo snel mee als ZFSguru. Maar zelfs onder Solaris platform kun je ashift nu instellen dus volgens mij is dat nu geen probleem meer. Je kunt achteraf de ashift niet veranderen van je pool, dan moet je hem destroyen en opnieuw aanmaken, met dataverlies tot gevolg.

Maar in jouw geval is het niet zo erg. Je draait RAID0 dus het is niet zo dat bij sequential transfers je disks emulatie moeten uitvoeren, hooguit voor kleinere writes. Dan is het probleem al veel minder erg.

[A1AD]

Verwijderd schreef op zaterdag 07 december 2013 @ 20:57:
Maar in jouw geval is het niet zo erg.

Het is dan ook maar een test pool, ik zal hem eens opnieuw aanmaken.

btw: Deze pool is wel degelijk opnieuw aangemaakt in freenas 9.2. Dus geen import van de oude pool.

[Verwijderd]

Ik ken FreeNAS niet zo goed, maar het moet zeker mogelijk zijn de pool aan te maken als ashift=12. Als je dat niet in de interface kunt vinden, zou je wellicht het FreeNAS forum kunnen raadplegen.

[A1AD]

Verwijderd schreef op zaterdag 07 december 2013 @ 22:02:
Ik ken FreeNAS niet zo goed, maar het moet zeker mogelijk zijn de pool aan te maken als ashift=12. Als je dat niet in de interface kunt vinden, zou je wellicht het FreeNAS forum kunnen raadplegen.

Kan zijn. Ik vind het nog vreemder dat mijn main nas met 4TB schijven gewoon aangemaakt is met ashift=12 zonder dat ik iets heb moeten doen.
Het is een wilde gok, maar volgens mij hebben mijn 1.5TB schijven geen 4k sectoren (ik vind er niet onmiddellijk iets van terug op google). Freenas denkt om 1 of andere reden (esx-rdm?) opeens wel dat ze deze hebben.

Het resultaat van dmesg | grep ada1 geeft toch duidelijk 512 byte sectors weer?

Als ik even leuk ga zeggen op het freenas forum dat ik freenas heb draaien op een ESX host met RDM schijven gaan er daar een paar een hart aanval krijgen vermoed ik

[ Voor 3% gewijzigd door A1AD op 07-12-2013 23:08 ]

[mkroes]

ilovebrewski schreef op zaterdag 07 december 2013 @ 15:24:
Heeft er al iemand ervaring met Nas4free of ZFSguru als vm onder Windows server 2012 R2?
En of dit sowieso wel mogelijk is.

zoals CiPHER al zegt: alles is mogelijk. Alleen is de ondersteuning nog steeds verre van voltooid.
Voornamelijk de scsi en network driver leveren nog wat problemen op (netwerk is er wel maar alleen legacy, 100mbit dus).
Vanwaar de noodzaak om Nas4free of ZFSguru te draaien? Als je graag ZFS wil gebruiken kan ik je ZFS on Linux wel aanraden.

[Verwijderd]

Huidige '4K' schijven zijn Advanced Format schijven. Die presenteren zich als 512 byte sector aan de host vanwege compatibiliteit met XP en veel utilities die allemaal hardcoded 512 bytes verwachten.

offtopic:
Ik vind dat vieeezzzz; bewijs=millennium-bugs; luie vieze coders: it works for now, i know its going to break in the future, but i don't care-mentaliteit.

Maargoed dat je 512 bytes ziet is dus goed. Ik dacht namelijke ven dat ESXi RDM misschien iets met de sectorsize zou doen, dat zou echt niet kunnen namelijk want dat kan enorm veel problemen veroorzaken aangezien LBA getallen dan naar andere data verwijzen. Maar gelukkig lijkt daarvan geen sprake.

[A1AD]

Verwijderd schreef op zaterdag 07 december 2013 @ 23:22:
Maargoed dat je 512 bytes ziet is dus goed. Ik dacht namelijke ven dat ESXi RDM misschien iets met de sectorsize zou doen, dat zou echt niet kunnen namelijk want dat kan enorm veel problemen veroorzaken aangezien LBA getallen dan naar andere data verwijzen. Maar gelukkig lijkt daarvan geen sprake.

Er is toch iets niet pluis met RDM vermoed ik. Ik heb de specs van de schijven nagekeken en zoals je zelf hier kan zien op pagina 10 hebben ze dus 512 b / sector.

[Verwijderd]

Dat klopt dan toch met wat er wordt gedetecteerd?

(2930277168 512 byte sectors: 15H 63S/T 16383C)

[A1AD]

Ja maar waarom dan de foutboodschap: "One or more devices are configured to use a non-native block size"

edit: remember mijn zpool status? "block size: 512B configured, 4096B native"

[ Voor 28% gewijzigd door A1AD op 07-12-2013 23:36 ]

[Verwijderd]

Geen idee. Je draait 9.2 dus ZFS v5000. Voor mij zijn deze meldingen ook nieuw. Ik draai ook 9.2 en 10.0 thuis en heb die meldingen zelf niet. Ik heb vrijwel alleen maar 4K disks + SSDs. Mijn oude servers met 512B disks draaien nog oudere versies, die update ik liever niet. Conservatieve trekjes in een progressief persoon.

Maar ik zie het niet als een probleem. Tenzij je performance aantoonbaar slecht is denk ik niet dat je je hier druk om hoeft te maken. Die melding is sowieso nieuw en wellicht krijg je hem ten onrechte; ik weet simpelweg niet. Ik weet verder ook niet wat je zou kunnen proberen, afgezien van reguliere performance tests. Laat het er lekker bij zou ik zeggen.

[A1AD]

Verwijderd schreef op zaterdag 07 december 2013 @ 23:36:
Laat het er lekker bij zou ik zeggen.

Zal ik doen maar ik hou niet zo van warnings