Het grote ZFS topic

[ph0t0nix]

Een vraag over ZFS send en receive:
Voor backups maak ik al jaren gebruik van rsnapshot. Elke nacht spring een USB kastje met backup drive aan en word een snapshot gemaakt en wordt die gebackupt.

Sinds ruim anderhalf jaar gebruik ik ZFS in plaats van LVM+Ext4, maar de backup methode is ongewijzigd gebleven. Nu de USB disk vol begon te raken heb ik een grotere disk gekocht en het idee was om dan meteen het backupproces aan te pakken d.m.v. zfs send en receive.

Om mijn schema van 12 maandelijkse, 4 wekelijkse en 7 dagelijkse backups niet meteen overhoop te gooien heb ik op de nieuwe disk een FS gemaakt (BackupPool/home) en data van de oude schijf er naartoe gersynct (beginnend bij de oudste maandelijkse backup) en telkens een snapshot gemaakt voor de volgende kopie. Dat ziet er allemaal prima uit, zfs list -o name -r -t snapshot BackupPool list ze allemaal.

Voor de nieuwe backups had ik het idee om eerst een snapshot op /home te maken en dan vervolgens een zfs send | zfs receive te doen naar BackupPool/home. Het liefst natuurlijk incremental. Dit lijkt echter niet te lukken. Twee vragen:

• Klopt het dat de snapshots voor een incremental zfs send beide op het bron-FS moeten bestaan? Dat is namelijk niet het geval bij mij (ik wil een van de snapshots op de USB disk gebruiken als 'bron') en zo te zien probeert ZFS de volledige hoeveelheid data over te pompen (en wil dan een leeg FS hebben).
• Sterker nog, kijkend naar de output van zfs send -vRn lijkt het wel alsof alle snapshots van /home meekomen. Of is zfs send -vp wat ik wil? (Er zijn naast de backup snapshots die uiteindelijk op de externe disk terecht komen ook andere snapshots die niet van belang zijn voor de backups.)

[Keiichi]

Ik heb met een zvol dat er ruim 2x de space gebruikt wordt die er op staan.

Ik heb een sparse zvol aangemaakt van 100G, helemaal volgeschreven en is 'zfs list' staat er meer dan het dubbel USED dan de zvol zelf is. Dit begint al vanaf het begin van het schrijven, is er 5G geschreven, dan is USED 10G.

Het enige wat ik kan vinden is dat het iets met blocksize te maken heeft, maar ik heb nu werkelijk geen flauw idee wat er mis is.

[FireDrunk]

Copies=2?

[CurlyMo]

ph0t0nix schreef op vrijdag 25 september 2015 @ 16:38:
Twee vragen:
• Klopt het dat de snapshots voor een incremental zfs send beide op het bron-FS moeten bestaan? Dat is namelijk niet het geval bij mij (ik wil een van de snapshots op de USB disk gebruiken als 'bron') en zo te zien probeert ZFS de volledige hoeveelheid data over te pompen (en wil dan een leeg FS hebben).

Ja, anders kan hij de delta's niet maken. Het zou ook erg risicovol zijn om te vertrouwen op de snapshots van twee verschillende locaties, omdat ZFS dan geen 100% zekerheid heeft over de consistentie van beide snapshots waartussen de delta's worden verstuurd.

• Sterker nog, kijkend naar de output van zfs send -vRn lijkt het wel alsof alle snapshots van /home meekomen. Of is zfs send -vp wat ik wil? (Er zijn naast de backup snapshots die uiteindelijk op de externe disk terecht komen ook andere snapshots die niet van belang zijn voor de backups.)

R betekent recursive. Of dat is wat je wil is aan jou.

[Keiichi]

FireDrunk schreef op vrijdag 25 september 2015 @ 17:02:
Copies=2?

Nope, slecht 1. Het is zelfs meer dan factor 2, heb nu bv 5.4g (uncompressable data overigens) en in zfs list meldt dit als 13.2G .Als filesysteem ,ufs2, helemaal leeg is, is de gerapporteerde grootte 700Mbytes ongeveer. (leeg na het verwijderen van alle bestanden + trim enabled)

[Verwijderd]

@Keiichi: gebruik je snapshots voor de ZVOL?

[Keiichi]

Verwijderd schreef op vrijdag 25 september 2015 @ 19:57:
@Keiichi: gebruik je snapshots voor de ZVOL?

Ook niet, ik heb net even zvol met verschillende 'volblocksize'es aangemaakt, en had dit uiteindelijk als zfs list resultaat

code:

tank/hosting_images/test_128k       8.48G  6.10T  8.48G  -
tank/hosting_images/test_16k        9.98G  6.10T  9.98G  -
tank/hosting_images/test_32k        9.76G  6.10T  9.76G  -
tank/hosting_images/test_4k         20.3G  6.10T  20.3G  -
tank/hosting_images/test_512         161G  6.10T   161G  -
tank/hosting_images/test_64k        8.52G  6.10T  8.52G  -
tank/hosting_images/test_8k         19.8G  6.10T  19.8G  -

disk usage:

code:

[root@nas /mnt]# du -d 1
1       ./test2
9024616 ./test_16k
9024616 ./test_64k
9024616 ./test_8k
1       ./test
9024616 ./test_4k
9024616 ./test_32k
9024616 ./test_512
9024616 ./test_128k

Ik heb in elke map het 1 groot bestand staan. Ik probeer ook beetje te snappen hoe en wat er nu eigenlijk allemaal gebeurd.

[DXaroth]

Keiichi schreef op vrijdag 25 september 2015 @ 20:18:
[...]


Ook niet, ik heb net even zvol met verschillende 'volblocksize'es aangemaakt, en had dit uiteindelijk als zfs list resultaat

code:

tank/hosting_images/test_128k       8.48G  6.10T  8.48G  -
tank/hosting_images/test_16k        9.98G  6.10T  9.98G  -
tank/hosting_images/test_32k        9.76G  6.10T  9.76G  -
tank/hosting_images/test_4k         20.3G  6.10T  20.3G  -
tank/hosting_images/test_512         161G  6.10T   161G  -
tank/hosting_images/test_64k        8.52G  6.10T  8.52G  -
tank/hosting_images/test_8k         19.8G  6.10T  19.8G  -

disk usage:

code:

[root@nas /mnt]# du -d 1
1       ./test2
9024616 ./test_16k
9024616 ./test_64k
9024616 ./test_8k
1       ./test
9024616 ./test_4k
9024616 ./test_32k
9024616 ./test_512
9024616 ./test_128k

Ik heb in elke map het 1 groot bestand staan. Ik probeer ook beetje te snappen hoe en wat er nu eigenlijk allemaal gebeurd.

wat is je test scenario? als in,wat heb je aangemaakt, hoe heb je bestand er in gezet, etc etc

[Keiichi]

DXaroth schreef op vrijdag 25 september 2015 @ 20:34:
[...]


wat is je test scenario? als in,wat heb je aangemaakt, hoe heb je bestand er in gezet, etc etc

code:

zfs create -s -o volblocksize=128K -V 100G tank/hosting_images/test_128k
newfs -U -t -O 2 /dev/zvol/tank/hosting_images/test_128k
mount /dev/zvol/tank/hosting_images/test_128k /mnt/test_128k/
cp /tank/iso/suse.tar /mnt/test_128k/

En dan 128k vervangen door verschillende sizes.

[ph0t0nix]

CurlyMo schreef op vrijdag 25 september 2015 @ 17:14:
[...]

Ja, anders kan hij de delta's niet maken. Het zou ook erg risicovol zijn om te vertrouwen op de snapshots van twee verschillende locaties, omdat ZFS dan geen 100% zekerheid heeft over de consistentie van beide snapshots waartussen de delta's worden verstuurd.

Dat klinkt logisch. Wel jammer, want dat betekent in dit geval dus dat ik twee kopieën van mijn data op de backup-schijf heb totdat we een jaar verder zijn en de laatste oude maandelijkse backup uitgerouleerd is.

Toch maar eens tijd om beter naar jouw backup script en HyperBart's aanpassing daarop te kijken.

R betekent recursive. Of dat is wat je wil is aan jou.

Weet je dat zeker? Als ik de man-page lees staat -R voor Replicatie (of bedoel je alle snapshots recursief in plaats van alle directories?):

Generate a replication stream package, which will replicate the specified filesystem, and all descendent file systems, up to the named snapshot. When received, all properties, snapshots, descendent file systems, and clones are preserved.

Maar goed, dus ook tussenliggende snapshots worden dus meegenomen door -R.

[CurlyMo]

ph0t0nix schreef op vrijdag 25 september 2015 @ 21:02:
Dat klinkt logisch. Wel jammer, want dat betekent in dit geval dus dat ik twee kopieën van mijn data op de backup-schijf heb totdat we een jaar verder zijn en de laatste oude maandelijkse backup uitgerouleerd is.

Waarom. Jij zegt zelf dat je 12 maandelijkse, 4 wekelijkse en 7 dagelijkse snapshots maakt. Je bewaart die 7 dagelijkse snapshots voor minimaal 4 weken. Na die 4 weken verwijder je alle oudere snapshots min één ook laat je al die vier wekelijkse staan en de 12 maandelijkse. Na 12 maanden verwijder je alle oudere snapshots en laat je de 12 maandelijkse staan.

In jouw situatie hoef je dus maar max 2 dagen historie aan snapshots te hebben mist je garantie hebt dat het elke dag werkt.

Weet je dat zeker? Als ik de man-page lees staat -R voor Replicatie (of bedoel je alle snapshots recursief in plaats van alle directories?):

Of je dat replication of recursion noemt maakt niet uit. Het idee is hetzelfde. Je kopieert de onderliggende structuur.

[ph0t0nix]

CurlyMo schreef op vrijdag 25 september 2015 @ 21:28:
[...]

Waarom. Jij zegt zelf dat je 12 maandelijkse, 4 wekelijkse en 7 dagelijkse snapshots maakt. Je bewaart die 7 dagelijkse snapshots voor minimaal 4 weken. Na die 4 weken verwijder je alle oudere snapshots min één ook laat je al die vier wekelijkse staan en de 12 maandelijkse. Na 12 maanden verwijder je alle oudere snapshots en laat je de 12 maandelijkse staan.

In jouw situatie hoef je dus maar max 2 dagen historie aan snapshots te hebben mist je garantie hebt dat het elke dag werkt.

Hmm, volgens mij snap ik je niet (of omgekeerd ). Momenteel ziet mijn backuppool er zo uit:

code:

$ zfs list -t all -r BackupPool/home
NAME                         USED  AVAIL  REFER  MOUNTPOINT
BackupPool/home              548G  1,25T   461G  /BackupPool/home
BackupPool/home@monthly.11  5,08G      -   263G  -
BackupPool/home@monthly.10  1,93G      -   282G  -
BackupPool/home@monthly.9   2,01G      -   288G  -
BackupPool/home@monthly.8   2,70G      -   292G  -
BackupPool/home@monthly.7   3,23G      -   294G  -
BackupPool/home@monthly.6   10,3G      -   303G  -
BackupPool/home@monthly.5   2,14G      -   295G  -
BackupPool/home@monthly.4   4,69G      -   303G  -
BackupPool/home@monthly.3   3,49G      -   335G  -
BackupPool/home@monthly.2   2,55G      -   344G  -
BackupPool/home@monthly.1   2,04G      -   347G  -
BackupPool/home@monthly.0   1,46G      -   352G  -
BackupPool/home@weekly.4    1,47G      -   355G  -
BackupPool/home@weekly.3    67,2M      -   355G  -
BackupPool/home@weekly.2     103M      -   355G  -
BackupPool/home@weekly.1     230M      -   356G  -
BackupPool/home@weekly.0    1,40G      -   362G  -
BackupPool/home@daily.7      898M      -   461G  -
BackupPool/home@daily.6      896M      -   461G  -
BackupPool/home@daily.5     13,8M      -   461G  -
BackupPool/home@daily.4     23,1M      -   461G  -
BackupPool/home@daily.3      965M      -   461G  -
BackupPool/home@daily.2      963M      -   461G  -
BackupPool/home@daily.1      128K      -   461G  -
BackupPool/home@daily.0      128K      -   461G  -

Dus 416GB aan data en dan nog wat snapshots, als ik het goed lees.

Als ik nu van mijn /home een snapshot maak en die naar BackupPool/home will overzetten zie ik het volgende:

code:

$ zfs send -vp storage/home@test -n 
send from @ to storage/home@test estimated size is 530G
total estimated size is 530G

Dan komt daar dus 530GB op de backuppool bij. Je hebt gelijk dat naarmate de tijd verstrijkt de oude dagelijkse, wekelijkse en maandelijkse snapshots kunnen worden verwijderd, maar de laatste maandelijke snapshot is toch nog zo'n 263GB. Dus ja, er komt steeds meer vrij, maar initieel heb ik toch bijna twee keer 500GB op te slaan.

En dan moet ik nog even uitvinden of zfs receive het wel accepeert om in BackupPool/home te ontvangen:

code:

$ zfs send -vp storage/home@test | zfs receive -vu -n BackupPool/home 
send from @ to storage/home@test estimated size is 530G
total estimated size is 530G
TIME        SENT   SNAPSHOT
cannot receive new filesystem stream: destination 'BackupPool/home' exists
must specify -F to overwrite it
warning: cannot send 'storage/home@test': Broken pipe

$ zfs send -vp storage/home@test | zfs receive -Fvu -n BackupPool/home
send from @ to storage/home@test estimated size is 530G
total estimated size is 530G
TIME        SENT   SNAPSHOT
cannot receive new filesystem stream: destination has snapshots (eg. BackupPool/home@monthly.11)
must destroy them to overwrite it
warning: cannot send 'storage/home@test': Broken pipe

[CurlyMo]

Je naamgeving is zeer verwarrend, want wat nu daily.0 is, is morgen daily.1. Ik zal het beschrijven a.d.v. datum snapshots. In jouw voorbeeld omgezet (uitgaande van vandaag = 2015-09-09)

code:

BackupPool/home
BackupPool/home@2014-09-01
BackupPool/home@2014-10-01
BackupPool/home@2014-11-01
BackupPool/home@2014-12-01
BackupPool/home@2015-01-01
BackupPool/home@2015-02-01
BackupPool/home@2015-03-01
BackupPool/home@2015-04-01
BackupPool/home@2015-05-01
BackupPool/home@2015-06-01
BackupPool/home@2015-07-01
BackupPool/home@2015-08-01
BackupPool/home@2015-08-03
BackupPool/home@2015-08-10
BackupPool/home@2015-08-17
BackupPool/home@2015-08-24
BackupPool/home@2015-08-31
BackupPool/home@2015-09-01
BackupPool/home@2015-09-03
BackupPool/home@2015-09-04
BackupPool/home@2015-09-05
BackupPool/home@2015-09-06
BackupPool/home@2015-09-07
BackupPool/home@2015-09-08
BackupPool/home@2015-09-09

Morgen maak je een snapshot 2015-09-10. Op de bron staat ook 2015-09-09. Je verstuurt nu de delta tussen 2015-09-09 en 2015-09-10. Op de backup komt er dus een 2015-09-10 bij. Vervolgens verwijder je 2015-09-03 (1 september bewaar je voor de maandelijkse snapshot en 3 september is geen maandag dus ook geen wekelijkse snapshot). Op de bron kan je nu 2015-09-09 verwijderen want je hebt al een delta verstuurt tussen 2015-09-09 en 2015-09-10. Overmorgen maak je snapshot 2015-09-11. Op de bron staat ook 2015-09-10. Je verstuurt nu de delta tussen 2015-09-10 en 2015-09-11. Op de backup komt er nu 2015-09-11 bij. Vervolgens verwijder je 2015-09-04 (opnieuw maakt deze geen deel uit van toekomstige wekelijkse snapshots en maandelijkse snapshots). Op de bron verwijder je 2015-09-10, want je hebt immer al de delta tussen 2015-09-10 en 2015-09-11 verstuurd. Enzovoort.

Conclusie, je hebt op de bron altijd maar 2 snapshots nodig.

Ontvangen in een andere doel FS kan gewoon. Dat doe ik zelf ook.

[ph0t0nix]

CurlyMo schreef op vrijdag 25 september 2015 @ 22:24:
Je naamgeving is zeer verwarrend, want wat nu daily.0 is, is morgen daily.1.

Dat ben ik met je eens, maar dat is de manier waarop rsnapshot zijn directories noemt en z'n rsync/hardlink 'magic' doet. Maar ik had bij het kopiëren van de backup directories op de oude Ext4 schijf naar de nieuw ZFS schijf de ZFS snapshots natuurlijk wel betere namen kunnen geven .

Conclusie, je hebt op de bron altijd maar 2 snapshots nodig.

Dat ben ik ook met je eens, maar het ik bedoelde op de doelschijf. Het probleem is (volgens mij) dat de ZFS snapshots in storage/home op basis waarvan de montly.*/weekly.*/daily.* rsnapshot backups zijn gemaakt niet meer bestaan (die verwijderde ik in mijn backup script zodra rsnapshot klaar was).

Dus zodra ik nu een nieuw snapshot storage/home@2015-09-26 maak en dat met zfs send naar de BackupPool wil sturen kan ik geen incremental doen (de eerste keer). Dus ik krijg naast de BackupPool/home@{monthly.*/weekly.*/daily.*} snapshots één keer weer een volledige data set. Daarna kan ik wel incremental versturen.

Ontvangen in een andere doel FS kan gewoon. Dat doe ik zelf ook.

Ja, dat klop. Maar mijn idee was dus om de nieuwe backups ook naar BackupPool/home te sturen. Dat lijkt niet te kunnen. Als ik het nu de volgende output goed begrijp moet ik mijn nieuwe backups in een nieuw FS plaatsen:

code:

$ zfs send -vp storage/home@test | zfs receive -vu -n BackupPool/home 
send from @ to storage/home@test estimated size is 530G
total estimated size is 530G
TIME        SENT   SNAPSHOT
cannot receive new filesystem stream: destination 'BackupPool/home' exists
must specify -F to overwrite it
warning: cannot send 'storage/home@test': Broken pipe

Want ook als ik de -F switch aan zfs receive toevoeg accepteert zfs receive mijn send niet:

code:

$ zfs send -vp storage/home@test | zfs receive -Fvu -n BackupPool/home
send from @ to storage/home@test estimated size is 530G
total estimated size is 530G
TIME        SENT   SNAPSHOT
cannot receive new filesystem stream: destination has snapshots (eg. BackupPool/home@monthly.11)
must destroy them to overwrite it
warning: cannot send 'storage/home@test': Broken pipe

[edit]
Of gaat 't toch lukken?

code:

$ zfs send -vpi storage/home@zfs-auto-snap_daily-2015-09-24-0559 storage/home@zfs-auto-snap_daily-2015-09-25-0622 | zfs receive -vu -n BackupPool/home
send from @zfs-auto-snap_daily-2015-09-24-0559 to storage/home@zfs-auto-snap_daily-2015-09-25-0622 estimated size is 156M
total estimated size is 156M
TIME        SENT   SNAPSHOT
would receive incremental stream of storage/home@zfs-auto-snap_daily-2015-09-25-0622 into BackupPool/home@zfs-auto-snap_daily-2015-09-25-0622
12:03:15   16,6M   storage/home@zfs-auto-snap_daily-2015-09-25-0622
12:03:16    176M   storage/home@zfs-auto-snap_daily-2015-09-25-0622

(hierbij gebruik ik even twee daily snapshots die zfs-auto-snapshot gemaakt heeft (die staan in principe los van mijn backups naar USB, maar zouden natuurlijk wel gebruikt kunnen worden)).

Maar dan weet ik niet zo goed wat er op de boelschijf terecht komt. Er wordt maar 156MB verstuurd, maar is het BackupPool/home FS dan wel een volledige backup?

[ Voor 18% gewijzigd door ph0t0nix op 26-09-2015 12:10 . Reden: zfs send -i probeersel met bestaande snapshots toegevoegd ]

[CurlyMo]

ph0t0nix schreef op zaterdag 26 september 2015 @ 12:03:
[...] Daarna kan ik wel incremental versturen.

Klopt.

Dat lijkt niet te kunnen. Als ik het nu de volgende output goed begrijp moet ik mijn nieuwe backups in een nieuw FS plaatsen:

Je kopieert delta van een filesystem. De bestandsstructuur moet dus helemaal overeenkomen met het bron FS.

[FREAKJAM]

Gister ZFS op mijn CentOS 7 VM (kernel 3.10) geupdate naar versie 0.6.5.1 (inclusief 2 nieuwe featureflags) en echt binnen het half uur (nadat ik mijn VM had gereboot) end_request i/o errors op alle zes mijn schijven. (var/log/messages). Harde schijven bekeken via smartctl (shorttest gedaan, smartctl -i, smartctl -a, en smartctl -H) en alle schijven zijn "PASSED" en geen vreemde errors te zien.

Overdag niet gemerkt, maar toen mijn pa en ik beiden in de avond iets aan het kijken waren via Plex, klapte de VM eruit. ZFS vervolgens gedowngrade naar de kmod-zfs versie.

That said, I may have a better solution available for CentOS 6/7 users. My suggestion would be to switch to the KMOD repository. These are binary packages for CentOS with weak-modules support which rely on the stable kABI. You can install them once and they will work with any of the stock CentOS kernels, no need to rebuild.

Gisteravond laat een scrub aangezet, en vannacht om 1.45 was weer de boel gecrashed. Hij had op het moment dat ik ging slapen (rond 0:00) al 2tb gescrubbed en moest 16kb aan data repairen. Op dit moment staan al mijn VM's uit en draait alleen ESXi. Vanmiddag een dagje vrij en dan maar de boel troubleshooten. Het zou toch niet mogen dat ik opeens i/o errors heb op mijn schijven na een ZFS-update en een reboot?

Straks de pool maar eens importen in ZFSGuru en een scrub draaien en eens kijken wat hij dan doet. Ik draai een RAIDZ2 pool op een Supermicro server met ESXi6 (zie signature).

[ Voor 10% gewijzigd door FREAKJAM op 29-09-2015 09:15 ]

[Bigs]

Dat KMOD repository lijkt me ook veel meer in de spirit van CentOS, ze hebben niet voor niets die ABI zo bevroren. Dat builden van enorme packages tijdens een yum update is bij ons ook wel eens mis gegaan. Het KMOD repository is alleen nog een beetje experimenteel (nog experimenteler) zo te lezen:

You can install them from the official repository but I'd suggest cleanly removing the DKMS version first. As always let me know if you hit any rough edges. ZFS still uses a few more symbols than exist in the stable kABI so it's possible things might break if one of those change. This is the main reason I didn't mention the KMOD repository before. However, thus far I haven't observed any issues due to this.

[FREAKJAM]

Ja, ik heb alles eerst netjes verwijderd van de normale ZFS installatie (spl, dkms, zfs etc). Zoals gezegd, straks even importeren in ZFSGuru en kijken wat er dan gebeurt. Vreemd vind ik het in ieder geval wel.

[ Voor 10% gewijzigd door FREAKJAM op 29-09-2015 09:10 ]

[FireDrunk]

Ik draai al een week ofzo 0.6.5.1 en heb nergens last van. (Fedora 22)

[FREAKJAM]

FireDrunk schreef op dinsdag 29 september 2015 @ 09:14:
Ik draai al een week ofzo 0.6.5.1 en heb nergens last van. (Fedora 22)

Grote verschil is dan wel dat Fedora kernel 4.x draait. Anyhow, vanmiddag troubleshooten. Als iemand nog bright ideas heeft of tips hoor ik die natuurlijk graag

[FireDrunk]

Monitor eens met top of er veel txg_sync processen lopen (een tiental is niet erg, een hondertal wordt al lastiger).

[FREAKJAM]

FireDrunk schreef op dinsdag 29 september 2015 @ 09:41:
Monitor eens met top of er veel txg_sync processen lopen (een tiental is niet erg, een hondertal wordt al lastiger).

Ik zal dadelijk eens kijken. Ik zie wel meer issues op github dat ZFS blijkbaar freezed op CentOS 7 sinds ZFS 0.6.5. Blijkbaar zou deze fix het moeten verhelpen, even zien hoe ik die straks moet toepassen.

[ Voor 16% gewijzigd door FREAKJAM op 29-09-2015 12:06 ]

[justice strike]

Heeft iemand hier zfs op usb drives recentelijk geprobeerd? usb3 is tegenwoordig snel genoeg. Legio externe ssd's te koop (of hdd's als dat zou moeten) en volgens mij zijn er behoorlijk wat usb poorten beschikbaar.

Is er iets inherent mis met USB of is dat gewoon veilig om te gebruiken (enige wat ik me kan bedenken is per ongeluk deze schijven ontkoppelen, dat zou ansich niet hoeven te gebeuren als je de interne usb poorten gebruikt en alles binnen de kast houdt)

Ik denk namelijk dat je zo vrij makkelijk ook goedkopere bordjes kunt gebruiken.

[ Voor 8% gewijzigd door justice strike op 29-09-2015 12:55 ]

[CurlyMo]

Ik gebruik zelf USB schijven als backup schijven. Werkt prima. Als je de schijf los koppelt dan geeft ZFS vanzelf een UNAVAIL aan. Een zpool export en import en het werkt dan weer.

[syl765]

Wij gebruike USB schijven ook als backup.
Wij gebruiken een pool bestaande uit twee schijven zonder raid.
De ene schijf gaat in de kluis, en de andere gaat bij een medewerker in huis.

Alleen als beide schijven bij elkaar zijn is de pool weer compleet en kan deze gebruikt worden.
Geeft toch weer wat extra veiligheid met de data buiten de deur.

[FireDrunk]

Ik heb ooit eens een pool gemaakt met USB3 disks maar dat werkte niet super. Waren WD Live schijven geloof ik, welke een JMicron USB3 controllertje hebben.

Misschien dat de drivers intussen verbeterd zijn hoor, maar toen ik ZFS er op los liet, ging het nogal stuk.

[Q]

Het beschermt wel tegen de noob die wat disks jat om op markplaats te verkopen, maar een beetje handig persoon haalt wel bruikbare data van een van de twee schijven.

Misschien een idee om iets met ZFS encryptie te doen? Dan kun je beide schijven ook redelijk veilig thuis neerleggen.

[justice strike]

FireDrunk schreef op dinsdag 29 september 2015 @ 13:23:
Ik heb ooit eens een pool gemaakt met USB3 disks maar dat werkte niet super. Waren WD Live schijven geloof ik, welke een JMicron USB3 controllertje hebben.

Misschien dat de drivers intussen verbeterd zijn hoor, maar toen ik ZFS er op los liet, ging het nogal stuk.

hoe slecht was het en waarom liep het stuk?

ansich hoef ik niet super performance, als je maar een gigabit lijn (of 2 ) kunt voltrekken

[Paul]

Q schreef op dinsdag 29 september 2015 @ 13:23:
Misschien een idee om iets met ZFS encryptie te doen? Dan kun je beide schijven ook redelijk veilig thuis neerleggen.

Met hem Als je CPU AES-NI ondersteunt merk je er qua performance zelfs helemaal niets van.

Je moet wel steeds dat je de pool (voor het eerst) wil benaderen een wachtwoord opgeven, maar als het je alleen gaat om de schijf die je mee naar huis neemt dan kun je best instellen dat dit wachtwoord onthouden mag worden

[FireDrunk]

justice strike schreef op dinsdag 29 september 2015 @ 16:02:
[...]

hoe slecht was het en waarom liep het stuk?

ansich hoef ik niet super performance, als je maar een gigabit lijn (of 2 ) kunt voltrekken

Het was een korte test, performance was ok, maar op een gegeven moment storte de verbinding tussen de USB Controller en de USB Disk in elkaar... Geen idee waarom.
(IO Timeouts in de kernel, of het nu een driver probleem was, geen idee).

Volgens mij getest onder FreeBSD toendertijd, maar het kan ook Linux geweest zijn.

Simpel gezegd: Voordat je een dure aanschaf doet, koop van dezelfde serie 1 klein schijfje, en test hem even met een single disk ZFS pool, voordat je over gaat op een grote aanschaf.

Mijn tests zijn alles behalve zuiver, dus baseer er maar niets op

[Q]

Paul schreef op dinsdag 29 september 2015 @ 16:44:
[...]
Met hem Als je CPU AES-NI ondersteunt merk je er qua performance zelfs helemaal niets van.

Je moet wel steeds dat je de pool (voor het eerst) wil benaderen een wachtwoord opgeven, maar als het je alleen gaat om de schijf die je mee naar huis neemt dan kun je best instellen dat dit wachtwoord onthouden mag worden

Dat maakt zo'n backup oplossing eigenlijk best ideaal.

Zelf ben ik niet helemaal fan van het idee dat je backup pool uit disks in een raid0 bestaat, maar een ouderwetse offsite tape backup is dat in feite ook, maar dan met tapes.

[Dadona]

FireDrunk schreef op dinsdag 29 september 2015 @ 16:55:
[...]

Het was een korte test, performance was ok, maar op een gegeven moment storte de verbinding tussen de USB Controller en de USB Disk in elkaar... Geen idee waarom.
(IO Timeouts in de kernel, of het nu een driver probleem was, geen idee).

Volgens mij getest onder FreeBSD toendertijd, maar het kan ook Linux geweest zijn.

Simpel gezegd: Voordat je een dure aanschaf doet, koop van dezelfde serie 1 klein schijfje, en test hem even met een single disk ZFS pool, voordat je over gaat op een grote aanschaf.

Mijn tests zijn alles behalve zuiver, dus baseer er maar niets op

Single disk pool werkt hier prima (nu iets van twee jaar onder Ubuntu). Ik heb één USB 2.0 disk Pool (1TB hdd in een cheap Chinese behuizing) en één USB 3.0 disk (1TB Western Digital Passport) pool. Allebei werken op zich prima. Wel heb ik soms met de USB 2.0 een issue na een reboot dat de computer de disk niet ziet. Even opnieuw aansluiten en alles werkt.

[FREAKJAM]

FireDrunk schreef op dinsdag 29 september 2015 @ 09:41:
Monitor eens met top of er veel txg_sync processen lopen (een tiental is niet erg, een hondertal wordt al lastiger).

De boel draait nu al ~18 uur in Freenas 9.3 zonder problemen. Zonder problemen weer bestanden kunnen afspelen in Plex en een volledige scrub gedaan (geen fouten) en /var/log/messages geeft ook geen i/o errors meer. Een jaar geleden al tegen een vervelende bug aangelopen in Ubuntu en nu in CentOS wat ik persoonlijk best vervelend vind. Gelukkig was de pool erg snel en makkelijk te importeren in FreeNAS. FreeNAS vindt alleen de sharenfs methode niet zo leuk, dus moest /etc/exports/zfs even leegmaken en de boel opnieuw sharen in de GUI zelf en toen kon ik weer netjes alles mounten via de clients.

Nu nog even bedenken wat wijsheid is. (Op FreeNAS blijven draaien of toch Fedora eens proberen).

[ Voor 3% gewijzigd door FREAKJAM op 30-09-2015 09:42 ]

[Q]

FREAKJAM schreef op woensdag 30 september 2015 @ 09:35:
Nu nog even bedenken wat wijsheid is. (Op FreeNAS blijven draaien of toch Fedora eens proberen).

FreeNAS = FreeBSD = denk ik veiligste. Persoonlijk nooit issues gehad met Debian, maar dat is slechts mijn ervaring (ik draai alles ZoL op Debian).

[Bigs]

Ik draai zelf ZFS op CentOS 7 en ik heb niet de problemen die freakjam beschrijft, maar het is allerminst stabiel (vreemde performance issues, ZFS kernel module verdwenen na updates). Wat dat betreft is ZFS op FreeBSD een vele malen betere ervaring.

[FREAKJAM]

Bij mij heeft het ook een jaar lang stabiel gedraaid, maar sinds de laatste 0.6.5.1 update met kernel-3.10.0-229 gaat er blijkbaar toch iets mis. Bug #3834 en bug #3822 liegen er in ieder geval niet om. Ik hou mijn VM in ieder geval nog intact. Wellicht dat ik het nog eens uit probeer wanneer 0.6.5.2 wordt uitgebracht.

[ Voor 15% gewijzigd door FREAKJAM op 30-09-2015 15:41 ]

[riwi]

FREAKJAM schreef op woensdag 30 september 2015 @ 15:40:
Bij mij heeft het ook een jaar lang stabiel gedraaid, maar sinds de laatste 0.6.5.1 update met kernel-3.10.0-229 gaat er blijkbaar toch iets mis. Bug #3834 en bug #3822 liegen er in ieder geval niet om. Ik hou mijn VM in ieder geval nog intact. Wellicht dat ik het nog eens uit probeer wanneer 0.6.5.2 wordt uitgebracht.

Hier ook al 2 dagen lockups met 0.6.5 onder Slackware met kernel 3.10.17. Het valt samen met een harddisk die een beetje hikt (sata errors) en dan hangt ineens de hele PC. Dood als een pier.
Als ik de probleem disk los koppel draait het wel goed. Net een nieuwe 3T schijf besteld want dat moet toch.

Maar ik ga nu ook even updaten naar het git-head niveau.

[Q]

Zo te zien is ZFS on Linux 0.6.5.2 uitgebracht op 30 september. http://zfsonlinux.org

[FREAKJAM]

Q schreef op donderdag 01 oktober 2015 @ 01:01:
Zo te zien is ZFS on Linux 0.6.5.2 uitgebracht op 30 september. http://zfsonlinux.org

Thanks voor de heads up. Via yum update nog niet binnen te halen, maar zal binnenkort wel beschikbaar zijn in de repo

[Bigs]

riwi schreef op woensdag 30 september 2015 @ 22:40:
[...]


Hier ook al 2 dagen lockups met 0.6.5 onder Slackware met kernel 3.10.17. Het valt samen met een harddisk die een beetje hikt (sata errors) en dan hangt ineens de hele PC. Dood als een pier.
Als ik de probleem disk los koppel draait het wel goed. Net een nieuwe 3T schijf besteld want dat moet toch.

Maar ik ga nu ook even updaten naar het git-head niveau.

Dat is wel echt matig.. heb onder FreeBSD wel falende schijven gehad maar dat was nooit een probleem. Zal binnenkort eens kijken of ik een testopstelling kan maken met CentOS en kijken hoe robuust het is want dit soort bugs mogen eigenlijk niet voorkomen.

[maomanna]

Na een reboot zijn mijn ZFS modules ineens weg. (ZOL op Ubuntu)

code:

root@centraalpunt:/# zpool list
The ZFS modules are not loaded.
Try running '/sbin/modprobe zfs' as root to load them.

code:

root@centraalpunt:/# dkms status
spl, 0.6.5.1, 3.19.0-25-generic, x86_64: installed
spl, 0.6.5.1, 3.19.0-28-generic, x86_64: installed
spl, 0.6.5.1, 3.19.0-30-generic, x86_64: installed
zfs, 0.6.5, 3.19.0-25-generic, x86_64: installed
zfs, 0.6.5, 3.19.0-28-generic, x86_64: installed

Enig idee hoe ik dat kan controleren?

[ Voor 78% gewijzigd door maomanna op 01-10-2015 13:17 ]

[begintmeta]

Wat bedoel je?

[maomanna]

ik heb een zpool, welke prima werkte.

Net rebootte ik de machine en zijn alle ZFS modules weg.
Het eerste commando geeft bij mij aan dat de ZFS modules niet geladen worden en dat er daarom dus (logisch ook) geen zpool is.

Het tweede commando geeft aan dat de files wel geinstalleerd zijn.

Ben nu aan het kijken wat de apt-get upgrade gaat doen.


Edit*
Dat was dus de clue.

code:

root@centraalpunt:/# dkms status
spl, 0.6.5.1, 3.19.0-25-generic, x86_64: installed
spl, 0.6.5.1, 3.19.0-28-generic, x86_64: installed
spl, 0.6.5.1, 3.19.0-30-generic, x86_64: installed
zfs, 0.6.5.1, 3.19.0-30-generic, x86_64: installed
[b]root@centraalpunt:/# zpool list[/b]
The ZFS modules are not loaded.
Try running '/sbin/modprobe zfs' as root to load them.
root@centraalpunt:/# /sbin/modprobe zfs
root@centraalpunt:/# zpool list[/b]
no pools available
root@centraalpunt:/# zpool import ZFSBulk
cannot mount '/ZFSBulk': directory is not empty
root@centraalpunt:/# zpool list
NAME      SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
ZFSBulk  18.1T  4.89T  13.2T         -      -    26%  1.00x  ONLINE  -

[ Voor 52% gewijzigd door maomanna op 01-10-2015 13:25 ]

[krijn1985]

Blijkbaar zijn je ZFS modules niet geladen. Wat krijg je als je dus /sbin/modprobe zfs doet als root (zoals is aangegeven bij de foutmelding die je zelf geeft)?

[maomanna]

krijn1985 schreef op donderdag 01 oktober 2015 @ 13:25:
Blijkbaar zijn je ZFS modules niet geladen. Wat krijg je als je dus /sbin/modprobe zfs doet als root (zoals is aangegeven bij de foutmelding die je zelf geeft)?

Door een update en upgrade van de repo heeft hij de nieuwe ZFS modules binnen gehaald, waarna ze wel weer werken.

Ligt het aan mij of is het vreemd dat de oude modules niet meer werken als er een nieuwe modules zijn?

[krijn1985]

Ik ben niet heel erg thuis in ZoL, maar een update zou dit niet moeten veroorzaken. Het kan zijn dat de ZFS modules niet automatisch gestart worden bij een reboot/opstarten. Nu je ze geupgrade hebt zijn ze misschien door de upgrade procedure gestart.

Je kunt dit natuurlijk even testen door weer een reboot uit te voeren nu;)

[maomanna]

Hij boot nu wel weer mee.

Bij boot start hij zpool-import Automatically import OpenZFS pools before mountall starts.
zpool-import.conf for Upstart. Alleen wil dat niet als de ZFS modules niet actief zijn...

[begintmeta]

maomanna schreef op donderdag 01 oktober 2015 @ 13:27:
...
Ligt het aan mij of is het vreemd dat de oude modules niet meer werken als er een nieuwe modules zijn?

Dat zou wel vreemd zijn inderdaad. Was het niet zo dat je een kernel had geboot waar je nog geen modules voor had?

[maomanna]

Zit even de log terug te kijken voor de reboot waarna het fout ging.

php5-common php5-mysql php5-cli php5-readline libapache2-mod-php5 php5-sqlite php5-gd php5-cgi php5-gmp php5-curl libcgmanager0:amd64 linux-image-3.19.0-30-generic linux-image-extra-3.19.0-30-generic linux-image-generic-lts-vivid linux-headers-3.19.0-30 linux-headers-3.19.0-30-generic linux-headers-generic-lts-vivid linux-generic-lts-vivid linux-libc-dev:amd64 php-pear php5 php5-dev python-software-properties python3-software-properties software-properties-common rpcbind

Die packages zijn geupdate. wssn heeft het dus te maken de 3.19.0.30, waar zfs, 0.6.5 niet mee overweg kan en voor 3.19.0-28-generic is. 0.6.5.1 was dan in de volgende update voor 3.19.0.30. Wellicht handig voor anderen die update hebben gekregen.

[riwi]

Bigs schreef op donderdag 01 oktober 2015 @ 09:35:
Dat is wel echt matig.. heb onder FreeBSD wel falende schijven gehad maar dat was nooit een probleem. Zal binnenkort eens kijken of ik een testopstelling kan maken met CentOS en kijken hoe robuust het is want dit soort bugs mogen eigenlijk niet voorkomen.

Inderdaad. Ik heb eerst een week op mijn testserver gedraaid met 0.6.5 en daarna de grotere bakken geupdate.Ik heb dit ook nog niet eerder meegemaakt. Misschien ook toeval dat net nu een harddisk staat te hikken. Ik heb al wel eerder harddisken gehad die haperen, maar dat leidde nooit tot zulke lock ups.

Na de update heb ik de probleem schijf weer geconnect en ge resilvered. Nu draait ie weer OK. Maar de nieuwe disk is al onderweg. Ik denk dat ik die toch vervang. Of ik doe nog een smart long test erop eerst.

[Loekie]

maomanna schreef op donderdag 01 oktober 2015 @ 13:54:
Zit even de log terug te kijken voor de reboot waarna het fout ging.


[...]


Die packages zijn geupdate. wssn heeft het dus te maken de 3.19.0.30, waar zfs, 0.6.5 niet mee overweg kan en voor 3.19.0-28-generic is. 0.6.5.1 was dan in de volgende update voor 3.19.0.30. Wellicht handig voor anderen die update hebben gekregen.

Nieuwe krnel dus, ubuntu draait na installeren kernel en headers normaal ook update script om modules te compileren(DKMS), heb je dat ook ergens gelogd?

[maomanna]

mmm die log kan ik helaas niet vinden (in webmin)

Is er nog een andere plek waar ik dat kan vinden?

[Loekie]

Meen /var/log/apt/term.log.<.n.gz> dan kun je greppen op dkms / image / linux om je een beeld te vormen.

[Compizfox]

Ik heb hier een fileserver met ZFS onder FreeBSD 10.2 waarvan ik vermoed dat er iets niet goed gaat met de L2ARC.

Dit is de output van zfs-stats -L:

code:

L2 ARC Summary: (DEGRADED)
        Passed Headroom:                        111.90m
        Tried Lock Failures:                    177.30k
        IO In Progress:                         1.20k
        Low Memory Aborts:                      18
        Free on Write:                          2.87k
        Writes While Full:                      7.08k
        R/W Clashes:                            9
        Bad Checksums:                          2.78m
        IO Errors:                              392.72k
        SPA Mismatch:                           2.43b

L2 ARC Size: (Adaptive)                         96.94   GiB
        Header Size:                    0.19%   187.50  MiB

L2 ARC Evicts:
        Lock Retries:                           9
        Upon Reading:                           0

L2 ARC Breakdown:                               35.87m
        Hit Ratio:                      11.85%  4.25m
        Miss Ratio:                     88.15%  31.62m
        Feeds:                                  1.79m

L2 ARC Buffer:
        Bytes Scanned:                          119.54  TiB
        Buffer Iterations:                      1.79m
        List Iterations:                        114.72m
        NULL List Iterations:                   193.84k

L2 ARC Writes:
        Writes Sent:                    100.00% 61.20k

Hier vallen me een aantal dingen aan op.

• Ten eerste: hij is "DEGRADED"? Wat betekent dit? Valt met Google niets over te vinden.
• "Bad Checksums", "IO Errors" en "SPA Mismatch" geven hoge waarden aan. Hoort dat?
• De "L2ARC Size" is 96.94 GiB terwijl de partitie maar 30 GB groot is. Dat kan dus niet kloppen.
• De hitratio is vrij laag.

Ik las iets over een bug in FreeBSD die ervoor zorgt dat de L2ARC groter groeit dan mogelijk is, wat dan weer voor allerlei rare problemen zorgt. Is dat wat er hier aan de hand is? Hoe kan ik dat fixen?

[FireDrunk]

De DKMS problemen die er zijn icm ZFSonLinux zijn zojuist getagged voor versie 0.6.5.3 / 0.7.0, dus hopelijk binnenkort easy peasy upgraden :
https://github.com/zfsonlinux/zfs/issues/3801

[matty___]

Compizfox schreef op donderdag 01 oktober 2015 @ 17:35:
Ik heb hier een fileserver met ZFS onder FreeBSD 10.2 waarvan ik vermoed dat er iets niet goed gaat met de L2ARC.

Dit is de output van zfs-stats -L:

code:

L2 ARC Summary: (DEGRADED)
        Passed Headroom:                        111.90m
        Tried Lock Failures:                    177.30k
        IO In Progress:                         1.20k
        Low Memory Aborts:                      18
        Free on Write:                          2.87k
        Writes While Full:                      7.08k
        R/W Clashes:                            9
        Bad Checksums:                          2.78m
        IO Errors:                              392.72k
        SPA Mismatch:                           2.43b

L2 ARC Size: (Adaptive)                         96.94   GiB
        Header Size:                    0.19%   187.50  MiB

L2 ARC Evicts:
        Lock Retries:                           9
        Upon Reading:                           0

L2 ARC Breakdown:                               35.87m
        Hit Ratio:                      11.85%  4.25m
        Miss Ratio:                     88.15%  31.62m
        Feeds:                                  1.79m

L2 ARC Buffer:
        Bytes Scanned:                          119.54  TiB
        Buffer Iterations:                      1.79m
        List Iterations:                        114.72m
        NULL List Iterations:                   193.84k

L2 ARC Writes:
        Writes Sent:                    100.00% 61.20k

Hier vallen me een aantal dingen aan op.

• Ten eerste: hij is "DEGRADED"? Wat betekent dit? Valt met Google niets over te vinden.
• "Bad Checksums", "IO Errors" en "SPA Mismatch" geven hoge waarden aan. Hoort dat?
• De "L2ARC Size" is 96.94 GiB terwijl de partitie maar 30 GB groot is. Dat kan dus niet kloppen.
• De hitratio is vrij laag.

Ik las iets over een bug in FreeBSD die ervoor zorgt dat de L2ARC groter groeit dan mogelijk is, wat dan weer voor allerlei rare problemen zorgt. Is dat wat er hier aan de hand is? Hoe kan ik dat fixen?

Al geprobeerd naar STABLE te gaan?

[maomanna]

FireDrunk schreef op vrijdag 02 oktober 2015 @ 09:41:
De DKMS problemen die er zijn icm ZFSonLinux zijn zojuist getagged voor versie 0.6.5.3 / 0.7.0, dus hopelijk binnenkort easy peasy upgraden :
https://github.com/zfsonlinux/zfs/issues/3801

Uit een post daar, voor nu een oplossing:

The only known workaround at this point is to run dkms install -k kernel.version before reboot and hope for the best.

[FireDrunk]

Ik deed het altijd na de reboot (ik heb geen ZFS on Root).

yum reinstall spl-dkms zfs-dkms

Werkt ook

[Wasp]

Ik heb wat advies nodig.

Ben van plan om twee HP Microservers te kopen (zie ook Twee HP Microservers (ZFS en virtualisatie apart))

Een van de HP Microservers zal puur als ZFS fileserver gaan dienen. De andere als VMWare Hypervisor, maar dat staat hier grotendeels los van omdat ik niet de VMDK's ga plaatsen op de ZFS fileserver, in plaats daarvan zal ik Samba en NFS shares gaan gebruiken.

Type data wat er op komt te staan zijn de gangbare zaken. Backups, films, muziek, foto's, en allerlei andere downloads.

Voor ZFS dacht zelf aan 3 schijven van 3 TB in de server in RAID-Z1 opstelling. Hiermee kan ik 1 schijf failure opvangen en heb ik als ik het goed ongeveer 5 TB netto ruimte.

Ik heb dan nog 1 drive bay over waarbij ik zelf dacht aan een SSD (60 GB). Ik kan er dan voor kiezen om daar ZFSGuru op te installeren en als bootdisk te gebruiken, maar wat misschien verstandiger is, is om ZFSGuru te installeren op een USB stick en de SSD te gebruiken als ZFS (meta)datacache. Het zou bv. fijn zijn om te kunnen browsen door files heen zonder dat de 3 disks upspinnen.

Maar ik hoor wel slechte verhalen over flash wear, waarbij je de ZFSguru install wellicht om zeep helpt. Kan ik bv. beter een iets grotere SSD kopen om vanaf te booten en een ander deel van de SSD gebruiken voor ZFS caching?

[Verwijderd]

Je kunt toch je huidige 60GB SSD voor meerdere doeleinden gebruiken? Dat is volgens mij niet mogelijk voor FreeNAS enzo, maar voor ZFSguru wel. Tenzij je veel services enzo gebruikt, heb je aan een 1GiB pool al genoeg theoretisch. Zou hem zelf wel iets groter maken overigens.

Dus dan heb je bijvoorbeeld 6GiB boot/systeem pool, een 40GiB L2ARC partitie en de rest unpartitioned. Lijkt me prima.

Als je de SSD nog niet hebt gekocht: neem een MX200 die je als SLC SSD kunt gebruiken. Dit geldt echter alleen voor het 250GB model. Die kun je dan als 120GB SSD gebruiken als je alles SLC wilt. Dat is voor L2ARC enorm nuttig en zorgt ook voor extra snelheid.

[FireDrunk]

Waar is je bron eigenlijk dat een MX200 een SLC SSD wordt als je hem goed provisioned? Is dat een firmware truukje?
Ben oprecht beniewd...

[Verwijderd]

Is gewoon hoe DWA werkt. Dat is de tegenhanger van de EVO firmware die min of meer hetzelfde doet voor Samsung SSDs, alleen die is fixed terwijl DWA dynamisch is en dus ook de hele SSD als SLC SSD kan maken.

Iemand had ergens een link naar een reviewsite hierover - ik kan hem zo snel niet vinden. De benchmarks bevestigden ook dat de feature daadwerkelijk werkt. Want zoiets kun je vrij gemakkelijk benchmarken - SLC is duidelijk sneller dan MLC.

Hier dus: http://techreport.com/rev...lid-state-drives-reviewed
Halverwege deze pagina staat uitgelegd hoe DWA werkt in de praktijk.

[ Voor 15% gewijzigd door Verwijderd op 03-10-2015 10:07 ]

[G-Tus]

Het lukt mij op de een of andere manier niet om een NTFS schijf te mounten onder ZFSguru 0.3.1/10.2.004. Ik heb de volgende commando's via SSH geprobeerd:

code:

[root@zfsguru /]# mount -t ntfs /dev/ada1p1 /mnt
mount: /dev/ada1p1: Operation not supported by device
[root@zfsguru /]# mount -t ntfs /dev/da3p1 /mnt
mount: /dev/da3p1: Operation not supported by device
[root@zfsguru /]# mount -t ntfs /dev/da4s1 /mnt
mount: /dev/da4s1: Operation not supported by device

ada1 is een GPT schijf op de Intel controller.
da3 is een GPT schijf op Dell PERC H310 geflashed naar LSI 9211-8i IT firmware.
da4 is een MBR schijf op Dell PERC H310 geflashed naar LSI 9211-8i IT firmware.

De schijven verschijnen wel in de WebGUI van ZFSguru en de map /dev.

Ergens op Internet gelezen dat eerst unmounten misschien nodig is, maar geeft deze fout:

code:

[root@zfsguru /]# umount -t ntfs /dev/da3
umount: /dev/da3: unknown file system

Gister tijdens een testsetup ook met NTFS-3G geprobeerd, zelfde fouten. Hoewel ik vandaag heb gelezen dat ik die mogelijk niet goed geïnstalleerd had, gezien de compatibiliteit van ZFSguru met portstree/FUSE etc.

Iemand enig idee waar het mis gaat?

[FireDrunk]

Probeer het eens via het ntfs-3g commando. Daar kan je ook mounts mee doen.

Sowieso is direct mounten op /mnt niet verstandig. Pak liever een subdir.

[G-Tus]

code:

[root@zfsguru /]# gpart show da4
=>        63  3907029105  da4  MBR  (1.8T)
          63        1985       - free -  (993K)
        2048  3907024896    1  ntfs  [active]  (1.8T)
  3907026944        2224       - free -  (1.1M)

[root@zfsguru /]# ntfs-3g /dev/da4s1 /mnt/various
fuse: failed to open fuse device: No such file or directory

Met ntfs-3g ook niet...

EDIT:

Het is gelukt. Blijkbaar wordt Fuse niet automatisch geladen: https://forums.freebsd.or...tfsfs-not-mounting.43260/

[ Voor 16% gewijzigd door G-Tus op 03-10-2015 19:23 ]

[Verwijderd]

Waarschijnlijk heb je de FUSE kernel module niet geladen.

[FireDrunk]

Verwijderd schreef op zaterdag 03 oktober 2015 @ 10:04:
Is gewoon hoe DWA werkt. Dat is de tegenhanger van de EVO firmware die min of meer hetzelfde doet voor Samsung SSDs, alleen die is fixed terwijl DWA dynamisch is en dus ook de hele SSD als SLC SSD kan maken.

Iemand had ergens een link naar een reviewsite hierover - ik kan hem zo snel niet vinden. De benchmarks bevestigden ook dat de feature daadwerkelijk werkt. Want zoiets kun je vrij gemakkelijk benchmarken - SLC is duidelijk sneller dan MLC.

Hier dus: http://techreport.com/rev...lid-state-drives-reviewed
Halverwege deze pagina staat uitgelegd hoe DWA werkt in de praktijk.

Ik wil je absoluut niet aanvallen, maar de term SLC is niet helemaal correct denk ik.
Waar we met z'n allen bang voor zijn in het kader van SLC vs MLC is:
1) Slijtage
2) Snelheid
3) Corrupte mapping tables bij power loss

Ik verwacht niet dat deze SSD alle karakteristieken van SLC ssd's kan nadoen, maar wat je zegt klopt wel aardig. De SSD zal hetzelfde presteren als een SLC drive.

Maar om een underprovisioned SSD nou een SLC SSD te noemen gaat mij persoonlijk iets te ver

Ik denk niet dat een MLC Cel waarvan je maar 1/2 van de 3 lagen beschrijft langer mee gaat dan een SLC cel. Juist daar zit de crux. Die cellen slijten net zo hard, omdat de spanning/lading nog steeds op dezelfde manier 'geschreven/gezet' moet worden.

Over punt 3: dat zit wel goed, ookal is het SLC gebruik op MLC cellen, heeft Crucial zijn power loss vaak wel op orde, dus dat zal wel goed gaan. (Want je weet overigens alleen maar uit de mapping tabellen of de hele MLC Cell nuttig is, of dat hij als SLC cel gebruikt is.)

Qua snelheid heb je dus gelijk, qua slijtage denk ik dat je het nog steeds niet moet willen.

[ Voor 8% gewijzigd door FireDrunk op 04-10-2015 10:54 ]

[dcm360]

FireDrunk schreef op zondag 04 oktober 2015 @ 10:53:
[...]

Ik denk niet dat een MLC Cel waarvan je maar 1/2 van de 3 lagen beschrijft langer mee gaat dan een SLC cel. Juist daar zit de crux. Die cellen slijten net zo hard, omdat de spanning/lading nog steeds op dezelfde manier 'geschreven/gezet' moet worden.

De cellen slijten net zo hard, maar dat is geen probleem. Een cel blijft bruikbaar zolang er met grote zekerheid bepaald kan worden welke waarde in de cel was weggeschreven. Stel je hebt een cel waarin je waarden wegschrijft in de range [0..3]. Bij gebruik als MLC is de cel defect zodra een weggeschreven 0 te veel op een weggeschreven 1 lijkt, bij gebruik als SLC is de cel pas defect zodra een weggeschreven 0 te veel op een weggeschreven 3 lijkt (dat is bij de waarde wanneer bij MLC de kritische grens tussen een 1 en een 2 overschreden zou worden).

Eigenlijk zouden 'versleten' MLC-cellen vaak nog prima ingezet kunnen worden als SLC-cel. Maarja, dan heb je dus wel een SSD die na verloop van tijd krimpt.

[Q]

Ik loop tegen een probleem aan. Mijn harde schijven spinnen telkens op ondanks dat ik alle processen op mijn machine heb gekilled.

Kan er binnen ZFS iets zijn waardoor ZFS mijn disks wekt uit spindown?

[Compizfox]

matty___ schreef op vrijdag 02 oktober 2015 @ 09:53:
[...]

Al geprobeerd naar STABLE te gaan?

Nee, maar dat was ik eigenlijk ook niet van plan. Ik begreep namelijk ook dat het niet mogelijk is om van/naar -STABLE te gaan met freebsd-update? Of klopt dat niet?

---

Q schreef op zondag 04 oktober 2015 @ 20:01:
Ik loop tegen een probleem aan. Mijn harde schijven spinnen telkens op ondanks dat ik alle processen op mijn machine heb gekilled.

Kan er binnen ZFS iets zijn waardoor ZFS mijn disks wekt uit spindown?

Gaat het om schijven waar je OS op is geïnstalleerd, of om data-schijven? Heb je software draaien die van de deze schijven leest, of er naar schrijft? (denk aan een bittorrent-client of zo)

[Q]

Compizfox schreef op zondag 04 oktober 2015 @ 20:05:
Gaat het om schijven waar je OS op is geïnstalleerd, of om data-schijven? Heb je software draaien die van de deze schijven leest, of er naar schrijft? (denk aan een bittorrent-client of zo)

Het gaat specifiek om de pool, dus data only.
Ik heb alle processen op mijn box gekilled. Tot aan ssh aan toe.

Ik heb zelfs mijn l2arc van mijn pool getrokken. Dat heb ik zonet gedaan, eens kijken of dat nog effect heeft.

Helpt ook niet.

Ik vraag me af of andere ZoL gebruikers hier last van hebben. Het maakt mij niet zoveel uit want ik zet mijn NAS uit. Maar als je box 24/7 aan staat is dit best klote.

[ Voor 21% gewijzigd door Q op 04-10-2015 20:26 ]

[Verwijderd]

Exporteer de pool zelf ook - zo kun je even uitsluiten of het inderdaad ZFS is. Importeer dan je pool maar mount je ZFS filesystems niet, dan kun je uitsluiten dat het niet ZFS is maar een proces wat iets schrijft naar je pool.

Ik ken een geval bij ZFSguru wat op de LiveCD ZFS beperkt heeft tot 64MiB RAM. Dit heeft een vreemd effect dat elke x seconden er iets naar de pool wordt geschreven, precies gelijk met de txg_timeout waarde. Ook als de pool read-only werd gemount, ook als alle filesystems unmounted waren. Het hield alleen op als de pool echt geëxporteerd werd.

Dus gewoon even zoeken naar het isoleren van dingen. En ik weet niet of je bij Linux iets als 'init 1' kunt doen? Dan draai je alleen de kernel + een shell, oftewel single user mode. Dat is heerlijk om echt alles uit te sluiten qua processen.

[Q]

Bedankt, het lijkt er sterk op dat het niet ZFS is.

Na een zpool export hoor ik de drives nog steeds opspinnen.
Dus het is een kernel of controller issue oid.

De processen heb ik allemaal gekilled en met ps ax nagelopen.

Ik zal eens kijken of ik met de megacli tool wat kan zien op de controllers.
edit: wordt ik ook niet wijzer van.

[ Voor 5% gewijzigd door Q op 04-10-2015 21:29 ]

[Compizfox]

Verwijderd schreef op zondag 04 oktober 2015 @ 20:30:
Dus gewoon even zoeken naar het isoleren van dingen. En ik weet niet of je bij Linux iets als 'init 1' kunt doen? Dan draai je alleen de kernel + een shell, oftewel single user mode. Dat is heerlijk om echt alles uit te sluiten qua processen.

Ja hoor, dat kan. Heet onder Linux ook gewoon "single-user mode". Geen idee hoe dat precies gaat met systemd eigenlijk maar vroeger onder sysvinit was dat dan een bepaald runlevel.

[Q]

init 1 en zfs export hebben niet geholpen. Het is jammer maar ik ga er nu verder geen tijd aan besteden. Mogelijk is het een issue met de schijven of in combinatie met de M1015 wiens firmware nooit door mij is geupdated. Bedankt voor de tips zover.

[ Voor 5% gewijzigd door Q op 04-10-2015 22:38 ]

[FireDrunk]

Zelfs init1 heeft niet geholpen? Dat is wel heel extreem... Misschien SMART monitoring vanuit je BIOS ofzo? Of in het geval van IPMI tooling iets van monitoring ofzo?

[maomanna]

Ik had gister mn disks aangesloten voor mn raidz2, allemaal op mn Dell PERC H310.
Heeft die domme kaart mn disks letters (dev/sd*) gewijzigd waardoor mn bulk pool corrupt is...

Kan ik zpool replace gebruiken om de juiste disks toe te voegen en mn data terug online te krijgen?

[Bigs]

maomanna schreef op maandag 05 oktober 2015 @ 08:48:
Ik had gister mn disks aangesloten voor mn raidz2, allemaal op mn Dell PERC H310.
Heeft die domme kaart mn disks letters (dev/sd*) gewijzigd waardoor mn bulk pool corrupt is...

Kan ik zpool replace gebruiken om de juiste disks toe te voegen en mn data terug online te krijgen?

Wat is de uitvoer van zpool status? Het wisselen van drive letters zou volgens mij niet uit moeten maken, ZFS scant bij de import al je block devices en herkent dan zelf de disks uit je pool(s) ongeacht onder welk pad ze zitten.

[Verwijderd]

Hier hebben FireDrunk en ik het eerder al over gehad; en volgens mij was hij van mening dat dit dus niet zou mogen. Ik heb het vaak genoeg gezien en het betekent volgens mij dat Linux geen device tasting toepast zoals BSD dat doet.

In elk geval, opnieuw importeren zou het probleem moeten oplossen. Maar dat ZoL dus niet tegen veranderde device nodes kan is iets wat ik koppel aan de begindagen van ZFS onder FreeBSD 7.0-CURRENT, waar dit probleem ook speelde. Maar dat is echt al heel lang geleden. Jammer dat ZoL op dit gebied (en anderen) nog flink achterloopt. Ik vind dit niet kunnen... Bedenk alleen al hoeveel mensen denken dat hun pool echt corrupt is; want dat staat er niet voor de lol, denken ze....

[FireDrunk]

Daar heeft het weer weinig mee te maken.
Device tasting geld alleen voor herkenning van wat er daadwerkelijk op de disk staat. Als er geen enkele partitie op staat, valt er weinig te herkennen.

Als maomanna zijn zpool doodleuk gemaakt heeft door 'zpool create /dev/sda /dev/sdb' te doen, blijft er weinig 'tasting' over.

Er staat daarna gewoon een tweetal devices in zijn zpool.cache waardoor zfs precies die device links gewoon gaat uitlezen.

Als die devices gewijzigd zijn, heb je inderdaad een uitdaging.

Wat je het beste kan doen:

zpool export [pool]
zpool import -d /dev/disk/by-id/

Dat zou beter moeten werken.

Je moet in ieder geval *niet* zpool replace gaan gebruiken!

[ Voor 9% gewijzigd door FireDrunk op 05-10-2015 09:19 ]

[maomanna]

De uitdraai van zpool status ZFSBulk is

code:

pool: ZFSBulk
 state: UNAVAIL
status: One or more devices could not be used because the label is missing
        or invalid.  There are insufficient replicas for the pool to continue
        functioning.
action: Destroy and re-create the pool from
        a backup source.
   see: http://zfsonlinux.org/msg/ZFS-8000-5E
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        ZFSBulk     UNAVAIL      0     0     0  insufficient replicas
          raidz1-0  UNAVAIL      0     0     0  insufficient replicas
            sdb     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     FAULTED      0     0     0  corrupted data
            sdg     FAULTED      0     0     0  corrupted data
            sdh     UNAVAIL      0     0     0  corrupted data

De driveletters zijn nu:


Daarbij is te zien dat nu 1x 4TB niet aangesloten is (straks even kijken hoe dat zit)
sdh was een 4TB schijf en is nu een 2TB schijf, terwijl die kabels niet gewijzigd zijn.

Stiekem hoop ik dat de kabel van de 5e 4TB schijf los zit waardoor hij niet herkent wordt en zodra die aangesloten wordt het weer doet en de pool blijft.

de ZFSBulk heb ik gemaakt via ZFSGuru (waarvoor dank CiPHER!)

de tweede pool, RaidZ2, is gemaakt met: zpool create raidz2 /dev/disk/by-partlabel/RZ2-1 /dev/disk/by-partlabel/RZ2-2 /dev/disk/by-partlabel/RZ2-3

code:

root@centraalpunt:/# zpool status datapool
  pool: datapool
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        datapool    ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            RZ2-1   ONLINE       0     0     0
            RZ2-2   ONLINE       0     0     0
            RZ2-3   ONLINE       0     0     0

errors: No known data errors

Edit:
Heb gelijk maar even /dev/sdf gesmart:

code:

Offline data collection status  Offline data collection activity was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status  The previous self-test routine completed without error or no self-test has ever been run.
Total time to complete Offline data collection  602 seconds.
Offline data collection capabilities    SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities  Saves SMART data before entering power-saving mode.
Supports SMART auto save timer.
Error logging capability    Error logging supported.
General Purpose Logging supported.
Short self-test routine recommended polling time    1 minutes.
Extended self-test routine recommended polling time 522 minutes.
Conveyance self-test routine recommended polling time   2 minutes.
SCT capabilities    SCT Status supported.
Raw Read Error Rate     -    159356056 (Normalized: 117)
Spin Up Time            -    0 (Normalized: 092)
Start Stop Count        -    24 (Normalized: 100)
Reallocated Sector Ct   -    0 (Normalized: 100)
Seek Error Rate         -    93124284 (Normalized: 079)
Power On Hours          -    3815 (Normalized: 096)
Spin Retry Count        -    0 (Normalized: 100)
Power Cycle Count       -    24 (Normalized: 100)
Runtime Bad Block       -    1 (Normalized: 099)
End-to-End Error        -    0 (Normalized: 100)
Reported Uncorrect      -    0 (Normalized: 100)
Command Timeout         -    0 (Normalized: 100)
High Fly Writes         -    6 (Normalized: 094)
Airflow Temperature Cel -    26 (Normalized: 074)
G-Sense Error Rate      -    0 (Normalized: 100)
Power-Off Retract Count -    23 (Normalized: 100)
Load Cycle Count        -    429 (Normalized: 100)
Temperature Celsius     -    26 (Normalized: 026)
Current Pending Sector  -    0 (Normalized: 100)
Offline Uncorrectable   -    0 (Normalized: 100)
Head Flying Hours       -    3728h+07m+03.302s (Normalized: 100)
Total LBAs Written      -    22562215883 (Normalized: 100)
Total LBAs Read         -    102995374047 (Normalized: 100)

op basis hiervan lijkt het erop dat de disk niet overleden is waardoor ik de data niet kwijt ben, ondanks dat ZFS hem als Faulted neerzet bij zpool status

[ Voor 39% gewijzigd door maomanna op 05-10-2015 10:03 ]

[maomanna]

FireDrunk schreef op maandag 05 oktober 2015 @ 09:18:
Wat je het beste kan doen:

zpool export [pool]
zpool import -d /dev/disk/by-id/

Dat zou beter moeten werken.

Je moet in ieder geval *niet* zpool replace gaan gebruiken!

code:

root@centraalpunt:/# zpool export ZFSBulk
cannot export 'ZFSBulk': one or more devices is currently unavailable

Logisch natuurlijk. Er is immers een incompleet ding. Ik verwacht/hoop dat de 5e disk het probleem verhelpt.

Zolang ik maar 1x erop kan en 1 map eraf kan halen is het prima.

[ Voor 5% gewijzigd door maomanna op 05-10-2015 11:42 ]

[aadje93]

Het begin is er



(3 maal lsi 9211-8i, de "handigere" variant van de beroemde IBM kaart door zijn aansluitingen achterop)

En de kast waar deze mooie kaartjes in verwerkt gaan worden:



Nu nog wachten op de overige hardware uit NL (duurt gek genoeg langer dan een stel raid kaarten uit hong kong)

Plan is 4x Z2 6disk arrays met 4TB schijven, langzaam beginnen met 1 vdev om dit uit te breiden naar een grote zpool van bruto 64TB effectief.

Hebben jullie nog tips omtrent het eventueel om flashen van deze kaarten (weet niet zeker of ze standaard op IT mode zitten gezien ze als HBA geadverteerd worden, nu nog niet de mogelijkheid om het te checken)

Overige hardware:

#	Product	Prijs	Subtotaal
1	Intel Xeon E5-1620 v3 Boxed	€ 309,70	€ 309,70
1	Supermicro X10SRL-F (Retail Pack)	€ 305,25	€ 305,25
6	WD Green WD40EZRX	€ 139,50	€ 837,-
4	Crucial CT16G4RFD4213	€ 128,-	€ 512,-
Bekijk collectie Importeer producten		Totaal	€ 1.963,95

(voeding heb ik nog, 1kw xfx beestje, moet ruim voldoende zijn voor de piek-startup)

[ Voor 54% gewijzigd door aadje93 op 05-10-2015 11:25 ]

[maomanna]

netjes!
ben benieuwd!

Welke kast heb je daar?

[Q]

FireDrunk schreef op maandag 05 oktober 2015 @ 07:28:
Zelfs init1 heeft niet geholpen? Dat is wel heel extreem... Misschien SMART monitoring vanuit je BIOS ofzo? Of in het geval van IPMI tooling iets van monitoring ofzo?

Ik zal nog eens kijken of ik iets kan zien in het BIOS van de 3 x IBM 1015 en anders geef ik het op. Het zou nog iets met de kernel kunnen zijn maar dan moet ik een soort 'tcpdump' op een SATA poort gaan zetten, misschien dat ik dat nog eens kan uitvissen.

Wat betreft ZoL, op de site staat duidelijk dat je nooit /dev/sd? moet gebruiken in je pool, altijd /dev/disk/by-xx (waar xx kan zijn id/path etc). Maar je kunt er inderdaad van herstellen op de manier die Firedrunk heeft beschreven. (been there, done that).

[aadje93]

De kast is een rpc 4220 als ik het goed heb, recent overgenomen van een tweaker dienmij contacteerde op mijn vraag ad (die nog open blijft voor eventueel das buildje aan deze machine). De kasten zijn volgensmij het zelfde als ipc model. Alleen nog even zoeken naar een 120mm fan paneel

[DXaroth]

[edit] geen onnodige discussies starten maar

@Aadje, interessante kast, laat ons weten als het draait

[ Voor 105% gewijzigd door DXaroth op 05-10-2015 12:27 ]

[maomanna]

FireDrunk schreef op maandag 05 oktober 2015 @ 09:18:
Wat je het beste kan doen:

zpool export [pool]
zpool import -d /dev/disk/by-id/

Dat zou beter moeten werken.

Je moet in ieder geval *niet* zpool replace gaan gebruiken!

Daarmee verlies ik niet alle data? Het klinkt veelbelovend! Dan is mijn hoop daar op gevestigd

[Pantagruel]

maomanna schreef op maandag 05 oktober 2015 @ 12:51:
[...]


Daarmee verlies ik niet alle data? Het klinkt veelbelovend! Dan is mijn hoop daar op gevestigd

Yep, als 't ware bereidt je de pool voor om in een andere machine zijn leven voort te zetten en unmount je alle gemounte file systems.
Vervolgens importeer je de pool op basis van device ID en niet op basis van de device letter (/dev/sdX) welke wel eens kan/wil veranderen (verschillende oorzaken).

[maomanna]

klinkt goed. mn vertrouwen begint weer te groeien in een positieve afloop.

Heb nog wel iets gevonden, soort gelijk iets:
https://github.com/zfsonlinux/zfs/issues/1390

[justice strike]

aadje93 schreef op maandag 05 oktober 2015 @ 11:23:
...
Plan is 4x Z2 6disk arrays met 4TB schijven, langzaam beginnen met 1 vdev om dit uit te breiden naar een grote zpool van bruto 64TB effectief.

Is het niet handiger om naar raid z3 te gaan voordat je een nieuwe vdev overweegt? in principe is dat efficienter gebruik van je hd's (of meer betrouwbaardheid met het zelfde aantal schijven)

[FireDrunk]

Q schreef op maandag 05 oktober 2015 @ 12:03:
[...]


Ik zal nog eens kijken of ik iets kan zien in het BIOS van de 3 x IBM 1015 en anders geef ik het op. Het zou nog iets met de kernel kunnen zijn maar dan moet ik een soort 'tcpdump' op een SATA poort gaan zetten, misschien dat ik dat nog eens kan uitvissen.

Was jij het niet ook die zijn kaarten niet naar -IT firmware geflashed had?

[aadje93]

justice strike schreef op maandag 05 oktober 2015 @ 14:03:
[...]


Is het niet handiger om naar raid z3 te gaan voordat je een nieuwe vdev overweegt? in principe is dat efficienter gebruik van je hd's (of meer betrouwbaardheid met het zelfde aantal schijven)

Efficienter gebruik van de hdd's denk ik niet gezien je er één extra aan parity per vdev verliest. Ik wil in groepen van 6 schijven max werken ivm upgradebaarheid (een vdev is te vervangen in stappen per schijf naar grotere capaciteit, groter dan 6 gaat het me teveel rebuilds kosten)

Ik denk dus aan raidz2 per groep van 6 schijven. Dat betekend circa 33% parity, wat ik acceptabel vind. Misschien dat ik alsnog raidz3 doe op de 6 schijven vdev. Verlies ik er wel 4 aan parity, maar dan word het 50% parity. (en 3 schijven kunnen verliezen in een rebuild van je pool is toch wel prettig, moet me nog verder verdiepen in hoe zfs data over de vdevs verdeelt bij uitbreiding, neem aan dat dit niet direct verdeeld word, alleen nieuwe data zal dan verdeeld worden)

[Q]

FireDrunk schreef op maandag 05 oktober 2015 @ 14:16:
[...]

Was jij het niet ook die zijn kaarten niet naar -IT firmware geflashed had?

Correct, lukte niet.

[FireDrunk]

Misschien dat dat er iets mee te maken heeft. Ik kan mij voorstellen dat een -IR firmware meer monitoring doet om te kijken of zijn 'volumes' nog online zijn.
Maar dat is puur speculatie.

[maomanna]

het maken van een zpool met:

zpool create raidz2 /dev/disk/by-partlabel/..... /dev/disk/by-partlabel/..... /dev/disk/by-partlabel/..... waarbij elke disk 1TB is, moet een netto opslag geven van ong 953GB? Hier geeft ie 2,7 TB aan... Dat lijkt meer op een striperaid dan een raidz2

code:

user@centraalpunt:~$ sudo zpool list
NAME       SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
ZFSBulk       -      -      -         -      -      -      -  FAULTED  -
datapool  2.72T   764K  2.72T         -     0%     0%  1.00x  ONLINE  -

[ Voor 33% gewijzigd door maomanna op 05-10-2015 15:23 ]

[FireDrunk]

Wat was je exacte commando?

zpool history

[maomanna]

code:

root@centraalpunt:/# zpool history datapool
History for 'datapool':

code:

root@centraalpunt:/# zpool history
History for 'datapool':

staat niks bij

bij de laatste komt mn andere pool ook niet naar voren.

[ Voor 40% gewijzigd door maomanna op 05-10-2015 15:52 ]

[FireDrunk]

zpool history ZFSBulk ?

[maomanna]

code:

root@centraalpunt:/# zpool history ZFSBulk
root@centraalpunt:/#

Komt helemaal niks.