[Sammelthread] ZFS Stammtisch

[TCM]

Da hiess es Datenkorruption bei den qcow2 Files, weil das auch ein COW sei.

Ich würde mal ganz stark nachdenken und mich fragen, wie gut ein Dateisystem sein soll, was bei bestimmten Konstellationen Daten kaputtmacht. Sowas hab ich ja noch nie gehört.

 

[trendco]

Ich war ja selbst erschrocken über die Aussage und verstehe nicht, was für Probleme es da geben soll (außer vielleicht Performance Einbußen). Ich setze das ganze ja auch seit gut 2 Jahren genau so ein und bis dato hatte ich noch keinerlei Probleme damit. Allerdings stimmen einem solche Aussagen eben nachdenklich

Grundlage is übrigens dieser Thread hier: qcow2 auf ZFS ? | Proxmox Support Forum

Bis dato konnte mir dort aber auch keiner erklären was da genau passieren könnte. Mythos?

 

[TCM]

Man muss erstmal unterscheiden, von welcher Ebene man spricht. Spricht man vom ZFS, auf dem das Image liegt, spricht man vom Filesystem in dem Image oder spricht man vom Snapshotting von qcow2? Dass beim Snapshotting vom qcow2 was durcheinanderkommen kann, wenn man mittendrin mit ZFS-Snapshots hantiert und da wild Rollbacks macht, kann ich mir noch vorstellen. Dass das Filesystem im Image inkonsistent werden kann, ist selbst nur mit ZFS-Snapshots klar. Aber dass das ZFS kaputtgeht? No way. Man muss halt einfach wissen, was man treibt und wovon man redet.

Edit: Und DANN redet er am Ende noch davon, dass man ZFS AUF qcow2-Images anlegt, was wieder was völlig Anderes ist.

Das alles ist dann auch nur im Zusammenhang mit Snapshots ein Problem. Mit COW ansich hat das überhaupt nichts zu tun.

 

[trendco]

Jetzt wirds wirr

Edit: Und DANN redet er am Ende noch davon, dass man ZFS AUF qcow2-Images anlegt, was wieder was völlig Anderes ist.

Bezieht sich das jetzt auf meinen Post dort im Proxmox Forum oder auf den englischen Beitrag den dort einer verlinkt hat?

Mir selbst geht es ja nur darum: Ich habe Proxmox mit ZFS-Mirror installiert und dort darauf laufen VM's deren Image-Format qcow2 ist.

 

[TCM]

Ja, das war der Link im letzten Beitrag zu dem Zeitpunkt. Wenn du nur ZFS benutzt ohne Snapshots, dann dürfte es absolut keine Probleme geben. Wo kommen denn diese Bedenken ursprünglich überhaupt her?

Edit: gefunden: qcow2 Disk Shrinken? | Proxmox Support Forum

Soll er mal begründen. Halte ich für Blödsinn. Klingt, als hätte er sowas wie ZFS: Practicing failures on virtual hardware JRS Systems: the blog gelesen und reimt sich jetzt irgendwas zusammen, weil er so tief auch nicht drinsteckt.

Die Sache ist nämlich die: Entweder ist ZFS ein Filesystem, was richtig funktioniert, dann ist es völlig egal, wie die Daten aussehen und was damit gemacht wird. Es hat die Daten ordentlich zu speichern. Ende. Wenn es das nicht tut und Nutzdaten(!) das Filesystem beeinflussen, dann ist das Filesystem kaputt. Sobald das Filesystem also aus der Betrachtung raus ist und als "transparent" angenommen werden kann, sind Probleme wie die angesprochenen logisch unmöglich. Performance und Snapshots mal außen vor. Es geht rein darum, ob da was kaputtgehen kann einfach so. Und ich sage: Nein.

 

[Turboschnecke]

Eine Frage zu LX Zones unter OmniOS:
Ich versuche gerade ein Ubuntu in einer LX Zone zu installieren/starten. Das klappt auch soweit, aber ich habe darin keinerlei Netzzugriff, weil als Interface nur ein local loopback angelegt wird...
Ich hab auf der Console eine vnic angelegt: dladm create-vnic lx0 -l igb0
In Napp-It habe ich dann beim Anlegen der Zone entsprechend lx0 ausgewählt und den Typ auf exclusive gelassen.
Was läuft schief? Soweit ich das verstanden habe, habe ich unter Ubuntu auch nur das eine Interface , ifconfig liefert mit zumindest nur lo als Interface...

 

[CommanderBond]

Also mit debian klappte es bei mir auf Anhieb. Nur die Vorlage war falsch was das Netzwerk betraff, musste Gateway manuell setzen, hatte ich vor ein paar Posts mal was zu geschrieben.

 

[Turboschnecke]

Hmm, ja. Dann will er da keine Maske haben, sondern gleich eine feste IP? Wollte eigentlich, dass dort DHCP benutzt wird. Hatte es nur von 192.168.1.0/24 auf 192.168.177.0/24 geändert. Direkt eine feste IP hatte ich noch nicht probiert. Mal testen

 

[CommanderBond]

192.168.177.0/24 ist aber falsch du musst die Adresse vom Router da eintragen 1 oder 254 oder was du halt benutzt

create -b
set zonename=unifi
set zonepath=/ssdpool/zones/unifi-5.6
set brand=lx
set autoboot=true
set ip-type=exclusive
add net
set physical=lx0
add property (name=gateway,value="192.168.1.1")
add property (name=ips,value="192.168.1.11/24")
add property (name=primary,value="true")
end
add attr
set name=dns-domain
set type=string
set value=example.com
end
add attr
set name=resolvers
set type=string
set value=8.8.8.8
end
add attr
set name=kernel-version
set type=string
set value=3.16.0
end
add fs
set dir=/shared
set special=/ssdpool/zones/shared
set type=lofs
end

damit ging es wie gesagt bei mir mit debian.

 

[Turboschnecke]

Es gibt einmal "Network ip/dhcp + netmask ex 192.168.1.0/24" und einmal Gateway
Beim ersten hab ich das ganze eben auf 192.168.177.0/24 gesetzt und das Gateway auf 192.168.177.1 für den Router.

Edit: hab jetzt bei Network ip mal dhcp reingeschrieben und Gateway auf .177.1 jetzt klappt es
Tausenddank Commander

 

[CommanderBond]

192.168.177.0/24 änder die 0 mal auf ne freie Adresse in deinem Netzwerk

 

[Turboschnecke]

DHCP funktioniert und langt mir! Mir war nicht klar, was er da haben will. Hab mich an dem Beispiel orientiert und mich hats gewundert, dass es gar nicht erst ein Interface ausser dem Loopback gibt.

 

[CommanderBond]

@gea

Folder Permission - - - - - - cfg State cfg File cfg Action
/ssdpool/zones/pyload drwx------ 3 root 4 Jan 18 15:27 pyload/zone.zfg edit zone.cfg configure
/ssdpool/zones/shared drwxrwxrwx 3 root 3 Jan 11 18:07 shared - -
/ssdpool/zones/unifi-5.6 drwx------ 4 root 7 Jan 18 15:30 unifi-5.6/zone.zfg edit zone.cfg configure

Mir ist noch ein Bug aufgefallen.
Wenn ich auf "configure" klicke steht bei cfg File und cfg Action jeweils "configured".

Wenn ich aber per "set zonename=unifi" einen Namen vergebe und dann auf configure klicke passiert dies nicht.

 

[gea]

Ich habs mir notiert.

Im Moment gilt meine Aufmerksamkeit der Datenschutz-Grundverordnung der EU. Die gilt direkt ab Mai in De und fordert neben Sachen wie Dokumentation über Daten und wie damit umgegengen wird, Verfahrensverzeichnisse oder Datenschutzbeauftragten auch einen Datenschutz nach Stand der Technik. Das bedeutet bereits auf Datenebene Verschlüssellung oder Strafe. Bei einer angedrohten Strafe bis zu 4% des weltweiten Umsatzes erwarte ich dass sich alle arbeitslosen Anwälte in der EU sich ab Mai darauf stürzen werden.

Ich konzentriere mich auf den technischen Aspekt. Derzeit bietet nur Solaris eine unterschiedliche Verschlüssellung auf ZFS Dateisystem-Ebene für mehrere Anwender. Ich möchte das durch ein Locking/Unlocking absichern indem ich ein ZFS Dateisystem automatisch oder per User Aktion und Zeitplan automatisch entschlüssle/verschlüssle, z.B. offen an bestrimmten Tagen zu bestimmten Zeiten.

Wie gesagt, im Moment nur Oracle Solaris, 2018 ist aber das Jahr von Open-ZFS mit

- ZFS Encryption für Open-ZFS
- entfernen eines vdevs
- Raid erweitern (hinzufügen einr Platte zu einem vdev, z.B. 6 Disk raid-Z2 auf 7 Disk raid-Z2)
- schnelles sequentielles Resilvering

 

[XBashX]

Hallo,

ich habe ein seltsames Problem mit meinem ZFS Filer @Home (omnios-r151022), welches mir auch jetzt erst auffällt.
Normalerweise benutze ich den Filer nur zum Abspeichern von Dokumenten und arbeite nicht direkt auf ihm, jedoch ist mir jetzt aufgefallen, dass Bilder als auch Office (hier zeigt es sich durch einen "Downloade Datei xyz" Fortschrittsbalken) sowie manchmal Adobe Dateien lange brauchen zum öffnen.
Shares sind mit SMB eingebunden auf einem Win 7 Client und 2x Win10. Auf allen tritt das Problem auf.
Normales kopieren (lesend als auch schreibend) funktioniert knapp unter der für 1GB möglichen Übertragungsrate mit 108 MB/s.

 

[layerbreak]

@XBashX guckst du in napp-it unter
Dienste/SMB/properties unten im Erklärungs-Bereich

Die Eigenschaft: oplock_enable

https://serverfault.com/questions/799295/omnios-zfs-windows-7-save-as-from-within-applications-lags-5-seconds-for-all?rq=1

Wenn du vorher wissen willst, wie die Eigenschaft eingestellt ist:
# svccfg -s network/smb/server listprop smbd/oplock_enable

 

[layerbreak]

Ich habe auf dem AIO mir eine Debian 9.3 Minimal-Install eingerichtet. Außer root gibt es dort nur einen User "paul" und einen User "websoft mit uid=999", den die installierte Anwendung angelegt hat.
Auf dem AIO habe ich ein Dateisystem "srv" mit smb-Freigabe "srv" und guestok, Folder-ACL steht auf: root, owner@ und everyone@ auf full_set. Plus einen SMB-User "layerbreak" mit Passwort "layerbreakPW".

Jetzt möchte ich auf dieser Debian-VM dieses FS "srv" für User "websoft" per fstab-Datei verbinden.
So hab ich es z.Zt. in die fstab eingetragen:

//AIO-IP/srv	/home/div-files	cifs	username=layerbreak,password=layerbreakPW	user,uid=999,gid=999	0	0

Vorher natürlich als root per mkdir /home/div-files angelegt und per chown websoft:websoft /homediv-files websoft zugewiesen.

Ich kann zwar auf das gemountete Verzeichnis "/home/div-files" drauf zugreifen - aber nur als User root. Mir gelingt es nicht, dass der mount im User websoft gehört.

Muss ich auf meinem AIO etwas anders einstellen, damit der Debian-User richtig gemountet wird oder hab ich in der fstab einen Fehler drinne? Verträgt sich smb, cifs von OmniOS und Debian nicht?

 

[you]

Mh ... ich habe eine Firewall in Betrieb genommen und sehe in den logs nun, was so "Unbekanntes" passiert.

Off-Topic: Schon interessant, wenn eine Steckdosenleiste, deren Steckdosen ich per LAN schalten kann, regelmässig bei "smart-metering-service.com" vorbei schaut. WHAT THE HELL !!!

On-Topic: Meine napp-it All-in-One VM versucht regelmässig mit einem Client über Port 111 Kontakt aufzunehmen. Problem: Dieser Client (also die IP Adresse) existiert nicht mehr ... was ist das?

 

[gea]

@layerbreak
Mit guestok=true brauchts keine Authentifizierung, dazu ist der Gastzugang ja da.
Das erst mal ausschalten

btw
Warum nicht einfach ein ZFS Dateisystem direkt an den Debian LX Container durchreichen?

@you
Port 111 wird z.B. von NFS genutzt.
Ist NFS aktiv? Eventuell mal testhalber ausschalten.

 

[you]

Sobald ich NFS ausschalte, ist die Meldung weg. Nach dem Einschalten aber wieder da. Ein Re-boot der NAS Appliance hat auch keine Änderung gebracht. Komisch. Die alte IP Adresse gehörte zu einem MacBook auf dem ich testweise mal eine NFS-Share gemountet hatte. Das ist aber ewig her ?!?

 

[MisterY]

Wie groß ist der Performance Sprung wenn man zwei 250gb 850evo als Cache hinzufügt? Oder bringt das nichts?

 

[layerbreak]

Mit guestok=true brauchts keine Authentifizierung, dazu ist der Gastzugang ja da.
Das erst mal ausschalten

OK, check ich mal, vielleicht funktioniert es dann.
Was ich halt nicht verstehe ist, dass der Mountpoint den ich auf der VM angelegt und die Rechte dem User zugeteilt habe, nach dem Mount jetzt wieder root gehört.
Wenn ich die man mount(8) von Debian richtig verstehe, müssten aber die Rechte bei "websoft" bleiben.

Warum nicht einfach ein ZFS Dateisystem direkt an den Debian LX Container durchreichen?

OK, auch ein Ansatz und geht das?

 

[TCM]

Was ich halt nicht verstehe ist, dass der Mountpoint den ich auf der VM angelegt und die Rechte dem User zugeteilt habe, nach dem Mount jetzt wieder root gehört.
Wenn ich die man mount(8) von Debian richtig verstehe, müssten aber die Rechte bei "websoft" bleiben.

Das Verzeichnis, wo ein anderes Filesystem hingemountet wird, hat andere Rechte als das gemountete Filesystem selber. Beim Mounten überlagert quasi das Verzeichnis "." des zu mountenden Filesystems den vorherigen Mountpoint im Elternverzeichnis. Deswegen sollten Mountpoints immer root:root gehören, damit vor dem Mounten niemand in den Pfad schreiben kann. Nach dem Mounten ändert man dann die Rechte wie gewünscht.

 

[gea]

OK, auch ein Ansatz und geht das?

Linux Zonen unter OmniOS/SmartOS können ZFS Dateisysteme direkt mounten z.B.:

add 
fs set dir=/zfs 
set special=/tank/test 
set type=lofs 
end

vgl http://www.napp-it.org/doc/downloads/zones.pdf

 

[layerbreak]

Das Verzeichnis, wo ein anderes Filesystem hingemountet wird, hat andere Rechte als das gemountete Filesystem selber. Beim Mounten überlagert quasi das Verzeichnis "." des zu mountenden Filesystems den vorherigen Mountpoint im Elternverzeichnis. Deswegen sollten Mountpoints immer root:root gehören, damit vor dem Mounten niemand in den Pfad schreiben kann. Nach dem Mounten ändert man dann die Rechte wie gewünscht.

Hm, dann ist es also kein OmniOS-Problem bzw. keines welches mit den zwei verschiedenen *nix System zu tun hat.
Verstanden, dass beim ersten Mount per fstab Datei der Mountpoint IMMER root gehört. In diesem Moment des Mountens ist das ok, aber gleich danach sollte es User websoft übergehen.
Nur wie bekomm ich es dann hin, dass danach der Mountpoint dem User "websoft" gehört, wenn weder ich noch websoft könne dies händisch ändern?

Linux Zonen unter OmniOS/SmartOS können ZFS Dateisysteme direkt mounten

Ich kenn mich mit Zones überhaupt nicht aus und ich möchte lieber es komplett getrennt von meinem OmniOS System haben.

 

[TCM]

Da scheint noch ein Missverständnis zu existieren. Also, du machst hypothetisch Folgendes als root:

mkdir /mnt/foo

/mnt/foo sollte in diesem Moment root:root gehören. Dann mountest du dein Filesystem nach /mnt/foo. Jetzt gehört /mnt/foo dem User, dem das Rootverzeichnis vom neuen Filesystem gehört, bei einem frischen ist das auch root:root. Das änderst du jetzt auf den gewünschten User. Danach gehört das Rootverzeichnis des Filesystems dauerhaft dem User. Wenn du /mnt/foo unmountest, ist /mnt/foo wieder auf root:root. Beim Mounten wird es wieder überlagert vom User des Filesystem-Rootverzeichnisses.

 

[layerbreak]

Jetzt möchte ich auf dieser Debian-VM dieses FS "srv" für User "websoft" per fstab-Datei verbinden.
So hab ich es z.Zt. in die fstab eingetragen:

//AIO-IP/srv	/home/div-files	cifs	username=layerbreak,password=layerbreakPW	user,uid=999,gid=999	0	0

@layerbreak
Mit guestok=true brauchts keine Authentifizierung, dazu ist der Gastzugang ja da.
Das erst mal ausschalten

Ich hab jetzt mal auf deinen Rat hin, die fstab so abgeändert:

//AIO-IP/srv	/home/div-files	cifs	user,uid=999,gid=999	0	0

Jetzt ist aber der Mountpoint nach einem Neustart nicht mehr vorhanden. In der mtab steht nichts mehr drinne.

- - - Updated - - -

Linux Zonen unter OmniOS/SmartOS können ZFS Dateisysteme direkt mounten

Funktioniert das eigentlich?

Eine Linux-Zone mit darin laufendem Debian und dann da ein Docker-Container laufen lassen.

- - - Updated - - -

Da scheint noch ein Missverständnis zu existieren. Also, du machst hypothetisch Folgendes als root:

mkdir /mnt/foo

.

Hab ich gemacht, als root

/mnt/foo sollte in diesem Moment root:root gehören.

Richtig, ist bei mir auch so.
Habe aber danach die Dateirechte per chown websoft:websoft /homediv-files zugewiesen.

Dann mountest du dein Filesystem nach /mnt/foo.

Das hab ich per fstab Datei gemacht, damit bei einem Neustart der Mount erhalten bleibt.
Nach einem Neustart gehört /homediv-files aber wieder root UND ist auch nicht änderbar.

Jetzt gehört /mnt/foo dem User, dem das Rootverzeichnis vom neuen Filesystem gehört, bei einem frischen ist das auch root:root.

Eben nicht.

Das änderst du jetzt auf den gewünschten User. Danach gehört das Rootverzeichnis des Filesystems dauerhaft dem User. Wenn du /mnt/foo unmountest, ist /mnt/foo wieder auf root:root. Beim Mounten wird es wieder überlagert vom User des Filesystem-Rootverzeichnisses

Auch das Ändern geht nicht per chown websoft:websoft /homediv-files es bleibt auf root:root.

Egal welchen Parameter ich in 4. Part nehme, es ändert sich nichts an den Eigentumverhältnissen.

So stehts in der mtab drinne:

//AIO-IP/srv /home/div-files cifs rw,relatime,vers=1.0,cache=strict,username=layerbreak,domain=AIO,uid=0,noforceuid,gid=0,noforcegid,addr=AIO-IP,file_mode=0755,dir_mode=0755,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1 0 0

 

[TCM]

Die Rechte des gemounteten Filesystems kommen vom Filesystem-Treiber. Bei CIFS musst du ihm irgendwie klarmachen, dass es nicht root:root ist. Wie das genau geht, da bin ich mal außen vor.

VOR dem Mounten solltest du dagegen keine Rechte ändern, sonst kann der User auch in das ungemountete Verzeichnis schreiben und damit eine völlig andere Partition füllen.

 

[Turboschnecke]

Ich hab noch mal eine Frage zu den Zones:
Eigentlich will ich einen Emby Server direkt auf dem Storage mit laufen lassen. Ich habe es inzwischen geschafft, dass ich Emby unter einer CentOS7 LX Zone installieren und manuell starten kann. Jetzt scheitere ich aber daran, dass die SMB Freigaben vom Storage nicht gefunden werden... Ist das ein grundsätzliches Problem wegen der Zone-Geschichte oder einfach nur mein Unvermögen? Ins Internet komme ich unter CentOS, dann müsste ich doch auch direkt die Freigaben über //IP/Freigabe finden oder nicht?

 

[layerbreak]

Die Rechte des gemounteten Filesystems kommen vom Filesystem-Treiber. Bei CIFS musst du ihm irgendwie klarmachen, dass es nicht root:root ist. Wie das genau geht, da bin ich mal außen vor.

VOR dem Mounten solltest du dagegen keine Rechte ändern, sonst kann der User auch in das ungemountete Verzeichnis schreiben und damit eine völlig andere Partition füllen.

Ich installiere ich mal das mount.cifs Paket und schau ob es dann geht.
Das dumme ist halt, dass es kein so tolles Tool wie beadm bei Linux gibt und ich daher vorsichtig sein muss, was ich mache.

Ich hab noch mal eine Frage zu den Zones:
Eigentlich will ich einen Emby Server direkt auf dem Storage mit laufen lassen. Ich habe es inzwischen geschafft, dass ich Emby unter einer CentOS7 LX Zone installieren und manuell starten kann. Jetzt scheitere ich aber daran, dass die SMB Freigaben vom Storage nicht gefunden werden... Ist das ein grundsätzliches Problem wegen der Zone-Geschichte oder einfach nur mein Unvermögen? Ins Internet komme ich unter CentOS, dann müsste ich doch auch direkt die Freigaben über //IP/Freigabe finden oder nicht?

@Turboschnecke @gea hatte mir das vor ein paar Tagen geschrieben. Vielleicht bekommst du so das Dateisystem in CentOS.

Linux Zonen unter OmniOS/SmartOS können ZFS Dateisysteme direkt mounten z.B.:

add 
fs set dir=/zfs 
set special=/tank/test 
set type=lofs 
end

vgl http://www.napp-it.org/doc/downloads/zones.pdf