[Sammelthread] ZFS Stammtisch

[gea]

Ich bin am Grübeln.
Wir haben an unserer Hochschule OmniOS Filer und auch über 100 Macs. Jede OSX Version hat zwar ihre eigenen SMB Probleme aber das betrifft eher Performance als das beschriebene Verhalten.

Da alle Einstellungen (ACL, idmappings, aclmode, aclinherit, ZFS ro, nbmand etc) das Verhalten nicht begründen können und auch root Vollzugriff haben muss, nochmal im Detail

Gehe zu > mit Server verbinden, dann
smb:// 192.168.178.79 (smb2) oder cifs:// 192.168.178.79 (smb1) eingeben

Als user dann root mit Rootpasswort eingeben und ein share auswählen
Dann eine Datei anlegen = geht nicht?

 

[qoosinoo8]

Ich bin am Grübeln.
Wir haben an unserer Hochschule OmniOS Filer und auch über 100 Macs. Jede OSX Version hat zwar ihre eigenen SMB Probleme aber das betrifft eher Performance als das beschriebene Verhalten.

Da alle Einstellungen (ACL, idmappings, aclmode, aclinherit, ZFS ro, nbmand etc) das Verhalten nicht begründen können und auch root Vollzugriff haben muss, nochmal im Detail

Gehe zu > mit Server verbinden, dann
smb:// 192.168.178.79 (smb2) oder cifs:// 192.168.178.79 (smb1) eingeben

Als user dann root mit Rootpasswort eingeben und ein share auswählen
Dann eine Datei anlegen = geht nicht?

Hab es jetzt über Windows 10 gemacht über "Map network drive". Dann als User root + entsprechendes Password. Lege ich eine Datei an, kommt folgende Meldung: "You need permission to perform this action"

 

[dstockm]

Das ist genau die Kernfrage.
Wurde etwas auf die Platten geschrieben und ist der Pool deshalb korrupt oder ist etwas anderes Schuld.

Ich würde tatsächlich mal versuchen, OmniOS direkt auf eine Platte zu installieren (ohne ESXi) um zu sehen ob der Pool dann importiert werden kann.

Kleines Update:
Ich habe nun als ersten Versuch die "originale" napp-it-san024-jan2018.ova importiert. Und die (bereits im fehlerhaften Zustand) exportierten Pools ließen sich ohne Probleme importieren. Alles wieder da.
Ein erster Scrub über den SSD-Pool:
info: scrub repaired 0 in 0h8m with 0 errors on Sun Mar 31 09:56:40 2019

Bei meiner eigenen Installation ließen sie sich nicht importieren, weil auch der exportierte Pool als corrupted angezeigt wurde. Bei dieser "Neuinstalltion" wurden sie als völlig ok angezeigt.

Wo steckt nun der Fehler? Ich hatte meine VM bereits mit einer älteren Boot-Environment gebootet. Das brachte nichts.

Da bleibt doch eigentlich nur die Konfiguartion der VM im ESXi oder irgend eine Solaris-Hardware-Config-Sache die nicht Teil der BE ist?

Als nächstes versuche ich nun mal meine ova von vor der Image-Aktion. Das habe ich zufällig alles in der optimalen Reihenfolge gemacht...

weiteres Update:
Wozu so kompliziert. Die alte Installation läuft nun auch einfach wieder. Das ist doch schon etwas seltsam, oder?

Update3:
So, die aktuellste BE (mit 19.01C) läuft nun auch wieder. Dort musste ich die Pools erst importieren, da ich sie in dieser BE exportiert hatte.

Damit dürften meine Probleme nun komplett gelöst sein. Nur die Ursache ist mir überhaupt nicht klar.
Das einzige was mir jetzt noch einfällt: Ich glaube ich hatte die USB-Platte und den Boot-Stick im laufenden Betrieb angestöpselt und erst dann die Napp-it-VM und ESXi heruntergefahren. Kann es daran liegen?

 

[gea]

Prinzipiell ist ZFS Software Raid extrem unkritisch im Fehlerfall, viel unkritischer als sonstige Raids. Sind nicht genug Platten für die gewählte Redundanz vorhanden, geht der Pool auf Offline. Kommen genügend Platten zurück geht er wieder auf Online oder degraded.

Das Betriebssystem speichert die ZFS Konfiguration (welche Platten dazugehören) aber nur um den schneller zu mounten. Ein zpool import liest immer alle Platten und kann daher auch einen völlig fremden/unbekannten Pool importieren.

Wenn beim Einstecken neuer Platten (USB oder andere) Platten auf degraded oder offline gehen so kann das nur daran liegen, dass die neue Platte etwas blockiert.

 

[dstockm]

Prinzipiell ist ZFS Software Raid extrem unkritisch im Fehlerfall, viel unkritischer als sonstige Raids. Sind nicht genug Platten für die gewählte Redundanz vorhanden, geht der Pool auf Offline. Kommen genügend Platten zurück geht er wieder auf Online oder degraded.

Das Betriebssystem speichert die ZFS Konfiguration (welche Platten dazugehören) aber nur um den schneller zu mounten. Ein zpool import liest immer alle Platten und kann daher auch einen völlig fremden/unbekannten Pool importieren.

Wenn beim Einstecken neuer Platten (USB oder andere) Platten auf degraded oder offline gehen so kann das nur daran liegen, dass die neue Platte etwas blockiert.

Ich könnte versuchen das nochmal nachzustellen, aber mein Bedarf an Experimenten ist fürs Erste gedeckt.
Ich frage mich ob es in diesem Falle besser gewesen wäre den Pool nicht zu exportieren, sondern die Platten abzustöpseln, den Pool zu löschen, Platten wieder dran und dann Import. Meine Installation hat sich das Problem ja irgendwie über den Export hinweg gemerkt und konnte deshalb nicht wieder importieren.

eine abschließende Frage noch:
Das USB-Backup (zusätzlich zum Backupserver) erstelle ich derzeit simpel über Windows.
Alternative wäre also die USB-Platten direkt an den Server zu stecken. Kann man mehrere externe Laufwerke zu einem Pool zusammenfassen und ist das sinnvoll? Eines meiner Dateisysteme ist nämlich zu groß für eine einzelne externe Platte.
Vorteil meiner jetzigen Lösung ist natürlich, dass ich ohne Weiteres an die Daten komme. Nachteil ist, dass es lange dauert (1 GBit-Netzwerk) und ich per Hand die Daten aufteilen muss. Und das führt zu sehr seltenen Backup-Zyklen. Und das hat mir die letzten Tage doch ein paar Sorgen gemacht (war fast 12 Monate her).

 

[gea]

Pool Export + Pool Import
Pool an anderem Rechner einfach anstecken und Pool Import
Pool Destroy und dann direkt wieder Pool Import

Macht genau das gleiche. Das klappt wenn die Platten da sind oder eben nicht wenn Platten fehlen.
Ein ZFS Pool kann aus allem gebildet werden was nach Platte riecht (Blockdevice), also Platten, Dateien, iSCSI, FC etc

Also auch USB Pool oder aber eSata/Sata (mit aktiviertem Hotplug) oder Sata Platten an SAS Controller + hotplug fähiger Backplane. Letzteres wäre die beste Lösung zusammen mit incrementellem zfs send (Replikation) und damit ZFS Snaps/ Versionierung.

 

[Sir Diablo]

Mir bereiten diese Ergebnisse etwas Bauchschmerzen, hat da jemand eine Idee warum die randomwrite Werte so unglaublich unterirdisch sind?

centos 7.6 ZFS v0.6.5.11-1 10GB RAM block device
  4k.read:      IOPS=2705k, BW=10.3GiB/s (11.1GB/s)(160GiB/15504msec)
  4k.write:     IOPS=2114k, BW=8256MiB/s (8657MB/s)(160GiB/19845msec)
  4k.randread:  IOPS=2691k, BW=10.3GiB/s (11.0GB/s)(160GiB/15589msec)
  4k.randwrite: IOPS=2054k, BW=8024MiB/s (8414MB/s)(157GiB/20002msec)
  4k.70%read:   IOPS=1545k, BW=6035MiB/s (6328MB/s)(112GiB/19004msec)
  4k.30%write:  IOPS=662k, BW=2586MiB/s (2712MB/s)(47.0GiB/19004msec)
centos 7.6 ZFS v0.6.5.11-1 zvol on 10GB RAM block device
  4k.read:      IOPS=289k, BW=1130MiB/s (1185MB/s)(22.1GiB/20002msec)
  4k.write:     IOPS=145k, BW=565MiB/s (593MB/s)(11.0GiB/20001msec)
  4k.randread:  IOPS=295k, BW=1153MiB/s (1209MB/s)(22.5GiB/20002msec)
  4k.randwrite: IOPS=32.3k, BW=126MiB/s (132MB/s)(2523MiB/20020msec)
  4k.70%read:   IOPS=52.5k, BW=205MiB/s (215MB/s)(4102MiB/20002msec)
  4k.30%write:  IOPS=22.5k, BW=87.9MiB/s (92.2MB/s)(1759MiB/20002msec)
Ubuntu 18.04 ZFS v0.7.5-1ubuntu16.4 10GB ram block device
  4k.read:      IOPS=3653k, BW=13.9GiB/s (14.0GB/s)(160GiB/11482msec)
  4k.write:     IOPS=2730k, BW=10.4GiB/s (11.2GB/s)(160GiB/15365msec)
  4k.randread:  IOPS=3335k, BW=12.7GiB/s (13.7GB/s)(160GiB/12578msec)
  4k.randwrite: IOPS=2535k, BW=9902MiB/s (10.4GB/s)(160GiB/16546msec)
  4k.70%read:   IOPS=2105k, BW=8221MiB/s (8620MB/s)(112GiB/13953msec)
  4k.30%write:  IOPS=902k, BW=3522MiB/s (3693MB/s)(47.0GiB/13953msec)
Ubuntu 18.04 ZFS v0.7.5-1ubuntu16.4 zvol on 10GB ram block device
  4k.read:      IOPS=213k, BW=833MiB/s (873MB/s)(16.3GiB/20003msec)
  4k.write:     IOPS=173k, BW=677MiB/s (710MB/s)(13.2GiB/20002msec)
  4k.randread:  IOPS=149k, BW=580MiB/s (609MB/s)(11.3GiB/20003msec)
  4k.randwrite: IOPS=26.2k, BW=102MiB/s (107MB/s)(2051MiB/20069msec)
  4k.70%read:   IOPS=35.3k, BW=138MiB/s (145MB/s)(2759MiB/20008msec)
  4k.30%write:  IOPS=15.2k, BW=59.2MiB/s (62.1MB/s)(1185MiB/20008msec)
solaris 11.3 8G RAM block device
  4k.read:      io=752176KB, bw=4055.7MB/s, iops=1038.3K, runt= 20380msec
  4k.write:     io=469448KB, bw=2240.3MB/s, iops=573495 , runt= 20317msec
  4k.randread:  io=2855.4MB, bw=3188.4MB/s, iops=816206 , runt= 20166msec
  4k.randwrite: io=4051.5MB, bw=1996.8MB/s, iops=511168 , runt= 20491msec
  4k.70%read:   io=4008.6MB, bw=1831.6MB/s, iops=468863 , runt= 20080msec
  4k.30%write:  io=3474.4MB, bw=803819KB/s, iops=200954 , runt= 20080msec
solaris 11.3 zvol on 8G RAM block device
  4k.read:      io=3364.2MB, bw=3848.9MB/s, iops=985301 , runt= 20030msec
  4k.write:     io=1627.2MB, bw=502717KB/s, iops=125679 , runt= 20001msec
  4k.randread:  io=3773.4MB, bw=2645.8MB/s, iops=677308 , runt= 20004msec
  4k.randwrite: io=2176.6MB, bw=111147KB/s, iops=27786 , runt= 20052msec
  4k.70%read:   io=3159.5MB, bw=161229KB/s, iops=40307 , runt= 20066msec
  4k.30%write:  io=1354.9MB, bw=69140KB/s, iops=17284 , runt= 20066msec
proxmox kernel 4.15.18-9 | zfs 0.7.12-1    10GB ramdisk
  4k.read:      io=163840MB, bw=15796MB/s, iops=4043.9K, runt= 10372msec
  4k.write:     io=163840MB, bw=12245MB/s, iops=3134.8K, runt= 13380msec
  4k.randread:  io=163840MB, bw=14387MB/s, iops=3683.9K, runt= 11388msec
  4k.randwrite: io=163840MB, bw=9229.1MB/s, iops=2362.9K, runt= 17751msec
  4k.70%read:   io=114704MB, bw=8526.1MB/s, iops=2182.9K, runt= 13452msec
  4k.30%write:  io=49136MB, bw=3652.7MB/s, iops=935084, runt= 13452msec
proxmox kernel 4.15.18-9 | zfs 0.7.12-1    10GB ramdisk zvol
  4k.read:      io=29757MB, bw=1487.8MB/s, iops=380854, runt= 20002msec
  4k.write:     io=16633MB, bw=851565KB/s, iops=212891, runt= 20001msec
  4k.randread:  io=20155MB, bw=1007.7MB/s, iops=257962, runt= 20002msec
  4k.randwrite: io=2770.5MB, bw=141650KB/s, iops=35412, runt= 20028msec
  4k.70%read:   io=3539.2MB, bw=181123KB/s, iops=45280, runt= 20009msec
  4k.30%write:  io=1517.8MB, bw=77672KB/s, iops=19417, runt= 20009msec

Getestet mit folgendem "Tool":

dofio () {
    local FIO="fio --name=test --direct=1 --refill_buffers --norandommap --randrepeat=0 --ioengine=libaio --iodepth=16 --numjobs=16 --runtime=20 --group_reporting --bs=4k"
    local FILE=$1
    shift
    ($FIO $* --filename=${FILE} --rw=read                   |sed 's/ read:/4k.read:     /';
     $FIO $* --filename=${FILE} --rw=write                  |sed 's/write:/4k.write:    /';
     $FIO $* --filename=${FILE} --rw=randread               |sed 's/ read:/4k.randread: /';
     $FIO $* --filename=${FILE} --rw=randwrite              |sed 's/write:/4k.randwrite:/';
     $FIO $* --filename=${FILE} --rw=randrw --rwmixread=70  |sed 's/ read:/4k.70%read:  /' |
                                                             sed 's/write:/4k.30%write: /' ;
    )| grep -i "IOPS="
}
modprobe brd rd_nr=1 rd_size=$(( 10 * 1024 * 1024)) # 10GB RAM block device
dd if=/dev/zero of=/dev/ram0 bs=1M
dofio /dev/ram0
P=b
zpool create ${P} /dev/ram0
VOL=volb
SIZE=$(zfs get -H -p -o value available ${P})
BLOCKSIZE=32768
SIZE=$(( ${SIZE} * 80 / ( 100 * ${BLOCKSIZE} ) * ${BLOCKSIZE} ))
sudo zfs create -s -b ${BLOCKSIZE} -V ${SIZE} -s  ${P}/${VOL}
dofio /dev/zvol/${P}/${VOL}
zpool destroy ${P}
rmmod brd

 

[morph027]

ZFS on Linux 0.8 erhält TRIM-Unterstützung - Pro-Linux

 

[sch4kal]

ZFS on Linux 0.8 erhält TRIM-Unterstützung - Pro-Linux

Die viel interessantere News ist doch die Einführung von Dataset Encryption und Sequentielles Scrubbing wie im Oracle ZFS.

 

[morph027]

Jau, auch super. Ich bin gespannt, wann ich mal Zeit und Lust zum kompilieren und testen finde.

 

[fdiskc2000]

Moin zusammen, bin gerade ratlos.
Habe auf meinem ML310e neu ESXI 6.7u1 mit napp-it laufen
Habe keinen HBA genommen, sondern 2x 4tb WD RED per RDM durchgereicht.
ESXI erkennt die Platten als 4TB, in napp-it sieht es für mich auch danach aus. Aber wenn ich einen Pool anlege, wird der nur mit 2/1,8 TB angelegt. Und ich verstehe nicht warum.



Ich habe den pool schon x-mal neu angelegt, im-/exportiert. Ich finde den Fehler nicht.

Wenn ich das richtig sehe, meint das System ja auch, dass noch 1,8TB "pending" sind, also noch frei?
Warum wird dann immer nur eine Partition mit 50% angelegt?


Hat jemand eine Idee?

 

[asche77]

1. HBA nehmen. Damit funktioniert es. Warum dann mit RDM rumschlagen?
2. Mal mit der aktuellen OmniOS Version probiert (r28, nicht r18)?

 

[Sir Diablo]

@gea
Wie viel IOPS bekommst du denn maximal für 4k randwr und mit welchen Settings? Ich Google gerade etwas rum und find nur ähnlich schlechte Ergebnisse wie bei meinem Ramdisk Test. Und 35k auf ner Ramdisk,.... was soll man da sagen, ich hab hier Platten die raw 160k+ 4k randwr schaffen... Keine Lust auf mdadm, aber was bleibt denn übrig, mit solchen Werten?

 

[gea]

Habe keinen HBA genommen, sondern 2x 4tb WD RED per RDM durchgereicht.

Von diesem "Problem" habe ich schon mehrfach gehört.
RDM über Sata ist in ESXi jedoch "unsupported", kann gehen, kann halbwegs gehen, muss gar nicht gehen.

Einfach die paar Euro für einen LSI HBA oder OEM (Dell, HP) ausgeben, zur Not gebraucht.
Da geht dann RDM einzelner Platten problemlos, genau wie Pass-through des ganzen HBA und damit Zugriff auf den Controller über die OminiOS Treiber.

- - - Updated - - -

@gea
Wie viel IOPS bekommst du denn maximal für 4k randwr und mit welchen Settings? Ich Google gerade etwas rum und find nur ähnlich schlechte Ergebnisse wie bei meinem Ramdisk Test. Und 35k auf ner Ramdisk,.... was soll man da sagen, ich hab hier Platten die raw 160k+ 4k randwr schaffen... Keine Lust auf mdadm, aber was bleibt denn übrig, mit solchen Werten?

Die Frage ist nicht mdadm Raid vs ZFS Raid sondern z.B. ext4/ntfs/fat32 vs ZFS als CopyOnWrite Dateisystem.
Wenn man in ersterem Fall z.B. den Buchstaben A auf Platte schreibt (1 Byte), so erfolgt ein Schreibvorgang entweder mit 512B oder 4kB, je nach physikalischer Sektorgröße. Ein 4KB Schreibvorgang schreibt dann auch nur 4KB an Daten. Kein Problem also mit viel ops (Operation/s)

Ein Schreibvorgang auf ZFS schreibt immer einen kompletten ZFS Datenblock neu. Dessen Größe ist zwar dynamisch (z.B. per default 128k oder Teil davon), dennoch schreibt ZFS per io immer deutlich mehr Daten als z.B. ext4. Darüberhinaus müssen noch Prüfsummen erzeugt und mitgeschrieben werden. Es fällt also mehr Rechenaufwand und mehr Daten an als bei ext4. Daten-Sicherheit kostet eben. Man muss also beachten, wieviel Daten per io geschrieben wird und eher das heranziehen als die Anzahl der io. Anders würde man es mit ZFS ja auch gar nicht schaffen vergleichbare Performancewerte zu haben wie bei ext4 trotz weniger ops (Operations per s)

Bei den erreichbaren iops spielt ohnehin der Cache eine entscheidende Rolle.
Eine einfache Festplatte kann physikalisch etwa 100 iops (begrenzt durch Rotationsgeschwindigkeit und Spurwechselzeit). In den Datenblättern oder Testprogrammen hat man aber viel höhere Werte (weil im Hintergrund mehrere io zusammengefasst werden. bevor die auf Platte gehen)

Bei SSD hat man zudem das Problem, dass in Pages geschrieben wird. Ist der nicht komplett leer, muss er vorher komplett gelöscht werden. Das hat zur Folge dass die Schreib iops (per Datenblatt 100k) nach kurzer zeit gerne mal auf 5k einbrechen. Die Datenblatt Angaben muss man daher lesen wie die Höchstgeschwindigkeit eines Autos (im freien Fall) oder dessen Benzinverbrauch.


Was ich so erreiche
Mit einer Intel Optane 900 (Datenblatt 500k iops) so etwas unter 100k random write ops (ohne sync) und unter 10k mit aktiviertem Sync write, vgl https://napp-it.org/doc/downloads/optane_slog_pool_performane.pdf Kapitel 2.13

Die 100k ops werden über den Ram Schreibcache von ZFS erreicht, die 10k bei aktiviertem Sync kommen daher dass zusätzlich jeder Commit direkt auf der Optane landen muss.

Wichtiger als iops ist daher die Frage des Durchsatzes. Da ist ZFS nur wegen den überragenden Ram-Schreib/Lesecaches vergleichbar mit ext4, mit viel RAM oft sogar aber deutlich besser als ext4 oder ntfs.

 

[Sir Diablo]

Nunja selbst mit nem recordsize/volblocksize=4k und compression/checksum/primary/secondarycache=off (aber sync=always) sind die Werte unterirdisch für ne Ramdisk (sogar schlechter als mit 32k volblocksize). Das kann doch nicht nur Werte im niedrigen 10k Bereich ergeben? Mit nem unoptimierten btrfs (auch CoW) fileio auf der Ramdisk bekomm ich 5-10 Mal so hohe Werte wie mit ZFS.

 

[gea]

Alle ZFS Eigenschaften beziehen sich auf einen ZFS Datenblock. Selbst bei Datenbanken oder iSCSI (mit 8k Blöcken) sollte man nicht unter 32k recordsize gehen weil dann die Performance leidet. Alle Caches ausschalten ist auch eine Einstellung die man nur macht um zwei Settings zu vergleichen ohne dass man den Cache Einfluss hat. Ansonst ist das kein regulärer Zustand sondern bremst ZFS massivst aus.

ZFS Sync sollte man auf default/off lassen weil man ansonst jeden Datenblock zweimal schreiben muss, einmal via Ram Schreibcache sequentiell und zusätzlich direkt per Commit als kleines random io write auf das ZIL. Btrfs hat eh keinen zu sync/Slog/ZIL vergleichbaren Mechanismus.

Ansonsten wie gesagt auf Durchsatz achten und nicht auf einzelne Messwerte die man bei sehr unterschiedlichen Konzepten schwer vergleichen kann.

Last but not least gibt es auch ZFS Unterschiede zwischen Solaris, BSD und Linux.
Bisher war Solarish die schnellste, Linux die langsamste ZFS Platform. Viele neuere Sachen in ZoL lassen aber den Schluss zu, dass sich das derzeit ändert,

"
Ubuntu 2200 iops
Debian 2000 iops
CentOS 8000 iops

FreeBSD 16000 iops

Ubuntu + XFS 34000 iops
Ubuntu + EXT4 32000 iops
Ubuntu + BcacheFS 14000 iops
"

siehe How many here run ZFS on Linux and get good fsync performance? | Page 2 | ServeTheHome and ServeThe.Biz Forums

 

[Sir Diablo]

Nunja, in dem Thread bin ich ja schon selbst am diskutieren, da haben wir ja aber auch keine Antwort gefunden. Mir gings mehr darum zu sehen was das Limit von ZFS an sich ist. Und für sync 4k randwr scheint es wohl schlecht(er) geeignet zu sein. sync zu disablen hilft natürlich um schöne Benchmark Ergebnisse zu erzielen, ist aber nicht immer eine Option.

 

[gea]

sync zu disablen hilft natürlich um schöne Benchmark Ergebnisse zu erzielen, ist aber nicht immer eine Option.

Eigentlich nicht. Ein ZFS Filer arbeitet per default mit deaktiviertem sync. Das ist auch für ZFS wegen CoW völlig problemfrei da selbst ein Crash beim Schreiben zu keinem korrupten ZFS Dateisystem führt so wie das bei Nicht-CoW Dateisystemen der Fall sein kann.

Es gibt aber Anwendungen wie transaktionsbasierte Datenbanken oder VM Storage mit Dateisystemen bei denen ein bestätigter Schreibvorgang auf stabilem Storage sein muss und nicht im RAM-Schreibcache verloren gehen darf. Dafür brauchte es bisher ein Hardwareraid mit Cache und BBU/Flashsicherung oder eben ZFS mit aktiviertem Sync Modus und einem Slog/Zil mit funktionierender Powerloss Protektion um den ZFS Cache abzusichern.

ZFS mit aktiviertem Sync kann man nur mit anderen Systemen vergleichen, wenn man dort ein Hardwareraid mit entsprechender Absicherung benutzt.

 

[Sir Diablo]

Genau das ist ja der Punkt, ZFS performt generell nicht schlecht, ist aber verglichen mit einem BBU Cache Raid den Messungen auf der Ramdisk zufolge "hoffnungslos" unterlegen in 4k randwr. Ein sync write entspricht zwei Schreibvorgängen auf der Platte, die Performance beträgt aber nicht die Hälfte sondern 1/10 bis 1/65. Dieser krasse Unterschied verwundert mich.

 

[gea]

Ein sync write entspricht zwei Schreibvorgängen auf der Platte

Nein, so arbeitet ZFS nicht.
Bei ZFS gehen grundsätzlich alle Writes (egal bei welcher Sync Einstellung) in den Ram-Schreibcache. Dessen Größe ist bei Open-ZFS 10% des RAM, max 4GB als default, bei Solaris entspricht er 5s Schreiben. Ist der Cache voll, wird der Inhalt als ein einziges bis zu Gigabytes großes, schnelles sequentielles Write auf den Pool geschrieben.

Aktiviert man sync, so wird jeder kleine bestätigte Schreibvorgang zusätzlich sofort auf dem Logdevice ZIL/Slog protokolliert damit diese bei einem Crash beim nächsten Reboot nachgeholt werden können. Je nach Anwendung können Dutzende bis Hunderte Log Commits auf ein Cache Flush kommen.

 

[Sir Diablo]

Also ist es genau so wie ich sage. Ein sync write entspricht zwei writes auf die "Platte"=ramdisk. Also erwartet man etwas in Richtung von 40-50% der raw randwr Werte dieses Devices, und nicht nur 3-10% der raw randwr Werte.

 

[gea]

Nehmen wir mal vereinfacht an, eine Datenbank schreibt in 5s 100 x kleine Datenmengen z.B. 4KB und der Ram-Schreibcache wird alle 5s geleert.

Das erzeugt in 5s mit aktiviertem sync 100 Schreibvorgänge je 4KB auf das Logdevice.
Nach 5s werden diese zusätzlich als ein gesammelter 400KB Schreibvorgang auf den Datenpool geschrieben.

In 5s haben wir also 101 Schreibvorgänge. Hundert kleine ganz langsame 4KB und einen schnelle großen 400KB der je nach recordsize Einstellung z.B. default 128 KB auf wenige geschriebene ZFS Datenblöcke verteilt wird.

Die Aufteilung der Daten erfolgt zwar in beiden Fällen auf die physikalischen Blöcke der Platte z.B. 4KB, dennoch ist eine Platte beim Schreiben kleiner Blöcke (4KB) erheblich langsamer als beim Schreiben großer Blöcke wie 128KB.

Wenn man z.B. einen Atto Performancetest laufen läßt, sieht man dass erst ab ca 128 oder 256KB Schreibblöcken die volle Plattenperformance erreicht wird. Das Schreiben kleiner Blöcke wie 4KB ist um Größenordnungen (Faktor 100) langsamer.


Prinzipiell ist dieses Verhalten immer ersichtlich, egal ob mechanische Platte, SSD oder Ramdisk. Das Verhalten von ZFS ist schon auf Plattenverhältnisse und nicht auf Ramdisk optimiert dennoch dürfte auch eine Ramdisk beim Schreiben weniger größerer Blöcke schneller sein als bei vielen kleinen Blöcken mit derselben Datenmenge.

 

[Sir Diablo]

Ja du beschreibst ständig das Verhalten mit Disks. Ich möchte ja nur ZFS an sich testen und dazu eliminiere ich den Faktor "langsame" Disk durch ne Ramdisk, die im raw randwr "ganz gut" performt... Also ein Schreibvorgang der Daten und ein Schreibvorgang zur Aktualisierung des Pointers, und das sollte eine Ramdisk mehr als nur 10k-40k/Sekunde können. Getestet mit verschiedenen Blockgrößen, Cache on/off, checksum on/off, kernel Versionen, ZoL Versionen, auf FreeBSD und Solaris. Es performt nie gut für sync 4k randwr.

 

[gea]

Cache on/off betrifft nur Arc/L2Arc, also den Lesecache. Checksum on/off reduziert etwas die Datenmenge, sind also nicht entscheidend für Write. Ansonst würde ich gerne mal ein Atto Benchmark auf Ramdisk sehen, bei dem 4KB und 256KB Werte ähnlich schnell ist.

Und wie gesagt, sync=on ist etwas ZFS spezifisches, hat nichts z.B. mit dem Plattencache oder anderen Einstellungen anderer Dateisysteme zu tun. Diese haben diesen RAMcache Sicherheitsmodus nicht. Macht also wenig Sinn ZFS mit Sync=on mit anderen Dateisystemen zu vergleichen und dann die schlechten ZFS sync Werte zu beklagen.Und wenn die sowas nicht haben, muss man sync=default/off vergleichen. Gleiches gilt für andere ZFS Eigenschaften. Wenn man alle Caches ausschaltet, schaltet man alles aus was ZFS schnell macht. Selbst beim Schreiben schlägt das durch da auch beim Schreiben Metadaten gelesen werden müssen.

Wenn man dann mit jeweils Standardeinstellungen die Werte vergleicht, dann wird vermutlich herauskommen, dass ZFS immer langsamer ist (wenig RAM) und bei viel RAM aber deutlich schneller sein kann. Die Realität liegt je nach RAM und Workload dazwischen

ZFS ist auf maximale Sicherheit entwickelt. Das ist per se langsamer als ein System das diese Sicherheitsmerkmale nicht hat. ZFS kann das durch seine Caches ausgleichen, manchmal sogar überkompensieren. Wenn man das alles aber ausschaltet und einen ZFS Spezialmodus aktiviert der es besonders sicher und langsam macht - den es anderswo nicht gibt, was erreicht man dann? ZFS ist schlecht und Dateisystem xxx ist gut?? Das ist dann doch sehr einseitig.

 

[Sir Diablo]

Das sagt doch auch keiner... meine Frage dazu war nur "ist ZFS in sync 4k randwr wirklich so schlecht" und die Antwort ist, leider, ja. Die Diskrepanz ist nur, dass es auf der Ramdisk kaum einen Unterschied machen sollte ob ich seqwr oder randwr teste, und im 4k seqwr sehen die Werte ja akzeptabel aus. Ich besprech das besser mal in der Mailingliste, trotzdem Danke.

 

[rigel]

Eine Frage zu SMB-Freigaben aus OmniOS/napp-it:

Ich habe eine solche Freigabe in einer Ubuntu-VM gemountet.
Nach meinem Verständnis werden die üblichen Unix-Rechte innerhalb dieser Freigabe nicht unterstützt. Für alle Dateien zeigt mir ls defaultmäßig 755 an:

-rwxr-xr-x 1 ubuntu ubuntu 0 Apr 6 13:37 test.txt*

Nun kann ich aber mit chmod 555 test.txt sehr wohl die Unix-Rechte der Datei verändern:

-r-xr-xr-x 1 ubuntu ubuntu 0 Apr 6 13:37 test.txt*

Von einem Windows-Client ist diese Datei dann "read-only". Das Ganze funktioniert auch bei aclmode=restricted, was mich sehr wundert.
Ich dachte, mit dieser Einstellung sollen sämtliche Änderungen durch chmod gerade abgeblockt werden.

 

[gea]

Soweit ich das verstehe funktioniert aclmode=restricted nur lokal oder über NFS. SMB (Solaris Kernelbased SMB Server) unterstützt ausschließlich NFS4 ACL (ähnlich wie ntfs ACL) - genau wie Windows.

Wenn ein Client der keine NFS4 ACL kann Rechte per chmod xxx verändert (auf Solarish oder Windows) so wird eine ACL gesetzt die genauso restriktiv ist wie das Unix Recht. Es ist ja auch nicht so dass bei ZFS entweder ACL oder klassische Unix Rechten gesetzt werden. Klassische Unixrechte sind ja mit ACL auch möglich. ACL könnte lediglich viel feinere Rechteabstufungen.

Da klassische Unixrechte keine ACL Vererbung können, sollte man allenfalls prüfen ob die ACL Vererbung aktiv bleibt (per Windows oder napp-it)

 

[rigel]

So ganz klar ist mir das immer noch nicht. Mein Client ist ja weder Solarish noch Windows, sondern Ubuntu.

Durch Probieren sieht es für mich so aus, dass der read-only-Status einer Datei auf das Write-Bit des Owners gemappt wird. Jeder Versuch, ein anderes Bit per chmod zu verändern, wird ignoriert.

Wenn dieses Verhalten erwartungsgemäß ist, muss es doch irgendwo dokumentiert sein.

 

[gea]

Windows und Solarish (mit dem kernelbased SMB Server) arbeiten intern ausschließlich mit ntfs/NFS4 ACL. Setzt ein Client Rechte, so werden diese ACL modifiziert, auch wenn der Client wie SAMBA die nicht unterstützt. Wenn SAMBA von Ubuntu Rechte auf Windows/Solarish setzt wird das auf eine passende ACL umgesetzt die vergleichbare Einschränkungen hat.

Umgekehr ist das genauso. Wenn Windows auf Linux mit SAMBA das nur klassische Unix Permissions unterstützt zugreift und Rechte ändert wird das auch so umgesetzt das es am Ende nicht mehr Rechte hat wie die ACL die Windows eigentlich setzen möchte.

Die Rechte sind natürlich nie identisch und manches macht Probleme oder geht verloren wenn es sich um auf dem Zielsystem nicht unterstützt Features handelt wie SMB Gruppen in SMB Gruppen, mehrere User ACL oder ACL Vererbung oder aber die Feinheiten von ntfs/NFS4 ACL.

Prinzipiell sollte sich Solarish hier so verhalten wie Windows als Ziel. Die genaue Art der Rechte Umsetzung findet sich vermutlich am Ehesten in den SAMBA docs. In dem Punkt ist Solarish besonders. ZFS ist ja ein Unix Dateisystem mit klassischen Unix Permissions und NFS4 ACL als Ergänzung. Der Solarish SMB Server verhält sich aber Windows alike und nicht Unix alike. Er nutzt Windows sid Identifier statt Unix UID/GID und setzt diese und die Rechte als erweiterte ZFS Attribute.

Ein weitgehend identisches Verhalten Server/Client hat man nur beim Rechte setzen von Windows->Windows/Solarish oder SAMBA -> SAMBA da hier Client und Server die gleiche Rechteverwaltung (Permissions oder ACL) haben. Beim Lesen (beliebiger Client) werden die Rechte dann immer so beachtet dass man sich innerhalb der gesetzten Rechte bewegt.

Eine passende Doku könnten ältere Solaris Docs sein wie Setting Up a Oracle Solaris SMB Server to Manage and Share Files - Managing SMB File Sharing and Windows Interoperability in Oracle Solaris 11.1. Da war Solaris und Illumos ja noch identisch. Neues Solaris weicht etwas ab.

Solaris ACL
New Solaris ACL Model - Oracle Solaris ZFS Administration Guide

 

[Trambahner]

Berücksichtigt ZFS eigentlich Smart-Stati von Devices? Sprich, was passiert wenn Smart "failed" ausgibt, die SSD aber durchaus noch funktioniert?

Beispiel: Die Samsung Enterprise-SSDs geben bereits "failed" aus, wenn die Powerloss-Kondensatoren ausgefallen sind, der Rest aber normal funktioniert.