Het grote ZFS topic

[FireDrunk]

DJ-Visto schreef op woensdag 20 april 2011 @ 22:10:
[...]

Dan kan het nog extremer met een areca 1880ix 24 ofzo

Maar daar wil je geen ZFS op draaien

[Arnoud1]

diskinfo -c -v -t 
voor da0 tot da7

        512             # sectorsize
        1000204886016   # mediasize in bytes (932G)
        1953525168      # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        121601          # Cylinders according to firmware.
        255             # Heads according to firmware.
        63              # Sectors according to firmware.
              # Disk ident.

I/O command overhead:
        time to read 10MB block      0.109607 sec       =    0.005 msec/sector
        time to read 20480 sectors   6.468009 sec       =    0.316 msec/sector
        calculated command overhead                     =    0.310 msec/sector

Seek times:
        Full stroke:      250 iter in   5.063315 sec =   20.253 msec
        Half stroke:      250 iter in   3.523778 sec =   14.095 msec
        Quarter stroke:   500 iter in   5.727597 sec =   11.455 msec
        Short forward:    400 iter in   2.825996 sec =    7.065 msec
        Short backward:   400 iter in   2.907713 sec =    7.269 msec
        Seq outer:       2048 iter in   0.453792 sec =    0.222 msec
        Seq inner:       2048 iter in   0.712670 sec =    0.348 msec
Transfer rates:
        outside:       102400 kbytes in   0.942692 sec =   108625 kbytes/sec
        middle:        102400 kbytes in   1.049140 sec =    97604 kbytes/sec
        inside:        102400 kbytes in   1.850596 sec =    55334 kbytes/sec

En Bonnie++:

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
nas           6368M    44  84 91758  49 51329  31   153  97 166440  43 127.5  16
Latency              8463ms    4429ms    4424ms     326ms     165ms   64144ms
Version  1.96       ------Sequential Create------ --------Random Create--------
nas                 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 10802  94 +++++ +++ 10763  97 10397  95 +++++ +++ 10935  97
Latency             25676us     191us     984us   52798us     735us     859us
1.96,1.96,nas,1,1303323955,6368M,,44,84,91758,49,51329,31,153,97,166440,43,127.5                               ,16,16,,,,,10802,94,+++++,+++,10763,97,10397,95,+++++,+++,10935,97,8463ms,4429ms                                ,4424ms,326ms,165ms,64144ms,25676us,191us,984us,52798us,735us,859us

Met deze waarden moet ik toch mijn netwerk vol kunnen trekken.
Geen flauw id hoe ik die bonnie moet interpreteren... Iemand?

Ik haal nog steeds max 16MB/sec over 1 Gbit netwerk.

[ Voor 3% gewijzigd door Arnoud1 op 20-04-2011 23:01 ]

[Splendid]

Verwijderd schreef op woensdag 20 april 2011 @ 22:36:
[...]


FreeNAS zal niet zo snel zijn met ZFS 28.. zitten nu ook nog op 15

Ja ik hoop wel dat ze dit snel gaan oppakken want deze FreeBSD release wordt wel een grote en belangrijke release qua ZFS ondersteuning, dus daar moeten ze snel op inhaken. En anders haak ik wel af naar wat anders

[Verwijderd]

FreeBSD 8.2 heeft nu ZFS v15, maar 8.3 zal ZFS v28 hebben - de versie die nu in FreeBSD 9 zit. Dus er zit geen stappen tussen v15 en v28. Ik hoop van de zomer een release te zien; zal wel september worden. Voor die tijd zou ZFS v28 al naar 8-STABLE komen; maar dat is niet echt een release maar een branch vergelijkbaar met 9-CURRENT (development).

@Arnoud1: ik heb je al eens geprobeerd te helpen met je trage writes; misschien even een apart topic aanmaken en daar álle informatie in zetten? Dus exacte hardware specs, dmesg output en benchmark resultaten. 93MB/s sequential write op lokale ZFS performance betekent dat je de helft max op je netwerk kunt zien. Als je netwerk dan ook nog bottlenecks kent kun je aan die extreem lage 16MB/s komen. Heb je al eens met iPerf getest of je netwerk wel 100MB/s aankan?

En als laatste nog over partities: er wordt vaak gezegd dat ZFS niet goed tegen partities kan. Dit heeft echter NIETS met ZFS te maken maar is een Solaris-specifieke beperking die ook voor UFS geldt. FreeBSD en Linux zouden dit probleem niet moeten hebben en dus hoef je je daar ook niet druk om te maken. Grootste probleem is dat je onder Solaris een enkele SSD niet als zowel SLOG als L2ARC kunt gebruiken; omdat je dan partities moet aanmaken en de SLOG dan niet meer veilig werkt op partities. Solaris kan namelijk geen FLUSH commando's versturen op partities; alleen op raw device nodes, als ik het goed heb begrepen.

[FireDrunk]

Verwijderd schreef op woensdag 20 april 2011 @ 23:22:
FreeBSD 8.2 heeft nu ZFS v15, maar 8.3 zal ZFS v28 hebben - de versie die nu in FreeBSD 9 zit. Dus er zit geen stappen tussen v15 en v28. Ik hoop van de zomer een release te zien; zal wel september worden. Voor die tijd zou ZFS v28 al naar 8-STABLE komen; maar dat is niet echt een release maar een branch vergelijkbaar met 9-CURRENT (development).

@Arnoud1: ik heb je al eens geprobeerd te helpen met je trage writes; misschien even een apart topic aanmaken en daar álle informatie in zetten? Dus exacte hardware specs, dmesg output en benchmark resultaten. 93MB/s sequential write op lokale ZFS performance betekent dat je de helft max op je netwerk kunt zien. Als je netwerk dan ook nog bottlenecks kent kun je aan die extreem lage 16MB/s komen. Heb je al eens met iPerf getest of je netwerk wel 100MB/s aankan?

Waar haal jij de wijsheid vandaan dat netwerk 50% overhead geeft?

http://sd.wareonearth.com/~phil/net/overhead/

[Verwijderd]

Dat verhaal gaat over TCP/IP; low-level overhead. Dat is iets van 8% ofzo, niets om je druk over te maken. Van de 125MB/s ruwe bandbreedte blijft dan 111MB/s over ofzo; dat is de max die je kunt halen met een echt protocol (FTP etc).

Maar ik doelde vooral op problemen met SMB/CIFS; dat gebeurt bij vrijwel iedereen. Ook ik haal 110MB/s write over CIFS naar mn ZFS server, maar read is altijd trager. In feite zitten er dan kleine gaatjes in de beschikbare bandbreedte die het CIFS protocol niet optimaal benut. Die overhead doelde ik dus op.

Ik heb enorm veel performanceproblemen bij CIFS (Samba) gezien terwijl FTP gewoon de volle bandbreedte pakt. Met nieuwere versies van Samba (en FreeBSD) lijkt dat al veel beter te gaan, maar nog steeds zie ik vrijwel altijd een lagere read dan een lagere write. Dat heeft verder niets met TCP/IP te maken vrees ik, maar inherent aan het ineffciente protocol.

Performanceproblemen kunnen meerdere oorzaken hebben, tezamen zorgen ze dan voor extreem lage performance, terwijl ieder euvel apart maar beperkt effect heeft. Ik raad meestal aan om eerst het netwerk apart te testen met iPerf; die test de ruwe bandbreedte. Als dat niet minimaal 950 megabit geeft op een gigabit netwerk, dan is je netwerk niet lekker. Als dat wel goed werkt kun je verder.

Stap 2 zou dan zijn op een memory filesystem met CIFS werken en kijken of je dan optimale performance haalt. Zo niet dan is Samba tuning een mogelijkheid, zo wel dan lijkt me dat ZFS ofwel local file I/O performance op de server een bottleneck kan zijn. Gezien dat hij lokaal max 93MB/s write haalt is dat laatste vast en zeker ook een factor; maar niet genoeg om tot 16MB/s totaal throughput te komen.

[Ravefiend]

Wat is nu zo tegenwoordig de makkelijkste manier om vanuit Win7 bv. FreeNAS-8.0-RC5-amd64.Full_Install.xz op een USB Flash Drive te krijgen?

code:

F:\FreeNAS\physdiskwrite-0.5.2-PhysGUI-bundle>physdiskwrite.exe -u F:\FreeNAS\FreeNAS-8.0-RC5-amd64.Full_Install.xz

physdiskwrite v0.5.2 by Manuel Kasper <[e-mail]>

Searching for physical drives...

Information for \\.\PhysicalDrive0:
   Windows:       cyl: 9729
                  tpc: 255
                  spt: 63
Information for \\.\PhysicalDrive1:
   Windows:       cyl: 38913
                  tpc: 255
                  spt: 63
   C/H/S:         16383/16/63
   Model:         Hitachi HTS725032A9A364
   Serial number: 101209PCK304GKHGEXJK
   Firmware rev.: PC3OCA0B

Information for \\.\PhysicalDrive2:
   Windows:       cyl: 981
                  tpc: 255
                  spt: 63

Which disk do you want to write? (0..2) 2
WARNING: that disk is larger than 2 GB! Make sure you're not accidentally
overwriting your primary hard disk! Proceeding on your own risk...
About to overwrite the contents of disk 2 with new data. Proceed? (y/n) y
78544896/78550820 bytes writtenWrite error after 78544896 bytes.

Als administrator, dit resultaat bekomen na diskpart / clean dus waarom zou het dan toch mis gaan?

[FireDrunk]

Command prompt -> rechtermuisknop als administrator? Of je bedoeld dat je user admin is?
(in windows 7 is dat een verschil )

[Ravefiend]

Daar is een verschil in dat klopt. Shift+rechtermuisknop op cmd, Run as a different user --> Administrator + pwd. Jammer maar helaas, dat geeft alvast hetzelfde resultaat ...

[Verwijderd]

Ravefiend schreef op vrijdag 22 april 2011 @ 12:56:
Daar is een verschil in dat klopt. Shift+rechtermuisknop op cmd, Run as a different user --> Administrator + pwd. Jammer maar helaas, dat geeft alvast hetzelfde resultaat ...

ik heb het zo wel eens gedaan :

> http://www.pendrivelinux....-installer-easy-as-1-2-3/

en dan haal je de .xz file eerst van de iso

maar bedankt voor de tip.. ga gelijk even rc5 proberen

* oeps.. dat was toen ik geen cdrom eraan had hangen.. maar het werkte wel
[HOWTO]install freenas on usb key without cdrom, for v7 & v8

[ Voor 17% gewijzigd door Verwijderd op 22-04-2011 13:43 ]

[Ravefiend]

Verwijderd schreef op vrijdag 22 april 2011 @ 13:31:
[...]
* oeps.. dat was toen ik geen cdrom eraan had hangen.. maar het werkte wel
[HOWTO]install freenas on usb key without cdrom, for v7 & v8

Geniaal, een beetje jongleren met USB sticks. Dan zullen we dat maar eens proberen ...

[Verwijderd]

Ravefiend schreef op vrijdag 22 april 2011 @ 15:58:
[...]


Geniaal, een beetje jongleren met USB sticks. Dan zullen we dat maar eens proberen ...

en..

[Sfynx]

Sinds dat het in FreeBSD als productiewaardig werd beschouwd draai ik dit op de fileserver op m'n werk. RAIDZ2 pool met root filesystem erop ook, GPT layout, kan FreeBSD gewoon van booten. Wel met een 3Ware hardware RAID kaart overigens, die hadden we al... op die kaart zit een DRAM cache + BBU en aardig wat bandbreedte, dus helemaal nutteloos is het niet... alleen gebruik ik natuurlijk niet meer de RAID functie op de kaart omdat anders het hele self healing idee van ZFS niet opgaat.... oftewel: schijven individueel exporteren en ZFS het laten beheren.

De diskcontroller negeert alle cache flush commando's vanwege de aanwezige BBU, en het geheel is echt bloedsnel.

Nooit meer een filesystem check of een of andere RAID parity verify hoeven doen na een smerige shutdown. Backups zijn enorm versimpeld met het snapshot systeem. Plus Offsite backups hiervan met het zfs send + zfs rceive systeem naar een ander ZFS systeem, gewoon snapshotje overzenden en klaar.

Meer ruimte nodig? Grotere schijven erin en je pool is groter. Ingebouwde compressie.
En sinds dat we dit hebben is er nooit meer data verloren gegaan of corrupt geraakt. Zit ook ECC RAM in, daar wil je ook geen omvallende bitjes.

Draait nu nog 8.2-RELEASE met pool v15 en fs v4, maar ik kan niet wachten tot v28 stabiel is, dan gaat er een extra sloot RAM in en kunnen we kwijlen over deduplicatie
Binnenkort i.i.g. maar eens een SSD in hangen als L2ARC, mensen klagen een beetje over slechte random read performance wat komt omdat er veel gebruikers allerlei dingen zitten te doen... ik denk dat ik een hoop collega;s erg blij ga maken

Overigens draait het thuis op m'n Atom servertje ook prima (mirror van twee schijven), alleen merk je wel dat het een aanslag is op ej CPU, zeker met SHA256 checksums.

[ Voor 7% gewijzigd door Sfynx op 27-04-2011 00:57 ]

[Ultraman]

Dat is fijn om te horen.
Hier is 8GB DDR3-1333 ECC van Kingston onderweg tezamen met een 2TB Hitachi 5K3000 (512b sectors) die denk ik als hot-spare gaat dienen naast de huidige drie 1.5TB Seagate LPs en twee 320GB schijven.
Moederbordje ligt klaar: Asus M4A88T-M. Hoop dat er ooit een HBA op kan werken, maar op dit moment heb ik die nog niet nodig.
En de CPU is nog in gebruik in de huidige server, een Athlon II X2 245.

Ik ga de behuizing modificeren en alle schijven ophangen in van dat koordelastiek.
En volgens mij moet ik een extra SATA power connector aan de bekabeling van de PSU gaan drukken. Gelijk maar een paar van maken voor een eventuele upgrade later.

Wat gaat het aan disken worden:
- 320GBers in ZFS Mirror
- 3x 1.5TB RAID-Z
- 2TB Hitachi hot-spare of voor backups?

Het OS gaat op de mirror komen, en ik wil tevens de incoming directory voor de Torrent client op de 320GBers hebben. De RAID-Z wordt opslag voor de home directories van de gebruikers en de gedeelde gebruiker 'share' (waaronder dus de muziek, ISO's e.d komen), de massa opslag dus.

Ben er nog niet helemaal uit hoe dit er exact uit komt te zien in de filesystem layout.
Iemand hier al eerder zoiets opgezet? Nog tips?
En die hot spare, nuttig? Of anders inzetten?

[FireDrunk]

Hot spare is echt alleen maar handig als je echt _nul_ downtime kan hebben. In mijn geval zet ik mijn server gewoon even uit, vervang de disk, en zet hem weer aan... Dat dat een dag duurt maakt mij niet zoveel uit...
Die hotspare gebruikt alleen maar stroom. Dan kun je hem beter voor backups gebruiken, maar dan zou ik hem hot swappable maken... ZFS Snapshot maken, snapshot naar 2TB disk kopieren, disk in de kast leggen.

Heb je gelijk een 'redelijkerwijs' goede backup.

[Ultraman]

Zou je zo'n ding niet op standby kunnen zetten?
Maar idd, ik kan toch bij dat ding komen wanneer het moet, dus hem omzetten van backup naar actieve disk zou ik dan altijd kunnen doen wanneer nodig. Bedankt voor de tip

Ander idee was om ipv RAID-Z er een mirror+mirror stripe van te maken. Maar voor de performance heb ik dat niet echt nodig.

Hij gaat nu iig goed van pas komen bij het leeg trekken van de huidige configuratie. Dan kan ik daar alles naar toe kopiëren en de 1.5TBers mooi zero-fillen en schoon inzetten.
Moet ik alleen wel zorgen dat ik er een filesystem van maak welke FreeBSD gaat kunnen lezen. Misschien een leuk moment om met ZFS onder Linux even te experimenteren.

[ Voor 15% gewijzigd door Ultraman op 27-04-2011 10:36 ]

[Sfynx]

Vannacht een scrub gedraaid op mijn thuisserver na een WRITE_DMA48 error op 1 van de schijven in de mirror. Resultaat: 17 checksum mismatches op die schijf, eentje door een READ_DMA48 error tijdens de scrub, maar ook op andere plekken op de schijf waar ik geen I/O errors van had gezien. Allemaal gerepareerd.

Ik check de kabels wel even, maar ik vermoed gewoon een schijf die op een smerige wijze wenst te overlijden... Eerste keer dat ZFS me van stille corruptie redt... ik vind het nu gewoon eng om iets anders op een server te gebruiken

[ Voor 5% gewijzigd door Sfynx op 27-04-2011 10:42 ]

[FireDrunk]

Rofl, mijn mdadm array doet ook aan scrubben hoor, dus dat is nou net iets waar zfs niet uniek in is. En die errors krijg ik ook gewoon te zien. Probleem van mdadm is dat het geen bitrot tegengaat

Dus als je een Checksum Mismatch krijgt

[raymonvdm]

Fuck weer een topic om te volgen. . . .

Ik ben me aan het inlezen in ZFS begonnen in Zuinige ESXi Server en Nieuwe Zuinige Server (discussie) kom ik deze tegen (bookmarked)


Ik kwam deze wiki tegen om een array te expanden met ZFS maar is dat ook wat. Ik kom veel kennis en hardware te kort en wil zo eerst maar eens beginnen om FreeBSD te downloaden en oude hardware te sprokkelen.

Ik heb nog ergens een xeon servertje daar wil ik een ide disk en doen van 40gb en daarna beginnen met het toevoeegen van SATA disken ( 2 x 80GB heb ik zoiezo liggen) en uiteindelijk groeien naar X x 1.5TB of 2TB afhankelijk van prijs/budget/tijd


Inmiddels heb ik het servertje voorzien van FreeBSD en een /tank op 2 x 80GB. Het wachten is nog even op extra tijd en meer diskspace

[ Voor 8% gewijzigd door raymonvdm op 27-04-2011 15:05 ]

[Verwijderd]

FireDrunk schreef op woensdag 27 april 2011 @ 10:45:
Rofl, mijn mdadm array doet ook aan scrubben hoor, dus dat is nou net iets waar zfs niet uniek in is.

Conventioneel RAID zoals md-raid kan geen onderscheid maken tussen corrupte en valide data. Het enige wat het kan doen is kijken of de pariteit met de data overeenkomt. Zo niet, dan wordt per definitie vanuit gegaan dat de data klopt en de pariteit niet. Als het andersom is, heb je dus corruptie en vernietigt een scrub/rebuild van md-raid de enige valide kopie die je over had.

ZFS is slimmer en kijkt aan de hand van checksums welke data correct is. Ook heb je feedback over corruptie: er kan simpelweg geen corruptie gebeuren zonder dat jij op de hoogte bent, en dan weet je precies in welke file. In tegenstelling tot standaard filesystems biedt ZFS altijd redundante metadata; dus hooguit files kunnen corrupt raken - het filesystem zelf zou altijd consistent moeten blijven. Corruptie op NTFS/Ext4/XFS metadata kan in een ongelukkig geval grote hoeveelheden data vernietigen of onklaar maken.

Dus wat dit betreft heeft ZFS wel degelijk een streepje voor.

[Sfynx]

Ik bewonder ZFS ook omdat het zo elegant in elkaar zit en het eigenlijk heel weinig code is vergeleken met de laag-op-laag-op-laag aanpak van de meeste systemen (RAID-op-LVM-op-filesystem) zonder dat ze iets van elkaar weten.

Ik dropte net even een schijf uit de RAID-Z2 om even aan een collega te laten zien dat ie niet de hele schijf hoeft te gaan zitten rebuilden (resilveren) zodra ik 'm er weer in hang... maar alleen de intussen gewijzigde delen. Als de RAID niets van het filesystem af zou weten, zou dit niet mogelijk zijn en moet die hele schijf overschreven worden.

Een groep mensen vindt het een 'blatant layering violation', ik vind die integratie briljant.

[Verwijderd]

Het bezwaar van de 'layering violation' is dat hetgeen ZFS doet niet nagedaan kan worden door een andere RAID-engine, en je zo geen enkele andere tools ter beschikking hebt dan ZFS zelf ten behoeve van recovery.

Het voordeel is natuurlijk dat je een heleboel potentiële problemen naar de prullenmand verwijst door één pakket te gebruiken; een filesystem wat direct meerdere disks aanspreekt en intelligentie kan toepassen op elk niveau wat bij gescheiden lagen niet mogelijk is. Bovendien heeft ZFS juist uitmuntende recovery en self-healing eigenschappen waar je zelf niets voor hoeft te doen; simpelweg toegang vragen tot het bestand is genoeg om problemen die er zijn op te laten lossen zonder dat de applicatie daarvan ook maar iets merkt - mits je maar voldoende redundancy hebt natuurlijk.

Dus ZFS is inderdaad wel briljant en Btrfs kan zelfs hier niet aan tippen, ook al heeft Btrfs op veel vlakken vergelijkbare eigenschappen als ZFS. Daarnaast is ZFS veel meer volwassen en stabiel om echt te gebruiken zonder zorgen. Btrfs zit je alsnog met losse RAID en LVM lagen.

[Tp21]

Verwijderd schreef op woensdag 27 april 2011 @ 14:13:
Het bezwaar van de 'layering violation' is dat hetgeen ZFS doet niet nagedaan kan worden door een andere RAID-engine, en je zo geen enkele andere tools ter beschikking hebt dan ZFS zelf ten behoeve van recovery.

Het voordeel is natuurlijk dat je een heleboel potentiële problemen naar de prullenmand verwijst door één pakket te gebruiken; een filesystem wat direct meerdere disks aanspreekt en intelligentie kan toepassen op elk niveau wat bij gescheiden lagen niet mogelijk is. Bovendien heeft ZFS juist uitmuntende recovery en self-healing eigenschappen waar je zelf niets voor hoeft te doen; simpelweg toegang vragen tot het bestand is genoeg om problemen die er zijn op te laten lossen zonder dat de applicatie daarvan ook maar iets merkt - mits je maar voldoende redundancy hebt natuurlijk.

Dus ZFS is inderdaad wel briljant en Btrfs kan zelfs hier niet aan tippen, ook al heeft Btrfs op veel vlakken vergelijkbare eigenschappen als ZFS. Daarnaast is ZFS veel meer volwassen en stabiel om echt te gebruiken zonder zorgen. Btrfs zit je alsnog met losse RAID en LVM lagen.

btrfs kan net zoals ZFS zelf raid doen, op het moment raid 0 en 1, maar in de (nabije) toekomst ook raid 5 en 6. ook kan je in btrfs subvolumes aanmaken, wat lvm 'vervangt'. het is inderdaad wel waar dat zfs een stuk volwassener is dan btrfs op het moment, maar je hoeft zéker geen mdraid met lvm laag onder btrfs te draaien (is zelfs af te raden, btrfs kan de schijven beter zelf beheren (net zoals zfs)).

[raymonvdm]

Kan iemand vertellen wat de beste ZFS oplossing is qua disk indeling. Is wat deze kerel doet een goed idee ?

Array Expansion:
http://wiki.mattrude.com/...ZFS_and_FreeNAS_expansion

Verder ben ik benieuwd of ik een manier kan vinden om een Samba export te maken zodat ik snel performance kan testen tussen mn ZFS storage ( 2 x 80GBSATA) en mn 1 x 1.5TB single disk in ubuntu Dan weet ik namelijk of de ZFS oplossing sneller en dus bruikbaar is.

[leuk_he]

raymonvdm schreef op woensdag 27 april 2011 @ 18:09:
Kan iemand vertellen wat de beste ZFS oplossing is qua disk indeling. Is wat deze kerel doet een goed idee ?

Als je verwacht veel te klooien met disks van verschillende groottte is het zeker een oplossing. Echter het feit dat je 4 stappen moet doen (en die begrijpen) om een disk uit te breiden is nou niet echt simpel te noemen.

Ook kan zfs omdat je verschillende pools op 1 disk hebt niet effecttief load balancen. En een raidz is wat betreft iops even snel als zijn langzaamste disk. (even zwaar versimpeld....bandbreedte en cache maakt het een ander verhaal). Dus disks van een verschillende generatie (80GB-250GB) mixen is niet echt bevordelijk voor de performance. Maar dat is niet in alle gevallen relevant. Merk ook op dat hij tijdens het upgraden in een degraded mode werkt. Als er dan een disk onderuit gaat heb je een groot probleem.

Als je geen fouten maakt is het wel een manier om meerdere disk sizes effect samen te gebruiken. Maar als je toch een dedicated file server neer zet kun je beter gewoon gelijke disks neerzetten.

voor het feit dat je diskruimte kwijt bent bij ongelijke disks in het originele zfs concept is het wel een mooie workarround.

Eigenlijk vind ik het gewoon lelijk dat zfs niet eens meld dat je ongebruikte diskruimte hebt in een mirror/raid omdat disk ongelijk zijn.

[raymonvdm]

Ik heb wat netwerk/snelheids problemen

raymonvdm in "Zuinige ESXi Server"

Wat halen jullie voor snelheid en vanaf wat voor soort machine is dat. Het lijkt erop dat mn laptop geen Jumbo frames ondersteund en dat daar een deel van de problemen onstaat maar dan nog is het niet heel snel te noemen

[Verwijderd]

van win7-64 naar samba share in zfs tank onder openindiana/napp-it

[warcow]

Ben mij al wat aan het oriënteren op de mogelijkheden van een nas systeem. Zoals het nu lijkt neig ik naar een Freenas setup met ZFS. Een write/read van 20 mb/s zou zeker al voldoende zijn over een 1 gigabit netwerk.
Is het haalbaar met een 4 of 5 * 3 TB disk Raid-Z1 setup op een systeem als de AMD brazos of Intel atom? (dualcore)

Hoeveel geheugen zal hierbij nodig zijn voor de gewenste performance?

edit: Lees net over de Core i3 2100T die inclusief moederbord/systeem al onder de 10 Watt idled. Dat is dan zeker een alternatief op het atom/brazos systeem en aardig sneller.

[ Voor 18% gewijzigd door warcow op 28-04-2011 01:25 ]

[Verwijderd]

Tp21 schreef op woensdag 27 april 2011 @ 17:11:
btrfs kan net zoals ZFS zelf raid doen, op het moment raid 0 en 1, maar in de (nabije) toekomst ook raid 5 en 6.

Hey dat is nieuws voor mij -- je hebt gelijk! Voor RAID5 en 6 moet je dan nog wel naar ouderwetse lagen grijpen, maar dit betekent wel dat Btrfs inderdaad een geduchte concurrent van ZFS kan worden in de toekomst. Ik vond het erg jammer dat Btrfs (naar ik dacht) nog steeds 'ouderwets' RAID nodig had en dit niet zelf kon doen. Maar dat kan dus wel, gelukkig.

Gelukkig, want keuzevrijheid is duidelijk in het voordeel van eindgebruikers. ZFS is fantastisch, maar een goed alternatief voor Linux-gebruikers is zeker niet verkeerd. Dat gezegd, voorlopig blijft ZFS toch wel de beste keus voor een NAS met goede bescherming voor je data, in elk geval totdat Btrfs volwassen is geworden.

@raymonvdm: zelf zou ik oude 80GB disks in de prullenmand gooien; die verbruiken relatief héél veel energie voor héél weinig opslag en zijn ook erg traag. Een 80GB disk heeft 40GB platters schat ik, dat is héél veel stappen terug van de huidige 666/750/1000GB platter generatie waar we nu zitten.

40GB @ 8W = 5GB per watt
2000GB @ 4W = 500GB per watt

Nieuwe schijven zijn dus een factor 100 zuiniger per opslageenheid. Laat staan de snelheid. Met de prijzen van Samsung F4 2TB is ook niets mis.

@warcow: Atom of Zacate zou prima moeten kunnen voor een simpele RAID-Z met weinig disks. Voor 8 disks of minder is dat wel oke, als je geen topsnelheid verwacht en geen geavanceerde functies als SHA256 checksums, compressie, encryptie, deduplicatie enzo gebruikt. Ook een Atom kan >2GB/s aan XOR doen.

Maar de beperking van Atom is dat je max 4GB RAM hebt, terwijl Zacate tot 16GB (in de praktijk 2x4= 8GB) kan doen. Bovendien biedt Zacate je een modernere chipset met 6x 6Gbps SATA. Nadeel is weer dat de gangbare bordjes geen Intel SASUC8i controller ondersteunen, dus uitbreiding is dan weet een probleem.

Hoeveel geheugen je nodig hebt ligt aan je wensen, maar voor een simpele config is 4GB prima te doen. Minder zou ik niet doen, dat ga je in elk geval in de snelheid merken. Ga je voor Zacate dan zou ik zeker 2x4= 8GB nemen, 1.35V DDR3 is mogelijk voor een nog lager verbruik.

Dat sub-10W Core i3 is alleen mogelijk met heftige tuning, reken op 22W met een PicoPSU met een kaal systeem (voeding, moederbord, geheugen en cpu-fan). Als je een conventionele ATX voeding wilt gebruiken kan het verbruik snel stijgen tot 40W - de meeste ATX voedingen zijn erg inefficient bij lage loads (50-60W schat ik). Ook 80+ voedingen met certificaat; die worden namelijk niet lager dan 20% load getest - en zelfs een 300W voeding is bij 20% load al 60W. Zie bijvoorbeeld dit plaatje:

[FireDrunk]

Maar dat is een 900W voeding, en een coolermaster... De Be Quiet L7 doet dat veel beter
Wel een beetje goed vergelijken he

[Kees]

Verwijderd schreef op woensdag 27 april 2011 @ 14:13:


Dus ZFS is inderdaad wel briljant en Btrfs kan zelfs hier niet aan tippen, ook al heeft Btrfs op veel vlakken vergelijkbare eigenschappen als ZFS. Daarnaast is ZFS veel meer volwassen en stabiel om echt te gebruiken zonder zorgen. Btrfs zit je alsnog met losse RAID en LVM lagen.

Zowel ZFS als btrfs zijn nu van Oracle, van mij mogen ze die twee teams wel mergen, of iig bij elkaar laten afkijken

[FireDrunk]

Ik dacht dat Oracle al had gezegd dat ze veel minder mensen op de ontwikkeling van ZFS zouden zetten.
Maar FreeBSD heeft het daarentegen juist opgepakt dacht ik. Dus zeggen dat het van Oracle is kan wel kloppen, maar de ontwikkelingen worden momenteel vooral gedaan door FreeBSD dacht ik


Oftopic: OpenIXSystems heette het toch?

[raymonvdm]

Verwijderd schreef op donderdag 28 april 2011 @ 00:21:
[afbeelding]

van win7-64 naar samba share in zfs tank onder openindiana/napp-it

Van jou wil ik wel eens een build how-to zien Ik wil eens kijken of ik het voor elkaar kan krijgen met wat oudere hardware door deze te voorzien van veel disken dan is de investering lager / rendement hoger. Ik hoef dan alleen een ander kastje / voeding en disken te kopen.

Ik ga er vanuit dat je openindiana server versie gebruikt ?

[ Voor 32% gewijzigd door raymonvdm op 28-04-2011 11:51 ]

[FireDrunk]

Zo moeilijk is dat toch niet?

[raymonvdm]

Blijkbaar wel Misschien moet er een "Show Your ZFS NAS" topic komen. Ik ben voor

[Ravefiend]

Verwijderd schreef op dinsdag 26 april 2011 @ 09:16:
[...]
en..

Wel ja, die method leek op het eerste zicht kinderlijk eenvoudig doch werkte het niet. Er zijn een paar extra stappen nodig op je Windows systeem om dit tot een goed einde te brengen.

Ondertussen dus mijn RAIDZ2 aangemaakt en dus kan ik wat tests beginnen uit te voeren. Vooraleerst maar eens nakijken of mijn 4K disks met de juiste ashift zijn ingesteld.

[Splendid]

raymonvdm schreef op donderdag 28 april 2011 @ 11:41:
Blijkbaar wel Misschien moet er een "Show Your ZFS NAS" topic komen. Ik ben voor

Ik zou sowieso wel een 'Show your DIY-NAS' topic willen zien

[Verwijderd]

Ravefiend schreef op donderdag 28 april 2011 @ 11:54:
[...]


Wel ja, die method leek op het eerste zicht kinderlijk eenvoudig doch werkte het niet. Er zijn een paar extra stappen nodig op je Windows systeem om dit tot een goed einde te brengen.

Ondertussen dus mijn RAIDZ2 aangemaakt en dus kan ik wat tests beginnen uit te voeren. Vooraleerst maar eens nakijken of mijn 4K disks met de juiste ashift zijn ingesteld.

Edit: Ok, so SliTaz is still useful by converting the .xz to .gz using:
1. Download FreeNAS-8.0-RC5-amd64.Full_Install.xz
2. Extract FreeNAS_amd64_embedded.xz
3. Download XZ Utils for Windows from http://tukaani.org/xz/
4. Extract the FreeNAS-8.0-RC5-amd64.Full_Install.xz using the XZ command line utility
5. Compress FreeNAS_amd64_embedded using gzip (Cygwin)
6. Put the FreeNAS_amd64_embedded.gz onto the SliTaz USB Flash Drive

Then you can put the FreeNAS_amd64_embedded.gz and use step 11 instead of step 12 at the above outlined instructions.



* punt 3 kan ook gewoon met 7 ZIP

[ Voor 3% gewijzigd door Verwijderd op 28-04-2011 14:21 ]

[Verwijderd]

raymonvdm schreef op donderdag 28 april 2011 @ 11:28:
[...]


Van jou wil ik wel eens een build how-to zien Ik wil eens kijken of ik het voor elkaar kan krijgen met wat oudere hardware door deze te voorzien van veel disken dan is de investering lager / rendement hoger. Ik hoef dan alleen een ander kastje / voeding en disken te kopen.

Ik ga er vanuit dat je openindiana server versie gebruikt ?

dat maakt kwa snelheid weing uit ..

[raymonvdm]

Nee wellicht niet maar is misschien wel handige info

[Ravefiend]

Toevallig niemand die een benchmark scriptje heeft voor FreeNAS die wat dd commands lanceert met verschillend bs en count waardes?

[FireDrunk]

das toch zo geschreven?

dd if=/dev/null of=/mnt/data/test1.bin bs=32 count=1024
dd if=/dev/null of=/mnt/data/test1.bin bs=64 count=1024
dd if=/dev/null of=/mnt/data/test1.bin bs=128 count=1024
dd if=/dev/null of=/mnt/data/test1.bin bs=256 count=1024
dd if=/dev/null of=/mnt/data/test1.bin bs=512 count=1024
dd if=/dev/null of=/mnt/data/test1.bin bs=1024 count=1024

[Verwijderd]

Vergeet niet de suffix bij 'bs' parameter, dus bs=128k of bs=1m. Als de count te laag is, krijg je cached results zoals 2GB/s+. Om echt sustained I/O te krijgen moet je tot 8 keer je RAM schrijven; behoorlijk veel meer dan een paar honderd meg dus.

[Ravefiend]

Bij deze heb ik het volgende script lopende:

code:

#!/bin/bash

BLOCKSIZE="4194304 16777216 1048576 524288 262144 131072 65536 32768 16384 8192 4096 1024 512 128"
LOG=raidz2-benchmark.log
TESTFILE=/mnt/tank1/ravefiend/testfile.bin
RAM_SIZE_GB=8
#TESTFILESIZE=8388608
TESTFILESIZE=$(($RAM_SIZE_GB*1024*1024*1024*10))
TRIES=4
DATASRC=/dev/zero
# DATASRC=/dev/urandom

echo "READ_WRITE|BLOCKSIZE|COUNT|DD_OUTPUT"
echo "READ_WRITE|BLOCKSIZE|COUNT|DD_OUTPUT" > $LOG

for x in $BLOCKSIZE
do
    i=0
    DD_COUNT=0
    DD_COUNT=$(($TESTFILESIZE/$x))
    while [ "$i" -lt $TRIES ]
    do
        TMP_W=`dd if=$DATASRC of=$TESTFILE bs=$x count=$DD_COUNT 2>&1 | grep bytes`
        echo "W|"$x"|"$DD_COUNT"|"$TMP_W 
        echo "W|"$x"|"$DD_COUNT"|"$TMP_W >> $LOG
        TMP_R=`dd if=$TESTFILE of=/dev/null bs=$x count=$DD_COUNT 2>&1 | grep bytes`
        echo "R|"$x"|"$DD_COUNT"|"$TMP_R
        echo "R|"$x"|"$DD_COUNT"|"$TMP_R >> $LOG
        ((i++))
        done 
done

Eens kijken wat voor resultaten we hiermee behalen.

Edit: Beginnen bij grotere blocksize want die is veel sneller, en /dev/zero werkt ook goed zolang ZFS compressie niet aan staat.

[ Voor 22% gewijzigd door Ravefiend op 29-04-2011 07:25 ]

[leuk_he]

FireDrunk schreef op donderdag 28 april 2011 @ 16:16:

dd if=/dev/null of=/mnt/data/test1.bin bs=32 count=1024

Tja... /dev/zero levert 0 data en goed comprimeerbaar. dat heeft niet zoveel zin lijkt me. (compressie staat meestal standaard aan toch....)

je zou dan beter ./dev/urandom kunnen gebruiken....

[ Voor 34% gewijzigd door leuk_he op 28-04-2011 17:35 ]

[Ravefiend]

leuk_he schreef op donderdag 28 april 2011 @ 17:34:
[...]


Tja... /dev/zero levert 0 data en goed comprimeerbaar. dat heeft niet zoveel zin lijkt me. (compressie staat meestal standaard aan toch....)

je zou dan beter ./dev/urandom kunnen gebruiken....

Good catch dus dat hebben we nog even aangepast ...

[Verwijderd]

Als je /dev/urandom of /dev/random gebruikt, zijn je benchmarks CPU-capped; dus dat zou ik niet doen. Nullen schrijven is even snel als random data schrijven voor normale bestanden op normaal ZFS filesystem zonder expliciet compressie ingeschakeld te hebben. Compressie staat standaard uit (alleen metadata wordt standaard gecomprimeerd).

/dev/urandom is voor BSD platform hetzelfde als /dev/random en geeft je snelheden onder de 100MB/s. Dat is dus voornamelijk een CPU-benchmark in plaats van een I/O-benchmark. Als je wilt weten wat de overhead is van compressie kun je proberen eerst random naar een RAM disk (tmpfs) te schrijven en dat vervolgens naar ZFS toe te kopieren.

[FireDrunk]

Probleem is dan weer dat je >10GB ram moet hebben.voor een accurate test...

[Verwijderd]

Dan test je toch gewoon met compressie uit? Kun je gewoon /dev/zero gebruiken, wel zo makkelijk.

[warcow]

Om nog even op die i3 setup terug te komen: Met het zotac ITX bordje en een goede voeding is die ~10 Watt idle goed mogelijk. (bij pricewatch werd er door een tweaker een 300Watt voeding gereviewed die zelfs met alleen een harde schijf eraan nog 80% efficient was geloof ik)

Het zotac bordje heeft overigens 6 sata aansluitingen waarvan 2 met 6 Gbps.
En bedankt voor de overige antwoorden, nu heb ik een idee van wat ik nodig heb.

[ Voor 11% gewijzigd door warcow op 28-04-2011 23:07 ]

[Verwijderd]

Nou dat wil ik dan wel eens zien; out of the box zonder modificaties 10W idle op een draaiend Core i3 systeem? Ik ken wel g3johan mux die met extreme modding een Core i3 systeem onder de 10W kreeg, maar out-of-the-box toch zeker het dubbele. Een ATX-voeding die op 10W load nog 80% efficient is, is ook bijna niet te vinden als dat überhaupt bestaat.

Als je het kunt vinden hoor ik het graag, zou echt een doorbraak zijn. Vooralsnog denk ik dat de praktijk toch minder rooskleurig is.

[ Voor 4% gewijzigd door Verwijderd op 29-04-2011 01:11 ]

[Dadona]

_{(g3johan moet ssj3gohan zijn, hij heeft z'n nick aangepast en gaat nu op Tweakers rond als 'mux')}
DC waarden van onder de 10W lukken wel, met een standaard i3. mux ging erg ver met zijn moederbord en deed dat met Windows 7. richardt kreeg hetzelfde voor elkaar, zonder modden, onder Linux. Het geheim is wel de inzet van een recentere kernel (die Debian niet heeft en Ubuntu niet heeft/had, .37) en de nodige custom kernel opties.
AC kom je inderdaad boven de 10W. Het probleem dat je hebt is dat de i3, stock, in stress richting de 60W loopt (cpu en gpu belast), je moet dus een aardige adapter nemen, waardoor je wat meer verlies moet nemen op lage belasting.

Maar goed, de dingen die ik nu zeg zijn al een beetje oud nieuws, inmiddels moeten we kijken naar de Sandybridge systemen die het ook best goed doen. Ik herinner mij een bericht dat Intel zich ook zou hebben bemoeid met de igp onder Linux en dat er daadwerkelijk zuinige opstellingen zijn ontdekt. Maar zeker het dubbele, nee dat echt niet, mits je maar aan de picopsu met een goede adapter gaat.
(Onder de 20W is eigenlijk geen sport meer, ook AMD duikt er inmiddels al, relatief, dik onder, met 15W AC idle waarden.)

[Verwijderd]

Ik ben toch enigszins sceptisch. Op een kaal systeem 15W halen lijkt me prima kunnen, maar met een ATX-voeding en een normale out-of-the-box Linux distributie en gigabit netwerk link zit je denk ik al gauw aan de 20W. Zo niet hoor ik het graag, maar het wordt nu wel enigszins off-topic.

Toch wel erg interessant; want een laag idle verbruik voor je ZFS NAS is wel degelijk interessant! Maar inhoudelijke discussies hierover kunnen wellicht beter in andere topics gevoerd worden.

Laat ik nog wel dit artikel aanhalen, waarin gesteld wordt dat recente Linux releases een significant hoger idle verbruik kennen dan oudere releases; erg teleurstellend als je het mij vraagt:
http://www.phoronix.com/s...=ubuntu_natty_power&num=2
(merk wel op dat 'idle' in feite 'light usage' is; beetje vreemd dat écht idle verbruik niet is getest vziw)

[Dadona]

ATX voeding gaat je niet lukken. Zodra je een 300W voeding inzet dan kom je boven de 20W. Maar goed, deze discussie is inderdaad niet specifiek iets voor in het ZFS topic. Er zijn een aantal topics (zoals het zuinige server topic) waarin energie efficiente samenstellingen langskomen.
De vraag is wel in welke mate de besturingssystemen met ZFS ook zuinig zijn. Er zijn de nodige inspanningen op Linux front (Die grafiekjes zijn idd onzinnig. je moet echt idle meten, 'light usage' is te verschillend. Daarnaast heb ik toch echt zelf ondervonden dat de recentere kernels zaken voor de i3 hebben gekregen waardoor het verbruik omlaag ging. Maar ook voor andere onderdelen op het mobo is ondersteuning gekomen. Daar komt bij dat Ubuntu 11 volgens mij ook iets minder energiezuinig is, de GUI is zwaarder.) Maar in welke mate zijn ze bij bijvoorbeeld FreeBSD op dat front goed bezig? Ik heb de indruk dat energieverbruik daar toch iets minder belangrijk is. (Linux komt wel op laptops, FreeBSD een heel stuk minder.)

[Ravefiend]

Ravefiend schreef op donderdag 28 april 2011 @ 11:54:
[...]
Ondertussen dus mijn RAIDZ2 aangemaakt en dus kan ik wat tests beginnen uit te voeren. Vooraleerst maar eens nakijken of mijn 4K disks met de juiste ashift zijn ingesteld.

Vaak wordt zdb gesuggereerd om dit te verifiëren maar op een FreeNAS 8.0 RC5 installatie dien je blijkbaar rekening te houden dat de zpool.cache file niet op de standaard locatie zijne /boot/zfs/zpool.cache staat, maar wel onder /data dus daarom:

code:

% zdb -U /data/zfs/zpool.cache | grep ashift
                         ashift=9

Dit had dus ashift=12 moeten zijn gezien de WD20EARS disks. Crap* ... Ticket 280 is dit: er is nog geen optie om dit aan te geven via the WebUI. Alternatief is dan maar het aanmaken van de zpool via cli? Is de gnop methode de beste of zijn er nog alternative / nettere oplossingen?

Is er trouwens nog een advies om net niet de ganse disks te alloceren, om zo problemen in de toekomst te vermijden wanneer een disk vervangen wordt door één die net iets kleiner is dan 2TB?

[ Voor 28% gewijzigd door Ravefiend op 29-04-2011 11:47 ]

[leuk_he]

Ravefiend schreef op vrijdag 29 april 2011 @ 10:47:
[...]
Is er trouwens nog een advies om net niet de ganse disks te alloceren, om zo problemen in de toekomst te vermijden wanneer een disk vervangen wordt door één die net iets kleiner is dan 2TB?

Nee, nog nergens gezien. Tenzij je verwacht een 2Tb disk te vervangen door een 1,5 Tb disk.

Ik heb wel gezien dat je de 1,5 Tb disk als hot spare kunt toevoegen, maar dat die niet geactiveerd kan worden in dat geval.

Ik heb het nog effe gechecked, maar zowel samsung als WDears als seagate hebben (2TB) schijven met exact 3,907,029,168 sectors.

Als je echt een kleineere schijf MOET toevoegen kun je uiteraard je pool opnieuw opbouwen met een export en import van de pool. (Ook zraid/snapshot zijn geen backup he, je blijft backups maken toch...)

[Verwijderd]

Gewoon partities gebruiken; tenzij je op Solaris platform zit dan kun je dat beter niet doen. ZFSguru kan disks formatteren met het reserveren van ruimte aan het einde (standaard 1 megabyte) en kan ook pools aanmaken met ashift=12 met de zogenaamde 'sectorsize override'. Daarna kun je gewoon rebooten naar je échte OS en de pool daarin importeren.

Op normaal FreeBSD kun je ashift zo controleren:
zdb -e <naamvandepool> | grep ashift

[Ravefiend]

Verwijderd schreef op vrijdag 29 april 2011 @ 13:07:
Gewoon partities gebruiken; tenzij je op Solaris platform zit dan kun je dat beter niet doen. ZFSguru kan disks formatteren met het reserveren van ruimte aan het einde (standaard 1 megabyte) en kan ook pools aanmaken met ashift=12 met de zogenaamde 'sectorsize override'. Daarna kun je gewoon rebooten naar je échte OS en de pool daarin importeren.

We houden het voorlopig op FreeNAS ... en wat jij dus voorstel lijkt me dan neer te komen op deze tutorial die het wat meer technisch benaderd. Kwestie van daarbij wat extra sectors ongebruikt te laten.

[Verwijderd]

Ben zelf niet zo'n voorstander van BSD partities (met a-f suffix) - die zijn incompatible met andere OS en ik denk dat je veel beter GPT partities kunt gebruiken die FreeBSD ook prima ondersteunt. Hoe FreeNAS hiermee omgaat weet ik niet precies, maar in principe zou dat moeten werken.

Voordeel van GPT partities is dat je een normale naam kunt geven; samsung4 bijvoorbeeld. Dat /dev/ad2s1a vind ik maar smerig; bovendien verhoogt het de kans op menselijke vergissingen, mogelijk met ernstige gevolgen. Door disk labels te gebruiken verklein je die kans, en het staat ook veel netter.

[Ravefiend]

Thx voor de feedback CiPHER. Mijn poging om GPT in de praktijk te brengen loopt helaas al spaak op het gebrek aan de gpt tool op FreeNAS. Deze heb ik daar toch voor nodig of vergis ik mij daarin? Of is gpart dan toch de juiste manier?

[ Voor 19% gewijzigd door Ravefiend op 29-04-2011 19:51 ]

[Verwijderd]

gpart create -s GPT /dev/ad4
gpart add -b 2048 -s 900g -t freebsd-zfs -l disk1 /dev/ad4

Dit maakt allereerst een GPT partitietabel aan op /dev/ad4. Daarna voegt het een nieuwe partitie toe die start op 2048 sectoren (1 megabyte); dit is de alignment ofwel offset. De grootte van de partitie wordt gegeven met het -s parameter en je kunt SI-suffix gebruiken zoals 'm' voor MiB en 'g' voor GiB. Het partitie-type dient freebsd-zfs te zijn (of freebsd-ufs voor UFS) en met -l (kleine L) geef je een naam aan de disk (géén spaties gebruiken!).

Merk op dat de groottes in binaire bytes zijn. Dus een 1TB disk is minder groot dan 1TiB. Het volgende commando's zijn handig voor offset en grootte:
gpart show /dev/ad4
diskinfo -v /dev/ad4
diskinfo -v /dev/gpt/disk1

Na het aanmaken van de GPT partitie krijg je een /dev/ad4p1 partitienaam, maar veel leuker is de labelnaam gebruiken in /dev/gpt/disk1. Die blijft hetzelfde hoe je de disk ook aansluit. Rommelen met je kabels of zelfs op een andere controller aansluiten blijft de disk onder dezelfde device name beschikbaar houden; erg handig!

[raymonvdm]

Ik ben vandaag weer even verder gegaan met openindiana maar ben nogal aan het "kutten tot het werkt"

In ubuntu en debian kom ik redelijk ver waar ik loop vast op BSD kennis. Het lukt me dus niet om een Samba share te maken waar ik ook iets mee kan. Ik heb via ZFS een share gemaakt maar ik mag er niet op inloggen

Kan iemand een voorbeeldje geven voor openindiana ?

code:

$ zfs set sharesmb=name=media tank/media

code:

beheer@openindiana:/var/log# zfs get sharesmb tank/media
NAME        PROPERTY  VALUE       SOURCE
tank/media  sharesmb  name=media  local

Het kan zijn dat ik een dubbele Samba actief heb want nadat ik delen van deze how to gevolgd heb wordt er logging weggeschreven in de loglocatie van de config file

http://wiki.genunix.org:8...esharing%29_Configuration


Ik heb nu iets wat werkt doormiddel van delen van deze how to te volgen
http://breden.org.uk/2008/03/08/home-fileserver-zfs-setup/

Ik haal nu 25mb/sec met het kopieren van een 1000mb.bin naar de ZFS machine toe. Dit is al meer dan de FreeBSD poging van afgelopen week. En 30mb/sec bij het lezen vanaf de ZFS machine

[ Voor 34% gewijzigd door raymonvdm op 01-05-2011 21:21 ]

[Verwijderd]

code:

zfs set sharesmb=on tank/media

Zou moeten werken onder Solaris distributies. Onder BSD werkt dit niet en moet je zelf met smb.conf kutten, zoals jij nu kennelijk hebt gedaan.

[raymonvdm]

Ik denk ook dat ik daar de mist in gegaan ben. Ik zal nog eens een keer een nieuwe installatie doen om te zien of het dan wel goed gaat. Trial and Error

[Verwijderd]

raymonvdm schreef op zondag 01 mei 2011 @ 23:26:
Ik denk ook dat ik daar de mist in gegaan ben. Ik zal nog eens een keer een nieuwe installatie doen om te zien of het dan wel goed gaat. Trial and Error

INFO

napp-it installen.. kan je dat soort zaken prima via een gui regelen.

[FireDrunk]

Hij draait BSD, dat is geen solaris.. Napp-it werkt toch alleen op solaris?

[Verwijderd]

FireDrunk schreef op maandag 02 mei 2011 @ 07:46:
Hij draait BSD, dat is geen solaris.. Napp-it werkt toch alleen op solaris?

klopt wel, maar de vraag was ' Kan iemand een voorbeeldje geven voor openindiana ? '

[Arnoud1]

Is het mogelijk om met ZFS onder FreeBSD alles schijven gewoon te versteken op een ander systeem, incl bootschijf? Dit zonder dataverlies enzo. Of moet die ZFS pool dan geimporteerd worden ofzo?

Met freenas kan ik de schijven versteken (bv van mobo naar raidkaart) zonder dat de zfs pool kapot gaat. Nu wil ik alle schijven uit mijn ene systeem (celeron + sasuc8i) versteken naar mijn E35M1-M PRO met 2 rocketraid 620 kaartjes, zonder dataverlies. De systeemschijf ook.

[Verwijderd]

Dat kan prima; maakt niet uit hoe je de disks aansluit. Al zou je ze allemaal in een USB behuizing zetten, dan werkt het ook.

De bootschijf is wel gevoeliger. Als je labels hebt gebruikt in je fstab geldt hetzelfde als hierboven. Als je voor je bootschijf ouderwetse MBR partities (/dev/ad4s1a bijvoorbeeld) hebt gebruikt dan kun je wel bootproblemen krijgen. Die kun je echter redelijk eenvoudig oplossen; als je weet hoe.

[Ravefiend]

Verwijderd schreef op zaterdag 30 april 2011 @ 02:05:
gpart create -s GPT /dev/ad4
gpart add -b 2048 -s 900g -t freebsd-zfs -l disk1 /dev/ad4
....
Na het aanmaken van de GPT partitie krijg je een /dev/ad4p1 partitienaam, maar veel leuker is de labelnaam gebruiken in /dev/gpt/disk1. Die blijft hetzelfde hoe je de disk ook aansluit. Rommelen met je kabels of zelfs op een andere controller aansluiten blijft de disk onder dezelfde device name beschikbaar houden; erg handig!

Hartelijk dank voor deze waardevolle toevoeging. Heb nog even het volgende uitgerekend, voor mijn WD20EARS (2TB) disks:

• 2000398934016 netto bytes per disk
• --> de laatste 100MB niet gebruiken dus 2000398934016 bytes - 104857600 bytes = 2000294076416 bytes
• --> 2000294076416 bytes afronden op 1MB maakt 2000294076416 bytes / (1024 * 1024) = 1,907,629.0859375
• ===> het integer gedeelte maakt dus netto 1907629 MB (1.81TB) = 2000293986304 bytes
• --> sector size is 512 bytes / sector oftewel 2000293986304 bytes / 512 = 3906824192 sectors

Dat maakt dat we de disks als volgt initialiseren en partitioneren:

code:

gpart create -s GPT /dev/da0
gpart add -b 2048 -s 3906824192 -t freebsd-zfs -l rz2_disk1 /dev/da0
gpart create -s GPT /dev/da1
gpart add -b 2048 -s 3906824192 -t freebsd-zfs -l rz2_disk2 /dev/da1
gpart create -s GPT /dev/da2
gpart add -b 2048 -s 3906824192 -t freebsd-zfs -l rz2_disk3 /dev/da2
gpart create -s GPT /dev/da3
gpart add -b 2048 -s 3906824192 -t freebsd-zfs -l rz2_disk4 /dev/da3
gpart create -s GPT /dev/da4
gpart add -b 2048 -s 3906824192 -t freebsd-zfs -l rz2_disk5 /dev/da4
gpart create -s GPT /dev/da5
gpart add -b 2048 -s 3906824192 -t freebsd-zfs -l rz2_disk6 /dev/da5
gpart create -s GPT /dev/da6
gpart add -b 2048 -s 3906824192 -t freebsd-zfs -l rz2_disk7 /dev/da6

Vervolgens zpool vanaf de cli want de FreeNAS WebUI ziet de aangemaakt partities niet:

code:

zpool create -fm /mnt/tank1 tank1 raidz2 gpt/rz2_disk1 gpt/rz2_disk2 gpt/rz2_disk3 gpt/rz2_disk4 gpt/rz2_disk5 gpt/rz2_disk6 spare gpt/rz2_disk7

Eens aangemaakt, is deze volume wel te importeren. Dan maar eens een benchmark uitgevoerd:

code:

READ_WRITE|BLOCKSIZE|COUNT|DD_OUTPUT
W|8192|8388608|68719476736 bytes transferred in 260.506653 secs (263791638 bytes/sec)
R|8192|8388608|68719476736 bytes transferred in 154.391123 secs (445099921 bytes/sec)
W|8192|8388608|68719476736 bytes transferred in 295.601786 secs (232473144 bytes/sec)
R|8192|8388608|68719476736 bytes transferred in 157.667309 secs (435851142 bytes/sec)
W|4096|16777216|68719476736 bytes transferred in 242.841785 secs (282980447 bytes/sec)
R|4096|16777216|68719476736 bytes transferred in 161.095860 secs (426575064 bytes/sec)
W|4096|16777216|68719476736 bytes transferred in 267.362988 secs (257026888 bytes/sec)
R|4096|16777216|68719476736 bytes transferred in 176.209113 secs (389988211 bytes/sec)
W|1024|67108864|68719476736 bytes transferred in 580.619804 secs (118355379 bytes/sec)
R|1024|67108864|68719476736 bytes transferred in 261.651758 secs (262637168 bytes/sec)

Bij mijn eerdere benchmark met een foutief aligned setup kwam ik niet hoger dan 320MB/s dus lijkt het erop dat dit wel beter is. Met dank aan CiPHER! Nu nog even verder kijken waarom dd na een tijdje het systeem om zeep help met "out of swap space" errors want dat is natuurlijk niet bedoeling. Met 8GB moet 'ie dit toch niet doen lijkt me zo.

[Verwijderd]

Om swap toe te voegen:

zfs create -V 4g tank/SWAP
zfs set org.freebsd:swap=on tank/SWAP
swapon /dev/zvol/tank/SWAP

Dit zal een 4GiB ZVOL aanmaken die automatisch als swap gebruikt wordt. Het laatste commando zorgt ervoor dat je niet hoeft te rebooten. Het middelste commando zorgt ervoor dat de ZVOL bij elke boot automatisch als swap zal worden geconfigureerd. Hiervoor moet de pool wel beschikbaar zijn tijdens boot; het werkt niet als je achteraf de pool nog moet importeren.

Je kunt controleren of je SWAP werkt met 'top' - alhoewel de gestripte FreeNAS dat misschien niet heeft.

Merk ook op dat al het werk wat jij met partities hebt gedaan veel makkelijker is met ZFSguru - een FreeNAS-achtige distro die heel netjes GPT partities aanmaakt inclusief reserveren van ruimte op het einde. Zelf gecontroleerd dat die partities inderdaad aligned zijn (1MiB offset).

[Ravefiend]

Verwijderd schreef op maandag 02 mei 2011 @ 18:16:
Merk ook op dat al het werk wat jij met partities hebt gedaan veel makkelijker is met ZFSguru - een FreeNAS-achtige distro die heel netjes GPT partities aanmaakt inclusief reserveren van ruimte op het einde. Zelf gecontroleerd dat die partities inderdaad aligned zijn (1MiB offset).

Zoiets had ik ook al begrepen inderdaad. Nu ja, FreeNAS lijkt er vooralsnog niet over te klagen en de offset lijkt me OK, gezien het resultaat van gpart die het volgende weergeeft:

code:

freenas# gpart show -l
=>        34  3907029101  da0  GPT  (1.8T)
          34        2014       - free -  (1.0M)
        2048  3906824192    1  rz2_disk1  (1.8T)
  3906826240      202895       - free -  (99M)

=>        34  3907029101  da1  GPT  (1.8T)
          34        2014       - free -  (1.0M)
        2048  3906824192    1  rz2_disk2  (1.8T)
  3906826240      202895       - free -  (99M)
...

Dus de partitie begint op sector 2048, wat met 512 bytes / sector een offset van 1 MiB maakt. .. Misschien dat ik ZFSguru nog wel eens probeer gezien FreeNAS WebUI de disks zelf niet goed detecteerd. Anders gezegd, die toont enkel de raw disks zelve.

[ Voor 41% gewijzigd door Ravefiend op 03-05-2011 09:21 ]

[raymonvdm]

FireDrunk schreef op maandag 02 mei 2011 @ 07:46:
Hij draait BSD, dat is geen solaris.. Napp-it werkt toch alleen op solaris?

Ik heb tegenwoordig OpenIndiana dat is toch Solaris ? Ik heb al iets gezien over Napp-it en ik dacht dat die er voor Solaris en BSD is..

Ik kan het alleen niet vinden op http://www.napp-it.org/index_en.html

Die aanpassingen met gpart is dat voor alle ZFS installaties nodig of heeft dat iets met FreeNAS te maken ?

[ Voor 12% gewijzigd door raymonvdm op 03-05-2011 10:27 ]

[Verwijderd]

raymonvdm schreef op dinsdag 03 mei 2011 @ 10:24:
[...]


Ik heb tegenwoordig OpenIndiana dat is toch Solaris ? Ik heb al iets gezien over Napp-it en ik dacht dat die er voor Solaris en BSD is..

Ik kan het alleen niet vinden op http://www.napp-it.org/index_en.html

Die aanpassingen met gpart is dat voor alle ZFS installaties nodig of heeft dat iets met FreeNAS te maken ?

http://www.napp-it.org/downloads/index_en.html

het staat er toch ? openindiana of nexentacore

tip : je eigen scripts binnen napp-it ?

'Napp-it is really awesome and I was hoping I could throw in a (probably easy) feature request. My server is connected to a UPS and it can monitor the UPS via APCUPSD, which runs well on solaris. It has some cgi scripts to generate UPS status information, see:http://www.apcupsd.com/manual/manual...g-cgi-programs

I was wondering if it would be possible to have napp-it display this information?

Thanks!
s0rce'

1.
copy your cgi files to /var/web-gui/wwwroot/_my

2.
make them executable

3.
call them via
http://serverip:81/_my/cgifile

and check if they work

4.
create a private menu in napp-it and link to this cgi-files
you may embedd the link in an iframe just i do it with help pages

[ Voor 45% gewijzigd door Verwijderd op 03-05-2011 10:58 ]

[Ravefiend]

Zoals gezegd, heb ik nu een pool genaamd tank1:

code:

zpool create -fm /mnt/tank1 tank1 raidz2 gpt/rz2_disk1 gpt/rz2_disk2 gpt/rz2_disk3 gpt/rz2_disk4 gpt/rz2_disk5 gpt/rz2_disk6 spare gpt/rz2_disk7

Dit resulteert in het volgende config (zpool status):

code:

NAME
tank1
  raidz2
    gpt/rz2_disk1
    gpt/rz2_disk2
    gpt/rz2_disk3
    gpt/rz2_disk4
    gpt/rz2_disk5
    gpt/rz2_disk6
spares
  gpt/rz2_disk7

Om de performance ruwweg te verdubbelen zou men hier 6 bijkomende disks toevoegen via een 2de vdev, striped that is. Met welk zpool command bekomt men dan zo'n aanpassing zonder de bestaande pool te moeten hercreëeren?

[Verwijderd]

zpool add tank1 raidz2 gpt/blah1 gpt/blah2 gpt/blah3 gpt/blah4 gpt/blah5 gpt/blah6

blah veranderen in de GPT label naam van je nieuwe 6 disks. Het uitvoeren duurt een seconde en dan heb je direct extra ruimte. Pas nieuwe data die je op de pool zet heeft snelheidswinst; de bestaande data blijft staan op de eerste vdev en zal dus geen snelheidswinst kennen.

[ Voor 42% gewijzigd door Verwijderd op 04-05-2011 15:25 ]

[Ravefiend]

Verwijderd schreef op woensdag 04 mei 2011 @ 15:24:
zpool add tank1 raidz2 gpt/blah1 gpt/blah2 gpt/blah3 gpt/blah4 gpt/blah5 gpt/blah6

ZFS commands zijn gewoon té voor de hand liggend ... .. Heb het ook even getest in een VM (FreeNAS en inderdaad, het is zo eenvoudig. Dan bekom je:

code:

NAME
tank1
  raidz2
    gpt/rz2_disk1
    gpt/rz2_disk2
    gpt/rz2_disk3
    gpt/rz2_disk4
    gpt/rz2_disk5
    gpt/rz2_disk6
  raidz2
    gpt/rz2_disk8
    gpt/rz2_disk9
    gpt/rz2_disk10
    gpt/rz2_disk11
    gpt/rz2_disk12
    gpt/rz2_disk13
spares
  gpt/rz2_disk7

Goed om dit te weten vooraleer we er daadwerkelijk data op gaan zetten, zodat de huidige RAIDZ2 later zonder al teveel problemen nog kan uitbreidt worden voor meer diskspace en performance.

[Ultraman]

Lekker bezig met die raidz2 setjes
Zelf voor mij nog overkill. Ik besloten om mijn vier schijven te gaan configureren als striped mirrors ipv 3-disk raidz1 en een schijf over te hebben.

Wat ik me nou eens voor de grap af vroeg. ZFS is een aardig slim fs. Bij RAID10 is het zo dat als het breekt (een complete mirror weg), dat je alles kwijt bent. Waar ik nou benieuwd naar ben is:
Stel je raak van een striped mirror, een stripe kwijt. Dus je heb nog maar een mirror van de stripe over.

Is de data op die ene mirror dan nog wel intact?
Want ik heb zo'n gevoel dat ZFS dat best zou moeten kunnen, maar ik kan geen bevestiging daarvoor vinden. Benieuwd of men dat hier misschien weet.
Uiteraard kan ik gaan experimenteren en er achter komen, maar ik zit op moment niet thuis en ik ben gewoon eens benieuwd dus

[Verwijderd]

Hoe bedoel je dat precies? Alle vdevs worden gestriped. Ravefiend hierboven heeft na de expansion dus een stripe van twee RAID-Z2's.

Bij RAID1+0 heb je mirrors die gestriped worden. Zeg dat je 4 disks hebt:
mirror
disk1
disk2
mirror
disk3
disk4

Dat is dus een stripe van twee mirrors. De mirror blijft werken als disk1 en disk4 compleet uitvallen. De pool wordt unavailable zodra disk3 én disk4 (of disk1 én disk2) uitvallen - je mag namelijk geen enkele vdev missen.

Leuk nieuwtje is dat ZFS heel gemakkelijk een mirror kan maken van een enkele disk (attach een device aan de single disk) en weer een single disk kan maken van een mirror (detach). Je kunt dus bijvoorbeeld met een 4-disk RAID0 beginnen en telkens een extra disk toevoegen en uiteindelijk een RAID1+0 hebben met 8 disks totaal. Of even een diskje lenen van je mirror. Dat laatste heeft natuurlijk wel risico; als die ene single disk uitvalt ben je de hele pool kwijt.

[Ultraman]

Verwijderd schreef op woensdag 04 mei 2011 @ 16:27:
Hoe bedoel je dat precies? Alle vdevs worden gestriped. Ravefiend hierboven heeft na de expansion dus een stripe van twee RAID-Z2's.

Yup.

Bij RAID1+0 heb je mirrors die gestriped worden. Zeg dat je 4 disks hebt:
mirror
disk1
disk2
mirror
disk3
disk4

Dat is dus een stripe van twee mirrors. De mirror blijft werken als disk1 en disk4 compleet uitvallen. De pool wordt unavailable zodra disk3 én disk4 (of disk1 én disk2) uitvallen - je mag namelijk geen enkele vdev missen.

Bij RAID10 breekt de boel idd zodra een complete mirror (d1+d2 | d3+d4) uitvalt. Bij ZFS dus ook? Omdat data over de twee mirror vdev's gestriped wordt, en wanneer een mirror wegvalt je dus halve data hebt ==> geen data.
Ik zat even te denken dat de twee hele mirrors als een JBOD aan elkaar zaten met een 4-disk ZFS "raid10" opstelling. En als je dan een complete mirror mist, dat de files op de nog werkende mirror er nog wel zouden kunnen zijn.
Maar aangezien de blocks gestriped worden is dat natuurlijk niet het geval.

Wel is ZFS zo slim dat je met een mirror min of meer van beide disks tegelijk kunt lezen en zo je iops hoger zijn correct? Afhankelijk v/d de gevraagde read natuurlijk, maar even in ideaal geval bedoel ik nu.

Leuk nieuwtje is dat ZFS heel gemakkelijk een mirror kan maken van een enkele disk (attach een device aan de single disk) en weer een single disk kan maken van een mirror (detach). Je kunt dus bijvoorbeeld met een 4-disk RAID0 beginnen en telkens een extra disk toevoegen en uiteindelijk een RAID1+0 hebben met 8 disks totaal. Of even een diskje lenen van je mirror. Dat laatste heeft natuurlijk wel risico; als die ene single disk uitvalt ben je de hele pool kwijt.

Hey dat is handig. Dan kan ik mooi 3 disken in mijn servertje steken en een broken raid10 aanmaken, data er op knallen en vervolgens de backupschijf legen en toevoegen als mirror voor de single disk.
Is gelijk de verdeling van de data over de vier schijven op orde.

[Dadona]

Het begint nu toch wel opvallend stil te worden wat ZFS guru betreft. Jason is al een tijdje nergens te bekennen, zonder blijkbaar enige aankondiging. Dit terwijl hij daarvoor dagelijks rondliep op hardforum en op zijn eigen site. Mogelijk dat er iets naars op zijn pad is gekomen, zomaar plotsklaps alleen een gebrek aan motivatie lijkt mij sterk. Misschien om toch in de gaten te houden, een eenmansproject is altijd lastig, maar helemaal in deze staat zou ik er niet zomaar mee aan de gang gaan.
En eigenlijk vind ik het tot daar aan toe als het project stopt, maar zijn kennis van ZFS zou toch wel een gemis zijn. Maar goed, even afwachten...

[Ravefiend]

Dadona schreef op woensdag 04 mei 2011 @ 19:26:
Het begint nu toch wel opvallend stil te worden wat ZFS guru betreft. Jason is al een tijdje nergens te bekennen, zonder blijkbaar enige aankondiging. Dit terwijl hij daarvoor dagelijks rondliep op hardforum en op zijn eigen site. Mogelijk dat er iets naars op zijn pad is gekomen, zomaar plotsklaps alleen een gebrek aan motivatie lijkt mij sterk. Misschien om toch in de gaten te houden, een eenmansproject is altijd lastig, maar helemaal in deze staat zou ik er niet zomaar mee aan de gang gaan.
En eigenlijk vind ik het tot daar aan toe als het project stopt, maar zijn kennis van ZFS zou toch wel een gemis zijn. Maar goed, even afwachten...

Wel ja, en daar tegenover staat FreeNAS wat door iXsystems verder ontwikkeld wordt. Voor hen is FreeNAS een product dat een commerciële potentieel biedt via professionele support tegen betaling. Eerst zien dan geloven, I know, dus we kunnen maar hopen dat ze voldoende klanten weten te vinden zodat FreeNAS ook niet een stille dood tegemoed gaat. Hoe dan ook, ZFS an sich heeft voldoende potentieel en daar zal ongetwijfeld wel een markt voor zijn.

[FireDrunk]

Ik weet al van een paar grote jongens die ZFS gebruiken onder Oracle en onder SAP. Dus ik denk dat er desnoods wel wat geld vrij komt

[Ravefiend]

FireDrunk schreef op woensdag 04 mei 2011 @ 20:19:
Ik weet al van een paar grote jongens die ZFS gebruiken onder Oracle en onder SAP. Dus ik denk dat er desnoods wel wat geld vrij komt

Wel ja, Oracle heeft al een aantal producten, Oracle Exadata being one of them, die gebruik maken van ZFS dus dat zit wel snor, en dan zet ik maar gelijk een disclaimer bij dat ik zelf voor Oracle werkzaam ben, helaas in een gans ander domein dan ZFS oid ...

[Dadona]

Ik ben ook niet bang voor ZFS op zich. Dat staat of valt echt niet met ZFS guru of FreeNAS. Maar het lijkt mij wel een belangrijke overweging of je wel of niet inzet op een FreeBSD (based) oplossing als een gui belangrijk voor je is.
Overigens, het is mei, de FreeBSD community zag mei toch als de maand waarin 9 stable het levenslicht zou moeten zien, misschien nog juni?

[ Voor 23% gewijzigd door Dadona op 04-05-2011 21:06 ]

[Ultraman]

Dat was de oorspronkelijke voorspelling ja. Maar zolang HEAD nog open staat zul je nog geen 9.0-RELEASE zien. Eerst moet HEAD bevroren worden (voor features e.d.), dan volgen er enkele RC's en daarna pas kun je een RELEASE tegemoet zien.
Ik vermoed augustus als geboortemaand van 9.0-RELEASE. Op de voet gevolgd door 8.3.

[ Voor 3% gewijzigd door Ultraman op 05-05-2011 07:57 ]

[Verwijderd]

Pas als de eerste 9.0-RC wordt gereleased, zal HEAD gebranched worden en komt er:
10-CURRENT ("HEAD")
9-STABLE (RC)

Althans zo gaat dat traditioneel met FreeBSD; alleen de 5.x reeks was een uitzondering waarbij pas bij 5.3 een 5-STABLE branch kwam.

Ik denk dat je van de zomer 9.0-RELEASE kunt verwachten; lijkt me een toffe release!

[Verwijderd]

Even een mooie crosspost (Verwijderd in "Het grote DIY RAID NAS topic deel 3"):

Iemand al ervaring met Squeeze en ZFS?

Van tweakers: "Na een ontwikkeltijd van twee jaar is Debian 6.0 uitgebracht. De Linux-distributie, die codenaam 'Squeeze' draagt, bevat onder andere een preview van Debian GNU/kFreeBSD, waarbij Debian-code gecombineerd wordt met de FreeBSD-kernel.", nieuws: Debian brengt versie 6.0 'Squeeze' uit

Op http://debian.fmi.uni-sof...zekFreeBSD-released!.html staat: "The 64bit release of Debian 6.0/kFreeBSD supports native ZFS as root partition. The kernel is now FreeBSD and there is no need for fuse now, so ZFS should now show its full potential."

Daarom ben ik juist zo benieuwd hoe ZFS zonder Fuse werkt op Linux

[Verwijderd]

Dat is geen Linux maar FreeBSD met GNU userland. Dus ook gewoon de FreeBSD ZFS implementatie. Net zoals Nexenta geen Linux is maar Solaris met GNU userland.

[Wouter.S]

FREENAS 8.0 is vandaag officieel gelanceerd.
http://sourceforge.net/projects/freenas/files/FreeNAS-8/

Momenteel werk ik nog met de 7.2 versie en overstappen zit er nog niet in. Hoewel de 8.0 versie al ongeveer alle gangbare file sharing protocols ondersteunt, zijn er voor mij persoonlijk nog functies die ontbreken zoals bijvoorbeeld de transmission torrent client. Hoewel dit strict genomen misschien geen NAS toepassing is, is het voor veel gebruikers wel een gemis volgens mij.

[FireDrunk]

Ik heb hem net geinstalleerd onder ESXi, en hij werkt prima. Snelheid valt me nog een beetje tegen.
~160MB/s schrijven met 4 x 2TB in RAID-Z

[ Voor 3% gewijzigd door FireDrunk op 05-05-2011 21:17 ]

[Verwijderd]

@ Wouter.S

heb je de roadmap gezien.. FreeNAS 8.1 gaat de 'kerstboom' versieren :

Migration utility from .7 to 8.x
Translations
SMART monitoring
more detailed system info
UPS management
rsync config GUI
cron mangement GUI
Error reporting/user feedback
Encryption
Network bandwidth reporting
Webserver
3rd party plug-ins system (modified PBI's from PC-BSD)
Unison config (using plug-in system?)
Mount management GUI
Home user features once plug-in system is working
BitTorrent
UPnP/DAAP/DLNA

jammer dat ze ZFS niet upgraden maar dat komt ooit ook nog wel.

[ Voor 201% gewijzigd door Verwijderd op 06-05-2011 16:37 ]

[Verwijderd]

.

[ Voor 101% gewijzigd door Verwijderd op 06-05-2011 10:16 ]

[Contagion]

edit:
Lezen... ZONDER zfs-fuse staat er in bericht van Backlash, niet ONDER. Sorry, relaas over m'n server op basis van zfs-fuse verwijderd...

Borroz/Firedrunk: wat voor host processor/mem gebruiken jullie? Ik kom (met zfs-fuse dus en dan ook alleen lezen van disk) niet hoger dan 70-80 MB/sec over NFS (met oude Athlon64 3000+/1 GB)

[ Voor 129% gewijzigd door Contagion op 06-05-2011 00:12 . Reden: Niet goed gelezen ]

[raymonvdm]

Xeon 3050 met 4GB en Openindinana en 2x 80GB SATA in radi1 (raidz) en ik kom niet boven de 30Mb/s dus jullie moeten niet zeuren over de snelheid dat mag ik alleen

[ Voor 5% gewijzigd door raymonvdm op 06-05-2011 00:29 ]

[FireDrunk]

Uh, ik haalde met OpenIndiana > 250MB/s lezen en schrijven
CPU is een Xeon 3430 (2.4Ghz QC)

[Verwijderd]

@ Contagion

crosspost SPECS

[ Voor 224% gewijzigd door Verwijderd op 06-05-2011 10:42 ]

[Sonic]

FireDrunk schreef op vrijdag 06 mei 2011 @ 07:41:
Uh, ik haalde met OpenIndiana > 250MB/s lezen en schrijven
CPU is een Xeon 3430 (2.4Ghz QC)

Draai je OpenIndiana als een VM?

[FireDrunk]

Draaide...

[raymonvdm]

Toevallig net nog even een google gedaan naar Ubuntu en ZFS

Ik heb nu namelijk een aantal ubuntu servers en omdat het niet anders kan een CentOS machine. Het liefst zou ik ZFS gebruiken binnen Ubuntu maar dat kan blijkbaar native nog niet. Het lijkt erop dat Nexenta wel iets in die richting is maar dat is me onduidelijk.

Ik wil dus eigenlijk alleen maar mn huidige servertje (Ubuntu 10.04 LTS Server) willen voorzien van veel strorage op basis van ZFS zodat ik geen raid controller of iets nodig heb.

http://www.osnews.com/sto..._Server_with_ZFS_goodness

[ Voor 7% gewijzigd door raymonvdm op 06-05-2011 17:28 ]