Het grote ZFS topic

[FireDrunk]

@CiPHER, dat leek mij ook leuk, en ik heb SmartOS gezien, Solaris met KVM (bijna Xen).
Naar mijn weten was/is Xen nog niet (100%) geport naar BSD?

@Jadjong, klopt, maar ik heb gister bij het updaten van mijn iKVM het ding gesloopt (password word niet meer herkend), dus ik moet even een support ticket inleggen. heb een support ticket ingelegd.
De iKVM heb ik nodig voor de installatie (aangezien ik geen lege CD's meer heb ), dus dat moet even op zich laten wachten.

@analog_, VMXNET3 is wel een pre, maar omdat ik nu 'echte' 10Gb adapters heb, is de E1000 controller prima om het ding van internet (en lokaal netwerk) te voorzien.

[ Voor 14% gewijzigd door FireDrunk op 11-04-2012 11:17 ]

[Pixeltje]

Ik heb m'n NAS nu weer up-and-running, alle schijven zijn in orde, elke nacht wordt er een SMART short self test uitgevoerd en de resultaten gemaild naar me, elke nacht )na de smart-test) wordt er een scrub gedaan (cron-job: zpool scrub tank) en de beveiliging is in orde.

Ik loop nu tegen een probleem aan bij het activeren van de firefly media server in FreeNAS. Ik heb de handleiding op het forum gevolgd en weet zeker dat alle waarden goed zijn ingesteld. (heb het verhaal nu 3 keer doorlopen en ben er absoluut zeker van dat alle " en paden goed staan)

Korte samenvatting:
Muziekfolder op /mnt/tank/Data/Muziek
mt-daapd.conf op /mnt/tank/Home/iTunes

user voor firefly: iTunes

Volume "tank" heeft rechten voor iedereen op read/write staan
Datasets Home en Data ook, ik kan als iTunes of als root ook gewoon schrijven en lezen naar die volumes.

Als ik de service mt-daapd wil starten krijg ik helaas een error waarvan ik niet weet hoe ik 'm moet oplossen:

command:
service mt-daapd start

Foutmelding:

code:

/usr/local/etc/rc.d/mt-daapd: WARNING: -c is not readable.
/usr/local/etc/rc.d/mt-daapd: WARNING: failed precmd routine for firefly

Hoe zorg ik ervoor dat "-c" readable wordt? Voor zover ik weet staan alle rechten goed, dus zou de user iTunes (of root, for that matter) gewoon deze service moeten kunnen starten en die bestanden uitlezen. Iemand hier misschien een idee wat ik fout doe?

[CurlyMo]

Pixeltje schreef op woensdag 11 april 2012 @ 21:44:
Ik heb m'n NAS nu weer up-and-running, alle schijven zijn in orde, elke nacht wordt er een SMART short self test uitgevoerd en de resultaten gemaild naar me, elke nacht )na de smart-test) wordt er een scrub gedaan (cron-job: zpool scrub tank) en de beveiliging is in orde.

Elke nacht een scrub is wel een beetje erg vaak. Ik draai een scrub elke maand. Ik zou hem sowieso niet vaker doen dan elke week.

[Pixeltje]

Fair enough. Er staat nu nog nauwelijks data op de NAS, dus een scrub is zo klaar (iets minder dan een minuut zelfs) en wil de eerste week gewoon even elke dag weten of alle schijven nog in orde zijn. In de RMA periode van de schijf die eerst stukging is er namelijk nog een overleden, deze dingen zijn zo onbetrouwbaar als de pest.

[Jaap-Jan]

Pixeltje schreef op woensdag 11 april 2012 @ 21:44:

Hoe zorg ik ervoor dat "-c" readable wordt? Voor zover ik weet staan alle rechten goed, dus zou de user iTunes (of root, for that matter) gewoon deze service moeten kunnen starten en die bestanden uitlezen. Iemand hier misschien een idee wat ik fout doe?

Eigenlijk off-topic, maar het configuratiebestand wat je meegeeft met de -c optie bestaat niet of heeft niet de juiste rechten, waardoor mt-daapd hem niet kan lezen. Aan jou de schone taak om uit te zoeken wat het probleem is.

[Pixeltje]

Jaap-Jan schreef op woensdag 11 april 2012 @ 21:57:
[...]
Eigenlijk off-topic, maar het configuratiebestand wat je meegeeft met de -c optie bestaat niet of heeft niet de juiste rechten, waardoor mt-daapd hem niet kan lezen. Aan jou de schone taak om uit te zoeken wat het probleem is.

ja, en daar ligt nu een beetje het probleem. Ik zou niet weten wat er mis is. Ik kan namelijk dat bestand (mt-daapd) gewoon editen via SSH in terminal, dus het bestaat.

Users Root, iTunes en Sjaak hebben allemaal toegang tot en schrijfrechten op het bestand, dus ik zou niet weten waarom het not readable zou zijn.

[FireDrunk]

Welke rechten hebben ze exact? Heb je iets met groepen gedaan? Heb je geavanceerde ACL's aangezet?

[Pixeltje]

Root mag alles, (ls -l op het bestand mt-daapd gedaan, exacte uitkomst zal ik vanmiddag posten als ik weer toegang heb tot m'n NAS), gebruiker iTunes zou dezelfde rechten moeten hebben. Ik heb geen ACL's of aparte groepen gemaakt. Root en iTunes zitten in Wheel, daar is niets aan veranderd.

[FireDrunk]

Dus de rechten moeten (0)777 zijn in mijn inziens?

[Pixeltje]

Dat zijn ze niet, ik heb ergens op internet een ingewikkeld artikel gevonden hoe je die rechten kunt berekenen, maar momenteel zijn ze allemaal geen 777. Ik zal vanavond even laten zien hoe het eruit ziet, dat praat wat makkelijker denk ik.

[u_nix_we_all]

Ik ben nu bezig met wat testen op OI-151a2, en zit te spelen met de sectorsize van de disks.
Ik heb Seagate ST2000DM001-9YN1 disks, deze hebben volgens de specs een logical sectorsize van 512B, maar een physical size van 4k.
Ik heb nu een pool aangemaakt met een ashift=12 (2^12=4k) , ipv de standaardwaarde ashift=9 (2^9=512), maar merk er in performance precies 0,0 van (t.o.v. 512B sectors).
(Hiervoor moest ik een gepatchte zpool binary gebruiken, standaard kan dit (nog ?) niet met OI-151a2)

Waar ik niet helemaal uitkom is het volgende: met fdisk zie ik dat de drives nog steeds een sectorsize van 512 claimen te hebben. Hoe kan ik zien of zfs de sectorsize van 4k goed gebruikt, of dat er intern toch 512B blocks op de disk worden geschreven ? Kan het zijn dat de alignment van de 4k sectoren (als er al met 4k tegelijk geschreven wordt) niet klopt en er voor elk 4k block 2 4k sectoren geschreven/gelezen moeten worden ? Kan ik dit controleren ?

Overigens is het best wel leuk om even met een 36-bay systeem, met 34 x 2TB en 2x 120 GB SSD te mogen spelen

[Verwijderd]

OI vraagt de disk: wat is je sector size ipv van het je laten opgeven. Je disk presenteert 512kb logical size naar het OS toe dus pakt hij dat. De "markt" is nog niet zo ver zo lijkt het dat dat op een "normale" manier wordt aangegeven.

Hoe IO/ZFS dat doet is een simple ioct() die een SCSI inquiry doet. Om je size te checken:

zdb -C <pool>

of via mdb:

echo '::spa -c' | mdb -k

[u_nix_we_all]

Alle vdevs' in de pool hebben nu ashift=12 (of 0x0000000c) en de disken in de vdev's ook, dus dat kan ik wel zien, dat is het probleem niet. Het probleem is dat ik vermoed dat er nog met 512b (geen kb ) gewerkt wordt, en ik niet weet hoe ik dat moet controleren, of begrijp ik je opmerking over de scsi ioctl's niet helemaal ?

[Verwijderd]

De sectorsize van de schijven blijft gewoon 512B, dat is het probleem niet. Het punt is dat ZFS nu geen I/O meer doet die een breuk zijn van 4K sectoren, zoals 15.5KB. Dit komt voor bij niet optimale configuraties van RAID-Z/RAID-Z2/RAID-Z3 familie, de 128K / <data disks> formule.

Post je zpool status output eens.

FireDrunk schreef op woensdag 11 april 2012 @ 08:33:
@CiPHER, dat leek mij ook leuk, en ik heb SmartOS gezien, Solaris met KVM (bijna Xen).
Naar mijn weten was/is Xen nog niet (100%) geport naar BSD?

FreeBSD deed al langer Xen DomU (=guest) op i386 (32-bit). Later kwam daar amd64 (64-bit) support bij, en FreeBSD 9 zou Xen Dom0 (=host) krijgen, maar dat ging helaas niet door. Hopelijk komt dat nog eens, maar als guest zou FreeBSD dus wel aardig moeten werken, al is het lange tijd dat ik dit heb geprobeerd.

Je moet wel een speciale kernel bakken; config file staat al klaar met de naam XENHVM. Dus bijvoorbeeld:
'make buildkernel KERNCONF=XENHVM' zou moeten werken.

Vond ook dit:
FreeBSD supports both hardware virtualized (HVM) and fully para-virtualized (PV) kernels on i386. PV drivers are supported only with the PV kernel.
FreeBSD supports only hardware virtualized (HVM) kernels on amd64; however, PV drivers are supported in this configuration.

[ Voor 65% gewijzigd door Verwijderd op 12-04-2012 16:39 ]

[Ravefiend]

Wat betreft die ashift, of die nu 9 of 12 is voor 512b disks, kon het toch ook door ervoor te zorgen dat de partie op elke disk op de juiste plaats begint (raidz2)?

gpart create -s GPT /dev/da0
gpart add -b 2048 -s 3906824192 -t freebsd-zfs -l rz2_disk1 /dev/da0
...

Op die manier zorg je er toch voor dat de partie op een 4K aligned sector begint?

[u_nix_we_all]

Verwijderd schreef op donderdag 12 april 2012 @ 16:29:
De sectorsize van de schijven blijft gewoon 512B, dat is het probleem niet. Het punt is dat ZFS nu geen I/O meer doet die een breuk zijn van 4K sectoren, zoals 15.5KB. Dit komt voor bij niet optimale configuraties van RAID-Z/RAID-Z2/RAID-Z3 familie, de 128K / <data disks> formule.

Post je zpool status output eens.

Configuratie van de pool tank zou wel optimaal moeten zijn, de pool tank is een stripe over 16 mirrors , dus 128k/16 is 8k per stripe per disk.

code:

root@supernas:~# zpool status
  pool: rpool
 state: ONLINE
  scan: resilvered 18.7G in 0h11m with 0 errors on Tue Mar 20 12:36:37 2012
config:

        NAME          STATE     READ WRITE CKSUM
        rpool         ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            c2t0d0s0  ONLINE       0     0     0
            c2t1d0s0  ONLINE       0     0     0

errors: No known data errors

  pool: tank
 state: ONLINE
  scan: none requested
config:

        NAME         STATE     READ WRITE CKSUM
        tank         ONLINE       0     0     0
          mirror-0   ONLINE       0     0     0
            c2t4d0   ONLINE       0     0     0
            c2t5d0   ONLINE       0     0     0
          mirror-1   ONLINE       0     0     0
            c2t6d0   ONLINE       0     0     0
            c2t7d0   ONLINE       0     0     0
          mirror-2   ONLINE       0     0     0
            c2t8d0   ONLINE       0     0     0
            c2t9d0   ONLINE       0     0     0
          mirror-3   ONLINE       0     0     0
            c2t10d0  ONLINE       0     0     0
            c2t11d0  ONLINE       0     0     0
          mirror-4   ONLINE       0     0     0
            c2t12d0  ONLINE       0     0     0
            c2t13d0  ONLINE       0     0     0
          mirror-5   ONLINE       0     0     0
            c2t14d0  ONLINE       0     0     0
            c2t15d0  ONLINE       0     0     0
          mirror-6   ONLINE       0     0     0
            c2t16d0  ONLINE       0     0     0
            c2t17d0  ONLINE       0     0     0
          mirror-7   ONLINE       0     0     0
            c2t18d0  ONLINE       0     0     0
            c2t19d0  ONLINE       0     0     0
          mirror-8   ONLINE       0     0     0
            c2t20d0  ONLINE       0     0     0
            c2t21d0  ONLINE       0     0     0
          mirror-9   ONLINE       0     0     0
            c2t22d0  ONLINE       0     0     0
            c2t23d0  ONLINE       0     0     0
          mirror-10  ONLINE       0     0     0
            c2t24d0  ONLINE       0     0     0
            c2t25d0  ONLINE       0     0     0
          mirror-11  ONLINE       0     0     0
            c2t26d0  ONLINE       0     0     0
            c2t27d0  ONLINE       0     0     0
          mirror-12  ONLINE       0     0     0
            c2t28d0  ONLINE       0     0     0
            c2t29d0  ONLINE       0     0     0
          mirror-13  ONLINE       0     0     0
            c2t30d0  ONLINE       0     0     0
            c2t31d0  ONLINE       0     0     0
          mirror-14  ONLINE       0     0     0
            c2t32d0  ONLINE       0     0     0
            c2t33d0  ONLINE       0     0     0
          mirror-15  ONLINE       0     0     0
            c2t34d0  ONLINE       0     0     0
            c2t35d0  ONLINE       0     0     0
        logs
          c2t2d0     ONLINE       0     0     0
        cache
          c2t3d0     ONLINE       0     0     0

Edit:

Ravefiend schreef op donderdag 12 april 2012 @ 16:46:
Wat betreft die ashift, of die nu 9 of 12 is voor 512b disks, kon het toch ook door ervoor te zorgen dat de partie op elke disk op de juiste plaats begint (raidz2)?

gpart create -s GPT /dev/da0
gpart add -b 2048 -s 3906824192 -t freebsd-zfs -l rz2_disk1 /dev/da0
...

Op die manier zorg je er toch voor dat de partie op een 4K aligned sector begint?

Hmm, op OI heb ik geen gpart, alleen een fdisk die niet zoveel info geeft. Ik weet niet eens of ik wel GPT-labels gebruik, het enige wat fdisk me laat zien is dat de whole disk een EFI partitie is.

Ik moet wel eerlijk zeggen dat OI (en OpenSolaris en verwanten vanaf versie 9) wel weer enorm zoeken is, wel solaris ervaring in het verleden, maar het lijkt wel of sinds sunos 2.8 /solaris 8 echt alles anders is geworden

[ Voor 11% gewijzigd door u_nix_we_all op 12-04-2012 16:57 ]

[Verwijderd]

@u_nix_we_all: ah oke, bij mirror heb je geen problemen met 4K disks, dus ook geen tot weinig voordeel, je hebt bij ashift=12 wel minder opslagruimte als je veel kleine bestanden opslaat, dus bij voorkeur ashift=9 houden als het toch geen voordeel oplevert.

@RaveFiend
Het gaat niet op partitie; de partitie moet zelf ook aligned zijn. Maar veel Solaris gebruikers gebruiken geen partities. De GPT support is ook niet zo heel goed; zo ondersteunt het geen FreeBSD GPT partities wat wel jammer is. Andersom werkt het wel.

De commando's die je gaf, maken een GPT partitie schema aan met één partitie die op 1MiB (2048 sectoren van 512B) offset start, dus dat is uitstekend. Maar dan ben je er nog niet; als ZFS vervolgens I/O zoals 35.5KiB gaat doen op de disks, moeten deze disks intern emulatie uitvoeren. Dus ze moeten eerst de hele sector lezen, dan de oude met nieuwe data verenigen en vervolgens een volle 4K sector wegschrijven, ook al wilde ZFS maar 1.5K van de 4K sector beschrijven.

Bovenstaand gedrag voorkom je met een ashift-waarde van 12. Dat is gewoon een macht van twee: 2^12=4096, Ashift waarde 13 zou overeenkomen met 8K sectoren. Wat gebeurt er nou met ashift=12?

Voorbeeld RAID-Z vdev met recordsize van 128K (max voor ZFS versie <32).

Voorbeeld niet-optimale 4K configuratie, 128K gedeeld door drie data disks
disk1: 42.6 = 43.0
disk2: 42.6 = 43.0
disk3: 42.6 = 43.0
disk4: 42.6 = 43.0 (parity)

Voorbeeld optimale 4K configuratie, 128K gedeeld door twee data disks:
disk1: 64.0 = 64.0
disk2: 64.0 = 64.0
disk3: (parity)

Je wilt dus de formule aanhouden:
<recordsize> / <total disks - parity disks> = request size per disk; moet een veelvoud zijn van 4KiB.
Voorbeeld: 128K / (5 - 1) = 32KiB = optimaal en veelvoud van 4KiB. 5-disk configuratie met RAID-Z dus 4 data disks.

[ Voor 7% gewijzigd door Verwijderd op 12-04-2012 16:57 ]

[Pixeltje]

Zoals beloofd;

code:

[Sjaak@freenas] /usr/local/etc/rc.d# ls -l
total 45
drwxr-xr-x   2 root  wheel  1024 Feb 29 03:23 ./
drwxr-xr-x  21 root  wheel  1536 Apr 12 18:54 ../
-r-xr-xr-x   1 root  wheel  1059 Feb 29 02:37 ataidle*
-r-xr-xr-x   1 root  wheel   873 Feb 29 02:39 avahi-daemon*
-r-xr-xr-x   1 root  wheel  1119 Feb 29 02:39 avahi-dnsconfd*
-r-xr-xr-x   1 root  wheel   522 Feb 29 02:26 collectd*
-r-xr-xr-x   1 root  wheel   612 Feb 29 02:26 collectdmon*
-r-xr-xr-x   1 root  wheel   832 Feb 29 02:38 dbus*
-rwxr-xr-x   1 root  wheel  2458 Feb 29 00:44 django*
-r-xr-xr-x   1 root  wheel  2036 Feb 29 01:45 fusefs*
-r-xr-xr-x   1 root  wheel   787 Feb 29 01:16 inadyn*
-r-xr-xr-x   1 root  wheel   462 Feb 29 01:22 istgt*
-r-xr-xr-x   1 root  wheel  3242 Feb 29 01:55 lighttpd*
-r-xr-xr-x   1 root  wheel   602 Feb 29 03:23 minidlna*
-r-xr-xr-x   1 root  wheel   434 Apr 11 21:07 mt-daapd*
-r-xr-xr-x   1 root  wheel  1991 Feb 29 02:41 netatalk*
-r-xr-xr-x   1 root  wheel   473 Feb 29 01:37 nmbd*
-r-xr-xr-x   1 root  wheel   958 Feb 29 01:58 nut*
-r-xr-xr-x   1 root  wheel   947 Feb 29 01:58 nut_upslog*
-r-xr-xr-x   1 root  wheel   843 Feb 29 01:58 nut_upsmon*
-r-xr-xr-x   1 root  wheel   710 Feb 29 01:21 proftpd*
-r-xr-xr-x   1 root  wheel   659 Feb 29 02:25 rrdcached*
-r-xr-xr-x   1 root  wheel   618 Feb 29 01:27 rsyncd*
-r-xr-xr-x   1 root  wheel  1934 Feb 29 01:37 samba*
-r-xr-xr-x   1 root  wheel  1534 Feb 29 01:47 smartd*
-r-xr-xr-x   1 root  wheel   473 Feb 29 01:37 smbd*
-r-xr-xr-x   1 root  wheel  1787 Feb 29 01:57 snmpd*
-r-xr-xr-x   1 root  wheel   812 Feb 29 01:57 snmptrapd*
-r-xr-xr-x   1 root  wheel  2585 Feb 29 01:54 spawn-fcgi*
-r-xr-xr-x   1 root  wheel  1518 Feb 29 03:07 transmission*
-r-xr-xr-x   1 root  wheel   766 Feb 29 01:50 vmware-guestd*
-r-xr-xr-x   1 root  wheel  2550 Feb 29 01:50 vmware-kmod*
-r-xr-xr-x   1 root  wheel   575 Feb 29 01:37 winbindd*

Je ziet dat alle rechten hetzelfde aangegeven worden (-r-xr-xr-x) behalve die voor Django.

Ik kan het mt-daapd bestand openen, bewerken en opslaan, maar kennelijk niet uitvoeren.

[FireDrunk]

[root@NAS init.d]# ls -l
total 568
-rwxr-xr-x. 1 root root  1725 Aug 18  2010 acpid
-rwxr-xr-x. 1 root root  2062 Jan 30 14:56 atd
-rwxr-xr-x. 1 root root  3378 Dec  8 02:14 auditd
*knip*

Ik zie hier toch heel wat meer w-tjes... En een * betekend dat er een ACL aan hangt...
Of FreeNAS moet weer een andere betekenis aan het * geven dan dat de rest van de wereld doet...

===

Intussen mijn iKVM weer gerepareerd (Windows 7 PE en een SOC flash utility doen wonderen...) zonder hulp van Tyan, want die zijn traag... Net Illumian geinstalleerd, JA ik wil DHCP, en na boot, NEE ik heb geen IP...

Begint goed...

ifconfig: e1000g0: wait timed out, operation still pending...

leuk...

-> ZFSguru

[ Voor 132% gewijzigd door FireDrunk op 12-04-2012 20:37 ]

[Pixeltje]

FireDrunk; het uiteindelijke probleem had niets met die rechten te maken.. in één van de configbestanden was ik een spatie vergeten. Waar dit had moeten staan:

code:

"-c /mnt/tank/blabla"

stond

code:

"-c/mnt/tank/blabla"

Let op de ontbrekende spatie tussen "-c en /mnt...

[ItsValium]

Vandaag mijn eerste probleem(pje) opgelost op één van mijn productiedozen met Nexenta erop.

Mailtje gekregen dat een disk checksum errors vertoonde. Even een cold-spare die ik op het schap had liggen in de hand en naar het datacenter gereden. Daar aangekomen (5 min. later, handig als je dicht woont) de falende disk offline gezet, detach, eruit, nieuwe disk in de tray gevezen, in de server, inloggen en volgende commando :

nmc:/$ setup volume <volumename> attach-lun.

en voila, boel draait weer met status online en een dikke 1,5 tb is geresilvered op 20 minuutjes.

Toch wel nice dat ZFS

[blobber]

Ik wil een user activeren in samba via de webinterface, maar zfsguru klaagt dat het wachtwoord alleen uit alfanumerieke tekens kan bestaan.Is dit te omzeilen?Ik wil graag een wat veiliger wachtwoord instellen.
Ik heb het geprobeerd met su smbpasswd, maar ik krijg een foutmelding dat het commando niet herkend wordt.

[Verwijderd]

# wachtwoord bestaande Samba-gebruiker aanpassen
smbpasswd <username>

# nieuwe gebruikersaccount toevoegen aan Samba met wachtwoord
smbpasswd -a <username>

Je moet als root ingelogd zijn. En als je veilig wilt raad ik je aan de pf firewall te activeren. man pf.conf en man pf.

[ Voor 18% gewijzigd door Verwijderd op 14-04-2012 22:08 ]

[blobber]

Thanks, ik ga dat maandag proberen

[Pantagruel]

Zoals ik eerder vermelde ben ik aan het spelen gegaan met OpenIndiana. Op zich was het werkend krijgen van SRP onder OI geen al te groot probleem, de pech was wel dat het leek alsof er een ca. 500 MB/sec write plafond was vanaf de Win 7 x64 machine.
Een hint op een andere forum was dat er wellicht meer te halen was als Linux toegang op de SRP target zou krijgen en er meerdere dd draadjes tegelijkertijd zouden schrijven of lezen. Aangezien Win 7 geen MPIO doet (Win 2008 wel, maar die heb ik niet om handen) leek dat een zinnige opmerking.

Dus, een extra test bakje bij elkaar gescharreld (Asus M3A, AMD 64 X2 5000+ BE, 4 Gig RAM), Ubuntu 11.10 erop en de linux SRP initiator een zwengel gegeven. Een beetje file editing en info verschaffing later werkte de boel. De pech was wel dat een RAMdisk van 2 Gib een beetje klein aanvoelde om met 8 threads te benaderen, 4 Gig voelde veel beter aan.
OI is op dat gebied een eigenheimer en staat standaard toe om max. 25% van het fysiek aanwezige geheugen tot RAMdisk om te zetten. Na wat zoeken en de Solaris manual na lezen bleek daar wel een mouw aan te passen en middels wat config editing kun je de standaard 25% ophogen tot een waarde die beter bij je past.

Aan de linux kant melde dmesg de vondst van een nieuw device, een rondje fdisk, mkfs en mount later was er een SRP storage brokje bij en kon de lol beginnen.

Write testing:
Een dd thread:
dd if=/dev/zero of=/SRP/file1.img bs=450M count=1 &

1+0 records in
1+0 records out
471859200 bytes (472 MB) copied, 1.35134 s, 349 MB/s

Twee dd threads:

1+0 records in
1+0 records out
471859200 bytes (472 MB) copied, 1.62561 s, 290 MB/s
1+0 records in
1+0 records out
471859200 bytes (472 MB) copied, 1.64829 s, 286 MB/s
——————
som: 576 MB/s

Vier dd threads:
1+0 records in
1+0 records out
471859200 bytes (472 MB) copied, 4.68419 s, 101 MB/s
1+0 records in
1+0 records out
471859200 bytes (472 MB) copied, 4.69119 s, 101 MB/s
1+0 records in
1+0 records out
471859200 bytes (472 MB) copied, 4.89475 s, 96.4 MB/s
1+0 records in
1+0 records out
471859200 bytes (472 MB) copied, 4.90767 s, 96.1 MB/s
——————
som: 394.5 MB/s

Acht dd threads: ca. 340 MB/s.

Dus Linux schrijft min of meer net zo snel op t SRP target als windows kan, meerdere instanties van dd veranderen daar weinig aan . Toch een glazen plafond voor OI van zo'n 550 to 600 MB/sec.

Read tests waren echt interresant.

Een dd thread:

dd if=/SRP/file1.img of=/dev/null bs=1M
450+0 records in
450+0 records out
471859200 bytes (472 MB) copied, 0.5343 s, 883 MB/s

Acht dd threads:

450+0 records in
450+0 records out

471859200 bytes (472 MB) copied, 1.91815 s, 246 MB/s
471859200 bytes (472 MB) copied, 2.03162 s, 232 MB/s
471859200 bytes (472 MB) copied, 2.03728 s, 232 MB/s
471859200 bytes (472 MB) copied, 2.09143 s, 226 MB/s
471859200 bytes (472 MB) copied, 2.11844 s, 223 MB/s
471859200 bytes (472 MB) copied, 2.13628 s, 221 MB/s
471859200 bytes (472 MB) copied, 2.15088 s, 219 MB/s
471859200 bytes (472 MB) copied, 2.14709 s, 220 MB/s
——————
som: 1819 MB/s

Onder de streep: Meerdere dd reads toucheren het theoretische maximum van de 20 Gbit max die staat voor de MHEA28-XTC /MHEA28-2TC IB HCA’s in gebruik.

Dus, ja de laatste 'bench' is voldoende reden voor vreugde en 500 a 600MB/sec schrijfsnelheid is ook niet niks. Maar toch voelt het aan alsof de resteren 1.25 GB/sec onbenut blijft en dat is jammer.

OpenIndiana test bak: GA-EX38-DQ6, E7400, 8 Gig RAM, mhea28-2tc IB HCA.

[FireDrunk]

Mooie snelheden! Ik vond het zelf veel werk om al die packages(ubuntu) goed te krijgen en voordat alles werkte.
Heb jij daar ook veel moeite mee gehad?

[magistus]

Ugh, deze week redelijk gebeten door (ik vermoed) fragmentatie. In eerste instantie lag de verdenking bij 1 van de 4 disks in mijn raidz1 pool waarop ik hoge latency zag (60ms+ tov max 13ms bij de andere 3). Deze disk uit mijn vdev gemikt, begon een andere disk dezelfde symptomen te vertonen. Wtf?
Waar oorspronkelijk het slechtste resultaat ongeveer als volgt was:
read: 519 MB/s
write: 292 MB/s

Behaalde ik nu in het beste geval:
read: 51 MB/s
write: 14 MB/s

Hmm, bad, mkay?

Mijn datasets dus maar naar mijn archiefpool (zfs send / receive werkt gelukkig inmiddels prima onder zfsonlinux ) gemikt en de pool opnieuw aangemaakt. Wederom een paar keer getest en de performance was weer als vanouds. Met rsync de data weer terug gemikt en het lijkt nu allemaal weer heel fatsoenlijk te performen. Hier een +1 voor de Block Pointer Rewrite functie in ieder geval... en nu maar een ander plekje zoeken voor mijn backuppc datadir

@Cipher/FireDrunk: fragmentatie (en gebrek aan defrag-opties/BPR) is nog wel een potentieel nadeel voor in de FP?

[ Voor 3% gewijzigd door magistus op 15-04-2012 15:49 . Reden: FireDrunk had het niet over de zfsonlinux packages :p ]

[FireDrunk]

Onder Ubuntu had ik ook problemen, maar ik kan me even meer herinneren wat, maar onder CentOS:
Infiniband werkte niet out of the box, ik had nog een aantal packages nodig om OpenSM aan de praat te krijgen.
Toen ik dat eenmaal had, wilde de IB versie in de Yum repository niet samenwerken met OpenSM, en heb ik dus het complete IFEB package geinstalleerd (en dus gerecompiled) en toen werkte er wel een aantal dingen (OpenSM). Maar om daarna IP-over-IB aan de praat te krijgen, moest ik toch wel wat dingen handmatig instellen.

Intussen yum remove libib* gedaan, dus kan niet echt meer verder
Op een regenachtige zaterdag kijk ik er nog wel een keer naar.

[Pantagruel]

FireDrunk schreef op zondag 15 april 2012 @ 15:41:
Onder Ubuntu had ik ook problemen, maar ik kan me even meer herinneren wat, maar onder CentOS:
Infiniband werkte niet out of the box, ik had nog een aantal packages nodig om OpenSM aan de praat te krijgen.
Toen ik dat eenmaal had, wilde de IB versie in de Yum repository niet samenwerken met OpenSM, en heb ik dus het complete IFEB package geinstalleerd (en dus gerecompiled) en toen werkte er wel een aantal dingen (OpenSM). Maar om daarna IP-over-IB aan de praat te krijgen, moest ik toch wel wat dingen handmatig instellen.

Intussen yum remove libib* gedaan, dus kan niet echt meer verder
Op een regenachtige zaterdag kijk ik er nog wel een keer naar.

Op zich was het geen raket wetenschap.
Voor een root shell, zodat je niet iedere keer 'sudo' hoeft te tikken

Bash:

sudo bash 
apt-get update
apt-get upgrade

/etc/modules onder handen nemen en de volgende modules toevoegen:

ib_sa
ib_cm
ib_umad
ib_addr
ib_uverbs
ib_ipoib
ib_ipath
ib_qib
ib_srpt

Om de subnetmanager te installeren:

Bash:

apt-get install opensm 

Vervolgens /etc/network/interfaces aanpassen:

auto ib0
iface ib0 inet static
address 10.10.0.40
netmask 255.255.255.0

Na een reboot worden alle relevante infiniband toevoegingen in /sys gemaakt, de ipoib modules geladen, en de infiniband poort met een ip adres in de lucht gebracht.

Vlgs t blog van David Hunt geeft connected mode een betere doorvoersnelheid dan IpoIB sec.
Om connected mode te krijgen run je als root vanuit de shell:

Bash:

echo connected >`find /sys -name mode | grep ib0`
echo 65520 >`find /sys -name mtu | grep ib0`

Makkelijker is het om het meteen bij t opstarten van ib interface te laten doen, daarvoor voeg je het geheel op de volgende manier toe aan /etc/network/interfaces:

auto ib0
iface ib0 inet static
address 10.10.0.40
netmask 255.255.255.0
up echo connected >`find /sys -name mode | grep ib0`
up echo 65520 >`find /sys -name mtu | grep ib0`

Voor het opzetten van een SRP target verwijs ik naar David Hunt's blog .

Het heeft mij meer tijd en moeite gekost om een grotere RAMdisk onder OpenIndiana voor elkaar te krijgen en deze op de juiste manier aanbieden. Van de ramdisk sec kun je een SRP-lun maken maar dat liep stuk op toegangsrechten. Uiteindelijk van de ramdisk een zfs pool gemaakt en dan een zero file in deze pool als SRP-lun presenteren (geen idee of een vdev of een zfs folder ook werkt).

(Ik zal later controleren of ik t bij t juiste eind heb, de tekst is uit t blote hoofd, kan zijn dat ik iets vergeten ben)

En ja, de snelheden van en naar het RAMdisk SRP-target op de OpenIndiana test bak is niet kinderachtig. Maar mocht OI toch een write plafond hebben dan blijft t jammer, om Jim Carrey te quoten "So much horse power,.. and nowhere to gallop'.

Om uit te sluiten of de MHEA28-2TC IB HCA ( degene met geheugen) stiekem toch niet beperkend is (zou me verbazen) zou ik deze ook in een linux bak moeten testen. In de eerdere tests met een MHEA28-XTC HCA in een linux bak was deze in ieder geval niet beperkend en waren lees- en schrijfsnelheid gelijkwaardig.

Een andere factor zou de IB driver van OpenIndiana kunnen zijn. Ik heb eerlijk gezegd geen idee of die driver ontwikkeling nog plaatsvindt sinds het ter ziele gaan van OpenSolaris.

Update:
Een verse Ubuntu 11.10 installatie en wat infiniband gefrunnik verder is er uitsluitsel over eventuele beperkingen die de MHEA28-2TC zou kunnen geven tov de eerder gebruikte MHEA28-XTC uit de wereld geholpen.

Een atto bench van een 4 Gig RAMdisk als SRP target gepresenteerd:



Conlusie:
De MHEA28-2TC doet niets onder voor de eerder gebruikte MHEA28-XTC (zoals ik al verwachte) en zet dezelfde +900 MB/sec neer. Het lijkt er dus op dat OpenIndiana inderdaad de schrijfsnelheid beperkt tot zo'n ca. 550MB/sec.

[ Voor 7% gewijzigd door Pantagruel op 15-04-2012 23:22 . Reden: Update ]

[Splendid]

Even een vraagje wat niet direct met ZFS te maken heeft maar wel indirect omdat het met opensolaris (Nexenta) te maken heeft. Ik heb nogal moeite om ftp users correct en gemakkelijk te beheren. Dit gaat nogal omslachtig, als het al lukt.

Nu vroeg ik mij af of jullie hiervoor nog aparte software gebruiken om ftp, email server, hosting e.d. beheren? Ik kan echt niks vinden wat op nexenta draait...

[ItsValium]

@ splendid, je kan altijd een ftp server draaien die dan zijn gedeelde mappen op een nexenta bak geeft staan (via NFS/CIFS/iSCSI) dan kan je met bijvoorbeeld filezilla alle gebruikersbeheer doen voor de ftp kant van de zaken.

[blobber]

Verwijderd schreef op zaterdag 14 april 2012 @ 22:07:
# wachtwoord bestaande Samba-gebruiker aanpassen
smbpasswd <username>

# nieuwe gebruikersaccount toevoegen aan Samba met wachtwoord
smbpasswd -a <username>

Je moet als root ingelogd zijn. En als je veilig wilt raad ik je aan de pf firewall te activeren. man pf.conf en man pf.

Ik bleef aanvankelijk de foutmelding krijgen dat smbpasswd niet herkend werd als commando.(ingelogd als root)
De smb* commands staan in /usr/local/bin Ik heb ze naar /bin gekopieerd en nu werkt het .Daarna heb ik ze weer uit /bin gehaald, want ik weet niet of het kwaad kan.
Dat pf moet ik me eerst in verdiepen, ik heb de indruk dat ik maar een heel klein gedeelte nodig heb van al die opties

[CurlyMo]

In plaats van executables te verplaatsen van de ene naar de andere plek, kan je er beter symlinks van maken ln -s /usr/local/bin/smpasswd /bin/smbpasswd

[Verwijderd]

Dat moet je écht niet doen hoor! Blijf af van die files! Verwijder de bestanden in /bin!

Als jij bestanden in /usr/local/bin niet kan uitvoeren, dan heb je een foute PATH in je login script (.profile). Corrigeer dat ipv programma-bestanden te kopiëren; dat doe je onder Windows maar normaliter NOOIT onder Linux/UNIX.

[blobber]

CurlyMo schreef op dinsdag 17 april 2012 @ 16:11:
In plaats van executables te verplaatsen van de ene naar de andere plek, kan je er beter symlinks van maken ln -s /usr/local/bin/smpasswd /bin/smbpasswd

Goed dat je het zegt, zal ik voortaan doen

Verwijderd schreef op dinsdag 17 april 2012 @ 16:20:
Dat moet je écht niet doen hoor! Blijf af van die files! Verwijder de bestanden in /bin!
Als jij bestanden in /usr/local/bin niet kan uitvoeren, dan heb je een foute PATH in je login script (.profile). Corrigeer dat ipv programma-bestanden te kopiëren; dat doe je onder Windows maar normaliter NOOIT onder Linux/UNIX.

Ik had ze al weggegooid, zal het PATH aanpassen, dan zijn die symlinks ook niet nodig.
_{Ja, dat was een beetje lompe actie, hoop dat Ciphers bloeddruk weer wat gedaald is}

[ Voor 50% gewijzigd door blobber op 08-03-2013 15:17 ]

[Verwijderd]

Het vervelende van kopiëren van files is dat je daar gezeik mee kunt krijgen bij updaten, in sommige gevallen. Dus ik raad het sterk af om daarmee te prutsen.

Met een goede PATH in je .profile (/.profile en /home/<username>/.profile en /root/.profile) zou je geen problemen moeten ondervinden. Je moet waarschijnlijk wel opnieuw inloggen om die PATH actief te laten worden.

[webfreakz.nl]

meuk: FreeBSD 8.3 --> http://www.freebsd.org/releases/8.3R/relnotes-detailed.html :

The FreeBSD ZFS subsystem has been updated to the SPA (Storage Pool Allocator, also known as zpool) version 28. It now supports data deduplication, triple parity RAIDZ (raidz3), snapshot holds, log device removal, zfs diff, zpool split, zpool import -F, and read-only zpool import.[r222741]

[Verwijderd]

Ja, dat zat dus al héél lang in 8-STABLE wat veel mensen dan ook draaide. Nu dus ook een release; verder niet zoveel spannends. Nu kun je 9.0 draaien wat je als thuisgebruiker waarschijnlijk wel wilt, door o.a. lager energieverbruik in idle versus FreeBSD 8.x.

[RudolfR]

Ik draai 0.2.0-beta5 in een VM onder ESXi 4.1.
Werkt prima, maar ik wil een NFS share voor XBMC.
Een filesystem sharen met NFS is een fluitje van een cent; op een ubuntu systeem kan ik de shares zien, mounten, lezen en schrijven.
Ik wil de share ook kunnen benaderen vanaf een ATV; direct vanuit XBMC, zonder de schijf in het onderliggende OS te mounten, maar dat lukt niet echt.

Hier staat uitgelegd hoe het zou moeten kunnen voor o.a. FreeNAS.
http://wiki.xbmc.org/index.php?title=NFS

Maar ik krijg dat niet vertaald naar ZFSGuru, deze regels verschijnen in de log:
Apr 25 19:57:33 zfsguru mountd[943]: mount request from 192.168.1.145 from unprivileged port

En deze bij xbmc:
20:38:37 T:90198016 ERROR: NFS: Failed to mount nfs share: /tank/media (mount/mnt call failed with "RPC Packet not accepted by the server")

Dit staat in m'n rc.conf bij NFS:

code:

nfs_server_enable="YES"
mountd_enable="YES"
mountd_flag="-r -u -t -n 4 -N"
rpcbind_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
nfs_reserved_port_only="NO"

Maar ik zie die commandline parameters voor mountd nergens terug.
Output van ps aux:
/usr/sbin/mountd -r /etc/exports /etc/zfs/exports

Iemand tips?

[ Voor 17% gewijzigd door RudolfR op 27-04-2012 09:47 ]

[Verwijderd]

This section addresses some specific issues to bear in mind if you are using FreeNAS 7.x (aka. legacy) installations.

ZFSguru is gebaseerd op FreeBSD 9 en FreeBSD 10, niet op FreeBSD 7. Gebruik dus geen ouderwetse NFS server maar de nieuwe ZFS NFS server die ook NFS versie 4 ondersteunt.

ZFSguru heeft NFS al ingeschakeld, dus alles wat je had hoeven doen is op 'Share with NFS' te klikken, en je XBMC zou hem moeten kunnen mounten; immers Linux kan hem ook mounten dus waarom XBMC dan niet? Je zult aan de client kant moeten rommelen; niet aan de server kant.

[RudolfR]

Volgens ZFSguru mount ik van unprivileged ports (> 1024), dat klopt van op de ATV ben ik geen root user.
Dit kan ik ook niet doen, dus ik denk dat ik serverside moet instellen dat dit toegestaan is.

Dit kan meestal door optie 'insecure' toe te voegen in de /etc/exports file.
Heb ik nu toegevoegd aan het commando bij het sharen via de webinterface en dit komt mee naar:
/etc/zfs/exports

/sbin/zfs set sharenfs="on insecure" tank/media
/sbin/zfs set sharenfs="on,insecure" tank/media
/sbin/zfs set sharenfs="on;insecure" tank/media

maar dat resulteert in niet zichtbare shares.

[FireDrunk]

Je kunt eens showmount uitvoeren op de host, dan krijg je te zien hoe de huidige NFS shares gepublished worden.

Showmount is overigens voor regular NFS, geen idee of dat ook werkt voor ZFS' NFS server...

[RudolfR]

[root@zfsguru /home/ssh]# showmount -e localhost
Exports list on localhost:
/tank/media Everyone

root@ubuntu-server-esxi:/mnt# showmount -e zfsguru
Export list for zfsguru:
/tank/media (everyone)

Daar zie ik geen verschil met een share op een server die wel werkt:
root@ubuntu-server-esxi:/mnt# showmount -e openwrt
Export list for openwrt:
/mnt/sda1/users/public/series *
/mnt/sda1/users/public/movies *
/mnt/sda1/users/public *

Maar daar staat dit in de exports file:
/mnt/sda1/users/public *(rw,all_squash,insecure,no_subtree_check)
/mnt/sda1/users/public/movies *(rw,all_squash,insecure,no_subtree_check)
/mnt/sda1/users/public/series *(rw,all_squash,insecure,no_subtree_check)

[FireDrunk]

all_squash en insecure zijn nou niet echt ZFS standaard settings volgens mij...

[RudolfR]

Goed punt, de implementatie van share_nfs onder ZFS is net ff anders.

http://wwwcgi.rdg.ac.uk:8...4/poplog/man/1M/share_nfs

Maar iets wat vergelijkbaar is met 'insecure' vind ik niet.

[Verwijderd]

Enige wat ik heb kunnen vinden is:
nfs_reserved_port_only="NO" # Provide NFS only on secure port (or NO).

Maar die staat standaard dus al uitgeschakeld. Je kunt wel proberen de oude NFS server te gebruiken, door dit toe te voegen aan je /etc/rc.conf en te rebooten:
oldnfs_server_enable="YES"

Verder hoor je nooit /etc/exports of /etc/zfs/exports handmatig aan te passen! Gebruik altijd de zfs set sharenfs="" <fs> commando. Normaliter gebruik je daarbij opties zoals "-alldirs -network 10.0.0.50 -maproot=root". Dus opties beginnen met een streepje, tenzij je gewoon "on" gebruikt dat is een shortcut.

Kort overzicht van de opties:
-alldirs = je mag ook subdirectories proberen te mounten, dus als je /tank/share deelt mag je client ook /tank/share/dir mounten
-network 10.0.0.0/24 = IP range of IP adres wat toegang heeft tot deze share. niet heel veilig natuurlijk, maar het is iets van bescherming.
-maproot=root = de client mag files met 'root' UID en GID aanmaken

[RudolfR]

Bedankt, ik ga nog ff wat proberen.

Dit helpt misschien ook:
http://forum.xbmc.org/showthread.php?tid=91776&page=6

[Dadona]

Verwijderd schreef op vrijdag 27 april 2012 @ 13:12:
Verder hoor je nooit /etc/exports of /etc/zfs/exports handmatig aan te passen! Gebruik altijd de zfs set sharenfs="" <fs> commando. Normaliter gebruik je daarbij opties zoals "-alldirs -network 10.0.0.50 -maproot=root". Dus opties beginnen met een streepje, tenzij je gewoon "on" gebruikt dat is een shortcut.

Daar kom je nu mee... Ik gebruik NFS alleen momenteel toch niet omdat ik problemen heb met file locking. Soms mis ik echt iets waardoor ik weet dat wat ik doe ook de goede manier is, niet alleen dat het een manier is die werkt. Het is gelijk ook het nadeel van het 'leren' middels zoekmachines, blogposts of individuele reacties blijven vaak wat op de vlakte en krijgen lang niet altijd de noodzakelijke follow-up.

[RudolfR]

Dacht even dat ik het gevonden had op http://www.daemon-systems.org/man/exports.5.html
daar wordt gesproken over -noresvport en -noresvmnt, maar dat blijkt NetBSD specifiek (FreeBSD heeft 't niet)

Maar nu heb ik 't toch voor elkaar met de '-n' parameter voor mountd.
In /etc/rc.d/mountd kom ik wel if-else paden tegen die '-n' toevoegen, maar hoe kan ik die configureren?
Edit: misschien gewoon alleen -n toevoegen in rc.conf... werkt niet.

Dit werkt wel: weak_mountd_authentication="YES"

-alldirs heeft geen toevoegde waarde voor xbmc, maar klinkt wel handig, ga ik nog ff testen.

[ Voor 11% gewijzigd door RudolfR op 27-04-2012 21:21 ]

[Graviton12]

Toevallig iemand die weet wanneer het 2de deel van ZFS review door Femme eraan komt?

[Dadona]

Tijd voor onderzoek...
End-to-end Data Integrity for File Systems: A ZFS Case Study

[EnerQi]

Dadona schreef op zondag 29 april 2012 @ 20:11:
Tijd voor onderzoek...
End-to-end Data Integrity for File Systems: A ZFS Case Study

Je durft straks niet meer een pc te bouwen wegens mogelijk errors. Het zal altijd een afwezig zijn tussen risico en kosten.

Wat zou eigenlijk 'DE' ZFS nas kunnen worden die zoveel mogelijk van dit soort problemen afvangt?

[analog_]

Eentje met Chipkill geheugen zoals aangegeven in de studie. Normaal ECC geheugen vangt 94% van de fouten op, Chipkill gaat nog verder maar foutloos is met het huidige ontwerp dus niet mogelijk. Hopelijk wordt ZFS gecorrigeerd hiervoor. Uiteindelijk kan je CPU cache ook bitrot vertonen en zijn er ook nog problemen met opslag protocollen á la NFS, SMB , ... waar nog corruptie kan optreden maar dat valt buiten de scope.

[ Voor 40% gewijzigd door analog_ op 30-04-2012 13:45 ]

[Nielsjuhz]

Hey ik had even een vraagje.

Ik zit zelf nu een leuk systeempje voor te bereiden voor een zfs datastore en een aparte vm.
Liefst zo energie zuinig natuurlijk

Maar ik had ook iets gelezen over SSD caching dat het de preformens ook kan opschroeven.
Maar kan ik dat vervangen voor de geheugen.

Dat ik ipv. 16gb ddr3 geheugen voor de ZFS
maar 2gb erin zet voor de os en de 64gb ssd als cache gebruik voor de zfs.

Zou dit ongeveer de zelfde preformence halen of is er echt echt veel geheugen nodig en is de ssd alleen als toevoeging.?

Samengevat. Kan ik het geheugen praktisch weglaten en een SSD in de plaats gooien als cache schrijf zonder echte preformence verlies?

[FireDrunk]

2GB is dan weer echt heel weinig. RAM is veel beter voor caching dan een SSD. Een SSD mag dan wel goedkoper zijn, maar je wil niet onder de 6GB ram komen in het geval van ZFS.

[Verwijderd]

@Nielsjuhz: nee, dat werkt zo niet. Voor L2ARC (SSD cache) heb je juist extra RAM nodig voor de L2ARC tabellen. Dat kan oplopen tot meerdere gigabytes als de cache goed gebruikt wordt, maar zal normaliter kleiner zijn. Veel RAM is juist wat je moet hebben; 2x8GiB=16GiB kun je in een Brazos servertje stoppen voor weinig geld (90 euro).

L2ARC caching is leuk voor een grote RAID-Z met lage rpm hardeschijven, die heel goede sequential I/O hebben, maar random reads met name een probleem zijn. Daar gebruik je dan de L2ARC cache voor, door een SSD als cache device toe te voegen aan de pool. Dit werkt ongeveer zoals Intel SRT (Windows SSD caching) maar dan veel beter, omdat corruptie op je SSD niet wordt doorgegeven aan de applicatie; bij corruptie wordt simpelweg van je RAID-Z gelezen. L2ARC is dus veilig om te gebruiken.

Je kunt een SSD ook voor meerdere dingen gebruiken, zoals:

• partitie 40GB L2ARC cache voor RAID-Z pool met hardeschijven
• partitie 40GB zfs pool 'ssd' voor opslag van VM files en andere random IOps intensieve opslag.
• ongebruikte ruimte uitgaande van 128GB SSD: ~35GiB, je kunt altijd je partitie groter maken en dus meer opslag aan je SSD pool geven achteraf.

Dadona schreef op vrijdag 27 april 2012 @ 14:08:
Daar kom je nu mee...

Wat vertel ik daar wat je nog niet wist?

Dadona schreef op zondag 29 april 2012 @ 20:11:
Tijd voor onderzoek...
End-to-end Data Integrity for File Systems: A ZFS Case Study

Interessant, en een beetje teleurstellend wat betreft RAM integrity. Toch ga ik dat zelf ook nog eens testen. Ik heb fout RAM hier liggen wat zeker voor corruptie zorgt (honderden errors per seconde in memtest). Mijn ervaring was namelijk dat corruptie door RAM wel plaatsvindt, maar bij een scrub die corruptie weer wordt gecorrigeerd. Toch wil je RAM corruptie kunnen uitsluiten; ofwel door ECC met verify, ofwel door een 'enhanced ZFS' die ook RAM-corruptie kan tegengaan.

Toch is dat probleem minder ernstig dan bad sectors of andersoortige corruptie op de disks; daar werkt ZFS heel goed tegen en dat is vrij uniek. Vooralsnog maakt dat ZFS één van de meest veilige filesystems bereikbaar voor gebruikers die betrouwbare opslag wensen. Als er over 5 jaar iets beters komt, stap ik zo over. Maar iets zegt mij dat ZFS zo gek nog niet is voor een vrij lange tijd. Hopelijk worden nog wel wat features toegevoegd zoals het uitbreiden van RAID-Z enzovoort. Als dat soort scherpe punten eruit gehaald worden, kan ZFS best een goed lange termijn filesystem worden, welke net als FAT32 en NTFS nog lang compatibiliteit kunnen genieten op toekomstige platforms. Althans zo is mijn verwachting.

[Goderic]

Is er eigenlijk een mogelijkheid om de ZFS ARC te behouden na een reboot?
Naar wat in tot nu toe gelezen heb is de ARC zo gemaakt dat hij pas "hot" is na een heel aantal uren, perfect voor een server die 24/7 aanstaat, maar nogal jammer voor een laptop of desktop die elke dag uitgaat.

[Ultraman]

Desktop of laptop niet uitschakelen maar suspenden zou ik zeggen.

[matty___]

Goderic schreef op dinsdag 01 mei 2012 @ 21:04:
Is er eigenlijk een mogelijkheid om de ZFS ARC te behouden na een reboot?
Naar wat in tot nu toe gelezen heb is de ARC zo gemaakt dat hij pas "hot" is na een heel aantal uren, perfect voor een server die 24/7 aanstaat, maar nogal jammer voor een laptop of desktop die elke dag uitgaat.

Dan is die de eerste keer dat je iets start misschien langzamer maar de 2de keer niet meer. Zie het probleem er niet zo van.

[FireDrunk]

Dat geld voor Standby to RAM, maar niet voor Standby to Disk. Elke implementatie die ik ken, dumpt alle overbodige RAM informatie om de tijd en diskspace die het kost om te suspenden te minimaliseren.
Denk vooral aan caches en er word vaak iets van ballooning gebruikt.

[Verwijderd]

Net even getest onder Windows; voor de Suspend-to-Disk had ik 6000MB cached en nu 6900MB, dus juist meer filecache nog.

Waarom zou hibernaten anders langer duren met veel RAM? Het is niet alsof je applicaties automatisch meer RAM gaan verbruiken.

[Goderic]

matty___ schreef op dinsdag 01 mei 2012 @ 21:19:
[...]

Dan is die de eerste keer dat je iets start misschien langzamer maar de 2de keer niet meer. Zie het probleem er niet zo van.

Het probleem is net dat ZFS ARC niet zo werkt. ZFS ARC is zo gebouwd dat de cache traag opbouwt en niet zo snel veranderd zodat over lange tijd de meest gebruikte dingen er in komen te staan.
Je applicaties zullen dus niet sneller starten nadat je ze de 2e keer start, maar pas nadat je ze de 25e keer in 10 uur gestart hebt (ik zeg maar wat), wat voor een laptop of desktop dus niet zo handig is.

Aan suspend to ram/disk heb ik gedacht, maar om de een of andere reden schakel ik mijn computer liefst toch gewoon uit. (Dat komt oa doordat in mijn Linux ervaring er toch altijd wel iets mis is als je herstart na een suspend, als suspend überhaupt al werkt.)

[FireDrunk]

Verwijderd schreef op dinsdag 01 mei 2012 @ 21:28:
Net even getest onder Windows; voor de Suspend-to-Disk had ik 6000MB cached en nu 6900MB, dus juist meer filecache nog.

Waarom zou hibernaten anders langer duren met veel RAM? Het is niet alsof je applicaties automatisch meer RAM gaan verbruiken.

Het gaat juist om de hibernate tijd. XP hibernate erg traag omdat het alles naar disk zet (je hiberfil.sys is ook gewoon de grootte van je RAM). Onder Windows 7 is dat volgens mij wel minder... Ik moet er niet aan denken dat elke keer als ik hibernate er 16GB naar mijn SSD geschreven word... (Een van de vele redenen waarom ik gewoon boot, en niet hibernate )

Dat je filecache zelfs meer is vind ik erg vreemd... Waar zou je OS dat vandaan moeten halen

===

Ik heb het nog even na zitten lezen, maar de snelheidswinst zit hem dus blijkbaar niet in het droppen van caches, maar in compressie. Hoe dat het verhaal sneller maakt vind ik nog altijd knap. Ik zie dat Linux wat vaker een drop van de caches doet, maar ook daar is het distributie afhankelijk.

[ Voor 15% gewijzigd door FireDrunk op 02-05-2012 09:31 ]

[matty___]

Goderic schreef op dinsdag 01 mei 2012 @ 22:01:
[...]

Het probleem is net dat ZFS ARC niet zo werkt. ZFS ARC is zo gebouwd dat de cache traag opbouwt en niet zo snel veranderd zodat over lange tijd de meest gebruikte dingen er in komen te staan.
Je applicaties zullen dus niet sneller starten nadat je ze de 2e keer start, maar pas nadat je ze de 25e keer in 10 uur gestart hebt (ik zeg maar wat), wat voor een laptop of desktop dus niet zo handig is.

Aan suspend to ram/disk heb ik gedacht, maar om de een of andere reden schakel ik mijn computer liefst toch gewoon uit. (Dat komt oa doordat in mijn Linux ervaring er toch altijd wel iets mis is als je herstart na een suspend, als suspend überhaupt al werkt.)

Dat idee heb ik niet. Ik heb een ZFS NAS voor series en films. als ik een tv serie a 500mb heb gedownload en ik met zpool iostat kijk dan zie ik dat op het moment dat alles binnen is en unrar gaat uitpakken er geen leesacties plaats vinden omdat alles uit de cache komt.
Dit doet mij vermoeden dat het met applicaties hetzelfde werkt.

[FireDrunk]

Dat is onder alle (niet uit het stenen tijdperk stammende) operating systems zo, dat is 'gewoon' filesystem cache. ARC is veel slimmer.

Tasks: 506 total,   1 running, 505 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.4%sy,  0.0%ni, 98.7%id,  0.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  12132252k total, 11980616k used,   151636k free,     8036k buffers
Swap:  3926008k total,    45892k used,  3880116k free,  9746720k cached

Met andere woorden, ik heb 9GB in mijn RAM cache staan...

[ Voor 58% gewijzigd door FireDrunk op 02-05-2012 10:04 ]

[matty___]

FireDrunk schreef op woensdag 02 mei 2012 @ 09:34:
Dat is onder alle (niet uit het stenen tijdperk stammende) operating systems zo, dat is 'gewoon' filesystem cache. ARC is veel slimmer.

Tasks: 506 total,   1 running, 505 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.4%sy,  0.0%ni, 98.7%id,  0.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  12132252k total, 11980616k used,   151636k free,     8036k buffers
Swap:  3926008k total,    45892k used,  3880116k free,  9746720k cached

Met andere woorden, ik heb 9GB in mijn RAM cache staan...

een normaal FS cached geen 9GB
Maar leg even uit waarom de ARC zo veel slimmer is. Want om even terug te gaan naar de desktop. als je firefox opent en daar na nog een keer zal dat uit de ARC komen.

[ Voor 11% gewijzigd door matty___ op 02-05-2012 11:31 ]

[Verwijderd]

Normale filesystems zoals onder Windows, Linux en UNIX cachen alles wat ze kunnen cachen. Als je RAM 32GB is, en je hebt 30GB vrij, en je leest een 60GB bestand. Dan staat de laatste 30GB van dat bestand in het RAM-geheugen. De 'Cached' waarde in task manager zal heel groot zijn, 'Free' slechts onder de 100MB.

Kortom, normaal werkt caching zo dat al je vrije RAM wordt gebruikt. Als RAM nodig is voor applicaties, wordt een deel van de filecache gewoon weggedonderd. Beschikbaar geheugen is dus Free + Cached RAM.

ZFS is anders omdat het niet alleen 'Most Recently Accessed' data cached, maar vooral ook 'Most Frequently Requested'. ZFS houdt dus twee aparte caches van elkaar gescheiden. Zo kan een groot bestand wat je inleest niet gelijk je filecache overschrijven, en zo nuttige caches verdrijven. Door deze caches gescheiden te houden, bereik je een effect waarbij ZFS beter kan cachen als de server aan blijft staan, en het gedrag van jou als gebruiker wordt benut om de juiste data te cachen.

[FireDrunk]

What he says ^^ .

Een 'normaal' FS cached *juist* 9GB. Maar vaak zoals CiPHER zegt, de laatste 9GB. En daar zit juist het probleem. Als je dus een fileserver hebt onder Linux, waar je ook een iSCSI volume op hebt staan en je leest een film in van 40GB dan is alles wat gecached was voor de iSCSI LUN weg. Als je dat onder ZFS doet en de iSCSI LUN word vaker geraadpleegd dan de film, blijft de iSCSI data in je ARC staan.

Dat zorgt er dus voor dat je caching veel beter werkt.

[ Voor 92% gewijzigd door FireDrunk op 02-05-2012 12:40 ]

[Nielsjuhz]

Verwijderd schreef op dinsdag 01 mei 2012 @ 20:43:
@Nielsjuhz: nee, dat werkt zo niet. Voor L2ARC (SSD cache) heb je juist extra RAM nodig voor de L2ARC tabellen. Dat kan oplopen tot meerdere gigabytes als de cache goed gebruikt wordt, maar zal normaliter kleiner zijn. Veel RAM is juist wat je moet hebben; 2x8GiB=16GiB kun je in een Brazos servertje stoppen voor weinig geld (90 euro).

L2ARC caching is leuk voor een grote RAID-Z met lage rpm hardeschijven, die heel goede sequential I/O hebben, maar random reads met name een probleem zijn. Daar gebruik je dan de L2ARC cache voor, door een SSD als cache device toe te voegen aan de pool. Dit werkt ongeveer zoals Intel SRT (Windows SSD caching) maar dan veel beter, omdat corruptie op je SSD niet wordt doorgegeven aan de applicatie; bij corruptie wordt simpelweg van je RAID-Z gelezen. L2ARC is dus veilig om te gebruiken.

Je kunt een SSD ook voor meerdere dingen gebruiken, zoals:

• partitie 40GB L2ARC cache voor RAID-Z pool met hardeschijven
• partitie 40GB zfs pool 'ssd' voor opslag van VM files en andere random IOps intensieve opslag.
• ongebruikte ruimte uitgaande van 128GB SSD: ~35GiB, je kunt altijd je partitie groter maken en dus meer opslag aan je SSD pool geven achteraf.

Oke dan is dat idee ook al van de wereld.

Maar Brados servertje met 16GB geheugen? ik heb overal gekeken en zie overal maar 2slots geheugenbanken met max 8gb geheugen. want zit zelf te kijken naar een e-350 of e-450 processortje.

Maar toch nog een vraag aangezien ik wel nieuwsartikelen voor bij heb zien komen op tweakers over cache ssd's enz. maar voor de zfs cache manier welke is nu beter dan?
Een normale SSD met SLC (heb wel gelezen dat je voor de L2ARC een SLC ssd moet hebben ipv MLC)
of zo'n Cache SSD?

En ik ben een soort van pva aan het opzetten. Misschien leuk om hier op te zetten?

[FireDrunk]

Niets *moet*, je kan best een MLC ssd nemen voor L2ARC, nadeel is alleen dat ALS je NAS echt zwaar gebruikt word, je SSD vrij snel slijt (in de orde van, 3-5 jaar meegaan ipv 10-15 jaar...) Of dat voor jou een probleem is, moet je zelf beslissen.

Als je veel RAM hebt word je SSD minder aangesproken. L1 ARC (ofwel gewoon ARC) zit in je RAM en zal altijd eerst aangesproken worden. Als dat vol is, dan word je SSD pas gevuld. 16GB is dus veel beter dan 16GB SSD.

Brazos kan trouwens 16GB aan door 2 latjes van 8GB te plaatsen.
pricewatch: GeIL Black Dragon GB316GB1333C9DC

[Nielsjuhz]

Oke dus ondanks dat het niet op de moederborden website staan kan het wel.

En oke ram dus gewoon zo groot mogelijk maken. maar de NAS/SAN wordt eigelijk alleen door mij gebruikt en door projects genoten die de VM's ook gebruiken. dus jah intensief gebruikt zal alleen door het downloaden gedaan worden maar voor de rest denk ik niet. Maar de SLC zijn toch ook sneller voor caching en was toch ook beter voor fouten tegen gaan aangezien slc 1bitje perkeer had en MLC meerdere waardoor bitjes kan kregen om corrupt te raken. zoiets staat me bij dat ik dat ergens had gelezen.

of is dat het geval van sneller slijten dat het nog maar 3jaar mee gaat ipv 10?

Eigelijk komt er gelijk ook een vraag naar boven en indirect gerelateerd met ZFS maar.

Vmware slaat zijn bestanden op in een file en die kan zo groot worden als de machine zelf is. Deze kan toch nooit in de ram telkens geladen worden. Is het daardoor misschien beter om het opslaan van de vm in split files van circa 2gb te doen.

[FireDrunk]

VMware en ZFS is een lastige combinatie waar je even goed over na moet denken. Als je even in het grote ESXi topic en hier goed zoekt op de andere term dan de topictitel (naar ZFS zoeken in het ESXi topic en naar ESX zoeken in het ZFS topic) kom je een heel eind.

Steekwoorden: RDM, VT-d, Passthrough.

[Graviton12]

FireDrunk schreef op woensdag 02 mei 2012 @ 14:21:
Niets *moet*, je kan best een MLC ssd nemen voor L2ARC, nadeel is alleen dat ALS je NAS echt zwaar gebruikt word, je SSD vrij snel slijt (in de orde van, 3-5 jaar meegaan ipv 10-15 jaar...) Of dat voor jou een probleem is, moet je zelf beslissen.

Las tijdje terug nog een artikel, een MLC 128GB SSD elke dag 52GB laten schrijven op 3 jaar komt overeen met aantal cycles waarbij ze aangeven dat het het maximum is qua levensduur.
Dit was nog rekening houdende met 3000-5000 cycles vanwege kwaliteit van MLC geheugen.

Terwijl MLC laatste nieuwe series op SLC niveau zou zitten qua cycles dus 10 000, wat, lijkt me, 6-9 jaar schrijven is vooraleer de ssd het echt 'moet' opgeven.

Heb zelf een ouwe X25 Intel, draait al 3 jaar als ik me goed herinner, TB's aan writes, scheelt nog niks mee.

[u_nix_we_all]

Nielsjuhz schreef op woensdag 02 mei 2012 @ 14:32:

Maar de SLC zijn toch ook sneller voor caching en was toch ook beter voor fouten tegen gaan aangezien slc 1bitje perkeer had en MLC meerdere waardoor bitjes kan kregen om corrupt te raken. zoiets staat me bij dat ik dat ergens had gelezen.

Ik denk dat je wat dingen door elkaar haalt m.b.t. ZFS en SSD's. Met ZFS kun je SSD's op 2 manieren gebruiken om je systeem te versnellen.
1: L2ARC. Dit is uitbreiding van je leescache door een SSD. Zoals hierboven al genoemd geen vervanging voor RAM-cache (ARC), maar een uitbreiding daarvan. Het kost zelfs extra geheugen om dit goed te gebruiken vanwege de referenties naar L2ARC die in de ARC komen te staan.
2: ZIL of LOG-device. Dit is een schrijf-cache die ervoor zorgt dat vooral random writes snel afgehandeld worden.

Voor de L2ARC volstaat elke SSD, de data die erin staat hoeft niet speciaal beschermd te worden, het staat namelijk ook al op de disks.
Voor de ZIL gelden andere regels, daar wil je (betrouwbaarder) SLC , en niet alle SSD's kunnen goed tegen stroomuitval, je wilt een model dat dat wel kan, en dan kom je terecht bij modellen met zgn. supercaps.
De data in de ZIL is belangrijk, die moet namelijk nog wel op de disk geschreven worden !

Zelf ben ik van mening dat je het best in RAM kunt investeren, dedicated L2ARC is vaak pas nuttig voor erg grote omgevingen (maar een bescheiden L2ARC partitie als je toch een SSD wilt gebruiken voor bijv. het OS is niet verkeerd), en als je echt een ZIL wilt, spaar dan door tot je er 2 in mirror kunt draaien, bij voorkeur 2 verschillende merken met verschillende controllers

[FireDrunk]

Een poos terug heeft Femme ook een paar posts geweid aan het feit dat ZIL op een NAS amper zin had, omdat in real-world scenario's je bijna geen sync writes doet. Dat gebeurt eigenlijk alleen in enterprise omgevingen (Synchrone iSCSI, Sync NFS, en dat soort dingen)

[Stefanovic45]

ZIL is toch vooral om extra snelheid te pakken? Als je een raid 5/RAIDZ opstelling hebt zou je zonder ZIL slechte schrijfperformance hebben. Dit zwakke punt van raid 5 kun je toch mooi oplossen met ZIL? Dat was mijn gedachte bij ZIL tenminste altijd

[ Voor 11% gewijzigd door Stefanovic45 op 02-05-2012 18:46 ]

[ItsValium]

@StefanvanGelder inderdaad ZIL is bedoeld om sync writes te versnellen echter komen sync-writes in thuisomgevingen niet veel voor. Heb het zelf genoeg getest, in het datacenter werken ZIL's top, in mijn thuisserver is een ZIL eigenlijk overbodig, vooral als je thuisserver uitgerust is met voldoende RAM.

[Stefanovic45]

Ja maar je RAM wordt niet gebruikt voor schrijfacties. Dan blijf je zonder ZIL ook thuis met slechte random write prestaties zitten...

[ Voor 43% gewijzigd door Stefanovic45 op 02-05-2012 18:51 ]

[ItsValium]

Toch wel, ZFS gebruikt een klein deel van de beschikbare hoeveelheid RAM als tempory write cache. Dit is wel maar een klein stuk (in de testjes die ik deed nooit meer dan 1 GB). Die wordt dan geflushed naar ZIL of de disks afhankelijk van de beschikbaarheid ervan.

Waarschijnlijk is dit ook de manier waarop ZFS een deel van de random-writes omzet naar sequentiele writes die éénder welke HD toch liever doet dan random. Maar dit is speculatie van mijn kant.

[ Voor 27% gewijzigd door ItsValium op 02-05-2012 18:54 ]

[Verwijderd]

ZFS wacht tot een transaction group vol zit of dat de timeout is bereikt; dan wordt een kleinere transaction group weggeschreven. De transaction group kan aardig groot worden; je kunt daar meerdere honderden megabytes mee bufferen. Dat heeft zoals gezegd een leuke eigenschap dat je random writes clustered en dankzij Copy-on-Write ook vrijwel sequentiëel kan wegschrijven.

De metadata-updates veroorzaken wel sync writes, wat voor RAID-Z-familie met hardeschijven niet zo fijn is doordat er expliciet op seeks gewacht moet worden, van álle disks.

Een ZIL heb je altijd, normaliter op de hardeschijven zelf. Met een separate log (SLOG) device besteed je deze feature uit aan een dedicated device; een SSD die goed is in random writes en graag ook capacitor-protected omdat dat de hele essentie van de ZIL is; juist bij stroomfalen heb je die ZIL nodig.

De vraag is hoe effectief een SLOG is voor thuisomgevingen. Waar niet over wordt gesproken is of er verschil zit tussen opslag-protocol (iSCSI/NFS/CIFS/AFP) en tussen ZFS platforms als Solaris, FreeBSD en Linux. Het komt geregeld voor dat Solaris-specifiek advies als algemeen advies wordt gebracht. Als je op FreeBSD platform zit, kunnen andere factoren gelden.

Zo is het een bekend probleem dat sommige NFS clients altijd sync writes doen. In dat geval kun je bij moderne ZFS implementaties sync=off instellen op dat specifieke filesystem, of een SLOG device gebruiken. Als ik wat meer tijd heb, hoop ik nog eens wat mooie benchmarks te maken van L2ARC en SLOG op basis van FreeBSD/ZFSguru.

[FireDrunk]

Je verhaal klopt exact, en strookt precies met wat ik bedoel. Juist omdat Synced NFS (om maar een voorbeeld te noemen) in een thuissituatie onzin is. Alsof je packetloss hebt op 1 switch zonder routering en daardoor je NFS connectie kaduuk zou gaan. NFS kan in theorie je Filesystem niet slopen (omdat het filebased is) er kan hooguit een file kaduuk gaan. In mijn optiek is synced NFS iets voor database en webservers met een shared store ofzo.

Er zijn zat toepassingen te verzinnen die synced werken, maar die heb je niet nodig in een thuissituatie.
Enige wat ik zou kunnen verzinnen is iets als een test ESX hosts die je via iSCSI of NFS van een datastore wil voorzien. Maar zelfs dan zou ik synced uitzetten, want het is sowieso traag en backups moet je toch wel maken...

Met andere woorden: ZIL of L2ARC heb je in mijn ogen niets aan, tenzij je er echt een specifieke toepassing voor hebt.

[ Voor 8% gewijzigd door FireDrunk op 02-05-2012 19:16 ]

[Verwijderd]

@FireDrunk: ik heb diskloze Linux clients die via NFS hun rootshare hebben enzo; daarvoor zijn sync writes wel belangrijk. Maar voor de andere filesystems heb ik gewoon met -o nolock,async gemount; ik werk toch niet met twee computers aan dezelfde files tegelijkertijd. Doe je dat wel, dan moet je geen 'nolock' gebruiken. Nolock voor de Linux NFS client wil zeggen dat file-locking lokaal is, en dus niet naar de ZFS server gestuurd worden (lockd proces).

Bijvoorbeeld: maak je een snapshot, dan moet op dat moment wel het filesystem consistent zijn. Dat lukt alleen als de sync writes van de applicatie (de Linux client over het netwerk) worden gerespecteerd. Als je dan een snapshot maakt, weet je zeker dat je filesystem consistent is zonder corruptie zou je weer naar die snapshot terugkeren. Dit zijn kleine dingetjes waar je rekening mee moet houden, voornamelijk als je speciale dingen doet zoals databases of besturingssystemen die hun systeemdisk op de ZFS server hebben, zoals hierboven beschreven.

Voor de meeste mensen die gewoon grote bestanden willen opslaan, zijn L2ARC en SLOG eigenlijk niet interessant. L2ARC is wel fijn omdat dat automatisch werkt en toch altijd iets kan schelen, in elk geval de metadata die dan van de SSD wordt ingelezen. Het openen/scannen/zoeken door directories kan dan veel sneller gebeuren. Bijvoorbeeld als je zoekt naar bestanden op je grote dataset.

[FireDrunk]

Dat is inderdaad een goede reden om een ZIL en L2ARC te hebben

Voor zoeken in files moet je gewoon mlocate gebruiken

[Verwijderd]

Ik bedoelde zoeken naar files.

Onder BSD heb je ook 'whereis' en 'which' en 'locate', maar dat zijn databases die maar eens in de zoveel tijd worden gemaakt en alleen voor systeembestanden. Doe je dingen als 'find' dan ben je wel even bezig op je RAID-Z zonder L2ARC.

[Stefanovic45]

Ik denk dat de meeste mensen de ZFS share ook benaderen vanuit windows en geen find commando's gebruiken etc

Heeft iemand trouwens enig idee of ZFS ook al veel wordt gebruikt bij (grote) organisaties? Je mist natuurlijk een beetje je aanspreek punt bij problemen en samenstelling en levering van hardware. Je wilt over het algemeen zo snel mogelijk een nieuw onderdeel hebben, ook al is het redundant uitgevoerd. Op software gebied heb je natuurlijk wel enterprise oplossingen zoals Nexenta of OpenIndiana, maar ik vind het toch altijd lastig om zoiets in het bedrijfsleven te implemeteren. Daar loop je een beetje tegen aan bij alle opensource ontwikkelingen.

[ Voor 22% gewijzigd door Stefanovic45 op 02-05-2012 20:05 ]

[FireDrunk]

Verwijderd schreef op woensdag 02 mei 2012 @ 19:28:
Ik bedoelde zoeken naar files.

Onder BSD heb je ook 'whereis' en 'which' en 'locate', maar dat zijn databases die maar eens in de zoveel tijd worden gemaakt en alleen voor systeembestanden. Doe je dingen als 'find' dan ben je wel even bezig op je RAID-Z zonder L2ARC.

Nee hoor, mijn mlocate database heeft gewoon een index van mijn array (/mnt/data). Je kan in /etc/mlocate.conf instellen welke paden je wel en niet wil includen in een update (die in cron staat). Maar je kunt ook gewoon het updatedb commando geven, dan word de database on the fly geupdate.
Easy as Dell Hell.

[Ravefiend]

StefanvanGelder schreef op woensdag 02 mei 2012 @ 20:03:Heeft iemand trouwens enig idee of ZFS ook al veel wordt gebruikt bij (grote) organisaties? Je mist natuurlijk een beetje je aanspreek punt bij problemen en samenstelling en levering van hardware. Je wilt over het algemeen zo snel mogelijk een nieuw onderdeel hebben, ook al is het redundant uitgevoerd. Op software gebied heb je natuurlijk wel enterprise oplossingen zoals Nexenta of OpenIndiana, maar ik vind het toch altijd lastig om zoiets in het bedrijfsleven te implemeteren. Daar loop je een beetje tegen aan bij alle opensource ontwikkelingen.

Vandaar dan ook dat grote organisaties eerder zullen opteren voor complete systemen zoals bv. Oracle’s Sun ZFS Storage Appliance, zoals recent nog deze aankondiging: GREE Selects Oracle’s Sun ZFS Storage Appliance, Oracle Solaris 11 on Sun x86 Server for Data Anal, met meer dan 1 petabyte aan storage capaciteit.

[Verwijderd]

StefanvanGelder schreef op woensdag 02 mei 2012 @ 20:03:
Ik denk dat de meeste mensen de ZFS share ook benaderen vanuit windows en geen find commando's gebruiken etc

Ik doe wel degelijk find op de server zelf, omdat dat sneller is als ik echt álles wil doorzoeken. Maar als je Windows laat doen via CIFS geldt hetzelfde. Je hebt dan ook baat van L2ARC, ook al sla je enkel grote bestanden op die sequentiëel worden aangesproken; de metadata kun je dan alsnog versnellen. Dit kun je ook expliciet opgeven met secondarycache=metadata zodat er geen files gecached worden, enkel metadata.

Heeft iemand trouwens enig idee of ZFS ook al veel wordt gebruikt bij (grote) organisaties? Je mist natuurlijk een beetje je aanspreek punt bij problemen en samenstelling en levering van hardware. (..) Daar loop je een beetje tegen aan bij alle opensource ontwikkelingen.

Mee eens; maar dat kun je denk ik vooral wijten aan de overname van Sun door Oracle.

FireDrunk schreef op woensdag 02 mei 2012 @ 20:19:
Nee hoor, mijn mlocate database heeft gewoon een index van mijn array (/mnt/data).

Hoe moet Linux weten of er bestanden zijn gewijzigd op de ZFS server? Je kunt de linux client wel CIFS/NFS mount laten indexeren, maar niets zegt dat die index accuraat is omdat het OS niet zelf controle heeft over het filesystem.

Maar voor de simpele zoekopdrachtjes kan het wel aardig zijn; ik ga het eens proberen onder Ubuntu.

[ Voor 22% gewijzigd door Verwijderd op 03-05-2012 14:51 ]

[matty___]

Heeft iemand de laatst tijd nog wat van de Block Pointer Rewriter gehoord?

[FireDrunk]

Verwijderd schreef op donderdag 03 mei 2012 @ 14:48:
Hoe moet Linux weten of er bestanden zijn gewijzigd op de ZFS server? Je kunt de linux client wel CIFS/NFS mount laten indexeren, maar niets zegt dat die index accuraat is omdat het OS niet zelf controle heeft over het filesystem.

Maar voor de simpele zoekopdrachtjes kan het wel aardig zijn; ik ga het eens proberen onder Ubuntu.

Ik had het niet over netwerk, maar mlocate gebruik ik sowieso op schedule basis. Het kan inderdaad makkelijk zijn dat files die nieuw geschreven worden ook in die database opgenomen worden, maar ach, zolang je database op een dag accuraat is lijkt me dat niet zo'n probleem. De dingen waar ik de afgelopen 24h mee bezig geweest ben weet ik vaak wel uit mijn hoofd.

Dus over het feit dat je database dan niet 100% accuraat is: Tja, so be it.

[RudolfR]

Ik heb regelmatig errors in m'n pool en volgens mij komt dat de performance niet ten goede.

code:

  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
 scan: scrub repaired 4.42M in 0h23m with 548 errors on Sat May  5 16:45:02 2012
config:

        NAME           STATE     READ WRITE CKSUM
        tank           ONLINE       0     0   548
          raidz1-0     ONLINE       0     0 1.08K
            gpt/disk1  ONLINE       0     0    37
            gpt/disk2  ONLINE       0     0    14
            gpt/disk3  ONLINE       0     0    30

errors: 548 data errors, use '-v' for a list

Ik share een deel van de pool via nfs en download er torrents naar toe. Ik vermoed dat het probleem daar in zit, omdat het probleem in Transmission zichtbaar is, en ook de gedownloadde files fouten bevatten, maar ik kan er weinig over vinden.

De fouten die er nu in zitten zijn niet van een torrent file, maar van een download van sabnzbd.

Dit is de SMART info:

Disk Status Temperature Power cycles Load cycles Cable errors Bad sectors Lifetime
da0 Healthy no sensor ? active • ? passive ???
da1 Healthy 32°C • 90°F 34 8714 0 0 active • 0 passive 29 days
da2 Healthy 34°C • 93°F 34 8693 0 0 active • 0 passive 29 days
da3 Healthy 33°C • 91°F 34 8715 0 0 active • 0 passive 29 days

Volgens ZFSGuru zijn de loadcycles vrij hoog. Ik had hier al wel over gelezen, maar kon niet echt achterhalen waar de grens ligt. Is het inderdaad te hoog? De schijf reageert niet op 'camcontrol identify',
mogelijk door ESXi?
Is het aan te raden om m'n RDM anders in te stellen zodat ze niet downspinnen?

[Verwijderd]

Check je RAM eerst eens met MemTest86+, te vinden op elke Ubuntu cd (druk escape zodra je klein logo ziet).

[RudolfR]

Dat heb ik gedaan toen ik het systeem in elkaar zette. (2 maanden geleden?)
Met de MemTest86+ van http://www.memtest.org/
Toen geen fouten geconstateerd.

Als dit vrijwel zeker wordt veroorzaakt door foutief geheugen, kan ik het nog wel herhalen, maar misschien heb je nog andere suggesties?

Ik heb de instellingen van de VMs wel even aangepast, ZFSGuru heeft nu 8GB dedicated geheugen
ipv 16, zodat overcommitten in ESXi niet meer nodig is.

Storage is 3x 1TB in Raid-Z1, dus dat moet genoeg zijn.
Nu bezig met een scrub (kennelijk automatisch na reboot?), later weer een torrent starten.

[ Voor 34% gewijzigd door RudolfR op 05-05-2012 20:26 ]

[Verwijderd]

Een scrub draaien met geheugencorruptie is gevaarlijk; ik raad je sterk aan om eerst minimaal 3 passes met MemTest86+ te doen.

Je gebruikt ESXi; gebruik je RDM of Vt-d om storage aan je VM toe te wijzen?

[RudolfR]

Bedankt voor de waarschuwing. Er staat nog nauwelijks belangrijke data op, dus 't kan nog niet veel kwaad.
Zal 'm op korte termijn aansluiten op een monitor en wederom 'n aantal keer memtest runnen.

Ik gebruik RDM. Een VT-D enabled CPU en een HBA was me een iets te grote investering.
Staat nog wel op de verlanglijst. Ik hoop niet dat dat 't probleem is, want dan moet ik 't toch gaan omdraaien en gaan virtualiseren binnen ZFSGuru.

Is die Load Cycle Count iets om me zorgen over te maken?

[3d0zer]

*offtopic* Cipher, kan je geen direct message versturen, maareh... Kom je nog wel eens op het ZFSGuru Forum?... http://zfsguru.com/forum/zfsgurudevelopment/388 * offtopic modus off Sorry!!

[0xDEADBEEF]

Het lukt me niet om te repliceren over ssh

Sigh poging 2.
Gelukt met behulp van deze video [1], om een kale installatie aan te maken, en onderstaande commando's heb ik een bestaande FreeBSD-installatie (op éen schijf, dus non-RAID) gecloned (geüpgrade naar een grotere schijf en van PATA naar SATA).
Om een ZFS-mirror te realiseren maakt de video gebruik van twee schijven.
[1] YouTube: FreeBSD full ZFS Root from bsdinstall

In grote lijnen (ja, er kan wat missen ):

Remote (opstarten van usbstick):

code:

# nc -4klnv 2468 | zfs receive -vFd tank

Lokaal:

code:

# zfs send -R tank/var@fullbackup | nc -4nv 172.16.0.48 2468
# zfs send -R tank/tmp@fullbackup | nc -4nv 172.16.0.48 2468
# zfs send -R tank/usr@fullbackup | nc -4nv 172.16.0.48 2468
# zfs send -R tank/root@fullbackup | nc -4nv 172.16.0.48 2468

( /usr/home@ wordt vanzelf opgepakt)

Remote:

code:

# zpool export tank
# zpool import -o altroot=/mnt -o cachefile=/tmp/zpool.cache tank
# cp /tmp/zpool.cache /mnt/boot/zfs/
# reboot

Ik heb public/private keys aangemaakt: http://www.ece.uci.edu/~chou/ssh-key.html
en daarna deze tutorial gevolgd:
http://www.mebsd.com/conf...ool-over-ssh-freebsd.html

Beide machines draaien FreeBSD 9.0.

[code]$ sudo zfs send -R tank@fullbackup | ssh root@172.16.0.48 "zfs recv -vFd tank"
cannot unmount '/usr': Device busy
warning: cannot send 'tank/var@fullbackup': Broken pipe
[/]

Ja, de pool is gemount en dus in gebruik maar het schijnt op deze manier wel mogelijk te zijn:
http://lists.freebsd.org/...rent/2009-May/007130.html ?

Hm, dan maar op deze manier, stap 1:
[code]$ sudo zfs send -R tank@fullbackup | ssh root@172.16.0.48 'cat - > snapshot_tank.zfs'[/]

Aan de lokale kant (links van de pipe) als user of root inloggen, of wel/niet gebruik maken van sudo, maakt geen verschil.

Remote:
[code]# mount
tank/root on / (zfs, local, nfsv4acls)
devfs on /dev (devfs, local, multilabel)
tank/tmp on /tmp (zfs, local, nfsv4acls)
tank/usr on /usr (zfs, local, nfsv4acls)
tank/usr/home on /usr/home (zfs, local, nfsv4acls)
tank/var on /var (zfs, local, nfsv4acls)

# df -h
Filesystem Size Used Avail Capacity Mounted on
tank/root 224G 213M 224G 0% /
devfs 1.0k 1.0k 0B 100% /dev
tank/tmp 224G 35k 224G 0% /tmp
tank/usr 224G 216M 224G 0% /usr
tank/usr/home 224G 31k 224G 0% /usr/home
tank/var 224G 252k 224G 0% /var
[/]

Lokaal:[code]$ zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 51.5G 37.9G 13.6G 73% 1.00x ONLINE -
$ zpool get all tank
NAME PROPERTY VALUE SOURCE
tank size 51.5G -
tank capacity 73% -
tank altroot - default
tank health ONLINE -
tank guid 3600601512902743568 default
tank version 28 default
tank bootfs tank/root local
tank delegation on default
tank autoreplace off default
tank cachefile - default
tank failmode wait default
tank listsnapshots off default
tank autoexpand off default
tank dedupditto 0 default
tank dedupratio 1.00x -
tank free 13.6G -
tank allocated 37.9G -
tank readonly off -
[/]

Remote:[code]# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 228G 431M 228G 0% 1.00x ONLINE -
# zpool get all tank
NAME PROPERTY VALUE SOURCE
tank size 228G -
tank capacity 0% -
tank altroot - default
tank health ONLINE -
tank guid 10506404859401947269 default
tank version 28 default
tank bootfs tank/root local
tank delegation on default
tank autoreplace off default
tank cachefile - default
tank failmode wait default
tank listsnapshots off default
tank autoexpand off default
tank dedupditto 0 default
tank dedupratio 1.00x -
tank free 228G -
tank allocated 430M -
tank readonly off -
[/]

[ Voor 114% gewijzigd door 0xDEADBEEF op 09-05-2012 03:28 ]

[ebia]

Al best lang wil ik een NAS in huis, voor wat centrale opslag enzo... Nu zie ik al een tijdje de ontwikkelingen rondom ZFS en vind het een erg gaaf systeem. Heel toevallig komt er binnenkort een systeem vrij na een upgrade, welke ik zou om kunnen bouwen tot NAS.

Het gaat om een AMD Athlon 64 X2 op een Asus M2A-VM mobo, met 4 GB ram. Disken zitten er niet in, maar ik overweeg 3 maal 1 TB. Dat is redelijk betaalbaar (duurder p/mb dan grotere disken, dat wel), genoeg voor mijn wensen (2 TB effectieve opslag) en dan hoef ik ook het geheugen niet op te waarderen.

Nu ben ik wel een hobbyist, maar ik wil gewoon 'productie' draaien op dit systeem. Dus niet bang hoeven te zijn dat alles zomaar in elkaar klapt, experimenteel is, enzovoorts. Gemak in beheer vind ik wel een enorme pré, en daarom kwam ik uit op FreeNAS. Als ik de HCL van FreeBSD 8.2 bekijk moet mijn hardware redelijk compatible zijn met het OS.

Zie ik nog andere dingen over het hoofd? Kan ik het beter anders aanpakken, andere hardware, ander OS?

[Ultraman]

Wat ik anders zou aanpakken zijn je disken.
Waarom het jezelf "moeilijk" maken door een raidz te bouwen met 3 x 1TB (effectief 2TB)?
Het lijkt mij verstandiger om twee disken van 2TB te kopen en die in mirror te zetten.
Dat is simpel, makkelijker uit te breiden, performance zit snor en het is zelfs iets betrouwbaarder.

Ik heb even gekeken in de pricewatch, en ik zie geen meerprijs als je dat zou doen.
1 TB disk kost rond de 80 euro, maal 3 = 240 euro.
2 TB disk kost tussen 100 en 120 euro, maal 2 = 200 ~ 240 euro.
De meesten daarvan zijn wel Advanced Format, mocht je dat "eng" vinden of niet zien zitten, dan is er de Hitachi 5K3000 2TB van 121,- euro, welke "normale" 512 bytes grote sectoren gebruikt.

Wat betreft de OS zou ik ook ZFSguru eens proberen. Die is ook handig in het gebruik en er lopen er hier genoeg rond die je er meer over kunnen vertellen. Daarnaast heeft het een volledige FreeBSD install onder de motorkap, in tegenstelling tot een ietwat gestripte vorm er van waar FreeNAS mee werkt.
Hierdoor kun je ook veel documentatie geschikt voor FreeBSD gebruiken om dingen voor elkaar te krijgen.

Het systeem is in mijn ogen best geschikt om mee te beginnen, daar kun je op deze manier nog best een tijd plezier van hebben

[ebia]

Ultraman schreef op woensdag 09 mei 2012 @ 06:20:
Wat ik anders zou aanpakken zijn je disken.
Waarom het jezelf "moeilijk" maken door een raidz te bouwen met 3 x 1TB (effectief 2TB)?
Het lijkt mij verstandiger om twee disken van 2TB te kopen en die in mirror te zetten.
Dat is simpel, makkelijker uit te breiden, performance zit snor en het is zelfs iets betrouwbaarder.

Geen idee waarom ik perse met 3 disken wilde werken, dacht dat dat RaidZ het veiligst/snelste was... maar blijkbaar dus niet.

De meesten daarvan zijn wel Advanced Format, mocht je dat "eng" vinden of niet zien zitten, dan is er de Hitachi 5K3000 2TB van 121,- euro, welke "normale" 512 bytes grote sectoren gebruikt.

Zijn er veel problemen met die disken met grotere sectoren dan?

Wat betreft de OS zou ik ook ZFSguru eens proberen. Die is ook handig in het gebruik en er lopen er hier genoeg rond die je er meer over kunnen vertellen. Daarnaast heeft het een volledige FreeBSD install onder de motorkap, in tegenstelling tot een ietwat gestripte vorm er van waar FreeNAS mee werkt.
Hierdoor kun je ook veel documentatie geschikt voor FreeBSD gebruiken om dingen voor elkaar te krijgen.

Dank je wel voor de tip. Ziet er ook goed uit. Gaat mij om hebben van een wat simpele webinterface, want ik ben zo'n type dat altijd command-line tools vergeet. Zeker als je zo'n systeem eenmaal bouwt en in de kast zet, en je er twee jaar later weer eens naar wilt kijken, ben je altijd vergeten wat je ook alweer moest doen.

Maar dat je inderdaad een full OS onderliggend hebt klinkt wel goed.

EDIT:

Me nog even verder ingelezen in de materie. Raid-Z zou iets goedkoper zijn, maar wel ten koste van performance verlies. Nah, doe maar gewoon een mirror.

De derde disk optie hou ik er misschien wel in: als hot spare. Lijkt me wel een gave feature om te hebben.

[ Voor 7% gewijzigd door ebia op 09-05-2012 12:14 ]