Het grote ZFS topic

[abusimbal]

Hallo, ik had graag julllie opmerkingen.

Wil een ZFS server bouwen met Freenas.

Heb onderstaande hardware in gedachten:

Norco RPC-4020 20bay case
Supermicro X10SL7-F
Crucial CT2KIT102472BD160B 16GB
IBM ServeRAID M1015
Cooler Master V450 Semi-Modular

Twijfel over de CPU.
Intel Xeon E3-1220 V3 of Intel Xeon E3-1240L v3

Ik vraag mij het volgende af. Sinds deze 24/7 aanstaat en ik een zo laag mogelijk verbruik wens, welke CPU is dan in werkelijkheid zuiniger ?
De 1240L met zijn 25W TDP of de 1220W met 80W ?

Heeft het voor de rest nut een SSD te gebruiken voor chaching ?
Zoja, welke is dan beter ? Ik heb onderste in gedachten, deze hebben ook power loss protection.
Samsung 845DC Evo 240GB of een Crucial M550 256GB

[Compizfox]

Verwijderd schreef op vrijdag 05 december 2014 @ 21:52:
Kabelproblemen gechecked met SMART (UDMA CRC Error Count)?

Dat zal ik even moeten doen na een reboot van de host

Welke controller gebruik je?

AMD SB700.

Firmware van de SSD geupdate bedoel je? Heb je ook de BIOS firmware en/of firmware van je controller geupdate?

Ja.

Ik heb de BIOS nog niet geupdatet. En de firmware van de SATA-controller? Ik wist niet dat je die ook kon updaten.

[jacovn]

abusimbal schreef op zaterdag 06 december 2014 @ 21:34:
Norco RPC-4020 20bay case

Stop de gaten in de fanwall goed dicht anders koelen je hdds niet goed

Twijfel over de CPU.
Intel Xeon E3-1220 V3 of Intel Xeon E3-1240L v3

Ik vraag mij het volgende af. Sinds deze 24/7 aanstaat en ik een zo laag mogelijk verbruik wens, welke CPU is dan in werkelijkheid zuiniger ?
De 1240L met zijn 25W TDP of de 1220W met 80W ?

Zal weinig tot niets uitmaken. Je kunt alleen met de 1240L een kleinere koelfan gebruiken omdat die maximal 25 watt hoeft te verwerken denk ik.

[abusimbal]

@jacovn

Ok, en de gaten bij de drive caddy's openzetten.

Ja, ik ook al eens gelezen dat een lagere TDP niet altijd betekend zuiniger.
Bedankt voor de opmerkingen.

[Keiichi]

Hoe zou ik met de 'zfs list' alleen snapshot van een enkele dataset kunnen krijgen?

'zfs list -t snapshot tank/dataset', werkt niet.
'zfs list -t snapshot -r tank/dataset', wel, maar hierbij heb ik nog childern datasets als tank/dataset/meuk waarvan ik geen snapshots wil zien.

[Verwijderd]

zfs list -t snapshot -r tank | grep "tank/dataset"

[Keiichi]

Verwijderd schreef op maandag 08 december 2014 @ 00:49:
zfs list -t snapshot -r tank | grep "tank/dataset"

De child datasets hebben ook die naam in zich
Ik kan het opzich wel oplossen door het eerste deel van de output (voor script gebruik ik altijd -H voor makkelijk splitsen), te splitsen op @ en exact te kijken of dit deel een 1-op-1 match is met wat ik wil hebben.

[Verwijderd]

Oke probeer dan eens:

zfs list -t snapshot -r tank | grep "tank/dataset$"

Dus een $ aan het einde; je dient dat wel tussen " " te hebben staan. $ = regexp voor eind van de regel.

[FireDrunk]

Moet je dan niet grep -e doen?

[Verwijderd]

Zelf uitgeprobeerd hier en werkt prima. Werkt niet als je de " " vergeet.

[justice strike]

Ben wel even benieuwd naar dat arm systeempje. Als je dat arm systeempje vergelijkt met een atom avoton. Is de atom dat niet zuiniger (ook ondat het scrubben 44 uur duurt en dan ook meer stroom zal verbruiken)

[CurlyMo]

Een Hummingboad / Raspberry Pi / etc verbruiken zo'n 3 á 4 watt excl. harde schijf. Ik denk dat dat een uitgemaakte zaak is.

[justice strike]

Ik dacht dat de Atom C2350 een tdp had van 6w. maargoed die kan dan ook meer geheugen aanspreken.

[CurlyMo]

Denk eraan dat het bij die kleine ARM pc's om een verbruik van een volledig systeem gaat.

[justice strike]

Ik begrijp wat je bedoelt. Ik was alleen benieuwd naar de verhoudingen aangezien atom ook een SOC is (maar dan wel met extra hd controllers zal komen enzo).

[CurlyMo]

Ik zou overigens in alle gevallen iets anders aanraden dan een ARM behalve bij een enkele ZFS pool offsite backup. Wat ook wel belangrijk is om te vermelden is dat de Hummingboard er 1 van de 3 was die ik gesponsord heb gekregen om juist deze dingen te testen. Ik weet niet of ik hem ervoor aangeschaft zou hebben.

[ Voor 46% gewijzigd door CurlyMo op 08-12-2014 16:08 ]

[Bigs]

CurlyMo schreef op maandag 08 december 2014 @ 16:00:
Denk eraan dat het bij die kleine ARM pc's om een verbruik van een volledig systeem gaat.

Bij de Atom C2000 zit het grootste deel van de platform (incl. de netwerkcontroller excl PHY) ook in de CPU. Qua performance per watt doen die het echt wel goed, plus je hebt een standaard x86 systeem (dus veel ondersteunde OS'en) en ondersteuning voor 64GB RAM. Dan ga ik niet lopen rommelen met obscure ARM platforms (tenzij de Raspberry Pi zou voldoen, maar die voldoet wat mij betreft eigenlijk nergens voor).

[CurlyMo]

Ik ben het over bijna alles met je eens behalve je laatste statement

[Compizfox]

Zijn er dan ook van die ARM-bordjes met SATA? De Raspberry Pi bijvoorbeeld heeft enkel USB (2.0)

[CurlyMo]

BananaPi heeft SATA.

[abusimbal]

Compizfox schreef op maandag 08 december 2014 @ 18:45:
Zijn er dan ook van die ARM-bordjes met SATA? De Raspberry Pi bijvoorbeeld heeft enkel USB (2.0)

Deze heeft eSATA http://www.solid-run.com/product/cubox-i4pro/

[yamahabest]

Bij ZFS kan je hot spares hebben.
Wat is daar nu aan te raden?

Bijvoorbeeld RAID-Z met hot spare versus RAID-Z2 zonder hot spare: Je zou kunnen zeggen, de kans dat er nog een disk overlijdt bij rebuilden RAID-Z is aanwezig, dus je kan beter voor RAID-Z2 gaan.

Maar bij RAID-Z2 met hot spare versus RAID-Z3 zonder hot spare?

Wat is daar common practice, denk je eerst over de veiligheid na en daarna over hot spares?

[ Voor 40% gewijzigd door yamahabest op 08-12-2014 23:04 ]

[CurlyMo]

4 disk RAIDZ2 boven een 3 disk RAIDZ met één hotspare
4 disk RAIDZ2 + 1 disk backup boven een 5 disk RAIDZ3

Het veiligste qua bang for the buck is:
RAIDZ2 (+ local backup) + offsite backup.

Ook geen geneuzel met constant wisselen en wegleggen van je backup schijf. Als je huis af brand of alles word gestolen, dan val je gewoon terug op je offsite backup.

[yamahabest]

Ok, in de 2e regel bedoel je in plaats van "backup", denk ik, "hot spare"?

Daarnaast, kan je bij een degraded RAID-Z2, nog bij je data, of moet je dan net zoals bij RAID-Z eerst rebuilden voordat je weer verder kan? En zorgt RAID-Z2 dus alleen voor extra zekerheid tijdens het rebuilden?

[CurlyMo]

Nee, ik bedoel backup, want je weet RAID != backup

Je kan ik ZFS in elke configuratie bij degraded nog bij je data. Zie https://docs.oracle.com/cd/E19253-01/819-5461/gamno/ Zolang je pool maar niet faulted is. Dus je aanname over RAIDZ klopte al niet.

RAIDZ2 geeft je de garantie dat 2 schijven mogen falen voordat je je data verliest.

[yamahabest]

Ik weet dat RAID != backup is

Maar bedoel je bij deze "4 disk RAIDZ2 + 1 disk backup boven een 5 disk RAIDZ3", dan dat je die "backup" disk klaar moet hebben liggen voor als er een disk het begeeft?

[A1AD]

yamahabest schreef op maandag 08 december 2014 @ 23:15:
Ik weet dat RAID != backup is

Maar bedoel je bij deze "4 disk RAIDZ2 + 1 disk backup boven een 5 disk RAIDZ3", dan dat je die "backup" disk klaar moet hebben liggen voor als er een disk het begeeft?

Backup als in backup machine en niet een extra disk

[CurlyMo]

Nee, want dan zou ik het een hot spare hebben genoemd. Nu bedoel ik dus gewoon een backup die je met regelmatige intervallen bijwerkt. Hier gebeurt dat bijvoorbeeld elke nacht voor zowel de lokale als de offsite backup.

Mijn lokale backup is trouwens een normale externe harde schijf helemaal readonly voor gebruikers. Die is gelukkig bij de laatste inbraak niet gejat. Overheen gekeken of niet waardevol genoeg geschat

[ Voor 31% gewijzigd door CurlyMo op 08-12-2014 23:19 ]

[yamahabest]

Ok, een disk die groot genoeg is om al je data op te zetten, duidelijk.

[CurlyMo]

Een disk die groot genoeg is om al je belangrijke data op te zetten.

[yamahabest]

Juist, en dan zeg je eigenlijk dat een RAID-Z2 met een offline backup veilig genoeg is om geen hot spare nodig te zijn?
Als in, die kan je dan wel gaan halen als het moment daar gekomen is?

[ Voor 22% gewijzigd door yamahabest op 08-12-2014 23:26 ]

[A1AD]

CurlyMo schreef op maandag 08 december 2014 @ 23:18:
Die is gelukkig bij de laatste inbraak niet gejat. Overheen gekeken of niet waardevol genoeg geschat

Dat is 1 van de redenen waarom er hier ergens goed verborgen en niet in het huis zelf een 2 de machine rond middernacht back-up's draait.

Een geluk bij een ongeluk...

[CurlyMo]

Nee, ik zeg dat RAIDZ2 goed genoeg is voor data beschikbaarheid en dan een online backup goed genoeg is voor data veiligheid. Offline backups ga je vergeten bij te werken. Als je een offsite backup teveel gedoe vind, kan je ook twee backup schijven kopen en die elke week wisselen. Leg dan de offline backup in een kluis. Voordat ik aan de offsite backup ging had ik met een familielid geregeld dat bij elke visite de backup schijf werd omgewisseld. De offline backup lag dus veilig offsite en de online backup werd netjes elke nacht bijgewerkt zodat die bij een volgende visite weer meegegeven kon worden.

Het doel van een backup schijf is dus niet dat je die gaat gebruiken als het nodig is. Je weet dus nooit wanneer je terug moet vallen op je backup. Als ik dat zou kunnen voorspellen dan zou ik ook geen backups hebben. Verkeerd gelezen

Hot-spares haal je niet wanneer je hem nodig hebt, omdat het dan geen hot-spare meer is Het wordt dan een vervangingen van je defecte schijf en daarmee dus niet meer spare. En ja, bij RAIDZ2 kan je het veroorloven om op een maandag een nieuwe schijf te kopen mocht op zondag een schijf crashen (overdreven gezegd).

[ Voor 31% gewijzigd door CurlyMo op 08-12-2014 23:36 ]

[Verwijderd]

Het is onzin dat RAID of ZFS enkel geschikt is om beschikbaarheid van data te garanderen. De meeste mensen (waaronder het grootste deel niet-commerciële gebruikers) gebruiken het om hun data te beschermen tegen permanent dataverlies zoals schijfuitval. En dat werkt over het algemeen heel goed.

ZFS heeft daarnaast ook mogelijkheden om tegen additionele risico's te beschermen waar traditioneel een backup voor wordt gebruikt, zoals het beschermen tegen perongeluk verwijderde bestanden, virussen die aan bestanden knagen, en corruptie.

Dat betekent niet dat ZFS een backup kan vervangen, evenals dat een backup geen goed filesystem kan vervangen. Het beste werken ze complementair - dus wanneer je ze beide gebruikt. Maar dat hele RAID != backup is een verkeerde voorstelling. Een appel is geen peer, maar beide zijn wel fruitsoorten. Analoog hieraan zijn RAID en ZFS technieken die je data beschermen, evenals backups. Beide hebben een overlap aan bescherming en beide bieden bescherming die de ander niet biedt.

Daarom zijn ze niet gelijk, maar door te stellen dat RAID enkel voor het beschermen van beschikbaarheid van data is, is gewoon pure onzin. Dat is niet waar RAID het meeste voor gebruikt wordt. En als we over beschikbaarheid praten dan is high availability storage superieur aan RAID voor die taak.

[CurlyMo]

Als ik zeg beschikbaarheid van data, dan geeft dat natuurlijk ook aan dat je data niet corrupt raakt En ja, als je begint ben een NAS e.d. dan is het denk ik handiger om wat ongenuanceerde maar duidelijke info te krijgen dan overal tot in de diepte over geïnformeerd te worden. Laat iemand eerst maar eens een goede basis leggen en zich daarna druk maken over snapshots enzo.

[ Voor 57% gewijzigd door CurlyMo op 09-12-2014 00:10 ]

[FireDrunk]

Probleem is, dat op het grote boze internet, mensen vaak hooguit de laatste 10 pagina's lezen van dit soort topics voordat ze (al) een mening vormen. Als we allemaal onze ongezouten mening geven *kan* het wel eens voorkomen dat mensen te snel conclusies trekken...

nou zeg ik niet dat we het *niet* moeten doen, maar we moeten er wel mee oppassen... Ik ben nog steeds van mening dat RAID voor mij een voldoende geschikte backup is... Ik noem het een backup, terwijl andere mensen zeggen dat het misschien geen backup is, maar inderdaad een beschikbaarheidsgarantie(-verbetering ). Voor mijn situatie, en mijn portemonnee is het in ieder geval voldoende (vooralsnog).

Het blijft een lastig punt, en ik denk dat we in plaats van elkaar aanvallen beter allemaal onze eigen kant van het verhaal kunnen blijven laten horen, en dan de gebruiker zelf zijn mening laten vormen...

CurlyMo (en Q for that matter) zijn vaak conservatief, CiPHER is erg progressief, en ik zit ergens in het midden

Dat is niet erg, dat creëert een mooie synergie

[CurlyMo]

FireDrunk schreef op dinsdag 09 december 2014 @ 08:32:
CurlyMo (en Q for that matter) zijn vaak conservatief, CiPHER is erg progressief, en ik zit ergens in het midden

Herinner je ons andere topic nog Zoals aangaf geef ik informatie waarvan ik denk dat de gebruiker er op dat moment verder mee kan. Dus een gedoseerde diepte.

Voor nu is het simpel. Bouw je een NAS met 4(+) schijven kies dan voor ZFS RAIDZ2, met 2 schijven kies je voor een ZFS mirror. Daarna focussen we wel op de rest. Stap 2 is dan het hardware lijstje uitvogelen.

[funnyname]

Ideaal is toch:

MIRROR => 2
RAIDZ1 => 2^x + 1
RAIDZ2 => 2^x + 2

(voor zakelijk gelden natuurlijk combinatie mogelijkheden (RAIDZ3) voor meer redundancy)

[ Voor 40% gewijzigd door funnyname op 09-12-2014 09:49 . Reden: toevoeging ]

[matty___]

funnyname schreef op dinsdag 09 december 2014 @ 09:47:
Ideaal is toch:

MIRROR => 2
RAIDZ1 => 2^x + 1
RAIDZ2 => 2^x + 2

(voor zakelijk gelden natuurlijk combinatie mogelijkheden (RAIDZ3) voor meer redundancy)

Met 9 disks ofzo wil je geen raidz1 meer omdat de rebuild tijd te lang duurt en gedurende deze een andere schijf kan uitvallen waardoor je alles kwijt bent.

[CurlyMo]

In plaats van eerst de theorie helemaal in te duiken. Wat wil je uiteindelijk bereiken? Zorg dat de theorie de praktijk ondersteund en niet andersom

[Verwijderd]

FireDrunk schreef op dinsdag 09 december 2014 @ 08:32:
CurlyMo (en Q for that matter) zijn vaak conservatief, CiPHER is erg progressief, en ik zit ergens in het midden

Dat is niet erg, dat creëert een mooie synergie

Dat is mooi verwoord, FireDrunk.

[justice strike]

hotspare is makkelijk te gebruiken als je 2 arrays hebt. Je weet niet welke zal falen en je hebt niet genoeg geld voor meerdere dedicated schijven per array. Dat neem je een hotspare die voor elke kan voldoen.

heb je maar 1 array zou ik hem altijd aan de array toevoegen.

[FireDrunk]

Dat impliceert wel dat je al genoeg centjes hebt voor twee pools

[IceTeaGX]

ZFS is ook vooral gericht naar zakelijk gebruik. En daar spreek je veel sneller over meerdere pools.
Zelfbouw home NAS zit dan ook ergens op de grens tussen consumer en enterprise.

Je kan er onnoemelijk veel geld in proppen (voor een consument dan) want de prijzen kunnen exponentieel stijgen naar mate je meer features wilt.

[Verwijderd]

ZFS is juist bedoeld om met goedkope hardware en slimme software toch een hoog niveau van bescherming te bieden. Jeff Bonwick gaf namelijk af tegen EMC met de stelling RAID was all about being cheap (the I for Inexpensive) and somehow we ended up here: EMC.

Je kunt het zo duur maken als je wilt, natuurlijk. Hardeschijven van goud als je wilt. Maar de filosofie achter ZFS is juist dat je geen peperdure hardware meer nodig hebt maar dat je intelligente software gebruikt om je problemen op te lossen ipv peperdure hardware.

[Verwijderd]

Hallo,

Na de laatste upgrade van ubuntu 14.04 server met ZoL heb ik het volgende probleempje: mijn pool heb ik geimporteerd middels zpool import -d /dev/disk/by-id bigpool
Een zpool status geeft de juiste output. Echter, na een reboot geeft zpool status alle onderliggende devices weer middels sda, sdb, sdc etcetera.
Als ik dan een zpool export bigpool doe gevolgd door zpool import -d /dev/disk/by-id bigpool dan klopt het weer.
In dmesg is de enige zfs vermelding het volgende:
[ 9.789207] ZFS: Loaded module v0.6.3-3~trusty, ZFS pool version 5000, ZFS filesystem version 5

Ik heb hier, en op google gezocht maar niks kunnen vinden wat dit zou kunnen veroorzaken.
Iemand enig idee wat hier aan de hand zou kunnen zijn?
Op de server zijn alle ubuntu updates geinstalleerd.

Alvast bedankt,
Jacques

[FireDrunk]

Is een bekend probleem, ik heb het zelf ook gehad, en al bij HyperBart moeten fixen.

De oplossing is:

code:

zpool export [poolnaam]
echo manual > /etc/init/zpool-import.override
zpool import -d /dev/disk/by-id/ [poolnaam]
reboot

Het kan zo zijn, dat applicaties als SabNZBd roet in het eten gooien omdat ze 1 keer eerder gestart zijn dan je pool gemount wordt, waardoor SabNZBd directories aanmaakt ipv wacht tot je ZFS pool actief wordt.

Dit zorgt er later weer voor dat ZFS de pool niet kan mounten om dat de directories niet leeg zijn. Even opletten dus.

Succes!

[ Voor 39% gewijzigd door FireDrunk op 09-12-2014 11:19 ]

[Verwijderd]

FireDrunk, je bent een held! Bedankt voor de oplossing.

[IceTeaGX]

Zit nu een tijdje ZFSguru te testen, en ik merk dat onder memory usage alles op Unknown allocated staat.
Het is een virtueel systeem in ESXi, maar heb online toch ook gevonden dat dit zou moeten werken.

Moet ik hier nog iets voor doen om dit werkend te krijgen?

[Verwijderd]

Mja soms is je /var/run/dmesg.boot niet compleet. Daar haalt die pagina zijn data vandaan. Ik weet niet precies waarom die file er soms niet is of niet compleet is. Kun je verifiëren of je dit bestand hebt? Zo ja, kun je de inhoud ervan in een DM sturen?

[IceTeaGX]

Ik zie er enkel boot info tussen staan. niks realtime memory info. Als ik het goed voor heb is de eerste regel het einde van het boot proces (zover komt mijn huidige sessie toch). Regel 2 en 3 kan ik niet plaatsen maar hoort waarschijnlijk ook bij de rest van de shutdown. Dus tussen boot en shutdown niks.

code:

Trying to mount root from zfs:zfsroot/zfsguru/10.1-001 [rw]...
KLD green_saver.ko: depends on splash - not available or version mismatch
linker_load_file: Unsupported file type
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 0 0 done
All buffers synced.
Uptime: 11m31s

[Verwijderd]

De eerste regel hoort te zijn:

Copyright (c) 1992-2014 The FreeBSD Project.

De specifieke info waar de Memory pagina naar zoekt is:

real memory = 34359738368 (32768 MB)
avail memory = 33214791680 (31676 MB)

Als die informatie ontbreekt, dan is die dmesg.boot file toch niet zoals het hoort; de dmesg zoals bij boot-time. Daarom kan de memory manager de informatie niet goed parsen.

Gezien dat Jason en ik erg druk zijn om de volgende beta uit te brengen, kan ik er niet teveel in duiken. Het is namelijk een FreeBSD-specifiek iets. Zal ooit wel gefixed worden. Tot die tijd werkt de Memory pagina soms niet en soms wel, kennelijk.

[ Voor 15% gewijzigd door Verwijderd op 09-12-2014 12:45 ]

[CurlyMo]

Het blijft natuurlijk raar om dat uit dmesg te halen, terwijl dit ook gewoon op te vragen is via sysctl:

code:

# sysctl hw.realmem
hw.realmem: 17179869184
# sysctl hw.physmem
hw.physmem: 16798822400

[IceTeaGX]

De memory pagina op zich werkt, de geheugen info staat er ook op en in dmesg.
Alleen staat alles 100% Unknown allocated ipv application, inactive, cache ...

[Verwijderd]

CurlyMo schreef op dinsdag 09 december 2014 @ 13:15:
Het blijft natuurlijk raar om dat uit dmesg te halen, terwijl dit ook gewoon op te vragen is via sysctl:

Die informatie wijkt af van de info in de dmesg. Dat is waarom er óók informatie uit de dmesg gehaald wordt, niet alleen van de sysctl en van 'top'.

IceTeaGX schreef op dinsdag 09 december 2014 @ 13:17:
De memory pagina op zich werkt, de geheugen info staat er ook op en in dmesg.
Alleen staat alles 100% Unknown allocated ipv application, inactive, cache ...

Zou je me dan toch het /var/run/dmesg.boot bestand kunnen zenden via een DM-bericht? Eventuele privacygevoelige data kun je met X-karakters overschrijven. Maar zorg dat het verder accuraat is, dan kan ik de regular expression die gebruikt wordt erop loslaten.

[ Voor 5% gewijzigd door Verwijderd op 09-12-2014 13:38 ]

[FireDrunk]

Oh?

root@san:~ # cat /var/log/dmesg.today  | grep "real memory"
real memory  = 6442450944 (6144 MB)
real memory  = 6442450944 (6144 MB)
real memory  = 6442450944 (6144 MB)
root@san:~ # dmesg | grep "real memory"
real memory  = 6442450944 (6144 MB)
root@san:~ # sysctl hw.realmem
hw.realmem: 6442450944
root@san:~ # sysctl hw.physmem
hw.physmem: 6414761984

Physmem is volgens mij exclusief PCIe reserveringen (256MB) enzo... Dat is terecht...

[ Voor 10% gewijzigd door FireDrunk op 09-12-2014 14:08 ]

[Keiichi]

Ik ben op het moment bezig een complete pool + snapshots van een FreeBSD 10.0 naar 10.1 server te sturen. Ik noem ze even 'oud' en 'nieuw'. Op alle datasets heb ik compression lz4, welke door alle childs overgenomen worden. Paar dingen vallen me op:

- Ik heb een volume op 'oud', deze is 100G in 'zfs list'. Op 'nieuw' 2.95M. Best een verschilletje. Ik heb de volume ooit wel aangemaakt als zijnde 100G groot, volgens mij nooit echt iets mee gedaan (op z'n best gevuld met /dev/zero de waarde 'volsize' staat wel op 100G
- Bij 'zfs list' is de Used kolom op 'nieuw' eigenlijk overal kleiner. Op 'oud' is sinds het aanmaken van datasets compressie aan geweest.
- Lege snapshots zijn nu 1.5K groot, ipv 0 bytes.

Het zijn dingetje die ik me afvraag waardoor het komt. Ik dacht zelf bv met compressie dat er altijd even goed/slecht gecomprimeerd wordt.

[FireDrunk]

Sparse volume? (zfs create -V)

[Keiichi]

FireDrunk schreef op dinsdag 09 december 2014 @ 22:09:
Sparse volume? (zfs create -V)

Ik had verwacht dat grootte van het volume in 'zfs list' zou komen te staan, omdat het een soort van reservering is.

[FireDrunk]

Hmm, kan het hier ook niet zo snel vinden.

On another note:

FreeNAS 9.3.0 is er! Support voor ZFS-on-Root, de nieuwe kernel iSCSI daemon, NFS 4.1 en het updat mechanisme is verbeterd!

Klinkt erg goed!

[Verwijderd]

Omdat ze gebruik maken van Grub is er volgens mij geen ondersteuning voor Root-on-ZFS op RAID-Z pools, iemand die dit kan testen? Nieuwe kernel iSCSI en andere verbereringen zijn wel mooi. Alleen snap ik de keuze voor FreeBSD 9.3 niet zo; had dan gelijk doorgepakt naar 10.0 of 10.1.

[funnyname]

Ik ben aan het testen met VM's om te kijken welke ZFS optie het beste bij me past.
Hoe installeer ik FreeNAS root-on-ZFS, kun je dan tijdens de installatie al een Zpool aanmaken?

[FireDrunk]

@CiPHER, ik dacht dat grub al wel van raidz kon booten, maar kan het mis hebben.

@funnyname, ja dat verwacht ik wel, dat je dat gewoon tijdens de installer kan doen. Waarschijnlijk op dezelfde manier als de reguliere FreeBSD installer dat kan. Maar misschien hebben ze ook al een Live versie. Check het in een vm, en je weet het

[FREAKJAM]

In 9.3 zit volgens mij nu een install-wizard. Volgens mij staat er op youtube een mooi filmpje over de nieuwe features.

[FireDrunk]

Goed filmpje!

[funnyname]

Ja werkt, de system files worden op een ZFS mirror geplaatst, alleen kan je die schijven niet voor data gebruiken..

[FireDrunk]

Ook niet als je een extra filesystem op die pool aanmaakt?

[funnyname]

Het is geen standaard pool waar je bij kan, je kan de schijven of het volume ook niet importeren/bewerken

[Compizfox]

Ik heb me nu toch iets raars...

Ik heb een ZFSGuru server met een ZFS pool die sinds kort "Bad file descriptor"-errors geeft, bijvoorbeeld bij een ls:

# ls
ls: Dropbox.txt: Bad file descriptor

Deze zelfde error geeft ie ook als je een file probeert te verwijderen.

Er zijn een hele hoop files die deze error geven, maar ook weer niet allemaal.

Uiteraard heb ik al een scrub geprobeerd, maar dat helpt niets:

code:

scrub repaired 0 in 1h22m with 0 errors on Wed Dec 10 14:56:33 2014

Waardoor kan dit komen? Ik snap er niets van. Volgens mij is het filesystem (of de onderliggende schijven) niet corrupt, want dan zou de scrub dat moeten repairen (of op zijn minst opmerken)

Toevallig heb ik een paar dagen geleden FreeBSD geupgrade van 10.0-RELEASE naar 10.1-RELEASE, maar ik denk niet dat dat relevant is. De error zou trouwens best al langer aanwezig kunnen zijn: het is meer dat ik het toevallig nu opmerk.

[CurlyMo]

Wat zegt:

code:

stat Dropbox.txt

En:

code:

zpool status -x

[ Voor 31% gewijzigd door CurlyMo op 10-12-2014 20:31 ]

[Compizfox]

# stat Dropbox.txt
stat: Dropbox.txt: stat: Bad file descriptor
# zpool status -x
all pools are healthy

Ik kan de inhoud van de file trouwens wel lezen, zoals bijvoorbeeld met:

# cat Dropbox.txt
* inhoud van bestand...*

[ Voor 57% gewijzigd door Compizfox op 10-12-2014 20:49 ]

[CurlyMo]

En het tweede commando (na de edit)?

[Compizfox]

Die staat er bij-in, na mijn edit

[Q]

Raar. memtest
Kun je nog een oudere BSD versie draaien, van stick/cd en heb je dit dan ook?

[ Voor 90% gewijzigd door Q op 10-12-2014 21:46 ]

[Keiichi]

Op mijn zfs pool heb ik waarschijnlijk wat last van fragmentatie (scrub die soms langzaam gaat, 'gstat' geeft aan dat device 100% bezig zijn). Voor wat onderhoud had ik alle datasets naar een andere server gecopieerd als backup. Hier heb ik scrub op gedraaid en die was met 6 uurtjes klaar (deze andere server deed hier laatste 34 uur over)

Op de 'langzame' server ben ik nu alle schijven 1 voor 1 aan het vervangen voor een nog grotere pool. Als ik dit doe, werkt dat ook als soort van defragmentatie? (Ik heb begrepen dat het copieren van een dataset dit in feite wel doet)

[duiveltje666]

Kom net nog een "leuke" issue tegen :
Heb Zfsguru 10.1-RC1 naar 10.1-RELEASE Updated en nu kan ik geen pool meer selecteren om te benchmarken ..

[Verwijderd]

Compizfox schreef op woensdag 10 december 2014 @ 20:19:
Ik heb me nu toch iets raars...

Ik heb een ZFSGuru server met een ZFS pool die sinds kort "Bad file descriptor"-errors geeft, bijvoorbeeld bij een ls:

Er zijn een hele hoop files die deze error geven, maar ook weer niet allemaal.

Toevallig heb ik een paar dagen geleden FreeBSD geupgrade van 10.0-RELEASE naar 10.1-RELEASE, maar ik denk niet dat dat relevant is.

Ik denk dat dat wel relevant is.

Je hebt waarschijnlijk niet geupdate via ZFSguru maar handmatig. En ik denk dat je daarbij fouten hebt gemaakt. Hierdoor is er een mismatch tussen kernel/userland en/of config files. Waarschijnlijk heb je óf de userland niet geupdate met dezelfde versie als de geïnstalleerde kernel, maar nog waarschijnlijker is dat je 'mergemaster' niet juist hebt gedraaid. Dat is een tijdrovende procedure om alle configuratie files van het systeem te updaten. Als je dat niet correct doet, kan dat veel vage issues geven. Aangezien ZFS zelf prima in orde is, en je problemen begonnen vlak na de update, denk ik dat het vrijwel zeker is dat je hier je probleem moet zoeken.

Oplossing is: verwijder de bestanden niet, update je systeem op de goede methode of installeer vers, dan zijn je bestanden gewoon weer normaal te benaderen.

[FireDrunk]

Dat is vrij makkelijk te testen door even een livecd te gebruiken en de pool te importeren.

[Verwijderd]

Inderdaad ja.

Eventueel kun je wel upgraden volgens de binary upgrade procedure. Maar als je handmatig gaat updaten via build/install kernel+world, dan moet je ook mergemaster draaien. En dat is nog niet zo heel makkelijk als je bepaalde dingen wilt behouden.

De correcte procedure staat hier beschreven:
https://www.freebsd.org/d...s/handbook/makeworld.html

[ Voor 19% gewijzigd door Verwijderd op 11-12-2014 08:26 ]

[FireDrunk]

Dat vind ik toch wel een nadeel van BSD, dat is toch niet zo koek en ei, als je zou willen... Er staat zelfs dat je in sommige gevallen zelf naar single user mode moet en daar die vage config roundups moet doen...

Dan ben ik toch blij met do-release-upgrade van Ubuntu

[Verwijderd]

Ubuntu doet binary updates toch? Dat kun je bij FreeBSD ook; freebsd-update. Enige voorwaarde is wel dat je een GENERIC kernel hebt geinstalleerd en dat je van een 'pointrelease' komt. Dus van 10.0 naar 10.1 kan prima. Van 10-STABLE naar 10.1 niet.

De procedure hierboven is als je handmatig gaat updaten, en dat is zeker ingewikkeld en error-prone. Maar ik post het omdat ik denk dat Compizfox een dergelijke procedure heeft gevolgd, maar hierbij fouten heeft gemaakt. Meest voorkomende problemen gaan over mergemaster. Als je dat overslaat kunnen er heel vreemde dingen gebeuren. De userland en kernel is dan wel up to date, maar je zit nog met ouderwetse config files en scripts die het systeem reguleren. En dat wil je niet....

Daarom ook dat ZFSguru niet doet aan 'upgrades' maar altijd een verse installatie doet. Met de toekomstige Migration Manager kun je specifieke config files zoals van Samba meenemen, maar de rest wordt heerlijk schoon zodat dat nooit een probleem kan vormen.

[FireDrunk]

Ubuntu doet beide. ZFS is gemaakt op het DKMS (https://wiki.archlinux.or...mic_Kernel_Module_Support) systeem.

Hierdoor kan bij een binary kernel upgrade de kernel zien dat er modules vanaf source gecompileerd moeten worden, en doet dat automatisch voor je.

Hierdoor kan je (relatief) veilig je kernel upgraden, en zal Ubuntu zelf je 'custom' modules hercompileren voor de nieuwste versie.

Tijdens een release upgrade zouden *in principe* dus gewoon de DKMS triggers af moeten gaan die ervoor zorgen dat je ZFS modules netjes voor de nieuwste kernel gecompileerd worden.

[Verwijderd]

Oke maar dat zijn modules, eigenlijk een uitzondering. Update je bij Ubuntu normaliter door de kernel en alle userland (apps enzovoorts) zelf te compileren en te installeren?

De reguliere apt-get is natuurlijk allemaal binair, en daarmee worden ook kernel updates gedaan. Maar misschien kan het ook handmatig via source; maar wordt dat ook daadwerkelijk gedaan in significante mate, zoals bij BSD het geval is?

[FireDrunk]

Nee, uiteraard niet, het is geen source distributie (dat is eigenlijk alleen Gentoo die dat doet).
De kernel is precompiled door Canonical ja.

Je kan zelf de kernel compileren, maar dat wil je eigenlijk niet onder Ubuntu, want je verliest compatibiliteit met de package repo's. Dat zorgt voor veel ergernis...

(net als dat Freebsd-update niet meer goed werkt als je zelf je kernel hebt gecompileerd.)

[matty___]

FireDrunk schreef op donderdag 11 december 2014 @ 08:39:
Dat vind ik toch wel een nadeel van BSD, dat is toch niet zo koek en ei, als je zou willen... Er staat zelfs dat je in sommige gevallen zelf naar single user mode moet en daar die vage config roundups moet doen...

Dan ben ik toch blij met do-release-upgrade van Ubuntu

Vind je? Zijn 3 commando's. Single user mode doe ik alleen als ik een hele release om hoog ga maar zolang in een branch blijf is dat niet nodig.

[FireDrunk]

Op de een of andere manier, vind het ik proces minder transaparant... Ik heb niet het gevoel dat ik weet wat ik doe met die commando's. Dat zal voor het grootste gedeelte vast aan mijn ervaring ermee liggen.

Ik bedoel, ik heb ook met Gentoo gewerkt, en dat werkt nog ingewikkelder (maar ook weer fijner in veel gevallen).

Binnenkort ga ik misschien mijn Thinkpad weer eens voorzien van Gentoo, dus dan duik ik er vast weer in

[matty___]

FireDrunk schreef op donderdag 11 december 2014 @ 10:31:
Op de een of andere manier, vind het ik proces minder transaparant... Ik heb niet het gevoel dat ik weet wat ik doe met die commando's. Dat zal voor het grootste gedeelte vast aan mijn ervaring ermee liggen.

Ik bedoel, ik heb ook met Gentoo gewerkt, en dat werkt nog ingewikkelder (maar ook weer fijner in veel gevallen).

Binnenkort ga ik misschien mijn Thinkpad weer eens voorzien van Gentoo, dus dan duik ik er vast weer in

Ik geef toe dat de mergemaster de eerste keer wel een uitdaging is want je mag/moet alles overschrijven op 2 bestanden na (groups en passwd) anders ben je je users/pwds kwijt

[FireDrunk]

Haha, bijvoorbeeld, of per ongeluk dingen niet in single user mode doen... gaat ook wel eens mis...

[Compizfox]

Verwijderd schreef op donderdag 11 december 2014 @ 08:43:
Ubuntu doet binary updates toch? Dat kun je bij FreeBSD ook; freebsd-update. Enige voorwaarde is wel dat je een GENERIC kernel hebt geinstalleerd en dat je van een 'pointrelease' komt. Dus van 10.0 naar 10.1 kan prima. Van 10-STABLE naar 10.1 niet.

De procedure hierboven is als je handmatig gaat updaten, en dat is zeker ingewikkeld en error-prone. Maar ik post het omdat ik denk dat Compizfox een dergelijke procedure heeft gevolgd, maar hierbij fouten heeft gemaakt. Meest voorkomende problemen gaan over mergemaster. Als je dat overslaat kunnen er heel vreemde dingen gebeuren. De userland en kernel is dan wel up to date, maar je zit nog met ouderwetse config files en scripts die het systeem reguleren. En dat wil je niet....

Daarom ook dat ZFSguru niet doet aan 'upgrades' maar altijd een verse installatie doet. Met de toekomstige Migration Manager kun je specifieke config files zoals van Samba meenemen, maar de rest wordt heerlijk schoon zodat dat nooit een probleem kan vormen.

Ik heb niet handmatig geupdate met "make buildworld", maar gewoon met freebsd-update. Dat ging prima omdat ik eerst een GENERIC kernel heb gebakken.

Er is ook geen mismatch met de userland, want ik heb gewoon alle ports recompiled (zoals freebsd-update mij ook instrueerde te doen)

Verwijderd schreef op donderdag 11 december 2014 @ 08:08:
[...]
Aangezien ZFS zelf prima in orde is, en je problemen begonnen vlak na de update, denk ik dat het vrijwel zeker is dat je hier je probleem moet zoeken.

Oplossing is: verwijder de bestanden niet, update je systeem op de goede methode of installeer vers, dan zijn je bestanden gewoon weer normaal te benaderen.

Ik weet niet zeker of het probleem pas na de upgrade begonnen is. Het zou best kunnen dat het al eerder aanwezig was, maar ik het nu pas merk.

Ik weet het niet zo goed allemaal, ik denk dat ik maar eens ga testen door te booten met een schone live-CD.

EDIT:

Zojuist geboot met een ZFSGuru Live-CD en de pool geïmporteerd. Krijg gewoon weer hetzelfde probleem dus het lijkt me dat het niet aan m'n upgrade ligt.

Ik heb overigens ook geprobeerd om een snapshot terug te zetten, maar hier bleef hij op hangen: na het commando

zfs rollback Data/shares@2014-11-20

krijg ik geen output. Ik heb het over de nacht laten draaien maar er lijkt niks te gebeuren.

Ik denk dat ik de dataset maar ga destroyen; hopelijk hoopt dat en ben ik dan van het probleem af.

[ Voor 35% gewijzigd door Compizfox op 11-12-2014 12:10 ]

[Verwijderd]

Hm, dat is toch wel erg vreemd. In elk geval heb je wat dingen uitgesloten. Maar wat het dan wèl is?

[matty___]

Compizfox schreef op donderdag 11 december 2014 @ 10:47:

Ik heb overigens ook geprobeerd om een snapshot terug te zetten, maar hier bleef hij op hangen: na het commando

zfs rollback Data/shares@2014-11-20

krijg ik geen output. Ik heb het over de nacht laten draaien maar er lijkt niks te gebeuren.

Even los van dit probleem maar als een proces loopt en je ziet geen output kun je in FreeBSD/OSX met ctrl+t meer info krijgen over het proces en wat hij op dit moment aan het doen is.

[FireDrunk]

@CompizFox, is het niet zo dat omdat je de pool geimporteerd heb, het zo kan zijn dat het pool filesystem je root / overgemount heeft?

Dus als de fout daar in zit, je door het importeren van die pool, diezelfde fout in je draaiende live systeem introduceert?

[CurlyMo]

@CompizFox, is dit wat:
http://www.mail-archive.c...solaris.org/msg40286.html

[FREAKJAM]

Iemand Fedora 21 server al geprobeerd in combinatie met ZFS? Sinds versie 21 leveren ze ook de server edition welke wordt geleverd met bijvoorbeeld cockpit. Volgens mij is dat best cool in combinatie met ZFS.

Ik heb al een tijdje de boel op CentOS 7 draaien, maar vind het toch wel interessant dat Fedora de smaak "server" levert. Dit weekend eens spelen in VMWare.

[ Voor 10% gewijzigd door FREAKJAM op 12-12-2014 14:54 ]

[FireDrunk]

Inderdaad, ziet er zeker gaaf uit!

Vanmiddag kwam ik dit tegen:

Btier:
http://www.lessfs.com/wordpress/?p=924

Ik zat te denken...

2 * SSD in ZFS mirror
2 * Laptop Disks in ZFS Mirror
N disks in ZFS ZPool.

en dan 3 tiers maken, en het ding zelf laten uitzoeken wat waar moet komen...
Je kan zelf in Python migratie regels / scriptjes schrijven, waardoor je zelf eventueel voorkeuren kan maken...

Het werkt voor zover ik kan zien alleen blockbased, en (nog) niet file based... Maar misschien moet ik wat meer onderzoek doen...

[Keiichi]

code:

  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Dec 11 16:57:39 2014
        7.43T scanned out of 7.41T at 96.4M/s, (scan is slow, no estimated time)
        1.48T resilvered, 100.24% done
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz1-0                                      DEGRADED     0     0     0
            gptid/82774e62-01ec-11e3-a2d3-6805ca19b391  ONLINE       0     0     0
            gptid/116c9a77-01f7-11e3-8c63-6805ca19b391  ONLINE       0     0     0
            gptid/1211903e-01f7-11e3-8c63-6805ca19b391  ONLINE       0     0     0
            replacing-3                                 OFFLINE      0     0     0
              489847279025191050                        OFFLINE      0     0     0  was /dev/gptid/12999a6a-01f7-11e3-8c63-6805ca19b391
              ada4                                      ONLINE       0     0     0  (resilvering)
            ada5                                        ONLINE       0     0     0
        cache
          ada0p4                                        ONLINE       0     0     0

errors: No known data errors
[root@nas3 ~]# zpool iostat -v
                                           capacity     operations    bandwidth
pool                                    alloc   free   read  write   read  write
--------------------------------------  -----  -----  -----  -----  -----  -----
tank                                    7.42T  1.46T    850     72  64.3M   700K
  raidz1                                7.42T  1.46T    850     72  64.3M   700K
    gptid/82774e62-01ec-11e3-a2d3-6805ca19b391      -      -    626      7  16.3M   130K
    gptid/116c9a77-01f7-11e3-8c63-6805ca19b391      -      -    600      6  16.4M   130K
    gptid/1211903e-01f7-11e3-8c63-6805ca19b391      -      -    609      6  16.3M   130K
    replacing                               -      -      0    868      0  19.5M
      489847279025191050                    -      -    345      3  9.52M  24.5K
      ada4                                  -      -      0    538      0  19.5M
    ada5                                    -      -    353    271  9.32M  9.43M
cache                                       -      -      -      -      -      -
  ada0p4                                69.3G  16.0E    106      5  3.09M   602K
--------------------------------------  -----  -----  -----  -----  -----  -----

Wat is hier aan de hand scannen is verder dan de grootte van de pool, en ik heb 16ExaByte vrij op m'n cache device...

[FireDrunk]

BSD? ZoL?

[CurlyMo]

Dat gebeurt hier ook vaak genoeg. Geen zorgen over maken.

[FireDrunk]

Ik vind die devicenamen door elkaar anders best zorgelijk... Ene is via id, ander via device descriptor (ada4/ada5).

oh shoot, nu zie ik ook dat het BSD moet zijn

[Verwijderd]

Daarom heeft ZFSguru de GPT-IDs ook uitgeschakelt via een tunable. Gewoon altijd GPT labels, waarom zou je iets anders willen???

Ik vermoed dat het FreeNAS is of een oudere BSD versie. Mocht het na een reboot niet in orde zijn kun je altijd een nieuwere BSD versie proberen, zoals een ZFSguru Livecd, om de rebuild af te ronden en de pool in een normale staat terug te brengen. Daarna kun je weer terug naar een oudere versie, mocht die een vreemde bug hebben oid.