Probleme mit rsync und sshfs

bsd4me

bsd4me

Well-Known Member
Hallo,

ich habe ein Problem, nachdem ich MooseFS erstellt habe, habe ich ein Verzeichnis in mein Dateisystem per fuse eingehängt. Alles super, nur funktioniert rsync nicht, immer core dump like:
...
current process = 1234 (rsync)
...
#0 0xffffffff808680fe at kdb_backtrace+0x5e
#1 0xffffffff80832cb7 at panic+0x187
#2 0xffffffff80b18400 at trap_fatal+0x290
#3 0xffffffff80b18749 at trap_pfault+0x1f9
#4 0xffffffff80b18c0f at trap+0x3df
#5 0xffffffff80b0313f at calltrap+0x8
#6 0xffffffff80b17cf0 at amd64_syscall+0x450
#7 0xffffffff80b03427 at Zfast_syscall+0xf7

Habe recherchiert und folgenden gefunden.
http://www.freebsd.org/cgi/query-pr.cgi?pr=167362
und ähnliches:
http://forums.pcbsd.org/showthread.php?p=104651

Hat jemand eine Idee, ob das schon behoben ist, oder einen Workaround gibt?

Das wäre super klasse!
Danke Euch! Norbert
 
FUSE in FreeBSD unter 10-CURRENT ist einfach kaputt. Es funktioniert so lala mit ntfs-3g, mit allem anderen ist die Panic nur eine Frage der Zeit. Aber dir kann geholfen werden: http://people.freebsd.org/~flo/fusefs-kmod-0.4.4.tar.bz2

Das ist eine inoffizielle Aktualisierung für sysutils/fusefs-kmod, die das Kernelmodul auf den Stand von FreeBSD 10-CURRENT bringt. Auspacken, in das Verzeichnis wechseln. Anschließend einmal "make makesum" um die Prüfsummen zu erstellen. Danach "make deinstall reinstall clean" um fusefs-kmod zu aktualisieren, das neue Modul mit "kldunload fuse && kldload fuse" laden. Zum Abschluss erst sysutils/fusefs-libs aktualisieren, danach alle Fuse-Dateisysteme neubauen. Es werden nicht mehr Dateisysteme funktionieren, aber die es tun laufen wesentlich runder als zuvor.
 
Super Danke!! Dann werde ich es doch gleich mal testen.

Und eigentlich benötige ich es nur für die sshfs anbindung zu MooseFS - wäre super, wenn dann auch der rsync laufen würde :-)

Viele Grüße, Norbert



Yamagi schrieb:
FUSE in FreeBSD unter 10-CURRENT ist einfach kaputt. Es funktioniert so lala mit ntfs-3g, mit allem anderen ist die Panic nur eine Frage der Zeit. Aber dir kann geholfen werden: http://people.freebsd.org/~flo/fusefs-kmod-0.4.4.tar.bz2

Das ist eine inoffizielle Aktualisierung für sysutils/fusefs-kmod, die das Kernelmodul auf den Stand von FreeBSD 10-CURRENT bringt. Auspacken, in das Verzeichnis wechseln. Anschließend einmal "make makesum" um die Prüfsummen zu erstellen. Danach "make deinstall reinstall clean" um fusefs-kmod zu aktualisieren, das neue Modul mit "kldunload fuse && kldload fuse" laden. Zum Abschluss erst sysutils/fusefs-libs aktualisieren, danach alle Fuse-Dateisysteme neubauen. Es werden nicht mehr Dateisysteme funktionieren, aber die es tun laufen wesentlich runder als zuvor.
Zum Vergrößern anklicken....
 
...bin dafür scheinbar ein wenig zu blöd...
Hier das was passiert, wenn ich der Anleitung folge...
(Das gleiche passiert auch unter /usr/ports/sysutils)

-- snip --
[root@HOST:fusefs-kmod-0.4.4] # pwd
/root/appl/fusefs-kmod-0.4.4

[root@HOST:fusefs-kmod-0.4.4] # make makesum
make: don't know how to make makesum. Stop

[root@HOST:fusefs-kmod-0.4.4] # make
===> sbin (all)
===> sbin/mount_fusefs (all)
Warning: Object directory not changed from original /root/appl/fusefs-kmod-0.4.4/sbin/mount_fusefs
cc -O2 -pipe -I/root/appl/fusefs-kmod-0.4.4/sbin/mount_fusefs/../mount -std=gnu99 -fstack-protector -c mount_fusefs.c
mount_fusefs.c:51:21: error: mntopts.h: No such file or directory
mount_fusefs.c:63: error: array type has incomplete element type
mount_fusefs.c:85: error: 'MOPT_STDOPTS' undeclared here (not in a function)
mount_fusefs.c:86: error: 'MOPT_END' undeclared here (not in a function)
mount_fusefs.c: In function 'main':
mount_fusefs.c:147: error: 'getmnt_silent' undeclared (first use in this function)
mount_fusefs.c:147: error: (Each undeclared identifier is reported only once
mount_fusefs.c:147: error: for each function it appears in.)
mount_fusefs.c:183: warning: implicit declaration of function 'getmntopts'
mount_fusefs.c:187: error: dereferencing pointer to incomplete type
mount_fusefs.c:187: error: increment of pointer to unknown structure
mount_fusefs.c:187: error: arithmetic on pointer to an incomplete type
mount_fusefs.c:190: error: dereferencing pointer to incomplete type
mount_fusefs.c:192: error: dereferencing pointer to incomplete type
mount_fusefs.c:194: error: dereferencing pointer to incomplete type
mount_fusefs.c:265: error: dereferencing pointer to incomplete type
mount_fusefs.c:265: error: increment of pointer to unknown structure
mount_fusefs.c:265: error: arithmetic on pointer to an incomplete type
mount_fusefs.c:266: error: dereferencing pointer to incomplete type
mount_fusefs.c:270: error: dereferencing pointer to incomplete type
mount_fusefs.c:279: error: dereferencing pointer to incomplete type
mount_fusefs.c:282: warning: implicit declaration of function 'build_iovec'
mount_fusefs.c:282: error: dereferencing pointer to incomplete type
mount_fusefs.c:288: error: dereferencing pointer to incomplete type
mount_fusefs.c:291: error: dereferencing pointer to incomplete type
mount_fusefs.c:294: error: dereferencing pointer to incomplete type
mount_fusefs.c:316: warning: implicit declaration of function 'checkpath'
mount_fusefs.c:318: warning: implicit declaration of function 'rmslashes'
mount_fusefs.c: In function 'usage':
mount_fusefs.c:441: error: dereferencing pointer to incomplete type
mount_fusefs.c:441: error: increment of pointer to unknown structure
mount_fusefs.c:441: error: arithmetic on pointer to an incomplete type
mount_fusefs.c:442: error: dereferencing pointer to incomplete type
*** [mount_fusefs.o] Error code 1

Stop in /root/appl/fusefs-kmod-0.4.4/sbin/mount_fusefs.
*** [all] Error code 1

Stop in /root/appl/fusefs-kmod-0.4.4/sbin.
*** [all] Error code 1

Stop in /root/appl/fusefs-kmod-0.4.4.
-- snip --
 
So, erste Tests waren (fast) erfolgreich - leider endete ein sehr langer rsync Lauf mit einem core dump und einem reboot des Systems... Also da ist noch eine Kleinigkeit kaputt. Versuche nun die Info zu reproduzieren, um sie dann verfügbar zu machen...

Grüße, Norbert
 
nun, es hat schon eine Weile gedauert, aber mit rdiff-backup konnte ich
einen page fault nachweisen:

May 23 14:12:47 HOST kernel: Fatal trap 12: page fault while in kernel mode
May 23 14:12:47 HOST kernel: cpuid = 0; apic id = 00
May 23 14:12:47 HOST kernel: fault virtual address = 0x64
May 23 14:12:47 HOST kernel: fault code = supervisor read data, page not present
May 23 14:12:47 HOST kernel: instruction pointer = 0x20:0xffffffff818541a4
May 23 14:12:47 HOST kernel: stack pointer = 0x28:0xffffff822d3467b0
May 23 14:12:47 HOST kernel: frame pointer = 0x28:0xffffff822d346870
May 23 14:12:47 HOST kernel: code segment = base 0x0, limit 0xfffff, type 0x1b
May 23 14:12:47 HOST kernel: = DPL 0, pres 1, long 1, def32 0, gran 1
May 23 14:12:47 HOST kernel: processor eflags = interrupt enabled, resume, IOPL = 0
May 23 14:12:47 HOST kernel: current process = 3624 (python2.7)
May 23 14:12:47 HOST kernel: trap number = 12
May 23 14:12:47 HOST kernel: panic: page fault
May 23 14:12:47 HOST kernel: cpuid = 0
May 23 14:12:47 HOST kernel: KDB: stack backtrace:
May 23 14:12:47 HOST kernel: #0 0xffffffff809208a6 at kdb_backtrace+0x66
May 23 14:12:47 HOST kernel: #1 0xffffffff808ea8be at panic+0x1ce
May 23 14:12:47 HOST kernel: #2 0xffffffff80bd8240 at trap_fatal+0x290
May 23 14:12:47 HOST kernel: #3 0xffffffff80bd857d at trap_pfault+0x1ed
May 23 14:12:47 HOST kernel: #4 0xffffffff80bd8b9e at trap+0x3ce
May 23 14:12:47 HOST kernel: #5 0xffffffff80bc315f at calltrap+0x8
May 23 14:12:47 HOST kernel: #6 0xffffffff80c687f1 at VOP_CREATE_APV+0x31
May 23 14:12:47 HOST kernel: #7 0xffffffff809604e0 at uipc_bind+0x380
May 23 14:12:47 HOST kernel: #8 0xffffffff8095a95e at kern_bind+0xde
May 23 14:12:47 HOST kernel: #9 0xffffffff8095a9d1 at sys_bind+0x41
May 23 14:12:47 HOST kernel: #10 0xffffffff80bd7ae6 at amd64_syscall+0x546
May 23 14:12:47 HOST kernel: #11 0xffffffff80bc3447 at Xfast_syscall+0xf7
May 23 14:12:47 HOST kernel: Uptime: 3h8m41s
May 23 14:12:47 HOST kernel: Automatic reboot in 15 seconds - press a key on the console to abort
May 23 14:12:47 HOST kernel: Rebooting...

bsd4me schrieb:
So, erste Tests waren (fast) erfolgreich - leider endete ein sehr langer rsync Lauf mit einem core dump und einem reboot des Systems... Also da ist noch eine Kleinigkeit kaputt. Versuche nun die Info zu reproduzieren, um sie dann verfügbar zu machen...

Grüße, Norbert
Zum Vergrößern anklicken....
 
Da ist nun natürlich die Frage, ob das Problem in FUSE liegt oder in der Zurückportierung auf 9.x liegt. In jedem Fall kommst du ohne eine Analyse nicht weiter:
1. Einen Debugkernel bauen
2. Coredumps einschalten
3. Den Dump analysieren, zumindest die Ausgabe von "bt" bräuchte man.
Da wird man dir allerdings eher auf der freebsd-fs@ Liste als hier helfen können.
 
Tja mal sehen, wieviel Zeit ich dafuer habe... da neue Hardware bald kommen wird und ich dann auch bald loslegen moechte, bleibt evtl. nur der Schritt zu Debian (evtl Ubuntu) uebrig... denn ich habe ein ungutes Gefuehl, wenn fusefs-ssh nicht rund laeuft... Denn davon wird dann die Anbindung der Clients an das MooseFS haengen... Und das wird halt den "backbone" bilden...

Aber noch habe ich nicht aufgegeben und schaue mal, wie es kommt. FreeBSD ist toll und ich mag es halt besonders...

LG Norbert


Yamagi schrieb:
Da ist nun natürlich die Frage, ob das Problem in FUSE liegt oder in der Zurückportierung auf 9.x liegt. In jedem Fall kommst du ohne eine Analyse nicht weiter:
1. Einen Debugkernel bauen
2. Coredumps einschalten
3. Den Dump analysieren, zumindest die Ausgabe von "bt" bräuchte man.
Da wird man dir allerdings eher auf der freebsd-fs@ Liste als hier helfen können.
Zum Vergrößern anklicken....
 
So, nun habe ich das ganze mal mit einem DEBUG Kernel laufen lassen... Leider hat das Kompilieren der fusefs-kmod version 0.4.4 irgendwie nicht mit DEBUG geklappt. Anhaltspunkt, wo das ganze einen Panic auslöst ist:

fuse_vnop_create 0x174

nur ist das ganze noch ein bisschen vage... Hätte gerne noch die Zeile des codes erhalten, wo es denn nun knallt...

Grüße Norbert
 
Sehe ich das richtig, dass du per ssh ein fs mountest und da drin mit rsync rummachst, obwohl rsync selbst per ssh kann?

Wozu?

Edit: Achja, MooseFS. Wer keine Probleme hat, macht sich halt welche. Vergiss meinen Einwand. :)
 
opsala... Ich weiss keinen anderen Weg, wenn ich MooseFS nutzen möchte... Hast Du was gegen Distributed Filesystems? Die Idee ist doch klasse, so finde ich.

Zur Zeit habe ich Solaris Kisten (z.B. X4540), die ich per ZFS/NFS "betriebe" - also remote per NFS... Es gibt Sachen, die sind einfach super lahm - besonders da ZFS immer synchronisiert (per default). Eine Testumgebung per MooseFS (2 Laptops, 1 alter PC) ist da schon wesentlich flotter. Und ausserdem ist das Thema Erweiterbarkeit ganz wichtig... Von daher auch der Wunsch MooseFS zu nutzen. Was ja auch gut in deiser Testumgebung läuft, nur halt ist fusefs in Kombination mit rsync mehr als "dürftig" auf einem Client...

Soweit dazu, wünsche Dir einen schönen Abend, Norbert


TCM schrieb:
Sehe ich das richtig, dass du per ssh ein fs mountest und da drin mit rsync rummachst, obwohl rsync selbst per ssh kann?

Wozu?

Edit: Achja, MooseFS. Wer keine Probleme hat, macht sich halt welche. Vergiss meinen Einwand. :)
Zum Vergrößern anklicken....
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben