Het grote ZFS topic

[0xygen]

Verwijderd schreef op vrijdag 17 augustus 2012 @ 21:01:

Performance vind ik lastig te zetten; test zoveel als je kan inclusief je fysieke disks. Dat RAID-Z2 veel CPU-kracht vergt is niet zo; een Brazos kan prima een 6-disk RAID-Z2 met scores ver boven de gigabit aan. Jouw scores zijn wat teleurstellend.

Verder: als je netwerkthroughput terugvalt (check dit met task manager > network) is dit een probleem met ZFS transaction groups als je merkt dat de netwerktransfer af en toe stil staat, en later weer verder gaat. Gemiddeld kom je dan maar aan een lage score. In dit geval krijgt ZFS de data niet snel genoeg weggeschreven.

Test al je schijven ook even los met de simple disk benchmark, soms kan het zijn dat één schijf trager is dan de rest en een hele array/pool naar beneden trekt.

Maar, begin eens met een andere netwerkcontroller, dat kan het ook zijn. Een Intel PRO/1000 CT kaartje (PCIe x1) is een uitstekende koop voor iets meer dan twee tientjes. Als je een los kaartje koop; koop dan alleen Intel!

Inmiddels heb ik het PRO/1000 CT kaartje besteld, dus ik kan vanaf donderdag pas testen of dat veel uithaalt (ik ben van dinsdag tot donderdag een paar daagjes weg)

Verder heb ik benchmarks gemaakt van alle disks individueel waarbij ik geen grote verschillen waarneem in resultaat.


Ook heb ik even het netwerk gemonitord met dit resultaat:


Er zitten dus inderdaad van die dipjes in...
Ik ga nu de server rebooten en doe dan nog wat tests.


Wat mij aan de laatste test opvalt is dat hij eerst wel de volle snelheid haalt (ik denk dat hij dan naar de RAM toe schrijft??) waarna hij daarna invalt. Hierdoor lijkt het er op dat het probleem dus in ZFSguru zit en niet in de server of de PC of netwerkkaart.

[ Voor 9% gewijzigd door 0xygen op 18-08-2012 12:40 ]

[Phasis]

Verwijderd schreef op zaterdag 18 augustus 2012 @ 11:35:
@Phasis: als je inlogt met SSH (of via console>Shell) en je doet iets als:
/usr/local/etc/rc.d/samba start

wat zie je dan?

code:

$ /usr/local/etc/rc.d/samba start
Removing stale Samba tdb files:  done
nmbd already running? (pid=761).
Starting smbd.
/usr/local/etc/rc.d/samba: WARNING: failed to start smbd

Dat geeft nog niet veel duidelijkheid volgensmij

[Sleepie]

Kijk eens in je samba logs of er aangegeven wordt waarom Samba niet wil starten:

code:

tail /var/log/samba/log.smbd

[Phasis]

Sleepie schreef op zaterdag 18 augustus 2012 @ 13:08:
Kijk eens in je samba logs of er aangegeven wordt waarom Samba niet wil starten:

code:

tail /var/log/samba/log.smbd

code:

$ tail /var/log/samba/log.smbd 
  ERROR: failed to setup guest info.
[2012/08/18 09:16:32,  0] smbd/server.c:1140(main)
  smbd version 3.5.9 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2010
[2012/08/18 09:16:32.792336,  1] smbd/files.c:193(file_init)
  file_init: Information only: requested 855000 open files, 59392 are available.
[2012/08/18 09:16:32.799616,  0] passdb/pdb_interface.c:259(guest_user_info)
  guest_user_info: Unable to locate guest account [share]!
[2012/08/18 09:16:32.799669,  0] smbd/server.c:1272(main)
  ERROR: failed to setup guest info.

[webfreakz.nl]

We hoeven je hand toch niet vast te houden?

http://smithfarm-thebrain...est-account-smbguest.html ?

[Phasis]

Phasis schreef op zaterdag 18 augustus 2012 @ 13:16:
[...]

code:

$ tail /var/log/samba/log.smbd 
  ERROR: failed to setup guest info.
[2012/08/18 09:16:32,  0] smbd/server.c:1140(main)
  smbd version 3.5.9 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2010
[2012/08/18 09:16:32.792336,  1] smbd/files.c:193(file_init)
  file_init: Information only: requested 855000 open files, 59392 are available.
[2012/08/18 09:16:32.799616,  0] passdb/pdb_interface.c:259(guest_user_info)
  guest_user_info: Unable to locate guest account [share]!
[2012/08/18 09:16:32.799669,  0] smbd/server.c:1272(main)
  ERROR: failed to setup guest info.

Thanks webfreakz.

code:

sudo edit /usr/local/etc/smb.conf

verander guest account naar: nfs

code:

sudo /usr/local/etc/rc.d/samba start

[ Voor 95% gewijzigd door Phasis op 18-08-2012 15:00 ]

[wjn]

Verwijderd schreef op zaterdag 18 augustus 2012 @ 11:35:
@wjn: de checksum is vooral cruciaal als je dedup gebruikt omdat anders je data gecorrumpeerd wordt. Maar dan is fletcher + verify beter omdat met verify er wordt gechecked of er een collission is. De corruptie-bescherming zonder dedup werkt prima met Fletcher2, SHA256 is veel zwaarder voor de CPU en dus ook voor readacties die dan een hogere latency krijgen. Als je CPU accelerated SHA256 doet is dit wel gaaf natuurlijk, of als je het hoogste niveau van corruptiebescherming wilt.

Maar het is niet zo erg zonder dedup als twee files dezelfe checksum delen. Wel als je dedup aan hebt staan (of had staan).

Ik ben een beetje aan het testen met ZFSGuru met verschillende instellingen.

Met de huidige NAS heb ik verschillende volumes, waarvan ééntje backup (voor backup van laptops & pc's). Voor die toepassing dacht ik een apart filesystem "backup" aan te maken en de checksum daarvan op SHA256 te zetten. Snelheid etc. maakt toch niet zoveel uit.

Met SHS256 aan gaat het idd wat trager dan Fletcher2. Als test kopieer ik vanaf laptop (SSD) naar de NAS, ca. 77GB aan ISO bestanden van DVD's (dat is dus al grotendeels gecomprimeerde data). Met Fletcher2 / geen compressie is de gigabit verbinding praktisch vol, duurt ca. 12,5 minuten (ca. 100MB/s)
SHA256 + G-ZIP6: 28 minuten (ca. 45MB/s)
SHA256 + LZJB: 17 minuten (ca. 75MB/s)
SHA256 / geen compressie: 15,5 minuten (ca. 82MB/s)

Denk dat ik die laatste instelling pak, aangezien de meeste backup's al uit gecomprimeerde files bestaan.

[Megalith]

Ik ben begonnen met mijn ZFS build. Twee IBM M1015's geflashed naar IT firmware en m'n norco eens mooi opgepoetst. Ik gebruik tien Samsung HD204UI schijven (4K sectors) en heb de pool daarom aangemaakt in ZFSguru om daarna te switchen naar OpenIndiana. De benchmarks zijn niet altijd even consequent. Hoewel ik er in de praktijk waarschijnlijk bar weinig van ga merken vielen de resultaten toch een héél klein beetje tegen. Ik had ongeveer 100MB's meer verwacht.
Wat ik vooral opvallend vind, is dat de sequential write sneller is dan de read performance

code:

ZFSguru 0.2.0-beta5 pool benchmark
Pool            : discovery (18.1T, 0% full)
Test size       : 64 GiB
Data source     : /dev/zero
Read throughput : 633.7 MB/s = 604.4 MiB/s
Write throughput: 741.6 MB/s = 707.2 MiB/s

Ik heb er 16GB RAM inzitten en het aggressive tuning profile aanstaan. (75% v/h RAM gebruiken voor ZFS)

[ Voor 5% gewijzigd door Megalith op 20-08-2012 19:41 ]

[Verwijderd]

Gebruik je RAID-Z of RAID-Z2? Als je ZFSguru installeert op USB-stick of losse schijf kun je de advanced disk benchmark gebruiken om je ideale pool configuratie te vinden. 2x RAID-Z bijvoorbeeld, 1x RAID-Z2 van 10 disks. Mijn voorkeur zou uitgaan naar die laatste, maar dan heb je wel 128K / 8 = 16KiB request size per disk wat het iets trager maakt. Dus in dat opzicht zijn je scores juist heel goed. Zou je 2x RAID-Z testen zie je hogere scores; je disks doen dan 32KiB requests en dat is efficienter. Vanaf 64K zou je verzadiging moeten krijgen (3-disk RAID-Z).

Met FreeBSD 9 kun je ook beter geen tuning toepassen, dan laat je FreeBSD zelf de tuning doen. Dat werkt wel aardig goed geloof ik; al wil ik nog specifieke tests doen.

[ Voor 13% gewijzigd door Verwijderd op 20-08-2012 20:17 ]

[Megalith]

Vergeten te vermelden, maar ik heb een pool van tien schijven in RAIDZ2. In deze situatie was het mooi geweest als je de de stripe size aan kon passen naar 256K (denk ik).

Vind het gewoon apart dat schrijven sneller is dan lezen, wat toch vaak andersom is. Ik ben nog iets aparts tegengekomen; de SMART data van mijn twee nieuwe Intel 330 60GB SSD's zegt dat de lifetime een paar miljard jaar is. Jammer dat ik net OI heb geinstalleerd want ik ben toch wel benieuwd naar die advanced benchmarking.

[wjn]

ff inhaken:
Kon je in zfsguru via disks->advanced de schijven benaderen (voor APM) die aan de M1015 zitten?
Bij mij werkt dat niet, smart werkt wel, advanced (camcontrol) kan de schijven wel benaderen voor "inquiry", maar "identify" werkt niet.

Edit: M1015 is gefalshed naar IT mode, ik heb niet de ROM geflashed omdat ik toch niet van de schijven in de pool wil opstarten. Dat gebeurt van schijven die op de controllers van het mainboard zijn aangesloten.

[ Voor 30% gewijzigd door wjn op 20-08-2012 22:32 ]

[Megalith]

@wjn
Nee dat lukt bij mij inderdaad ook niet, en ik heb de ROM van de M1015 ook niet geflashed.

De SSD's zijn trouwens allemaal aangesloten op de Intel chipset dus daar kan het niet aan liggen.

[wjn]

fcg123 schreef op maandag 20 augustus 2012 @ 22:46:
@wjn
Nee dat lukt bij mij inderdaad ook niet, en ik heb de ROM van de M1015 ook niet geflashed.

De SSD's zijn trouwens allemaal aangesloten op de Intel chipset dus daar kan het niet aan liggen.

Thanks, ben nu aan het testen met het tooltje "spindown".

[EnerQi]

Beste Tweakers,

Een kleine maand geleden heb ik een NAS gemaakt op basis van ZFSguru beta 6.
Om productieproblemen/uitval te voorkomen, bestel ik 1 harde schijf per week bij verschillende leveranciers

De build:

#	Product	Prijs	Subtotaal
1	Intel Celeron G530 Boxed	€ 38,70	€ 38,70
6	Seagate Barracuda 7200.14 ST3000DM001, 3TB	€ 139,-	€ 834,-
1	Antec Three Hundred Two	€ 54,90	€ 54,90
1	FSP Aurum Gold 400	€ 57,70	€ 57,70
2	Kingston KVR1333D3N9/8G	€ 34,90	€ 69,80
1	MSI B75MA-P45	€ 57,56	€ 57,56
Bekijk collectie Importeer producten		Totaal	€ 1.112,66

Ik heb verschillende testjes gedaan waaruit het volgende uitkomt, gemeten met de Voltcraft Energy monitor 3000
NAS uit: 0 tot 0,1 watt
Stroomverbruik zonder harde schijf, idle: 34 watt piekspanning, 20,7/21,7 idle
Stroomverbruik zonder harde schijf, low speed casefan, idle: 19,8/20,6
btw, op low start de casefan niet op, te weinig aandrijving voor de eerste keer ronddraaien

Stroomverbruik met 1 harde schijf (en usbstick): 52 watt piekspanning, 34/35 watt normaal bij activiteit, 26 watt in idle stand.
3 harde schijven: 89 watt piekspanning, 49 watt normaal bij activiteit (in dit geval opstarten ), 40 watt bij idle stand.

De idle stand is harde schijf opgespind, CPU niet actief (400 Mhz), 1 casefan actief (high speed, tenzij anders aangegeven) en niet actief naar schijven, overigens is er getest met 1 ram latje.

En vervolgens een vraagje:
Nu wil ik van deze NAS ook een backup maken (1:1 kopie) en dit wil ik doe door middel van een HD dock en losse schijven (of externe schijven, net wat het goedkoopst is ) aan die NAS.

Nu komt het probleem dat ik geen "verkenner" in ZFSguru kan vinden om de files te kopieren van de NAS naar externe schijf. Nu kan ik natuurlijk een backup maken via een andere pc in het netwerk, maar hierdoor belast ik 1) het netwerk voor tig minuten 2) mogelijke (extra) data lost/corruptie doordat er 2 pc's gebruikt worden in die actie (ipv 1 )

P.s. de externe schijven zullen gewoon het NFTS bestandssysteem bevatten zodat ik niet afhankelijk ben van de NAS om het uit te lezen.

[ Voor 0% gewijzigd door EnerQi op 22-08-2012 20:10 . Reden: knullige typfout ]

[ransbal]

Om productieproblemen/uitval te voorkomen, bestel ik 1 harde schijf per week bij verschillende leveranciers

Ik ben benieuwd hoe grote OEM's die duizenden disks per dag in PC's, Laptops, Servers en andere apparatuur drukken, hier dan mee om gaan

[webfreakz.nl]

ransbal schreef op woensdag 22 augustus 2012 @ 20:56:
[...]

Ik ben benieuwd hoe grote OEM's die duizenden disks per dag in PC's, Laptops, Servers en andere apparatuur drukken, hier dan mee om gaan

Cold spares, hot spares, meerdere lagen redundantie, etc. (voor servers dan )

[ Voor 3% gewijzigd door webfreakz.nl op 22-08-2012 20:59 ]

[Durandal]

ransbal schreef op woensdag 22 augustus 2012 @ 20:56:
[...]

Ik ben benieuwd hoe grote OEM's die duizenden disks per dag in PC's, Laptops, Servers en andere apparatuur drukken, hier dan mee om gaan

Die zetten geen 6 disks van dezelfde batch in dezlefde PC, maar 1 in elke afzonderlijke PC.

Ik heb een 4x1TB disk Raid5 gehad waarbij er 2 kapot gingen binnen anderhalf uur. Wel een waarschuwingsmail naar de eerste maar je gaat niet elk uur in je mailbox kijken. Resultaat alles kwijt. Bij nader onderzoek bleek dat de andere 2 disks ook op sterven stonden.
Alle 4 de disks op hetzelfde moment gekocht en waren volgens de serienummers ook van dezelfde batch. Zo onverstandig is het dus niet om disks uit verschillende batches te kopen.

Omgeruild voor 4x1.5TB seagate refurbished, en die draaien al jaren zonder problemen.

[sloth]

Ik kwam net tijdens mijn zoektocht naar de performance van ZFS via Samba / NFS / FTP op basis van een platform met beperkte cpu resources uit op een post waarin een aantal samba, ZFS en sysctl tunings in staan:

http://lists.freebsd.org/...2011-February/061642.html

Mogelijk ook interessant voor jullie? Zelf kan ik ze helaas nog niet uittesten.

[EnerQi]

Durandal schreef op woensdag 22 augustus 2012 @ 21:11:
[...]
Ik heb een 4x1TB disk Raid5 gehad waarbij er 2 kapot gingen binnen anderhalf uur. Wel een waarschuwingsmail naar de eerste maar je gaat niet elk uur in je mailbox kijken. Resultaat alles kwijt. Bij nader onderzoek bleek dat de andere 2 disks ook op sterven stonden.
Alle 4 de disks op hetzelfde moment gekocht en waren volgens de serienummers ook van dezelfde batch. Zo onverstandig is het dus niet om disks uit verschillende batches te kopen.

Dat is de reden , gewoon het risico verkleinen + minder grote uitgaven in 1x

[dutch_warrior]

Ik heb even een vraagje over het aansluiten van mijn schijven.
Mijn moederbord heeft 6x Sata600 via AMD SB950 en 2x Sata300 + 2x e-sata via een jmicron MB362 controller. Om te beginnen wil ik 3x 2.0TB WD ears schijven gebruiken, kan ik de eerste twee schijven aansluiten op de jmicron controller en de derde schijf op een sata 600 poort? De 3 schijven vormen samen in raidz vdev.
Ik meen me te herinneren dat dit in principe niet zou moeten uitmaken, de Sata600 poorten wil ik graag vrijhouden voor een toekomstige SSD pool.

[ Voor 16% gewijzigd door dutch_warrior op 23-08-2012 21:47 ]

[FireDrunk]

Je kan ze later toch sowieso nog omprikken? tis niet dat die dingen vastgeplakt zitten na een week ofzo
Of de JMicron supported is onder FreeBSD weet ik zo niet.

[dutch_warrior]

Ja ik weet wel dat ik ze kan omprikken maar ik was vooral benieuwd of dit mogelijk problemen kon opleveren qua betrouwbaarheid of performance. Ik heb wel eens minder positieve verhalen gelezen over dit soort extra controllers op een moederbord.

Het werkt in ieder geval wel, ik kon alle disken netjes zien en zelfs de nog aanwezige pool op deze disken zou ik kunnen importeren.

[FireDrunk]

Je zal CiPHER even moeten poken of die JMicron goed ondersteund is, die weet dat uit z'n hoofd

[Verwijderd]

Ik loop wat achter met mijn berichten hier, maar over die JMicron: die werken prima in FreeBSD al lange tijd. Althans de JMB363 maar ik verwacht niet dat de 362 veel zal verschillen. Silicon Image doet het ook erg goed qua drivers; de nieuwe siis driver is as good as it gets voor deze low-end chips. JMicron heb ik ook een paar PCIe kaartjes van en dat draait prima.

Besef wel dat ze je pool kunnen afremmen, door hogere latencies. Dit is met name voor RAID-Z een probleem. De transfercap zit rond de 120MB/s, waardoor ik vermoed dat het een PCI chip is met interne bridge ofzoiets. Kan ook gewoon toeval zijn. Maar Silicon Image SiI-3132 heeft hetzelfde, dus ik vermoed dat het toch PCI chips zijn die naar PCIe zijn gebridged.

[dutch_warrior]

Oke bedankt voor de info, ik zal binnenkort eens even testen wat het verschil is in prestaties tussen alle schijven op de sata600 poortjes of twee schijven op de jmicron sata300 poortjes.

Kan ik eigenlijk een open indiana pool (oi build 148 zpool v28) gebruiken in zfsguru?
Ik kan hem wel importeren en kan ok wel het hoofd filesystem delen en benaeren via sama, als ik echter het data filesystem deel en via het netwerk wil benaderen crasht de server.
Er flitsen een boel meldingen voorbij waarna de console zwart wordt en het hele systeem nergens meer op reageert. Probeer ik iets onmogelijks te doen of moet ik in logfiles gaan zoeken naar een aanleiding voor deze crash?

[Megalith]

Ik heb vorige week twee nieuwe Intel 330 60GB ssd's besteld. Deze hangen nu in m'n norco case aangesloten op de SATA backplane maar de lifetime van deze twee dingen geeft wel hele abnormale waardes aan. De RAW value verhoogt om de seconde met enkele tientallen biljoenen.



Ook valt het me op dat er wel erg veel gespammed wordt. Vooral de da10 en da02 willen nog wel eens SCSI meldingen geven.

[Verwijderd]

Wat zegt je Power_On_Hours dan precies? Waarschijnlijk is de SMART voor die schijf gewoon anders ge-encode, dus een raw value van 1440 betekent niet 1440 power-on-hours. Bijvoorbeeld een getal als 43847987 kan een temperatuur zijn met meerdere metingen. Binary encoded noem ik dat maar.

En je mps fouten; draai je de oude 9.0-xxx system image? zo ja: bekend probleem. Upgraden naar 9.1-xxx die hebben nieuwe mps driver.

[Megalith]

Ik stop de SSD nu even in m'n Windows PC. Wat jij zegt zal wel de meest logische verklaring zijn. Of het moet uitmaken dat ze op de twee SATA 600 poorten zijn aangesloten.

Heb er inderdaad nog 9.0 opstaan, zal eens zien of ik een beetje makkelijk kan updaten :-)

EDIT: oja, het disk activity LED'je van de ssd's is ook continue blauw. Misschien zegt het niks hoor, de I/O monitor in ZFSguru vertelt me dat ze aan het niksen zijn, 0% activity.

[ Voor 25% gewijzigd door Megalith op 23-08-2012 23:10 ]

[Verwijderd]

Even een waarschuwing: je hebt beta6 of hoger nodig wil je de 9.1-002 system image gebruiken! Je kunt dan het beste de livecd gebruiken die in deze thread als URL staat: http://zfsguru.com/forum/zfsgurudevelopment/428.

En je SSDs zijn onboard aangesloten toch? Anders zou je 'da' zien ipv 'ada'.

[ Voor 15% gewijzigd door Verwijderd op 23-08-2012 23:22 ]

[Megalith]

De Intel Toolbox geeft als Raw value voor Power on hours count 894808. Zoveel uren zitten er niet in de week dat ik 'm heb :-)

Morgen ga ik de update installeren aangezien hij nu nog data aan het overpompen is. Wel jammer dat ik dan al m'n instellingen weer kwijt ben (LAGG, users etc). Is het sowieso niet mogelijk om de schijven die aan de M1015 hangen als AHCI apparaten te benaderen?

[Sleepie]

Klein vraagje:
Het valt me op dat bij elke scrub job die ik uitvoer er altijd wel een hele kleine hoeveelheid repairs plaatsvindt, zo rond de 200-300K repaired.

Is hier een verklaring voor te vinden en moet ik me zorgen maken om bv. slechte schijven ofzo?

[Snow_King]

Sleepie schreef op donderdag 23 augustus 2012 @ 23:57:
Klein vraagje:
Het valt me op dat bij elke scrub job die ik uitvoer er altijd wel een hele kleine hoeveelheid repairs plaatsvindt, zo rond de 200-300K repaired.

Is hier een verklaring voor te vinden en moet ik me zorgen maken om bv. slechte schijven ofzo?

Hoe ziet je pool er uit?

Dit moet in principe niet gebeuren namelijk.

Ik draai een aantal grote pools van 20TB (Nexenta) waar elke maand een scrub overheen gaat, daar is in 1.5 jaar nog nooit een repair geweest.

Als er dus elke keer 200 tot 300K gerepareerd wordt zou ik me wel zorgen maken.

[Sleepie]

Pool is een 10 disk RAIDZ2 pool, waarmee ik in t dagelijks gebruik eigenlijk nog nooit problemen heb gehad.
Maar het is inderdaad opvallend dat er elke keer iets gerepareerd wordt.

Wat zou ik er aan kunnen doen om er achter te komen wat er precies mis is?

[Snow_King]

Sleepie schreef op vrijdag 24 augustus 2012 @ 00:03:
Pool is een 10 disk RAIDZ2 pool, waarmee ik in t dagelijks gebruik eigenlijk nog nooit problemen heb gehad.
Maar het is inderdaad opvallend dat er elke keer iets gerepareerd wordt.

Wat zou ik er aan kunnen doen om er achter te komen wat er precies mis is?

Kan je eens een "zpool status" posten?

Zie je verder in je kernel buffer ($ dmesg) toevallig foutmeldingen over disks?

Het lijkt me dat er een disk niet helemaal lekker is en errors aan het geven is.

[Sleepie]

zpool status momenteel (scrub job running)

code:

[ssh@wega /home/ssh]$ zpool status tank
  pool: tank
 state: ONLINE
 scan: scrub in progress since Thu Aug 23 15:22:16 2012
    9.78T scanned out of 10.1T at 426M/s, 0h14m to go
    236K repaired, 96.54% done
config:

        NAME              STATE     READ WRITE CKSUM
        tank              ONLINE       0     0     0
          raidz2-0        ONLINE       0     0     0
            label/disk5   ONLINE       0     0     0
            label/disk10  ONLINE       0     0     0
            label/disk1   ONLINE       0     0     0
            label/disk2   ONLINE       0     0     0
            label/disk3   ONLINE       0     0     0
            label/disk4   ONLINE       0     0     0
            label/disk6   ONLINE       0     0     0
            label/disk7   ONLINE       0     0     0
            label/disk8   ONLINE       0     0     0
            label/disk9   ONLINE       0     0     0  (repairing)

errors: No known data errors

dmesg had ik nog niet aan gedacht, dat ziet er verdacht uit:

code:

(da7:mpt0:0:7:0): READ(10). CDB: 28 0 7c d8 6e 88 0 0 32 0
(da7:mpt0:0:7:0): CAM status: SCSI Status Error
(da7:mpt0:0:7:0): SCSI status: Check Condition
(da7:mpt0:0:7:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error)
(da7:mpt0:0:7:0): Info: 0x7cd86eb5
(da7:mpt0:0:7:0): READ(10). CDB: 28 0 7c d5 9c 30 0 0 53 0
(da7:mpt0:0:7:0): CAM status: SCSI Status Error
(da7:mpt0:0:7:0): SCSI status: Check Condition
(da7:mpt0:0:7:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error)
(da7:mpt0:0:7:0): Info: 0x7cd59c4a
(da7:mpt0:0:7:0): READ(10). CDB: 28 0 7d 5 fb 1b 0 0 e1 0
(da7:mpt0:0:7:0): CAM status: SCSI Status Error
(da7:mpt0:0:7:0): SCSI status: Check Condition
(da7:mpt0:0:7:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error)
(da7:mpt0:0:7:0): Info: 0x7d05fb5b
(da7:mpt0:0:7:0): READ(10). CDB: 28 0 7c f9 c7 20 0 0 e1 0
(da7:mpt0:0:7:0): CAM status: SCSI Status Error
(da7:mpt0:0:7:0): SCSI status: Check Condition
(da7:mpt0:0:7:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error)
(da7:mpt0:0:7:0): Info: 0x7cf9c7e0

Ik zie nu ook op de SMART status pagina in ZFSGuru 33 Current Pending Sectors.

Worden die nu automatisch hersteld (dan zouden die 200-300K repaired data toch moeten verdwijnen?) ....

Ik snap het ff niet meer

[ Voor 43% gewijzigd door Sleepie op 24-08-2012 00:15 ]

[dutch_warrior]

Zoals ik eerder al zei heb ik dus een geïmporteerde pool (zpool v28 afkomstig van een OI_148 systeem).Deze pool heeft twee filesystems, het hoofdbestandssysteem en een bestandssysteem genaamd data waarin een goede terabyte aan (niet belangrijke!) data staat.

Ik kan de data onder het hoofdbestandsysteem inzien, een scrub op de pool loopt ook gewoon alleen wanneer ik het data filesystem aanroep slaat het systeem vast. Ook een ls commando in het mountpoint van het data bestandsysteem laat het systeem vastslaan.
Probeer ik nu iets onmogelijks te doen of is dit een raar probleem? Helaas wordt er niets gelogd, ik zie wel een paar regels over het scherm flitsen net voor het vastslaan maar deze regels lijken opgebouwd te zijn uit willekeurige karakters, het is in ieder geval geen engelse tekst .
Ik ga de pool morgen destroyen en een nieuwe aanmaken want de data an sich heb ik niet nodig die had ik al eerder op een paar losse schijven gezet. Het was gewoon puur als leermoment om even te kijken of ik zomaar een pool van een solaris based os kon importeren.

[ Voor 11% gewijzigd door dutch_warrior op 24-08-2012 00:21 ]

[Verwijderd]

@sleepie: je hebt dus last van pending sectors en ZFS beschermt je hier perfect tegen! ZFS veroorzaakt dus wel die read timeouts, maar leest gewoon van de andere disks en schrijft dan de data ook naar de disk met de bad sector, die dan overschreven wordt en automatisch gefixed. Merk op dat dit bijna altijd geen échte bad sectors zijn; gewoon amnesia van de huidige generatie 2TB+ schijven met hoge datadichtheid.

Om deze reden wil je dus ZFS gebruiken. Je kunt gewoon doorwerken en als je maar eens in de zoveel tijd een scrub doet, zit je prima. Zeker met RAID-Z2 heb je gewoon uitstekende bescherming tegen bad sectors; je bent er vrijwel immuun voor.

Let wel: er kunnen ook bad sectors / pending sectors zijn in gebieden die ZFS niet in gebruik heeft. Als je op de SMART-pagina pending sectoren ziet zelfs nádat je een scrub hebt uitgevoerd, dan zijn die sectoren simpelweg niet in gebruik. Dit heb ik bij een familielid op 3 van de 6 schijven met WD EARX. Het is ook een teken dat de schijf aan background surface scans doet, niet álle schijven doen dat en vinden dus pending sectoren die onleesbaar zijn omdat ze al heel lang niet in gebruik zijn.

Kortom: niets aan de hand, ZFS is chill.

[Sleepie]

Verwijderd schreef op vrijdag 24 augustus 2012 @ 00:40:
@sleepie: je hebt dus last van pending sectors en ZFS beschermt je hier perfect tegen! ZFS veroorzaakt dus wel die read timeouts, maar leest gewoon van de andere disks en schrijft dan de data ook naar de disk met de bad sector, die dan overschreven wordt en automatisch gefixed. Merk op dat dit bijna altijd geen échte bad sectors zijn; gewoon amnesia van de huidige generatie 2TB+ schijven met hoge datadichtheid.

Ik weet dat ZFS hiertegen beschermt, da's de reden dat ik na mijn mdadm debacle overgestapt ben.
Overigens gebruik ik 1.5TB schijven, maar dat zal niet veel verschil maken.

Om deze reden wil je dus ZFS gebruiken. Je kunt gewoon doorwerken en als je maar eens in de zoveel tijd een scrub doet, zit je prima. Zeker met RAID-Z2 heb je gewoon uitstekende bescherming tegen bad sectors; je bent er vrijwel immuun voor.

Ook dat weet ik op zich wel, maar het is en blijft frappant dat er bij elke scrub job zo'n 200-300K aan data repaired moet worden.
Ook zie ik de bad sectors niet verdwijnen overigens (gelukkig komen er ook niet echt bij, af en toe eens eentje maar dat lijkt me geen probleem).

Let wel: er kunnen ook bad sectors / pending sectors zijn in gebieden die ZFS niet in gebruik heeft. Als je op de SMART-pagina pending sectoren ziet zelfs nádat je een scrub hebt uitgevoerd, dan zijn die sectoren simpelweg niet in gebruik. Dit heb ik bij een familielid op 3 van de 6 schijven met WD EARX. Het is ook een teken dat de schijf aan background surface scans doet, niet álle schijven doen dat en vinden dus pending sectoren die onleesbaar zijn omdat ze al heel lang niet in gebruik zijn.

Kortom: niets aan de hand, ZFS is chill.

Ik blijf ze dus inderdaad zien (1 disk met 2 stuks bad sectors, nu eentje met 33) na een scrub job.

Waar het mee begon en wat me opviel is dus die 200-300K data die elke scrub job weer gerepaired wordt.
Dan ga ik toch denken dat er iets mis is ergens.....ondanks dat ZFS chill is en het ongetwijfeld wel opvangt (ik heb er 100% vertrouwen in), wil ik bij zoiets toch wel graag weten waar het nu vandaan komt.

Ik zal als zometeen de scrub job klaar is eens noteren hoeveel data er exact repaired is en dan meteen een volgende scrub job laten lopen vannacht.
Het zou me niet verbazen als het weer exact dezelfde hoeveelheid data is de repaired wordt ... en dat vind ik ondanks alles gewoon vreemd

[Verwijderd]

Je zult wel RAM-corruptie moeten uitsluiten met MemTest86+. Maar dat je nu pending sectors hebt ná je scrub betekent dat die sectoren geen probleem hebben kunnen veroorzaken. In de toekomst worden ze willekeurig een keer overschreven. Zou je je pool met een bestand met allemaal nullen volschrijven en daarna verwijderen, dan zouden ze weg moeten zijn. Maar ik vind dat zelf onnodig.

Wat wel zo is... als je regelmatig een scrub doet, dan zie je de bad sectors niet in de SMART. Want ZFS lost ze gelijk op, en je ziet ook geen 'Reallocated Sector Count' verhoogd worden, want dat gebeurt alleen bij fysiek beschadigde sectoren. Dit type bad sectors is van het type 'onvoldoende bitcorrectie; ECC fout' ofwel het steeds populairder wordende uBER probleem. De datadichtheid neemt toe maar het absoluut aantal bitfouten per stuk data blijft gelijk.

Wil je de bad sectors kunnen zien, dan zou je nou een tijd niet moeten scrubben. Dan doe je eens een dd read op alle disks. Dat kan terwijl het systeem draait; lekker veilig want je mag er dan ook niet naar schrijven. Zoiets als 'dd if=/dev/ada0 of=/dev/null bs=1m conv=noerror &' die conv is belangrijk want met 'noerror' gaat dd lekker vrolijk door, precies wat je wilt dus.

Doe dat voor alle disks en ga naar de Disks->SMART pagina in ZFSguru. Dan zou je wél hogere pending sectoren moeten zien, die weggaan als je een scrub doet. Maar als je de scrub doet en dan past kijkt naar SMART, dan zie je die bad sectors die ZFS corrigeert dus niet. Ook niet allemaal als je vóór een scrub naar de SMART kijkt omdat je niet weet of de schijf autonoom op de achtergrond alle sectoren inmiddels gescand heeft. Dat gaat denk ik in een rustig tempo af en toe eens wat wanneer de schijf idle is. Met die dd surface read doe je dus leesacties buiten ZFS om, om zo bad sectors op te sporen.

Misschien wel een leuke toevoeging voor de SMART pagina? Een simpele surface scan voor bad sectors?

[FireDrunk]

@CiPHER, is het niet een idee om de historie van SMART data op te slaan? Dus zeg elk uur pollen en wegschrijven zodat je kan zien wanneer sectoren opgetreden zijn, en dus automatisch ook wanneer ze door een scrub opgeruimd zijn?

_{Waren de SMARTmontools problemen al opgelost?}

[iRReeL]

Ik heb inmiddels 7 disks met active bad sectors in mijn pool (van 10) 5,20,70,87,106,187,980). Die met 980 heeft nu ook 413 passive bad sectors. Tijdens een replace van die disk waren er iets van 6K corrupt data. Ik probeer dit weekend de disk met de WD tool te checken.

Ik probeer ook de bad sectors een beetje bij te houden en sla het regelmatig op in een bestandje zodat ik het een beetje kan volgen.

[fluppie007]

FireDrunk schreef op vrijdag 24 augustus 2012 @ 09:33:
@CiPHER, is het niet een idee om de historie van SMART data op te slaan? Dus zeg elk uur pollen en wegschrijven zodat je kan zien wanneer sectoren opgetreden zijn, en dus automatisch ook wanneer ze door een scrub opgeruimd zijn?

_{Waren de SMARTmontools problemen al opgelost?}

Dat lijkt me ook een mooie, kan je grafiekjes genereren van pending/bad sectors e.d. als ook het temperatuur loggen van je schijven. Tof idee!

[Brains]

Dergelijke wensen kunnen met tools als MRTG, Cacti, Nagios en Zabbix worden bijgehouden. Je krijgt dan grafiekjes als:

[FireDrunk]

Maar dat is een beetje overkill om onder ZFSguru te draaien...

[Brains]

Nadeel van zoiets is dat het systeem nooit zal gaan "slapen". Weer ook niet of de intervallen op te rekken van zijn seconden naar uren.

[FireDrunk]

Hoezo? Smart opvragen spint de disk toch niet op?

[Verwijderd]

Volgens mij helaas wel, maar je kunt met SMART eerst 'querien' of de schijf aan het slapen is. Dan sla je de meting gewoon over voor die disk. Of dat nodig is voor alleen een smartctl -A commando weet ik niet, want je hebt gelijk dat alleen het electrische gedeelte hiervoor in actie hoeft te komen, althans zo zegt mijn verstand. Maar het is specifiek ingebouwd in smartmontools dus er zal wel een reden voor zijn.

Manpage van smartmontools:

-n POWERMODE, --nocheck=POWERMODE
[ATA only] Specifies if smartctl should exit before performing
any checks when the device is in a low-power mode. It may be
used to prevent a disk from being spun-up by smartctl. The power
mode is ignored by default. A nonzero exit status is returned
if the device is in one of the specified low-power modes (see
RETURN VALUES below).

Note: If this option is used it may also be necessary to specify
the device type with the '-d' option. Otherwise the device may
spin up due to commands issued during device type autodetection.

En SMART opslaan: ja dat idee is er al langer. Jason wilde dat pas doen als de task manager er is, dan kan zoiets automatisch op de achtergrond draaien net als andere onderhoudstaken. En dus ook langzaam een historie opbouwen die grafisch weergegeven kan worden. Eén image voor alle schijven als je nog geen schijf hebt gedetecteerd: je ziet dan met name de temperatuur van alle schijven. En een image per schijf voor alle SMART attributen, zodat je verschillen kunt opmerken over een tijdsperiode.

Ook kun je daar aan koppelen waarschuwingsmailtjes.

@ iRReeL: 413 passieve bad sectors is wel een goede waarschuwing; dat is meer dan gebruikelijk en indien mogelijk zou ik die schijf laten omwisselen nu je nog garantie hebt.

[ Voor 25% gewijzigd door Verwijderd op 24-08-2012 13:12 ]

[Sleepie]

Verwijderd schreef op vrijdag 24 augustus 2012 @ 01:22:
Je zult wel RAM-corruptie moeten uitsluiten met MemTest86+. Maar dat je nu pending sectors hebt ná je scrub betekent dat die sectoren geen probleem hebben kunnen veroorzaken. In de toekomst worden ze willekeurig een keer overschreven. Zou je je pool met een bestand met allemaal nullen volschrijven en daarna verwijderen, dan zouden ze weg moeten zijn. Maar ik vind dat zelf onnodig.

Ik zou nog eens een memtest kunnen doen natuurlijk, maar ik heb toen ik mijn 16GB EEC DDR3 binnenkreeg er eerst een memtest op losgelaten en die gaf na zo'n 20 uur absoluut geen fouten.

Wat wel zo is... als je regelmatig een scrub doet, dan zie je de bad sectors niet in de SMART. Want ZFS lost ze gelijk op, en je ziet ook geen 'Reallocated Sector Count' verhoogd worden, want dat gebeurt alleen bij fysiek beschadigde sectoren. Dit type bad sectors is van het type 'onvoldoende bitcorrectie; ECC fout' ofwel het steeds populairder wordende uBER probleem. De datadichtheid neemt toe maar het absoluut aantal bitfouten per stuk data blijft gelijk.

Ik zie inderdaad geen Reallocated Sectors op die disk, wel nog steeds de Pending (33 stuks)

Wil je de bad sectors kunnen zien, dan zou je nou een tijd niet moeten scrubben. Dan doe je eens een dd read op alle disks. Dat kan terwijl het systeem draait; lekker veilig want je mag er dan ook niet naar schrijven. Zoiets als 'dd if=/dev/ada0 of=/dev/null bs=1m conv=noerror &' die conv is belangrijk want met 'noerror' gaat dd lekker vrolijk door, precies wat je wilt dus.

Doe dat voor alle disks en ga naar de Disks->SMART pagina in ZFSguru. Dan zou je wél hogere pending sectoren moeten zien, die weggaan als je een scrub doet. Maar als je de scrub doet en dan past kijkt naar SMART, dan zie je die bad sectors die ZFS corrigeert dus niet. Ook niet allemaal als je vóór een scrub naar de SMART kijkt omdat je niet weet of de schijf autonoom op de achtergrond alle sectoren inmiddels gescand heeft. Dat gaat denk ik in een rustig tempo af en toe eens wat wanneer de schijf idle is. Met die dd surface read doe je dus leesacties buiten ZFS om, om zo bad sectors op te sporen.

Misschien wel een leuke toevoeging voor de SMART pagina? Een simpele surface scan voor bad sectors?

Ik snap dat ZFS op alle mogelijke manieren tegen datacorruptie beschermt, maar ik snap nog steeds niet waarom elke scrub job bij mij fouten geeft.
Misschien dat jouw bovenstaande verhaal het verklaart, maar dan zie/snap ik het niet.

Het resultaat van twee scrub jobs, direct na elkaar gedraaid:

job 1

code:

[ssh@wega /home/ssh]$ zpool status tank
  pool: tank
 state: ONLINE
 scan: scrub repaired 236K in 6h58m with 0 errors on Thu Aug 23 22:20:51 2012

job2

code:

[ssh@wega /home/ssh]$ zpool status tank
  pool: tank
 state: ONLINE
 scan: scrub repaired 348K in 7h6m with 0 errors on Fri Aug 24 06:00:08 2012

In de tussentijd is er niks naar mijn NAS geschreven, ik zou graag snappen waar die repaired data nu vandaan komt elke keer weer.....

[FireDrunk]

Als 1 disk timeouts geeft telt de on-the-fly gerepareerde data ook als repaired omdat ZFS die daarna terugschrijft naar de pool. Dat dat nog steeds de sectoren niet repareert zorgt ervoor dat bij elke pass die data opnieuw gereconstrueert moet worden denk ik.

[Dadona]

Één van de attractieve mogelijkheden van ZFS vind ik toch wel de read cache. Alleen zou ik toch iets meer inzicht krijgen hoe goed de geheugencache nu is. En vooral of ik er wat aan heb om een SSD in te zetten voor caching. (En dat mag rustig 30GB zijn gezien het type files.)
Met arc_summary.pl is het mogelijk om inzicht te krijgen in de efficiëntie van het geheel. Maar ik zou toch graag een stapje dieper gaan en weten welke files in het cache hangen. In mijn geval wil ik namelijk eigenlijk dat bepaalde files in de cache terechtkomen die het verschil maken.
Concreet gaat het erom dat ik bij de videobewerking graag zou zien dat de videofiles in de cache belanden. Nu heb ik het idee dat die files van de harde schijf worden uitgelezen, met als gevolg dat het snel door de bestanden bladeren toch wat langer duurt. Maar het is een vermoeden, het zou dus prettig zijn om te kunnen zien welke files in de cache terecht zijn gekomen. Iemand tips?

[FireDrunk]

Volgens mij is het cache van ZFS niet filebased, maar block based... En het werkt niet met een FILO systeem (First in Last out) maar het is adaptive, met andere woorden, een combinatie van most frequently used en last used.

[ Voor 53% gewijzigd door FireDrunk op 26-08-2012 14:42 ]

[Verwijderd]

Inderdaad, dus cachen van 'videobestanden' kun je vergeten, want die worden vrijwel altijd sequentiëel ingeladen en weggeschreven. Daar is L2ARC niet voor bedoeld, alleen L1ARC (RAM) kan je daarbij helpen.

Wel kun je kiezen welke bestanden/data je wilt cachen, door de secondarycache attribuut in te stellen. Hetzelfde kun je doen voor de 'level 1' RAM-cache met primarycache. Zelf raad ik aan om op de pool zelf secondarycache op 'none' in te stellen. Dan staat alles standaard uit en geef je per filesystem op wat je wél wilt dat er op de L2ARC komt. Je kunt ook voor kiezen om alleen metadata standaard te cachen (op je pool filesystem instellen) en dan voor sommige filesystems (of ZVOLs) de attribuut op 'all' in te stellen.

[Dadona]

FireDrunk schreef op zondag 26 augustus 2012 @ 14:42:
Volgens mij is het cache van ZFS niet filebased, maar block based... En het werkt niet met een FILO systeem (First in Last out) maar het is adaptive, met andere woorden, een combinatie van most frequently used en last used.

Of het nu block based of file based caching is, het kan uiteindelijk om hetzelfde deel van de harde schijf gaan toch? Dat het adaptive is dat wist ik al, alleen wou ik daar wel wat meer grip op krijgen omdat ik mij momenteel afvraag of het systeem wel de, voor mij, handigste combinatie maakt. Dat een log file super actief is en in de cache terecht komt is leuk, maar ik heb persoonlijk liever dat een video (/de blocks met...) daarin terecht komt.

Verwijderd schreef op zondag 26 augustus 2012 @ 14:54:
Inderdaad, dus cachen van 'videobestanden' kun je vergeten, want die worden vrijwel altijd sequentiëel ingeladen en weggeschreven. Daar is L2ARC niet voor bedoeld, alleen L1ARC (RAM) kan je daarbij helpen.

Ik weet nu niet precies of je nu uitgaat van hetzelfde. Bij de bewerking van multicam footage heb ik drie of vier video's lopen die van dezelfde pool komen. En ik had het specifiek over het geval van het snel door die video's lopen. Op die momenten is het even een uitdaging voor de schijf/schijven omdat drie files tegelijk moeten worden opgezocht.

Wel kun je kiezen welke bestanden/data je wilt cachen, door de secondarycache attribuut in te stellen. Hetzelfde kun je doen voor de 'level 1' RAM-cache met primarycache. Zelf raad ik aan om op de pool zelf secondarycache op 'none' in te stellen. Dan staat alles standaard uit en geef je per filesystem op wat je wél wilt dat er op de L2ARC komt. Je kunt ook voor kiezen om alleen metadata standaard te cachen (op je pool filesystem instellen) en dan voor sommige filesystems (of ZVOLs) de attribuut op 'all' in te stellen.

Dit klinkt langzaam aan waar ik heen wil. Het zijn slechts bepaalde mappen die relevant zijn.

[Verwijderd]

Het probleem is denk ik: dat 'bladeren' uit hoeveel stapjes bestaat dat? Want als het vrijwel random is kun je caching vergeten. Als het vrij 'grove' stappen zijn waarbij toch elke keer specifieke data van een videostream ergens middenin wordt opgevraagd, kan het cachen misschien een beetje helpen. Maar dit is niet echt waar ZFS L2ARC voor gemaakt/bedoeld is. Het is bedoeld voor repetitive random read access naar specifieke datafragmenten. Dat eerste woordje is ook cruciaal: repetitive, dus pas als je dezefde datafragmenten herhaaldelijk opvraagt met random read, wordt deze gecached.

Dan denk ik dat L1ARC je misschien meer kan helpen, door het overal op metadata in te stellen en alleen voor die filesystems op all in te stellen, zodat daar je RAM naartoe gaat. Wel gevaarlijk want de performance van de rest van je pool gaat er onder lijden. Zorg dat in elk geval je OS wel RAMcache krijgt (primarycache op 'all'.

[Dadona]

Het bladeren is totaal random. Nu had ik al het idee dat ik vrij snel met L1ARC in de problemen kom (te grote bestanden). Maar een (zeer) grote L2ARC leek mij geschikt. Ik wil alleen dat er meer en gerichter blocks in de cache terechtkomen.
Door gerichter aan te kunnen geven voor welke mappen caching ingeschakeld zou moeten worden had ik de hoop dat ZFS mij kon helpen. Want hoewel op het totale systeem die files niet zo vaak geraadpleegd zullen worden, is er wel een herhalend element binnen de map 'footage'. Daar zitten video's, audio files, .. in opgebouwd uit datafragmenten die, afhankelijk van het project, meerdere malen worden doorzocht. Misschien worden ze maar twee of drie keer opgevraagd, maar in die map is dat al meer dan de andere bestanden die in een ver verleden zo vaak werden opgevraagd. Dus als ik in het algemeen caching uit kan schakelen of kan beperken in mate (xx%) en type (L1ARC) en vervolgens voor specifieke mappen het kan inschakelen (L2ARC) zou ik opeens wel het opvallende repeterende element hebben. (Hoewel het nog altijd nog mooier zou zijn als de hele file al meteen zou worden ingeladen, maar omdat het op block niveau werkt gaat dat niet, dat snap ik.)
Dat de snelheid van de pool dan misschien lager ligt maakt mij niet zoveel uit (denk ik ) omdat voor mij op dat moment alleen uitmaakt dat er geen vertraging zit in het opzoeken van random datafragmenten van een file.

[ Voor 12% gewijzigd door Dadona op 26-08-2012 15:42 ]

[FireDrunk]

Is het dan niet gewoon beter om een SSD met een pool te sharen en die SSD weer te backupen naar je main pool?

[Dadona]

Ik neem aan dat je erop doelt dat ik de files dan op een SSD zet ? Op zich is dat een optie, alleen moet je dan toch altijd vooral wat voorbereidend werk doen als aan een ander project (met andere files) gewerkt wordt.
Door het middels caching te spelen zal dat automatisch veranderen. Na het wisselen van project zal het even duren voordat de juiste blocks in de cache terechtkomen, maar dat zou wel automatisch verlopen zonder enige interventie.

*Je omschrijft het ietwat cryptisch, het is ook mogelijk om een SSD (of meerderen) in vdevs te plaatsen en toe te voegen aan de pool. ZFS gaat dan zelf uitzoeken wat de snelste mix is. Maar daar schiet ik niets mee op.

[FireDrunk]

Een SSD is toch sowieso al snel genoeg? Dan heb je toch geen caching meer nodig?

[Dadona]

Een SSD is snel zat. Een HDD is op zich ook snel genoeg qua totale overdrachtsnelheid, maar niet bij een seek met meerdere videos. Dat resulteert dan al snel in wachttijden.

Een SSD is ook relatief duur in de aanschaf. Ik had de hoop dat ik middels caching met een relatief kleine SSD (128GB-256GB) toch zonder nadenken aan het werk kon gaan. Data (videos, audio, foto's, ..) naar de pool en afhankelijk van de projectfile die ik open heb komen dan de relevante datafragmenten naar de SSD.

Maar goed, eigenlijk is het feit dat alleen veel en laatst gebruikte blocks in de cache komen, in plaats van de veel en laatst gebruikte files en daar de blocks van (/geen read-ahead), al een limiterende factor.

[FireDrunk]

Om hoeveel data gaat het nou uiteindelijk?
Hoeveel data wil je nou in de cache hebben?

[Dadona]

De hoeveelheid data omvat twee dingen: totale data en de data per project. De totale hoeveelheid data (videofiles en foto's) gaat al snel over de 1TB heen. De data per projectfile wisselt. Momenteel ben ik aan het werk met een project dat zo'n 42GB aan videofiles heeft (drie camera's). En een paar dagen geleden werkte ik aan een project dat iets meer dan 60GB aan videofiles had. Ik denk dat je daadwerkelijk uit kunt gaan van zo'n 40-60GB voor de meeste projecten.
Maar in de toekomst verandert dit wel omdat ik (eindelijk) geen gebruik meer maak van tapes waardoor ik niet zomaar een paar files van 10+GB in één projectfile inzet. Tel daarbij op dat na wat knipacties maar een deel van de files worden ingeladen (daar gaat de block based caching in het voordeel werken), wat een toevoeging van een SSD interessant maakt.

De hoeveelheid data die ik in de cache zie belanden is (zo goed als) alle data die daadwerkelijk in een projectfile actief is. Dus in het ergste geval hebben we het over zo'n 60GB.

En nu denk ik dat ik al weet wat je wil zeggen: gooi die zooi dan op de SSD en ga daarop werken. Maar het lijkt mij net iets minder gebruiksvriendelijk en wat minder snel startklaar.

[FireDrunk]

Dan zou ik per project een filesystem aanmaken. Zodra je aan een project gaat werken, zet je de cache attribuut van een filesystem op all. Dan worden in principe alle files direct ingeladen.

Misschien kan je CiPHER lief aankijken om een snelle quicklink te maken om dat snel vanaf je desktop te kunnen doen.

[Dadona]

Laat CiPHER eerst zich volledig richten op de aanstaande release. Edit: dat is snel...

Serious: Jason is working on it (Dadona: Beta 7) now, out of my hands. Expect a message from him within a week or so.

I can tell you this: it will be worth the wait.

Ik wou in ieder geval voor nu even weten wat mijn opties waren en of hetgeen ik voor ogen had uberhaupt mogelijk is. Als het zometeen even wat rustiger is dan kan ik mij vol op de meest recente versies storten en daar diverse dingen mee uitproberen.

[ Voor 25% gewijzigd door Dadona op 27-08-2012 16:59 ]

[HyperBart]

w00t w00t, ik denk dat we een nieuwe gekroonde ZIL SSD hebben:

nieuws: Kingston mikt met SSDNow E100-ssd's op servermarkt

Om dataverlies als gevolg van stroomuitval te voorkomen, zijn de solid state disks voorzien van zogenaamde Tantalum-condensatoren. Deze zorgen er volgens Kingston voor dat de ssd's een schrijfcyclus alsnog bijtijds kunnen afronden.

[ Voor 34% gewijzigd door HyperBart op 27-08-2012 19:48 ]

[Dadona]

Een quote van één van de reacties op de frontpage:

gezien het bedoelt is voor de servermarkt zal het liggen tussen "schofterig veel" en "tyfusduur".

Hoewel ik lange tijd op de Intel 320 serie heb gemikt gaat dat hem uiteindelijk toch niet worden. Ik kies liever voor een UPS en dan een Samsung 830 of Crucial m4.

[EnerQi]

ik las het ook en er kwam een glimlach

Om een harde schijf failure te testen, heb ik een harde schijf zonder stroom gezet (sata power kabel losgetrokken) en heb ik de nas opgestart. Hoe lang heeft zfsguru nodig om op te starten?
Op dit moment wacht ik al 5 minuten en zie dat ie aan het laden is (hoop ik dan toch ). Het enige wat ik op het scherm zie, is een snel knipperende sterrentje. Volgens mij is het afwisselend "/" "|" "\".

Overigens heb ik wel mijn schijven in 512b format gezet ipv 4k

Iemand ideeën?

Edit: al 20 minuten laden.....
30 minuten and counting

[ Voor 5% gewijzigd door EnerQi op 27-08-2012 21:09 ]

[HyperBart]

Dadona schreef op maandag 27 augustus 2012 @ 20:07:
Een quote van één van de reacties op de frontpage:

[...]

Ik denk dat dat mee gaat vallen... Ik hoop het althans... Plus, als ik zo een SSD van 32GB zou kunnen kopen en hij kost dan al 200 EUR is me dat ook waard...

EDIT: Hmmm, prijzen zijn toch +/- 450 USD... Dat is idd wel redelijk veel... Maar mijn wens blijft: zo een SSD van 32GB of 64GB...

[ Voor 14% gewijzigd door HyperBart op 27-08-2012 20:53 ]

[dutch_warrior]

EnerQi schreef op maandag 27 augustus 2012 @ 20:33:
ik las het ook en er kwam een glimlach

Om een harde schijf failure te testen, heb ik een harde schijf zonder stroom gezet (sata power kabel losgetrokken) en heb ik de nas opgestart. Hoe lang heeft zfsguru nodig om op te starten?
Op dit moment wacht ik al 5 minuten en zie dat ie aan het laden is (hoop ik dan toch ). Het enige wat ik op het scherm zie, is een snel knipperende sterrentje. Volgens mij is het afwisselend "/" "|" "\".

Overigens heb ik wel mijn schijven in 512b format gezet ipv 4k

Iemand ideeën?

Edit: al 20 minuten laden.....
30 minuten and counting

Dat duurt wel erg lang, ik heb net na een scrub job de nas afgesloten, bay met een schijf uit mijn drie disk raidz vdev verwijderd en de machine weer opgestart, het booten duurde eigenlijk niet merkbaar langer dan normaal.

De pool had netjes de degraded status gekregen maar was nog wel operationeel. Na het opnieuw afsluiten van de nas en het terugplaatsen van de disk heb ik de machine weer gestart, toen ik een paar minuten later terugkwam en de webinterface opnieuw had geladen was de resilver job al klaar en was de pool weer netjes online.

EDIT:
Ik had daarstraks wel een aantal checksum errors na de 1e scrub, aangezien dit door meerdere zaken kan komen heb ik counter even gereset en ik draai nu opnieuw een scrub. De disks zijn volgens smart gewoon goed en ik heb ze alle drie afzonderlijk een benchmark laten draaien en ook die uitkomsten waren volledig zoals ik had verwacht. Het zou kunnen dat er een slecht kabeltje tussenzit maar het waren maar 3 checksum errors dus ik denk dat het gewoon komt omdat ik veel heb lopen testen met de machine.

[ Voor 17% gewijzigd door dutch_warrior op 27-08-2012 21:43 ]

[Verwijderd]

Dat is ook hoe het hoort te gaan. Maar ik heb meer berichten ontvangen dat mensen hier problemen mee ondervinden.

Controleer even het volgende:
1) op de ZFSguru disks pagina kun je de freebsd-boot partition selecteren. Check of deze up to date is en update de bootcode 'just to be sure'.
2) probeer eens van wat andere disks te booten door middel van F11 ofzo (Boot Menu)

[EnerQi]

Na een uur maar opgegeven en de disk weer stroom gegeven (na powerdown . Start gewoon juist op met 3 disks.

ZFSguru bevestigd de up to date bootcode maar voor de zekerheid nogmaals geupdate.

Weer een disk losgetrokken (disk 3) en nu weer wachten.

Edit: het lijkt er niet op alsof ie wil booten

Edit2: In de UEFI herkent ie 2 harde schijven (sata 1 en 2 zoals het hoort) en beide schijven staan als 2e boot optie (1e = usb, die er niet insteek).Een andere schijf selecteren heeft weinig zin......

Edit3: het lijkt erop alsof ie de bootloader niet kan vinden. Als de nas 3 disks heeft, vind ie 'm binnen enkele seconden.

Edit4: de disks zijn geformateerd in een GPT format (mocht dit van belang zijn) + AHCI mode op moederbord (hotplug disabled, blijkbaar een optie op mijn moederbord)

[ Voor 54% gewijzigd door EnerQi op 27-08-2012 22:10 ]

[sloth]

HyperBart schreef op maandag 27 augustus 2012 @ 20:40:
[...]


Ik denk dat dat mee gaat vallen... Ik hoop het althans... Plus, als ik zo een SSD van 32GB zou kunnen kopen en hij kost dan al 200 EUR is me dat ook waard...

EDIT: Hmmm, prijzen zijn toch +/- 450 USD... Dat is idd wel redelijk veel... Maar mijn wens blijft: zo een SSD van 32GB of 64GB...

Zoals Dadona hierboven al opmerkt, als je zo bang voor dataverlies bent, waarom koop je dan niet meteen een UPS?

[0xygen]

Verwijderd schreef op vrijdag 17 augustus 2012 @ 21:01:
AIO = Asynchronous I/O en dat is een kernel module voor FreeBSD. Deze wordt standaard geladen als je ZFSguru gebruikt al sinds een lange tijd. De smb.conf samba configuratie doent ook het bovenstaande stukje gepost door djrc18 te hebben; de setting van 1 zorgt dat voor alle I/O, async I/O wordt gebruikt.

Performance vind ik lastig te zetten; test zoveel als je kan inclusief je fysieke disks. Dat RAID-Z2 veel CPU-kracht vergt is niet zo; een Brazos kan prima een 6-disk RAID-Z2 met scores ver boven de gigabit aan. Jouw scores zijn wat teleurstellend.

Verder: als je netwerkthroughput terugvalt (check dit met task manager > network) is dit een probleem met ZFS transaction groups als je merkt dat de netwerktransfer af en toe stil staat, en later weer verder gaat. Gemiddeld kom je dan maar aan een lage score. In dit geval krijgt ZFS de data niet snel genoeg weggeschreven.

Test al je schijven ook even los met de simple disk benchmark, soms kan het zijn dat één schijf trager is dan de rest en een hele array/pool naar beneden trekt.

Maar, begin eens met een andere netwerkcontroller, dat kan het ook zijn. Een Intel PRO/1000 CT kaartje (PCIe x1) is een uitstekende koop voor iets meer dan twee tientjes. Als je een los kaartje koop; koop dan alleen Intel!

Inmiddels doet het probleem met de snelheid niet meer voor.
Ik heb ZFSguru nu zonder ESXI geïnstalleerd en heb een Intel PRO/1000 CT kaartje erin geschroefd. Ik haal nu schrijfsnelheden van 230 Mbit+ en benut mijn gigabit netwerk nu optimaal.

Bedankt voor de hulp.
Ik probeer het op een later moment nog wel eens onder ESXI draaiende te krijgen.

[HyperBart]

sloth schreef op maandag 27 augustus 2012 @ 21:49:
[...]


Zoals Dadona hierboven al opmerkt, als je zo bang voor dataverlies bent, waarom koop je dan niet meteen een UPS?

Heb ik al lang staan . Niettemin wil ik gewoon geen inconsistente rotzooi dus wil ik nog steeds een SSD die voor ZFS zijn werk doet...

[ Voor 18% gewijzigd door HyperBart op 28-08-2012 14:58 ]

[sloth]

Dan begrijp ik het nog niet meteen.

De Kingston SSDNow E100 zijn volgens jou interessant als ZIL (ZFS write cache) omdat ze over Tantalum-condensatoren beschikken. Hierdoor zijn ze in staat een write cycle af te sluiten indien er stroomuitval is.
Als je toch al een UPS hebt, dan is deze toch net in staat het bovenstaande al af te handelen?
Daarnaast hebben deze SSD's geen TRIM ondersteuning. Dat lijkt me ook niet zo prettig als ZIL?

Wat is trouwens de kans dat je een stroomonderbreking / defecte voeding hebt net terwijl je ZIL bezig is met write acties? En om hoeveel belangrijke data gaat het dan?
Deze ZFS gebruiker heeft het ongeluk gehad dit te ervaren, en had geen data loss.

[FireDrunk]

Als we alles zouden relativeren op alleen kans zouden we in sommige gevallen slecht uit zijn geweest...

De *kans* dat fukishima zou gebeuren was misschien niet zo groot, maar de impact wel...

Kans en Impact gaan niet altijd hand in hand...

[HyperBart]

FireDrunk schreef op dinsdag 28 augustus 2012 @ 16:36:
Als we alles zouden relativeren op alleen kans zouden we in sommige gevallen slecht uit zijn geweest...

De *kans* dat fukishima zou gebeuren was misschien niet zo groot, maar de impact wel...

Kans en Impact gaan niet altijd hand in hand...

^^ Dat dus!

Waarom steken mensen een alarm als ze goede sloten hebben op hun deuren? Juist ja, extra veiligheid. Simple as that toch? Plus, op data kan je geen waarde zetten. Het enige argument waar ik me nog een beetje in kan vinden is idd dat het alleen met writes is dat ik nu veiliger zit te maken...

[FireDrunk]

Nou ja, je kan aan data wel één waarde hangen.. Het is minder waard dan... [enter naam van vriendin/moeder/vader]. Maar inderdaad, als je data je lief is, mag het best wat kosten...

[EnerQi]

Cipher en andere tweakers,

Wat zou ik nog meer moeten testen om mijn probleem te verhelpen, welke info hebben jullie nodig?

Logs van ZFSguru:

code:

Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.1-PRERELEASE #0: Sun Jul 22 14:52:10 UTC 2012
    root@zfsguru:/usr/obj/tmpfs/2-tempdir/sys/OFED amd64
CPU: Intel(R) Celeron(R) CPU G530 @ 2.40GHz (2394.61-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x206a7  Family = 6  Model = 2a  Stepping = 7
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0xd9ae3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,TSCDLT,XSAVE,OSXSAVE>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8025825280 (7654 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <ALASKA A M I>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  2
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
ctl: CAM Target Layer loaded
acpi0: <ALASKA A M I> on motherboard
acpi0: Power Button (fixed)
unknown: I/O range not supported
acpi0: reservation of 67, 1 (4) failed
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 550
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
Event timer "HPET3" frequency 14318180 Hz quality 440
Event timer "HPET4" frequency 14318180 Hz quality 440
Event timer "HPET5" frequency 14318180 Hz quality 440
Event timer "HPET6" frequency 14318180 Hz quality 440
atrtc0: <AT realtime clock> port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
Event timer "RTC" frequency 32768 Hz quality 0
attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
vgapci0: <VGA-compatible display> port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0
agp0: <SandyBridge desktop GT1 IG> on vgapci0
agp0: aperture size is 256M, detected 65532k stolen memory
xhci0: <Intel Panther Point USB 3.0 controller> mem 0xf7c00000-0xf7c0ffff irq 16 at device 20.0 on pci0
usbus0: waiting for BIOS to give up control
xhci0: 32 byte context size.
usbus0 on xhci0
pci0: <simple comms> at device 22.0 (no driver attached)
ehci0: <Intel Panther Point USB 2.0 controller> mem 0xf7c18000-0xf7c183ff irq 16 at device 26.0 on pci0
usbus1: EHCI version 1.0
usbus1 on ehci0
hdac0: <Intel Panther Point HDA Controller> mem 0xf7c10000-0xf7c13fff irq 22 at device 27.0 on pci0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci1: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.1 on pci0
pci2: <ACPI PCI bus> on pcib2
re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet> port 0xe000-0xe0ff mem 0xf0004000-0xf0004fff,0xf0000000-0xf0003fff irq 17 at device 0.0 on pci2
re0: Using 1 MSI-X message
re0: Chip rev. 0x2c800000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
re0: Ethernet address: 8c:89:a5:df:bd:ba
ehci1: <Intel Panther Point USB 2.0 controller> mem 0xf7c17000-0xf7c173ff irq 23 at device 29.0 on pci0
usbus2: EHCI version 1.0
usbus2 on ehci1
pcib3: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci3: <ACPI PCI bus> on pcib3
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
ahci0: <Intel Panther Point AHCI SATA controller> port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7c16000-0xf7c167ff irq 19 at device 31.2 on pci0
ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich2: <AHCI channel> at channel 2 on ahci0
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
acpi_button0: <Power Button> on acpi0
acpi_tz0: <Thermal Zone> on acpi0
acpi_tz1: <Thermal Zone> on acpi0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
ppc1: <Parallel port> port 0x378-0x37f irq 5 drq 3 on acpi0
ppc1: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: <Parallel port bus> on ppc1
plip0: <PLIP network interface> on ppbus0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
ppc0: cannot reserve I/O port range
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
p4tcc1: <CPU Frequency Thermal Control> on cpu1
ZFS filesystem version 5
ZFS storage pool version 28
Timecounters tick every 1.000 msec
hdacc0: <Realtek ALC887 HDA CODEC> at cad 0 on hdac0
hdaa0: <Realtek ALC887 Audio Function Group> at nid 1 on hdacc0
pcm0: <Realtek ALC887 (Rear Analog)> at nid 20 and 24,26 on hdaa0
pcm1: <Realtek ALC887 (Front Analog)> at nid 27 and 25 on hdaa0
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: 480Mbps High Speed USB v2.0
usbus2: 480Mbps High Speed USB v2.0
ugen0.1: <0x8086> at usbus0
uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
ugen1.1: <Intel> at usbus1
uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
ugen2.1: <Intel> at usbus2
uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
uhub0: 8 ports with 8 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
ugen1.2: <vendor 0x8087> at usbus1
uhub3: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus1
ugen2.2: <vendor 0x8087> at usbus2
uhub4: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus2
uhub3: 6 ports with 6 removable, self powered
uhub4: 6 ports with 6 removable, self powered
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <ST3000DM001-9YN166 CC4C> ATA-8 SATA 3.x device
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)
ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
ada1: <ST3000DM001-9YN166 CC4B> ATA-8 SATA 3.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)
ada2 at ahcich2 bus 0 scbus2 target 0 lun 0
ada2: <ST3000DM001-9YN166 CC4B> ATA-8 SATA 3.x device
ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada2: Command Queueing enabled
ada2: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)
SMP: AP CPU #1 Launched!
Timecounter "TSC-low" frequency 9353950 Hz quality 1000
Running ipoib_init_module (0xffffffff80b11c30)
Trying to mount root from zfs:Data/zfsguru/9.1-002 [rw]...
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
coretemp1: <CPU On-Die Thermal Sensors> on cpu1

[FireDrunk]

@EnerQI volgens mij kan je niet switchen van 512 naar 4k, dat moet je bij het aanmaken van de pool meteen goed doen. En ik lees niet overduidelijk dat je dat gedaan hebt.

[Verwijderd]

Het mixen van ashift=9 en 12 werkt prima als je het per toplevel vdev neemt. Met andere woorden een raidz of mirror config met 512k disken kan je later uitbreiden met een *nieuwe* vdev en allemaal 4K sectoren. Ik weet alleen niet of dat ook bij BSD werkt.

[FireDrunk]

Dat snap ik, maar het leek er in mijn ogen op (na zijn verhaal gelezen te hebben) dat hij veel geswitched had, en dat het daarna niet meer werkte... Klinkt in mijn oren alsof er daar iets mis is gegaan.

Kan je anders eens een compleet stappenplan opschrijven wat je allemaal gedaan hebt, en sinds wanneer het niet meer werkt?

[EnerQi]

Jullie begrijpen me verkeerd.

Stappenplan:
X. Normal Beta6 gedownload van ZFSguru (van Cipher).
X. Deze geladen in Vmware en een installatie gedaan op een usbstick inclusief image.
X. Via usb opgestart en een RaidZ1 gemaakt met 3 harde schijven met ashift 9 (ja fout van mij, dit zag ik pas 4 dagen later )

Edit: Hmm 1 stap vergeten, op die RaidZ1 heb ik de installatie uitgevoerd inclusief kopieren van image en vervolgens de bootloader van de usbstick disabled. Daarna NAS uit, usbstick eruit en de NAS start zelfstandig op.

X. Wat opviel is dat ZFSguruNAS zelf NIET aangeeft dat ie een IP adres krijgt (http://0.0.0.0.) maar ik wel via een andere pc kan connecten/werken etc.
X. Wat benchmark gedaan op de schijven en eens getest hoe je kunt delen/sharen met samba (dit werkt out-of-the-box )
X. Wat films gekopierd en de snelheid gemeten (80MB/s) wat me niet tegenviel, al had ik 100MB verwacht . Ik verdenk hierbij de ashift 9 optie of CPU die enorm stijgt bij gebruik. Ram lijkt me geen probleem.
X. Vervolgens een weekje opstarten/afsluiten getest en nog wat opties bekijken in zfsguru waaronder het delen met samba maar niets gewijzigd.
X. Vervolgens een test gedaan om te kijken of een harde schijf faillure wel werkt en dit zorgt voor problemen. Ik zet de NAS uit en koppel de sata power kabel los van disk 3. Ik boot de NAS weer maar blijft hangen na het biosscherm. Na een uur de NAS toch maar gewoon uitgezet.
X.Disk 3 weer stroom gegeven en de NAS aangezet en zfsguru werkt zonder problemen.
X.Dit gemeld in dit topic en vervolgens de bootcode in zfsguru geupdate via "disks". Deze was al up-to-date en vervolgens de harddisk faillure test opnieuw gedaan.
X.Helaas wil de NAS niet opstarten zonder disk 3. In de bios geeft de NAS disk 1 en 2 probleemloos aan en zelf met boot volgorde veranderen, blijft de NAS hangen op de (zfs)bootloader.
X. NAS uitgezet en vervolgens disk 3 weer stroom gegeven. NAS start probleemloos op en kan weer in zfsguru.

Deze testjes zijn in de afgelopen paar weken uitgevoerd en de NAS werkt probleemloos. Het gaat blijkbaar fout op het moment dat ie een harde schijf mist. Wat ik nog wil proberen is disk 1 of 2 uitschakkelen ipv disk 3 maar ik verwacht hetzelfde probleem.

De NAS is nog niet in productie dus testen kan gewoon

p.s. ashift 9 heb ik dus niet aangepast, dat zal ik wel doen bij het aanmaken van raidz2 (als ik de harde schijven binnen heb )

[ Voor 4% gewijzigd door EnerQi op 29-08-2012 11:11 . Reden: aanvullig ]

[FireDrunk]

Hmm, je hebt een VM die boot van USB? Kan je dat eens veranderen naar een echte VMDK?

[EnerQi]

Nee, ik heb een pc met vmware geinstalleerd en hierin heb ik zfsguru beta6 geladen (liveCD/ISO). In ZFSguru zit een optie om te installeren op een harde schijf. Ik heb een usbstick geshared met de vmware en hierop zfsguru geinstalleerd met de optie "kopier Image" (zodat ik 'm op andere pc's ook kan installeren ). Met deze stick heb ik dus mijn NAS geinstalleerd. Via usbstick booten (liveCD/ISO in feite) en daarna de installeer optie in ZFSguru gebruiken om voortaan via RaidZ1 op te starten ipv usbstick. De usbstick zit overigens niet meer in de NAS.

[FireDrunk]

Dat klinkt alsof het bootsysteem aan het wachten is op de USB stick...

[EnerQi]

FireDrunk schreef op woensdag 29 augustus 2012 @ 17:23:
Dat klinkt alsof het bootsysteem aan het wachten is op de USB stick...

Dit zou ik vreemd vinden, zonder usbstick start zfsguru gewoon op via de raidz1 array. Zodra er 1 harde schijf faalt (in dit geval nep ), start de pc niet door.

[Verwijderd]

EnerQi schreef op woensdag 29 augustus 2012 @ 20:39:
[...]
Dit zou ik vreemd vinden, zonder usbstick start zfsguru gewoon op via de raidz1 array. Zodra er 1 harde schijf faalt (in dit geval nep ), start de pc niet door.

Even een wilde gok, maar koppel de sata kabel eens los ipv de power kabel.

Joop

[EnerQi]

Verwijderd schreef op woensdag 29 augustus 2012 @ 20:57:
[...]

Even een wilde gok, maar koppel de sata kabel eens los ipv de power kabel.

Joop

Hoe raar het ook klinkt, nu doet ie iets meer.....

De error die ik krijg:
ZFS: i/o error - all block copie unavailable
ZFS: i/o error - all block copie unavailable

FreeBSD/x86 boot
Default: Data:/boot/kernel/kernel
Boot:
ZFS: i/o error - all block copie unavailable

FreeBSD/x86 boot
Default: Data:/boot/kernel/kernel
Boot:
(en nu een streepje, lijkt op "nadenken")

Na powerdown weer de kabel erin gedaan en zfsguru boot gewoon...

[ Voor 5% gewijzigd door EnerQi op 29-08-2012 21:20 ]

[Ultimation]

Ik heb een VM met daarin Nas4Free. Binnen Nas4Free heb ik een RAIDZ pool van 3x 1TB schijven en een RAID-1 met 2x 500Gb schijven.
Nu heb ik een tijdje gedraaid met 4Gb geheugen, maar merkte op dat er nooit meer dan 1,5Gb gebruikt werd. Daarom besloten om het geheugen terug te zetten naar 2Gb, alleen nu merk ik op dat er maar +/- 500mb gebruikt word.

Moet ik aan die 4Gb vasthouden, meer geheugen toewijzen of kan ik met 2Gb ook uit de voeten?

[EnerQi]

ZFS wil graaaaaag geheugen en gebruikt deze om data te cache, dit lijkt op "niet gebruiken". Door geheugen weg te nemen, ontneem je ZFS juist de sterke punten. Als het goed is, is je snelheid bij 2 GB lager als bij 4 GB . Eigenlijk moet je juist zoveel mogelijk geheugen erin doen.

[ Voor 5% gewijzigd door EnerQi op 29-08-2012 21:28 ]

[Ultimation]

Straks maar eens wat mee testen vanaf een andere vm. Eerst de laatste data kopiëren!

[dutch_warrior]

Ultimation schreef op woensdag 29 augustus 2012 @ 21:36:
Straks maar eens wat mee testen vanaf een andere vm. Eerst de laatste data kopiëren!

Als je gaat testen gebruik dan wel even een groot bestand of doe een 32GB of meer DD test.
In het verleden was ZFS op een BSD based systeem niet 100% stabiel met weinig ram.
Ik merkte toen ik een hele tijd geleden met Freenas 8rc1 heb getest flink prestatieverschil tussen 4 en 8GB ram zelfs van 8 naar 16GB was duidelijk merkbaar met single gigabit interface.

[Ultimation]

Even wat tests gedraaid, het lijkt erop dat het met 2Gb nog de beste resultaten worden gehaald..
3x 1Tb Samsung Spinpoint F3 RAIDZ. Op de disks staat alwel wat data.

Eerst bestand geschreven, daarna ingelezen en daarna verwijderd. Dan 4x achter elkaar.

Mis ik wat tweaks? Daar heb ik mij nog niet mee bezig gehouden. Is een standaard nas4free installatie.

2Gb geheugen test:

Schrijven

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 63.466346 secs (67673146 bytes/sec, 64,53 mb/s)

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 54.529044 secs (78764764 bytes/sec, 75,11 mb/s)

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 53.330641 secs (80534702 bytes/sec, 76,80 mb/s)

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 50.037414 secs (85835117 bytes/sec, 81,85 mb/s)

EDIT; 32Gb:

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=8M count=4096
4096+0 records in
4096+0 records out
34359738368 bytes transferred in 342.784952 secs (100237009 bytes/sec, 95,59 mb/s)

Lezen

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 27.166508 secs (158097879 bytes/sec, 150,77 mb/s)

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 29.703403 secs (144595126 bytes/sec, 137,89 mb/s)

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 26.777362 secs (160395461 bytes/sec, 152,96 mb/s)

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 25.057443 secs (171404851 bytes/sec, 163,46 mb/s)

EDIT, 32Gb:

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=8M count=4096
4096+0 records in
4096+0 records out
34359738368 bytes transferred in 218.527450 secs (157233054 bytes/sec, 149,94 mb/s)

4Gb geheugen test

Schrijven

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 86.373625 secs (49725449 bytes/sec, 47,21 mb/s)

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 82.625004 secs (51981447 bytes/sec, 49,57 mb/s)

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 55.496071 secs (77392277 bytes/sec, 73,80 mb/s)

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 52.847737 secs (81270600 bytes/sec 77,50 mb/s)

Lezen

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 38.706004 secs (110963852 bytes/sec, 105,82 mb/s)

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 37.181750 secs (115512780 bytes/sec, 110,16 mb/s)

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 37.690219 secs (113954427 bytes/sec, 108,67 mb/s)

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 36.555441 secs (117491875 bytes/sec, 112,04 mb/s)

8Gb geheugen test

Schrijven

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 54.482476 secs (78832087 bytes/sec, 75,18 mb/s)

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 53.048904 secs (80962413 bytes/sec, 77,21 mb/s)

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 69.565435 secs (61739962 bytes/sec, 58,87 mb/s)

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 52.237372 secs (82220202 bytes/sec, 78,41 mb/s )

Lezen

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 36.453544 secs (117820295 bytes/sec, 112,36 mb/s)

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 38.182097 secs (112486417 bytes/sec, 107,27  mb/s)

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 35.364126 secs (121449835 bytes/sec, 115,82 mb/s)

nas4free:~# dd if=/mnt/DATA/Downloads/tst.bin of=/dev/zero bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 33.447501 secs (128409214 bytes/sec, 122,46 mb/s)

[ Voor 4% gewijzigd door Ultimation op 29-08-2012 23:58 ]

[Verwijderd]

@Ultimation: controleer eens met `uname -a` of je wel FreeBSD 9.0+ draait?

[Ultimation]

nas4free:~# uname -a
FreeBSD nas4free.xxx 9.0-RELEASE-p4 FreeBSD 9.0-RELEASE-p4 #0: Mon Aug 27 01:00:08 CEST 2012     [e-mail]4free:/usr/obj/nas4free/usr/src/sys/NAS4FREE-amd64  amd64

[FireDrunk]

Ik vind het vreemde resultaten. Kan je tijdens de test eens in een tweede scherm iostat -x 1 runnen voor een paar iteraties en de resultaten posten?

[Ultimation]

32Gb of weer een 4Gb bestand?

EDIT; 2Gb geheugen:

Schrijven, dd test

nas4free:~# dd if=/dev/zero of=/mnt/DATA/Downloads/tst.bin bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 44.484450 secs (96549858 bytes/sec, 92,77 mb/s)

Schrijven, iostat

                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   0.0     0.0     0.0    0   0.0   0 
md1        0.0   3.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        3.0 863.3     3.5 43575.8    3  15.6  80 
da4        5.0 723.7     5.9 34635.0    0   8.7  55 
da5        5.9 723.7     6.4 34636.5    0   4.6  23 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   0.0     0.0     0.0    0   0.0   0 
md1        0.0   3.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        1.0 657.4     0.5 38466.7   14  16.7  88 
da4        3.0 956.5     4.5 57486.2   13   7.1  55 
da5        2.0 1067.4     4.0 64463.7    0   5.6  35 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   0.0     0.0     0.0    0   0.0   0 
md1        0.0   3.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        4.0 675.3     3.0 40038.6   14  17.9  95 
da4        3.0 592.1     2.0 34777.5   17   5.0  38 
da5        0.0 552.5     0.0 32303.7    0   5.4  16 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   0.0     0.0     0.0    0   0.0   0 
md1        0.0   3.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        1.0 740.6     1.0 44536.0   16  14.2  91 
da4        3.0 619.8     2.0 36813.8    0  16.2  52 
da5        3.0 548.5     2.0 32307.9    0   5.5  17 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   0.0     0.0     0.0    0   0.0   0 
md1        0.0   0.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        4.9 715.2     2.9 38408.9    4  18.9  85 
da4        1.0 624.0     0.5 32375.1    4   9.0  41 
da5        4.9 621.0     3.9 32377.5    4   4.8  20 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   9.9     0.0     0.0    0   0.0   0 
md1        0.0   3.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        1.0 702.3     0.5 41713.9   13  17.0  93 
da4        3.0 939.1     4.5 56742.0   18   7.2  73 
da5        2.0 1062.9     4.0 64551.6    0   5.6  32 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   0.0     0.0     0.0    0   0.0   0 
md1        0.0   3.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        3.0 864.4     1.5 52012.1   15  11.2  93 
da4        1.0 677.2     0.5 40105.6    0  15.3  48 
da5        1.0 553.5     0.5 32304.1    0   5.5  18 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0  11.9     0.0     0.0    0   0.0   0 
md1        0.0   3.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        3.0 734.7     2.0 41157.9   13  22.6  83 
da4        5.9 644.6     3.5 35318.7   14   7.5  42 
da5        5.0 685.2     2.5 37853.9   19   5.1  24 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   0.0     0.0     0.0    0   0.0   0 
md1        0.0   3.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        1.0 856.4     0.5 50250.4   14  10.8  94 
da4        3.0 1014.8     1.5 60132.5   16   7.5  62 
da5        1.0 1005.9     0.5 59511.7    0   5.5  29 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   0.0     0.0     0.0    0   0.0   0 
md1        0.0   3.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        2.0 923.7     1.0 53138.2   13  11.9  78 
da4        5.9 830.7    13.4 47187.8   17  11.1  56 
da5        5.9 952.5    13.4 54963.5   19   5.4  32 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   0.0     0.0     0.0    0   0.0   0 
md1        0.0   3.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        2.0 877.2     1.0 52849.1    0  11.6  86 
da4        2.0 857.4     1.0 51648.1    1  11.2  58 
da5        2.0 705.0     1.0 41949.0    0   5.5  23 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   0.0     0.0     0.0    0   0.0   0 
md1        0.0   6.9     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        4.0 878.2     3.0 50294.7   14   8.3  76 
da4        4.0 1004.0     2.5 58274.5   17   7.3  79 
da5        4.0 1105.0     3.0 64626.5    0   5.6  37 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 
                        extended device statistics  
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b  
md0        0.0   0.0     0.0     0.0    0   0.0   0 
md1        0.0   3.0     0.0     0.0    0   0.0   0 
da0        0.0   0.0     0.0     0.0    0   0.0   0 
da1        0.0   0.0     0.0     0.0    0   0.0   0 
da2        0.0   0.0     0.0     0.0    0   0.0   0 
da3        3.0 779.2     2.0 46644.2    1  14.3  83 
da4        3.0 653.5     2.0 38657.6    0  16.7  53 
da5        2.0 552.5     2.0 32309.6    0   5.5  18 
pass0      0.0   0.0     0.0     0.0    0   0.0   0 
pass1      0.0   0.0     0.0     0.0    0   0.0   0 
pass2      0.0   0.0     0.0     0.0    0   0.0   0 
pass3      0.0   0.0     0.0     0.0    0   0.0   0 
pass4      0.0   0.0     0.0     0.0    0   0.0   0 
pass5      0.0   0.0     0.0     0.0    0   0.0   0 
pass6      0.0   0.0     0.0     0.0    0   0.0   0 

[ Voor 99% gewijzigd door Ultimation op 30-08-2012 10:55 ]

[Rannasha]

Hebben er mensen (praktijk) ervaring met ZFS-on-Linux (via de Ubuntu PPA of op andere manieren)? Ik heb een stapeltje hardware (AMD C60 bordje van Asus, 4x2 TB disks, en overige benodigdheden) besteld om een homeserver / NAS te bouwen en wou het liefst ZFS gebruiken. Ik heb vrij veel Linux ervaring, maar nog nooit een BSD-variant gebruikt, dus ik wou het liefst alles gewoon binnen Linux houden.

Wat ik lees her en der is dat de Linux-port van ZFS al behoorlijk stabiel en bruikbaar is, maar er zijn weinig uitgebreide ervarings-verhalen. Lagere prestaties maken me niet zoveel uit, m'n huidige server/"NAS" is een notebook met 2 externe schijven achter een 100 Mbit switch, dus het wordt hoe dan ook een forse verbetering. Het doel is om een simpele, stabiele setup te maken, waar ik makkelijk services aan toe kan voegen of wijzigen.

[FireDrunk]

@Ultimation, waarom zie ik maar 3 van de 6 disks werken? Heb je 2 arrays?

[Ultimation]

2 arrays, 3x 1TB Samsung Spinpoint F3, RAIDZ en 2x 500Gb Samsung Spinpoint F1 RAID1.