Het grote ZFS topic

[Verwijderd]

Ik ben bang dat als ik een normale "zpool upgrade" doe er allerlei features flags aan gaan waarna ik compatibility verlies.

Die vrees is heel erg terecht en wees ajb voorzichtig! Je molt je compatibility.

Je kunt volgens mij het beste enkel één feature enablen. Dit zal je pool upgraden naar v5000 maar niet gelijk alle features op enabled gooien waardoor je pool nooit meer te importeren is op andere OS.

[CurlyMo]

@Wiebeltje, Zie de links van de TS. Onlangs ben ik hier uitgebreid op ingegaan.

[ Voor 54% gewijzigd door CurlyMo op 15-12-2014 11:19 ]

[Wiebeltje]

Check! Dan ga ik die zpool versie toch maar laten denk ik. Ik ben nu heel tevreden over Ubuntu + ZOL maar ik hou de optie toch graag open om terug te kunnen naar FreeBSD...

Ik heb de export / import gedaan en opzich is het goed gaan alleen kloppen de labels niet helemaal. De labels zijn hdd1 en hdd2 alleen hij laat de cijfers dus weg blijkbaar :-/ . Als ik de partie tabel print via parted staat er wel gewoon hdd1 en hdd2.

config:

        NAME         STATE     READ WRITE CKSUM
        datapool     ONLINE       0     0     0
          mirror-0   ONLINE       0     0     0
            hdd      ONLINE       0     0     0
            hdd      ONLINE       0     0     0
        cache
          zfs-cache  ONLINE       0     0     0

# parted /dev/sdb print
Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      17.4kB  280kB   262kB
 2      283kB   3001GB  3001GB  zfs          hdd1

[ Voor 16% gewijzigd door Wiebeltje op 15-12-2014 11:22 ]

[FireDrunk]

Hmm, vreemd, klinkt als een bugje. Waarschijnlijk denkt ZFSonLinux slim te zijn en het nummertje voor je weg te halen...

Misschien even een bugreportje doen.

[CurlyMo]

Feature flags aanzetten kan prima zolang je even mijn posts erover leest. Zou zonde zijn om lz4 niet te gebruiken bijvoorbeeld.

[Gonadan]

Opnieuw opgestart en nu is mijn pool weg.

[ Voor 118% gewijzigd door Gonadan op 15-12-2014 15:07 ]

[FREAKJAM]

cat /var/log/messages | grep zfs

Bestaat er een bestand /etc/zfs/zpool.cache?

[Gonadan]

Ja die bestaat nog. Ik was even gaan zoeken buiten de standaard status:

Blijkbaar vind hij dat er al corrupted data op staat, dat is rap. Hele pool corrupted en niet meer te importeren.

code:

   pool: data1
     id: 6035867969645106503
  state: FAULTED
 status: One or more devices contains corrupted data.
 action: The pool cannot be imported due to damaged devices or data.
        The pool may be active on another system, but can be imported using
        the '-f' flag.
   see: http://zfsonlinux.org/msg/ZFS-8000-5E
 config:

        data1                                         FAULTED  corrupted data
          raidz1-0                                    ONLINE
            ata-WDC_WD30EZRX-00D8PB0_WD-WCC4NDPT01JV  UNAVAIL  corrupted data
            ata-WDC_WD30EZRX-00D8PB0_WD-WCC4NHDR8C5E  UNAVAIL  corrupted data
            ata-WDC_WD30EZRX-00D8PB0_WD-WCC4NKCPS5PY  UNAVAIL  corrupted data
            ata-WDC_WD30EZRX-00D8PB0_WD-WCC4NCCAUNUV  UNAVAIL  corrupted data

Edit:

code:

sudo zpool import -d /dev/disk/by-partlabel data1

En hij doet het weer prima.

[ Voor 72% gewijzigd door Gonadan op 15-12-2014 15:16 ]

[FREAKJAM]

Hoe heb je de pool initieel aangemaakt? Las dat FireDrunk je had geadviseerd op basis van gpt labels een pool aan te maken.

Wat krijg je als je sudo zpool import -d /dev/disk/by-partlabel/ doet? (Nu lijkt hij sudo zpool import -d /dev/disk/by-id/ uit te voeren, wat hij default doet). Kan zijn dat je in de zfs config moet uitzetten dat hij op basis van "by-id" de import moet doen.

1.3.1 Ubuntu 14.04 LTS (Trusty Tahr) and earlier.

All storage pool devices come online and appear in /dev/disk/by-id.
Upstart runs the /etc/init/mountall.conf part.
The /sbin/mountall utility calls the /sbin/zfs list command.
The /sbin/zfs utility inserts the zfs.ko kernel module.
The ZFS driver reads the /etc/zfs/zpool.cache file, which contains a list of disks in each zpool. Any disk that is not ready during this step faults out of the pool.
The /sbin/mountall utility mounts all ZFS filesystems and all /etc/fstab entries during the same pass.
The /sbin/mountall utility issues the local-filesystems event for Upstart.

Nog belangrijker:

Do not set ZFS_MOUNT=y in the /etc/default/zfs file. (This option is deprecated. The /etc/init.d/zfs-mount script will not be installed for new installations.)

Lees ook anders even hier de boel door, bij de laatste ZFS update voor Ubuntu is het een en ander veranderd omdat 0.6.4 systemd ready moet zijn.

[ Voor 17% gewijzigd door FREAKJAM op 15-12-2014 15:23 ]

[Gonadan]

Zie boven, dat helpt inderdaad. Mijn boerenverstand zegt mij dat hij probeert de pool op de oude manier te starten. Dat lukt dus niet. Ik ga even op zoek waar je zoiets uberhaupt kunt instellen.

[FREAKJAM]

Gonadan schreef op maandag 15 december 2014 @ 15:22:
Zie boven, dat helpt inderdaad. Mijn boerenverstand zegt mij dat hij probeert de pool op de oude manier te starten. Dat lukt dus niet. Ik ga even op zoek waar je zoiets uberhaupt kunt instellen.

Wat staat er in je /etc/default/zfs?

[Gonadan]

code:

# ZoL userland configuration.

# Wait this many seconds during system start for pool member devices to appear
# before attempting import and starting mountall.
ZFS_AUTOIMPORT_TIMEOUT='30'

# Run `zfs share -a` during system start?
# nb: The shareiscsi, sharenfs, and sharesmb dataset properties.
ZFS_SHARE='no'

# Run `zfs unshare -a` during system stop?
ZFS_UNSHARE='no'

# Build kernel modules with the --enable-debug switch?
ZFS_DKMS_ENABLE_DEBUG='no'

# Build kernel modules with the --enable-debug-dmu-tx switch?
ZFS_DKMS_ENABLE_DEBUG_DMU_TX='no'

# Keep debugging symbols in kernel modules?
ZFS_DKMS_DISABLE_STRIP='no'

# Wait for this many seconds in the initrd pre_mountroot?
# This delays startup and should be '0' on most systems.
ZFS_INITRD_PRE_MOUNTROOT_SLEEP='0'

[FREAKJAM]

Dat is goed, dat config is op basis van de nieuwste zfs release. (in de vorige release stond er ZFS_MOUNT=y in de config).

Wat staat er in het bestand /etc/init/mountall.conf?

[Gonadan]

code:

# mountall - Mount filesystems on boot
#
# This helper mounts filesystems in the correct order as the devices
# and mountpoints become available.

description     "Mount filesystems on boot"

start on startup
stop on starting rcS

expect daemon
task

emits virtual-filesystems
emits local-filesystems
emits remote-filesystems
emits all-swaps
emits filesystem
emits mounting
emits mounted

script
    . /etc/default/rcS || true
    [ -f /forcefsck ] && force_fsck="--force-fsck"
    [ "$FSCKFIX" = "yes" ] && fsck_fix="--fsck-fix"

    # Doesn't work so well if mountall is responsible for mounting /proc, heh.
    if [ -e /proc/cmdline ]; then
        read line < /proc/cmdline
        for arg in $line; do
            case $arg in
                -q|--quiet|-v|--verbose|--debug)
                    debug_arg=$arg
                    ;;
            esac
        done < /proc/cmdline
    fi
    # set $LANG so that messages appearing in plymouth are translated
    if [ -r /etc/default/locale ]; then
        . /etc/default/locale || true
        export LANG LANGUAGE LC_MESSAGES LC_ALL
    fi


    exec mountall --daemon $force_fsck $fsck_fix $debug_arg
end script

post-stop script
    rm -f /forcefsck 2>dev/null || true
end script

Volgens apt staat de policy op de zfs-variant van mountall, dus dat zou goed moeten zijn. Of is dat misschien vernaggeld met de recente dist-upgrade?

[ Voor 5% gewijzigd door Gonadan op 15-12-2014 15:34 ]

[FREAKJAM]

Je kunt ook nog even kijken in /etc/init/zpool-import.conf

Anders zou ik het volgende doen; (lees eerst even dit door, ik heb het geneuzel ook gehad een tijdje terug na een dist-upgrade).

Export je huidige pool opnieuw en controleer of het bestand /etc/zfs/zpool.cache weg is. (Zo niet, dan even handmatig verwijderen). Verder zit er een bug volgens mij in 0.6.3-3. Je moet je hostid goed zetten/opnieuw genereren want nu klopt op een of andere manier je hostid niet meer, dus denkt hij dat je pool van een vreemd systeem komt, dus mount hij hem niet automatisch.

Je kunt je hostid met de volgende commandos opnieuw genereren:
dd if=/dev/urandom of=/etc/hostid bs=4 count=1
update-initramfs -c -k all

[Gonadan]

Aan die zpool-import.conf ga ik niets vreemds zien, het is gewoon een script, daar mis ik wat kennis voor.

Een hostid heb ik inderdaad niet (meer?). Ik zal jouw stappen wel gaan proberen dan.

[FREAKJAM]

Ik ken de scripts ook niet zo heel erg goed. Sinds de laatste ZFS update hebben ze boel flink op de schop gegooid in Ubuntu. Ik was er ook niet zo heel erg blij mee.

Ik draai nu inmiddels alles in CentOS 7, ik was Ubuntu beu geworden

[Gonadan]

Dat flikken ze mij ook even te vaak inderdaad. Importeren voor of na de reboot?

[FREAKJAM]

Het biedt geen garantie hoor, ik denk alleen maar met je mee.

Maar volgens een knakker op github zou het in de volgende volgorde moeten werken;
do the hostid thing and ran a zpool export/zpool import and reran the updateinitramfs.
All is good now - removed the /etc/init/zfs.override and it boots cleanly

[IceTeaGX]

Tussendoor even iets anders:
De console (en logs) van mijn ZFS guru tonen het volgende:


DA1 is een RDMed 120GB OCZ SSD gebruikt als SLOG en L2ARC.
Heb al wat gegoogeld, maar niet direct iets nuttig gevonden.

[Verwijderd]

Check je SMART. Kabelproblemen?

[Gonadan]

FREAKJAM schreef op maandag 15 december 2014 @ 15:53:
Het biedt geen garantie hoor, ik denk alleen maar met je mee.

Maar volgens een knakker op github zou het in de volgende volgorde moeten werken;
do the hostid thing and ran a zpool export/zpool import and reran the updateinitramfs.
All is good now - removed the /etc/init/zfs.override and it boots cleanly

Haha daar waar hij eerst alleen niet wilde mounten begint hij nu ook over de id.
Via de stappen dat nu gefixt, dus blijkbaar was die ID nooit veranderd maar heb ik er nooit een gehad.

Verder helaas dezelfde situatie, hij mount niet vanzelf. Alleen als ik het op partlabel doe.

[syl765]

@IceteaGX

Als het je SLOG is en deze is niet gemirrored, dan zou ik wel een beetje voorzichtig zijn.
Een SLOG device die faalt kan wel eens voor grotere problemen zorgen. Nu moet er wel aan een aantal randzaken voldaan worden wil het echt misgaan, maar Murphy's Law weet daar soms goed raad mee.

Zoals Cipher al aangaf, of schijf problemen of kabel problemen.

[IceTeaGX]

Geen smart issues, geen cable errors. Wel een OCZ vertex 3, niet de meest betrouwbare reeksen, maar kom.

Het is caching en slog voor een VM testomgeving waar geen belangrijke data op staat.
Server hangt verder ook aan een UPS om toch de meest banale kans op problemen te voorkomen.
Op termijn zal dit nog vervangen worden door mirrored slog en striped l2arc, samen met backups voor de data, maar voorlopig ben ik mij bewust van de mogelijke gevaren en mag het zo blijven.

[ Voor 3% gewijzigd door IceTeaGX op 15-12-2014 18:59 ]

[Gonadan]

Dronkenfikkie hellup, het was jouw idee.

[FireDrunk]

Zoek even op post net mijn naam en het woord override er. Dan vind je het antwoord.

[FREAKJAM]

FireDrunk schreef op maandag 15 december 2014 @ 17:09:
Zoek even op post net mijn naam en het woord override er. Dan vind je het antwoord.

echo manual >/etc/init/zpool-import.override
>
> ^ That worked.
>
> But I'm not clear what it's doing?

This reverts behavior and causes import to happen later when mountall calls /sbin/zfs, which implicitly loads the zfs.ko driver, which does an automatic import.

Dat?

[FireDrunk]

Yup

[Gonadan]

Held!

[FireDrunk]

[Gonadan]

Wanneer komt er een blog 2.0?

[FREAKJAM]

Stond trouwens ook in een post van mij hier hoor

FREAKJAM in "Het grote ZFS topic"

[Gonadan]

Sterker nog, het stond zelfs op die specifieke thread van eerder, alleen vanwege onderstaande post heb ik juist steeds gecontroleerd of dat ding weg was. Omdat die kerel het werkend had gekregen.

code:

I did the hostid thing and ran a zpool export/zpool import and reran the updateinitramfs.

All is good now - removed the /etc/init/zfs.override and it boots cleanly :)

Maar ik had natuurlijk initieel dat ID probleem uberhaupt niet.

[Durandal]

Ik heb een 40GB Intel 320 SSD (die met die capacitors) goedkoop op de kop kunnen tikken en ben die nu aan het installeren als boot disk voor mijn ZFSonLinux servertje.
Na de boot en de swap (heb je die eigenlijk nog nodig met 8GB ram) partitie heb ik nog ong. 24GB over op de SSD dus denk ik er aan deze als cache voor ZFS te gebruiken.

Ik doe voornamelijk opslag (media/projecten en weinig DB spul) en schrijfsnelheid boeit me niet veel.
Is het slim om die 24GB in te zetten als l2ARC? Eerst een partitie maken neem ik aan? Welk type?
Hoe zit het me de levensduur van die SSD? Gaat die significant achteruit?

[Verwijderd]

Als je L2ARC gaat gebruiken dien je een groot percentage aan overprovisioning te gebruiken. Je 40GB SSD dien je als 20GB en max 32GB te beschouwen. Doe je dit niet, dan zal je write amplification ook flink stijgen en dat is flink zonde voor een moderne SSD die tot 1.02 factor write amplification kan behalen mits juist gebruikt.

Dus partitioneer 12GiB als extra partitie voor L2ARC en laat de rest leeg (unpartitioned). Dan heb je toch een leuke hoeveelheid L2ARC en verpest je je mooie SSD niet.

[FireDrunk]

Voordat je die 320 sloopt heb je nog wel wat te gaan hoor, dat zijn goede ssds!

[Verwijderd]

Dat kan toch behoorlijk snel gaan hoor met een hoge write amplification. Vooral omdat Intel lazy GC (foreground garbage collection) gebruikt en dus niet actief GC (background GC) zoals Samsung en veel anderen. Zolang je zorgt dat de SSD spare space heeft, blijft de write amplification heel laag. Maar deze kan juist wel enorm oplopen als je hem volledig gebruikt en dan ook nog enorm veel random writes zoals bij L2ARC. De grootte (40GB) zorgt er verder voor dat de SSD wel degelijk 'op' kan raken bij onjuist gebruik. Want L2ARC kan behoorlijk veel schrijven naar de SSD.

Met de default instellingen kun je tot 691 gigabyte per dag schrijven naar je SSD. In de praktijk natuurlijk veel minder omdat je niet altijd tegen de write limit aan zit. Maar met zo'n kleine SSD en hoge write amplification zou het toch hard kunnen gaan denk ik.

Bovendien; L2ARC is juist leuk voor metadata enzo. Als je dat zo instelt heb je ook niet zoveel ruimte nodig. Dus dan kun je het ook 'goed' doen zodat je SSD heel lang mee gaat en je daar gedurende 10+ jaar ook plezier van hebt.

[Tadream]

FireDrunk schreef op maandag 15 december 2014 @ 09:32:
Goed, die handleiding mag in de prullenbak... Duidelijk door iemand gemaakt die niet snapt hoe device descriptors werken onder Linux...

Nogmaals: Pools aanmaken op SDA, SDB etc devices IS NIET VERSTANDIG! Verre van zelfs! Het is ontzettend gevoelig voor fouten!

Ik kan je toch echt aanraden om je pool opnieuw te maken...

Heb dezelfde beginnersfout gemaakt ben ik bang van
Ook ergens de stappen gevolgd van een site en die gaven ook sda, sdb enz aan.
Nu staat er nog niet heel veel op (zo'n 300GB) en dat kan ik nog even opzij zetten (inmiddels gedaan).
Ik ga hem ook opnieuw opbouwen die pool, maar dan met de juiste benaming en meteen lz4 erop. Dan hoeft dat niet achteraf meer.
Het is even nu wat extra werk maar dan heb je het wel goed staan.

[funnyname]

Na wat onderzoek op internet heb ik meer vragen dan toen ik begon, dus die ga ik hier gewoon stellen.

SITUATIE
Windows 7 client, ik wil de lokale (data) schijf in het NAS opnemen, dus dan heb ik voor data opslag alleen het NAS als optie. Met data bedoel ik (film) media, (RAW) foto's, virtuele machines en losse bestanden (downloads, text, enz).

ZFS/OS
Volgens deze uitstekende vergelijking tabel (ik heb geen andere goede vergelijking gevonden), is de perfomance van ZoL 'matig'. Is dit nu nog steeds zo?
Is hier enige verklaring voor te geven, over het algemeen staat Linux niet bekend om zijn slechte performance. (dat moet dan wel de ZFS implementatie op linux zijn?) (het liefst zou ik voor een linux oplossing kiezen, dit is beken(der) voor mij en flexibeler volgens mij..)

RAID
In het algemeen, hoe zit het nu met performance en het gekozen RAID level?
Volgens deze uitgebreide performance test, is de performance volgorde van snel naar langzamer:
◾Raid0 (21) (42)
◾Raid5 (19) (40)
◾Raid6 (17) (38)
◾Raid5+0 (17) (38)
◾Raid7 (16) (33)
◾Raid6+0 (14) (34)
◾Raid7+0 (10) (30)
◾Raid1+0 (10) (20)
◾Raid1 (1.8)

Maar volgende deze site is de volgorde:
◾RAID-0 (fastest)
◾RAID-1
◾RAIDZ-1 (5)
◾RAIDZ-2 (6)
◾RAIDZ-3 (7 slowest)

Ik neem aan dat de tweede site niet klopt?

HDD/CONTROLLER
Verder wordt hier aangegeven dat 'standaard' onboard SATA controllers dramatisch presteren, vergeleken met toegepaste RAID controller(S) Is dit niet gewoon een driver issue geweest? (de performance die ze halen is wel erg laag)
Ook wordt er op deze site aangegeven altijd voor een NAS-type harde schijf te kiezen, (bv WD Red), omdat de ECO versies slechte SATA timings hebben. Is er een dergelijk verschil tussen de verschillende series schijven van WD?

SDD/CACHING
Aangezien ik het OS het liefst op een SDD zet (misschien in mirror met een flashdrive?), kan de rest van de SDD gebruikt worden voor caching.
Hoeveel zin heeft het om een SDD als L2ARC en ZIL te gebruiken en welke partitie groottes zijn aan te raden bij bv 16GB RAM? (volgens mij 1/2 x RAM voor ZiL) Volgens deze site heeft het behoorlijk veel zin, maar wel afhankelijk van het gebruik.

NETWERK
Volgens mij heeft LACP (link aggregation (NIC teaming)) alleen zin bij een 1-op-veel connectie, 1-op-1 gaat het verkeer altijd over één van de twee NIC's, klopt dit? In mijn thuis situatie gaat het om een 1-op-1 situatie, is er een manier om de netwerk snelheid te verbeteren, zonder te investeren in peperdure 10Gb netwerk infra.?
(ik blijf het zo een verspilling vinden als je lokaal op je NAS hoge snelheden haalt, maar over het netwerk niet..)

Alvast bedankt voor de antwoord(en).

[ Voor 0% gewijzigd door funnyname op 16-12-2014 10:01 . Reden: typo ]

[justice strike]

funnyname schreef op dinsdag 16 december 2014 @ 09:48:
Na wat onderzoek op internet heb ik meer vragen dan toen ik begon, dus die ga ik hier gewoon stellen.

SITUATIE
Windows 7 client, ik wil de lokale (data) schijf in het NAS opnemen, dus dan heb ik voor data opslag alleen het NAS als optie. Met data bedoel ik (film) media, (RAW) foto's, virtuele machines en losse bestanden (downloads, text, enz).

ik weet niet precies wat je bedoelt met 'lokale data schijf in het nas opnemen' maar zfs werkt niet onder windows tenzij je een aparte server hebt draaien die filesharing of iscsi aanbied aan je windows client.

ZFS/OS
Volgens deze uitstekende vergelijking tabel (ik heb geen andere goede vergelijking gevonden), is de perfomance van ZoL 'matig'. Is dit nu nog steeds zo?
Is hier enige verklaring voor te geven, over het algemeen staat Linux niet bekend om zijn slechte performance. (dat moet dan wel de ZFS implementatie op linux zijn?) (het liefst zou ik voor een linux oplossing kiezen, dit is beken(der) voor mij en flexibeler volgens mij..)

ben je bekend met linux? anders zou ik een all in oplossing kiezen zoals zfsguru of freenas

RAID
In het algemeen, hoe zit het nu met performance en het gekozen RAID level?
Volgens deze uitgebreide performance test, is de performance volgorde van snel naar langzamer:
◾Raid0 (21) (42)
◾Raid5 (19) (40)
◾Raid6 (17) (38)
◾Raid5+0 (17) (38)
◾Raid7 (16) (33)
◾Raid6+0 (14) (34)
◾Raid7+0 (10) (30)
◾Raid1+0 (10) (20)
◾Raid1 (1.8)

Maar volgende deze site is de volgorde:
◾RAID-0 (fastest)
◾RAID-1
◾RAIDZ-1 (5)
◾RAIDZ-2 (6)
◾RAIDZ-3 (7 slowest)
Ik neem aan dat de tweede site niet klopt?

beide zou kunnen. ligt aan de specifieke configuratie en de aantallen schijven. raid 5 op 3 schijven werkt goed, op 4 schijven niet zo erg. Raid 6 op 4 schijven is weer sneller dan raid 5 op 4 schijven.

HDD/CONTROLLER
Verder wordt hier aangegeven dat 'standaard' onboard SATA controllers dramatisch presteren, vergeleken met toegepaste RAID controller(S) Is dit niet gewoon een driver issue geweest? (de performance die ze halen is wel erg laag)
Ook wordt er op deze site aangegeven altijd voor een NAS-type harde schijf te kiezen, (bv WD Red), omdat de ECO versies slechte SATA timings hebben. Is er een dergelijk verschil tussen de verschillende series schijven van WD?

vuistregel is een plain as vanilla controller te gebruiken zonder raid oid. Voor schijven, gewoon de schijf kopen die je normaal zou halen. Leuke van zfs is dat het zelf alles afhandeld kwa foutmeldingen.

SDD/CACHING
Aangezien ik het OS het liefst op een SDD zet (misschien in mirror met een flashdrive?), kan de rest van de SDD gebruikt worden voor caching.
Hoeveel zin heeft het om een SDD als L2ARC en ZIL te gebruiken en welke partitie groottes zijn aan te raden bij bv 16GB RAM? (volgens mij 1/2 x RAM voor ZiL) Volgens deze site heeft het behoorlijk veel zin, maar wel afhankelijk van het gebruik.

kan, maar de vraag is, heb je er veel profijt van als je je netwerk lijntje al leeg kan trekken.

NETWERK
Volgens mij heeft LAPC (link aggregation (NIC teaming)) alleen zin bij een 1-op-veel connectie, 1-op-1 gaat het verkeer altijd over één van de twee NIC's, klopt dit? In mijn thuis situatie gaat het om een 1-op-1 situatie, is er een manier om de netwerk snelheid te verbeteren, zonder te investeren in peperdure 10Gb netwerk infra.?
(ik blijf het zo een verspilling vinden als je lokaal op je NAS hoge snelheden haalt, maar over het netwerk niet..)

Alvast bedankt voor de antwoord(en).

kan 2 op 2 of 3 op 3. moet je wel behoorlijk wat configureren en je beide machines moeten natuurlijk 2 of 3 nics hebben.

[funnyname]

Die lokale data schijf wil ik uit de win7 machine halen en samen met 2 andere schijven in het NAS in een RAIDZ oplossing plaatsen.

Zoals gezegd ben ik enigzins bekend met Linux, maar in ieder geval meer dan met FreeBSD..

Ja ik plan dan 2 NIC's per machine en een switch die LACP ondersteund in te zetten, maar heeft dat voor de performance ook echt zin?

[ Voor 46% gewijzigd door funnyname op 16-12-2014 10:19 . Reden: typo + extra info ]

[Gonadan]

Heb al wel een nadeel ondervonden van een array vs losse disks. Een grote hoeveelheid data kopieren is ontzettend veel trager.

Als hij weer even rustig is maar eens proberen te benchmarken of hij normale waarden behaalt.

[Q]

funnyname schreef op dinsdag 16 december 2014 @ 09:48:

ZFS/OS
Volgens deze uitstekende vergelijking tabel (ik heb geen andere goede vergelijking gevonden), is de perfomance van ZoL 'matig'. Is dit nu nog steeds zo?
Is hier enige verklaring voor te geven, over het algemeen staat Linux niet bekend om zijn slechte performance. (dat moet dan wel de ZFS implementatie op linux zijn?) (het liefst zou ik voor een linux oplossing kiezen, dit is beken(der) voor mij en flexibeler volgens mij..)

Mijn NASje doet met ZoL 2.5 GB/s lezen en 1.9 GB/s schrijven. Is dat matig? Random I/O is een ander verhaal, maar zo belangrijk lijkt me dat niet voor jouw situatie.

[IceTeaGX]

Bij LACP is de link tussen 2 toestellen steeds beperkt tot 1 kanaal. De meeste standaard link aggregation systemen werken zo. Er zijn blijkbaar round robin implementaties, maar dat komt neet op hobbywerk.

RAIDz1/2 is een andere implementatie dan RAID5/6. Hierdoor zijn waarschijnlijk beide sites juist.

Maak een backup van het OS op een USB stick, maar geen mirror.
De ZIL kan nooit het volledige RAM bedragen, hoe meer RAM hoe groter het percentage. Zet het gelijk aan het RAM en je hebt wat headroom.
Voor de L2ARC laat je liefst de nodige vrije ruimte over om je SSD niet te veel te belasten. Verder is het nut hiervan inderdaad afhankelijk van de workload. Meer is altijd leuker, maar of het nodig is, is veel gezegd.

[funnyname]

Dat zijn nette waarden, ik neem aan dat dit lokaal is, wat voor snelheden aal je over het netwerk?

[funnyname]

IceTeaGX schreef op dinsdag 16 december 2014 @ 10:29:
Bij LACP is de link tussen 2 toestellen steeds beperkt tot 1 kanaal. De meeste standaard link aggregation systemen werken zo. Er zijn blijkbaar round robin implementaties, maar dat komt neet op hobbywerk.

RAIDz1/2 is een andere implementatie dan RAID5/6. Hierdoor zijn waarschijnlijk beide sites juist.

Maak een backup van het OS op een USB stick, maar geen mirror.
De ZIL kan nooit het volledige RAM bedragen, hoe meer RAM hoe groter het percentage. Zet het gelijk aan het RAM en je hebt wat headroom.
Voor de L2ARC laat je liefst de nodige vrije ruimte over om je SSD niet te veel te belasten. Verder is het nut hiervan inderdaad afhankelijk van de workload. Meer is altijd leuker, maar of het nodig is, is veel gezegd.

OK, dus LACP biedt geen load balancing?
Ik vind een hoby oplossing niet erg, als het maar uitvoerbaar is..

Beide sites gingen uit van ZFS, alleen de gebruikte terminologie is wat anders. Formeel is RAIDZ niet hetzelfde als RAID5, maar het is natuurlijk op veel punten vergelijkbaar.

Waarom geen mirror voor je OS. (kan natuurlijk ook MDraid zijn, of iets dergelijks van FreeBSD)

Maakt het nou nog uit hoeveel RAM je hebt t.o.v. de grootte van de L2ARC cache? Ik meen ergens gelezen te hebben dat de L2ARCH geheugen gebruikt om aangestuurd te worden en dat dit ten koste gaat van de snelle ARC cache?

[Verwijderd]

funnyname schreef op dinsdag 16 december 2014 @ 09:48:
ZFS/OS
Volgens deze uitstekende vergelijking tabel (ik heb geen andere goede vergelijking gevonden), is de perfomance van ZoL 'matig'. Is dit nu nog steeds zo?

Dat is een tabel van FireDrunk en de gegevens ervan komen ook van hem vandaan. Ik meen me te herinneren dat hij destijds wat testjes had gedaan op verschillende platforms en tot die conclusie kwam. Maar het is heel waarschijnlijk dat die tabel er nu heel anders uit zou moeten zien als je opnieuw zou testen. ZoL heeft namelijk niet stil gezeten en zeker goede vorderingen gemaakt.

Om voor platform X of Y te kiezen vanwege performance lijkt mij dan ook vreemd. Je zou beter kunnen selecteren op stabiliteit en features. BSD heeft de beste ZFS implementatie, Linux de slechtste. Maar het verschil wordt wel steeds kleiner. Een tijd geleden werd Linux min of meer 'production ready' verklaard. Ik vind dat nog heel prematuur. Denk maar even aan de bug bij Ubuntu update waardoor opeens je pool niet wilt importeren, of het gebrek aan goede I/O framework wat FreeBSD wel heeft dankzij GEOM. BSD kan gewoon 'proeven' of een disk bij ZFS hoort terwijl Linux dat ouderwets in een file heeft staan. Veranderen je nodes dan krijg je gelijk een 'corrupte' pool omdat ZFS data krijgt te zien die niet kloppen met wat het verwacht te zien. Dit soort verschillen zijn duidelijk te relateren aan de implementatie en niet aan ZFS zelf.

RAID
In het algemeen, hoe zit het nu met performance en het gekozen RAID level?
Volgens deze uitgebreide performance test, is de performance volgorde van snel naar langzamer:

Is natuurlijk onzin; want een RAID0 van RAID5s is sneller dan een enkele RAID5. Wat er bedoeld wordt zijn setjes van RAID5s met veel disks versus één grote RAID5 van veel disks. Dat laatste is natuurlijk totaal niet 'viable'. Sowieso is legacy RAID niet meer erg viable. Zie ook de artikelen 'Why RAID5 stops working in 2009' wat alles met uBER te maken heeft. Daarom wil je ook ZFS.

HDD/CONTROLLER
Verder wordt hier aangegeven dat 'standaard' onboard SATA controllers dramatisch presteren

Bullshit. De chipset SATA zijn de best mogelijke SATA poorten die je kunt krijgen. Een SAS controller is bijna per definitie minder goed dan de chipset poorten. Addon SATA controllers zijn veelal wel inferieur.

Ook wordt er op deze site aangegeven altijd voor een NAS-type harde schijf te kiezen, (bv WD Red), omdat de ECO versies slechte SATA timings hebben.

Slechte SATA timings? Klinkt ook gewoon als bullshit. ZFS is ook specifiek gemaakt voor goedkope hardware en heeft specifiek geen TLER nodig, en om bepaalde redenen wil je dat ook niet. Dus juist geen NAS schijf kiezen kan een goed advies zijn.

SDD/CACHING
Aangezien ik het OS het liefst op een SDD zet (misschien in mirror met een flashdrive?), kan de rest van de SDD gebruikt worden voor caching.
Hoeveel zin heeft het om een SDD als L2ARC en ZIL te gebruiken en welke partitie groottes zijn aan te raden bij bv 16GB RAM? (volgens mij 1/2 x RAM voor ZiL)

Dat laatste is ook bullshit. sLOG (ZIL heb je altijd) kun je 1GiB tot max 4GiB voor gebruiken. Dit is niet afhankelijk van je RAM grootte of van de pool capaciteit, maar van performance. Is je pool dubbel zo snel, dan heb je een dubbel zo grote sLOG disk nodig, grof gezegd. Hangt natuurlijk ook erg af hoe de verhouding sync/async writes is. 1GiB is veelal al overkill maar wat extra is vaak niet verkeerd.

NETWERK
Volgens mij heeft LACP (link aggregation (NIC teaming)) alleen zin bij een 1-op-veel connectie, 1-op-1 gaat het verkeer altijd over één van de twee NIC's, klopt dit?

Multipath Samba onder moderne Windows (weet even niet welke versie) zou er wel voordeel uit kunnen halen omdat het meerdere connecties gebruikt. Anders zou Round Robin wel point-to-point voordelen bieden voor een enkele TCP stream, maar dat kent ook nadelen, zoals dat niet veel switches het ondersteunen en Windows volgens mij helemaal niet.

Wil je sneller dan Gigabit, dan kun je beter wachten op Thunderbolt 3 met 20Gbps point-to-point ethernet interfaces. Dat gaat leuk worden als dat een realiteit wordt.

[FireDrunk]

Groot voordeel van een SAS controller is de diepere queue depth. Dat kan in bepaalde enterprise omgevingen erg belangrijk zijn.

Voor huis-tuin-en-keuken gebruik voldoen de onboard SATA poorten juist veel beter zoals CiPHER al zegt... Kosten per poort, en verbruik per poort is veel beter dan welke andere controller dan ook.

Ik moet inderdaad dat tabelletje eens updaten...

[Verwijderd]

Die queue kun je alleen gebruiken als je ook een SAS disk hebt, volgens mij. Want SATA gaat tot 32 queues. En het is niet alsof je bij een normale HDD daar voordeel bij hebt; want NCQ voor hardeschijven is alleen nuttig als je software een slechte job doet qua I/O reordering. Het is een bugfix/workaround/hack voor legacy filesystems die I/O domweg naar de disk duwen en zelf geen reordering toepassen. Bovendien geldt dit enkel voor random I/O zoals database applicaties. Ik heb voldoende benchmarks gezien waarbij software I/O reordering superieure performance geeft dan NCQ omdat de HDD controller een hogere latency heeft voor het reorderen dan de centrale CPU met megaperformance.

[funnyname]

Als ik het goed begrijp kan ik Adaptive load balancing (balance-alb) kiezen, dit wordt ondersteund door de Intel ANS teaming software onder Windows7 en als het goed is native onder de Linux bondig driver.

[Gonadan]

Verwijderd schreef op dinsdag 16 december 2014 @ 10:46:
Om voor platform X of Y te kiezen vanwege performance lijkt mij dan ook vreemd. Je zou beter kunnen selecteren op stabiliteit en features. BSD heeft de beste ZFS implementatie, Linux de slechtste. Maar het verschil wordt wel steeds kleiner. Een tijd geleden werd Linux min of meer 'production ready' verklaard. Ik vind dat nog heel prematuur. Denk maar even aan de bug bij Ubuntu update waardoor opeens je pool niet wilt importeren, of het gebrek aan goede I/O framework wat FreeBSD wel heeft dankzij GEOM. BSD kan gewoon 'proeven' of een disk bij ZFS hoort terwijl Linux dat ouderwets in een file heeft staan. Veranderen je nodes dan krijg je gelijk een 'corrupte' pool omdat ZFS data krijgt te zien die niet kloppen met wat het verwacht te zien. Dit soort verschillen zijn duidelijk te relateren aan de implementatie en niet aan ZFS zelf.

Waarbij ik wel wil aangeven dat je dat wellicht eerder moet toeschrijven aan Ubuntu dan ZoL. Een oude kennis van mij noemde het altijd 'debian testing', zo'n gevoel krijg ik er af en toe dan ook wel bij. Ze proberen rustig wat nieuws in hun distributies en als het dan niet lekker werkt of 'de community' muit teveel dan passen ze het rustig weer aan.

Zo heb ik ooit een Wacom tablet op Ubuntu gehad welke via xorg was geconfigureerd. In een volgende release waren ze over gestapt op HDI (niet helemaal zeker van exacte term) vanwege hotplug ofzo. Dat bleek toch niet te bevallen dus de volgende release was weer xorg. En de release daarna weer een andere methode omdat die dan wel goed zou zijn. Na vier keer opnieuw de resolutie en knoppen op andere wijze te moeten configureren ben ik dus van Ubuntu afgestapt als desktop OS. En het is dat het als server voor 99% lekker werkt, anders had ik daar waarschijnljk ook al op CentOS of iets anders over gestapt. Je server opnieuw inrollen is wel erg veel werk.

Lang verhaal kort, ik denk (mede door wat ik gelezen heb) dat ZoL al meer dan volwassen genoeg is om gewoon te gebruiken, maar dat je wel goed moet nadenken over welke linuxdistributie je dan wilt.

[FireDrunk]

@CiPHER,

Niet helemaal waar, het gaat vooral om driver queue's en in-controller queue's. Niet om applicatie queue's

Zoek maar eens op de problemen die er waren met VMware vSAN als het gaat om Queue Depth.
Dit komt omdat in het geval van ESXi er zo ontzettend veel IO is vanuit zo ontzettende veel VM's, dat er niet meer tegenop te schedulen valt.

Een queue van > 1024 is daar gewoon valide. Je kan wel heel mooi schedulen, maar je wil niet tegen een VM moeten hoeven zeggen:"Stop ff met IO, ik kan niet meer schedulen." Aan de andere kant wil je ook niet dat je maar een gigantische queue van > 10000 requests krijgt...

Daar moet een goede wisselwerking in zitten.

[funnyname]

Gonadan schreef op dinsdag 16 december 2014 @ 11:12:
[...]
Lang verhaal kort, ik denk (mede door wat ik gelezen heb) dat ZoL al meer dan volwassen genoeg is om gewoon te gebruiken, maar dat je wel goed moet nadenken over welke linuxdistributie je dan wilt.

ik zat te denken aan Ubuntu server of Debian, ik heb een klein beetje ervaring met Ubuntu desktop..
Wat is dan aan te raden?

[Verwijderd]

Al heeft de host een miljoen uitstaande queues; wat belet de software om dat te reorderen? Hoezo zou een low-power ARM-chipje dit beter kunnen? Zeer waarschijnlijk is de geoptimaliseerde firmware beter in staat dit te doen dan de huidige software van de host; maar dat is de praktijksituatie niet wat theoretisch mogelijk is. Precies dezelfde reden waarom Hardware RAID veelal sneller wat dan softwarematige implementaties vooral als het om RAID5 ging. De hardware kan echt niet dingen beter dan de software. Dat hele 'je moet een XOR-chip hebben' is pure onzin. Het is de geoptimaliseerde firmware die het beter doet dan de voor handen zijnde RAID5 drivers. De geom_raid5 driver bijvoorbeeld deed het beter dan mijn Areca hardware RAID controller 'back in the days'.

Dat gezegd, heb ik niet veel ervaring met systemen met dergelijke queues. Maar daar hebben thuisgebruikers die een ZFS NAS willen ook helemaal niets mee te maken.

[FireDrunk]

Je begrijpt me verkeerd, ik zeg niet dat een SAS controller dat beter kan, de queue is simpelweg gewoon dieper. Dat scheelt al. Hij hoeft het echt niet te reorderen. Dat *kan* wel, maar dat is vooral interresant voor HDD's, en veel minder voor SSD's, daar wil je gewoon een zo hoog mogelijke doorvoer.

Lees de blog van Duncan Epping maar eens over Queue Depths, dan zie je wat het probleem bij VMware is/was.

[Gonadan]

funnyname schreef op dinsdag 16 december 2014 @ 11:15:
ik zat te denken aan Ubuntu server of Debian, ik heb een klein beetje ervaring met Ubuntu desktop..
Wat is dan aan te raden?

Dat is heel erg persoonlijk. Hoeveel ervaring heb je met commandline linux?

Persoonlijk had ik ontzettend veel ervaring met Ubuntu in verschillende vormen voordat ik een server ging bouwen. Ervaring met andere varianten had ik alleen als incidentele gebruiker, daarom was de keuze snel gemaakt.

Elke distributie heeft zijn eigen nukken en voordelen. Ubuntu is vaak heel makkelijk, veel noobinformatie te vinden en uitgebreid. Maar anderen zijn wellicht behoudender en stabieler en houden vaker vast aan een gekozen koers.

Als je nu goed bekend bent met apt en de structuur van Ubuntu dan is dat wellicht het prettigst, het is wel gewoon een prima server OS. Debian zal niet heel veel verschillen maar hooguit wat volwassener zijn en wellicht weer wat minder standaard in de repo hebben aan noobtooling.
Anders is CentOS een optie, maar die werkt niet meer met apt (yum) en de structuur zal wat anders zijn. Zeker een goed en stabiel server OS.
Verder is natuurlijk iets als die BSD-variant zeer goed voor ZFS, echter is BSD wel significant anders van wat je gewend bent.
Let op: bovenstaand is niet gehinderd door persoonlijke blik.

Dus tja, als je nu nog niets hebt en je commandline ervaring is minimaal dan zou ik overwegen naar de BSD varianten te kijken. Heb je meer ervaring dan kan je alsnog Ubuntu of Debian nemen, maakt niet heel veel uit denk ik.
Als laatste, wat is je vaardigheid hierbij? Vogel je het snel uit met behulp van google of wil je toch wel graag dat het gewoon makkelijk werkt? Want in het tweede geval zou ik lekker bij Ubuntu blijven.

[funnyname]

Over het algemeen kom ik een heel eind met Google en de commandline. (ik heb in het verleden ook wel met BASH gerommeld)
Als het niet zo veel uitmaakt denk ik dat Ubuntu server een juiste keuze is voor mij, bedankt voor het advies.

[FireDrunk]

Ubuntu zit midden in een verandering van een aantal core componenten (SystemD onder andere), en daar komen nog wel eens wat bugjes uit naar voren...

Persoonlijk draai ik ook gewoon Ubuntu, maar als je bang bent om een keer je handen uit de mouwen te moeten steken bij een update, kun je beter naar een iets stabieler platform kijken (zoals CentOS of Debian).

[funnyname]

OK dan is misschien toch Debian de beste keuze. Ik dacht dat Ubu server ook behoorlijk stabiel was en niet zo progressief als Ubu desktop..

Volgens mij heb ik voldoende info gevonden om NIC teaming aan de praat te krijgen, je hebt niet eens een speciale switch nodig.. Hoewel, bij nader inzien is dit nog niet helemaal duidelijk...

[ Voor 8% gewijzigd door funnyname op 16-12-2014 11:52 . Reden: aanvulling ]

[FireDrunk]

Ubuntu server is conservatief in vergelijking met Desktop, maar nog lang niet zo conservatief als Debian.

Ubuntu server zit bijvoorbeeld op kernel 3.13 en Debian op 3.2...

[Gonadan]

Houdt dat dan niet in dat Debian minder conservatief is.

[FireDrunk]

3.2 is ouder dan 3.13... 11 versies om precies te zijn

[Gonadan]

D'oh!

3.13, niet 3.1.3

[FireDrunk]

[Gonadan]

Klopt onderstaand scenario of moet ik nog wat aan tuning gaan doen?

Ik doe tegelijkertijd:
• kopieren data van losse schijf naar ZFS array (10MB/s)
• kopieren data van gemount image op ZFS array naar map op ZFS array (max 10MB/s)

De snelheden zijn wel hoger geweest maar dat was tijdelijk. Geheugen is nog bijna een gig vrij.

[CurlyMo]

Als de keuze is CentOS of Debian, dan lijkt mij de keus duidelijk voor CentOS. Debian kan er echt net zo'n potje van maken als Ubuntu. Dat ondervinden we bij XBian aan den lijve

[FREAKJAM]

Ik heb zelf CentOS 7 draaien en ben er tevreden over. Het is wel anders, bijv yum ipv apt-get voor updates en CentOS 7 komt met systemd.

[CurlyMo]

En ook FreeBSD doet rare dingen. Zo wilde hij twee weken geleden opeens MySQL server verwijderen bij een upgrade Automatische upgrades vertrouw ik daar ook niet op.

[FireDrunk]

--pretend (oh wacht, dat is apt )

[FREAKJAM]

CurlyMo schreef op dinsdag 16 december 2014 @ 12:03:
En ook FreeBSD doet rare dingen. Zo wilde hij twee weken geleden opeens MySQL server verwijderen bij een upgrade Automatische upgrades vertrouw ik daar ook niet op.

Docker is wellicht dan ook interessant. MySQL draaien in een soort van bubbel op je VM. CentOS 7 komt standaard ook met docker. Docker-ZFS packages heb ik ook gezien, maar die waren vrij oud. Vraag me af of dat ooit gaat werken. Docker gaat in ieder geval groot worden.

[Gonadan]

funnyname schreef op dinsdag 16 december 2014 @ 11:36:
OK dan is misschien toch Debian de beste keuze. Ik dacht dat Ubu server ook behoorlijk stabiel was en niet zo progressief als Ubu desktop..

Zoals je al kunt lezen na een paar posts, elke distributie heeft zijn eigen nukken. Het is een beetje als de discussies tussen bepaalde gadgetmerken, telefoonsoftwarefabrikanten, hardwareproducenten etc. Feit is dat alle genoemde distributies erg veel gebruikt hebben dus gewoon bestaansrecht hebben. Je zult je aan geen een een grote buil vallen.

Convervatief is niet gelijk aan stabiliteit. Ik draag Ubuntu server en dat is uitermate stabiel, die draait rustig jaren zonder problemen. Als je echter voor een distupgrade gaat kan je tegen de relatief hoge progressiviteit aanlopen. Die moet je niet even een uurtje voordat je weer film wilt gaan kijken doen, houd daarbij gewoon rekening dat er 'iets' mis kan gaan.

Bij de OS variant heb ik weinig dist-upgrades gehad die vlekkeloos gingen, bij de servervariant de meeste wel. Wel moet je er rekening mee houden dat sommige softwarefabrikanten gewoon te lui zijn hun spullen knap te bouwen. Zo heeft mijn backupsoftwarefabrikant bedacht dat je gewoon lekker de driver opnieuw moet knutselen met hun eigen tool na elke kernelupgrade, lui volk.

[funnyname]

Ja Linux blijft mooi spul, ik zal eens wat gaan testen met VM's, heb ik ook al met Freenas en Nas4Free gedaan. Upgrades in het algemeen en dist. upgrades blijven in mijn ogen een zwak punt van Linux, many moving parts..

[Gonadan]

Ach, het is maar waar je het mee vergelijkt. Ooit wel eens een Windows machine geprobeerd sequentieel per versie te upgraden van NT tot aan 2012? Ik vind het al prachtig dat het uberhaupt kan, dat ik dan voor Ubuntu heb gekozen en bovengemiddeld moet googelen neem ik op de koop toe.

[Durandal]

Verwijderd schreef op dinsdag 16 december 2014 @ 02:32:
Als je L2ARC gaat gebruiken dien je een groot percentage aan overprovisioning te gebruiken. Je 40GB SSD dien je als 20GB en max 32GB te beschouwen. Doe je dit niet, dan zal je write amplification ook flink stijgen en dat is flink zonde voor een moderne SSD die tot 1.02 factor write amplification kan behalen mits juist gebruikt.

Dus partitioneer 12GiB als extra partitie voor L2ARC en laat de rest leeg (unpartitioned). Dan heb je toch een leuke hoeveelheid L2ARC en verpest je je mooie SSD niet.

Bedankt

Is het ook een idee om er een 2GB ZIL partitie bij te zetten (hou ik 10GB vrij), en is mijn pool dan nog ok als mijn SSD de geest geeft?

[Verwijderd]

Ja je pool is dan nog ok, mits je minimaal versie 19 hebt. Je data kan wel corrupt zijn als je iSCSI images gebruikt; als je gewoon ZFS filesystems via Samba/NFS gebruikt geldt dit risico niet; hooguit dat je de laatste writes/mutaties kwijt bent.

[CurlyMo]

Als je zvol's gebruikt voor je iSCSI dan moet corruptie ook geen probleem meer vormen.

[Verwijderd]

Hoezo dat? Als je de sLOG gebruikt voor sync writes en dus de data asynchroon schrijft en flush requests niet eerbiedigt, zou de ZVOL zelf niet corrupt zijn maar het filesystem van de client op de ZVOL wel corrupt kunnen zijn. Daarom gebruik je een sLOG disk ipv gewoon sync=disabled te draaien. Of bedoelde je wat anders?

[FireDrunk]

Vanuit de kant van ZFS is er dan geen corruptie, maar Windows is bijvoorbeeld best lomp in het cachen van writes van applicaties. Hierdoor kan het zo zijn dat ZFS sync writes keurig honoreert, maar je Windows VM toch wat data mist...

Als je in Windows Write caching helemaal uit zet, is het wel veilig.

@CiPHER, iSCSI kent ook gewoon het SYNC / FLUSH commando

[ Voor 8% gewijzigd door FireDrunk op 16-12-2014 16:19 ]

[Verwijderd]

@CiPHER, iSCSI kent ook gewoon het SYNC / FLUSH commando

Maar dat heeft natuurlijk geen zin als je een sLOG gebruikt en dan de sLOG kwijt raakt. De data disks (de HDD pool) zullen gewoon async schrijven. Dat is de hele reden dat een sLOG performance voordeel heeft; omdat je de ZIL verhuist van de HDD pool naar een dedicated disk (daarom: separate log).

Ik zie niet het verschil tussen een file-based extend en een ZVOL als beide op een pool met sLOG staan en de sLOG raakt kwijt of verliest de recente writes zoals een onbeschermde SSD (Samsung e.d.).

[FireDrunk]

Oh die bedoel je, je kan writes kwijtraken als je je slog verliest, ja zeker... Ik begreep je verkeerd

[CurlyMo]

Wat ik bedoel te zeggen is dat je door middel van een zvol iSCSI corruptie kan voorkomen door bijv. netjes snapshots van je zvol te maken. Zo kan je in geval van corruptie je snapshot terugdraaien waardoor ook je iSCSI weer in oude staat is teruggekeerd.

[FireDrunk]

Mja, is dat erg nuttig ten opziche van NTFS? NTFS kan zelf ook gewoon een journal rollback doen, en weer een werkend filesystem maken.

De kans dat je hele filesystem echt aan gort is, is toch niet zo groot?

[Verwijderd]

Nee, ik bedoel dat je client filesystem (NTFS/Ext) op de iSCSI volume corrupt kan raken.

De sync writes van filesystems beschermen tegen inconsistency van het filesystem. Daarvoor is het wel nodig dat de sync writes worden eerbiedigd. Dit geldt even goed voor ZFS; daarom is ZFS ook corrupt te krijgen als je een hardware RAID controller gebruikt met write-back enabled; omdat hierbij de flush requests voor sync writes genegeerd worden.

Bij het gebruik van sLOG worden sync writes niet genegeerd, maar naar sLOG geschreven; dezelfde write gaat async naar de HDD pool. Zou je je sLOG verliezen dan heb je enkel de async writes naar je HDD pool en dat kan betekenen een corrupt client filesystem. ZFS is dan corruptievrij - ZFS heeft zelf geen ZIL nodig om te overleven. Maar de client data wel - zoals een NTFS/Ext filesystem op een iSCSI extend.

Wat je zegt over write buffer uitschakelen kan inderdaad; maar dan schrijf je tegen 1MB/s omdat voor elke write er een bevestiging moet zijn en de volgende write pas uitgevoerd wordt als de voorgaande is afgerond. Dan zit je met latency problemen op een hardeschijf; een SSD heeft er minder last van.

Solaris bijvoorbeeld schakelde automatisch write buffering uit als je ZFS met partities gebruikte; omdat de mogelijkheid bestond dat UFS ook werd gebruikt en alleen FreeBSD heeft UFS met soft-updates; een alternatieve vorm van journalling om tegen filesystem inconsistency te beschermen zonder de write buffer uit te schakelen.

[ Voor 27% gewijzigd door Verwijderd op 16-12-2014 16:42 ]

[CurlyMo]

Om dat te ondervangen kan je dus een zvol iSCSI maken met snapshots. Mocht je toch tegen corruptie aanlopen, dan zet je een snapshot terug.

[Verwijderd]

Klopt inderdaad, maar dan moet je de snapshot wel maken op een consistent punt. Het liefst als je iSCSI volume niet in gebruik/mounted is. Maak je de snapshot terwijl het filesystem in gebruik is, en daarna knalt je sLOG onderuit, dan weet ik niet precies wat er gebeurt...

[CurlyMo]

Laat ik het zo zeggen. Ik gebruik zvols voor mijn virtualbox images en daarbij heb ik nooit problemen ervaren bij het terugzetten van een snapshot.

[Verwijderd]

Al zou er corruptie zijn, merk je daar veelal niets van omdat de filesystem checks de corruptie veelal weer corrigeren. Maar in een ernstig geval kan er toch meer stuk gaan. En vooral omdat je bij legacy filesystems niet weet wat er 'stuk' is, vind ik dit niet zo'n fijn idee. Ik wil weten wanneer er iets mis gaat, met precies welke files. Daarom gebruik ik ZFS ook met NAS-protocollen en niet met SAN-protocollen zoals iSCSI en AoE.

[FireDrunk]

Er zijn wel technieken om dat dus te doen. VMware heeft daar zijn VAAI (VMware API for Array Integration) protocol voor, en andere tools maken eerst een VMware snapshot, en backuppen daarna de VMDK (die is als VMware Tools geinstalleerd was, altijd consistent, omdat het alle buffers geflushed worden).

Zo'n integratie is er ook al met Nexenta icm ZFS.. Die hebben die plugin geschreven... Best leuk speelgoed.

[ Voor 4% gewijzigd door FireDrunk op 16-12-2014 17:08 ]

[Gonadan]

Misschien een filesystemnoobvraag, maar kan het zijn dat de grootte van bestanden anders samengevat wordt op ZFS dan EXT4?

Als ik na het kopieren van een map met veel bestanden een du -hs doe op beiden verschilt de grootte.
Gooi ik echter een ls -al van beiden in de diff dan zijn de groottes per bestand identiek.

[Verwijderd]

du = disk usage, niet file size.

Wil je de grootte van het bestand weten, gebruik dan du -A (of onder linux --apparent-size ofzoiets). Zonder die flag doet du wat de naam zegt: de disk usage rapporteren. Dus met compressie en andere meuk aan betekent dat lagere grootte, zonder compressie kan het groter zijn dan de grootte van het bestand, vanwege overhead. Bijvoorbeeld een bestand van 2 byte zal 512B aangeven, omdat minimaal één sector wordt gebruikt voor opslag en dus is de disk usage ook 512B en niet 2B.

Kortom: disk usage != filesize

[Gonadan]

noob dus

thanks

[Madshark]

Moederbord van mijn thuisservertje heeft sindskort wat relatieproblemen met mijn Areca controller.
Intussen met een schuin oog aan het kijken naar ZFS, als mogelijk kandidaat voor een nieuwe raid setup met een wat eenvoudigere controller. Vooral de block data deduplication spreekt me heel erg aan.

Ik vroeg me alleen af of de regel van 1GB ram voor iedere TB nog steeds actueel is met de recentere versies van ZFS. (meeste info wat ik hiervoor kon vinden is alweer wat jaartjes oud).
Met 24x 4TB aan brutto diskcapaciteit is dat eigenlijk nog best kostbaar. Zou je met, 16GB (minus OS) hier ook mee uit de voeten kunnen ?

Qua performance zijn de eisen niet zo super hoog, zolang er genoeg IOP aanwezig is om met 24 concurrent usenet sessies iets te downloaden ( 280mbit ), gelijktijdig een 50GB archive te unparren/unrarren en ook een +/- 35mbit datastream zonder onderbrekingen van de diskpool te kunnen lezen (als in, een bluray iso kijken vanaf een mediaplayer in SMB of NFS).Dat is zo'n beetje de maximale belasting wat regelmatig voor kan komen.
CPU is een i7-3930k.

[FireDrunk]

Wil je echt voor je complete array deduplication aanzetten? Want dan heb je wel echt een monster machine nodig... Als voor een selectief filesystem van een paar honderd GB Dedup aan zet, kan je met een paar GB al prima toe.

Voorbeeldje: 127GB aan data kost je 300MB RAM.
http://www.oracle.com/tec...ze-zfs-dedup-1354231.html

Als je dat extrapoleert (kan niet zomaar, maar het geeft een indicatie), dan zou je 232GB geheugen nodig hebben...

[ Voor 38% gewijzigd door FireDrunk op 17-12-2014 08:56 ]

[CurlyMo]

Ik denk dat dat vooral ligt aan inderdaad je eisen. Mijn ARM offsite backup heeft ook deduplication en lz4 compressie aanstaan met maar 1GB aan geheugen voor 700GB aan data. Met een 3.5" HDD via USB 3.0 (aangesloten op USB 2.0) haalt dat max. 15 MB/s tijdens het scrubben. Normale doorvoersnelheid is 4MB/s.

[ Voor 5% gewijzigd door CurlyMo op 17-12-2014 08:59 ]

[FireDrunk]

Het kan (bijna) altijd, alleen zakt de snelheid gigantisch in op het moment dat de DDT(Tabel met Dedup informatie) van disk gelezen moet worden. In CurlyMo's systeem zou dat best eens zo kunnen zijn, maar 4MB/s vs 5MB/s zal het verschil niet maken.

Jij hebt het over 280Mbit/s downloaden, en parren, dan ga je dat wel merken... (200MB/s regulier, naar 10MB/s is niet uitzonderlijk)

Dit is ook een 'nadeel':

By using an 8K block size in the dedup target dataset instead of 128K, one could conceivably see up to a 10X better deduplication ratio.

Bij een 8k blocksize is je sequentiele performance een stukje lager, en haal je minder compressie, en heb je als je toch compressie aan zet, een hogere CPU load volgens mij.

[Wiebeltje]

Wiebeltje schreef op maandag 15 december 2014 @ 11:19:
Check! Dan ga ik die zpool versie toch maar laten denk ik. Ik ben nu heel tevreden over Ubuntu + ZOL maar ik hou de optie toch graag open om terug te kunnen naar FreeBSD...

Ik heb de export / import gedaan en opzich is het goed gaan alleen kloppen de labels niet helemaal. De labels zijn hdd1 en hdd2 alleen hij laat de cijfers dus weg blijkbaar :-/ . Als ik de partie tabel print via parted staat er wel gewoon hdd1 en hdd2.

config:

        NAME         STATE     READ WRITE CKSUM
        datapool     ONLINE       0     0     0
          mirror-0   ONLINE       0     0     0
            hdd      ONLINE       0     0     0
            hdd      ONLINE       0     0     0
        cache
          zfs-cache  ONLINE       0     0     0

# parted /dev/sdb print
Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      17.4kB  280kB   262kB
 2      283kB   3001GB  3001GB  zfs          hdd1

Om mezelf nog even te quote-en. Na een reboot is alles weer terug naar sdb, sdc.Heeft iemand een idee hoe ik de wijziging definitief kan maken ? In syslog / dmesg vind ik ook geen foutmelding of iets dergelijks en Google kan me ook niet helpen. Het maakt overigens niet uit of ik de import gedaan heb met by-id of by-partlabel. Na een reboot gaat ie altijd terug naar sda...

[FireDrunk]

FireDrunk schreef op dinsdag 09 december 2014 @ 11:17:
Is een bekend probleem, ik heb het zelf ook gehad, en al bij HyperBart moeten fixen.

De oplossing is:

code:

zpool export [poolnaam]
echo manual > /etc/init/zpool-import.override
zpool import -d /dev/disk/by-id/ [poolnaam]
reboot

Het kan zo zijn, dat applicaties als SabNZBd roet in het eten gooien omdat ze 1 keer eerder gestart zijn dan je pool gemount wordt, waardoor SabNZBd directories aanmaakt ipv wacht tot je ZFS pool actief wordt.

Dit zorgt er later weer voor dat ZFS de pool niet kan mounten om dat de directories niet leeg zijn. Even opletten dus.

Succes!

^^

[Wiebeltje]

Je bent een held! Nu is ie goed. Ik zal zo eens even die bug reporten m.b.t. het label wat fout gaat.

[ppl]

Verwijderd schreef op dinsdag 16 december 2014 @ 17:29:
Wil je de grootte van het bestand weten, gebruik dan du -A (of onder linux --apparent-size ofzoiets). Zonder die flag doet du wat de naam zegt: de disk usage rapporteren.

In Linux is het inderdaad --apparent-size. In BSD-wereld bestaat deze optie niet. Waarschijnlijk omdat je die apparent size ook al ziet wanneer je een ls -h doet. Ergo: check de man van du, er zitten vaak subtiele verschillen tussen de versies van diverse OS's.

Kortom: disk usage != filesize

Om iets duidelijker te zijn: de size die een file op een disk inneemt. Dat is dus wat anders dan de size die een file heeft.

[FREAKJAM]

Wiebeltje schreef op woensdag 17 december 2014 @ 13:37:
Je bent een held! Nu is ie goed. Ik zal zo eens even die bug reporten m.b.t. het label wat fout gaat.

Is geen bug. Is een change die is doorgevoerd voor ZFS 0.6.4 en systemd support.