NAS med FreeBSD/ZFS

Hej alla,

det här blir min första post här- jag läste först angående prestanda över SAMBA/NFS där jag verkar ha gjort allting rätt. Sen så såg jag det här uttalandet och var tvungen att registrera mig. Man kan nämligen "optimera" för 4k-diskar även efteråt väldigt lätt. Anta att du har en pool med 6 disk raidz2 ser ut så här:

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

	NAME        STATE     READ WRITE CKSUM
	pool1       ONLINE       0     0     0
	  raidz2-0  ONLINE       0     0     0
	    ada1    ONLINE       0     0     0
	    ada2    ONLINE       0     0     0
	    ada3    ONLINE       0     0     0
	    ada4    ONLINE       0     0     0
	    ada5    ONLINE       0     0     0
	    ada6    ONLINE       0     0     0

Om man kör zdb på den, ser det ut så här:

[root@main ~]# zdb pool1

Cached configuration:
        version: 28
        name: 'pool1'
        state: 0
        txg: 61133
        pool_guid: 14552470060135351457
        hostid: 416064828
        hostname: 'main.local'
        vdev_children: 1
        vdev_tree:
            type: 'root'
            id: 0
            guid: 14552470060135351457
            children[0]:
                type: 'raidz'
                id: 0
                guid: 17973397078630951462
                nparity: 2
                metaslab_array: 30
                metaslab_shift: 36
                ashift: 9
                asize: 8001599569920
                is_log: 0
                create_txg: 4
                children[0]:
                    type: 'disk'
                    id: 0
                    guid: 16364327500934050621
                    path: '/dev/ada1'
                    phys_path: '/dev/ada1'
                    whole_disk: 1
                    DTL: 883
                    create_txg: 4
                children[1]:
                    type: 'disk'
                    id: 1
                    guid: 10369477754760373505
                    path: '/dev/ada2'
                    phys_path: '/dev/ada2'
                    whole_disk: 1
                    DTL: 882
                    create_txg: 4
                children[2]:
                    type: 'disk'
                    id: 2
                    guid: 4226438707690289390
                    path: '/dev/ada3'
                    phys_path: '/dev/ada3'
                    whole_disk: 1
                    DTL: 881
                    create_txg: 4
                children[3]:
                    type: 'disk'
                    id: 3
                    guid: 6427312922042785305
                    path: '/dev/ada4'
                    phys_path: '/dev/ada4'
                    whole_disk: 1
                    DTL: 880
                    create_txg: 4
                children[4]:
                    type: 'disk'
                    id: 4
                    guid: 7309946089772210616
                    path: '/dev/ada5'
                    phys_path: '/dev/ada5'
                    whole_disk: 1
                    DTL: 879
                    create_txg: 4
                children[5]:
                    type: 'disk'
                    id: 5
                    guid: 9653730431203467366
                    path: '/dev/ada6'
                    phys_path: '/dev/ada6'
                    whole_disk: 1
                    DTL: 3949
                    create_txg: 4
                children[6]:
                    type: 'disk'
                    id: 6
                    guid: 6415590009208375457
                    path: '/dev/ada7'
                    phys_path: '/dev/ada7'
                    whole_disk: 1
                    DTL: 877
                    create_txg: 4

Sen vill man utöka den poolen med ytterligare 6 diskar raidz2, men den här gången är de 4k-diskar. Då gör man:

# gnop create -S 4096 /dev/ada7
# zpool add pool1 raidz2 ada7.nop ada{8,9,10,11,12}
# zpool export pool1
# gnop destroy /dev/ada7.nop
# zpool import pool1

Och då ser det ut som så här:

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

	NAME        STATE     READ WRITE CKSUM
	pool1       ONLINE       0     0     0
	  raidz2-0   ONLINE       0     0     0
	    ada1     ONLINE       0     0     0
	    ada2     ONLINE       0     0     0
	    ada3     ONLINE       0     0     0
	    ada4     ONLINE       0     0     0
	    ada5     ONLINE       0     0     0
	    ada6     ONLINE       0     0     0
	  raidz2-1   ONLINE       0     0     0
	    ada7     ONLINE       0     0     0
	    ada8     ONLINE       0     0     0
	    ada9     ONLINE       0     0     0
	    ada10    ONLINE       0     0     0
	    ada11    ONLINE       0     0     0
	    ada12    ONLINE       0     0     0

Och zdb:

Cached configuration:
        version: 28
        name: 'pool1'
        state: 0
        txg: 61133
        pool_guid: 14552470060135351457
        hostid: 416064828
        hostname: 'main.local'
        vdev_children: 1
        vdev_tree:
            type: 'root'
            id: 0
            guid: 14552470060135351457
            children[0]:
                type: 'raidz'
                id: 0
                guid: 17973397078630951462
                nparity: 2
                metaslab_array: 30
                metaslab_shift: 36
                ashift: 9
                asize: 8001599569920
                is_log: 0
                create_txg: 4
                children[0]:
                    type: 'disk'
                    id: 0
                    guid: 16364327500934050621
                    path: '/dev/ada1'
                    phys_path: '/dev/ada1'
                    whole_disk: 1
                    DTL: 883
                    create_txg: 4
                children[1]:
                    type: 'disk'
                    id: 1
                    guid: 10369477754760373505
                    path: '/dev/ada2'
                    phys_path: '/dev/ada2'
                    whole_disk: 1
                    DTL: 882
                    create_txg: 4
                children[2]:
                    type: 'disk'
                    id: 2
                    guid: 4226438707690289390
                    path: '/dev/ada3'
                    phys_path: '/dev/ada3'
                    whole_disk: 1
                    DTL: 881
                    create_txg: 4
                children[3]:
                    type: 'disk'
                    id: 3
                    guid: 6427312922042785305
                    path: '/dev/ada4'
                    phys_path: '/dev/ada4'
                    whole_disk: 1
                    DTL: 880
                    create_txg: 4
                children[4]:
                    type: 'disk'
                    id: 4
                    guid: 7309946089772210616
                    path: '/dev/ada5'
                    phys_path: '/dev/ada5'
                    whole_disk: 1
                    DTL: 879
                    create_txg: 4
                children[5]:
                    type: 'disk'
                    id: 5
                    guid: 9653730431203467366
                    path: '/dev/ada6'
                    phys_path: '/dev/ada6'
                    whole_disk: 1
                    DTL: 3949
                    create_txg: 4
            children[0]:
                type: 'raidz'
                id: 1
                guid: 17973397078630951462
                nparity: 2
                metaslab_array: 30
                metaslab_shift: 36
                ashift: 12
                asize: 8001599569920
                is_log: 0
                create_txg: 4
                children[0]:
                    type: 'disk'
                    id: 0
                    guid: 16364327500934050621
                    path: '/dev/ada7'
                    phys_path: '/dev/ada7'
                    whole_disk: 1
                    DTL: 883
                    create_txg: 4
                children[1]:
                    type: 'disk'
                    id: 1
                    guid: 10369477754760373505
                    path: '/dev/ada8'
                    phys_path: '/dev/ada8'
                    whole_disk: 1
                    DTL: 882
                    create_txg: 4
                children[2]:
                    type: 'disk'
                    id: 2
                    guid: 4226438707690289390
                    path: '/dev/ada9'
                    phys_path: '/dev/ada9'
                    whole_disk: 1
                    DTL: 881
                    create_txg: 4
                children[3]:
                    type: 'disk'
                    id: 3
                    guid: 6427312922042785305
                    path: '/dev/ada10'
                    phys_path: '/dev/ada10'
                    whole_disk: 1
                    DTL: 880
                    create_txg: 4
                children[4]:
                    type: 'disk'
                    id: 4
                    guid: 7309946089772210616
                    path: '/dev/ada11'
                    phys_path: '/dev/ada11'
                    whole_disk: 1
                    DTL: 879
                    create_txg: 4
                children[5]:
                    type: 'disk'
                    id: 5
                    guid: 9653730431203467366
                    path: '/dev/ada12'
                    phys_path: '/dev/ada12'
                    whole_disk: 1
                    DTL: 3949
                    create_txg: 4

Det man letar efter är värdet ashift som står som 9 på den första vdev:en, men står som 12 på den andra. Det är så att varje vdev kan ha egna egenskaper. Alltså kan man ha en grupp av vanliga diskar, och en annan grupp av 4k-diskar i samma pool, full prestanda. Däremot ska man låta bli att blanda vanliga diskar med 4k-diskar i samma vdev, då kommer prestandan att bli svårt lidande.

[root@main ~]# uname -a
FreeBSD main.local 8.2-STABLE FreeBSD 8.2-STABLE #1: Tue Aug  2 11:04:08 CEST 2011     root@main.local:/usr/obj/usr/src/sys/KERNEL-20110706-1  amd64

/Sebulon

scrub_in_progress()
{
  pool=$1

  if zpool status $pool | grep "scrub in progress" > /dev/null; then
    return 0
  else
    return 1
  fi
}

scrub_in_progress()
{
  pool=$1

  if zpool status tank | grep "scrub in progress" > /dev/null; then
    return 0
  else
    return 1
  fi
}

Jag kan tipsa om sysutils/zfs-snapshot-mgmt i ports. Jag prövade att få ovanstående script att funka men det blev som ett steg fram och två steg tillbaka. Med zfs-snapshot-mgmt har jag fem timmes-snaps, sju stycken dags-snaps och fyra stycken vecko-snaps. Så allt mitt data är uppbackat i en månad, grovt sett.

/usr/local/etc/zfs-snapshot-mgmt.conf:

# Automatic ZFS snapshot management configuration file
#
# This is a YAML file (see http://www.yaml.org)
# Use exactly 2 spaces for each indentation level
#
snapshot_prefix: auto-
filesystems:
  pool1/root:
    # Create snapshots recursively for all filesystems mounted under this one
    recursive: true
    # Create snapshots every 60 minutes, starting at midnight
    creation_rule:
      at_multiple: 60
      offset: 0
    preservation_rules:
      - { for_minutes:   300, at_multiple:    60, offset: 0 }
      - { for_minutes: 10080, at_multiple:  1440, offset: 0 }
      - { for_minutes: 40320, at_multiple: 10080, offset: 0 }

/etc/crontab:

# /etc/crontab - root's crontab for FreeBSD
#
# $FreeBSD: src/etc/crontab,v 1.33.2.1.4.1 2010/06/14 02:09:06 kensmith Exp $
#
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
#
#minute	hour	mday	month	wday	who	command
#
*/5	*	*	*	*	root	/usr/libexec/atrun
#
# Save some entropy so that /dev/random can re-seed on boot.
*/11	*	*	*	*	operator /usr/libexec/save-entropy
#
# Rotate log files every hour, if necessary.
0	*	*	*	*	root	newsyslog
#
# Perform daily/weekly/monthly maintenance.
1	3	*	*	*	root	periodic daily
15	4	*	*	6	root	periodic weekly
30	5	1	*	*	root	periodic monthly
#
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time.  See adjkerntz(8) for details.
1,31	0-5	*	*	*	root	adjkerntz -a
#
# Beginning of local jobs...
*/5	*	*	*	*	root	/usr/local/bin/zfs-snapshot-mgmt

Ifall att någon blir sugen att pröva.

/Sebulon

Alltså, jag blev lite skraj för det där scriptet, för jag har två pooler och om en av dem skrubbade så tyckte scriptet att den inte kunde ta snapshots på den andra poolen heller. Jag plockade då isär scriptet och testade funktionen, fick det att göra som det skulle; jag skrev en ny skrubbtest-funktion som jag sen förde tillbaka in i scriptet men det funkade ändå inte, så jag kunde helt enkelt inte lite på det. zfs-snapshot-mgmt vet jag iaf att det funkar.

Vad är "baserat"? Menar du inkrementet- timmar, dagar, veckor, så är det samma som jag haft i något år ungefär.

/Sebulon

Hejsan jag har en fråga, om man arbetar direkt med filerna via smb/nfs läggs inte filerna i ramminnet på filserver?, om det är så , finns det inte risk för korruption under tiden som dom ligger där om man inte har ecc minnen ?

Jag försöker få ihop en liten låda till backup server ,, och det verkar som den inte stödjer ecc,, så hur stor är risken för att korruption kan uppstå och hur kan man minska den risken, jag vet att zfs som standard flashar till disk var 30 sekund ,, skulle risken minska om man sänkte den gränsen så att den flashar oftare till disk tillexempel?

Nu blev jag rädd,, :S

ZFS på Solaris flushar till disk var 30 sekund, ELLER om minnet är fyllt till 7/8. Då flushas allt till RAM. Men detta är inget problem egentligen. ZFS lagrar ju allt COW, dvs alla lagringar skrivs alltid på ett nytt ställe på disken - inget skrivs över. Allt gammalt finns kvar.

Antag att strömmen bryts mitt i en skrivning och zpoolen blir korrupt och du kan inte läsa zpoolen - då kan du alltid backa tillbaka till 30 sekunder tidigare då zpoolen faktiskt var i ett fungerande läge och man kunde läsa zpoolen. Så det värsta som kan hända, är att du förlorar de senaste 30 sekunderna av data. Men zpoolen kommer aldrig att korruptas om du drar strömmen mitt i. Men om du har lite RAM, så kommer RAM disken flusha när det är fyllt till 87.5% (dvs 7/8). Har du 1GB RAM, så flushar den till disk ofta. Nackdelen med att flusha ofta till disk, är att disken blir fragmenterad. Om du har mycket RAM, och kan cacha upp 10GB ändringar, så skrivs 10GB i ett svep och du slipper fragmentering. Men om du har 1GB så cachas 200MB (pga FreeBSD tar 800MB) så ökar fragmenteringen. ZFS har ingen defragmenterare.

En del Btrfs användare rapporterar att när de förlorat strömmen mitt i så har allting korruptat och de inte kan läsa sin btrfs raid längre.

Men återigen, allt det ovanstående gäller SOLARIS. Jag vet inte hur FreeBSD flushar till disk. Flusha till disk är ju inget som ZFS bestämmer, utan det är ju bestämt i OSet.

Ja nu har lådan som jag tittar på 2GB ram.

Det som du inte skriver Saddam som jag är orolig över,
är att den data som är i ramet kan blir korrupt och efter 30 sek eller 7/8 skrivas till poolen utan att zfs kommer att reagera, av den enkla anledningen att zfs inte gör någon kontroll av datat som skall skrivas till disk ,
vilket inte är konstigt egentligen.

Hur skall zfs kunna veta om dom ändringarna som är gjort är korrekta ändringar eller korruption, det ända sättet att skydda sig ifrån detta är antingen ecc minnen eller ha filsystemen i read-only så att ändringar inte skall skrivas till filsystemet.

ZFS har ingen aning om datat är korrekt eller inte. Du skickar ett gäng 1 och 0 till ZFS att lagra ned. Hur kan ZFS veta om en 1 är fel? Tänk om det är en mp3, och då är det korrekt bitsträng. Om det är en rar fil så kanske det inte ska vara en 1just där, utan det ska vara en 0:a. ZFS har ju ingen aning om det är mp3 eller rar eller exe fil eller whatever. Varje filändelse har ju regler vilka bitar som är korrekta. T.ex. MP3 säger att bit nr 1023 måste alltid vara 1. Men om det är rar, så kan biten vara vad som helst. ZFS har ingen aning.

Om man skickar en bitsträng ned till ZFS att spara ned, och dessutom talar om för ZFS att så här ska bitsträngen vara - så kan ZFS jämföra och se. Men... du ser att det är helt hopplöst. Tänk om även facit är fel? Mao, det är alltså inte ZFS ensak att kontrollera att datat som ska skrivas ned är korrekt. ZFS litar på att datat som ska skrivas ned är korrekt.

Om ZFS visste att bitsträngen som ska sparas ned är en gcc output och gcc output ser alltid ut som följer: "...." då kan ZFS kontrollera. Men då skulle ZFS bli bloatat: man måste tala om hur gcc output ser ut, rar output ser ut, exe filer, etc. Det finns inget filsystem som vet hur alla bitsträngar ska se ut. Binär rådata kan ju se ut hur som helst, hur ska ZFS veta om det är binär rådata eller en rar fil som har strikta regler hur det ska se ut? Det finns inget filsystem som gör det du efterfrågar.

Mao, det är ECC RAMs ensak att fixa detta. Om du är orolig för att du inte har ECC RAM - så förstår jag dig. I alla seriösa servrar har man ju ECC. Och det utav en anledning. Jag själv är lite orolig över att jag inte kör ECC. Men Intel Xeon är lite dyrt. Hittills har jag kört utan ECC och klarat mig. ZFS har aldrig klagat nån gång. Ta i trä.

Men som sagt, din oro har inget med ZFS att göra. Du får börja titta på ECC RAM om du vill slippa oron.

Det jag skrev var ingen kritik mot dig Saddam överhuvudtaget! Jag ville bara påtala fakta till alla andra som läser i denna tråd.

Men det är inte bara när du skriver ner ny data till filsystemet som zfs inte kan skydda, utan när du arbetar med data.

Säg att du skall redigera en bild som ligger på en zfs filsystem, så du öppnar bilden i ett program vilket gör att bilden kopieras från filsystemet till ramminnet. Du redigerar bilden efter ditt behag en under tiden du gör det så kommer en kosmisk strålning igenom ditt ramminne och gör att bilden du arbetar med får en pixel som blir svart , detta märker inte du och du sparar ändringarna du har gjort till bilden och efter 30 sek eller 7/8 är fyllt av ramminnet så skickas ändringarna till filsystemmet och zfs bara tackar och tar emot.

Jag skriver detta för jag tycker det är viktigt att man får reda på att zfs inte skyddar mot allt ,, zfs skyddar mot det som den skall skydda emot men om man inte vet vad det är så kan man lätt tro att zfs skyddar emot allt.

Jag vill också skriva att jag inte är negativ mot zfs, zfs är det bästa filsystem som jag känner till men jag tycker att det är viktigt att hålla en objektiv syn på zfs och berätta både för och nackdelar med zfs.
Nu är det är med ecc inte en nackdel mot zfs utan detta gäller väl egentligen alla filsystem. Men det blir känner jag mer påtagligt när man tittar på zfs.

Nu när jag skriver detta så testar jag mina raminnen på min stationära låda och har upptäckt att det är minst 100st errors i alla fyra modulerna , jag testade minnena med memtest86+ v 4.20

Mysticsam, helt rätt. ZFS kan bara garanterar att all data den fick, är korrekt nedskrivet. Om datat är fel från början, så vet inte ZFS det. Om du är orolig för hela kedjan, dvs från RAM ned till disk, så bör du köra ECC RAM. Jag själv är lite orolig för det och vill ha ECC RAM själv. Men jag kör ju intel, så jag vet inte riktigt hur jag ska göra. Kanske vore AMD bulldozer med ECC det bästa. Hmmm...

Jag tänkte på det du skrev:

Du kan ju inte vara säker på att din data är intakt. Av den anledningen att om du har arbetat med din data någon gång efter du har skrivit ner den så kan din data ha blivit korrupt utan att zfs kan upptäcka det.

Jag skall leta fram den forskningrapporten om zfs där fenomenet beskrivs på ett väldigt bra sätt. Dock har rapporten något år på nacken men den borde ändå vara ganska gångbar:

http://www.cs.wisc.edu/wind/Publications/zfs-corruption-fast1...

På sida 5-6 så förklarar dom hur dom sätter in data i ramminnet ändrar datat och sedan låter zfs spara ner det ändrade datat till disk utan att zfs reagerar.

Hela rapporten är väldigt intressant att läsa faktiskt och förklarar det som jag redan har skrivit här att zfs gör det den är designad till att göra.

Om det är någon som vet var man kan få tag i senare rapporter så skriv gärna ner länken så att man kan läsa dessa

Helt korrekt. Efter att datat skrivs ned så kan datat korruptas. Men, ZFS har något som heter "scrub" vilket innebär att ZFS går igenom varje bit och kontrollerar att allt är korrekt - om det inte är korrekt så korrigeras felen automatiskt och du får en rapport om det. scrub rekommenderas att köra 1 gång i månaden om du har Enterprise Server diskar och 1 gång i veckan om du har vanliga diskar. Men eftersom du kan köra scrub medan du använder filsystemet så är det ingen big deal att göra.

När ett vanligt filsystem fsck så sker inte detta, dvs själva datat kontrolleras inte. Metadatat och journalen kontrolleras endast. Men själva datat kan vara korrupt efter fsck. Dessutom, fsck kräver att du avmonterar filsystemet och tar det off-line. Under tiden fsck kontrollen sker, så kan man inte använda filsystemet.

Jag förstår inte varför du verkar se detta som en brist i ZFS? Om datat i RAM har ändrats - så är det RAMs sak att detektera och korrigera det. ZFS har ingen aning om vad CPUn eller RAM sysslar med och kan inte på något magiskt sätt veta det.

Antag att cpun räknar ut 25 + 34, men det råkar bli en strömspik så cpun räknar ut 25 + 24 istället. Hur ska då ZFS veta vad cpun egentligen skulle räkna ut? Det är cpuns sak att fixa sina fel och brister, så fixar ZFS sina fel och brister.

Det är ungefär som en lärare delar ut ett matteprov, men det har slunkit in ett fel. Istället för "24" så ska det stå "15". Vid rättningen säger läraren "ja, jag menade förstås 15, och ingen av er visste vad jag tänkte på. Så ni får underkänt". Hur i hela friden ska eleverna veta vad läraren tänkte på? Det är lärarens sak att ge eleverna rätt input så kommer eleverna göra det som de tränats till. Eleverna kan inte läsa tankarna eller veta vad läraren egentligen menade.

Det finns inget filsystem som korrigerar fel i RAM. Det är RAMs sak att göra. Och det sker lämpligtvis med ECC RAM eller nåt liknande. Det finns inte heller något filsystem som korrigerar en felaktig CPU. Hur skulle det gå till? För att korrigera felaktiga beräkningar, så måste man använda en annan cpu, för att kunna jämföra beräkningarna. Använder du samma cpu så blir det ju samma fel.

Om du hittar ett filsystem som korrigerar fel i RAM, och i CPUn och i grafikkortet och i tangentbordet även läser mina tankar, så säg till. Då byter jag filsystem ögonaböj.

Som jag har skrivit innan jag ser inte ner på ZFS (jag tror det är tredje gången jag skriver det) jag tar bara upp fakta om situationer som man skall tänka på. Varför jag tar upp detta är för att folk inte skall tro att det är zfs sak att åtgärda dessa saker utan att det ligger utanför zfs kontroll. Och så är det tänkt att vara också.

Som du skriver det finns inget filsystem som kan fixa fel bättre än zfs.

Som jag skrev innan så tycker jag att det är viktigt att uppmärksamma för jag är rädd att det är många som stirrar sig blind på hur bra zfs är och i ochmed det och tror att zfs skyddar din data i dessa situationer med vilket det inte gör och inte heller är designad att göra.

Jag kom och tänka på en sak angående ecc minnen,

Jag har under en tid kollat på olika lådor från hp och andra märken, och i specifikationerna har det stått att ecc ram kan åtgärda en-bits fel och upptäcka två-bits fel,(http://www.supermicro.com/products/system/4U/7046/SYS-7046A-T...)
Så gick jag in på wikipedia och kom in på denna sida (http://en.wikipedia.org/wiki/Cyclic_redundancy_check) där är det ett stycke som pratar om att kunna upptäcka dubbel och trippel-bits fel.

Är det någon som har detaljer på detta?

För jag trodde att det bara fanns enkel och dubbel-bits fel?