Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Jacques Marneweck ha scritto: Danny Braniss wrote: Daichi GOTO wrote: All folks have interests in improved unionfs should keep attentions and ask how about merge? at every turn :) OK. How about a merge? I'd really like to see this in 6-STABLE. Regards, Jan Mikkelsen. just a 'me too'. I've been running with the patch(under 6.1) and it's definitely better than the panics with the unpatched version. in other words, IMHO, it does not break anything, and it actualy fixes somethings. danny Any ETA to when we can see this merged into 6.1 and 5.5? This patchset doesn't apply in 5.x branch. The unionfs code of 5.x is different and afaik is working quite well (we used it on freesbie 1.1 without problems). Cheers, -- Dario Freni ([EMAIL PROTECTED]) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc signature.asc Description: OpenPGP digital signature
Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
On Wed, Mar 15, 2006 at 06:25:33PM +0900, Daichi GOTO wrote: I have updated the patchset-9 of unionfs. Another panic, this time from umount -f: panic: union_lock: wrong vnode (un == null) db wh Tracing pid 17750 tid 100151 td 0xc7c38a20 kdb_enter(c07273ef,2,c0720d69,ee2d2aa0,c7c38a20) at kdb_enter+0x30 panic(c0720d69,c0599f59,c0599bef,ee2d2ab8,c07605c0) at panic+0x13f union_lock(ee2d2afc,0,0,2002,ca29ed20) at union_lock+0x68 VOP_LOCK_APV(c07605c0,ee2d2afc,ca29ede8,c6643488,8d3) at VOP_LOCK_APV+0xa6 vn_lock(ca29ed20,2002,c7c38a20,8d3,c6643488) at vn_lock+0xd3 vflush(c6643400,1,2,c7c38a20,c666bd80) at vflush+0x186 unionfs_unmount(c6643400,808,c7c38a20,c7c38a20,0) at unionfs_unmount+0x54 dounmount(c6643400,808,c7c38a20,415,800ff05) at dounmount+0x338 unmount(c7c38a20,ee2d2d04,c074769a,3ed,c69ea738) at unmount+0x270 syscall(3b,3b,3b,804a625,a000aa1) at syscall+0x2ea Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280c54c3, esp = 0xbfbfe44c, ebp = 0xbfbfe508 --- db show lockedvnods Locked vnodes 0xc7347d20: tag ufs, type VLNK usecount 0, writecount 0, refcount 1 mountedhere 0 flags () lock type ufs: EXCL (count 1) by thread 0xc692c360 (pid 17230)#0 0xc05274eb at lockmgr+0x587 #1 0xc0594a97 at vop_stdlock+0x32 #2 0xc06fda82 at VOP_LOCK_APV+0xa6 #3 0xc066b4a1 at ffs_lock+0x19 #4 0xc06fda82 at VOP_LOCK_APV+0xa6 #5 0xc05ad540 at vn_lock+0xd3 #6 0xc059f500 at vrele+0x149 #7 0xc04ef97f at union_hashrem+0x28c #8 0xc04f4257 at union_reclaim+0x1b #9 0xc06fd958 at VOP_RECLAIM_APV+0xc4 #10 0xc05a02cc at vgonel+0x1b2 #11 0xc059cd48 at vtryrecycle+0x135 #12 0xc059c64b at vnlru_free+0x18e #13 0xc059cdce at getnewvnode+0x47 #14 0xc066a126 at ffs_vget+0xfc #15 0xc0671b7b at ufs_lookup+0xb83 #16 0xc06fb53d at VOP_CACHEDLOOKUP_APV+0xc4 #17 0xc0592219 at vfs_cache_lookup+0xcb ino 297887, on dev da0s1e 0xcb5d52a0: tag ufs, type VDIR usecount 3, writecount 0, refcount 6 mountedhere 0 flags () v_object 0xc8fa2d20 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc692c360 (pid 17230)#0 0xc05274eb at lockmgr+0x587 #1 0xc0594a97 at vop_stdlock+0x32 #2 0xc06fda82 at VOP_LOCK_APV+0xa6 #3 0xc066b4a1 at ffs_lock+0x19 #4 0xc06fda82 at VOP_LOCK_APV+0xa6 #5 0xc05ad540 at vn_lock+0xd3 #6 0xc0596ba5 at lookup+0xe5 #7 0xc05967f9 at namei+0x434 #8 0xc05a69c6 at kern_lstat+0x4f #9 0xc05a6951 at lstat+0x2f #10 0xc06e4c52 at syscall+0x2ea #11 0xc06cebef at Xint0x80_syscall+0x1f ino 3044707, on dev da0s1e 0xc6d66540: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0xc6643400 flags () lock type ufs: EXCL (count 1) by thread 0xc7c38a20 (pid 17750)#0 0xc05274eb at lockmgr+0x587 #1 0xc0594a97 at vop_stdlock+0x32 #2 0xc06fda82 at VOP_LOCK_APV+0xa6 #3 0xc066b4a1 at ffs_lock+0x19 #4 0xc06fda82 at VOP_LOCK_APV+0xa6 #5 0xc05ad540 at vn_lock+0xd3 #6 0xc0599c72 at dounmount+0x51 #7 0xc0599bef at unmount+0x270 #8 0xc06e4c52 at syscall+0x2ea #9 0xc06cebef at Xint0x80_syscall+0x1f ino 612352, on dev da0s1d 0xca29ed20: tag unionfs, type VLNK usecount 0, writecount 0, refcount 2 mountedhere 0 flags (VI_DOOMED) VI_LOCKed lock type unionfs: EXCL (count 1) by thread 0xc692c360 (pid 17230)#0 0xc05274eb at lockmgr+0x587 #1 0xc04ef789 at union_hashrem+0x96 #2 0xc04f4257 at union_reclaim+0x1b #3 0xc06fd958 at VOP_RECLAIM_APV+0xc4 #4 0xc05a02cc at vgonel+0x1b2 #5 0xc059cd48 at vtryrecycle+0x135 #6 0xc059c64b at vnlru_free+0x18e #7 0xc059cdce at getnewvnode+0x47 #8 0xc066a126 at ffs_vget+0xfc #9 0xc0671b7b at ufs_lookup+0xb83 #10 0xc06fb53d at VOP_CACHEDLOOKUP_APV+0xc4 #11 0xc0592219 at vfs_cache_lookup+0xcb #12 0xc06fb43b at VOP_LOOKUP_APV+0xa6 #13 0xc0596f3a at lookup+0x47a #14 0xc05967f9 at namei+0x434 #15 0xc05a69c6 at kern_lstat+0x4f #16 0xc05a6951 at lstat+0x2f #17 0xc06e4c52 at syscall+0x2ea Kris pgpnhadU96tBP.pgp Description: PGP signature
Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Kris Kennaway wrote: On Wed, Mar 15, 2006 at 06:25:33PM +0900, Daichi GOTO wrote: I have updated the patchset-9 of unionfs. Another panic, this time from umount -f: Thanks for your reports, Kris. OKay, we'll try to fix those panic problems when we have time :) -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Daichi GOTO wrote: All folks have interests in improved unionfs should keep attentions and ask how about merge? at every turn :) OK. How about a merge? I'd really like to see this in 6-STABLE. Regards, Jan Mikkelsen. just a 'me too'. I've been running with the patch(under 6.1) and it's definitely better than the panics with the unpatched version. in other words, IMHO, it does not break anything, and it actualy fixes somethings. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Danny Braniss wrote: Daichi GOTO wrote: All folks have interests in improved unionfs should keep attentions and ask how about merge? at every turn :) OK. How about a merge? I'd really like to see this in 6-STABLE. Regards, Jan Mikkelsen. just a 'me too'. I've been running with the patch(under 6.1) and it's definitely better than the panics with the unpatched version. in other words, IMHO, it does not break anything, and it actualy fixes somethings. danny Any ETA to when we can see this merged into 6.1 and 5.5? Regards --jm -- Jacques Marneweck http://www.powertrip.co.za/blog/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Danny Braniss [EMAIL PROTECTED] wrote: I'd really like to see this in 6-STABLE. just a 'me too'. I've been running with the patch(under 6.1) and it's definitely better than the panics with the unpatched version. in other words, IMHO, it does not break anything, and it actualy fixes somethings. Compare the mount options the current implementation and the completely rewritten implementation of unionfs is able to understand. There is a difference. Since it would break a documented interface, we can't MFC it. Except maybe you can prove that the option in question doesn't work at all, and therefore isn't used anywhere. Then we could MFC it, since we wouldn't break something for someone. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Being a mime means never having to say you're sorry. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Jacques Marneweck wrote: Danny Braniss wrote: Daichi GOTO wrote: All folks have interests in improved unionfs should keep attentions and ask how about merge? at every turn :) OK. How about a merge? I'd really like to see this in 6-STABLE. Regards, Jan Mikkelsen. just a 'me too'. I've been running with the patch(under 6.1) and it's definitely better than the panics with the unpatched version. in other words, IMHO, it does not break anything, and it actualy fixes somethings. danny Any ETA to when we can see this merged into 6.1 and 5.5? Regards --jm Since it's not in HEAD yet, it's pretty improbable that it'll get into 5.5 and 6.1. It would be nice to get it in for 6.2 though. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
On Fri, Mar 17, 2006 at 02:04:36PM +0100, Alexander Leidinger wrote: Danny Braniss [EMAIL PROTECTED] wrote: I'd really like to see this in 6-STABLE. just a 'me too'. I've been running with the patch(under 6.1) and it's definitely better than the panics with the unpatched version. in other words, IMHO, it does not break anything, and it actualy fixes somethings. Compare the mount options the current implementation and the completely rewritten implementation of unionfs is able to understand. There is a difference. Since it would break a documented interface, we can't MFC it. Except maybe you can prove that the option in question doesn't work at all, and therefore isn't used anywhere. Then we could MFC it, since we wouldn't break something for someone. IMO there's absolutely no barrier to getting this one day merged to 6.x, since unionfs is documented to not work in any FreeBSD release since 2.x or earlier. Kris pgpPeqx9rcQ52.pgp Description: PGP signature
Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Daichi GOTO wrote: Jan Mikkelsen wrote: Daichi GOTO wrote: All folks have interests in improved unionfs should keep attentions and ask how about merge? at every turn :) OK. How about a merge? I'd really like to see this in 6-STABLE. Me too, but unfortunately it is difficult with some reasons (detail information http://people.freebsd.org/~daichi/unionfs/). Of course, our patch gives the conditions for integration of -current OK. For -stable is BAD. We must keep the API compatibility of command/library for integration of -stable. With some technical/specifical reasons, our improved unionfs has a little uncompatibility. For the last time, integration of -stable will be left to the judgment of src committers and others. Regards, Jan Mikkelsen. Right now, unionfs is somewhat usable for read-only purposes. As long as your work doesn't alter or break the behaviour of read-only mounts, I think it's very much ready to go into CVS. From there it can get wider testing and review and be considered for 6-stable. Since read-write support in the existing code is pretty much worthless, I don't think that there will be a problem justifying the operational changes that you describe in your documentation. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Daichi GOTO wrote: All folks have interests in improved unionfs should keep attentions and ask how about merge? at every turn :) OK. How about a merge? I'd really like to see this in 6-STABLE. Regards, Jan Mikkelsen. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
As a side note. I'm quietly using the patchset and the stability has never been so good as with those patches. Over the years I have tried to use unionfs to mount /usr/ports and /usr/src over NFS while the objects files stayed local at the client side. I was never able to do a complete build, without a crash. With this patchset I haven't had a single crash, even on SMP systems. Lots of kudos for the work -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Long Sent: Thursday, March 16, 2006 1:36 PM To: Daichi GOTO Cc: Jan Mikkelsen; [EMAIL PROTECTED]; freebsd-hackers@freebsd.org; [EMAIL PROTECTED]; freebsd-current@freebsd.org; 'Mars G. Miro' Subject: Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010) Daichi GOTO wrote: Jan Mikkelsen wrote: Daichi GOTO wrote: All folks have interests in improved unionfs should keep attentions and ask how about merge? at every turn :) OK. How about a merge? I'd really like to see this in 6-STABLE. Me too, but unfortunately it is difficult with some reasons (detail information http://people.freebsd.org/~daichi/unionfs/). Of course, our patch gives the conditions for integration of -current OK. For -stable is BAD. We must keep the API compatibility of command/library for integration of -stable. With some technical/specifical reasons, our improved unionfs has a little uncompatibility. For the last time, integration of -stable will be left to the judgment of src committers and others. Regards, Jan Mikkelsen. Right now, unionfs is somewhat usable for read-only purposes. As long as your work doesn't alter or break the behaviour of read-only mounts, I think it's very much ready to go into CVS. From there it can get wider testing and review and be considered for 6-stable. Since read-write support in the existing code is pretty much worthless, I don't think that there will be a problem justifying the operational changes that you describe in your documentation. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
I have updated the patchset-9 of unionfs. Patchset-9: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p9.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p9.diff Changes in unionfs-p9.diff - Now you can use unionfs with nullfs. To fix the problem, We fixed the rock-treatment of src/sys/fs/nullfs/null_vnops.c The documents of those unionfs patches: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) The patchset-9 is important step for merging to FreeBSD 7-current. You can use improved unionfs and nullfs together. This is a goot step for all of us. Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
I have updated the patchset-9 of unionfs. Patchset-9: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p9.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p9.diff Changes in unionfs-p9.diff - Now you can use unionfs with nullfs. To fix the problem, We fixed the rock-treatment of src/sys/fs/nullfs/null_vnops.c The documents of those unionfs patches: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) The patchset-9 is important step for merging to FreeBSD 7-current. You can use improved unionfs and nullfs together. This is a goot step for all of us. Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Mars G. Miro wrote: Daichi-san, I have updated the patchset-9 of unionfs. We've been using an in-house LiveCD toolkit that uses unionfs (where cd9660 is the lower layer) and all I can say is that these patches are very important, at least on = 6.X, otherwise things would just not work. I believe the FreeSBIE folks also went thru the same experience as they also do this (cd9960 lower, unionfs upper). I have tried your p8-patchset diffs for about 2 weeks now and It Works (TM). Will try your p9 diffs soon ;-) Good. Will these diffs remain to be diffs or do people think that these will be integrated into the sources sometime? It is depending on src committer's intentions. I am a ports committer. I want to merge it into -current and I think it is getting ripe for integrating into -current. The patchset-9 already has enough quality for merge. All folks have interests in improved unionfs should keep attentions and ask how about merge? at every turn :) -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Jan Mikkelsen wrote: Daichi GOTO wrote: All folks have interests in improved unionfs should keep attentions and ask how about merge? at every turn :) OK. How about a merge? I'd really like to see this in 6-STABLE. Me too, but unfortunately it is difficult with some reasons (detail information http://people.freebsd.org/~daichi/unionfs/). Of course, our patch gives the conditions for integration of -current OK. For -stable is BAD. We must keep the API compatibility of command/library for integration of -stable. With some technical/specifical reasons, our improved unionfs has a little uncompatibility. For the last time, integration of -stable will be left to the judgment of src committers and others. Regards, Jan Mikkelsen. -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
