RESTIC: Mounting unter FreeBSD 13.1 führt zu einer >>resource temporarily unavailable<<-Meldung.

[testit]

Hallo allerseits,

bei meiner Suche nach einer Backup-Lösung für FreeBSD bin ich auf restic gestoßen.

Ich habe restic auf FreeBSD 13.1 (13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC amd64) installiert und auch ein erstes Backup erstellt.
Danach wollte ich das Repository mounten, aber ich erhalte die Fehlermeldung "resource temporarily unavailable".

Was könnte der Grund dafür sein?

Anscheinend war dies auch schon einmal ein Thema hier:

fuse lib is broken on recent FreeBSD · Issue #280 · bazil/fuse

A recent change to FreeBSD has broken apps using the bazil.org/fuse lib. As of the following commit to the FreeBSD FUSE driver: CURRENT: https://cgit.freebsd.org/src/commit/?id=7b8622fa220b9c080411...

github.com

und

265736 – [FUSEFS] fuse(4) reports error on F_SETFL, O_RDWR|O_NONBLOCK but still sets the device in non-blocking mode

bugs.freebsd.org

Da das schon einige Zeit her ist, kann ich mir nicht vorstellen, dass dieses Problem nicht schon längst gelöst wurde.
Gibt es etwas Bestimmtes, das ich beachten muss? Mache ich etwas falsch?

Danke und viele Grüße
testit

 

[xbit]

Moin,

es wird dein Problem nicht lösen, aber bei mir verhält es sich genauso unter FreeBSD 13.2.

Ansonsten kann ich aber restic sehr empfehlen, auch wenn der Restore ohne fuse vielleicht etwas weniger bequem ist.

Nur der vollständigkeithalber: ich habe restic 0.15.2 laufen und hab natürlich das Kernelmoduls fusefs geladen.

Grüße
xbit

 

[testit]

Hallo xbit,

vielen Dank für den Hinweis!

Der Maintainer hat auf meine Anfrage reagiert und will sich freundlicherweise des Problems annehmen.

Er schreibt aber auch "Have you tried mounting fusefs outside restic?".

Das habe ich noch nicht getan und müsste mir erst einmal anschauen, was diesbezüglich zu tun ist.


Viele Grüeß
testit

 

[Andy_m4]

13.1-RELEASE-p2

Hat zwar nix mit Deinem Problem zu tun, aber die aktuelle Iteration von 13.1 ist 13.1p8
Außerdem wird die 13.1 demnächst aus dem Support rausrutschen.

Er schreibt aber auch "Have you tried mounting fusefs outside restic?"

Ich bin auch gerade am überlegen, was damit gemeint ist. Ich würde es erst mal so lesen, das Du mal ein anderes FUSE-Dateisystem testen sollst. Vermutlich um zu gucken, ob das generell bei Dir funktioniert.

Der Maintainer hat auf meine Anfrage reagiert und will sich freundlicherweise des Problems annehmen.

Ok.
Ich fänd' es prima, wenn Du hinterher auch schreibst, wie die Sache ausgegangen ist.

 

[testit]

Hallo Andy_m4,

danke für den Hinweis auf p8!

Selbstverständlich werde ich hier berichten, sobald ich eine weitere Rückmeldung erhalte.

Unter FreeBSD 14 (aktueller Entwicklungsstand) geht es lt. Mitteilung des o. a. Maintainers ebenfalls nicht.


Viele Grüße
testit

 

[Andy_m4]

Unter FreeBSD 14 (aktueller Entwicklungsstand) geht es lt. Mitteilung des o. a. Maintainers ebenfalls nicht.

Ja. Und FreeBSD 14 ist zwar schon am Horizont zu sehen aber ein paar Monate dauert es ja doch noch, bis es "released" wird. Ich bin mir aber relativ sicher, das es kein großes Problem sein wird das auf 13 zurück zu portieren.
Können wir ja machen, sobald die Änderungen verfügbar sind.

 

[testit]

Hallo,

wie versprochen, halte ich Euch in dieser Sache auf dem Laufenden:

Nuno T. hat mir eben geschrieben, dass das Problem, welches übrigens nichts mit "fuse" zu tun habe, sondern ein FreeBSD-Bug gewesen sei, gelöst ist und verweist u. a. auf

os: recent FreeBSD update to sys/fusefs to allow kevents breaks go polling model · Issue #54100 · golang/go

What version of Go are you using (go version)? $ go version go version go1.18.4 freebsd/amd64 Does this issue reproduce with the latest release? Yes, but it's dependent on the FreeBSD release. i.e....

github.com

"This will be MFC to STABLE in about 2 weeks."

Allerdings verstehe ich das so, dass das nur in FreeBSD 14 gefixed sein wird, was ich schade fände.


Viele Grüße
testit

 

[Andy_m4]

welches übrigens nichts mit "fuse" zu tun habe, sondern ein FreeBSD-Bug gewesen sei,

Ok. Gut zu wissen.

Allerdings verstehe ich das so, dass das nur in FreeBSD 14 gefixed sein wird

Davon würde ich erst mal ausgehen.
Ich hab aber schon mal ein Blick auf den Patch geworfen. Der sollte auch auf FreeBSD 13.2 funktionieren.
Wenn Du Dir prinzipiell zutraust den Kernel zu kompilieren, dann könnte ich Dir schreiben was Du tun musst, um den Patch bei Dir einzuspielen. Sind eigentlich auch gar nicht so viele Schritte. Das wird jetzt keine Doktorarbeit oder so, sondern ist eigentlich eher easy-going.

 

[testit]

Netterweise gab es auch zeitnah eine Antwort auf meine Nachfrage wg. FreeBSD 13.X:

It will be MFCed to 13-STABLE and then included in next 14.0 (October 2023) and in 13.3 (if plans for this release to happen)

Gruß
testit

 

[Andy_m4]

wg. FreeBSD 13.X

Ja. Gut zu wissen, das es nach 13.x reinwandern wird. Allerdings wird Version 13.3 deutlich später erscheinen als FreeBSD 14. Insofern nützt einem das nicht viel, wenn man es zeitnah haben möchte.

Ich hab übrigens den Patch auf 13.2 mal getestet und er scheint zu funktionieren. Ich würde jetzt trotzdem noch mal das Review abwarten, aber eigentlich dürfte da nix mehr bei rum kommen.
Der Patch sollte auch auf 13.1 laufen. Allerdings ist 13.1 ohnehin Ende diesen Monats End-of-Life.

 

[peterle]

AMANDA ... mehr sag ich nicht.

 

[Andy_m4]

Läuft hier problemlos.
Wer den Patch (Review-Status: https://reviews.freebsd.org/D40955 ) selbst bei sich auf FreeBSD 13.2 installieren will, braucht dazu aber die Quellen.
Üblicherweise packt man die unter /usr/src/ (im Prinzip kann man aber auch ein anderes Verzeichnis nehmen).
Die Vorgehensweise ist so ähnlich, wie sie auch im Handbuch beschrieben steht.

Erstmal holt man sich die Quellen:
git clone -o freebsd -b releng/13.2 --depth 1 https://git.freebsd.org/src.git /usr/src
(siehe auch: https://docs.freebsd.org/en/books/handbook/mirrors/#git-install)

Dann muss man die betroffene Datei /usr/src/sys/kern/kern_descrip.c patchen. Die Vorlage dafür findet man ja ebenfalls im FreeBSD-git-Repository:
https://cgit.freebsd.org/src/commit/?id=6c049996ec29bad4a913b019a28f211ab84b0d3d
Den kann man so direkt nicht nehmen, weil die kern_descrip.c in Version 13.2p1 ein bisschen anders aussieht. Da braucht man einen entsprechend angepassten Patch:

--- kern_descrip.c    2023-07-16 18:04:05.879784000 +0200
+++ kern_descrip.c    2023-07-16 18:01:03.294057000 +0200
@@ -483,7 +483,7 @@
     struct vnode *vp;
     struct mount *mp;
     struct kinfo_file *kif;
-    int error, flg, kif_sz, seals, tmp;
+    int error, flg, kif_sz, seals, tmp, got_set, got_cleared;
     uint64_t bsize;
     off_t foffset;
 
@@ -561,11 +561,12 @@
             tmp &= ~FCNTLFLAGS;
             tmp |= FFLAGS(arg & ~O_ACCMODE) & FCNTLFLAGS;
         } while (atomic_cmpset_int(&fp->f_flag, flg, tmp) == 0);
+        got_set = tmp & ~flg;
+        got_cleared = flg & ~tmp;
         tmp = fp->f_flag & FNONBLOCK;
         error = fo_ioctl(fp, FIONBIO, &tmp, td->td_ucred, td);
         if (error != 0) {
-            fdrop(fp, td);
-            break;
+            goto revert_f_setfl;
         }
         tmp = fp->f_flag & FASYNC;
         error = fo_ioctl(fp, FIOASYNC, &tmp, td->td_ucred, td);
@@ -576,6 +577,13 @@
         atomic_clear_int(&fp->f_flag, FNONBLOCK);
         tmp = 0;
         (void)fo_ioctl(fp, FIONBIO, &tmp, td->td_ucred, td);
+revert_f_setfl:
+        do {
+            tmp = flg = fp->f_flag;
+            tmp &= ~FCNTLFLAGS;
+            tmp |= got_cleared;
+            tmp &= ~got_set;
+        } while (atomic_cmpset_int(&fp->f_flag, flg, tmp) == 0);
         fdrop(fp, td);
         break;

Den tut man in ne beliebige Datei z.B. mit dem Namen kern_descrip.c.patch und dann kann man den dann problemlos anwenden:
cd /usr/src patch sys/kern/kern_descrip.c /path/to/kern_descrip.c.patch
(Manpage von patch)

Nun muss man nur noch den Kernel kompilieren und entsprechend installieren:
make buildkernel make installkernel reboot
(Manpage zum Build mit make)

Man kann bei make auch den Schalter -j angeben, um mehrere Compile-Jobs parallel ausführen zu lassen. Je nachdem, wie viel / wie intensiv man die Kerne man beschäftigen will:
make -j 4 buildkernel