zfs shares des FreeBSD Server korrekt bei den FreeBSD-Clients mounten

H

holgerw

Guest
Hallo,

ich stelle gerade etwas eigenartiges fest, was ich nicht hatte, als mein Daten-NAS noch mit Debian und ext4 lief.

Im dolphin meines Desktop-PC sehe ich, wenn ich versteckte Dateien sichtbar mache, bei den Shares vom FreeBSD Daten-Nas solche mit .nfs.blablub. Diese haben die gleiche Größe, wie zuvor gelöschte Dateien. Sie lassen sich vom dolphin ohne Fehlermeldung löschen, und sind wenige Sekunden später wieder da. Sie haben auch die gleichen Eigenschaften, war die gelöschte Datei eine 1 GB große wav-Datei, dann hat die .nfs.blablub Datei auch 1 GB und wird mir im dolphin auch als Audio-Datei angezeigt.

Wo kommen diese komischen Dateien her?
Wie bekomme ich dieses Zeug, was tatsächlich auch Platz benötigt, wieder weg?

Muss man, wenn man auf dem Server zfs (als einfacher Mirror auf ada0p3 und ada1p3) verwendet, diese irgendwie anders freigeben bzw. anders auf den Clients mounten, als wenn man nur nfs und z.B. ext4 oder ufs2 verwendet? Darf man da etwa gar kein "normales" nfs verwenden?

Meine /etc/exports auf dem NAS taschenmaus:
Code:
/daten/pc               -maproot=root   -alldirs feldmaus biber elch
/daten/nutzer/share                     -alldirs feldmaus biber elch farbmaus eichhorn
/daten/nutzer/diane                     -alldirs feldmaus biber elch
/daten/nutzer/holger                    -alldirs feldmaus biber elch

Und hier die relevanten fstab-Einträge auf meinem Desktop-Rechner biber:
Code:
taschenmaus.unix.pc:/daten/nutzer/share         /nas/share              nfs     rw              0      0
taschenmaus.unix.pc:/daten/pc                   /nas/pc                 nfs     rw              0      0
taschenmaus.unix.pc:/daten/nutzer/holger        /usr/home/holger/nas    nfs     rw              0      0
taschenmaus.unix.pc:/daten/nutzer/diane         /usr/home/diane/nas     nfs     rw              0      0

Viele Grüße,
Holger

Nachtrag: Melde ich mich auf dem NAS an und gehe mit der Konsole in ein solches Verzeichnis und lösche die .nfs ... Dateien, dann tauchen sie übrigens nicht wieder auf und sind wohl tatsächlich gelöscht.
 
Ist vielleicht auch einfach KDE? Das macht so "in den Papierkorb verschieben" statt löschen, und AS sieht dann so ähnlich aus...
 
Ist vielleicht auch einfach KDE? Das macht so "in den Papierkorb verschieben" statt löschen, und AS sieht dann so ähnlich aus...
Hallo,

das hat mit KDE nix zu tun. Auch über ein Terminal vom Client aus lässt sich .nfsblablub zwar löschen, erscheint aber sofort wieder.

Noch skurriler: Ich kann mit dolphin (vom Client) mir über Suchen Dateitypen gefiltert anzeigen. Ich gehe in das Unterverzeichnis eines nfs-Shares, in welchem z.B. wav-Dateien sind. Dann lass ich nach *.wav suchen, es gibt aber laut dolphin gar keine *.wav in dem Verzeichnis. Häh, was ist denn das? (die Suche funktioniert ansonsten, auch mit wav)

Diese Dateien lösche ich dann, Sekunden später erscheinen an der Stelle .nfs-Dateien mit exakt der gleichen Größe der wav-Dateien und sie werden auch als wav-Audios angezeigt.
Vom Terminal des clients:
Code:
ls -lh
total 5007548
-rw-rwxr-x  1 holger  users   135M  5 Aug. 22:40 EURO_2016-2017_OL_004_01.flac
-rw-rwxr-x  1 holger  users   358M 16 Mai  08:30 EURO_2016-2017_OL_004_01.wav
-rw-rwxr-x  1 holger  users   159M  5 Aug. 22:40 EURO_2016-2017_OL_004_02.flac
-rw-rwxr-x  1 holger  users   411M 16 Mai  09:09 EURO_2016-2017_OL_004_02.wav
-rw-rwxr-x  1 holger  users   116M  5 Aug. 22:40 EURO_2016-2017_OL_004_03.flac
-rw-rwxr-x  1 holger  users   300M 16 Mai  09:54 EURO_2016-2017_OL_004_03.wav
-rw-rwxr-x  1 holger  users   211M  5 Aug. 22:41 EURO_2016-2017_OL_004_04.flac
-rw-rwxr-x  1 holger  users   580M 16 Mai  11:59 EURO_2016-2017_OL_004_04.wav
-rw-rwxr-x  1 holger  users    48M  5 Aug. 22:40 EURO_2016-2017_OL_004_05.flac
-rw-rwxr-x  1 holger  users   132M 16 Mai  12:21 EURO_2016-2017_OL_004_05.wav
-rw-rwxr-x  1 holger  users    20K 16 Mai  12:24 EURO_2016-2017_OL_004.odt
-rw-rwxr-x  1 holger  users    34K 16 Mai  12:24 EURO_2016-2017_OL_004.pdf

Dann nach einem
Code:
rm *.wav
vom Terminal des Clients:
Code:
ls -lah                                                                               
total 5007582
drwxrwxr-x   2 holger  users    14B  6 Aug. 07:42 .
drwxrwxr-x  15 holger  users    15B  6 Aug. 07:24 ..
-rw-rwxr-x   1 holger  users   358M 16 Mai  08:30 .nfs.80088ccc.05054.4
-rw-rwxr-x   1 holger  users   411M 16 Mai  09:09 .nfs.80088cd1.05054.4
-rw-rwxr-x   1 holger  users   300M 16 Mai  09:54 .nfs.80088cd5.05054.4
-rw-rwxr-x   1 holger  users   580M 16 Mai  11:59 .nfs.80088cd9.05054.4
-rw-rwxr-x   1 holger  users   132M 16 Mai  12:21 .nfs.80088cdd.05054.4
-rw-rwxr-x   1 holger  users   135M  5 Aug. 22:40 EURO_2016-2017_OL_004_01.flac
-rw-rwxr-x   1 holger  users   159M  5 Aug. 22:40 EURO_2016-2017_OL_004_02.flac
-rw-rwxr-x   1 holger  users   116M  5 Aug. 22:40 EURO_2016-2017_OL_004_03.flac
-rw-rwxr-x   1 holger  users   211M  5 Aug. 22:41 EURO_2016-2017_OL_004_04.flac
-rw-rwxr-x   1 holger  users    48M  5 Aug. 22:40 EURO_2016-2017_OL_004_05.flac
-rw-rwxr-x   1 holger  users    20K 16 Mai  12:24 EURO_2016-2017_OL_004.odt
-rw-rwxr-x   1 holger  users    34K 16 Mai  12:24 EURO_2016-2017_OL_004.pdf
Diese .nfs.-Dateien sind vom Terminal des Clients aus nicht lösdchbar, es kommt zwar keine Fehlermeldung, sie sind sofort aber wieder da.

Melde ich mich mit dem gleichen Nutzer per ssh auf dem NAS an, gehe zum besagten Verzeichnis mit den .nfs-Dateien:
Code:
ls -lah
total 2503791
drwxrwxr-x   2 holger  users    14B  6 Aug. 07:42 .
drwxrwxr-x  15 holger  users    15B  6 Aug. 07:24 ..
-rw-rwxr-x   1 holger  users   358M 16 Mai  08:30 .nfs.80088ccc.05054.4
-rw-rwxr-x   1 holger  users   411M 16 Mai  09:09 .nfs.80088cd1.05054.4
-rw-rwxr-x   1 holger  users   300M 16 Mai  09:54 .nfs.80088cd5.05054.4
-rw-rwxr-x   1 holger  users   580M 16 Mai  11:59 .nfs.80088cd9.05054.4
-rw-rwxr-x   1 holger  users   132M 16 Mai  12:21 .nfs.80088cdd.05054.4
-rw-rwxr-x   1 holger  users   135M  5 Aug. 22:40 EURO_2016-2017_OL_004_01.flac
-rw-rwxr-x   1 holger  users   159M  5 Aug. 22:40 EURO_2016-2017_OL_004_02.flac
-rw-rwxr-x   1 holger  users   116M  5 Aug. 22:40 EURO_2016-2017_OL_004_03.flac
-rw-rwxr-x   1 holger  users   211M  5 Aug. 22:41 EURO_2016-2017_OL_004_04.flac
-rw-rwxr-x   1 holger  users    48M  5 Aug. 22:40 EURO_2016-2017_OL_004_05.flac
-rw-rwxr-x   1 holger  users    20K 16 Mai  12:24 EURO_2016-2017_OL_004.odt
-rw-rwxr-x   1 holger  users    34K 16 Mai  12:24 EURO_2016-2017_OL_004.pdf
und lösche dann die .nfs-Dateien, dann sind sie auch gelöscht.

Nun versetehe das nicht, mir gefällt das nicht und ich möchte wissen:
- wo diese Dateien herkommen
- warum sie über den Client mit dem Nutzer holger mit UID 1000 und GID 5000 nicht löschbar sind
- aber mit dem Nutzer holger UID 1000 und GID 5000 auf dem Server löschbar sind.

Hat da noch jemand eine Idee?

Viele Grüße,
Holger
 
Und es geht weiter:
Im Terminal vom Server aus:
Code:
sof .nfs.7ffbe981.04b34.4
lsof: WARNING: compiled for FreeBSD release 11.0-RELEASE-p11; this is 11.0-RELEASE-p9.

Alles ist up-to-date per freebsd-update fetch && install und auch per pkg update && upgrade.
Code:
uname -a
FreeBSD taschenmaus.unix.pc 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11 08:48:40 UTC 2017     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

Code:
freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 11.0-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 11.0-RELEASE-p11.

Was habe ich nun, ein 11.0-p9 oder 11.0-p11? Mehr als alles mit den gängigen Werkzeugen aktuell halten kann ich hier nicht. Ich weiß, dass 11.1 mittlerweile draußen ist, aber bis zum Support-Ende muss doch mit 11.0 so etwas funktionieren.

Und so Basis-Unix-Befehle wie lsof möchte ich schon gerne nutzen können. :D
 
Code:
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

Soll ich da mal an Stelle von "quarterly" ein "latest" reinpinseln?

Nachtrag: Hab das gerade gemacht, es wurden ein paar Pakete aktualisiert, aber auch nach einem Neustart:
Code:
[holger@taschenmaus ~]$ freebsd-version -uk
11.0-RELEASE-p9
11.0-RELEASE-p11
[holger@taschenmaus ~]$

Und wie bekomme ich nun ein korrekt arbeitendes lsof?
 
.nfs-Dateien sind Dateien, die eigtl. gelöscht, aber noch nicht geschlossen sind. Man kann ja unter UNIX eine Datei lesen und schreiben, solange ein Handle offen ist(?), auch wenn der Verzeichniseintrag schon gelöscht wurde. Über NFS muss das mit diesen Hilfsdateien erfolgen.
 
.nfs-Dateien sind Dateien, die eigtl. gelöscht, aber noch nicht geschlossen sind. Man kann ja unter UNIX eine Datei lesen und schreiben, solange ein Handle offen ist(?), auch wenn der Verzeichniseintrag schon gelöscht wurde. Über NFS muss das mit diesen Hilfsdateien erfolgen.
Das vermute ich ja auch, und daher habe ich schon versucht, ein lsof /pfad-zur-.nfs.datei auszuführen, was wie oben erwähnt nicht geht.

Ich bin gerade dabei, den Server auf 11.1 hoch zu ziehen, dann geht hoffentlich lsof wieder und ich werde mich hier wieder melden.
 
Das vermute ich ja auch, und daher habe ich schon versucht, ein lsof /pfad-zur-.nfs.datei auszuführen, was wie oben erwähnt nicht geht.

Ich bin gerade dabei, den Server auf 11.1 hoch zu ziehen, dann geht hoffentlich lsof wieder und ich werde mich hier wieder melden.

Irgendein Prozess auf dem Client hat die Dateien noch geöffnet. Da bringt es nichts, auf dem Server lsof zu machen. NFS muss die Dateien aus dem Tree "entfernen", aber den Inhalt noch bereithalten für den Prozess, der auf dem Client läuft. Client und Server teilen sich aber nicht die Handles in dem Sinne, dass der Server weiß, welcher Clientprozess noch was offen hat.
 
Du kannst auch fstat nehmen. Das ist etwas robuster.
Habe ich gemacht, danke Dir und zwar
Irgendein Prozess auf dem Client hat die Dateien noch geöffnet. Da bringt es nichts, auf dem Server lsof zu machen.
wie @TCM sagte, auf dem Client. Und der Schuldige heißt:
baloo

So ein Mist, sonst deaktiviere ich den immer, aber diesmal habe ich das wohl schlichtweg vergessen.

Dennoch habe ich etwas gelernt zu nfs, was es mit .nfs-Dateien auf sich hat und den Befehl fstat.

Vielen Dank für Eure Hinweise und Hilfen.

Achso, die Ausgabe von fstat auf dem Client bei einer betroffnen Datei:
Code:
fstat KJP_01.wav
USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W NAME
holger   baloo_file  1164  481 /usr/home/holger/nas   3473 -rw-rwxr-x  192914400  r  KJP_01.wav

Viele Grüße
Holger
 
das hat mit KDE nix zu tun. Auch über ein Terminal vom Client aus lässt sich .nfsblablub zwar löschen, erscheint aber sofort wieder.
mir würde das als Ausschlussverfahren nicht genügen (wenn ich deine Handlung richtig deute). So lange KDE noch läuft und irgendwas daraus die Dateien mit Beschlag belegt, kannst du das so nicht eindeutig ausschließen.
 
mir würde das als Ausschlussverfahren nicht genügen (wenn ich deine Handlung richtig deute). So lange KDE noch läuft und irgendwas daraus die Dateien mit Beschlag belegt, kannst du das so nicht eindeutig ausschließen.
Hah, einioge Sekunden zu spät, :D aber Du hast Recht, es lag an baloo von KDE auf dem Client.
 
<klugscheissmodus>
diese DEs wie KDE & Co. machen ein System undurchsichtig. Der Nutzen steht in keinem vernünftigen Verhältnis zu den Nachteilen, wie wir am aktuellen Beispiel hier sehen.
Mit find im Terminal bin ich fast genauso schnell, wie irgend ein grafisches Teil, dass dann in ner Datenbank die von Baloo mühsam zusammengesuchten und gespeicherten Indizes abgreift!
</klugscheissmodus>

Aber ein schöner Nebeneffekt ist doch, dass Du jetzt bei 11.1 angekommen bist:D
 
Hallo Walter,

ich verstehe Deine Einwände gut - ja, so etwas wie baloo kann nerven (und auch KDE-Fans sind von so etwas teilweise genervt).
Aber ein schöner Nebeneffekt ist doch, dass Du jetzt bei 11.1 angekommen bist
Ja, und der Lerneffekt, was .nfs-Dateien angeht, kommt noch dazu.

Aber: Immerhin kann man baloo deaktivieren.
 
balooctl disable ist dein Freund :) -- kannst aus selektiv Ordner deaktivieren (und ev auch auf polling umstellen).

Aber ist weniger baloo's Schuld, als dass Filemonitoring unter FreeBSD einfach schlecht ist, da die Dateien dafür geöffnet werden müssen.
 
balooctl disable ist dein Freund

Hallo Tobias,

danke, das ist eine elegante Lösung (ich habe vorhin schon in den Systemsettings die Datei-Indizierung deaktiviert, bewirkt das das gleiche?)

Aber ist weniger baloo's Schuld, als dass Filemonitoring unter FreeBSD einfach schlecht ist, da die Dateien dafür geöffnet werden müssen.
Ah verstehe, das wirkt sich dann unter Linux anders aus, als unter FreeBSD.

Wobei Kritik an baloo erst neulich wieder auf pro-linux Thema war:
http://www.pro-linux.de/news/1/24921/comm/608833/baloo.html

Ich fände ja schön, wenn das Teil nicht standardmäßig aktiviert würde. Aber es gibt wohl auch Nutzer, bei denen baloo im Großen und Ganzen ordentlich funktioniert.

Davon abgesehen würde ich wegen baloo nicht KDE aufgeben. Dafür hat es viel zu viele Sachen, die mir sehr gut gefallen.

Aber dennoch finde ich Einwände wie die von @Vril wichtig (wobei hier wohl auch das Zusammenspiel von baloo und speziell FreeBSD wegen dessen Filemonitorings nicht so optimal zu sein scheint).

baloo kann man nicht zufällig durch bestimmte Options beim Bau mit poudriere loswerden?
 
Nein, baloo wirst du nicht los :)

Wenn er funktinoniert ist es ja auch ein feines Feature -- man muss ihm halt einfach teils explizit unter die Arme greifen und sagen dass er ~/mein_fancy_nfs_mount nicht indizieren/überwachen soll, sofern man beabsichtigt das regelmässig zu unmounten.

Eine Gefahr ist ja auch, dass man an die Grenze der openfiles kommt -- da muss man kern.maxfiles manuell hochsetzen -- oder sich wundern warum nix neues mehr starten will =)
 
mal was Anderes.
Es ging ja hier um das korrekte mounten der NFS-Greigaben.
Im Eingangsthread wurde dann eine exports gezeigt, die für die Freigaben verantwortlich ist. Ich nutze auch eine exports und habe noch nicht weiter darüber nachgedacht, aber gelesen, dass man das mit ZFS nicht mehr braucht. Vermutlich kann man Datasets direkt die Eigenschaft mitgeben, dass sie exportiert werden.
Vielleicht sollte man mal darüber nachdenken und Vor- und Nachteile abwägen. Ich denke dabei auch an das Script zu FreeBSD von holgerw.

Also anders herum gefragt: wie exportiert man denn eigentlich NFS-Shares korrekt mit ZFS?
 
zfs set sharensf
( und die dann folgenden Optionen sind der Syntax von der bekannten 'exports' ziemlich ähnlich )

'zfs set sharensf' sollte sich Holger auch mal anschauen
 
Das macht nichts Anderes, als eine exports zu generieren, die dann auch nur von mountd reingezogen wird. /etc/zfs/exports müsste das sein.
 
Ein zfs set sharenfs macht zwar auch nichts anderes els eine exports-Datei zu generieren, dafür gehen Änderungen on-the-fly ohne einen Daemo neu zu starten.
Leider kann man da pro Dataset nur eine Zeile generieren.
 
Zurück
Oben