Het grote ZFS topic

[ComTech]

Bij de samba configuratie heb ik alleen de optie verborgen bestanden weergeven gevonden.
Verder kan ik het nergens vinden.
Ondertussen heb ik wel in verkenner vorige versies van bestanden aan de praat, daar zie ik dus ook m'n snapshot en kan erin bladeren en eventueel terugzetten.
Maar helaas nog niet met een andere filemanager.

[Wasp]

Ik krijg sinds kort mails van FreeNAS met de waarschuwing:

code:

Device: /dev/ada0, Self-Test Log error count increased from 6 to 7

smartctl -a /dev/ada0 geeft idd dat de laatste 7 self tests mislukt zijn. Completed: read failure staat erbij.

Is deze schijf aan het overlijden? Schijf is net geen 3 jaar oud maar draait wel 24/7. Is een WD Red 3 TB met volgens mij 5 jaar garantie.

Echter een zpool status geeft geen bijzonderheden. Vermoed dat ZFS hier nog geen "last" van heeft oid?

Stel dat dat zo is, welke stappen moet ik nemen om de pool te resilveren met een nieuwe schijf? Het betreft een striped mirror:

code:

[root@freenas] ~# zpool status
  pool: freenas-boot
 state: ONLINE
  scan: scrub repaired 0 in 0h1m with 0 errors on Wed Aug  8 03:46:54 2018
config:

        NAME        STATE     READ WRITE CKSUM
        freenas-boot  ONLINE       0     0     0
          da0p2     ONLINE       0     0     0

errors: No known data errors

  pool: tank
 state: ONLINE
  scan: scrub repaired 0 in 16h15m with 0 errors on Sun Aug 12 16:15:50 2018
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            ada0p1  ONLINE       0     0     0
            ada1p1  ONLINE       0     0     0
          mirror-1  ONLINE       0     0     0
            ada2p1  ONLINE       0     0     0
            ada3p1  ONLINE       0     0     0

errors: No known data errors

[CurlyMo]

Wasp schreef op zondag 19 augustus 2018 @ 09:50:
Stel dat dat zo is, welke stappen moet ik nemen om de pool te resilveren met een nieuwe schijf? Het betreft een striped mirror:

Het blijft wel tweakers hier. Dus i.p.v. te vragen of iemand de stappen voor je wilt uitschrijven zie ik graag welke stappen je zelf gevonden hebt. Daarop kunnen wij hier wel zeggen of dat de juiste zijn. Dit topic biedt voldoende aanknopingspunten om je zoektocht te beginnen.

[Wasp]

CurlyMo schreef op zondag 19 augustus 2018 @ 11:10:
[...]

Het blijft wel tweakers hier. Dus i.p.v. te vragen of iemand de stappen voor je wilt uitschrijven zie ik graag welke stappen je zelf gevonden hebt. Daarop kunnen wij hier wel zeggen of dat de juiste zijn. Dit topic biedt voldoende aanknopingspunten om je zoektocht te beginnen.

Fair enough... typte bovenstaande beetje uit paniek.

Na wat gegoogle heb ik iig de eerste stappen gevonden:

zpool offline <poolname> <diskname>
(disk verwijderen, vraag: server uit? het is een HP Gen8 MicroServer.)
(nieuwe disk erin)
(systeem weer aan)

Maar hier haak ik ff af:

glabel label <name> <disk>
zpool replace <poolname> <olddisk> <newdisk>

Want ze hebben het hier over <name> en <disk>. Is name dan bv ada0p1 en disk /dev/ada0?

[nero355]

Wasp schreef op zondag 19 augustus 2018 @ 09:50:
Ik krijg sinds kort mails van FreeNAS met de waarschuwing:

code:

Device: /dev/ada0, Self-Test Log error count increased from 6 to 7

smartctl -a /dev/ada0 geeft idd dat de laatste 7 self tests mislukt zijn. Completed: read failure staat erbij.

Is deze schijf aan het overlijden? Schijf is net geen 3 jaar oud maar draait wel 24/7. Is een WD Red 3 TB met volgens mij 5 jaar garantie.

Stel dat dat zo is, welke stappen moet ik nemen om de pool te resilveren met een nieuwe schijf?

Doe eens gewoon een

code:

smartctl -a /dev/ada0

voordat je allerlei rare dingen doet uit paniek

[CurlyMo]

Wasp schreef op zondag 19 augustus 2018 @ 11:33:
[...]
Maar hier haak ik ff af:

Heb je in dit topic gezocht? Daar heb bijv. ik al vele malen gereageerd op de offline en replace sequentie.

Wasp schreef op zondag 19 augustus 2018 @ 11:33:
[...]
Fair enough... typte bovenstaande beetje uit paniek.

Voordat je een kritisch systeem bouwt zorg je er normaliter voor dat je ook in een test setup getest hebt wat je moet doen wanneer er dingen fout gaan. Dan hoef je niet in paniek te raken wanneer het er toe doet.

[Wasp]

nero355 schreef op zondag 19 augustus 2018 @ 12:19:
[...]

Doe eens gewoon een

code:

smartctl -a /dev/ada0

voordat je allerlei rare dingen doet uit paniek

Dat heb ik gedaan.. Daaruit maakte ik op dat de laatste 7 self tests mislukt waren.

Hier de gehele dump.

CurlyMo schreef op zondag 19 augustus 2018 @ 13:19:
Heb je in dit topic gezocht? Daar heb bijv. ik al vele malen gereageerd op de offline en replace sequentie.

Ja, maar ik kan mijn situatie niet terugvinden. Dus heb hierboven aangegeven wat ik denk wat ik moet uitvoeren en ik vraag eigenlijk om een bevestiging of dat klopt + wat vragen op onduidelijkheden.

CurlyMo schreef op zondag 19 augustus 2018 @ 13:19:
Voordat je een kritisch systeem bouwt zorg je er normaliter voor dat je ook in een test setup getest hebt wat je moet doen wanneer er dingen fout gaan. Dan hoef je niet in paniek te raken wanneer het er toe doet.

Eens hoor. Alleen had ik geen replacement klaarliggen om deze situatie te testen. En kritisch.... tsja wat is kritisch. Naast de ZFS freenas opslag sla ik ook alles op in de cloud. Alleen het scheelt een boel werk als ik zometeen de schijf zonder problemek kan vervangen.

[CurlyMo]

Wasp schreef op zondag 19 augustus 2018 @ 13:45:
[...]
Ja, maar ik kan mijn situatie niet terugvinden. Dus heb hierboven aangegeven wat ik denk wat ik moet uitvoeren en ik vraag eigenlijk om een bevestiging of dat klopt + wat vragen op onduidelijkheden.

Je bent minder uniek dan je denkt

Ik help je even:
Sleepie in "Het grote ZFS topic"
kdbruin in "Het grote ZFS topic" (met name de reactie van @FireDrunk)
GioStyle in "Het grote ZFS topic"
tvwes in "Het grote ZFS topic"
CurlyMo in "Het grote ZFS topic"

Maar voordat je in de CLI gaat klooien. Wat zegt het FreeNAS forum erover? Ik heb geen verstand van FreeNAS, juist alleen van de CLI.

Eens hoor. Alleen had ik geen replacement klaarliggen om deze situatie te testen. En kritisch.... tsja wat is kritisch. Naast de ZFS freenas opslag sla ik ook alles op in de cloud. Alleen het scheelt een boel werk als ik zometeen de schijf zonder problemek kan vervangen.

ZFS werkt prima met bestanden als vdev's. Dus testen kan altijd. Als zijn je vdev bestanden maar 100MB groot.

[Paul]

CurlyMo schreef op zondag 19 augustus 2018 @ 14:13:
Wat zegt het FreeNAS forum erover? Ik heb geen verstand van FreeNAS, juist alleen van de CLI.

In FreeNAS kan (/moet) het helemaal via de GUI, in de manual staat precies hoe:
http://doc.freenas.org/11...#replacing-a-failed-drive

Op het forum heeft ook iemand de procedure uitgeschreven met plaatjes:
https://forums.freenas.or...a-failed-failing-disk.75/

Met of zonder encryptie maakt op één wezenlijk onderdeel uit: Je moet je pool re-keyen:
http://doc.freenas.org/11...lacing-an-encrypted-drive

[Gonadan]

Lange tijd geleden heb ik een ZFS pool op m'n linux servertje geknutseld om mijn data te beschermen. Met name de verhalen over bitrot/silenct corruption vond ik eng omdat ik veel foto's maak en die kunnen er niet zo goed tegen als een bitje omkiepert. De laatste tijd heb ik mijn opstelling niet zo best onderhouden en wil dat nieuw leven in blazen, maar wil wel van het geknutsel af. Dat als achtergrond, nu mijn vraag.

Één van de grootste voordelen van ZFS is steeds de bescherming tegen corruptie, al schijn je te kunnen discussiëren over de kans dat het gebeurt. Echter, wat ik en heel veel mensen doen is synchroniseren naar andere platformen, bijvoorbeeld voor offsite redundantie.
Nu bedacht ik mij dat je daardoor wellicht juist weer de kans op corruptie herintroduceert. Hebben diensten zoals Stack, OneDrive, Jottacloud, etc niet alsnog een risico op corruptie? Dus dat je eigen volume in feite wel beschermd is, maar dat de corruptie van buitenaf komt?
In dit topic zie ik namelijk ook veel mensen een offsite ZFS-pool hebben waarmee ze syncen.

[CurlyMo]

Gonadan schreef op dinsdag 21 augustus 2018 @ 11:43:
Nu bedacht ik mij dat je daardoor wellicht juist weer de kans op corruptie herintroduceert.

Maar je verkleind ermee de kans dat dat tegelijkertijd gebeurt met je lokale pool. Kleine kans * kleine kans = hele kleine kans. Maar nog altijd een kans.

In dit topic zie ik namelijk ook veel mensen een offsite ZFS-pool hebben waarmee ze syncen.

Dat is het handigste, want het snelst. Maar in elke stap waarin je data verplaatst kunnen fouten ontstaat zoals in je geheugen, processor, netwerk communicatie, software zoals rsync of ssh. De kans daarop is opnieuw verwaarloosbaar klein als je een onsite en offsite backup gebruikt.

[Gonadan]

CurlyMo schreef op dinsdag 21 augustus 2018 @ 11:52:
Maar je verkleind ermee de kans dat dat tegelijkertijd gebeurt met je lokale pool. Kleine kans * kleine kans = hele kleine kans. Maar nog altijd een kans.

[...]

Dat is het handigste, want het snelst. Maar in elke stap waarin je data verplaatst kunnen fouten ontstaat zoals in je geheugen, processor, netwerk communicatie, software zoals rsync of ssh. De kans daarop is opnieuw verwaarloosbaar klein als je een onsite en offsite backup gebruikt.

Misschien begrijp ik dan gewoon niet zo goed hoe die corruptie werkt, maar als op één locatie een bit omkiepert dan ziet de synctool dat toch als een wijziging en wordt die naar de andere locaties gesynct?

[CurlyMo]

Gonadan schreef op dinsdag 21 augustus 2018 @ 12:02:
[...]

Misschien begrijp ik dan gewoon niet zo goed hoe die corruptie werkt, maar als op één locatie een bit omkiepert dan ziet de synctool dat toch als een wijziging en wordt die naar de andere locaties gesynct?

Zolang je een versioned backup hebt, maakt dat niet uit. Dan kan je altijd terug naar een vorige staat van je backup. Dat maakt de ZFS snapshots zo krachtig. Je stuurt een lokale snapshot naar offsite. Offsite bewaar je minder snapshots dan lokaal, maar wel genoeg om hiertegen beschermt te zijn. Zodra er dus iets corrupt naar je backup is verzonden, dan herstel je dat vanuit een oudere backup versie zodat de nieuwste versie van je backup weer het niet-corrupte bestand zal bevatten na de volgende backup ronde.

[Gonadan]

CurlyMo schreef op dinsdag 21 augustus 2018 @ 12:13:
Zolang je een versioned backup hebt, maakt dat niet uit. Dan kan je altijd terug naar een vorige staat van je backup. Dat maakt de ZFS snapshots zo krachtig. Je stuurt een lokale snapshot naar offsite. Offsite bewaar je minder snapshots dan lokaal, maar wel genoeg om hiertegen beschermt te zijn. Zodra er dus iets corrupt naar je backup is verzonden, dan herstel je dat vanuit een oudere backup versie zodat de nieuwste versie van je backup weer het niet-corrupte bestand zal bevatten na de volgende backup ronde.

Kunnen oudere snapshots niet ook corrupt raken? Of is dat nu juist de bescherming van ZFS? Want ik kan bijvoorbeeld ook met tools als Duplicatie of anderen versioning gaan doen, maar dan nog kan de corruptie in de backupset gebeuren en dan ben ik wel benieuwd hoever je dan van huist bent.

De vraag is natuurlijk wel hoe je er achter komt dat iets corrupt is, het wordt niet voor niets silent genoemd natuurlijk. Die snapshots zal je niet eeuwig bewaren dus je wilt op z'n minst voordat een snapshot vervalt door hebben dat iets corrupt is geraakt.

Doen cloud diensten hier overigens helemaal niets tegen? Of hebben zij ook technieken waardoor de kans niet zo groot is? Ik weet dat TransIP RAID-Z gebruikt, maar van verdere diensten heb ik eigenlijk geen idee.

[RobertMe]

Gonadan schreef op dinsdag 21 augustus 2018 @ 12:58:
[...]

Kunnen oudere snapshots niet ook corrupt raken? Of is dat nu juist de bescherming van ZFS? Want ik kan bijvoorbeeld ook met tools als Duplicatie of anderen versioning gaan doen, maar dan nog kan de corruptie in de backupset gebeuren en dan ben ik wel benieuwd hoever je dan van huist bent.

De vraag is natuurlijk wel hoe je er achter komt dat iets corrupt is, het wordt niet voor niets silent genoemd natuurlijk. Die snapshots zal je niet eeuwig bewaren dus je wilt op z'n minst voordat een snapshot vervalt door hebben dat iets corrupt is geraakt.

Doen cloud diensten hier overigens helemaal niets tegen? Of hebben zij ook technieken waardoor de kans niet zo groot is? Ik weet dat TransIP RAID-Z gebruikt, maar van verdere diensten heb ik eigenlijk geen idee.

Snapshots zijn copy-on-write. Als het bestand wordt aangepast wordt het hele bestand dus opnieuw opgeslagen. Ook bij deze oude kopieën kan er dus bit-rot optreden. Maar ZFS beschermt daartegen door het principe van scrubs. Bij een scrub wordt namelijk elk bestand (en dus ook oude uit snapshots) gecontroleerd of de inhoud en checksum nog met elkaar overeen komen. Door dus periodiek een scrub te draaien detecteer je dus ook silent errors.

[CurlyMo]

Gonadan schreef op dinsdag 21 augustus 2018 @ 12:58:
[...]
De vraag is natuurlijk wel hoe je er achter komt dat iets corrupt is, het wordt niet voor niets silent genoemd natuurlijk. Die snapshots zal je niet eeuwig bewaren dus je wilt op z'n minst voordat een snapshot vervalt door hebben dat iets corrupt is geraakt.

Het is dus aan jou om aan monitoring te doen zodat je op tijd kan ingrijpen. Oftewel, als je een jaar nodig hebt om corruptie in je pool te detecteren, moet je tenminste 1 snapshot voor maximaal een jaar behouden.

Daarnaast heb ik al eerder laten zien hoe je een OrangePi kan gebruiken als een ZFS offsite backup target. Er zullen vast wel familieleden of vrienden zijn die hem voor je neer willen zetten. Dan heb je ook volledige controle over je offsite backup machine.

[RobertMe]

CurlyMo schreef op dinsdag 21 augustus 2018 @ 13:10:
[...]

Het is dus aan jou om aan monitoring te doen zodat je op tijd kan ingrijpen. Oftewel, als je een jaar nodig hebt om corruptie in je pool te detecteren, moet je tenminste 1 snapshot voor maximaal een jaar behouden.

Dit helpt toch niet tegen bit-rot in combinatie met langdurige opslag? Want door copy-on-write wordt het bestand nooit opnieuw opgeslagen dus zal het bestand ook in je snapshot van 1, 2, 3, ... jaar terug corrupt zijn.

IMO zijn snapshots vooral handig om een back-up van een oude versie te hebben. Maar als je het hebt over langdurige opslag van foto's is er maar een versie. Detectie van bit-rot doe je dan bv door periodiek te scrubben. Maar dan is het kwaad dus al geschied. En AFAIK is de enige echte 'beveiliging' daartegen het werken met redundancy. Of in de vorm van off site opslag of gebruik maken van mirroring of RAID-Z/Z2/5/6. Waarbij een offsite vorm de voorkeur heeft omdat je dan ook beschermd bent bij brand/waterschade/blikseminslag/...

[CurlyMo]

RobertMe schreef op dinsdag 21 augustus 2018 @ 13:31:
[...]

Dit helpt toch niet tegen bit-rot in combinatie met langdurige opslag? Want door copy-on-write wordt het bestand nooit opnieuw opgeslagen dus zal het bestand ook in je snapshot van 1, 2, 3, ... jaar terug corrupt zijn.

IMO zijn snapshots vooral handig om een back-up van een oude versie te hebben. Maar als je het hebt over langdurige opslag van foto's is er maar een versie. Detectie van bit-rot doe je dan bv door periodiek te scrubben. Maar dan is het kwaad dus al geschied. En AFAIK is de enige echte 'beveiliging' daartegen het werken met redundancy. Of in de vorm van off site opslag of gebruik maken van mirroring of RAID-Z/Z2/5/6. Waarbij een offsite vorm de voorkeur heeft omdat je dan ook beschermd bent bij brand/waterschade/blikseminslag/...

Laten we deze sequentie van gebeurtenissen nemen:

L = Lokaal
O = Offsite

1. L <= Hello World
1. Hello World => O
2. L <= Hella World
2. Hella World => O
[scrub]
3. L <= Hello World
3 Hello World => O

Je 1ste en 3de snapshot bevatten nu de juiste versie van het oorspronkelijke bestand. Daarom heeft het zin om ook oude versies van je snapshot te bewaren op je backup.

[RobertMe]

CurlyMo schreef op dinsdag 21 augustus 2018 @ 13:36:
[...]

Laten we deze sequentie van gebeurtenissen nemen:

L = Lokaal
O = Offsite

1. L <= Hello World
1. Hello World => O
2. L <= Hella World
2. Hella World => O
[scrub]
3. L <= Hello World
3 Hello World => O

Je 1ste en 3de snapshot bevatten nu de juiste versie van het oorspronkelijke bestand. Daarom heeft het zin om ook oude versies van je snapshot te bewaren op je backup.

Hoe bedoel je precies? Ik snap wel dat je ook de snapshots op je backup locatie wilt bewaren (ook voor als je primaire locatie helemaal weg valt bv). Maar hoe geeft dat extra bescherming tegen dingen als bit-rot? Ik mag in ieder geval toch aannemen dat ook tijdens een zfs send de data gecontroleerd wordt (hetzelfde als elke lees actie en scrub doet) waarbij ik toch verwacht dat een error (door bv bit-rot) ervoor zorgt dat dat bestand niet gesynced wordt? Of wordt het bestand dan wel (foutief) over gezet?

En ook daarbij lijkt mij dat zfs send alleen de gewijzigde bestanden verstuurd, hetzelfde als de copy-on-write bij opslag. Dus dan zou ook in dat geval bij langdurige (ongewijzigde) opslag het bestand nooit opnieuw worden over gestuurd en de omgevallen bit dus niet naar de backup locatie worden gestuurd.

---

Gonadan schreef op dinsdag 21 augustus 2018 @ 12:02:
[...]

Misschien begrijp ik dan gewoon niet zo goed hoe die corruptie werkt, maar als op één locatie een bit omkiepert dan ziet de synctool dat toch als een wijziging en wordt die naar de andere locaties gesynct?

Hierop terugkomende, dat ligt aan de werking van de sync tool. De meeste zullen als primaire reden om te syncen de filesystem events gebruiken. Hierbij wordt aan het OS gevraagd om wijzigingen van bestanden te rapporteren aan de synctool. Als (door ouderdom) bitjes omkieperen weet het OS daar niet van (want dat event wordt uiteraard door het OS gegeven bij het schrijven naar het bestand) en dus de synctool ook niet. Daarnaast kan als fallback zo'n sync tool kijken naar de laatst gewijzigd datum van het bestand, en ook die veranderd niet bij omvallende bitjes. Een sync tool neemt een omgevallen bitje dus alleen over als: 1. je het bestand daadwerkelijk wijzigt, of 2. de sync tool periodiek het bestand helemaal leest en verstuurd (of leest, een hash berekend, en die vergelijkt met een hash van de versie in de cloud, dan ziet dat die hashes verschillen en dan het bestand alsnog over zet).


Edit:
In het algemeen Ik kijk trouwens voornamelijk even naar het punt van bit-rot op de NAS/opslag locatie. Als je van een PC naar je NAS synced en er bit-rot op je PC is is het natuurlijk weer een heel ander verhaal, dan sla je gewoon het verkeerde bestand op met ZFS en beschermd ZFS je uiteraard niet.

[ Voor 5% gewijzigd door RobertMe op 21-08-2018 13:51 ]

[Gonadan]

CurlyMo schreef op dinsdag 21 augustus 2018 @ 13:10:
Het is dus aan jou om aan monitoring te doen zodat je op tijd kan ingrijpen. Oftewel, als je een jaar nodig hebt om corruptie in je pool te detecteren, moet je tenminste 1 snapshot voor maximaal een jaar behouden.

Dat blijft dan dus in principe handwerk.
Waarom hoor je hier zo weinig over buiten een topic als deze? Komt het relatief weinig voor of denken mensen in het geval van één corrupte foto iets als 'het zal wel'?

RobertMe schreef op dinsdag 21 augustus 2018 @ 13:47:
Hierop terugkomende, dat ligt aan de werking van de sync tool. De meeste zullen als primaire reden om te syncen de filesystem events gebruiken. Hierbij wordt aan het OS gevraagd om wijzigingen van bestanden te rapporteren aan de synctool. Als (door ouderdom) bitjes omkieperen weet het OS daar niet van (want dat event wordt uiteraard door het OS gegeven bij het schrijven naar het bestand) en dus de synctool ook niet. Daarnaast kan als fallback zo'n sync tool kijken naar de laatst gewijzigd datum van het bestand, en ook die veranderd niet bij omvallende bitjes. Een sync tool neemt een omgevallen bitje dus alleen over als: 1. je het bestand daadwerkelijk wijzigt, of 2. de sync tool periodiek het bestand helemaal leest en verstuurd (of leest, een hash berekend, en die vergelijkt met een hash van de versie in de cloud, dan ziet dat die hashes verschillen en dan het bestand alsnog over zet).

Dus feitelijk is dat koffiedik kijken, tenzij je achterhaalt hoe zo'n sync precies werkt.
Wat dat betreft zou je dus als niet-ZFS-gebruiker zelfs checksums moeten gaan genereren en opslaan zodat je periodiek kunt vergelijjken?

In het algemeen Ik kijk trouwens voornamelijk even naar het punt van bit-rot op de NAS/opslag locatie. Als je van een PC naar je NAS synced en er bit-rot op je PC is is het natuurlijk weer een heel ander verhaal, dan sla je gewoon het verkeerde bestand op met ZFS en beschermd ZFS je uiteraard niet.

Inderdaad. En ik mag aannemen dat je het wel doorhebt als je een corrupt bestand gebruikt op je PC.

[RobertMe]

Gonadan schreef op dinsdag 21 augustus 2018 @ 14:07:
[...]

Inderdaad. En ik mag aannemen dat je het wel doorhebt als je een corrupt bestand gebruikt op je PC.

Als je het gebruikt wel ja. Maar als je zoals @CurlyMo zegt het bestand bv maar eens het jaar gebruikt en je komt dan ineens erachter dat het corrupt is, en je backups/snapshots die maar tot 6 maanden terug gaan allemaal de corrupte versie bevatten, heb je alsnog een probleem.

[Gonadan]

RobertMe schreef op dinsdag 21 augustus 2018 @ 14:12:
[...]

Als je het gebruikt wel ja. Maar als je zoals @CurlyMo zegt het bestand bv maar eens het jaar gebruikt en je komt dan ineens erachter dat het corrupt is, en je backups/snapshots die maar tot 6 maanden terug gaan allemaal de corrupte versie bevatten, heb je alsnog een probleem.

Dat blijft zo inderdaad, maar dan zal je niet per ongeluk een sync triggeren. Want je zal wel doorhebben dat hij corrupt is.

[FireDrunk]

Yay, vandaag Pushover in gebruik genomen! In combinatie met ZED (ZFS Event Daemon), krijg ik nu keurig een melding (en het resultaat) van een scrub gepusht naar mijn telefoon.

Scriptje:

Bash:

#!/bin/bash

[ -f "${ZED_ZEDLET_DIR}/zed.rc" ] && . "${ZED_ZEDLET_DIR}/zed.rc"
. "${ZED_ZEDLET_DIR}/zed-functions.sh"

zed_check_cmd "${ZPOOL}" || exit 9

APP_TOKEN=<token>
USER_KEY=<token>

note_subject="ZFS ${ZEVENT_SUBCLASS} event for ${ZEVENT_POOL} on $(hostname)"
MESSAGE="[ZFS event]
subject: ${note_subject}
eid: ${ZEVENT_EID}
class: ${ZEVENT_SUBCLASS}
host: $(hostname)
time: ${ZEVENT_TIME_STRING}

$(${ZPOOL} status ${ZEVENT_POOL})"

curl -s \
  --form-string "token=${APP_TOKEN}" \
  --form-string "user=${USER_KEY}" \
  --form-string "message=${MESSAGE}" \
      https://api.pushover.net/1/messages.json

Om het scriptje activeren:

root@nas:/etc/zfs/zed.d# ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Aug 21 13:57 .
drwxr-xr-x 4 root root 4.0K Aug 21 13:56 ..
lrwxrwxrwx 1 root root   22 Aug 21 13:53 scrub_finish-pushover.sh -> /root/pushover/push.sh
lrwxrwxrwx 1 root root   22 Aug 21 13:53 scrub_start-pushover.sh -> /root/pushover/push.sh

Aanmaken kan dmv:

ln -s /etc/zfs/zed.d/scrub_start-pushover.sh /root/pushover/push.sh
ln -s /etc/zfs/zed.d/scrub_finish-pushover.sh /root/pushover/push.sh

Misschien in de toekomst nog wat sleutelen aan de opmaak, we'll see.

[Wiebeltje]

CurlyMo schreef op dinsdag 24 april 2018 @ 07:57:
[...]

En het draait sinds die tijd perfect Oftewel, de OrangePI PC2 is de ideale offsite backup machine. Goedkoop, zuinig, klein en snel genoeg.

Ik heb eens zitten zoeken naar de specs / benchmarks van het bordje maar het is allemaal wat lastiger te vinden. Heb je er een enkele schijf aan hangen of een mirror? Ik zou het wel mooi vinden om dit bordje te kunnen gebruiken icm met twee 2TB 2.5" schijven in mirror. Ik zag dat je met een scrub 20MB/s haalde. Met een "zfs send" zal dit nog wat hoger liggen gok ik?

Vraag me vooral af of je zonder problemen twee externe schijven rechtstreeks kan aansluiten op het bord.

[CurlyMo]

Wiebeltje schreef op dinsdag 21 augustus 2018 @ 15:58:
[...]

Ik heb eens zitten zoeken naar de specs / benchmarks van het bordje maar het is allemaal wat lastiger te vinden.

Gewoon op de OrangePi site is toch alles te vinden wat je nodig hebt:
http://www.orangepi.org/orangepipc2/

Heb je er een enkele schijf aan hangen of een mirror?

Eén 3.5" schijf extern gevoed.

Ik zou het wel mooi vinden om dit bordje te kunnen gebruiken icm met twee 2TB 2.5" schijven in mirror. Ik zag dat je met een scrub 20MB/s haalde. Met een "zfs send" zal dit nog wat hoger liggen gok ik?

USB2.0 is de beperking. Meestal is je upload de beperking en hoe hoog heb je nodig voor een sync 's nachts.

Vraag me vooral af of je zonder problemen twee externe schijven rechtstreeks kan aansluiten op het bord.

Extern gevoed zeker.

[Sandor_Clegane]

Goh dat is toevallig, ik ben op zoek naar zo'm boardje. Ik zag de Banana PI en die heeft een SATA interface, iemand daar ervaringen mee?

En over die Orange Pi gesproken, wat is de doorvoer snelheid op dat dingetje? Is dat hetzelfde als de Pi dat alles aan elkaar geknoopt is via een USB bus? Of heeft deze een "echte" bus?

[CurlyMo]

Sandor_Clegane schreef op woensdag 22 augustus 2018 @ 11:15:
Goh dat is toevallig, ik ben op zoek naar zo'm boardje. Ik zag de Banana PI en die heeft een SATA interface, iemand daar ervaringen mee?

En over die Orange Pi gesproken, wat is de doorvoer snelheid op dat dingetje? Is dat hetzelfde als de Pi dat alles aan elkaar geknoopt is via een USB bus? Of heeft deze een "echte" bus?

Opnieuw, stel jezelf de vraag welke snelheid je nodig hebt? OrangePi werkt vrijwel out-of-the-box. RaspberryPi en BananaPi heb ik niet stabiel gekregen.

[Sandor_Clegane]

Moet wel 100 MBit kunnen volblazen, minimaal. Ik wil hem voornamelijk gebruiken als servertje voor een .Net applicatie waarin wel wat IO gedaan wordt.

Wat bedoel je met de raspberry pi niet stabiel, heb er een paar en die lopen prima.

[CurlyMo]

Sandor_Clegane schreef op woensdag 22 augustus 2018 @ 11:32:
Wat bedoel je met de raspberry pi niet stabiel, heb er een paar en die lopen prima.

Dit is het ZFS topic, oftewel, ook voor een ZFS offsite backup toepassing?

[Sandor_Clegane]

Nee dat niet, maar ik zag je post en was nieuwsgierig naar wat indrukken van dat boardje. Maar dat ZFS niet goed werkt is wel goed om te weten, moet namelijk ook het FS formatteren op de PI.

[CurlyMo]

Sandor_Clegane schreef op woensdag 22 augustus 2018 @ 11:35:
Nee dat niet, maar ik zag je post en was nieuwsgierig naar wat indrukken van dat boardje. Maar dat ZFS niet goed werkt is wel goed om te weten, moet namelijk ook het FS formatteren op de PI.

Ik gebruik de OrangePi louter voor ZFS offsite backup. Voor andere indrukken moet je in een ander topic zijn.

[FireDrunk]

@CurlyMo
Is dat iets wat ik makkelijk kan testen? Ik heb Rock64's liggen (https://www.pine64.org/?page_id=7147).
Wil best een keer wat testen. Zit 4GB ram op, en een quadcore, dus ik verwacht dat die dingen best snel zijn.

[CurlyMo]

FireDrunk schreef op woensdag 22 augustus 2018 @ 12:30:
@CurlyMo
Is dat iets wat ik makkelijk kan testen? Ik heb Rock64's liggen (https://www.pine64.org/?page_id=7147).
Wil best een keer wat testen. Zit 4GB ram op, en een quadcore, dus ik verwacht dat die dingen best snel zijn.

Hangt van de OS ondersteuning af. Meestal moet je namelijk zelf ZFS compileren voor je kernel. En het moet 64bit zijn.

En ik vind Rockchips in zijn algemeenheid ruk

[ Voor 5% gewijzigd door CurlyMo op 22-08-2018 13:30 ]

[lseg]

Ik wil mij nas gaan gebruiken voor wat server stuff maar vooral voor SMB share op een ZFS schijf.
ik zou 3x6TB schijven in RaidZ1 willen zetten, dan houd ik dus 12TB over. Hoeveel Ram heb ik dan nodig in combinatie met een Intel G4650 om maximum doorvoer te hebben bij een Gb Ethernet. ECC geheugen is nl duur en ik begrijp dat ZFS processor en geheugen intensief is. Ik zou trouwens Ubuntu gebruiken (ben ik nl in thuis ook voor de andere server toestanden)

[CurlyMo]

lseg schreef op woensdag 22 augustus 2018 @ 20:44:
Ik wil mij nas gaan gebruiken voor wat server stuff maar vooral voor SMB share op een ZFS schijf.
ik zou 3x6TB schijven in RaidZ1 willen zetten, dan houd ik dus 12TB over. Hoeveel Ram heb ik dan nodig in combinatie met een Intel G4650 om maximum doorvoer te hebben bij een Gb Ethernet. ECC geheugen is nl duur en ik begrijp dat ZFS processor en geheugen intensief is. Ik zou trouwens Ubuntu gebruiken (ben ik nl in thuis ook voor de andere server toestanden)

Idealiter minimaal 8GB, maar begin eens met 4GB.

[nero355]

lseg schreef op woensdag 22 augustus 2018 @ 20:44:
Hoeveel Ram heb ik dan nodig in combinatie met een Intel G4650 om maximum doorvoer te hebben bij een Gb Ethernet. ECC geheugen is nl duur en ik begrijp dat ZFS processor en geheugen intensief is.

https://nl.hardware.info/...n-in-vierde-kwartaal-2018

Ik kan niet wachten, want dan kan ik eindelijk wat leuks gaan bouwen voor mezelf

[SymbolicFrank]

Ok, ik had weer een kapotte HD. En ik heb mijn RAID server een paar jaar geleden opgeruimd omdat het heel onpraktisch was (eindeloze rebuilds en er gingen in een week tijd twee schijven kapot).

Ik zit al een hele tijd naar ZFS te kijken, maar het heeft de oorspronkelijke beloftes niet waargemaakt en is nu gewoon een RAID kloon die ook bit-rot opvangt.

Wat zijn mijn wensen en eisen:

1. Schijven toevoegen en verwijderen moet heel eenvoudig zijn en mag nooit resulteren in een onbruikbaar bestandssysteem. Bestanden op de schijven moeten ook altijd leesbaar zijn, alhoewel het er minder kunnen worden als er snel veel schijven verdwijnen (worst case).
2. Opslag kan lokaal en op een server zijn (of in de cloud en zo).
3. Bestanden worden automatisch over de beschikbare opslagmedia verdeeld, er wordt geprobeerd om van alle veelgebruikte bestanden altijd een lokale kopie te hebben.
4. Bestanden zijn beschermd tegen omvallende bits en verdwijnende blokken.
5. SMB2 (windows share) word ondersteund.
6. Het moet heel eenvoudig te beheren en configureren zijn.

Ik wil ook geen "vuilnisbak" voor verwijderde bestanden. Je moet oudere versies terug kunnen halen. Als er ruimte op de schijf nodig is, worden automatisch de oudste/minst belangrijke bestanden verwijderd.

Maar ja, wat is er op de markt dat dit ondersteunt? Ik kan niets vinden.

Een andere optie is het zelf te maken. Dat is zeker te doen; punt 5 (SMB2) kost dan waarschijnlijk de meeste tijd. Maar het kost me al gauw een half jaar of langer om zoiets te maken, dus ik zou heel graag willen weten of er zoiets toch al bestaat, of hoe ik dat op een eenvoudigere manier in kan richten.

[CurlyMo]

SymbolicFrank schreef op maandag 17 september 2018 @ 00:57:
Ok, ik had weer een kapotte HD. En ik heb mijn RAID server een paar jaar geleden opgeruimd omdat het heel onpraktisch was (eindeloze rebuilds en er gingen in een week tijd twee schijven kapot).

Ik zit al een hele tijd naar ZFS te kijken, maar het heeft de oorspronkelijke beloftes niet waargemaakt en is nu gewoon een RAID kloon die ook bit-rot opvangt.

Wat zijn mijn wensen en eisen:

1. Schijven toevoegen en verwijderen moet heel eenvoudig zijn en mag nooit resulteren in een onbruikbaar bestandssysteem. Bestanden op de schijven moeten ook altijd leesbaar zijn, alhoewel het er minder kunnen worden als er snel veel schijven verdwijnen (worst case).
2. Opslag kan lokaal en op een server zijn (of in de cloud en zo).
3. Bestanden worden automatisch over de beschikbare opslagmedia verdeeld, er wordt geprobeerd om van alle veelgebruikte bestanden altijd een lokale kopie te hebben.
4. Bestanden zijn beschermd tegen omvallende bits en verdwijnende blokken.
5. SMB2 (windows share) word ondersteund.
6. Het moet heel eenvoudig te beheren en configureren zijn.

Ik wil ook geen "vuilnisbak" voor verwijderde bestanden. Je moet oudere versies terug kunnen halen. Als er ruimte op de schijf nodig is, worden automatisch de oudste/minst belangrijke bestanden verwijderd.

Maar ja, wat is er op de markt dat dit ondersteunt? Ik kan niets vinden.

Een andere optie is het zelf te maken. Dat is zeker te doen; punt 5 (SMB2) kost dan waarschijnlijk de meeste tijd. Maar het kost me al gauw een half jaar of langer om zoiets te maken, dus ik zou heel graag willen weten of er zoiets toch al bestaat, of hoe ik dat op een eenvoudigere manier in kan richten.

Kan je aangegeven waar huidige tools zoals FreeNAS in tekort schieten? Ik gebruik het zelf niet, maar lees dat dat toch aardig flexibel is.

[nero355]

SymbolicFrank schreef op maandag 17 september 2018 @ 00:57:
Ok, ik had weer een kapotte HD. En ik heb mijn RAID server een paar jaar geleden opgeruimd omdat het heel onpraktisch was (eindeloze rebuilds en er gingen in een week tijd twee schijven kapot).

Als in klassieke Hardware RAID Controller ?

Heb je wel erg veel pech gehad IMHO

Ik zit al een hele tijd naar ZFS te kijken, maar het heeft de oorspronkelijke beloftes niet waargemaakt en is nu gewoon een RAID kloon die ook bit-rot opvangt.

Leg eens uit, want dit klinkt wel erg kort door de bocht

Wat zijn mijn wensen en eisen:

1. Schijven toevoegen en verwijderen moet heel eenvoudig zijn en mag nooit resulteren in een onbruikbaar bestandssysteem. Bestanden op de schijven moeten ook altijd leesbaar zijn, alhoewel het er minder kunnen worden als er snel veel schijven verdwijnen (worst case).

Klinkt als een systeem dat er nog niet is, tenzij je bereid bent één grote cluster te bouwen...

2. Opslag kan lokaal en op een server zijn (of in de cloud en zo).

Dit kan altijd

3. Bestanden worden automatisch over de beschikbare opslagmedia verdeeld, er wordt geprobeerd om van alle veelgebruikte bestanden altijd een lokale kopie te hebben.

Bestaat niet voor zover ik weet ?!

4. Bestanden zijn beschermd tegen omvallende bits en verdwijnende blokken.

Hey, look! ZFS!

5. SMB2 (windows share) word ondersteund.

Lijkt me meer een OS ding ?

6. Het moet heel eenvoudig te beheren en configureren zijn.

Dan kom je denk ik al gauw uit bij de kant en klare ZFS distro's of misschien iets met BTRFS zoeken ?

Ik wil ook geen "vuilnisbak" voor verwijderde bestanden. Je moet oudere versies terug kunnen halen. Als er ruimte op de schijf nodig is, worden automatisch de oudste/minst belangrijke bestanden verwijderd.

Klinkt als een Cronjob die je zelf moet verzinnen!

Maar ja, wat is er op de markt dat dit ondersteunt? Ik kan niets vinden.

Heel eerlijk gezegd klinkt het meer als een "storage trauma" die je bent opgelopen en nu hoopt dat er een systeem bestaat die al je zorgen wegneemt...

Een andere optie is het zelf te maken. Dat is zeker te doen; punt 5 (SMB2) kost dan waarschijnlijk de meeste tijd. Maar het kost me al gauw een half jaar of langer om zoiets te maken, dus ik zou heel graag willen weten of er zoiets toch al bestaat, of hoe ik dat op een eenvoudigere manier in kan richten.

Dat zou eigenlijk niet mogen...

[FireDrunk]

Kijk hier eens:
https://www.snapraid.it/compare

[SymbolicFrank]

CurlyMo schreef op maandag 17 september 2018 @ 07:24:
[...]

Kan je aangegeven waar huidige tools zoals FreeNAS in tekort schieten? Ik gebruik het zelf niet, maar lees dat dat toch aardig flexibel is.

Zoals ik al aangaf:

- Schijven wisselen is een ramp. En als er een schijf te veel omvalt, of je server het niet meer doet, zijn je schijven onleesbaar en je bestanden verdwenen. Of je moet van de helft van je schijven "spares" maken...

- Het is niet gedistribueerd, je zit altijd aan dat moeilijk te vergroten, lokale volume vast.

- Het is zelfs voor een professional moeilijk te beheren.

[SymbolicFrank]

nero355 schreef op maandag 17 september 2018 @ 08:42:
Als in klassieke Hardware RAID Controller ?

Heb je wel erg veel pech gehad IMHO

Custom linux server, mdadm, 5 schijven. Er gingen na twee jaar in korte tijd 2 schijven kapot. Vervanging en rebuilden duurde iets langer. De extra "spare" kwam net te laat. Misschien had ik geen ECO schijven moeten gebruiken.

Leg eens uit, want dit klinkt wel erg kort door de bocht

Oorspronkelijk was het doel van ZFS, dat het eenvoudig moest zijn on drives toe te voegen en te verwijderen en dat je meerdere volumes kon samenvoegen of juist splitsen. En dat opslag gedistribueerd was.

En omdat bitrot tegenwoordig een ding is, moest het daar ook tegen beschermen.

Het was dus ook geen striped RAID. Bestanden werden verdeeld over de beschikbare opslagmedia.

Cool! Dat was wat ik wilde!

Klinkt als een systeem dat er nog niet is, tenzij je bereid bent één grote cluster te bouwen...

[...]

Dit kan altijd

[...]

Bestaat niet voor zover ik weet ?!

[...]

Hey, look! ZFS!

[...]

Lijkt me meer een OS ding ?

[...]

Dan kom je denk ik al gauw uit bij de kant en klare ZFS distro's of misschien iets met BTRFS zoeken ?


[...]

Klinkt als een Cronjob die je zelf moet verzinnen!


[...]

Heel eerlijk gezegd klinkt het meer als een "storage trauma" die je bent opgelopen en nu hoopt dat er een systeem bestaat die al je zorgen wegneemt...


[...]

Dat zou eigenlijk niet mogen...

Nou, zelf een nieuw bestandssysteem en interface ontwerpen en programmeren doe je niet in een paar avondjes. Een half jaar is heel snel, zelfs voor een minimale versie.

[ Voor 3% gewijzigd door SymbolicFrank op 19-09-2018 03:24 ]

[SymbolicFrank]

FireDrunk schreef op maandag 17 september 2018 @ 09:00:
Kijk hier eens:
https://www.snapraid.it/compare

Interessant, dank je. Daar ga ik eens uitgebreid naar kijken.

[CurlyMo]

SymbolicFrank schreef op woensdag 19 september 2018 @ 03:05:
[...]
- Schijven wisselen is een ramp. En als er een schijf te veel omvalt, of je server het niet meer doet, zijn je schijven onleesbaar en je bestanden verdwenen. Of je moet van de helft van je schijven "spares" maken...

Dat is toch bij alle RAID oplossingen zo.

- Het is niet gedistribueerd, je zit altijd aan dat moeilijk te vergroten, lokale volume vast.

Dan moet je naar andere oplossingen kijken buiten ZFS zoals glusterfs.

- Het is zelfs voor een professional moeilijk te beheren.

De eisen die je stelt zijn ook vrij professioneel, waarbij je volgens mij ook bij hele andere soort tooling terecht komt (e.g. Ansible). Waarbij delen zelf via de CLI beheerd moeten worden.

[FireDrunk]

SnapRAID komt in de buurt, maar wat je wil is gewoon een utopie. Het is er gewoon niet, en komt er (waarschijnlijk) niet.
Sommige van die eisen zijn consumer grade, veel anderen weer enterprise, en weer anderen gelden alleen voor tweakers. Die 3 werelden willen combineren komt alleen maar hier voor, niet ergens anders.

Daardoor is er niemand die in dat gat wil springen, want er is geen markt voor.

[johnkeates]

Een magische opslag machine die alles doet wat je wil en 'beter dan ZFS' is, die bestaat deels niet en is deels te duur. Je kan namelijk prima multisite replicated block storage doen met hierarchical storage management enz, maar dan moet je wel een paar ton neerleggen en dat wil je dan vast weer niet.

[nero355]

SymbolicFrank schreef op woensdag 19 september 2018 @ 03:16:
Nou, zelf een nieuw bestandssysteem en interface ontwerpen en programmeren doe je niet in een paar avondjes. Een half jaar is heel snel, zelfs voor een minimale versie.

Voordat je dat doet : Kijk ook eens naar CEPH => https://ceph.com/ceph-storage/

Succes!

[IceTeaGX]

Zwaar off topic aan het lopen, maar azure file sync i.c.m. azure file storage heeft ook wel enkele elementen welke je aanhaalt (on-demand local copy van cloud storage)
Je zit dan natuurlijk nog met de aanzienlijke kosten en "betrouwbaarheid" van een cloud platform.

[SymbolicFrank]

johnkeates schreef op woensdag 19 september 2018 @ 08:47:
Een magische opslag machine die alles doet wat je wil en 'beter dan ZFS' is, die bestaat deels niet en is deels te duur. Je kan namelijk prima multisite replicated block storage doen met hierarchical storage management enz, maar dan moet je wel een paar ton neerleggen en dat wil je dan vast weer niet.

De eisen die ik stel zijn vrijwel hetzelfde als de originele specs van ZFS. Dus ik ben zeker niet de enige die het zo wil doen.

Het grootste probleem is, dat dingen meestal maar 1x bedacht worden. Het moet ingeburgerd raken. En de meeste mensen kunnen vernieuwing niet goed overzien.

Iemand bedacht RAID om een gat in de markt op te vullen, het werkte en sindsdien maakt iedereen dat na. Het is wel flink gegroeid, zoals de opslag van blokken op meerdere locaties. En iedereen doet het, dus is het de beste manier.

Totdat RAID helemaal omvalt en/of er een nieuw gat in de markt opgevuld moet worden, is voor bijna iedereen RAID de enige manier. En de ontwikkeling van ZFS laat dat ook zien: alle ontwikkelaars die er aan gewerkt hebben kenden RAID, en dus is het RAID geworden.

Ook de meeste online opslag is geen goede optie. Ten eerste maakt de meerderheid een kopie van (een gedeelte van) je lokale gegevens. Wat moet / kun je daar mee? Niet veel. En de rest werkt als een FTP server: je kunt individuele bestanden up- en downloaden. Leuk als backup voor een paar belangrijke bestanden, maar verre van een bestandssysteem.

Iemand moet dus eerst iets beters maken en het moet dat gat vullen. Daarna moet het populair worden. Op een gegeven moment gaan andere mensen het ook gebruiken en namaken. En dan wordt het de nieuwe standaard.

Als je dan 25 jaar later jezelf afvraagt of er nou geen betere manier is, want het begint nu wel heel problematisch te worden, en je post die vraag op een forum, krijg je waarschijnlijk veel reacties van mensen die vinden dat het allemaal prima werkt, het in ieder geval de enige manier is, en een andere oplossing die de problemen opheft, een utopie is.

[SymbolicFrank]

nero355 schreef op woensdag 19 september 2018 @ 10:12:
[...]

Voordat je dat doet : Kijk ook eens naar CEPH => https://ceph.com/ceph-storage/

Succes!

Interessant, neem ik mee!

[imdos]

Mannen; ik weet even niet waar ik goed aan ga doen. Ik heb nu mijn test-NAS bijna zover dat ik een veilige en goede case heb i.pv. de huidge en denk er nu dus over om mijn config nog eens onder de loep te nemen.

Huidige setup. FreeNAS 11.1-U6 met:
ASRock Rack C2750D4I met 32Gb ECC
RAID-Z2 6* 4Tb (plus 2 reserve schijven i.h.g.v. disk failures).
RAID-Z1 van 3* 240Gb Crucial BX200 SSD voor VM's, jails, Docker's et cetera. Ik wil 1x Windows draaien (W7 of W10), 1x Linux; beide bhyve denk ik, Docker voor de spielerij en nog diverse jails voor downloading en sharing (couchpotato, sabnzbd, etc. en plex + emby).

Plan:
Nu zat ik te denken om i.p.v. de 6*4Tb dit uit te breiden naar de max van 8 (i.v.m. ruimte in 2U kast met 8x hotswap). Moet ik enkel wel weer 1 of 2 nieuwe bijkopen via V&A voor on-the-fly redundancy.
Dit komt echter niet goed uit met 4K schijven. Daarnaast heb ik een probleem mocht ik dan een storage groei hebben. Dan moet ik 8 schijven kopen om uit te bouwen. RAID-Z3 vind ik een te grote penalty hit zeker bij het beschikbaar houden van minstens een schijf op de plank.
Maar wil ik dit anders doen dan kom ik uit op 2x een vdev van 4*4Tb RAID-Z1. Ook niet echt een geruststellende gedachte. Zie ik nog andere, logischere, opties over het hoofd

2. i.p.v. 3* naar 4* SSD in RAID-Z1, dit is ook meteen de max. i.v.m. 12 aanwezige SATA poorten op het moederbord. Moet wel kunnen na het e.e.a. gelezen te hebben dacht ik. Of zie ik wederom iets over het hoofd?

[Paul]

Hoezo komt het niet uit met 4k schijven? Geen macht van 2 aan dataschijven? Voor thuis (vooral grote files en lage load) maakt dat sowieso al een heel stuk minder uit en met compressie erbij maakt het nog minder uit: https://www.delphix.com/b...p-worrying-and-love-raidz

Tenzij dat artikel debunked is of zo, dan hoor ik het graag

[nero355]

imdos schreef op vrijdag 21 september 2018 @ 17:24:
plex + emby

Die twee doen eigenlijk hetzelfde dus ik zou zeggen maak een keuze en hou het daarbij

[imdos]

Paul schreef op vrijdag 21 september 2018 @ 17:32:
Hoezo komt het niet uit met 4k schijven? Geen macht van 2 aan dataschijven? Voor thuis (vooral grote files en lage load) maakt dat sowieso al een heel stuk minder uit en met compressie erbij maakt het nog minder uit: https://www.delphix.com/b...p-worrying-and-love-raidz

Tenzij dat artikel debunked is of zo, dan hoor ik het graag

Potverdikke, dat is een mooi artikel. Ik ben gerustgesteld. Er zit ook een handige Excel bij om te bekijken wat je verlies zal zijn. Erg fijn, daar kan ik wel wat mee.

Verder off-topic als reactie op @nero355 Ik wil btw plex om alles op elk device te kunnen afspelen en emby voor het goed kunnen syncen van dit alles. zodat je kan pauzeren op Chromecast en kodi en verder kijken op een ander device. Of heb ik iets gemist?

[nero355]

imdos schreef op vrijdag 21 september 2018 @ 23:53:
Potverdikke, dat is een mooi artikel. Ik ben gerustgesteld. Er zit ook een handige Excel bij om te bekijken wat je verlies zal zijn. Erg fijn, daar kan ik wel wat mee.

Verder off-topic als reactie op @nero355 Ik wil btw plex om alles op elk device te kunnen afspelen en emby voor het goed kunnen syncen van dit alles. zodat je kan pauzeren op Chromecast en kodi en verder kijken op een ander device. Of heb ik iets gemist?

Geen idee wat je met die Chromecast doet, maar ik stel het me effe zo voor :
- Meerdere Kodi Clients.
- Emby plug-in voor het syncen van de database.
- Plex voor het transcoden naar apparaten, maar dat heb je amper nodig tegenwoordig dus ik gok dat het dan voor de momenten waarop je buiten het huis bent is bedoeld

Maar... dat laatste kan Emby ook als je hier kijkt bijvoorbeeld : https://www.smarthomebegi...mby-comparison-with-kodi/

[imdos]

nero355 schreef op zaterdag 22 september 2018 @ 09:26:
[...]

Geen idee wat je met die Chromecast doet, maar ik stel het me effe zo voor :
/

Transcoden vanaf plex was het idee. Zodat ik onafhankelijk ben van het device of de source.

[nero355]

imdos schreef op zaterdag 22 september 2018 @ 11:20:
Transcoden vanaf plex was het idee. Zodat ik onafhankelijk ben van het device of de source.

Dat kan Emby dus ook

[SymbolicFrank]

Als je programmeert in C++, zijn er heel veel artikelen die je vertellen wat je wel, en vooral niet moet doen. Maar bijna al die dingen gelden ook alleen voor C++. Andere programmeertalen hebben daar geen last van.

Nou is het probleem, dat nog steeds veel mensen en bedrijven in C++ programmeren. Gewoon, omdat ze dat al 30+ jaar doen. En het is dus voor hun de enige manier.

Je komt dus heel veel mensen tegen, die je vertellen hoe je moet programmeren, in iedere willekeurige programmeertaal, terwijl dat in die specifieke taal geen enkel probleem is. En als je daar over in discussie gaat, vertellen ze je dat die nieuwe programmeertaal veel te ingewikkeld is, en ze teruggaan naar C++, waar "alles gewoon werkt".

Ik dank jullie dan ook voor het meedenken, maar alle aangedragen oplossingen zijn RAID, of manieren waarmee je de problemen met RAID kunt verminderen of omzeilen.

Ik wil wat anders en beters.

[imdos]

SymbolicFrank schreef op zondag 23 september 2018 @ 04:25:
(Knip) verhaal over programmeren in C++(Knip).

Ik dank jullie dan ook voor het meedenken, maar alle aangedragen oplossingen zijn RAID, of manieren waarmee je de problemen met RAID kunt verminderen of omzeilen.

Ik wil wat anders en beters.

Imho, Als we je niet goed hebben geholpen is of je vraag niet duidelijk genoeg of bestaat het niet.

Bij het laatste moet je het zelf bouwen (vanaf een goede basis uitbouwen desnoods)

[CurlyMo]

@SymbolicFrank Dit is echt veel te kort door de bocht. De meeste professionals programmeren in c++, omdat dat de beste taal is voor het project dat voor ze ligt. Of inderdaad omdat dat dat de beste taal was toen het project begon. Als bij een ander project een andere taal vereist is dan gebruikt men dat. Niet omdat men die talen nu eenmaal kennen, maar omdat men de principes van programmeren kent zoals (een paar willekeurige termen) OOP, low level memory management, design patterns, front en backend talen, functioneel en imperatief enz.

Wij kiezen dus geen ZFS, omdat het het enige is dat we kennen, maar omdat dat het beste product voor ons doel is. Met inderdaad ook haken en ogen zoals het gebrek aan Block-pointer rewrite. Maar daar is binnen de ZFS ontwikkelaars ook bewust voor gekozen, omdat dat een risico volle operatie is. Voor mij levert dat ik geen enkele beperking op, want nu ik na vier jaar weer ruimte tekort kom, wordt het ook tijd om gewoon al vier mijn schijven weer te vervangen. Zodra een ander product beter wordt voor mijn doel, dan stap ik over.

[FireDrunk]

@CurlyMo Blockpointer rewrite is exit:

YouTube: OpenZFS Device Removal and RAID-Z Expansion, by Matt Ahrens

RAIDZ Expansion is in de maak.

[CurlyMo]

@FireDrunk Super interessant. Ik zit nog wel een beetje te dubben op dat stukje "Transient errors become permanent". Klopt het dat je beide operaties (verkleinen en vergroten) alleen moet doen na een succesvolle scrub zodat je zeker weet dat je geen "Transient errors" hebt?

[FireDrunk]

Transient errors zijn toch nog niet gevonden errors? Dacht dat ze bezig waren om dat te mitigeren door altijd te scrubben voor de reflow. Maar filmpje is al ouder, ben niet echt op de hoogte hoe ver ze zijn.

[Paul]

SymbolicFrank schreef op zondag 23 september 2018 @ 04:25:
Ik dank jullie dan ook voor het meedenken, maar alle aangedragen oplossingen zijn RAID, of manieren waarmee je de problemen met RAID kunt verminderen of omzeilen.

Ik wil wat anders en beters.

Je kunt single disk of JBOD draaien? Als het andere wordt een vorm van RAID zodra je meer dan één schijf tegelijk aanspreekt voor een bestandje. Sommigen doen het op bestandsniveau, sommige op blockniveau, maar zodra je dingen gaat verdelen over meerdere schijven ben je met het concept RAID bezig...

[imdos]

https://forums.servetheho...s-media-array.8272/page-2

imdos schreef op vrijdag 21 september 2018 @ 17:24:
<knip>huidige config: RAID-Z2 6* 4Tb (plus 2 reserve schijven i.h.g.v. disk failures).
<knip>
Plan:
Nu zat ik te denken om i.p.v. de 6*4Tb dit uit te breiden naar de max van 8 (i.v.m. ruimte in 2U kast met 8x hotswap). Moet ik enkel wel weer 1 of 2 nieuwe bijkopen via V&A voor on-the-fly redundancy.
Daarnaast heb ik een probleem mocht ik dan een storage groei hebben. Dan moet ik 8 schijven kopen om uit te bouwen. RAID-Z3 vind ik een te grote penalty hit zeker bij het beschikbaar houden van minstens een schijf op de plank.
Maar wil ik dit anders doen dan kom ik uit op 2x een vdev van 4*4Tb RAID-Z1. Ook niet echt een geruststellende gedachte. Zie ik nog andere, logischere, opties over het hoofd

Hierin zegt met dus; veiligheid dan Z2 en er is weinig probleem met saturatie van de link met Z2. Echter het uitbreiden naar een grotere array wordt dan dus veel lastiger. Dan moet ik echt naar 6x6 in Z-3 of zoiets en dus opnieuw opbouwen en wederom migreren. Auto expand is dan namelijk wel erg prijzig.

[CurlyMo]

imdos schreef op maandag 24 september 2018 @ 15:32:
https://forums.servetheho...s-media-array.8272/page-2
[...]

Hierin zegt met dus; veiligheid dan Z2 en er is weinig probleem met saturatie van de link met Z2. Echter het uitbreiden naar een grotere array wordt dan dus veel lastiger. Dan moet ik echt naar 6x6 in Z-3 of zoiets en dus opnieuw opbouwen en wederom migreren. Auto expand is dan namelijk wel erg prijzig.

Ik snap weinig van wat je hier schrijft, en dat ligt niet aan mijn kennis van ZFS

[ Voor 3% gewijzigd door CurlyMo op 24-09-2018 15:34 ]

[imdos]

CurlyMo schreef op maandag 24 september 2018 @ 15:34:
[...]

Ik snap weinig van wat je hier schrijft, en dat ligt niet aan mijn kennis van ZFS

Excuses; in mijn hoofd klonk het logisch

Ik twijfel aan de optimale configuratie voor mijn data (tv show, movies, ISO's etc) en back-up die op FreeNAS staan en wil:

• enerzijds een snelle configuratie
• een veilige back-up houden (lokaal (ook al wil ik in de toekomst weer de backup syncen naar mijn ouders waar weer een NAS moet komen)).

Dus i.h.k.v. het beantwoorden van mijn eigen vraag. Ik moet eigenlijk wel voor 8*4Tb raid-Z2 gaan i.p.v. 2*4Tb raid-Z1 met 2 vdev's. Dat zegt men hier ook.

Zo snel zal mijn use-case geen single disk snelheid satureren met max. 1Gb. toch? Ik verwacht niet meer dan:

• 2 gelijktijdige streams en
• max 2 uploads (vanuit laptop en 1x Android, beide rsync).
• Hooguit komt er dan nog een gelijktijdige download van een newsgroup.

Geen SLOG of L2ARC op SSD btw; wel 4*240Gb SSD in raid-Z1 voor VM's, jails, bhyve en docker (in die volgorde ook).

[CurlyMo]

Je bedoelt denk ik 2x 4TB mirrors. Dat is niet hetzelfde als RAIDZ1. De meningen verschillen over welke de beste route is. Helemaal als we binnenkort pools kunnen uitbreiden met schijven lijkt me RAIDZ2 een prima keuze.

Satureren lijkt me inderdaad ook niet.

[FireDrunk]

De snelheid van een RAIDZ array is niet die van 1 disk qua *bandbreedte*, maar die van *iops*.

Groot verschil.

Mijn RAIDZ2 array (6*4TB) doet vrolijk >350MB/s, en die is al bijna helemaal vol, en 60% gefragmenteerd

thijs@nas:~$ dd if=/archive/Backups/Desktop\ Backup\ 01-08-2016/Samsung\ SSD\ 850\ PRO\ 512GB_full_b1_s1_v1.tib of=/dev/null bs=16M
^C2874+0 records in
2873+0 records out
48200941568 bytes (48 GB, 45 GiB) copied, 133.243 s, 362 MB/s

[Sando]

Ik krijg mijn vanilla ZFS on Linux datasets niet te zien onder "Devices" in Nemo of Nautilus.
Blijkbaar heb je dat bij de officiële Ubuntu release van ZFS wel.

Hoe doen ze dat? Met welke hook of welk commando kan ik mijn datasets ook bij "Devices" listen?

Related: https://github.com/linuxmint/nemo/issues/1951

[FireDrunk]

Datasets zijn toch geen devices? Dat zijn gewoon gemounte directories? Ik gok dat alleen Zdev's onder Devices komen te staan, ook bij de Ubuntu release.

[Demogorg0N]

hey iedereen, na lang lurken toch zelf eens posten.

ik zit met een probleem op mijn freenas, ik heb 2 dagen geleden een upgrade gedaan naar 11.2-beta3.
had niet gezien dat de 11.2-stable train nog een beta was, anders had ik wel nog gewacht.

Maar deze is gisteren gecrasht, geen idee waarom, de boot environment was volledig kapot. Ik heb deze terug opgestart op 11.1-U6, maar al mijn pools waren leeg.
via de ISO terug een upgrade gedaan naar 11.2-beta3, maar mijn pools blijven leeg...
enkele vdev's zijn wel nog intact (plex jail, ISCSI volume & mijn HDD NFS datastore) & sommige heb ik wel nog snapshots, maar niet gewone data... (mijn SSD datastore)

ik heb wel al mijn pools geupgrade na de install...

iemand enig idee hoe of waarom dit gebeurt is? en als er nog hoop is dat ik de data terug zou kunnen vinden?

[CurlyMo]

Demogorg0N schreef op donderdag 11 oktober 2018 @ 09:48:
hey iedereen, na lang lurken toch zelf eens posten.

ik zit met een probleem op mijn freenas, ik heb 2 dagen geleden een upgrade gedaan naar 11.2-beta3.
had niet gezien dat de 11.2-stable train nog een beta was, anders had ik wel nog gewacht.

Maar deze is gisteren gecrasht, geen idee waarom, de boot environment was volledig kapot. Ik heb deze terug opgestart op 11.1-U6, maar al mijn pools waren leeg.
via de ISO terug een upgrade gedaan naar 11.2-beta3, maar mijn pools blijven leeg...
enkele vdev's zijn wel nog intact (plex jail, ISCSI volume & mijn HDD NFS datastore) & sommige heb ik wel nog snapshots, maar niet gewone data... (mijn SSD datastore)

ik heb wel al mijn pools geupgrade na de install...

iemand enig idee hoe of waarom dit gebeurt is? en als er nog hoop is dat ik de data terug zou kunnen vinden?

Wat zeggen de boot logs?
Hoe stel je vast dat je pools leeg zijn?
Wat is de uitvoer van een handmatige zpool import?
Heb je al een FreeBSD 11.2 live cd geprobeerd?

[Demogorg0N]

CurlyMo schreef op donderdag 11 oktober 2018 @ 09:52:
[...]

Wat zeggen de boot logs?
Hoe stel je vast dat je pools leeg zijn?
Wat is de uitvoer van een handmatige zpool import?
Heb je al een FreeBSD 11.2 live cd geprobeerd?

de boot logs zien er goed uit, daar zie ik niets verkeerd in.

de pools tonen in de GUI een used space van 50 - 100 Kib. (in plaats van +- 40TiB voor mijn media pool)
via de CLI een ls -lst toont niets, via SMB zijn ze leeg & via NFS zijn ze ook leeg.

de pools zijn wel degelijk geimporteerd, ik zie ze in de GUI & CLI.
of stel je voor om ze de unmounten en eens manueel opnieuw te importeren?

een FreeBSD 11.2 liveCD heb ik nog niet geprobeerd, dat zal ik zeker vanavond eens doen als ik thuis ben.
Of misschien straks eens proberen over VPN via de console.

[CurlyMo]

Demogorg0N schreef op donderdag 11 oktober 2018 @ 09:57:
[...]
de pools zijn wel degelijk geimporteerd, ik zie ze in de GUI & CLI.
of stel je voor om ze de unmounten en eens manueel opnieuw te importeren?

Ik ben benieuwd naar een zpool status commando op de CLI.

een FreeBSD 11.2 liveCD heb ik nog niet geprobeerd, dat zal ik zeker vanavond eens doen als ik thuis ben.
Of misschien straks eens proberen over VPN via de console.

Dit zijn overigens de beschikbare feature flags in FreeBSD 11.1:

zroot feature@async_destroy enabled local
zroot feature@empty_bpobj active local
zroot feature@lz4_compress active local
zroot feature@multi_vdev_crash_dump enabled local
zroot feature@spacemap_histogram active local
zroot feature@enabled_txg active local
zroot feature@hole_birth active local
zroot feature@extensible_dataset enabled local
zroot feature@embedded_data active local
zroot feature@bookmarks enabled local
zroot feature@filesystem_limits enabled local
zroot feature@large_blocks enabled local
zroot feature@sha512 enabled local
zroot feature@skein enabled local

Dit degene in FreeBSD 11.2

zroot feature@async_destroy enabled local
zroot feature@empty_bpobj active local
zroot feature@lz4_compress active local
zroot feature@multi_vdev_crash_dump enabled local
zroot feature@spacemap_histogram active local
zroot feature@enabled_txg active local
zroot feature@hole_birth active local
zroot feature@extensible_dataset enabled local
zroot feature@embedded_data active local
zroot feature@bookmarks enabled local
zroot feature@filesystem_limits enabled local
zroot feature@large_blocks enabled local
zroot feature@sha512 disabled local
zroot feature@skein disabled local
zroot feature@device_removal disabled local
zroot feature@obsolete_counts disabled local
zroot feature@zpool_checkpoint disabled local

Het is overduidelijk dat er drie nieuwe feature flags bij zijn gekomen.

Lees ook dit forum topic maar eens:
https://forums.freenas.or...ture-flags-in-freenas.95/

Het kan dus zijn dat dat de reden is dat je je pools niet meer kunt goed importeren in oude versies. Het is dus ook erg naïef om zomaar even een zpool upgrade te doen, zonder dat je blijkbaar weet wat de consequenties zijn.

Ik ben benieuwd naar de FreeBSD 11.2 LiveCD.

Oftewel: Don't fix it if it aint broken.

---

Ik was even de nieuwe zpool remove features aan het testen, maar dat leverde me in FreeBSD 11.2 een mooie kernel panic op Nog even geen zpool upgrade voor mij

[FireDrunk]

@Demogorg0N Dat de pools geimporteerd zijn wil niet altijd zeggen dat de filesystems goed gemount zijn.
FreeNAS deed dacht ik alles op legacy mounts onder /mnt.

Kan je eens een overzicht geven van alles wat daadwerkelijk gemount is?

[Demogorg0N]

CurlyMo schreef op donderdag 11 oktober 2018 @ 10:05:
[...]

Ik ben benieuwd naar een zpool status commando op de CLI.

dit is de output van zpool status

zpool status
  pool: Data
 state: ONLINE
  scan: scrub repaired 0 in 0 days 05:10:33 with 0 errors on Sun Oct  7 05:10:40 2018
config:

        NAME                                            STATE     READ WRITE CKSUM
        Data                                            ONLINE       0     0     0
          mirror-0                                      ONLINE       0     0     0
            gptid/951f7038-5d69-11e6-bf47-90e2ba3e5700  ONLINE       0     0     0
            gptid/962f5bd8-5d69-11e6-bf47-90e2ba3e5700  ONLINE       0     0     0
        cache
          gptid/6dd9d8cf-ccb6-11e7-bdb3-90e2ba3e5700    ONLINE       0     0     0
          gptid/6e24d567-ccb6-11e7-bdb3-90e2ba3e5700    ONLINE       0     0     0

errors: No known data errors

  pool: Datastore
 state: ONLINE
  scan: scrub repaired 0 in 0 days 00:12:25 with 0 errors on Sun Sep  2 00:12:27 2018
config:

        NAME                                            STATE     READ WRITE CKSUM
        Datastore                                       ONLINE       0     0     0
          mirror-0                                      ONLINE       0     0     0
            gptid/4085d470-cb93-11e7-bdb3-90e2ba3e5700  ONLINE       0     0     0
            gptid/40e45bfa-cb93-11e7-bdb3-90e2ba3e5700  ONLINE       0     0     0

errors: No known data errors

  pool: Media
 state: ONLINE
  scan: scrub repaired 1.87M in 0 days 08:09:23 with 0 errors on Sun Sep  2 08:09:25 2018
config:

        NAME                                            STATE     READ WRITE CKSUM
        Media                                           ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            gptid/004f54f2-4ba8-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/01008a9c-4ba8-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/01a95c79-4ba8-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/025ca950-4ba8-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/031185f9-4ba8-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/03c35714-4ba8-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/04755980-4ba8-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/05267b6d-4ba8-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/05e81a98-4ba8-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/06b12b5f-4ba8-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
          raidz2-1                                      ONLINE       0     0     0
            gptid/50b91004-4c60-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/51959e97-4c60-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/52f1c8a1-4c60-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/54476e5e-4c60-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/55480dc0-4c60-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/56a9e5f3-4c60-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/582e5920-4c60-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/59ab28c5-4c60-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/5b188572-4c60-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0
            gptid/5c9596ef-4c60-11e7-8f77-90e2ba3e5700  ONLINE       0     0     0

errors: No known data errors

  pool: freenas-boot
 state: ONLINE
  scan: scrub repaired 0 in 0 days 00:11:00 with 0 errors on Mon Oct  8 03:56:34 2018
config:

        NAME        STATE     READ WRITE CKSUM
        freenas-boot  ONLINE       0     0     0
          da25p2    ONLINE       0     0     0

errors: No known data errors

  pool: temp
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
        Expect reduced performance.
action: Replace affected devices with devices that support the
        configured block size, or migrate data to a properly configured
        pool.
  scan: scrub repaired 0 in 0 days 04:58:25 with 0 errors on Sun Oct  7 05:00:46 2018
config:

        NAME                                            STATE     READ WRITE CKSUM
        temp                                            ONLINE       0     0     0
          mirror-0                                      ONLINE       0     0     0
            gptid/c5d20a69-6afb-11e8-a254-90e2ba3e5700  ONLINE       0     0     0  block size: 512B configured, 4096B native
            gpt/HDD_12                                  ONLINE       0     0     0  block size: 512B configured, 4096B native

errors: No known data errors

Het kan dus zijn dat dat de reden is dat je je pools niet meer kunt goed importeren in oude versies. Het is dus ook erg naïef om zomaar even een zpool upgrade te doen, zonder dat je blijkbaar weet wat de consequenties zijn.

dat de import in een oude versie niet meer werkt kan ik volledig begrijpen.
alsook dat die zpool upgrade niet het beste idee was, maar hindsight is 20/20...

Ik ben benieuwd naar de FreeBSD 11.2 LiveCD.

Oftewel: Don't fix it if it aint broken.

agreed, maar ik had om een probleem op te lossen in mijn download jail een 11.2 base image nodig...
de liveCD is aan het downloaden, ik laat iets weten wanneer ik heb kunnen testen.

FireDrunk schreef op donderdag 11 oktober 2018 @ 10:33:
@Demogorg0N Dat de pools geimporteerd zijn wil niet altijd zeggen dat de filesystems goed gemount zijn.
FreeNAS deed dacht ik alles op legacy mounts onder /mnt.

Kan je eens een overzicht geven van alles wat daadwerkelijk gemount is?

sure, bij deze, en voor zover ik kan zien is alles wel degelijk goed gemount.

 mount
freenas-boot/ROOT/default-20181010-221255 on / (zfs, local, noatime, nfsv4acls)
devfs on /dev (devfs, local, multilabel)
tmpfs on /etc (tmpfs, local)
tmpfs on /mnt (tmpfs, local)
tmpfs on /var (tmpfs, local)
fdescfs on /dev/fd (fdescfs)
Data on /mnt/Data (zfs, local, nfsv4acls)
Data/.bhyve_containers on /mnt/Data/.bhyve_containers (zfs, local, nfsv4acls)
Data/Data on /mnt/Data/Data (zfs, local, nfsv4acls)
Data/Datastore on /mnt/Data/Datastore (zfs, NFS exported, local, noatime, nfsv4acls)
Data/ISCSI on /mnt/Data/ISCSI (zfs, local, nfsv4acls)
Data/Profiles on /mnt/Data/Profiles (zfs, local, nfsv4acls)
Data/VMs on /mnt/Data/VMs (zfs, local, nfsv4acls)
Data/hulin on /mnt/Data/hulin (zfs, local, nfsv4acls)
Data/jails on /mnt/Data/jails (zfs, local, nfsv4acls)
Data/jails/.warden-template-pluginjail-10.3-x64 on /mnt/Data/jails/.warden-template-pluginjail-10.3-x64 (zfs, local, nfsv4acls)
Data/jails/.warden-template-pluginjail-11.0-x64 on /mnt/Data/jails/.warden-template-pluginjail-11.0-x64 (zfs, local, nfsv4acls)
Data/jails/.warden-template-standard-10.3-x64 on /mnt/Data/jails/.warden-template-standard-10.3-x64 (zfs, local, nfsv4acls)
Data/jails/.warden-template-standard-11.0-x64 on /mnt/Data/jails/.warden-template-standard-11.0-x64 (zfs, local, nfsv4acls)
Data/jails/HULIN-PLX01 on /mnt/Data/jails/HULIN-PLX01 (zfs, local, nfsv4acls)
Data/jails/HULIN-SAB01 on /mnt/Data/jails/HULIN-SAB01 (zfs, local, nfsv4acls)
Data/jails/sabnzbd_1 on /mnt/Data/jails/sabnzbd_1 (zfs, local, nfsv4acls)
Data/iocage on /mnt/iocage (zfs, local, nfsv4acls)
Data/iocage/download on /mnt/iocage/download (zfs, local, nfsv4acls)
Data/iocage/images on /mnt/iocage/images (zfs, local, nfsv4acls)
Data/iocage/jails on /mnt/iocage/jails (zfs, local, nfsv4acls)
Data/iocage/log on /mnt/iocage/log (zfs, local, nfsv4acls)
Data/iocage/releases on /mnt/iocage/releases (zfs, local, nfsv4acls)
Data/iocage/templates on /mnt/iocage/templates (zfs, local, nfsv4acls)
temp on /mnt/temp (zfs, local, noatime, nfsv4acls)
temp/download on /mnt/temp/download (zfs, local, noatime, nfsv4acls)
Media on /mnt/Media (zfs, local, nfsv4acls)
Media/Movies on /mnt/Media/Movies (zfs, local, nfsv4acls)
Media/TV on /mnt/Media/TV (zfs, local, nfsv4acls)
freenas-boot/.system on /var/db/system (zfs, local, noatime, nfsv4acls)
freenas-boot/.system/cores on /var/db/system/cores (zfs, local, noatime, nfsv4acls)
freenas-boot/.system/samba4 on /var/db/system/samba4 (zfs, local, noatime, nfsv4acls)
freenas-boot/.system/syslog-76c11d7f8a944b3d8e42fe35420dbaa3 on /var/db/system/syslog-76c11d7f8a944b3d8e42fe35420dbaa3 (zfs, local, noatime, nfsv4acls)
freenas-boot/.system/rrd-76c11d7f8a944b3d8e42fe35420dbaa3 on /var/db/system/rrd-76c11d7f8a944b3d8e42fe35420dbaa3 (zfs, local, noatime, nfsv4acls)
freenas-boot/.system/configs-76c11d7f8a944b3d8e42fe35420dbaa3 on /var/db/system/configs-76c11d7f8a944b3d8e42fe35420dbaa3 (zfs, local, noatime, nfsv4acls)
freenas-boot/.system/webui on /var/db/system/webui (zfs, local, noatime, nfsv4acls)
Datastore on /mnt/Datastore (zfs, NFS exported, local, noatime, nfsv4acls)

[CurlyMo]

De snapshots bevatten nog wel je originele data?
Zie je nog iets raars in zpool history?
Wat zeggen zpool list en zfs list?

[FireDrunk]

Is de directory /mnt/Media(/*) ook echt leeg op de commandline?

[Demogorg0N]

CurlyMo schreef op donderdag 11 oktober 2018 @ 10:44:
De snapshots bevatten nog wel je originele data?

ja, alhoewel van SSD datastore de laatste snapshot van ergens in Juni is.
De HDD datastore heeft wel recentste snapshot nog staan.

Zie je nog iets raars in zpool history?

nope, niets vreemd, enkel scrubs & imports & de upgrade

2018-07-15.00:00:08 zpool scrub temp
2018-08-26.00:00:08 zpool scrub temp
2018-09-22.15:01:07 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 9472761440627661817
2018-09-22.15:01:07 zpool set cachefile=/data/zfs/zpool.cache temp
2018-09-22.15:06:30 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 9472761440627661817
2018-09-22.15:06:30 zpool set cachefile=/data/zfs/zpool.cache temp
2018-10-07.00:03:02 zpool scrub temp
2018-10-10.00:42:50 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 9472761440627661817
2018-10-10.00:42:50 zpool set cachefile=/data/zfs/zpool.cache temp
2018-10-10.00:56:18 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 9472761440627661817
2018-10-10.00:56:18 zpool set cachefile=/data/zfs/zpool.cache temp
2018-10-10.01:00:38 zpool upgrade temp
2018-10-10.23:05:56 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 9472761440627661817
2018-10-10.23:05:56 zpool set cachefile=/data/zfs/zpool.cache temp
2018-10-11.01:03:08 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 9472761440627661817
2018-10-11.01:03:08 zpool set cachefile=/data/zfs/zpool.cache temp

Wat zeggen zpool list en zfs list?

 zpool list
NAME           SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
Data          2.72T   426G  2.30T        -         -    52%    15%  1.01x  ONLINE  /mnt
Datastore      236G   157G  78.5G        -         -    62%    66%  1.08x  ONLINE  /mnt
Media         81.8T   317M  81.7T        -         -     0%     0%  1.00x  ONLINE  /mnt
freenas-boot  14.4G  4.93G  9.44G        -         -      -    34%  1.00x  ONLINE  -
temp           928G  10.2M   928G        -         -     3%     0%  1.00x  ONLINE  /mnt

zfs list
NAME                                                            USED  AVAIL  REFER  MOUNTPOINT
Data                                                            573G  2.08T  1.07G  /mnt/Data
Data/.bhyve_containers                                           92K  2.08T    92K  /mnt/Data/.bhyve_containers
Data/Data                                                       104K  2.08T   104K  /mnt/Data/Data
Data/Datastore                                                 9.36G  2.08T  9.36G  /mnt/Data/Datastore
Data/ISCSI                                                      508G  2.08T    96K  /mnt/Data/ISCSI
Data/ISCSI/ISCSI-MDT                                            508G  2.22T   366G  -
Data/Profiles                                                    96K  2.08T    96K  /mnt/Data/Profiles
Data/VMs                                                         88K  2.08T    88K  /mnt/Data/VMs
Data/hulin                                                       96K  2.08T    96K  /mnt/Data/hulin
Data/iocage                                                    3.70M  2.08T  3.19M  /mnt/iocage
Data/iocage/download                                             88K  2.08T    88K  /mnt/iocage/download
Data/iocage/images                                               88K  2.08T    88K  /mnt/iocage/images
Data/iocage/jails                                                88K  2.08T    88K  /mnt/iocage/jails
Data/iocage/log                                                  88K  2.08T    88K  /mnt/iocage/log
Data/iocage/releases                                             88K  2.08T    88K  /mnt/iocage/releases
Data/iocage/templates                                            88K  2.08T    88K  /mnt/iocage/templates
Data/jails                                                     35.9G  2.08T   104K  /mnt/Data/jails
Data/jails/.warden-template-pluginjail-10.3-x64                 469M  2.08T  3.24M  /mnt/Data/jails/.warden-template-pluginjail-10.3-x64
Data/jails/.warden-template-pluginjail-11.0-x64                 539M  2.08T  3.38M  /mnt/Data/jails/.warden-template-pluginjail-11.0-x64
Data/jails/.warden-template-standard-10.3-x64                  1.69G  2.08T  3.26M  /mnt/Data/jails/.warden-template-standard-10.3-x64
Data/jails/.warden-template-standard-11.0-x64                  1.79G  2.08T  3.39M  /mnt/Data/jails/.warden-template-standard-11.0-x64
Data/jails/HULIN-PLX01                                         31.4G  2.08T  3.30M  /mnt/Data/jails/HULIN-PLX01
Data/jails/HULIN-SAB01                                          256K  2.08T  3.41M  /mnt/Data/jails/HULIN-SAB01
Data/jails/sabnzbd_1                                            280K  2.08T  3.42M  /mnt/Data/jails/sabnzbd_1
Datastore                                                       171G  70.8G  4.07G  /mnt/Datastore
Media                                                           230M  60.3T   201K  /mnt/Media
Media/Movies                                                    530K  60.3T   530K  /mnt/Media/Movies
Media/TV                                                        219K  60.3T   219K  /mnt/Media/TV
freenas-boot                                                   4.93G  8.99G    64K  none
freenas-boot/.system                                           72.7M  8.99G    36K  legacy
freenas-boot/.system/configs-76c11d7f8a944b3d8e42fe35420dbaa3   126K  8.99G   126K  legacy
freenas-boot/.system/cores                                     64.1M  8.99G  64.1M  legacy
freenas-boot/.system/rrd-76c11d7f8a944b3d8e42fe35420dbaa3      8.07M  8.99G  8.07M  legacy
freenas-boot/.system/samba4                                     132K  8.99G   132K  legacy
freenas-boot/.system/syslog-76c11d7f8a944b3d8e42fe35420dbaa3    216K  8.99G   216K  legacy
freenas-boot/.system/webui                                       29K  8.99G    29K  legacy
freenas-boot/ROOT                                              4.84G  8.99G    29K  none
freenas-boot/ROOT/11.1-RELEASE                                  372K  8.99G   825M  /
freenas-boot/ROOT/11.1-U4                                       386K  8.99G   836M  /
freenas-boot/ROOT/11.1-U5                                       250K  8.99G   838M  /
freenas-boot/ROOT/11.1-U6                                      3.97G  8.99G   839M  /
freenas-boot/ROOT/Initial-Install                                 1K  8.99G   727M  legacy
freenas-boot/ROOT/Wizard-2017-11-14_08-31-11                      1K  8.99G   727M  legacy
freenas-boot/ROOT/default                                       125K  8.99G   727M  legacy
freenas-boot/ROOT/default-20181010-221255                       883M  8.99G   883M  legacy
freenas-boot/grub                                              6.85M  8.99G  6.85M  legacy
temp                                                           9.95M   899G    21K  /mnt/temp
temp/download                                                    22K   899G    22K  /mnt/temp/download

FireDrunk schreef op donderdag 11 oktober 2018 @ 10:46:
Is de directory /mnt/Media(/*) ook echt leeg op de commandline?

ja, afgezien van de 2 datasets, maar de 2 datasets zijn leeg

/mnt/Media # ls -als
total 331
  1 drwxrwxrwx  4 media  media    4 Nov 14  2017 .
  0 drwxr-xr-x  7 root   wheel  384 Oct 11 06:36 ..
330 drwxrwxrwx  2 media  media    2 Oct 10 05:25 Movies
  1 drwxrwxrwx  2 media  media    2 Oct 10 05:24 TV

/mnt/Media/Movies # ls -als
total 330
330 drwxrwxrwx  2 media  media  2 Oct 10 05:25 .
  1 drwxrwxrwx  4 media  media  4 Nov 14  2017 ..

/mnt/Media/TV # ls -als
total 1
1 drwxrwxrwx  2 media  media  2 Oct 10 05:24 .
1 drwxrwxrwx  4 media  media  4 Nov 14  2017 ..

De liveCD zal moeten wachten tot vanavond, als ik freenas herstart zal mijn PFsense down gaan & ik heb geen storage vmotion mogelijkheden op mijn ESXi.

[CurlyMo]

Demogorg0N schreef op donderdag 11 oktober 2018 @ 11:06:
[...]
# zpool list

NAME           SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
Media         81.8T   317M  81.7T        -         -     0%     0%  1.00x  ONLINE  /mnt

Het is helder dat je Media pool nagenoeg leeg is.

# zfs list
NAME                                                            USED  AVAIL  REFER  MOUNTPOINT
Media                                                           230M  60.3T   201K  /mnt/Media
Media/Movies                                                    530K  60.3T   530K  /mnt/Media/Movies
Media/TV                                                        219K  60.3T   219K  /mnt/Media/TV

En nog helderder.

De liveCD zal moeten wachten tot vanavond, als ik freenas herstart zal mijn PFsense down gaan & ik heb geen storage vmotion mogelijkheden op mijn ESXi.

Ik ben benieuwd wat vanilla FreeBSD 11.2 gaat doen, maar ik zie het somber in.

Zou Brein erachter zitten

[FireDrunk]

Ik heb wel eens meegemaakt dat die mount points in de verkeerde volgorde gemount werden, waardoor het mountpoint van /mnt/Media *na* /mnt/Media/Movies etc werdt gedaan. Als daar dan lege directories in staan, lijkt het alsof je datasets leeg zijn, omdat de mount points over elkaar liggen.

Probeer die filessystems eens te unmounten en rustig opnieuw zelf te mounten.


Door wat @CurlyMo zie ik het ook inderdaad somber in. Als zfs denkt dat alles leeg is, is het gewoon over.

[Demogorg0N]

daar vreesde ik al wat voor.
normaal zou er een kleine 40TB aan data onder /mnt/Media moeten staan.

het is alsof iets random beslist heeft van in willekeurige datasets rm -rf * te doen.
daar gaat 15 jaar aan hoarding...

gelukkig heb ik van de echt belangrijke data nog een backup.

ik ga vanavond zeker nog eens de liveCD proberen, maar ik heb er niet echt goede hoop op...

[FireDrunk]

Wel bizar, alsof FreeNAS de filesystems opnieuw heeft aangemaakt. Want rm -rf * is een flinke operatie.

Geen snapshots ook?

[DaCoTa]

Mijn ZFS NAS (ZFSGuru, RaidZ2 met 1x3TB en 5x4TB) die al 8 jaar draait (DaCoTa in "Het grote ZFS topic") heeft zijn eerste grote onderhoud nodig. Een week geleden is de laatste 3TB disk overleden en heb nu een pricewatch: HGST Ultrastar He10 (SATA 6Gbps, 4Kn ISE), 8TB binnen ter vervanging. Na het vervangen van de disk kreeg ik geen toegang meer tot de machine.

Bij een eerste reset kon hij de boot partitie niet vinden. Pas na een power-off kwam de machine op. Ik heb toen de resilver gestart maar na een paar minuten viel de web UI weer uit. Monitor aangesloten en zag daar het volgende:



gpt/axelrod is de bootpartitie (een 8 jaar oude Intel M25) en die is uit het systeem gegooid. De machine is nu niet bereikbaar, niet via de web UI en ook niet via SSH, maar volgens mij loopt de resilver gewoon door want de machine blijft druk.

Ik ga nu eerst een aantal uren wachten (resilver duurt ongeveer 6 tot 8 uur), maar is de vraag - ook gezien bovenstaand verhaal - wat dan? Ik verwacht niet dat ik de hele bootdisk (root on zfs) nog gemirrored kan worden naar een vervangende schijf, dus moet een clean install doen.

Mijn opties: bij ZFSGuru blijven, naar FreeNAS of naar Ubuntu.

• ZFSguru: ik denk de route met het minste risico. Hetzelfde OS, EOL maar heeft de laatste 8 jaar eigenlijk probleemloos gedraaid;
• FreeNAS: geen ervaring mee, actief project en de-facto ZFS implementatie;
• Ubuntu: ben ik inmiddels meer bedreven in dan 8 jaar geleden. Heeft mijn voorkeur, omdat ik eigenlijk op alle andere machines nu ook Ubuntu draai.

En verder, zijn er nog dingen die ik niet moet doen (pool upgraden) of juist wel moet doen? Pool versie is nog 28, dus qua compatibiliteit verwacht ik geen problemen eerlijk gezegd.

[CurlyMo]

DaCoTa schreef op donderdag 11 oktober 2018 @ 14:44:
maar volgens mij loopt de resilver gewoon door want de machine blijft druk.

Wat is druk? De CPU, je pool HDD's? Want het kan ook zomaar zijn dat je PC continue probeert de SSD te benaderen.

• FreeNAS: geen ervaring mee, actief project en de-facto ZFS implementatie;

FreeNAS heeft eigen specificaties wat betreft pool indeling. De vraag is of een pool uit een ander systeem importeren zo goed gaat.

Ik zou kiezen voor een FreeBSD installatie, maar dat hangt van je bedrevenheid af van de FreeBSD CLI. Anders inderdaad Ubuntu, maar dan speelt hetzelfde CLI verhaal. Als je afhankelijk bent van een GUI, dan inderdaad FreeNAS.

Ik zou booten van een FreeBSD LiveCD en van daaruit kijken wat er mis is met je SSD en hoe het met je data pool gaat. Dan weet je ook zeker dat de resilver wel doet wat hij moet doen. Eventueel proberen je GPT te herstellen.

[FireDrunk]

Je pool is in alle 3 de opties te importeren. Volgens mij hoef je je daar niet druk over te maken.
De indeling van ZFSguru komt aardig overeen met die van FreeNAS, en werkt prima in Linux.

[DaCoTa]

CurlyMo schreef op donderdag 11 oktober 2018 @ 14:57:
[...]

Wat is druk? De CPU, je pool HDD's? Want het kan ook zomaar zijn dat je PC continue probeert de SSD te benaderen.


[...]

FreeNAS heeft eigen specificaties wat betreft pool indeling. De vraag is of een pool uit een ander systeem importeren zo goed gaat.

Ik zou kiezen voor een FreeBSD installatie, maar dat hangt van je bedrevenheid af van de FreeBSD CLI. Anders inderdaad Ubuntu, maar dan speelt hetzelfde CLI verhaal. Als je afhankelijk bent van een GUI, dan inderdaad FreeNAS.

Ik zou booten van een FreeBSD LiveCD en van daaruit kijken wat er mis is met je SSD en hoe het met je data pool gaat. Dan weet je ook zeker dat de resilver wel doet wat hij moet doen. Eventueel proberen je GPT te herstellen.

Heb nu de machine naar beneden gehaald en ook een toetsenbord aangesloten, maar de bootdrive kwam helemaal niet meer op, de BIOS zag hem niet eens meer.

Heb nu de bootdrive op de laatste vrije poort gezet, en vooralsnog start hij. De resilver was idd doorgegaan en is inmiddels op 45%. Even afwachten wat de boosdoener is: de SATA poort of de drive. Mijn gok is dat die poort niet meer lekker werkt, vind het vreemd als de drive soms wel werkt en soms niet.

[CurlyMo]

DaCoTa schreef op donderdag 11 oktober 2018 @ 16:03:
[...]
Mijn gok is dat die poort niet meer lekker werkt, vind het vreemd als de drive soms wel werkt en soms niet.

Je kan voor de zekerheid wel even een mirror maken. Als de bootdrive klein is gebleven, dan moet dat met een SSD in 5 minuten wel gedaan zijn.

[DaCoTa]

Hmm, nog niet helemaal out of the woods:

code:

Oct 11 16:05:32 zfsguru kernel: (ada0:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 58 98 7e 55 40 29 01 00 00 00 00
Oct 11 16:05:32 zfsguru kernel: (ada0:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
Oct 11 16:05:32 zfsguru kernel: (ada0:ahcich1:0:0:0): Retrying command
Oct 11 16:07:22 zfsguru kernel: (ada0:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 30 a8 bb 55 40 2e 01 00 00 00 00
Oct 11 16:07:22 zfsguru kernel: (ada0:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
Oct 11 16:07:22 zfsguru kernel: (ada0:ahcich1:0:0:0): Retrying command
Oct 11 16:12:19 zfsguru kernel: (ada0:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 40 50 08 c0 40 fa 00 00 00 00 00
Oct 11 16:12:19 zfsguru kernel: (ada0:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
Oct 11 16:12:19 zfsguru kernel: (ada0:ahcich1:0:0:0): Retrying command
Oct 11 16:12:19 zfsguru kernel: (ada0:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 40 90 08 c0 40 fa 00 00 00 00 00
Oct 11 16:12:19 zfsguru kernel: (ada0:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
Oct 11 16:12:19 zfsguru kernel: (ada0:ahcich1:0:0:0): Retrying command

ada0 is de eerste dataschijf.

Die van 16:12 gebeurde zodra ik de SATA connector aanraakte van die disk, dus wellicht ook een kabelprobleem daar. Die schijf heeft ook een UDMA_CRC_Error_Count van 4, maar dat had hij volgens mij al voor deze problemen.

[Demogorg0N]

CurlyMo schreef op donderdag 11 oktober 2018 @ 11:10:

Ik ben benieuwd wat vanilla FreeBSD 11.2 gaat doen, maar ik zie het somber in.

zonet eens getest met een liveCD.
Ik kan alle zpools mounten, maar iedere keer met hetzelfde resultaat, alles leeg.

Ik vrees dus dat zoals verwacht alle data weg is.
mocht iemand nog een geniale ingeving hebben, do share.

[CurlyMo]

Demogorg0N schreef op donderdag 11 oktober 2018 @ 17:32:
[...]


zonet eens getest met een liveCD.
Ik kan alle zpools mounten, maar iedere keer met hetzelfde resultaat, alles leeg.

Ik vrees dus dat zoals verwacht alle data weg is.
mocht iemand nog een geniale ingeving hebben, do share.

Dan moet je naar zdb, maar dat is hogere wiskunde die hier volgens mij niet vertegenwoordigd is. Anders toch maar even het FreeNAS forum of eventueel een ZFS mailing list (als die bestaat).

[DaCoTa]

DaCoTa schreef op donderdag 11 oktober 2018 @ 16:15:
[...]
Die van 16:12 gebeurde zodra ik de SATA connector aanraakte van die disk, dus wellicht ook een kabelprobleem daar. Die schijf heeft ook een UDMA_CRC_Error_Count van 4, maar dat had hij volgens mij al voor deze problemen.

Probleem lijkt voorbij met het vervangen van twee kabels, van de bootdisk en van disk 5. Wel verdacht dat er twee kabels tegelijkertijd problemen geven, dus ben er niet helemaal gerust op.

[imdos]

F*ck; ik had juist ook een opwelling deze week om misschien naar FreeNAS 11.2-B3 te kijken i.v.m. verbeterde bhyve support en fixes op iocage + slack.com error support. Daarnaast is het inderdaad een nasty bug die 11.2 versus 11.1 incompatibiliteit.

Ondanks dat dit mijn in aanbouw zijnde NAS is wacht ik toch maar even na het lezen van de horror van
je verslag en de mogelijkheden.

@Demogorg0N FN11.2-RC1 wordt verwacht, nog 3 dagen (of 4 dagen voor download?);

1. Misschien helpt dit bij je probleem
2. Moet je sowieso een bug rapport invullen daar.

En misschien moet je in 11.2 iets eens opnieuw de imports doen? Of is dat ook gebeurt met vanilla 11.2? Want veel erger dan dit kan toch niet.

[ Voor 10% gewijzigd door imdos op 12-10-2018 13:10 . Reden: toevoeging import ]

[Demogorg0N]

imdos schreef op vrijdag 12 oktober 2018 @ 13:07:
F*ck; ik had juist ook een opwelling deze week om misschien naar FreeNAS 11.2-B3 te kijken i.v.m. verbeterde bhyve support en fixes op iocage + slack.com error support. Daarnaast is het inderdaad een nasty bug die 11.2 versus 11.1 incompatibiliteit.

Ondanks dat dit mijn in aanbouw zijnde NAS is wacht ik toch maar even na het lezen van de horror van
je verslag en de mogelijkheden.

@Demogorg0N FN11.2-RC1 wordt verwacht, nog 3 dagen (of 4 dagen voor download?);

1. Misschien helpt dit bij je probleem
2. Moet je sowieso een bug rapport invullen daar.

En misschien moet je in 11.2 iets eens opnieuw de imports doen? Of is dat ook gebeurt met vanilla 11.2? Want veel erger dan dit kan toch niet.

@imdos, dit probleem was er in iedere versie, zelf in de FreeBSD 11.2 liveCD.
dus in gelijk welke versie ik een import deed waren de zpools leeg.
zdb heb me even over ingelezen, maar die vond zelf die pools niet terug, enkel mijn freenas-boot volume...

wachten op die update zal weinig verschil maken.
ik heb er me al bij neergelegd dat ik de data zal kwijt zijn,

bugreport wil ik wel doen, maar mijn boot environment van 11.2-beta was niet meer bruikbaar, dus heb het moeten overschrijven via een 'clean' install met de ISO.
ik heb dus niets van logs meer van wat er zou kunnen gebeurd zijn.

hoe dan ook, wachten op een 'release' release ipv een beta release is de boodschap & je pools niet upgraden als je die specifieke feature flags niet nodig hebt.
ik heb m'n lesje nu wel geleerd...

[FutureCow]

FireDrunk schreef op dinsdag 21 augustus 2018 @ 14:52:
Yay, vandaag Pushover in gebruik genomen! In combinatie met ZED (ZFS Event Daemon), krijg ik nu keurig een melding (en het resultaat) van een scrub gepusht naar mijn telefoon.

Scriptje:

Bash:

#!/bin/bash

[ -f "${ZED_ZEDLET_DIR}/zed.rc" ] && . "${ZED_ZEDLET_DIR}/zed.rc"
. "${ZED_ZEDLET_DIR}/zed-functions.sh"

zed_check_cmd "${ZPOOL}" || exit 9

APP_TOKEN=<token>
USER_KEY=<token>

note_subject="ZFS ${ZEVENT_SUBCLASS} event for ${ZEVENT_POOL} on $(hostname)"
MESSAGE="~~~[ZFS event]
subject: ${note_subject}
eid: ${ZEVENT_EID}
class: ${ZEVENT_SUBCLASS}
host: $(hostname)
time: ${ZEVENT_TIME_STRING}

$(${ZPOOL} status ${ZEVENT_POOL})"

curl -s \
  --form-string "token=${APP_TOKEN}" \
  --form-string "user=${USER_KEY}" \
  --form-string "message=${MESSAGE}" \
      https://api.pushover.net/1/messages.json

Om het scriptje activeren:

root@nas:/etc/zfs/zed.d# ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Aug 21 13:57 .
drwxr-xr-x 4 root root 4.0K Aug 21 13:56 ..
lrwxrwxrwx 1 root root   22 Aug 21 13:53 scrub_finish-pushover.sh -> /root/pushover/push.sh
lrwxrwxrwx 1 root root   22 Aug 21 13:53 scrub_start-pushover.sh -> /root/pushover/push.sh

Aanmaken kan dmv:

ln -s /etc/zfs/zed.d/scrub_start-pushover.sh /root/pushover/push.sh
ln -s /etc/zfs/zed.d/scrub_finish-pushover.sh /root/pushover/push.sh

Misschien in de toekomst nog wat sleutelen aan de opmaak, we'll see.

Hier iets vergelijkbaars voor elkaar gekregen met Telegram, dan heb ik niet een extra app nodig.

[mdbraber]

Hoi! Om zo veel mogelijk applicaties / toepassingen zelf te hosten (zoals bijv. een Dropbox-alternatief) heb ik een thuis-server met 4x5TB storage en ECC RAM en een cloud-server met 2x4TB storage en ECC RAM. Ik wil graag over en weer de servers als backup gebruiken. Dus de cloud-server slaat backups op van data die primair op mijn thuis-server leeft en andersom. Die data bevat ook gevoelige data die bij voorkeur versleuteld moet zijn.

Bij het onderzoeken van verschillende storage / NAS oplossingen was de voor de hand liggende keuze allereerst FreeNAS. Bij wat meer onderzoek naar encryptie-mogelijkheden lijkt dat nog niet meteen een uitgemaakte zaak. Ik kan weliswaar full-disk encryption doen, maar dat lost maar een gedeelte van mijn use-case op. Ik wil namelijk dat backups ook versleuteld verstuurd kunnen worden (dus on-the-line encryptie).

Wat verder onderzoek leidde mij naar de Encryption-at-Rest features van ZFSonLinux door Tom Caputi. Dat is grotendeels in lijn met wat ik zoek (bijv. encrypted zfs send/receive) en inmiddels onderdeel van 0.8-RC1 van ZoL.

Mijn vraag is nu wie er ervaring heeft met het runnen van een "storage appliance" met ZoL in plaats van via de (grafische) interface van FreeNAS. Ik ben prima thuis in de commandline, dat is geen probleem. Het gaat mij voornamelijk om alles wat met monitoring etc. te maken heeft - aangezien slechte monitoring net zo'n drama kan zijn als geen encryptie... Ik heb nog niet heel veel tools gevonden die dit process verder automatiseren (behalve dan de standaard ZFS Events Daemon).

Wat zijn jullie ervaringen met ZFSonLinux als "storage appliance" en het bijbehorende beheer?

[CurlyMo]

mdbraber schreef op dinsdag 16 oktober 2018 @ 14:40:
Wat zijn jullie ervaringen met ZFSonLinux als "storage appliance" en het bijbehorende beheer?

Ik doe niet anders, maar dan in vanilla FreeBSD. Scriptjes zijn er genoeg te vinden of anders zelf te maken naar behoefte. Een aantal van mijn monitoring scripts staan in dit topic.

FutureCow schreef op zondag 14 oktober 2018 @ 08:29:
[...]


Hier iets vergelijkbaars voor elkaar gekregen met Telegram, dan heb ik niet een extra app nodig.
[Afbeelding]

Scripts or it didn't happen

[ Voor 30% gewijzigd door CurlyMo op 16-10-2018 14:56 ]

[mdbraber]

CurlyMo schreef op dinsdag 16 oktober 2018 @ 14:55:
[...]
Ik doe niet anders, maar dan in vanilla FreeBSD. Scriptjes zijn er genoeg te vinden of anders zelf te maken naar behoefte. Een aantal van mijn monitoring scripts staan in dit topic.
[...]

Fair enough :-)

Dan nu op zoek naar het tweede deel van de vraag: als ik Proxmox draai voor al het andere, is het dan beter een VM te draaien voor ZFSonLinux of om dat native te doen?

Het voordeel van een VM zou ik verwachten is het beter managen van toegewezen RAM en CPU en evt. het kunnen draaien van een andere kernel / ZFSonLinux versie.

Het nadeel is echter dat het non-native is met mogelijke performance issues. Iemand daar toevallig ervaring mee? Ik zal het ook even posten in Het grote Proxmox VE topic

[FireDrunk]

mdbraber schreef op dinsdag 16 oktober 2018 @ 15:46:
[...]


Fair enough :-)

Dan nu op zoek naar het tweede deel van de vraag: als ik Proxmox draai voor al het andere, is het dan beter een VM te draaien voor ZFSonLinux of om dat native te doen?

Het voordeel van een VM zou ik verwachten is het beter managen van toegewezen RAM en CPU en evt. het kunnen draaien van een andere kernel / ZFSonLinux versie.

Het nadeel is echter dat het non-native is met mogelijke performance issues. Iemand daar toevallig ervaring mee? Ik zal het ook even posten in Het grote Proxmox VE topic

Ik zou het native doen, die limieten kan je ook prima op ZFS niveau installen (ARC limieten etc).

Wat bedoel je met non-native? Proxmox bied zelfs out-of-the-box support voor ZFS?
Of bedoel je dat ZFS zelf non-native is voor Linux? Dat is achterhaald, ZFS is een 'first-class citizen' op Linux tegenwoordig.

Ook ligt FreeBSD niet meer 'voor' qua features t.o.v. Linux. In sommige gevallen bied FreeBSD wel 'andere' features dan Linux, maar dat is ook zo vice-versa.

Ik draai zelf mijn 2 flinke ZFS arrays native in Proxmox, dus mocht je iets willen weten, vraag maar raak.

[ Voor 4% gewijzigd door FireDrunk op 16-10-2018 15:59 ]