Het grote ZFS topic

[secretdk]

Verwijderd schreef op dinsdag 15 december 2015 @ 00:38:
Dit kun je achteraf niet aanpassen nee. Heel erg is het niet want je hebt een optimale configuratie; RAID-Z1 met 5 disks. Dus dat betekent dat bij het schrijven van grote bestanden je aan de 128K blocksize zit en dat houdt in dat je 128 / (5 - 1) = 32KiB per disk doet en dat is een veelvoud van 4KiB. Kortom, lekker zo laten. Alleen voor kleinere I/O groottes zul je een performance hit ervaren, en dan alleen voor writes is dat significant.

Maar is het niet vreemd dat mijn storage2 pool precies dezelfde configuratie heeft en deze melding niet geeft? Enige verschil is de schijf grootte. Is er ook een manier om deze melding weg te krijgen?

[RudolfR]

Sinds kort heb ik problemen met het benaderen van mijn samba-shares vanuit Windows 7. Het lijkt te zijn ontstaan na de upgrade naar 0.3.1, voorheen werkte het wel op deze machine. Op een Windows10-client in het LAN heb ik het probleem niet.

Ik kan de shares wel zien en als ik ze probeer te openen dan moet ik mezelf aanmelden, maar dit lukt maar zelden. Meestal wordt de combinatie van gebruikersnaam en wachtwoord geweigerd. Ook werkt het niet als ik domein '.' of 'WORKGROUP' probeer.
Het wachtwoord heb ik al een aantal keer veranderd en voer ik niet verkeerd in, op de Windows10-client gaat het inloggen niet mis.

Logging van de sessie met de windows10-client

code:

[2015/12/15 21:41:39.757042,  2] smbd/sesssetup.c:1291(setup_new_vc_session)
  setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources.
[2015/12/15 21:41:39.760245,  2] auth/auth.c:309(check_ntlm_password)
  check_ntlm_password:  authentication for user [user1] -> [user1] -> [user1] succeeded
[2015/12/15 21:41:39.807029,  1] smbd/service.c:1114(make_connection_snum)
  hostname (192.168.1.X) connect to service media initially as user user1 (uid=1001, gid=1000) (pid 1451)

Logging van de Windows7-client

code:

[ssh@zfsguru /var/log/samba]$ tail -f log.192.168.1.X
[2015/12/15 21:51:42.340992,  2] auth/auth.c:319(check_ntlm_password)
  check_ntlm_password:  Authentication for user [share] -> [share] FAILED with error NT_STATUS_WRONG_PASSWORD
[2015/12/15 21:51:42.341443,  2] auth/auth.c:319(check_ntlm_password)
  check_ntlm_password:  Authentication for user [share] -> [share] FAILED with error NT_STATUS_WRONG_PASSWORD
[2015/12/15 21:51:42.341957,  2] auth/auth.c:319(check_ntlm_password)
  check_ntlm_password:  Authentication for user [share] -> [share] FAILED with error NT_STATUS_WRONG_PASSWORD
[2015/12/15 21:51:42.342007,  2] smbd/service.c:655(create_connection_session_info)
  Invalid username/password for [media]
[2015/12/15 21:51:42.342043,  1] smbd/service.c:805(make_connection_snum)
  create_connection_session_info failed: NT_STATUS_WRONG_PASSWORD

De W7-client lijkt verschillende credentials te proberen, die allemaal worden geweigerd.

Ook mijn Android filebrowser kan gewoon inloggen, ook shares zonder wachtwoord zijn geen probleem.

In Windows7 heb ik de kluis met credentials al geleegd (zoals hier: http://serverfault.com/qu...7-to-a-password-protected).
'net use' geeft geen resultaten terug.
Ook deze wijzigingen heb ik doorgevoerd in het lokale beveiligingsbeleid:
http://www.tannerwilliams...haring-fix-samba-smb/394/

Ook vreemd is dat het soms opeens wel werkt. Iemand tips?

[FireDrunk]

Post je smb.conf eens
Staat je windows 7 in een homegroup?

[RudolfR]

smb.conf: http://pastebin.com/dftBs91s

Windows 7 staat in een homegroup en deelt de daarop aangesloten printer, maar dat is niet nieuw.

[jacovn]

De zfsguru centrale servers lijken er beide niet te zijn, althans ik kan geen nieuwe versie downloaden. (2 dagen geleden ging het prima)

[Verwijderd]

Ben nu bezig met upgrade van Bravo. Duurt nog 10 minuten ofzo.
Edit - nu weer online.

[ Voor 17% gewijzigd door Verwijderd op 21-12-2015 08:52 ]

[jacovn]

dat was toevallig dan ..thx voor de mededeling..

update: gaat nu inderdaad weer goed.

[ Voor 29% gewijzigd door jacovn op 21-12-2015 09:01 ]

[Olivier]

Ik heb nu een tijdje FreeNAS draaien en laatst heb ik er een aantal schijven bijgestopt waardoor ik nu op 24x4TB zit. Nu zit ik nu een beetje te twijfelen hoeveel schijven ik per vdev wil gebruiken. Oorspronkelijk wilde ik 4x6 raidz2 doen, echter vind ik 8 schijven 'verliezen' erg veel voor de data die er op staat(media en backups, belangrijkste bestanden staan ook nog op 2 andere locaties opgeslagen). Op IRC stelde iemand 2x12 Raidz2 voor, dit is echter niet optimaal. Wat is jullie mening hierover? Elke input is welkom.

Tweede dingetje waar ik over zit te twijfelen is de hoeveelheid ram ik aan de FreeNAS vm moet geven, op dit moment heeft de vm 16GB, maar ik vermoed dat dit wat weinig is voor 24 schijven.

[FireDrunk]

Wil je perse 1 pool? Want je kan ook gewoon 2(of meer) pools maken die verschillende beveiligingslevels hebben.
Daarna kan je zelfs met de mountpoints spelen zodat het lijkt alsof het allemaal in 1 directory zit.

Edit:
De hoeveelheid geheugen staat (bijna) niet in relatie tot de hoeveelheid geheugen die je aan de VM geeft.
Wat handig is, is dat ZFS rustig een aantal transacties (TXG groups) in RAM kan zetten alvorens je RAM op is. Als jouw schijven alle 24 continu 100MB/s doen, dan moet je dus potentieel 15 * 2.4G (~37GB) aan RAM toekennen buiten je ARC om. Dat is natuurlijk kolder.

Waar je misschien goed aan doet, is je min en max pending lager te zetten dan default (15 in FreeBSD9, 5 in FreeBSD11 dacht ik).

Dit zorgt er voor dat je TXG's kleiner worden en korter leven, waardoor je RAM belasting iets lager is.

Daarnaast moet je bedenken hoeveel cache je wil (ARC). Als je alleen maar films en series op het ding zet, is ARC vrijwel nutteloos omdat je die dingen bijna nooit 2 keer snel achter elkaar inleest.
Dan kan je je ARC op bijvoorbeeld 8GB limiteren, en de VM 16GB geven. Dan heb je veel ruimte voor lopende TXG's en is je ARC van een prima format.

Bovenal telt: Meten is weten. Test het uit, en benchmark het systeem, dan kom je er snel genoeg achter wat de beste instelling is voor jou.

[ Voor 74% gewijzigd door FireDrunk op 21-12-2015 10:03 ]

[Q]

Olivier schreef op maandag 21 december 2015 @ 09:26:
Op IRC stelde iemand 2x12 Raidz2 voor, dit is echter niet optimaal. Wat is jullie mening hierover? Elke input is welkom.

Met de large blocks feature is een 'niet-optimale' pool niet zo'n issue meer. Je gooit niet langer terrabytes aan capaciteit weg.

Ik heb 24 disks en zou als ik het opnieuw kon doen 2 x 12 disk RAIDZ2 draaien in 1 pool.

[FireDrunk]

Je kan in dat geval misschien ook 3*8 overwegen. Ik zou persoonlijk meerdere pools maken, maar dat is mijn persoonlijke voorkeur.

[Paul]

Olivier schreef op maandag 21 december 2015 @ 09:26:
Op IRC stelde iemand 2x12 Raidz2 voor, dit is echter niet optimaal. Wat is jullie mening hierover? Elke input is welkom.

Met FireDrunk 2x 8+2 RAIDZ2 of als het echt zo "onbelangrijk" is zelfs 2x 8+1 RAIDZ, en de resterende schijven in mirror of RAIDZ2 voor het stukje data dat wel belangrijk is

"Optimaal" is tegenwoordig relatief, ik neem aan dat je compressie aan hebt staan? Zeker als ik zie dat het vooral media (lees: grote bestanden) is maakt het zelfs nog minder uit.

16 GB is voor zo'n 'streaming' NAS ruim voldoende, zelfs 4 of 8 GB lijkt me voldoende. 1 GB per TB is voor enterprise workloads, jouw verkeer is vooral sequential.

[Q]

Ik heb 7 jaar prima op een 20-disk RAID6 gedraaid, 16 GB RAM is meer dan zat voor een NAS thuis. Ik heb er ook 'maar' 16 in gestopt (24 disk 71 TB). Ik haal gigabytes per seconde.

[Psycho_Bartje]

Vraag:
Ik heb (door de tijd heen) wisselende ervaringen gelezen over het kunnen importeren van een bestaande ZFS-pool (specifiek: met FreeNAS aangemaakt) in ZFS-on-Linux.
Wie heeft er een recente positieve ervaring ? ik overweeg namelijk om mijn FreeNAS "over te zetten" naar Linux Mint 17.3, zodat ik een PC heb die ook voor andere taken kan gebruiken dan alleen datastorage (mediaverzameling).

Een OS wat me ook interessant lijkt, maar waarover ik binnen Tweakers weinig lees is PC-BSD, ga ik misschien ook eens proberen, ervaringen ?

[duiveltje666]

Psycho_Bartje schreef op maandag 21 december 2015 @ 16:16:
Vraag:
Ik heb (door de tijd heen) wisselende ervaringen gelezen over het kunnen importeren van een bestaande ZFS-pool (specifiek: met FreeNAS aangemaakt) in ZFS-on-Linux.
Wie heeft er een recente positieve ervaring ? ik overweeg namelijk om mijn FreeNAS "over te zetten" naar Linux Mint 17.3, zodat ik een PC heb die ook voor andere taken kan gebruiken dan alleen datastorage (mediaverzameling).

Een OS wat me ook interessant lijkt, maar waarover ik binnen Tweakers weinig lees is PC-BSD, ga ik misschien ook eens proberen, ervaringen ?

ik kan het je sterker vertellen : Mn huidige pool (Zfs on Linux op Proxmox) is begonnen als pool op FreeBSD/Zfsguru en die pool heeft ook nog in een Napp-it setup gezeten en kon probleemloos imported worden

[FireDrunk]

Hier ook regelmatig geswitched hoor. Werkt prima.

[Audio-Catalyst]

FireDrunk schreef op donderdag 12 november 2015 @ 21:02:
Leuke post! Mijn 840 Pro's zouden daarmee dus geschikt zijn voor SLOG en L2ARC. Ze honoreren bij Samsung blijkbaar ondanks de grote DRAM caches, goed de fsyncs.

840's als L2ARC werken prima, wel zorgen dat je 70% OP't
840's als SLOG werken uitermate slecht.
uiteindelijk intel 3700's in een mirror geplaats, en dat werkt dan wel weer helemaal top

wel moet ik hier bij aantekenen dat Mijn os OmniOS is (Solaris), en dat heeft wat hardere eisen aan je hardware.

Valt me trouwens dat de meeste hier kiezen voor FreeNAS, NAS4free of een andere BSD variant.
Waarom niet eens spelen met een Native Solaris variant, mocht je een Webgui willen gebruiken, dan kun je NAPP-IT gebruiken

http://omnios.omniti.com/
http://omnios.omniti.com/

[Audio-Catalyst]

Bigs schreef op dinsdag 08 december 2015 @ 13:05:
[...]


Wat is je use case? Ik vind het zo jammer dat je met ZFS altijd een single point of failure hebt omdat je maar één host voor je storage hebt staan. Oracle verkoopt HA ZFS oplossingen met twee controllers (passief/actief) die allebei verbonden zijn aan een of meer JBODs maar ik zie in de OpenZFS wereld hier weinig concrete voorbeelden van die ik echt in productie zou durven gebruiken (vaak is het iets van pacemaker/corosync met een fragiel import/export proces en een virtueel IP voor NFSv3 waarvan onduidelijk het is hoe bv VMware hierop reageert).

http://www.high-availability.com/zfs-ha-plugin/

word door eigenlijk alle leveranciers van de solaris varianten gebruikt ( Dell, Nexenta, Omnios)

[Evianon]

Ik heb een klein vraagje:

Momenteel heb ik een paar ZFS servers voor backups op FreeBSD. Alles draait verder op Debian en Ubuntu, alleen deze backup servers nog niet, die stammen nog uit de tijd dat ZFS hem niet ging worden op Linux. Inmiddels wil ik toch eens wisselen naar Ubuntu.

Alles heeft een aparte OS disk, en ik wil dus wat nieuwe OS schijven maken met ZFS op Ubuntu, naar het datacenter rijden, de disks even wisselen en de complete pools importeren op Ubuntu. Ik vraag me echter af of een FreeBSD pool importeren op Ubuntu zomaar kan en gaat werken. Ik heb dit topic (en Google) al behoorlijk doorgespit, maar weinig over te vinden.

Ik zal op z'n minst dezelfde feature-flags moeten hebben neem ik aan? De servers bevatten een paar duizend snapshots, maar dat lijkt me niet zoveel moeten uitmaken?

[martijndierckx]

Guys

Een probleem waarvan ik hoop dat jullie me erbij kunnen helpen:
Telkens wanneer ik mijn zelfbouw NAS VM boot, dan wordt mijn ZFS pool ge-automount. Echter telkens op basis device naam (sdb, sdd, sde ...) en niet by-partlabel, waardoor hij telkens dezelfde HDD niet kan vinden.
Als ik dan mijn pool export en opnieuw import (zpool import -d /dev/disk/by-partlabel/), dan werkt het weer ... totdat ik een reboot uitvoer. Dan begint de volledige cyclus opnieuw.

Ook al geprobeerd:

• Cache file deleten -> rebooten -> import (zpool import -d /dev/disk/by-partlabel/) -> reboot = zelfde probleem

Bedankt!

---

zpool status (na boot)

  pool: dataTank
 state: ONLINE
status: One or more devices could not be used because the label is missing or
	invalid.  Sufficient replicas exist for the pool to continue
	functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-4J
  scan: resilvered 36K in 0h0m with 0 errors on Sun Dec 20 20:22:43 2015
config:

	NAME                      STATE     READ WRITE CKSUM
	dataTank                  ONLINE       0     0     0
	  raidz2-0                ONLINE       0     0     0
	    15065218163434541547  UNAVAIL      0     0     0  was /dev/sdc
	    sdb                   ONLINE       0     0     0
	    sdd                   ONLINE       0     0     0
	    sde                   ONLINE       0     0     0
	    sdf                   ONLINE       0     0     0
	    sdg                   ONLINE       0     0     0

errors: No known data errors

zpool status (na export en import)

root@nas:/home/nas# zpool status
  pool: dataTank
 state: ONLINE
  scan: resilvered 364K in 0h0m with 0 errors on Sun Dec 20 20:33:43 2015
config:

	NAME         STATE     READ WRITE CKSUM
	dataTank     ONLINE       0     0     0
	  raidz2-0   ONLINE       0     0     0
	    HD4TB-5  ONLINE       0     0     0
	    HD4TB-0  ONLINE       0     0     0
	    HD4TB-1  ONLINE       0     0     0
	    HD4TB-2  ONLINE       0     0     0
	    HD4TB-3  ONLINE       0     0     0
	    HD4TB-4  ONLINE       0     0     0

errors: No known data errors

/etc/zfs.zpool.cache

vdev_childrenrsio?$(name       dataTank$ stat  tx? ?((	pool_guiÐ՚tmE$ errat$ hosti$hostname	nas,(
,8	vdev_tree  type	root  i  guiÐ՚tmE	?children$ type	raidz  i  gui??R??$ nparit,(metaslab_arra!,(metaslab_shif%$ ashift
                                                                                                                                 $ asiz??$ is_lo((
create_tx?children  type	disk  i  gui?h?GQ?<8path	/dev/disk/by-partlabel/HD4TB-548	phys_path	/dev/gpt/HD4TB-5((
whole_dis  DT%((
create_tx  type	disk  i  gui?LL@z?<8path	/dev/disk/by-partlabel/HD4TB-048	phys_path	/dev/gpt/HD4TB-0((
whole_dis  DT,((
create_tx  type	disk  i  guig%??8"?A<8path	/dev/disk/by-partlabel/HD4TB-148	phys_path	/dev/gpt/HD4TB-1((
whole_dis  DT*((
create_tx  type	disk  i  guim??%X
                                 8path	/dev/disk/by-partlabel/HD4TB-248	phys_path	/dev/gpt/HD4TB-2((
whole_dis  DT)((
create_tx  type	disk  i  guiJEV&#607;a??<8path	/dev/disk/by-partlabel/HD4TB-348	phys_path	/dev/gpt/HD4TB-3((
whole_dis  DT(((
create_tx  type	disk  i  gui?K??m?0<8path	/dev/disk/by-partlabel/HD4TB-448	phys_path	/dev/gpt/HD4TB-4((
whole_dis  DT'((

df -h

/dev/sda1          4,2G     2,0G  2,0G  50% /
none               4,0K        0  4,0K   0% /sys/fs/cgroup
udev                12G     4,0K   12G   1% /dev
tmpfs              2,4G     4,6M  2,4G   1% /run
none               5,0M        0  5,0M   0% /run/lock
none                12G        0   12G   0% /run/shm
none               100M        0  100M   0% /run/user
/dev/sda6           11G      28M   11G   1% /home
dataTank           581G     384K  581G   1% /mnt/dataTank

partities

Disk /dev/sdc: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 92645488-1CDA-11E4-A73F-000C297256E3

Device     Start        End    Sectors  Size Type
/dev/sdc1   2048 7814037127 7814035080  3,7T FreeBSD ZFS


Disk /dev/sdb: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: EE99C26F-89C3-11E3-A4A6-001871EB3324

Device     Start        End    Sectors  Size Type
/dev/sdb1   2048 7814035455 7814033408  3,7T FreeBSD ZFS


Disk /dev/sdd: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F1576545-89C3-11E3-A4A6-001871EB3324

Device     Start        End    Sectors  Size Type
/dev/sdd1   2048 7814035455 7814033408  3,7T FreeBSD ZFS


Disk /dev/sde: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F2E1C3F4-89C3-11E3-A4A6-001871EB3324

Device     Start        End    Sectors  Size Type
/dev/sde1   2048 7814035455 7814033408  3,7T FreeBSD ZFS


Disk /dev/sdf: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F44C0C11-89C3-11E3-A4A6-001871EB3324

Device     Start        End    Sectors  Size Type
/dev/sdf1   2048 7814035455 7814033408  3,7T FreeBSD ZFS


Disk /dev/sdg: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F5C1BC99-89C3-11E3-A4A6-001871EB3324

Device     Start        End    Sectors  Size Type
/dev/sdg1   2048 7814035455 7814033408  3,7T FreeBSD ZFS

environment

HW: ML330 G6
OS: ESXi 6.0 u1 (custom HP build)
VM OS: Ubuntu 14.10 (niet meer geüpdatet sinds initiële install)
Services: ZFS, SMBD
IBM ServeRAID M1015 (LSI firmware) met 6 disks via DirectPath I/O rechtstreeks aan VM gekoppeld

[ Voor 23% gewijzigd door martijndierckx op 24-12-2015 15:42 ]

[Verwijderd]

Voortaan GPT partities met GPT labels gebruiken, en niet volledige disks dat is vies!

Bedenk ook dat als je je disks even op Windows aansluit, dat Windows zal vragen de disks te 'initialiseren'. Dit klinkt heel onschuldig maar als je daarmee instemt ben je je pool kwijt want de disks worden in feite geformatteerd met een nieuw partitieschema. En dan kun je je pool niet meer importeren omdat belangrijke data mist. Eén van de vele redenen waarom ruwe disks gebruiken een heel slecht idee is.

[begintmeta]

Is een zfs-array niet bestand tegen klein verlies ter grootte van de data die initialisatioe van een pt(+fs evt) zou overschrijven?

[Verwijderd]

Durf ik eigenlijk niet te zeggen. Wat random sectors kwijt is denk ik niet erg; want alle metadata is redundant. Maar het verlies van 40.000+ sectoren aan het begin kan misschien teveel van het goede zijn. En ook het einde van de capaciteit wordt opnieuw geïnitialiseerd volgens mij. In elk geval bij GPT.

[HyperBart]

Verwijderd schreef op donderdag 24 december 2015 @ 12:13:
Voortaan GPT partities met GPT labels gebruiken, en niet volledige disks dat is vies!

Bedenk ook dat als je je disks even op Windows aansluit, dat Windows zal vragen de disks te 'initialiseren'. Dit klinkt heel onschuldig maar als je daarmee instemt ben je je pool kwijt want de disks worden in feite geformatteerd met een nieuw partitieschema. En dan kun je je pool niet meer importeren omdat belangrijke data mist. Eén van de vele redenen waarom ruwe disks gebruiken een heel slecht idee is.

Dat is net het rare, als hij de pool kan importeren met by-partlabel, waarom doet ie het dan na een reboot terug op basis van /dev/sd a b c d e?

[Verwijderd]

Goeie vraag. Sowieso heeft Linux niet zo'n goede disk infrastructuur als BSD heeft met GEOM. Dat laatste werkt veel beter - alle storage devices zijn modules die in één framework zijn geïntegreerd. Een partitie is ook gewoon een GEOM module. Bij andere operating systems is dat niet zo. Dan krijg je ook grote verschillen tussen de ZFS implementaties.

Als je een GPT partitie hebt, zou dat ook moeten betekenen dat je ZFS disk op een heel andere offset begint. Dus dat hij dan als ruwe 'sdb' disk wordt herkend, vind ik wel gek. Wat ik wel weet, is dat je een GPT partitie kunt hebben en dan toch de ruwe device node gebruiken voor ZFS. Dan wordt de GPT device node onzichtbaar zodra je ZFS de disk laat gebruiken, en pas bij een export komt je partitie weer naar voren.

[FireDrunk]

Volgens mij zit er ergens een mismatch tussen /dev/sda en /dev/disk/by-partlabel.
Die dingen zijn namelijk niet hetzelfde.

Het feit dat je /dev/disk/by-partlabel *hebt* betekend dat je gepartitioneerd hebt, maar /dev/sda zegt dat je juist *geen* partitie hebt.

@CiPHER, dat verhaal met die Linux disk infrastructuur is nog steeds een beetje bullshit. Die infrastructuur is er best, alleen is er nog legacy ondersteuning aanwezig. Dat is precies wat je hier ziet.

Wat wel klopt is dat het raar is dat ZFS je /dev/sd* als geldige ZFS onderdelen ziet.

De kernvraag is:

Heb je nu wel of niet paritites gemaakt op je disks voordat je ze aan ZFS gegeven hebt?

[Verwijderd]

Feit dat er by-partlabel bestaat zou suggereren dat er partities zijn. Relevantere vraag is mogelijk of dat ZFS is aangemaakt met de partlabels of de ruwe disks.

Overigens heb je naast partitielabels ook disklabels. Die disklabels wijzen wel naar de volledige disk.

En Linux heeft toch niets qua equivalent van GEOM? Dus wat is er dan bullshit? Laten we daar maar een keer in een apart topic over spreken want het komt elke keer terug. Volgens mij praten we gewoon langs elkaar heen.

Edit: haha, juist dat schuingedrukte heb ik niet gelezen...

[ Voor 6% gewijzigd door Verwijderd op 24-12-2015 14:38 ]

[FireDrunk]

Er is vanalles, Disk ID, Disk UUID, Part UUID (vanuit Grub / UDEV), partlabel (grub, grub2, UEFI, UDEV).

Maar jouw "relevantere" vraag is *exact* wat ik scheefgedrukt zei?

[martijndierckx]

Volgens mij heb ik dat in der tijd wel gedaan (is intussen al een hele poos geleden).
Hoe check ik dat voor jullie even?

[FireDrunk]

List je partities eens op alle disks

(fdisk -l <dev> ofzo?)

[martijndierckx]

Heb in de originele post de partities opgelijst.
Wel vreemd dat ie zegt "was /dev/sdc", maar dat ik dus perfect voor /dev/sdc de partities kan uitlezen

[FireDrunk]

Ah, je hebt dus keurig partities. Heb je ooit zelf aan je udev regels gezeten? En heb je zelf iets van chkconfig zfs-mount on gedaan?

[Q]

Het kern probleem is dat /dev/sd* is gebruikt bij het aanmaken van de pool, ondanks dat dit expliciet wordt afgeraden door ZoL.

Ik denk dat de beste oplossing is om disk voor disk uit de pool te halen, en dan te 'vervangen' door de /dev/disk/by-id equivalent, meestal zo'n wwn-* nummer.

code:

...
raidz2-0                        ONLINE       0     0     0
        wwn-0x5000cca22bef486a  ONLINE       0     0     0
        wwn-0x5000cca22bf0f4c3  ONLINE       0     0     0
        wwn-0x5000cca23dc01655  ONLINE       0     0     0
...

Zorg voor backups

[ Voor 31% gewijzigd door Q op 24-12-2015 21:28 ]

[FireDrunk]

Hij liet juist zien dat hij wel partities gebruikt heeft.

Replacen is een optie inderdaad, maar ik verwacht dat het ergens in het os zit. Misschien wordt de zfs module eerder geladen dan de udev rules bijvoorbeeld.

Ik wil best even remote helpen

[jjust]

Ik zit te klooien met send receive tussen twee zfsguru systemen over ssh. Het probleem is dat ik niet voor elkaar krijg dat ssh root wordt. Althans ik weet niet hoe ik "su" kan toevoegen aan onderstaande code. Nu heeft user ssh geen permissie.

code:

 zfs send Storage/test@2015-12-24 | ssh ssh@192.168.1.201 "zfs recv -F temp_data/test"

Het alternatief is -als ik het goed heb begrepen- dat ik ssh user root maak. Eerst dit proberen.

[Dutch2007]

Of je past the ssh config bestand aan, en staat ssh login met root toe😉

[Q]

Normaal doe je dat toch met sudo?

[FireDrunk]

Volgens mij kan je schrijven:

sudo:ssh@systeem <commando>
Of

ssh user@systeem sudo <commando>

[Verwijderd]

zfs allow ssh receive,create,mount <poolnaam>

[jjust]

Q schreef op vrijdag 25 december 2015 @ 00:16:
Normaal doe je dat toch met sudo?

FireDrunk schreef op vrijdag 25 december 2015 @ 09:11:
Volgens mij kan je schrijven:

sudo:ssh@systeem <commando>
Of

ssh user@systeem sudo <commando>

Bedankt voor de tips. Als ik sudo gebruik krijg ik de volgende melding;

code:

sudo: no tty present and no askpass program specified

Daar moet ik nog eens induiken maar omdat ik nu niet veel tijd heb eerst de tip van CiPHER geprobeerd;

Verwijderd schreef op vrijdag 25 december 2015 @ 10:10:

zfs allow ssh receive,create,mount <poolnaam>

Als ik hierna het eerdere commando geef krijg ik de volgende melding;

code:

cannot mount '/temp_data/test': failed to create mountpoint

Het snapshot is wel overgezet. Het gaat de goede kant op.

Nu naar de kerstverplichtingen vanavond verder.

[Verwijderd]

Laat je exacte commando en de output eens zien; heb je het commando wel juist uitgevoerd?

[FireDrunk]

Die requiretty is een sudo optie, er is een -T optie bij het ssh commando dacht ik om een pseudo tty te gebruiken.

[Kortfragje]

Het /dev/sda verhaal liep ik ook tegenaan. Heel vervelend, zie ook hier. https://github.com/zfsonlinux/pkg-zfs/issues/130

[rows]

Ik heb inmiddels al het e.e.a. gelezen aangaande ZFS en ben inmiddels al bijna zover dat ik ipv het vervangen van mijn oude synology (DS209+II) zelf een NAS wil gaan bouwen op basis van FreeNAS. Nu heb ik nu al 1 belangrijke vraag waar ik zo snel niet het antwoord op kan vinden, althans een duidelijk antwoord en dat heeft te maken met hardware failure. Wat als ik een ZFS pool heb draaien en mijn hardware gaat stuk? Is dat dan net als bij Synology een nieuwe kopen, disken erin en verder draaien maar?

Of moet ik mij met deze vraag melden bij Het grote DIY RAID NAS deel 3 topic

[ Voor 7% gewijzigd door rows op 25-12-2015 15:32 ]

[FireDrunk]

Ja hoor, je kan een ZFS pool gewoon importeren op nieuw systeem. Als je geen aparte features aan zet, kan je je pool zelfs onder een ander besturingssysteem importeren. (ZFSonLinux <-> ZFSguru <-> FreeNAS <-> Illumos <-> Nexenta)

Alleen even opletten met de features die je aan zet bij creatie van de pool

[jjust]

Verwijderd schreef op vrijdag 25 december 2015 @ 12:23:
Laat je exacte commando en de output eens zien; heb je het commando wel juist uitgevoerd?

Wat heb ik gedaan;

Eerst op de ontvangende server;

code:

zfs allow ssh receive,create,mount temp_data

Als ik dan op deze server naar de rechten op de pool kijk via

code:

zfs allow temp_data

Lijken de rechten goed te staan. Zie onderstaande print uit putty (klik voor groot)



Dan inloggen op de versturende server met user ssh.
Dan

code:

su

Het te versturen snapshot heb ik via de website gemaakt.
Vervolgens de volgende code gebruikt;

code:

zfs send Storage/test@2015-12-24 | ssh ssh@192.168.1.201 zfs recv -F temp_data/test

Via een prompt wordt gevraagd om het wachtwoord van de ontvangende server. Deze heb ik ingegeven.
Ik krijg dan de volgende melding;

code:

failed to create mountpoint

Zie onderstaande print uit putty (klik voor groot)



Het snapshot is wel overgezet. Nu eerst weer kerstverplichtingen dan verder.

[_-= Erikje =-_]

user ssh is geen root

[CurlyMo]

Is je doel een readonly FS?

[Guru Evi]

@jjust: Als je via SSH als ssh inlogt, kun je dan wel zfs create volume/dataset doen? Ik neem aan dat je een *BSD systeem gebruikt:


Van de man page:

zfs allow someuser create mydataset gives the specified user permission to create child datasets under the selected parent dataset. There is a caveat: creating a new dataset involves mounting it. That requires setting the FreeBSD vfs.usermount sysctl( to 1 to allow non-root users to mount a file system. There is another restriction aimed at preventing abuse: non-root users must own the mountpoint where the file system is to be mounted.

Dus alhoewel je waarschijnlijk wel de toelatingen toevoegt op het ZFS systeem, moet het OS ook nog de toelatingen doen. Als je ZFS Linux-gebaseerd is kan het ook zijn dat SELinux je user niet toelaat een mount te maken/laden.

[jjust]

Ben er nog niet helemaal uit. Het licht waarschijnlijk aan mijn beperkte kennis van FreeBSD. Je zou denken dat meer mensen snapshots tussen twee hosts versturen maar ik krijg het nog niet werkend. Heb ook voorbeelden in dit topic gezocht maar de meeste geven ssh root rechten of loggen met root in via SSH. Misschien toch maar gewoon root inloggen via ssh mogelijk maken maar dit lijkt me niet best practice.

Wat heb ik gedaan met jullie tips;

FireDrunk schreef op vrijdag 25 december 2015 @ 12:27:
Die requiretty is een sudo optie, er is een -T optie bij het ssh commando dacht ik om een pseudo tty te gebruiken.

Dit heb ik geprobeerd maar blijf die melding houden. Heb ook -t en -t -t geprobeerd. Deze opties was ik ook als mogelijke oplossing tegengekomen maar ook daar krijg ik foutmeldingen bij.
Bij -T en bij -t is de melding;

code:

no tty present  and no askpass program specified

Bij -t -t is de melding;

code:

Connection to 192.168.1.201 closed

_-= Erikje =-_ schreef op zaterdag 26 december 2015 @ 17:30:
user ssh is geen root

Dat was ook -vooralsnog- de bedoeling. Ik had met onderstaande code user ssh rechten gegeven om o.a. te mounten. Zie een eerdere post.

code:

zfs allow ssh receive,create,mount temp_data

CurlyMo schreef op zaterdag 26 december 2015 @ 18:36:
Is je doel een readonly FS?

Nee als ik direct op de host inlog kan ik wel filesystemen toevoegen en mounten (met een root user). Ook via de website. Zie output verderop in de post. Hoe zou ik dit verder kunnen controleren?

Guru Evi schreef op zaterdag 26 december 2015 @ 22:51:
@jjust: Als je via SSH als ssh inlogt, kun je dan wel zfs create volume/dataset doen? Ik neem aan dat je een *BSD systeem gebruikt:


Van de man page:

[...]


Dus alhoewel je waarschijnlijk wel de toelatingen toevoegt op het ZFS systeem, moet het OS ook nog de toelatingen doen. Als je ZFS Linux-gebaseerd is kan het ook zijn dat SELinux je user niet toelaat een mount te maken/laden.

Het gaat om ZFSGURU /FreeBSD 10.2-stable.
Ik denk dat je gelijk heb. Als ik direct op de host inlog kan ik met user SSH wel createn maar niet mounten. Na het su commando kan dit wel. Hieruit leid ik ook af dat het FS niet alleen read-only is. Zie onderstaande putty output.

Lijkt er dus inderdaad op dat ik dat ook nog de FreeBSD setting moet aanpassen. Als ik het goed begrijp werkt het dan ook nog alleen als ssh eigenaar is van het mountpoint. Dit lijkt mij ook een flinke beperking.

Vraag me toch af wat nu best practice is.

[FireDrunk]

Grote kans dat de directory die je wil mounten nog aangemaakt moet worden door je OS (in het kader van het mountpoint). Dit mag je gewone user niet.

Normaal zou je dit oplossen door in /etc/fstab een entry te maken en daar het user argument aan toevoegen. (Bron: https://wiki.archlinux.or...g_to_FAT32_as_Normal_User)

Wat je kan proberen is de ssh user meer rechten geven op het onderliggende filesystem (of de root, als het een top level filesystem is.)

Dus iets als /tank/a, en je wil /tank/b aanmaken onder user ssh, dan moet je user ssh ook rechten geven op de directory /tank. Als je dat niet wil (omdat je de ssh user geen rechten wil geven aan a, kan je een "tussen" filesystem maken.

/tank/snapshots/* en je geeft de SSH user alle rechten op /tank/snapshots.

(tenminste, dat denk ik, ik kan het wel proberen, maar dan moet ik even een FreeBSD VM maken )

De best practice is gewoon SUDO gebruiken denk ik... dat is veel makkelijker.

[ Voor 15% gewijzigd door FireDrunk op 28-12-2015 08:20 ]

[CurlyMo]

Of gewoon een root login via een ssh-key. Dat is wat volgende mij de meeste mensen die ssh root gebruiken doen. Daar zit een verwaarloosbaar risico aan. Zolang je root maar niet toestaat in te loggen met een wachtwoord.

[FireDrunk]

Maar dan is de andere kant wel meteen root, ook met key... Dat is misschien niet wenselijk. Dan kan je misschien beter een gewone user icm Sudo doen.

[jantje112]

Ik wil mijn freenas pool overzetten naar een andere server waar de controller in passtrough staat. Het is een kleine pool (4*3).

Iemand goede tips hoe dit makkelijk te doen is?

[_-= Erikje =-_]

zfs export, schijven overknopen, zfs import toch?

[jantje112]

_-= Erikje =-_ schreef op maandag 28 december 2015 @ 10:59:
zfs export, schijven overknopen, zfs import toch?

Zou het zo makkelijk zijn? Geen problemen met invoeren van serienummers, aansluitvolgorde etc?

[_-= Erikje =-_]

in theorie als je je pool op UID aangemaakt hebt niet dacht ik... maar zeker weten doe ik het niet

[Q]

Je kunt een proef draaien met een of twee USB schijven.
Maak een pool op basis van deze disks conform wat Erikje schrijft
Export de pool, haal de disks los.
Koppel de disks aan je VM via usb passthrough
Import en zie of dat goed gaat.

[Adr01]

Top topic, heel duidelijk. Ik kon mezelf niet verkopen dat een niet mirror (RAID0) oplossing een vorm van redundantie kon hebben, ik ben verkocht.

Ik heb een SSD over, een 840 Pro (128GB) of Evo (120GB). (Één hiervan plan ik te gebruiken voor een Hackintosh project.)
Wat mij nog niet helemaal is doorgedrongen is waar ik het beste een SSD kan inzetten binnen de ZFS pool die ik ga maken. (3x 4TB voor 8TB opslag)

Zonder het topic-alert te willen schenden, wil ik kortom dus kortom vragen, welke setup voor een SSD het beste redundantie en performance zou kunnen combineren met ZFS RAID-Z.

[Dutch2007]

Zlog? Of als l2arc (als je iets met nfs share of iscsi doet)

[idef1x]

Oefff deze zfs noob kreeg even leermomentje om zijn oren vandaag: Was even wat snapshots aan het opschonen (alles behalve de laatste)...gaat mijn zfs send /receive script naar mijn backup server proberen een incremental tussen de laatste en dus laatste snapshot over te sturen. Gevolg: wel melding maken dat ie dat niet snapt, maar wel ondertussen op de receiver side de boel verwijderen

Afijn niet meer doen dus en maar weer mijn netwerk snelheid vol belasten door opnieuw de volledige snapshot over te zetten

Wellicht dat het nog wel terug te halen was, want het pool gebruik gaf nog steeds een 5TB aan, maar aangezien de fragmentatie ook al op de 45% stond (is dat hoog voor zfs eigenlijk?), gelijk maar even kijken of met een verse toestand dit ook lager/weg is. Schijnt DE truuk te zijn om zfs te defragmenteren (of de ene dataset naar de andere kopieren en dan weer renamen ofzo)...

[FireDrunk]

45% is wel vervelend hoog. Het is niet extreem, maar zeker wel merkbaar in performance.

Zoals je zelf al zegt, complete zfs send en receive van een filesystem helpt vaak.

[idef1x]

Hmmm helaas na de complete nieuwe send/receive nu 47% fragmentatie? Nou moe! Daar gaat die truuk
Enig idee hoe/of je kunt zien om welke dataset/bestanden het gaat? Wellicht dat daar nog wat mee te rommelen valt..

[FireDrunk]

Nee, fragmentatie zit op Pool niveau, dwars door alle datasets heen.

Heb je toevallig nog (oudere) snapshots op de desbetreffende datasets? want dan kan je send en receiven wat je wil, maar wordt er niks vrijgegeven.

[idef1x]

Nee die had ik juist net opgeschoond
Ik had dus ten tijde van de volledige send/receive slechts 1 snapshot. Inmiddels staat er wel weer 1 bij, want dat doe ik automatisch eens per dag (is vooralsnog voldoende voor mijn redelijk statische NAS)

Maar goed raar dus dat ie zo fragmented is al...op zich niet zo'n ramp daar het mijn backup machine is, dus heeft niet veel performance nodig, maar de main NAS is ook al 28% fragmented (na die opschoon actie dus)..

[cinquento]

even een noobish vraagje:

Ik heb nu twee hdd, dus als ik gebruik wil maken van ZFS moet ik deze stripen of mirroren.

Stel dat ik ze nu mirror en ik schaf later extra hdd's aan, kan ik de configuratie dan veranderen van mirror naar een of andere vorm van RAIDZ terwijl ik al mijn data gewoon laat staan?

thanks!

[dcm360]

Nee, dat kan niet.

[FireDrunk]

Jawel hoor, van mirror naar raidz met drie disken kan wel. Mirror breken, van de nieuwe en losse disk een nieuwe array maken (met een missende derde disk), data kopieren, laatste disk toevoegen aan nieuwe array en laten resilveren.

[CurlyMo]

Zelfde truc kan overigens ook van RAIDZ naar RAIDZ2

[FireDrunk]

1 disk er uit, 1 erbij kopen, van twee disks een raidz2 met 2 missende disks maken, data overzetten, oude disks toevoegen en resilveren.

OK, maar... Wil je dan niet liever 2 mirrors?

[Verwijderd]

RAID-Z2 is beter dan een mirror van 4 disks of twee pools van elk één mirror vdev. Dus met 4 disks zeker een RAID-Z2 maken tenzij je random read IOps wilt. Dat is wel veel beter met een mirror.

[FireDrunk]

De betrouwbaarheid van Z2 is wel iets beter, maar de performance van een set mirrors is zoveel hoger...
Bovendien ben je vrij in uitbreiden met mirrors... RAID0 van 3 mirrors bijvoorbeeld...

[Verwijderd]

Ja maar dat wil je niet als je redundancy wilt. Na het verliezen van één disk is je data alweer kwetsbaar voor bad sectors en andere corruptie, en twee disks en mogelijk is je hele pool plat. RAID-Z2 is veel beter omdat het twee verloren disks gegarandeerd kan opvangen.

Meerdere mirrors is leuk voor een database op een SSD mirror ofzo. Maar voor massaopslag zie ik dat niet als een gewenste configuratie.

[jjust]

Even nog terugkoppeling. Het is gelukt om snapshots tussen twee host te versturen met send | receive door gebruik te maken van sudo.

Ik probeerde de volgende code;

code:

zfs send Storage/test@2015-12-24 | ssh -T ssh@192.168.1.201 sudo zfs recv -F temp_data/test

Ondanks de -T parameter kreeg ik als melding;

code:

no tty present and no askpass program specified

Ik bedacht me dat er twee keer om het wachtwoord van de ssh user werd gevraagd. (1) bij het inloggen van ssh en (2) bij het sudo commando. Vermoedelijk verwerkt de parameter -T wel het eerste verzoek om input van het wachtwoord maar niet het tweede waardoor ik alsnog die melding kreeg.

Om het tweede verzoek voor een wachtwoord van ssh te voorkomen heb ik de sudoers file aangepast. Hier heb ik toegevoegd;

code:

ssh ALL=(ALL) NOPASSWD: ALL

Nu werkt het commando prima.

[CurlyMo]

Als dat je sudoers is kan je net zo goed direct met root inloggen.

[Dadona]

Het is natuurlijk niet volledig gelijk. PermitRootLogin = no en je hebt toch nog een verschil.

[CurlyMo]

Ik bedoel het dus in het licht van mijn eerdere opmerking dat je ook met root kan inloggen met een key.

[Bigs]

jjust schreef op woensdag 30 december 2015 @ 22:26:
[..]

Om het tweede verzoek voor een wachtwoord van ssh te voorkomen heb ik de sudoers file aangepast. Hier heb ik toegevoegd;

code:

ssh ALL=(ALL) NOPASSWD: ALL

Nu werkt het commando prima.

Ik zou het wat anders doen:

code:

ssh ALL=(root) NOPASSWD: /usr/bin/zfs recv

Op die manier zijn de rechten van de ssh user wat beperkt.

[jjust]

CurlyMo schreef op donderdag 31 december 2015 @ 00:08:
Ik bedoel het dus in het licht van mijn eerdere opmerking dat je ook met root kan inloggen met een key.

Ik moet me nog verdiepen in hoe de keys werken. Zoals je waarschijnlijk wel door had ben ik nog niet zo lang bezig met bsd/zfs/linux. Maar dat zal ik nog eens doen.

Bigs schreef op donderdag 31 december 2015 @ 08:38:
[...]


Ik zou het wat anders doen:

code:

ssh ALL=(root) NOPASSWD: /usr/bin/zfs recv

Op die manier zijn de rechten van de ssh user wat beperkt.

Ik was daar gisteren ook al mee bezig geweest maar kreeg dat niet werkend. Als ik jou code gebruik krijg ik weer die melding no tty etc.... Na wat google werk ben ik nu tot de volgende code gekomen voor de sudoers file;

code:

ssh ALL=(root) NOPASSWD: /sbin/zfs

Nu werkt send | receive prima.

[FireDrunk]

https://www.shell-tips.co...t-have-a-tty-to-run-sudo/

Je moet gewoon even requiretty uit zetten.
Overigens zei je -T, dat moest -t zijn (zie bron).

[jjust]

Ze werken allebei.

Bij -t krijg ik een melding;

code:

Pseudo-terminal will not be allocated because stdin is not a terminal.

Verder werkt het na de aanpassing in sudoers file wel.


Na wat googlen kwam ik op -T die werkt zonder foutmelding.

Ik begrijp niet goed wat de 'pseudo terminal' is. In onderstaande handleiding staat een toelichting maar dat zegt mij vrij weinig. Maar goed het werkt.


http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/ssh.1?query=ssh&sec=1

-t = Force pseudo-terminal allocation.
-T= Disable pseudo-terminal allocation

[Bigs]

Die psuedoterminal is niet van belang dus je kunt gewoon -T gebruiken. Je moet inderdaad wel requiretty uitzetten in je sudoers file.

[Compizfox]

Ik had laatst op Reddit een discussie over bitrot en self-healing data. Ik was altijd in de veronderstelling dat ZFS door combinatie van volume manager en bestandssysteem dingen kan doen die legacy RAID niet kan, zoals automatisch opsporen en repareren van corruptie.

Echter, volgens degene met wie ik in discussie was, kan legacy RAID dit ook doordat HDDs ook ECC hebben over elke sector, en doorgeven aan de RAID-controller als een sector corrupt is.



In hoeverre is dit nou waar?

[FireDrunk]

Ik moet de eerste RAID implementatie die bad sectors via SMART uitleest nog zien.
Wat hij zegt is leuk, maar volgens mij niet correct. Er zit helemaal geen foutafhandeling in de sata en sas protocollen die verteld wat er precies aan de hand is. Bovendien zit je os er ook nog tussen. Je krijgt gewoon IO timeouts...

En ik zie geen enkele RAID engine anders dan ZFS en BTRFS, een sector herschrijven met data van een andere sector als er een bad sector gevonden is.

[jbhc]

Compizfox schreef op maandag 04 januari 2016 @ 20:28:
Ik had laatst op Reddit een discussie over bitrot en self-healing data. Ik was altijd in de veronderstelling dat ZFS door combinatie van volume manager en bestandssysteem dingen kan doen die legacy RAID niet kan, zoals automatisch opsporen en repareren van corruptie.

Echter, volgens degene met wie ik in discussie was, kan legacy RAID dit ook doordat HDDs ook ECC hebben over elke sector, en doorgeven aan de RAID-controller als een sector corrupt is.

[afbeelding]

In hoeverre is dit nou waar?

Ik zou aan Y0tsuja even om een bronvermelding vragen.

[FireDrunk]

Ok, even opgezocht. Mdadm doet wel een write terug na een block mismatch. Hoe ze weten welke van de twee schijven in een raid1 array de juiste data bevat zonder checksum validatie, weet ik nog niet...

[Compizfox]

FireDrunk schreef op maandag 04 januari 2016 @ 21:06:
Ik moet de eerste RAID implementatie die bad sectors via SMART uitleest nog zien.

Het gaat ook niet om bad sectors, en het heeft zover ik het snap niets met SMART te maken. Maar er wordt dus beweerd dat een HDD het aan een RAID-controller kan doorgeven als de ECC over een bepaalde sector niet klopt.

Wat hij zegt is leuk, maar volgens mij niet correct. Er zit helemaal geen foutafhandeling in de sata en sas protocollen die verteld wat er precies aan de hand is. Bovendien zit je os er ook nog tussen. Je krijgt gewoon IO timeouts...

Waar zit een OS tussen? Tussen een RAID-controller en een HDD zit geen OS hoor

---

FireDrunk schreef op maandag 04 januari 2016 @ 21:50:
Ok, even opgezocht. Mdadm doet wel een write terug na een block mismatch. Hoe ze weten welke van de twee schijven in een raid1 array de juiste data bevat zonder checksum validatie, weet ik nog niet...

Het idee is dat een HDD ECC doet over z'n sectoren, en dat een HDD dus doorgeeft dat de ECC van een bepaalde sector niet klopt. Met die informatie kan de RAID-controller wat doen.

Maar eh, ik vind het allemaal een beetje vreemd, want als dat dus inderdaad zo is, dan is dat "self-healing data" van ZFS helemaal niets bijzonders.

[Verwijderd]

Compizfox schreef op maandag 04 januari 2016 @ 20:28:
Ik had laatst op Reddit een discussie over bitrot en self-healing data. Ik was altijd in de veronderstelling dat ZFS door combinatie van volume manager en bestandssysteem dingen kan doen die legacy RAID niet kan, zoals automatisch opsporen en repareren van corruptie.

Echter, volgens degene met wie ik in discussie was, kan legacy RAID dit ook doordat HDDs ook ECC hebben over elke sector, en doorgeven aan de RAID-controller als een sector corrupt is.

Dit is onjuist. Een hardeschijf met een sector waarbij het aantal bitfouten de ECC foutcorrectie overschrijdt, heeft een (uBER) bad sector. Dat kan een RAID controller weten door de timeout die volgt en vervolgens de data van een andere bron betrekken (de redundancy/parity) en vervolgens de schijf met de bad sector herstellen door de bad sector te overschrijven. Ik ken echter geen enkele RAID controller die dit doet. Dat md raid dit doet, is heel goed mogelijk. ZFS doet het in elk geval. Mogelijk geldt dit ook voor Btrfs en misschien ook wel ReFS.

Maar hoe er wordt omgegaan met bad sectors is een heel ander ding. Het gaat hier om corruptie. Daarmee versta ik niet dat er bitfouten in een sector op de hardeschijf zijn, want dat handelt de hardeschijf zelf af via ECC: of het wordt gecorrigeerd of het is een bad sector.

Nee, het gaat om corrupte data. Bijvoorbeeld door RAM corruptie dat een hardeschijf een schrijfactie krijgt van foute data. Dan staat er foutieve data op de hardeschijf. Weet de hardeschijf veel? Die krijgt gewoon een write request en voert deze uit. Er is dan ook geen sprake van bitfouten en ECC en al die meuk. Er is sprake van corruptie.

Corruptie kan door legacy RAID niet worden hersteld, en vaak ook niet worden gedetecteerd. Het enige wat legacy RAID kan, is constateren dat de redundancy dus de mirror disk of parity data, niet overeenkomt met de originele data. Alle RAID implementaties die ik ken, gaan er blindelings vanuit dat de originele data de juiste versie is en overschrijven de parity/mirror versie. Dit mechanisme kan juist de corruptie onherstelbaar maken omdat de enige juiste niet-corrupte versie van de data wordt overschreven. Legacy RAID is dom en kent eigenlijk geen mechanisme om slim om te gaan met corruptie. We overschrijven de data zodat in elk geval data en parity weer met elkaar overeenkomen, en vervolgens zoekt het filesystem het maar uit. Dit resulteert in een corrupte file, of blipjes in films of artefacts in foto's.

ZFS en andere 3e generatie filesystems gebruiken checksums om daadwerkelijk te controleren of de opgeslagen data zoals de hardeschijf deze aanlevert, wel overeenkomt met de checksum. En zo niet wordt de data vanuit een andere bron gelezen. Het grote verschil is dus dat ZFS weet welke versie van de data de juiste is. De enige uitzondering hierop is wanneer de checksum zelf onjuist is aangemaakt, dan heb je altijd nog errordetectie kortom je ziet dat file X is afgekeurd. Dat is nog altijd prima, want als die file echt belangrijk is, kun je deze uit backup herstellen. Is het niet belangrijk, dan is het fijn dat je in elk geval weet welke data niet meer goed is zodat je de file in kwestie bijvoorbeeld opnieuw kunt downloaden. Zo heb je controle over je data en weet je zeker dat wat een scrub overleeft, ook daadwerkelijk goed is.

De enige uitzondering op dit verhaal is als de data al corrupt was voordat ZFS het in handen krijgt. Door gebruik van Sendfile is die kans niet heel groot, omdat de netwerkcontroller de data via DMA in het geheugen zet, en daar blijft totdat ZFS de data weer uitleest. Zonder Sendfile vinden er meerdere memory copies plaats en is de kans op corruptie voordat het ZFS bereikt dus groter, omdat er meer met de data gesjouwd wordt. Als de netwerkcontroller ook over ECC zou beschikken en je RAM ook over ECC, dan is het enige risico nog de client die de data foutief aanlevert.

[Pantagruel]

Verwijderd schreef op dinsdag 05 januari 2016 @ 00:16:
[...]

Interessant stuk tekst it de quote geknipt

Als de netwerkcontroller ook over ECC zou beschikken en je RAM ook over ECC, dan is het enige risico nog de client die de data foutief aanlevert.

Waarmee we terug zijn bij het punt dat het enkel zo sterk is als de zwakste schakel in de keten.

Volledig afdekken zal een utopie blijven, 't maximale nastreven het doel. Hoewel dit laatste naar mijn idee eerder voor de relevante zakelijke omgevingen zal gelden dan voor de thuis situatie (ok, dromen mag ).

[BartNL]

Verwijderd schreef op dinsdag 05 januari 2016 @ 00:16:
[...]

Corruptie kan door legacy RAID niet worden hersteld, en vaak ook niet worden gedetecteerd. Het enige wat legacy RAID kan, is constateren dat de redundancy dus de mirror disk of parity data, niet overeenkomt met de originele data. Alle RAID implementaties die ik ken, gaan er blindelings vanuit dat de originele data de juiste versie is en overschrijven de parity/mirror versie.

Dit is onjuist. Raid controllers maken onderscheid tussen een "bad block" en data die niet klopt. Bij scrubben kan ik de Areca controller scrubbing separaat instellen voor beide situaties.

[FireDrunk]

Maar hoe weet de Areca controller welke van de twee blokken bij een mismatch de goede is?

Wat CiPHER bedoelt, is dat als er een mismatch is in een RAID5 stripe, er altijd vanuit gegaan wordt dat de parity niet goed is, en dus de parity opnieuw berekend wordt aan de hand van de corrupte data.

Dit omdat zonder metadata checksums je nooit weet of de parity of de data incorrect is (zoals je bij ZFS en BTRFS wel weet).

Hierdoor kunnen 3e Generatie filesystems de goede keuze maken, en kan je Legacy raid controller dit niet.

[Verwijderd]

Pantagruel schreef op dinsdag 05 januari 2016 @ 11:43:
[...]


Waarmee we terug zijn bij het punt dat het enkel zo sterk is als de zwakste schakel in de keten.

Ook met ECC blijft een risico bestaan. Maar we praten dan over risico's die echt nihil zijn. Ik vind het blindstaren op heel kleine risico's niet erg nuttig. Met ZFS ga je van 0% bescherming naar 99,9% bescherming. Die overige 0,1% kun je over zeuren maar dat is mijns inziens alleen nuttig voor speciaal gebruik. Bijvoorbeeld als je een bank bent of kerncentrale.

BartNL schreef op dinsdag 05 januari 2016 @ 12:31:
Dit is onjuist. Raid controllers maken onderscheid tussen een "bad block" en data die niet klopt. Bij scrubben kan ik de Areca controller scrubbing separaat instellen voor beide situaties.

Je reageert op een stuk over corruptie en je hebt het over het verschil met bad blocks en corruptie. Dus ik snap niet goed waar je precies op reageert en wat je precies onjuist vind wat ik zeg. Kun je daar nog iets meer over zeggen?

Daarnaast, 'data die niet klopt' oftewel corruptie is niet iets wat een RAID controller kan detecteren. RAID controllers weten namelijk niets van het filesystem, ze weten enkel of de parity data overeenkomt met de originele data en of er inderdaad onleesbare sectoren zijn. Maar corruptie op het niveau van het filesystem - waar we hier over praten - kan niet worden gedetecteerd door een RAID controller. Zelfs corruptie op het niveau van de RAID-laag - dus dat de parity niet overeenkomt met de data - kan een RAID controller weinig mee. Het enige wat het kan is blindelings aannemen dat één versie correct is en de parity maar gewoon overschrijven. Daarmee kan het dus zijn dat de parity de enige niet-corruptie versie is en die wordt daarmee overschreven. Daarmee is de corruptie permanent en onherstelbaar geworden.

Legacy RAID is dom. 3e generatie filesystems zijn slim. Die hebben beschermingsmechanismen waar je een betrouwbaar opslagsysteem mee kunt bouwen. Bij Legacy RAID blijven er zoveel risico's bestaan (write hole bijvoorbeeld) dat het uiteindelijk een keer mis gaat. Het is dan alleen de vraag hoe snel je statistisch gezien gegrepen wordt door silent corruption. Sommigen bagatelliseren bepaalde risico's, omdat zij zelf ogenschijnlijk nooit last hebben ondervonden van deze risico's. Maar dat betekent niet dat de risico's niet bestaan. Een oma die 99 jaar is geworden met dagelijks drie pakjes sigaretten, is nog geen bewijs dat roken niet heel ongezond en zelfs dodelijk is. Kortom, dat enkelen legacy RAID zonder ogenschijnlijke problemen draaien voor lange tijd, betekent nog niet dat de genoemde risico's niet bestaan - hooguit dat zij tot nu toe geluk hebben gehad. Maar de dobbelsteen des doods rolt niet voor iedereen even gunstig.

[F-Tim]

Mede-tweakers! Kan ik weer even een paar simpele (en wellicht voor sommigen domme) vragen stellen? Ik kan nl. geen concrete antwoorden hierop vinden.

Ik wil op een ZFSGuru installatie UMS draaien, deze heeft Gnome nodig om de UI in te kunnen stellen. Beiden staan in System Services, en zijn dus te installeren op een 0.3.1 systeem. Althans, zo lees ik het als leek.
Als ik namelijk hier kijk, dan staat er dat het niet werkt op systeem versie 002 en 003. Als ik vervolgens op de website van ZFSGuru zelf kijk, dan zie ik dat de meest actuele versie 0.3.1 en systeem 005 zijn... Terwijl de installatie en liveCD allen de versie 10.2.003 versienummer hebben. Eindigend op.... 003. Wellicht toeval, of werkt gnome niet op mijn huidige installatie?
Welke systeem versie is de huidige stabiele 10.2.003 / 0.3.1 versie?

Indien Gnome niet werkt, dan zal ik kijken dat ik een Plex installatie werkend krijg oók over DLNA. En dan maar hopen dat het niet zo'n XML gehack blijkt te zijn als ik op veel sites lees. Onze huidige TV ondersteunt geen Plex, maar wel DLNA en dat werkt met UMS iig perfect.

Daarnaast ben ik benieuwd of ik Dropbox kan installeren op ZFSGuru/FreeBSD? Ik draai nu (lokaal op m'n windows machine) SabNZBd+, waarbij ik een te monitoren map heb ingesteld op de root folder van dropbox. Uiteraard wil ik het downloaden ook overzetten naar de NAS zodat de desktop wat vaker uit kan. Als ik google naar "Dropbox FreeBSD", dan lijkt het erop dat er geen (officiele) clients zijn? Of is er wel een werkbare oplossing? Ik zie Dropbox namelijk ook niet bij services voorbij komen Dropbox als tussenstap werkt namelijk prima als ik een keer een NZB via mijn iPhone of iPad upload.

Als Dropbox ook niet werkt, in hoeverre is Owncloud dan een goed en veilig alternatief? Het ziet er namelijk wel érg strak uit. En met de informatie die ik erover vind lijkt deze ook goed geintegreerd te zijn met apps op iOS, en dus zou ik daar een vergelijkbare oplossing mee kunnen creeren.
Alleen zou dat betekenen dat de NAS (middels 1 of meerdere poorten) open op internet wordt aangesloten, maar dit zou dan niet moeten resulteren in dat al mijn data (op de NAS) eenvoudig op straat belandt...

[Q]

Ik weet niet of dit heel veel toevoegd maar de situatie is eigenlijk heel simpel.

Legacy RAID vertrouwt je harde schijf. Zolang je harde schijf geen lees error geeft (URE) vertrouw je RAID laag de data.

Komt je RAID laag een lees fout tegen dan doet RAID zijn werk. Maar als je op dat moment al een schijf kwijt bent en niet meer redundant bent (RAID5) dan ben je dus de sjaak.

Of je dan daadwerkelijk je hele RAID array verliest of dat je alleen enkele bestanden kwijt bent ligt denk ik aan de RAID controller / software die je gebruikt. Dat weet ik niet zo goed. Maar ZFS kan die situatie aan, hooguit verlies je een paar files.

Je hoort veel mensen praten over UREs maar UREs zijn gewoon niet zo relevant voor thuis. Daar kan legacy RAID prima mee overweg, dat gaat in 99.9% van de gevallen goed.

Voor zowel legacy RAID als ZFS geldt dat je wel regelmatig moet scrubben om latente UREs op te sporen, zodat je ze kunt afhandelen als je nog parity beschikbaar hebt.

MDADM kan met een scrub alleen UREs opsporen, het controleert niet de integriteit van de data door de data met de parity te vergelijken (en als er dan een fout wordt gevonden, is de parity of de data fout? -> werkt conceptueel alleen 'echt' met RAID6 maar dat is dus niet geimplementeerd)

Silent data corruptie
Harde schijven gebruiken intern ECC en belangrijker Reed-Solomon encoding om foute data te corrigeren.
Er moet dus best wat mis zijn voordat een harde schijf een read error geeft. En de kans dat een schijf zelf corrupte data retourneert zonder foutmeldingen is dus zeer klein, vanwege die checksums over een sector.

Voor thuis gebruik is het gebruik van legacy RAID niet zo'n issue wat mij betreft. ZFS is 'beter' in die zin dat het tegen een klein risico beschermt dat niet wordt gemitigeerd door legacy RAID oplossingen.

Zonder ZFS weet je in feite ook niet of data corrupt is geraakt, dat is best interessant. Tot nu toe heeft ZFS bij mij over mijn data set nog nooit een verkeerde bit aangetroffen. Met bovenstaande in acht nemende is dat denk ik ook helemaal niet zo gek. Maar toegegeven, het is slechts een anekdote.

Je neemt thuis geen groter risico met legacy RAID als al die mensen die een Synology of QNAP kopen. Aan jou om te bepalen of je daar OK mee bent of niet.

Die dingen doen ook geen ECC RAM geheugen, dus daarvoor geldt precies hetzelfde. Het plaatst alles een beetje in perspectief.

Als je echt het risico niet wilt lopen dat je data corrupt raakt dan moet je zowel ZFS als ECC RAM geheugen toepassen. Je kunt ook ECC geheugen wegbezuinigen, maar dan laat je weer een nogal zeer goed gedocumenteerd en aangetoond risico open.

Grote discussies over nut en noodzaak van ECC geheugen zijn terug te vinden in
ECC geheugen voor zelfbouw ZFS NAS?

Ik heb hier ook een post geplaatst over wat info over silent data corruptie, om deze thread niet te laten vervuilen over de ECC discussie.

De enige uitzondering op dit verhaal is als de data al corrupt was voordat ZFS het in handen krijgt. Door gebruik van Sendfile is die kans niet heel groot, omdat de netwerkcontroller de data via DMA in het geheugen zet, en daar blijft totdat ZFS de data weer uitleest. Zonder Sendfile vinden er meerdere memory copies plaats en is de kans op corruptie voordat het ZFS bereikt dus groter, omdat er meer met de data gesjouwd wordt. Als de netwerkcontroller ook over ECC zou beschikken en je RAM ook over ECC, dan is het enige risico nog de client die de data foutief aanlevert.

Ik ben er niet zo goed in thuis maar volgens mij doen de meeste andere file systems ook wel gewoon DMA copies dus dat is dan weer niet zo relevant. Als je data integriteit en veiligheid wilt is ECC RAM geheugen een eis, je moet namelijk de hele keten van risico's afdekken. ZFS is 'maar' een schakel in de keten.

Netwerk controllers en ECC geheugen
Of je netwerk controller in je server ECC geheugen heeft hangt af van de netwerk controller.

https://communities.intel...hernet-controller-updated
https://communities.intel.../16/even-more-ecc-updates

Zover ik weet worden server moederborden altijd met controllers uitgeleverd die (uiteraard) ECC ondersteunen zodat het hele pad is afgedekt.

Ook dit is weer een pré om dus server moederborden te gebruiken als je een 'veilige' NAS wilt bouwen ofwel om je netwerk controller met zorg uit te kiezen.

[ Voor 28% gewijzigd door Q op 05-01-2016 17:30 ]

[BartNL]

Verwijderd schreef op dinsdag 05 januari 2016 @ 12:49:
[...]

Je reageert op een stuk over corruptie en je hebt het over het verschil met bad blocks en corruptie. Dus ik snap niet goed waar je precies op reageert en wat je precies onjuist vind wat ik zeg. Kun je daar nog iets meer over zeggen?

Een raid controller kan wel een bad block als oorzaak van corruptie detecteren. Ik neem aan dat dit gebeurt wanneer de HDD error correctie detecteert dat een data block niet klopt.
Misschien klopt mijn aanname niet maar dat een raid controller altijd op dezelfde manier de party corrigeert is niet waar.

[Verwijderd]

F-Tim schreef op dinsdag 05 januari 2016 @ 15:09:
Ik wil op een ZFSguru installatie UMS draaien, deze heeft Gnome nodig om de UI in te kunnen stellen. Beiden staan in System Services, en zijn dus te installeren op een 0.3.1 systeem. Althans, zo lees ik het als leek.
Als ik namelijk hier kijk, dan staat er dat het niet werkt op systeem versie 002 en 003. Als ik vervolgens op de website van ZFSGuru zelf kijk, dan zie ik dat de meest actuele versie 0.3.1 en systeem 005 zijn... Terwijl de installatie en liveCD allen de versie 10.2.003 versienummer hebben.

De LiveCD is om mee te booten. Tijdens de eerste installatiestap kies je welke versie je wilt installeren. Daar kun je 005 kiezen. Je hebt dus niet continu een nieuwe livecd nodig. Je kunt met de LiveCD of USB stick alle versies installeren. Ik zou voor 10.2.005 of 10.3.005 gaan.

Indien Gnome niet werkt, dan zal ik kijken dat ik een Plex installatie werkend krijg oók over DLNA. En dan maar hopen dat het niet zo'n XML gehack blijkt te zijn als ik op veel sites lees. Onze huidige TV ondersteunt geen Plex, maar wel DLNA en dat werkt met UMS iig perfect.

Ik ken Plex en UMS enzo niet. Plex werkt in elk geval wel met ZFSguru. Alles wat grafische interface (Gnome) vereist op ZFSguru, is nog ultra experimenteel. Ik zou lekker voor een andere oplossing gaan, zoals een aparte machine met Ubuntu erop of een virtual machine. Dat werkt vooralsnog veel stabieler. BSD en dus ook ZFSguru hebben sowieso nog heel experimentele grafische drivers die alleen voor wat oudere (Sandy Bridge/Ivy Bridge) Intel en AMD onboard graphics en voor nVidia videokaarten redelijk werkt. Dus dat is wellicht niet een heel goede optie voor je.

Daarnaast ben ik benieuwd of ik Dropbox kan installeren op ZFSGuru/FreeBSD?

Ik heb ooit gekeken naar de mogelijkheid. Ik ben er toen niet meer mee verder gegaan. Het zou wel kunnen werken met Linux emulatie. Er is geen native BSD client. Ik ben verder geen fan van Dropbox om privacy redenen. Het is zeer privacy onvriendelijk.

Als Dropbox ook niet werkt, in hoeverre is Owncloud dan een goed en veilig alternatief? Het ziet er namelijk wel érg strak uit. En met de informatie die ik erover vind lijkt deze ook goed geintegreerd te zijn met apps op iOS, en dus zou ik daar een vergelijkbare oplossing mee kunnen creeren.
Alleen zou dat betekenen dat de NAS (middels 1 of meerdere poorten) open op internet wordt aangesloten, maar dit zou dan niet moeten resulteren in dat al mijn data (op de NAS) eenvoudig op straat belandt...

Ik ken Owncloud op zich niet zo. Weet wel dat het heel aardig werkt op ZFSguru. Maar ik heb het nooit echt in gebruik genomen. Het heeft inderdaad wel mooie sync clients. Ik zou zeggen, probeer het eens? Lijkt me vrij gemakkelijk aan de praat te krijgen.

[FireDrunk]

BartNL schreef op dinsdag 05 januari 2016 @ 21:41:
[...]

Een raid controller kan wel een bad block als oorzaak van corruptie detecteren. Ik neem aan dat dit gebeurt wanneer de HDD error correctie detecteert dat een data block niet klopt.
Misschien klopt mijn aanname niet maar dat een raid controller altijd op dezelfde manier de party corrigeert is niet waar.

Nou, daar wil ik wel eens bewijs van zien, want ik ben het met CiPHER eens. Er is geen "taal" die HDD's met RAID controllers kunnen praten over wat er mis is. Zoals CiPHER al zei, krijg je gewoon een I/O error. Of dat komt door ECC, CRC, Kabelfouten, magnetische straling, een johovah getuige, of Britney spears die staat te kwelen, weet je RAID controller niet. Het enige dat hij weet, is dat de disk die sector niet kon lezen.

Wat de RAID controller wel kan is zien dat de stripe niet volledig is (door een scrub (check in mdadm)).
Simpel gezegd: de RAID controller leest gewoon alle stripes in, en waar hij geen data krijgt, kan hij data terugschrijven in theorie (maar dat doet voor zover ik weet alleen mdadm).

Waar hij wel data terugkrijgt maar de data is foutief, weet hij niet of de parity niet klopt (want die mismatch), of de data niet klopt (want de parity mismatched )

Daar zit het grote euvel. Dat eerste probleem is overkomelijk want je hebt je redundancy om de data te reconstrueren (je krijgt immers data + geen data). Het tweede probleem is veel lastiger, want je krijgt twee versies van je data waar je niet weet welke waar is.

In theorie zou RAID6 dit probleem kunnen verminderen omdat er twee pariteiten zijn, maar ook daar zou er eigenlijk gebruik gemaakt moeten worden van metadata checksums. Bovendien moet ik (net als Q) de eerste RAID6 implementatie nog zien die dit goed doet.

[ Voor 7% gewijzigd door FireDrunk op 06-01-2016 07:27 ]

[idef1x]

Noobvraagje:
Ik heb een disk in een raidz2 pool (ZFS on linux) die een pending sector geeft die maar niet wil verdwijnen, (1 is niet veel, maar om nu elke dag een mailtje van smart te krijgen is ook weer zo wat ) dus dacht ik deze maar eens geheel te overschrijven/controleren met "badblocks -w" oid, maar moet ik nu:

1) de disk offline zetten => zpool tank offline disk; gevolgd door de disk controle en dan weer een "zpool tank online disk doen;

of:

2) de disk detachen => zpool tank detach disk etc?

Als ik zo op het web lees lijkt het me de 1e, maar wat gebeurd er dan precies als je een disk offline zet? Klinkt als van gewoon even niets mee doen, maar zfs onhoud hem wel, dus wat gebeurd er dan precies als je een overschreven disk dan weer online zet? Gaat zfs een complete resilver doen als of het een nieuwe disk is of gaat ie het niet meer snappen daar de disk overschreven/leeg is? Met detach haal je hem zo te lezen geheel uit de pool en kun je ermee doen wat je wilt dus klinkt eigenlijk logischer?

[CurlyMo]

Waarschijnlijk kan je na een badblocks je disk niet meer online zetten, omdat dan volgens mij ook de ZFS informatie op die schijf is verdwenen. Nadat hij offline is gehaald moet je hem waarschijnlijk replacen. ZFS ziet dan gewoon weer een lege schijf en zal de oude door de nieuwe vervangen. Detach lijkt me dan beter omdat je dan al tegen ZFS zegt dat de schijf onbeschikbaar gaat zijn i.p.v. dat ZFS zelf ontdekt.

[A1AD]

FireDrunk schreef op woensdag 06 januari 2016 @ 07:25:
[...]
Zoals CiPHER al zei, krijg je gewoon een I/O error. Of dat komt door ECC, CRC, Kabelfouten, magnetische straling, een johovah getuige, of Britney spears die staat te kwelen, weet je RAID controller niet.