Re: More unionfs madness

> Date: Mon, 01 Aug 2005 18:17:12 +0200
> From: Dario Freni <saturnero_at_freesbie.org>
> Sender: owner-freebsd-current_at_freebsd.org
> 
> Background:
> - Read-only compressed partition mounted on /var
> - Memory fs created on /mnt/union/var (using mount_md function of rc.subr)
> - Created the directory structure on the memory fs
> - mount_unionfs -o noatime /mnt/union/var /var (noatime is a suggested
> workaround for a bug I've already found, see fs_at_ archive)
> 
> I'm getting panic during the init phase, when newsyslog script is called:
> 
> Creating and/or trimming log files:panic: lockmgr: locking against myself
> cpuid = 0
> KDB: enter: panic
> [thread pid 231 tid 100051 ]
> Stopped at      kdb_enter+0x2b: nop
> db> tr
> Tracing pid 231 tid 100051 td 0xc1470480
> kdb_enter(c08a550b) at kdb_enter+0x2b
> panic(c08a397e,c1470480,0,c0913fa0,c840a990) at panic+0x127
> lockmgr(c1917058,2002,c191707c,c1470480,c840a970) at lockmgr+0x3da
> vop_stdlock(c840a990,2,c1917000,c840a9ac,c06cb648) at vop_stdlock+0x1e
> VOP_LOCK_APV(c0905ae0,c840a990) at VOP_LOCK_APV+0x87
> vn_lock(c1917000,2,c1470480,0,13) at vn_lock+0xa8
> union_allocvp(c840ac2c,c1455800,c1878550,c17f2990,c840ac40) at
> union_allocvp+0x25b
> union_lookup(c840ab38,c1878550,0,c840ab54,c06ba68a) at union_lookup+0x627
> VOP_LOOKUP_APV(c0905ae0,c840ab38) at VOP_LOOKUP_APV+0x87
> lookup(c840ac18,c1458044,0,c1470480,12b) at lookup+0x3d6
> namei(c840ac18,1,0,c09861e8,c0985b30) at namei+0x35a
> kern_rename(c1470480,bfbfb730,8051100,0,c840ad30) at kern_rename+0xf4
> rename(c1470480,c840ad04,2,1c,80296) at rename+0x15
> syscall(3b,3b,3b,3,bfbfb730) at syscall+0x22f
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (128, FreeBSD ELF32, rename), eip = 0x280bbd47, esp =
> 0xbfbfb70c, ebp = 0xbfbfbba8 ---
> db>
> 
> In know that unionfs is totally broken atm, but when will this be fixed?
>  The unusability of unionfs is a step back for my project.

I don't know about "totally broken" I use unionfs regularly on my system
and it's been fine. I'll admit that the use (profile) is fairly
straight-forward, but it's given me no problems.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634