Het grote ZFS topic

[Durandal]

Vanmiddag mijn vervangende harddisk binnen gekregen, en die zit nu in de server om getest te worden, daarna terug in de zpool (RaidZ2).
De oude disk is er ook al uit.

Straks de disk in de pool replacen met:

zpool replace tank /dev/disk/by-id/scsi_(old disk) /dev/disk/by-id/scsi_(new disk)

Zie ik nog wat over het hoofd?

[FireDrunk]

Geen labels?

[Durandal]

FireDrunk schreef op maandag 12 augustus 2013 @ 19:03:
Geen labels?

ALs je het over ZFS labels hebt en geen stickertjes dan nee, ik heb er voor gekozen het disk serienummer te gebruiken want die zijn onveranderlijk, en staan ook nog eens op de sticker.

Verder geen pitfalls?
Ben benieuwd hoe lang de resilver gaat duren.

Ik kreeg overigens een gereviseerde WD Red 3TB terug voor een 'echte'. De sticker is dan zwatr/wit en er staat iets van 'recertified' op o.i.d.

[HyperBart]

Refurbished disks zijn wel schering en inslag. Heb hier al 2 vervangende Seagates met een groen randje "Recertified" oid

[Keiichi]

HyperBart schreef op maandag 12 augustus 2013 @ 20:32:
Refurbished disks zijn wel schering en inslag. Heb hier al 2 vervangende Seagates met een groen randje "Recertified" oid

Zo weinig? Ik heb op de plank 3 van 4 schijven uit een enkele raid die refurbished zijn 'geworden'. Ik durf ze eigenlijk uberhaupt niet meer te gebruiken

[HyperBart]

Dat zijn degene die ik nog "over" heb/had. In mijn Qnap zaten al 2 van die refurbished beestjes.

Nou ja, ik heb ze nu al een tijdje in mijn ZFS NAS zitten en daar doen ze toch braaf hun werk horo.

[DrFlash]

de refurbished/recertified schijven zijn over het algemeen gewoon goed, beter als nieuwe vaak omdat deze schijven wel door een uitgebreid test process zijn heengegeen waar nieuwe schijven vaak zo van de band af komen en alleen steekproef gewijs worden getest.

Ik heb er zelf ook een aantal in gebruik nadat ik een hele rits met schijven (uit een zelfde serie) had met problemen. de referb disks draaien nu al een hele tijd zonder problemen.

[ Voor 26% gewijzigd door DrFlash op 13-08-2013 09:42 ]

[Durandal]

DrFlash schreef op dinsdag 13 augustus 2013 @ 09:41:
de refurbished/recertified schijven zijn over het algemeen gewoon goed, beter als nieuwe vaak omdat deze schijven wel door een uitgebreid test process zijn heengegeen waar nieuwe schijven vaak zo van de band af komen en alleen steekproef gewijs worden getest.

Ik kan dit beamen en ben er ook niet bang voor.

Mijn Refurbished 1.5TB seagates hebben er nu meer dan 4 jaar op zitten geloof ik en geen enkel probleem mee gehad.

De replace van mijn gefaalde disk is trouwens zonder problemen verlopen. Wel moest ik de -f (force) optie meegeven want hij dacht dat de verse disk een gebruikte mbr had.


Nu iets anders:

code:

root@server:~$ zpool status
  pool: tank
 state: ONLINE
status: The pool is formatted using a legacy on-disk format.  The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
        pool will no longer be accessible on software that does not support
        feature flags.

Als ik upgrade, kan ik dan nog terugvallen op BSD?

[FireDrunk]

Alleen naar FreeBSD 10.0 volgens mij, 9.1 doet nog geen pool versie 5000.

[Keiichi]

FireDrunk schreef op dinsdag 13 augustus 2013 @ 16:22:
Alleen naar FreeBSD 10.0 volgens mij, 9.1 doet nog geen pool versie 5000.

9.2 doet 5000 Ik was ongeduldig genoeg met mijn NAS herinstallatie op RC1 te installeren (imho stabieler dan de stabielste windows release *bash bash bash*)

[HyperBart]

Hoe regel je eigenlijk een periodic scrub? Ik heb in /etc/crontab nu het volgende staan:

[root@zfsguru /]# cat /etc/crontab
# /etc/crontab - root's crontab for FreeBSD
#
# $FreeBSD: releng/9.1/etc/crontab 194170 2009-06-14 06:37:19Z brian $
#
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
#
#minute hour    mday    month   wday    who     command
#
*/5     *       *       *       *       root    /usr/libexec/atrun
#
# Save some entropy so that /dev/random can re-seed on boot.
*/11    *       *       *       *       operator /usr/libexec/save-entropy
#
# Rotate log files every hour, if necessary.
0       *       *       *       *       root    newsyslog
#
# Perform daily/weekly/monthly maintenance.
1       3       *       *       *       root    periodic daily
15      4       *       *       6       root    periodic weekly
30      5       1       *       *       root    periodic monthly
#
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time.  See adjkerntz(8) for details.
1,31    0-5     *       *       *       root    adjkerntz -a

37      20      *       *       *       root    /sbin/zpool scrub maximus

Maar hij weigert om een scrub te starten...

als ik via crontab -e een lijntje plaats (zonder de "who" die hierboven vermeld staat), dan doet hij ook niks.

Kan toch niet dat ik de enige ben die hier tegen loopt?

[Xudonax]

Ik regel het in de crontab van root (Linux he ) op deze manier:

code:

15  12  *   *   fri /usr/sbin/zpool scrub tank
30  12  *   *   fri /bin/echo check > /sys/block/md0/md/sync_action

Oftewel, iedere vrijdag terwijl ik lunch word mijn ZFS pool gescrubbed en mijn MDADM array gecontroleerd

EDIT: Hmm, dit is bijna hetzelfde als wat jij hebt, alleen laat jij het iedere avond ipv iedere week doen. Ik zie zo 1-2-3 geen problemen. Kun je het eens proberen in /etc/cron.daily te gooien als los scriptje anders?

[ Voor 27% gewijzigd door Xudonax op 13-08-2013 20:44 ]

[FireDrunk]

FreeBSD kent volgens mij geen /etc/cron.daily

[Keiichi]

FireDrunk schreef op dinsdag 13 augustus 2013 @ 21:02:
FreeBSD kent volgens mij geen /etc/cron.daily

Jawel, het heet anders: /etc/periodic/daily/ en daar dan scripts in.

[HyperBart]

[root@zfsguru ~]# crontab -l

08      21      *       *       *       *       /home/root/scrub.sh
[root@zfsguru ~]# cat scrub.sh
#!/bin/sh

/sbin/zpool scrub maxim

Doet nog altijd niets

[ Voor 6% gewijzigd door HyperBart op 13-08-2013 21:10 ]

[Xudonax]

Heb je daar niet een sterretje teveel in staan?

[HyperBart]

[root@zfsguru ~]# date
Tue Aug 13 21:17:42 CEST 2013
[root@zfsguru ~]# crontab -l

19      21      *       *       *       /home/root/scrub.sh
[root@zfsguru ~]# crontab -l

19      21      *       *       *       /home/root/scrub.sh
[root@zfsguru ~]# date
Tue Aug 13 21:19:04 CEST 2013
[root@zfsguru ~]# date
Tue Aug 13 21:19:04 CEST 2013
[root@zfsguru ~]# date
Tue Aug 13 21:19:05 CEST 2013
[root@zfsguru ~]# date
Tue Aug 13 21:19:05 CEST 2013
[root@zfsguru ~]# cat scrub.sh
#!/bin/sh

/sbin/zpool scrub maxim

Nog steeds niets

En toen was het stil

[ Voor 10% gewijzigd door HyperBart op 13-08-2013 21:47 ]

[FireDrunk]

chmod +x /home/root/scrub.sh ?

[HyperBart]

En dan opeens toch weer niet

Had 'm al gechmod:

[root@zfsguru ~]# ls -lah
total 18
drwxr-xr-x   2 root  wheel     8B Aug 13 21:05 .
drwxr-xr-x  22 root  wheel    28B Aug 13 20:18 ..
-rw-------   1 root  wheel   7.6k Aug 13 20:39 .bash_history
-rw-r--r--   1 root  wheel     1k Jan 29  2013 .cshrc
-rw-r--r--   1 root  wheel   148B Jan 29  2013 .k5login
-rw-r--r--   1 root  wheel   311B Mar 19  2012 .login
-rw-r--r--   1 root  wheel   579B Mar 19  2012 .profile
-rwxr-xr-x   1 root  wheel    35B Aug 13 21:06 scrub.sh

[HMS]

Hoe zit het met je PATH variable in het script dat door CRON wordt aangeroepen? Vaak is de PATH variable via CRON echt super beperkt. Daarnaast, wat voor errors krijg je wel uit je script?

Doe anders:

code:

19      21      *       *       *       /home/root/scrub.sh >> /var/log/scrub_cron.log 2>&1

En sowieso: /home/root ? moet dat niet /root zijn?

[Verwijderd]

/home/root moet /root zijn inderdaad denk ik.

Maar een periodic scrub kun je ook simpelweg in /etc/periodic.conf inschakelen:

         daily_scrub_zfs_enable
             (bool) Set to ``YES'' if you want to run a zfs scrub periodi-
             cally.

         daily_scrub_zfs_pools
             (str) A space separated list of names of zfs pools to scrub.  If
             the list is empty or not set, all zfs pools are scrubbed.

         daily_scrub_zfs_default_threshold
             (int) Number of days between a scrub if no pool-specific thresh-
             old is set.  If not set, the default value is 35, corresponding
             to 5 weeks.

         daily_scrub_zfs_<poolname>_threshold
             (int) The same as daily_scrub_zfs_default_threshold but specific
             to the pool <poolname>.

Zie ook 'man periodic.conf'.

[HyperBart]

HMS schreef op dinsdag 13 augustus 2013 @ 22:02:
Hoe zit het met je PATH variable in het script dat door CRON wordt aangeroepen? Vaak is de PATH variable via CRON echt super beperkt. Daarnaast, wat voor errors krijg je wel uit je script?

Doe anders:

code:

19      21      *       *       *       /home/root/scrub.sh >> /var/log/scrub_cron.log 2>&1

En sowieso: /home/root ? moet dat niet /root zijn?

Ik had idd begrepen dat de included path variabele redelijk limited is, maar dat zou toch niet mogen uitmaken als ik het full path meegeef? Dat zeggen ze ook hier:

http://www.wonkity.com/~wblock/docs/html/interrupted.html

Dus ik geef toch het volledige pad mee, dat zou toch moeten werken?

Er loopt nu al een scrub, maar ik zal dat morgen doorheen de dag eens even testen wat jij nu net aangeeft.

CiPHER: ik ga het eerst eens, voor de wetenschap, werkend proberen te krijgen via cron. Wil daarna ook wel eens naar jouw manier kijken.

6 x 3TB in RAIDZ2. Hitachi Ultrastars. Scrub loopt aan 630 640MB/s


Ik heb zonet het eens getest op mijn bootpool, maar het lijkt er echt op dat die job gewoon NOOIT wordt opgestart vanuit cron

[ Voor 6% gewijzigd door HyperBart op 14-08-2013 00:07 ]

[FireDrunk]

Moet je dat commando niet tussen "" zetten? Anders interpreteert hij het als meerdere kolommen denk ik.

[HyperBart]

Nog altijd niets

[root@zfsguru ~]# date
Wed Aug 14 00:03:37 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 00:03:37 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 00:03:37 CEST 2013
[root@zfsguru ~]# crontab -l

4       0       *       *       *       "/root/scrub.sh >> /var/log/scrub_cron.log 2>&1"
[root@zfsguru ~]# date
Wed Aug 14 00:03:43 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 00:03:54 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 00:04:09 CEST 2013
[root@zfsguru ~]# ls -lah /var/log/
auth.log         dmesg.today      lpd-errs         maillog.1.bz2    maillog.4.bz2    messages         pf.today         security         sendmail.st.1    userlog          xferlog
cron             dmesg.yesterday  maillog          maillog.2.bz2    maillog.5.bz2    mount.today      ppp.log          sendmail.st      sendmail.st.2    utx.lastlogin
debug.log        lighttpd/        maillog.0.bz2    maillog.3.bz2    maillog.6.bz2    mount.yesterday  samba/           sendmail.st.0    sendmail.st.3    utx.log
[root@zfsguru ~]# ls -lah /var/log/
total 127
drwxr-xr-x   4 root  wheel      33B Aug 14 00:00 .
drwxr-xr-x  23 root  wheel      23B Aug 13 20:26 ..
-rw-------   1 root  wheel     6.7k Aug 13 20:59 auth.log
-rw-------   1 root  wheel     357k Aug 14 00:04 cron
-rw-------   1 root  wheel      63B Aug  4 13:01 debug.log
-rw-------   1 root  wheel      11k Aug  6 05:02 dmesg.today
-rw-------   1 root  wheel     9.8k Aug  5 05:01 dmesg.yesterday
drwx------   2 www   www         4B Aug  4 13:01 lighttpd
-rw-r--r--   1 root  wheel      63B Aug  4 13:01 lpd-errs
-rw-r-----   1 root  wheel      62B Aug 14 00:00 maillog
-rw-r-----   1 root  wheel     1.3k Aug 14 00:00 maillog.0.bz2
-rw-r-----   1 root  wheel     1.2k Aug 13 02:00 maillog.1.bz2
-rw-r-----   1 root  wheel     1.0k Aug 12 02:00 maillog.2.bz2
-rw-r-----   1 root  wheel     1.0k Aug 11 02:00 maillog.3.bz2
-rw-r-----   1 root  wheel     878B Aug 10 02:00 maillog.4.bz2
-rw-r-----   1 root  wheel     814B Aug  9 02:00 maillog.5.bz2
-rw-r-----   1 root  wheel     736B Aug  8 02:00 maillog.6.bz2
-rw-r--r--   1 root  wheel      57k Aug 13 20:59 messages
-rw-------   1 root  wheel     1.4k Aug 12 05:01 mount.today
-rw-------   1 root  wheel     2.1k Aug  9 05:02 mount.yesterday
-rw-------   1 root  wheel       0B Aug  5 05:01 pf.today
-rw-r-----   1 root  network    63B Aug  4 13:01 ppp.log
drwxr-xr-x   3 root  wheel      11B Aug  8 23:18 samba
-rw-------   1 root  wheel      63B Aug  4 13:01 security
-rw-r-----   1 root  wheel       0B Aug 11 15:00 sendmail.st
-rw-r-----   1 root  wheel       0B Aug 11 14:00 sendmail.st.0
-rw-r-----   1 root  wheel       0B Aug  4 15:00 sendmail.st.1
-rw-r-----   1 root  wheel       0B Aug  4 14:00 sendmail.st.2
-rw-r-----   1 root  wheel       0B Jan 29  2013 sendmail.st.3
-rw-------   1 root  wheel     682B Aug  5 22:06 userlog
-rw-r--r--   1 root  wheel     394B Aug 13 20:56 utx.lastlogin
-rw-r--r--   1 root  wheel      18k Aug 13 20:56 utx.log
-rw-------   1 root  wheel      63B Aug  4 13:01 xferlog

[FireDrunk]

Geef de cron daemon eens een schop.

[Keiichi]

Mijn scrub haalt 'maar' 200 Mbytes/sec. Maakt het verschil om met onboard adapters te werken of 'dedicated' adapters?

[Xudonax]

Volgens mij is je scrub snelheid vooral afhankelijk van je disks en wat er verder gebeurd op de machine. Ik haal bijvoorbeeld maar ~175MB/s op mijn RAIDZ2 pool, waar ik normaliter met ~320MByte/s kan lezen. Ik moet wel zeggen dat ik de scrubs schedule tijdens lunch (aka overdag) waarbij alle daemons en alles nog vrolijk draaien. Er is dus genoeg overige activiteit op de pool

[FireDrunk]

Het maakt vooral uit hoe *ver* je scrub is... Hij begint hier op 18MB/s en pas na 10-15 minuten loopt dat op.

 scan: scrub repaired 0 in 5h55m with 0 errors on Wed Aug 14 02:51:59 2013

4*4TB RAIDZ, 8.64T in use.

Dat maakt 423MB/s gemiddeld.

[ Voor 41% gewijzigd door FireDrunk op 14-08-2013 08:47 ]

[Snow_King]

Scrub snelheid is ook afhankelijk van de grootte van je records.

Ik heb een paar pools met miljoenen kleine files, daar gaat de scrub met maximaal 10MB/sec tot soms 20MB/sec, maar harder wil het niet.

Grote files nemen grotere records (128k) in beslag en zijn makkelijker te scrubben.

[Keiichi]

Dan kan dat een verklaring zijn. Ik heb op een verbruik van 2TB ongeveer 22 miljoen bestanden

[FireDrunk]

Dat is inderdaad best veul

---

* FireDrunk is bezig met een ZFS IOstats Daemon

Perl scriptje wat ZFS io stats logged naar een SQLite database is al af, nu nog een PHP pagina die de stats toont

[ Voor 76% gewijzigd door FireDrunk op 14-08-2013 09:39 ]

[HyperBart]

Is dat nu gvd nog altijd niet af? Wat zit je weer heel de dag te doen?

[Snow_King]

Keiichi schreef op woensdag 14 augustus 2013 @ 09:16:
Dan kan dat een verklaring zijn. Ik heb op een verbruik van 2TB ongeveer 22 miljoen bestanden

In mijn geval gaat het om pools van +/- 10TB met daar op rond de 300 miljoen bestanden per pool.

Records (blocks) in ZFS zijn dynamisch. De default setting is 128k, dat wil zeggen dat files worden gestriped over 128k records. Als files echter kleiner dan 128k zijn, dan wordt het een kleiner record.

Scrubbing en resilvering gaat echter record voor record. Dus als je veel kleine files hebt, dan heb je veel kleine records die allemaal stuk voor stuk moeten worden gecontroleerd.

Zie ook deze blogpost: https://blogs.oracle.com/roch/entry/tuning_zfs_recordsize

[onox]

Hyperbart, gewoon periodic.conf gebruiken wat cipher zegt. Gebruik ik ook op freebsd. Werkt goed.

[HyperBart]

Maar dan heb je geen controle over het start-tijdstip?

[HyperBart]

Snow_King schreef op woensdag 14 augustus 2013 @ 10:17:
[...]
In mijn geval gaat het om pools van +/- 10TB met daar op rond de 300 miljoen bestanden per pool.

Records (blocks) in ZFS zijn dynamisch. De default setting is 128k, dat wil zeggen dat files worden gestriped over 128k records. Als files echter kleiner dan 128k zijn, dan wordt het een kleiner record.

Scrubbing en resilvering gaat echter record voor record. Dus als je veel kleine files hebt, dan heb je veel kleine records die allemaal stuk voor stuk moeten worden gecontroleerd.

Zie ook deze blogpost: https://blogs.oracle.com/roch/entry/tuning_zfs_recordsize

Bij mij is de scrub snelheid in het begin wat trager maar je merkt toch echt wel dat die een omgekeerde badkuip-curve volgt hoor. Begint aan enkele MB, na een paar minuutjes zit ik al aan enkele honderden MB's per seconden en hij finisht bijna aan pieksnelheid van 614 MB/s terwijl hij op zijn maximum een tijdje 649MB/s aanhield, wat toch het maximum benadert (162.25MB/s / disk en het maximum is 162.5 ) van 4 van mijn disks (6 disks in RAIDZ2 minus 2 parity disks).

[syl765]

@ hyperbart
Wat zegt /var/log/cron ??

gr
Johan

[FireDrunk]

Tis zo goed als af, nog even wat finetunen

[Snow_King]

HyperBart schreef op woensdag 14 augustus 2013 @ 13:06:
[...]

Bij mij is de scrub snelheid in het begin wat trager maar je merkt toch echt wel dat die een omgekeerde badkuip-curve volgt hoor. Begint aan enkele MB, na een paar minuutjes zit ik al aan enkele honderden MB's per seconden en hij finisht bijna aan pieksnelheid van 614 MB/s terwijl hij op zijn maximum een tijdje 649MB/s aanhield, wat toch het maximum benadert (162.25MB/s / disk en het maximum is 162.5 ) van 4 van mijn disks (6 disks in RAIDZ2 minus 2 parity disks).

Maar hoe groot zijn de files die op je pool staan?

In mijn geval zijn het dus héél véél kleine files, die slopen daardoor de scrub en resilver performance.

[HyperBart]

syl765 schreef op woensdag 14 augustus 2013 @ 13:36:
@ hyperbart
Wat zegt /var/log/cron ??

gr
Johan

root@zfsguru ~]# /etc/rc.d/cron restart
Stopping cron.
Waiting for PIDS: 1016.
Starting cron.
[root@zfsguru ~]# 
[root@zfsguru ~]# 
[root@zfsguru ~]# 
[root@zfsguru ~]# 
[root@zfsguru ~]# crontab -l

07      14      *       *       *       "/root/scrub.sh >> /var/log/scrub_cron.log 2>&1"
[root@zfsguru ~]# date
Wed Aug 14 14:06:43 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:06:45 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:06:46 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:06:47 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:06:47 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:06:48 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:06:49 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:06:50 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:06:51 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:06:57 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:06:59 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:07:00 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:07:00 CEST 2013
[root@zfsguru ~]# date
Wed Aug 14 14:07:01 CEST 2013

Aug 14 12:00:00 zfsguru /usr/sbin/cron[36188]: (root) CMD (/usr/libexec/atrun)
Aug 14 14:01:52 zfsguru crontab[36203]: (root) BEGIN EDIT (root)
Aug 14 14:02:23 zfsguru crontab[36203]: (root) REPLACE (root)
Aug 14 14:02:23 zfsguru crontab[36203]: (root) END EDIT (root)
Aug 14 14:02:27 zfsguru crontab[36206]: (root) LIST (root)
Aug 14 12:03:00 zfsguru /usr/sbin/cron[1016]: (root) RELOAD (tabs/root)
Aug 14 12:05:00 zfsguru /usr/sbin/cron[36597]: (root) CMD (/usr/libexec/atrun)
Aug 14 14:05:34 zfsguru crontab[36698]: (root) LIST (root)
Aug 14 14:05:58 zfsguru crontab[36700]: (root) BEGIN EDIT (root)
Aug 14 14:06:09 zfsguru crontab[36700]: (root) REPLACE (root)
Aug 14 14:06:09 zfsguru crontab[36700]: (root) END EDIT (root)
Aug 14 14:06:41 zfsguru crontab[36725]: (root) LIST (root)
Aug 14 14:07:00 zfsguru /usr/sbin/cron[36739]: (root) CMD ("/root/scrub.sh >> /var/log/scrub_cron.log 2>&1")

Das wel de eerste keer dat ik dat commando in de log zie verschijnen... Dus ik vermoed dat een restart van cron wel wat geholpen heeft. Maar ik heb net gecheckt en er is geen scrub gestart.

[ Voor 6% gewijzigd door HyperBart op 14-08-2013 14:11 ]

[syl765]

Volgens mij moet je de quotejes weghalen.

[RudolfR]

Jup, die quotes doen meer kwaad dan goed.
Zonder quotes kon ik vanuit cron een scrub starten, met quotes lukt het niet.

[HyperBart]

EINDELIJK!!!11!

[root@zfsguru ~]# crontab -l

42      15      *       *       *       /sbin/zpool scrub BOOTPOOL >> /var/log/scrub_cron.log 2>&1
[root@zfsguru ~]# date
Wed Aug 14 15:41:14 CEST 2013
[root@zfsguru ~]# /etc/rc.d/cron restart
Stopping cron.
Waiting for PIDS: 38955.
Starting cron.
[root@zfsguru ~]# date
Wed Aug 14 15:41:21 CEST 2013
[root@zfsguru ~]# zpool status BOOTPOOL
  pool: BOOTPOOL
 state: ONLINE
  scan: scrub canceled on Wed Aug 14 15:34:15 2013
config:

        NAME            STATE     READ WRITE CKSUM
        BOOTPOOL        ONLINE       0     0     0
          gpt/USBBOOT1  ONLINE       0     0     0

errors: No known data errors
[root@zfsguru ~]# date
Wed Aug 14 15:41:50 CEST 2013
[root@zfsguru ~]# zpool status BOOTPOOL
  pool: BOOTPOOL
 state: ONLINE
  scan: scrub in progress since Wed Aug 14 15:42:00 2013
        15.8M scanned out of 708M at 7.90M/s, 0h1m to go
        0 repaired, 2.23% done
config:

        NAME            STATE     READ WRITE CKSUM
        BOOTPOOL        ONLINE       0     0     0
          gpt/USBBOOT1  ONLINE       0     0     0

errors: No known data errors

[webfreakz.nl]

Cool! Zelfs die statistieken en ETA erbij

[HyperBart]

Dat is normaal. Nu nog ff een cron-regeltje er bij om iedere dag de status eens te dumpen naar een log file en biebie is helemaal tevreden.

[HMS]

Je gaat elke dag een scrub uitvoeren? Of begrijp ik het verkeerd ?

[webfreakz.nl]

Nee, hij gaat elke dag de status uitlezen en in een logfile stoppen

[Xudonax]

Zo, mijn RAID-Z2 setup is weer aan het rebuilden Vandaag een nieuwe schijf gekregen van MaxICT als vervanging voor mijn "oude" Hitachi 5K1000 die de een significant aantal sectoren aan het reallocaten was.

Terwijl deze bezig was (met ~250MByte/s, niet verkeerd voor een stapeltje notebookschijven IMO) ben ik nog eens opzoek gegaan naar 2.5" 9.5mm schijfjes die meer dan de normale 1TB aan data kunnen hebben. En ik kwam ze zowaar tegen, de Hitachi 5K1500. Volgens Hitachi zelf verwachten ze dat de schijven beschikbaar zijn rond juni, maar ze zijn in Nederland nog niet beschikbaar volgens de Pricewatch.

Ik zit te overwegen om mijn nieuwe 22 disk array op te bouwen met deze schijven. Dat betekent dat ik in plaats van 22TB - 4TB = 18TB ineens 33TB - 6TB = 27TB aan beschikbare ruimte zou hebben met een RAID-Z2 setup. Het idee is om dan 2x 11 disks te doen, en deze twee vdevs samen te voegen met mijn reeds bestaande RAID-Z2 pool voor een totaal van ~31TB. Of zouden jullie op dit soort aantallen zeggen, kijk eens naar RAID-Z3? Dit zou betekenen dat ik nog eens 3TB inlever en dus met "slechts" 24TB blijf zitten op de twee nieuwe vdevs.

[u_nix_we_all]

Xudonax schreef op woensdag 14 augustus 2013 @ 20:18:

Ik zit te overwegen om mijn nieuwe 22 disk array op te bouwen met deze schijven. Dat betekent dat ik in plaats van 22TB - 4TB = 18TB ineens 33TB - 6TB = 27TB aan beschikbare ruimte zou hebben met een RAID-Z2 setup. Het idee is om dan 2x 11 disks te doen, en deze twee vdevs samen te voegen met mijn reeds bestaande RAID-Z2 pool voor een totaal van ~31TB. Of zouden jullie op dit soort aantallen zeggen, kijk eens naar RAID-Z3? Dit zou betekenen dat ik nog eens 3TB inlever en dus met "slechts" 24TB blijf zitten op de twee nieuwe vdevs.

2 vdevs is misschien geen slecht idee, maar 11 disk per raid-z2 vdev is niet optimaal, wellicht is 10 beter qua performance.
Als het echt om capaciteit gaat zou je 1 grote raid-z3 kunnen overwegen. 19 disks is dan qua performance het optimale getal, dan houd je ook 16x1,5 TB over. Of met 22 disks, ik vraag me af of je iets merkt qua performance als je een niet-optimaal aantal disks gebruikt.
Als je wel 2 vdevs maakt weet ik niet of het nog heel nuttig is om daar een stripe van te maken, tenzij je 1 heel groot filesystem erop wilt maken. Met 2 kleinere pools ben je flexibeler.

[Xudonax]

Het idee is om één gigantische pool te maken van die twee vdevs en mijn bestaande 6x 1TB vdev. Ik kan natuurlijk ook voor 20 disks gaan, en de laatste twee sloten in de behuizing gebruiken voor mijn boot SSD en Intel 320 caching/ZLOG SSD. Dan zou ik 1.5TB * 20 disks doen met RAID-Z2, wat dus netto 24GB zou opleveren.

Ik ben van plan om voor één grote pool te gaan omdat dit wel zo makkelijk is met dingen als video's en backups. Ik ken mezelf, ik heb altijd te weinig ruimte voor hetgeen er op de kleinste partitie staat

[Verwijderd]

RAID-Z3 met 19 disks is optimaal voor 4K disks. Dat kun je overwegen. Dan zit je aan 16 data disks. 16 * 1.5TB = 24TB bruikbaar.

[FireDrunk]

Hoezo een stille pool...

[HMS]

Rustige 4 seconden inderdaad

[webfreakz.nl]

Hij doet hamandeggs!

[FireDrunk]

Tijd klopt nog niet helemaal, is 3600 seconden.

[Xudonax]

Verwijderd schreef op woensdag 14 augustus 2013 @ 20:58:
RAID-Z3 met 19 disks is optimaal voor 4K disks. Dat kun je overwegen. Dan zit je aan 16 data disks. 16 * 1.5TB = 24TB bruikbaar.

Het zit momenteel nog helemaal in de planfase, maar dat klinkt als een leuke hoeveelheid beschikbare ruimte. Zeker aangezien er nog ~4TB bijkomt van mijn huidige vdev dus dat moet wel goed komen lijkt me. Tegen de tijd dat ik het geheel ga bouwen zal ik hier wel wat foto's en stats neerzetten

Even een andere vraag die ik krijg nu ik een beetje aan het rommelen ben met ZFS. Ik heb mijn oude USB pool weer opgebouwd, structuur hiervan is:

$ sudo zpool list -v usb
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
usb  14,9G   405M  14,5G     2%  1.86x  ONLINE  -
  mirror  7,44G   201M  7,24G         -
    usb-SanDisk_Cruzer_Fit_4C532000031129106193-0:0      -      -      -         -
    usb-SanDisk_Cruzer_Fit_4C532000040210122173-0:0      -      -      -         -
  mirror  7,44G   204M  7,24G         -
    usb-SanDisk_Cruzer_Fit_4C532000050913100011-0:0      -      -      -         -
    usb-SanDisk_Cruzer_Fit_4C532000041129106180-0:0      -      -      -         -

Nu heb ik hier dedup en compressie (gzip-9) op aangezet. Vervolgens de Linux kernel source gedownload vanwege stevige compressie en goede mogelijkheid tot deduplicatie IMO. Echter, als ik de kernel source uitpak naar mijn pool, en deze kopieër naar een nieuwe map dan krijg ik dit:

$ sudo zpool list
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank  5,44T  4,01T  1,43T    73%  1.00x  DEGRADED  -
usb   14,9G   405M  14,5G     2%  1.86x  ONLINE  -

Waarom is mijn dedup ratio maar 1,86x? Dit zou logischerwijs 2,00x moeten zijn in mijn ogen, of eigenlijk zelfs 2,20x aangezien ik met één keer de kernel source al op een deduplicatieratio van 1,10x zat. Doe ik iets fout? Interpreteer ik de gegevens verkeerd?

[webfreakz.nl]

Xudonax schreef op woensdag 14 augustus 2013 @ 21:44:
Waarom is mijn dedup ratio maar 1,86x? Dit zou logischerwijs 2,00x moeten zijn in mijn ogen, of eigenlijk zelfs 2,20x aangezien ik met één keer de kernel source al op een deduplicatieratio van 1,10x zat. Doe ik iets fout? Interpreteer ik de gegevens verkeerd?

Het verschil zit hem erin dat je files/blocks/bytes hebt. Ik vermoed dat je blocks niet volledig (en/of verschillend) met bytes gevuld zijn, dus een andere dedup tot gevolg hebben.

https://blogs.oracle.com/bonwick/entry/zfs_dedup
http://christopher-techni...rformance-real-world.html

Dedup works on a ZFS block or record level. For a iSCSI or FC LUN, i.e. objects backed by ZVOL datasets, the default blocksize is 8K. For filesystems (NFS, CIFS or Direct Attach ZFS), object smaller than 128K (the default recordsize) are stored as a single ZFS block while objects bigger than the default recordsize are stored as multiple records Each record is the unit which can end up deduplicated in the DDT. Whole Files which are duplicated in many filesystems instances are expected to dedup perfectly. For example, whole DB copied from a master file are expected to fall in this category. Similarly for LUNS, virtual desktop users which were created from the same virtual desktop master image are also expected to dedup perfectly.

Daar zal ongeveer het echte antwoord welk ergens tussen staan
ofzo

[johann1982]

Hoi !

Ik heb momenteen een pool bestaande uit 1 vdev (in mirror) bestaande uit twee 2TB WD20EARS. Deze staat +- voor de helft vol.
Nu wil ik deze pool uitbreiden met nogmaal twee 2TB schijven. Ik was van plan de een nieuwe vdev mirror te maken zodat ik een striped mirror krijg ? (Gelijkaardig aan raid10). Kan dit zonder dataverlies ?

Ik zie ook dat de oude pool nog in ashift 9 staat. kan dit kwaad ? (Snelheidsverlies?). Kan ik beter met de 2 nieuwe schijven een nieuwe pool in ashift 12 maken, data overzetten en de oude schijven formatten en bij de nieuwe pool voegen als striped mirror ?

bedankt voor de info alvast !

Johan

[FireDrunk]

Ja hoor, dat kan zonder dataverlies, je kan de nieuwe vdev toevoegen aan de pool.

De data word niet automatisch geherdistribueerd, daar moet je wat andere truukjes voor uithalen.

(zoals het kopieren van een hele directory en daarna de oude lokatie weggooien.)

[Snow_King]

Verwijderd schreef op woensdag 14 augustus 2013 @ 20:58:
RAID-Z3 met 19 disks is optimaal voor 4K disks. Dat kun je overwegen. Dan zit je aan 16 data disks. 16 * 1.5TB = 24TB bruikbaar.

19 disks in één vdev? Dat gaat een flinke resilver tijd opleveren bij een disk verlies.

Ik durf nooit over de 9 disks in één vdev te gaan.

[Xudonax]

Maar je zit wel met RAID-Z3, oftewel drie disks die mogen falen. De kans op onherstelbare fouten is minimaal. Daarnaast, mijn RAID-Z2 pool met 6 diskjes was ook in een kleine 4 uur klaar met resilveren, dat is 6x 1TB. En aangezien het voor persoonlijk gebruik is zal die resilver tijd me echt niet wakker houden

Wel ben ik eigenlijk benieuwd, hoezo is 19 disks optimaal voor RAID-Z3 met 4k sectoren FireDrunk?

[Snow_King]

Xudonax schreef op donderdag 15 augustus 2013 @ 10:08:
Maar je zit wel met RAID-Z3, oftewel drie disks die mogen falen. De kans op onherstelbare fouten is minimaal. Daarnaast, mijn RAID-Z2 pool met 6 diskjes was ook in een kleine 4 uur klaar met resilveren, dat is 6x 1TB. En aangezien het voor persoonlijk gebruik is zal die resilver tijd me echt niet wakker houden

Stond die pool vol? Want ZFS resilvered alleen de gebruikte blocks.

6 disks in een vdev is wel iets anders dan 19.

Xudonax schreef op donderdag 15 augustus 2013 @ 10:08:
Wel ben ik eigenlijk benieuwd, hoezo is 19 disks optimaal voor RAID-Z3 met 4k sectoren FireDrunk?

Ben ik ook wel benieuwd naar inderdaad

[FireDrunk]

19 schijven - 3 parity = 16 data schijven.
ZFS heeft 128k records, dus er word 128k verdeeld over 16 schijven, dat is 8k per schijf, dat is een veelvoud van 4k dus erg efficiënt.

11 schijven kan ook, dat is 11 - 3 = 8 data schijven, 128k / 8 = 16k per schijf.

Overigens is de resilver tijd voor RAIDZ / RAIDZ2 / RAIDZ3 gelijk bij hetzelfde aantal schijven.

Alle data blocks moeten toch ingelezen worden, en er worden gewoon nieuwe checksums berekend voor de schijf die mist.

Leuke van ZFS is zelfs, dat je alle schijven tegelijk kan resilveren (mits er genoeg data is), ZFS is zo slim, om de data maar 1 keer in te lezen, en tegelijk de twee missende stukken te berekenen.

Waar normale RAID engines daar vaak veel langer over doen.

Overigens zou ik eerder voor 11 schijven gaan dan voor 19. Bij 19 heb je dezelfe Random IO performance als 11 namelijk die van 1 schijf. Best wel heel erg kak dus.

Zonder ZIL en L2ARC niet doen, met ZIL en L2ARC is het te overwegen.

[ Voor 61% gewijzigd door FireDrunk op 15-08-2013 10:24 ]

[Snow_King]

FireDrunk schreef op donderdag 15 augustus 2013 @ 10:20:
19 schijven - 3 parity = 16 data schijven.
ZFS heeft 128k records, dus er word 128k verdeeld over 16 schijven, dat is 8k per schijf, dat is een veelvoud van 4k dus erg efficiënt.

11 schijven kan ook, dat is 11 - 3 = 8 data schijven, 128k / 8 = 16k per schijf.

Overigens is de resilver tijd voor RAIDZ / RAIDZ2 / RAIDZ3 gelijk bij hetzelfde aantal schijven.

Dan ga je er vanuit (wat logisch is), dat het gros van de files groter dan 128k is

Dat is bij een Tweaker die media gaat op slaan een veilige aanname, maar als je een pool hebt met héél veel kleine files, dan zal je niet altijd 128k records hebben.

[FireDrunk]

Dan heb je een variable record size, en daar kan je met geen enkele disk configuratie iets aan doen

[Xudonax]

Ik heb sowieso een ZIL/L2ARC, dus dat moet wel los lopen Toch denk ik dat twee pools van 11 schijven wat fijner zijn om héél eerlijk te zijn

[FireDrunk]

Mja, mee eens.

[Verwijderd]

Maar dan zit je weer met veiligheid en overhead. Twee keer 10 disks in RAID-Z2 of één keer 19 disks in RAID-Z3 zou dan de overweging zijn:

2x10 = 16 effectief, 4 disks overhead, minimaal 3 disks dood voordat pool dood is. 1 disk dood betekent nog volledige bescherming tegen bad sectors
1x19 = 16 effectief, 3 disks overhead, minimaal 4 disks dood voordat pool dood is. 2 disks dood betekent nog volledige bescherming tegen bad sectors

Choose your poison.

De verouderde 'vuistregel' dat je niet meer dan 9 devices in een vdev moet stoppen komt louter doordat RAID-Z met steeds kleinere blocks gaat werken en dit minder efficient is, alsmede dat je qua IOps geen winst maakt. Een enkele vdev van 19 disks in RAID-Z3 heeft maximaal de random read IOps van een enkele disk.

Het nadeel van kleinere blocks is inferieur aan het feit of iets 4K optimaal is bij 4K sector schijven. De vuistregel gaat uit van 512-byte sector disks. Bij 4K sector disks verandert alles. Bovendien heb je bij nieuwere ZFS versies de mogelijkheid tot 1MiB recordsize (Solaris ZFS, maar wellicht ook een keer naar de v5000 opensource implementaties). Met 1MiB recordsize kun je rustig je vdevs wat groter maken. Met een 19-disk RAID-Z3 vdev zit je dan niet aan 8K blocks per disk, maar aan 64K blocks. Dat is enorm optimaal.

Dan het nadeel van beperkte IOps, dat kun je grotendeels wegnemen met een L2ARC en SLOG SSD opstelling. Zeker als je voornamelijk grote bestanden opslaat, zie ik niet een groot probleem.

[FireDrunk]

Helemaal mee eens. Wat misschien nog een voordeel kan zijn, is als je twee pools hebt, en je gebruikt niet altijd alle data, je nog iets van spindown zou kunnen doen.

GROOT nadeel van zo'n grote pool is dat spindown praktisch onbruikbaar word, omdat alle schijven na elkaar opgespint worden... Bij 19 schijven is dat dus ongeveer een minuut voordat de eerste IO's beginnen te rollen...

Dat vinden veel applicaties niet leuk...

[Verwijderd]

Klopt ja. Alhoewel daar volgens mij wel een trucje voor was in de vorm van een patch. Alweer een tijd geleden, stond ergens op de FreeBSD mailinglist dacht ik.

Maar spindown met zoveel schijven is niet erg praktisch. Dan kun je misschien beter aan twee pools denken waarbij de één in spindown gaat en de ander always on is, ofzoiets.

Dat gezegd, met 2,5" disks hoef je spindown niet echt te overwegen. Die 0,6W voor moderne disks is redelijk efficiënt. Dan zou ik geen spindown doen persoonlijk.

[FireDrunk]

Precies, daar dacht ik ook aan, 2 pools en dan 1 al dan niet always on, en de tweede voor backup en archief data. Maar goed, dat moet hij natuurlijk zelf weten.

Kan je eens kijken of je die patch kan vinden? Wil ik hier ook wel installeren... scheelt toch weer 20-30 seconden wachten

[Xudonax]

Spinup tijden zijn inderdaad redelijk vervelend ja... Ik ben benieuwd naar eerder genoemde patch om te zorgen dat alles tegelijk opstart. Ik bedoel, dat kan met ~30 2.5" schijven niet echt bizar veel zijn lijkt me. Zeg even 10W per schijf piek, dan zit ik nog ruim binnen de marges van mijn voeding

En waarschijnlijk overschat ik het benodigde vermogen met minstens een factor 2.

[Verwijderd]

Tussen 2 en 5W voor 2,5" disks meen ik. Meestal werkt het net niet voor 2,5W die normaal USB2 kan leveren. 4W voor USB3 is dan wel voldoende. Dus voor 2,5" disks is spinup current niet zo'n punt.

Patch vinden is me niet zo snel gelukt. Ik heb ook niet zo heel veel tijd nu, druk druk druk.

Maar ik zal binnenkort nog eens kijken. Het is wel een tijd geleden alweer, meerdere jaren. Misschien handiger om een bericht op de mailinglist (freebsd-zfs) te plaatsen.

[u_nix_we_all]

Xudonax schreef op donderdag 15 augustus 2013 @ 18:53:
Spinup tijden zijn inderdaad redelijk vervelend ja... Ik ben benieuwd naar eerder genoemde patch om te zorgen dat alles tegelijk opstart. Ik bedoel, dat kan met ~30 2.5" schijven niet echt bizar veel zijn lijkt me. Zeg even 10W per schijf piek, dan zit ik nog ruim binnen de marges van mijn voeding

En waarschijnlijk overschat ik het benodigde vermogen met minstens een factor 2.

Houd er wel rekening mee dat 2,5" disks geen 12V hebben en alles van de 5V lijn(en) van je voeding afhalen. Dus het totale vermogen van je voeding is niet maatgevend, maar het vermogen wat je van je 5V rail beshikbaar hebt wel.

Edit:
De meeste moderne 2'5" disks werken al op wat een USB-poort kan leveren, 0,5A. 2,5W lijkt mij dus een redelijke schatting, daarmee zit je met 30 disks aan 15A op je 5V.

Edit2:
Ik lees net CiPHER's opmerking mbt USB, die heeft duidelijk iets andere ervaringen met USB2. Anyhow ... you do the math

[ Voor 16% gewijzigd door u_nix_we_all op 15-08-2013 19:58 ]

[Patatjemet]

Mijns inziens is een nadeel van 1 grote pool dat je bij een upgrade alle disks ineens moet upgraden (en dus tegen de aankoop van 19 disks aanloopt €€€).

Om deze reden heb ik zelf gekozen voor 2 (8 * 2.5" 640 GB) raidz-2 arrays. Kom ik ruimte tekort dan upgrade ik 1 pool, de oude disks kan ik dan gebruiken als spare voor de andere pool, verkopen of in de backup server (al gebruik ik daar zelf 3.5" disk voor). Het plan is om zo om en om de 2 arrays te upgraden.

[Squixx]

Een van de schijven in mijn raidz1 array geeft checksum errors, betekend dit dat hij stervende is? (heb de disk sinds jan.)
ik heb net alle bekabeling aangedrukt (had gelezen dat het wellicht daar aan kon liggen), maar voor de herstart hiervoor gaf freenas 40 checksum errors, wat mij redelijk veel lijkt. Kan ik hier iets aan doen of moet ik me opmaken voor een RMA van de betreffende schijf?

[DXaroth]

FireDrunk schreef op woensdag 14 augustus 2013 @ 21:41:
Tijd klopt nog niet helemaal, is 3600 seconden.

gebruik je een javascript lib om die grafiek te maken? js staat er om bekend om als enige unix timestamps op milliseconden te doen, ipv op seconden met optioneel milliseconden achter de komma.

[Xudonax]

coredalae schreef op vrijdag 16 augustus 2013 @ 01:08:
Een van de schijven in mijn raidz1 array geeft checksum errors, betekend dit dat hij stervende is? (heb de disk sinds jan.)
ik heb net alle bekabeling aangedrukt (had gelezen dat het wellicht daar aan kon liggen), maar voor de herstart hiervoor gaf freenas 40 checksum errors, wat mij redelijk veel lijkt. Kan ik hier iets aan doen of moet ik me opmaken voor een RMA van de betreffende schijf?

Kun je de SMART waardes eens posten (smartcl -a /dev/<disk>)? Dat zou al een hoop informatie moeten geven

[FireDrunk]

Verwijderd schreef op donderdag 15 augustus 2013 @ 18:58:
Tussen 2 en 5W voor 2,5" disks meen ik. Meestal werkt het net niet voor 2,5W die normaal USB2 kan leveren. 4W voor USB3 is dan wel voldoende. Dus voor 2,5" disks is spinup current niet zo'n punt.

Patch vinden is me niet zo snel gelukt. Ik heb ook niet zo heel veel tijd nu, druk druk druk.

Maar ik zal binnenkort nog eens kijken. Het is wel een tijd geleden alweer, meerdere jaren. Misschien handiger om een bericht op de mailinglist (freebsd-zfs) te plaatsen.

Bedoelde jij deze?

http://forums.servethehom...pinup-scripts-zpools.html

DXaroth schreef op vrijdag 16 augustus 2013 @ 02:00:
[...]


gebruik je een javascript lib om die grafiek te maken? js staat er om bekend om als enige unix timestamps op milliseconden te doen, ipv op seconden met optioneel milliseconden achter de komma.

Klopt, ik zal de waarde eens maal 1000 doen.

[ Voor 20% gewijzigd door FireDrunk op 16-08-2013 09:29 ]

[Verwijderd]

FireDrunk schreef op vrijdag 16 augustus 2013 @ 09:22:
[...]

Bedoelde jij deze?

http://forums.servethehom...pinup-scripts-zpools.html

Volgens mij niet. Uit mijn hoofd was het een beetje slordige patch/hack die een soft timeout al heel vroeg genereert en zodoende ZFS de informatie van de overige schijven laat lezen. Dat zorgt ervoor dat alle schijven binnen een seconde of twee worden aangesproken en zodoende allemaal opspinnen. Het was een vieze patch, dat was volgens mij ook de reden dat hij niet is geaccepteerd. Maar gebruikers posten soms wel eens 'vieze workarounds' om dingen werkend te krijgen zoals zij willen. Maar die worden dan niet officieel geaccepteerd.

Of de patch überhaupt werkt op moderne ZFS is ook zeer de vraag, want volgens mij stamt dit van het ZFS v6/v13 tijdperk dus toch al een tijd geleden.

Maar misschien zijn er anderen die ook een workaround of iets gevonden hebben. Zijn vast meer mensen die het storend vinden dat het opspinnen serieel gebeurt ipv parallel.

[FireDrunk]

Probleem is een beetje dat je moet kiezen welk systeem je aanpast. OF je moet ZFS aware maken van het feit dat het schijven moet opspinnen (en dus IO concurrent moet doen) OF je moet de kernel aware maken dat schijven in een ZFS pool zitten, en als er dus IO naar de eerste disk gaat, je automatisch alle disks in de pool opspint.

En de kernel aware maken van zfs pools, is een beetje vies...

[Verwijderd]

De juiste plek hiervoor is in ZFS (SPA) en dat je via een sysctl instelling kan zeggen dat na 1 seconde soft timeout alle devices aangesproken worden.

[FireDrunk]

* FireDrunk gaat eens in de sourcecode neuzen.

[u_nix_we_all]

FireDrunk schreef op vrijdag 16 augustus 2013 @ 10:26:
* FireDrunk gaat eens in de sourcecode neuzen.

Ik weet niet hoe de relatie tussen de ZFS-code van freeBSD en van Illumos/OpenSolaris is, maar ook daar is het in ZFS ingebouwd dat de disks een voor een weer opgestart worden wanneer ze spun down zijn.
Bij mijn 4 disks RAID-Z pool levert dat al een vertraging van 4x10 = 40 sec op. Ik heb mijn time-out maar wat hoger gezet, maar het geeft nog steeds wel probleempjes nu en dan, zoals een timeout bij afspelen vanaf de NAS via de serviio-mediaserver, of downloads naar de NFS-share die corrupt aankomen.

Het is echt een ZFS-iets, bij coldboot van mijn HP N40L gaan de disks tegelijk aan, en heb ik geen staggered spin-up op de onboard controller.

Ik kan me voorstellen dat bij meer disk het echt een issue kan zijn, misschien dat het dan zelfs beter is de disks niet te laten stoppen, ondanks het stroomverbruik.

[FireDrunk]

Klopt zeker, met 10 schijven had ik ook wel eens last van timeouts, maar met 4 gaat het gelukkig snel genoeg. Voorbeeld was XBMC op mijn HTPC die vond het te lang duren voor hij data kreeg over NFS (ookal had je de NFS timeout hoog staan). Met 4 disks geen last meer van. Spinup tijd is ook 'maar' iets van 15-20 seconden.

[Phuncz]

Yay, hardware is compleet !

Phuncz in "Heb je iets nieuws en MOET je het gewoon showen deeltje 118"

Nu beginnen met de boel in de PowerMac G5 case te bouwen en zien of alles het doet. Dan mijn huidige media zien te reduceren tot 2TB zodat mijn twee andere 2TB schijven uit de PC en in de NAS kunnen.

[batsma]

Firedrunk, ben je al iets verder gekomen met FreeBSD op hyper-v?

[FireDrunk]

Nog niet mee verder gegaan eerlijk gezegd, momenteel weer ESXi aangezet om wat andere meuk te kunnen doen. Zal er binnenkort weer eens tijd aan besteden, maar verwacht dat niet binnen 2-3 weken.

[FDMK]

Ik ga van het weekend mn productie home-nas uitbreiden van OSonUSB naar OSonSSD(M500) en van N4F naar ZFSguru brengen, althans dat is het plan. Voornamelijk om het gewoon weer een filebak te maken waar iedereen alles kan omdat het toch maar een media-lib/download bak wordt. Nu is het zo dat de huidige authenticatie gedaan wordt via de AD maar dat wil ik eruit hebben omdat het wel cool is maar verder geen enkel nut dient.
Een pool import en daarna alle rechten 777 laten inheritten is voldoende neem ik aan? Mn unix/bsd skills zijn niet zo hoog vandaar heb al eens een keer alles inaccessible gemaakt

[ Voor 12% gewijzigd door FDMK op 16-08-2013 17:01 ]

[Verwijderd]

Rechten lekker zo laten? Mocht je problemen tegenkomen graag een DM berichtje. Voordat je alles op 777 gooit, dat is viezzz.

[HyperBart]

Ligt het nu aan mij, of zijn dit rare getallen:

                  capacity     operations    bandwidth
pool           alloc   free   read  write   read  write
-------------  -----  -----  -----  -----  -----  -----
maxim          12.3T  3.90T  3.22K      0   412M      0
  raidz2       12.3T  3.90T  3.22K      0   412M      0
    gpt/disk1      -      -    462      0  52.2M      0
    gpt/disk2      -      -    826      0   103M      0
    gpt/disk3      -      -    460      0  51.9M      0
    gpt/disk4      -      -    459      0  51.5M      0
    gpt/disk5      -      -    867      0   103M      0
    gpt/disk6      -      -    462      0  52.2M      0
-------------  -----  -----  -----  -----  -----  -----

Zo gaat het een eindje door. Ik denk dat ik wel weet welke twee de parity disks zijn
Ik ga nog wat slapen.

Klopt toch niet dat 2 disks zo vlot mee doen en 4 andere zo traag?

Absolute snelheid is prima hoor, maar vond het gewoon gek.

[ssh@zfsguru /maxim/test]$ dd if=test.file of=/dev/null bs=1M
102400+0 records in
102400+0 records out
107374182400 bytes transferred in 242.691700 secs (442430386 bytes/sec)

[ Voor 16% gewijzigd door HyperBart op 16-08-2013 20:56 ]

[webfreakz.nl]

Je bedoelt 2 x 100 = 4 x 50?

[FireDrunk]

Er kunnen meerdere transacties tegelijk plaatsvinden binnen 1 transactie groep, en metadata word redundant opgeslagen, maar het is volgens mij niet verplicht dat deze ook echt in RAIDZ opgeslagen wordt, het kan volgens mij ook zijn dat deze in mirror opgeslagen word. Hierdoor kan er in een tweede transactie meer/andere data zitten dan een volledige stripe, en kunnen bepaalde disks drukker zijn dan andere.

On another note:

v7 (update 16-8-2013): Ik hoop dat ik al het recente commentaar heb verwerkt, zo niet, schreeuw even.

[ Voor 6% gewijzigd door FireDrunk op 16-08-2013 23:55 ]

[Phuncz]

Bedankt voor de overview, zeer interessant om te vergelijken en daardoor een goed afgewogen keuze te kunnen maken !

Hij staat nog niet in de Start Post

[u_nix_we_all]

FireDrunk schreef op vrijdag 16 augustus 2013 @ 23:55:

[...]
On another note:
[....]

Misschien handig om ook de versies van zpool die ondersteund worden erbij te zetten ? Of zelfs welke versie default gebruikt wordt ?

Edit:

Ik denk ook dat SmartOS onderhand een plekje op de lijst verdient. Bij OpenIndiana gebeurt niet zo veel meer geloof ik. Napp-it heb ik al een tijdje niet zoveel mee gedaan ook, maar die geeft nu ook SmartOS als preferred distro aan.

Ik vond deze video wel grappig, vooral het stukje vanaf ca 5:00

[ Voor 40% gewijzigd door u_nix_we_all op 17-08-2013 10:32 ]

[Phuncz]

Het begint al goed: nieuwste FreeNAS 9.1 RELEASE en blijkbaar hebben ze gekozen om 4K-drives enkel in theorie te ondersteunen maar niet in de praktijk. Resultaat: alle WD Green drives zijn 512B-alligned...

En als ik de pool manueel met ashift=12 probeer te maken krijg ik dit:

code:

[root@freenas ~]# zpool create -f -o ashift=12 zpool1 raidz2 /dev/ada0 /dev/ada1 /dev/ada2 /dev/ada3 /dev/ada4 /dev/ada5            
property 'ashift' is not a valid pool property
[root@freenas ~]#

En natuurlijk doet Google alsof zijn neus bloed en het FreeNAS forum doet ook niet meer dan opsommen dat je momenteel niet via de GUI in orde krijgt, maar geen bericht waarom het niet via command-line gaat.

Zal ik dan maar NAS4Free of ZFSGuru proberen ?

[Verwijderd]

Dat werkt zo niet, alleen middels een hack in OpenSolaris dacht ik.

Pool aanmaken in ZFSguru is het beste wat je kunt doen denk ik, en in FreeNAS importeren. Dan heb je ook partities, zoals het hoort, ipv ruwe devicenodes; dat is vies.

[u_nix_we_all]

Verwijderd schreef op zaterdag 17 augustus 2013 @ 11:52:
Dat werkt zo niet, alleen middels een hack in OpenSolaris dacht ik.

Dat was een aparte binary om met ashift=12 pools aan te maken, maar volgens mij kan dat inmiddels ook native.

Pool aanmaken in ZFSguru is het beste wat je kunt doen denk ik, en in FreeNAS importeren. Dan heb je ook partities, zoals het hoort, ipv ruwe devicenodes; dat is vies.

Ik ben er nog niet helemaal uit wat die beperking nu precies is. Ik weet dat ik met openindiana mijn rootpool op een Solaris slice heb staan, dus het is niet zo beperkt als veel mensen denken. Als ik eens tijd heb zal ik eens kijken of GPT en MS-DOS labels / partities ook gebruikt kunnen worden, maar ik neem aan van wel eigenlijk.
Volgens mij zijn het vooral de GUI's van Nexenta en Solaris die het niet ondersteunen ?

Hoe zit dat eigenlijk met FreeBSD, die gebruikt GPT neem ik aan ? Of zijn dat BSD-disklabels ? Hoe zit dat als je zo'n pool naar een IllumOS-based systeem wilt importeren ?


Edit
PS, waarom is dat vies ? Qua portabiliteit ben je niet afhankelijk van support voor partitietypes, en je gebruikt gewoon direct je hele disk. Via de blockdriver, niet raw vziw.

[ Voor 8% gewijzigd door u_nix_we_all op 17-08-2013 12:43 ]

[Ravefiend]

Phuncz schreef op zaterdag 17 augustus 2013 @ 11:30:
...
En natuurlijk doet Google alsof zijn neus bloed en het FreeNAS forum doet ook niet meer dan opsommen dat je momenteel niet via de GUI in orde krijgt, maar geen bericht waarom het niet via command-line gaat.

Zal ik dan maar NAS4Free of ZFSGuru proberen ?

Je kan eventueel doen op mijn manier:
Ravefiend in "Het grote ZFS topic"

Kwestie van een klein stukje in't begin van de disk te reserveren zodat al wat erna komt, je data dus, automatisch aligned is.

[Phuncz]

Verwijderd schreef op zaterdag 17 augustus 2013 @ 11:52:
Dat werkt zo niet, alleen middels een hack in OpenSolaris dacht ik.

Hmm bizar, dus FreeNAS 9.1 heeft gewoon geen mogelijkheid om 4K drives correct te benutten ? Wat een brol.

Pool aanmaken in ZFSguru is het beste wat je kunt doen denk ik, en in FreeNAS importeren. Dan heb je ook partities, zoals het hoort, ipv ruwe devicenodes; dat is vies.

Dan stap ik maar over op ZFSguru, deze blijkt wél bij de tijd te zijn. Helaas geen ervaring mee maar dat zal wel snel veranderen

Ravefiend schreef op zaterdag 17 augustus 2013 @ 12:37:
Je kan eventueel doen op mijn manier:
Ravefiend in "Het grote ZFS topic"

Kwestie van een klein stukje in't begin van de disk te reserveren zodat al wat erna komt, je data dus, automatisch aligned is.

Dit zal ik in overweging nemen, maar eerlijk gezegd ben ik erg teleurgesteld hoe slecht de ontwikkelaars van FreeNAS dit probleem hebben "aangekaart", aangezien hun oplossing onmogelijk als "getest" kan bezien worden. Van zo'n aanpak heb ik een hele afkeer.

[ Voor 33% gewijzigd door Phuncz op 17-08-2013 12:51 ]