Date: Fri, 13 May 2011 22:10:52 +0100 From: Johannes Totz <jtotz@imperial.ac.uk> To: freebsd-fs@freebsd.org Subject: Re: fusefs broken on 8-stable? Message-ID: <iqk6os$3ui$1@dough.gmane.org> In-Reply-To: <20110513131902.GA34738@tops> References: <iqj9pf$mrn$1@dough.gmane.org> <20110513131902.GA34738@tops>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13/05/2011 14:19, Gleb Kurtsou wrote: > On (13/05/2011 13:56), Johannes Totz wrote: >> Heya! >> >> Using encfs (built on top of fuse) gives me panics in combination with >> rsync. Dump didn't succeed. The info below is transcribbled from a >> photograph. This is repeatable. >> Without dump this is probably not very helpful.... > > As far as I know there is memory corruption. But this particular case > looks like VFS bug in fuse. > > I'd appreciate if you give native FreeBSD kernel level cryptographic > filesystem PEFS a try: > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/156002 -- port > http://wiki.freebsd.org/PEFS > https://github.com/glk/pefs Looks interesting... I was relying on encfs's reverse-mode though: given a plaintext directory, it provides an encrypted view on-the-fly which I was rsync'ing to other file servers. >> # uname -a >> FreeBSD XXX 8.2-STABLE FreeBSD 8.2-STABLE #1: Thu Mar 10 23:30:08 GMT >> 2011 root@XXX:/usr/obj/usr/src/sys/GENERIC amd64 >> >> >> >> First panic (top bits scrolled off screen): >> >> trap number = 12 >> panic: page fault >> cpuid = 0 >> KDB: stack backtrace >> #0 ... kbd_backtrace+0x5c >> #1 ... panic+0x1b4 >> #2 ... trap_fatal+0x394 >> #3 ... trap_pfault+0x252 >> #4 ... trap+0x3f4 >> #5 ... calltrap+0x8 >> #6 ... fdisp_make+0xe4 >> #7 ... fuse_lookup+0x1dc >> #8 ... VOP_LOOKUP_APV+0x4c >> #9 ... at lookup+0x61e >> #10 ... at namei+0x592 >> #11 ... at vn_open_cred+0x339 >> #12 ... at vn_open+0x1c >> #13 ... at kern_openat+0x152 >> #14 ... at kern_open+0x19 >> #15 ... at open+0x18 >> #16 ... at syscallenter+0x2d9 >> #17 ... at syscall+0x38 >> >> >> >> Second panic: >> >> >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 17 (vnlru) >> trap number = 12 >> panic: page fault >> cpuid = 0 >> KDB: stack backtrace >> #0 ... at kdb_backtrace+0x5c >> #1 ... at panic+0x1b4 >> #2 ... at trap_fatal+0x394 >> #3 ... at trap_pfault0x252 >> #4 ... at trap+0x3f4 >> #5 ... at calltrap+0x8 >> #6 ... at fdisp_make_pid+0xc7 >> #7 ... at fuse_send_forget+0x44 >> #8 ... at fuse_recyc_backend+0xb2 >> #9 ... at VOP_RECLAIM_APV+0x49 >> #10 ... at vgonel+0x1b7 >> #11 ... at vnlru_proc+0x591 >> #12 ... at fork_exit+0x121 >> #13 ... at fork_trampoline+0xe >> >> >> >> Any idea what could be going on? >> >> >> Johannes
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?iqk6os$3ui$1>