Re: patchset-10 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Kris Kennaway wrote: > I get this panic with mount_unionfs -b: We cannot get the same kernel panic error. Please give us a how-to-repeat-the-same-problem in simple way. > kdb_backtrace(ebf369e8,c056b59a,c06c905a,c06e297e,c72d7000) at > kdb_backtrace+0x29 > vfs_badlock(c06c905a,c06e297e,c72d7000) at vfs_badlock+0x11 > assert_vop_locked(c72d7000,c06e297e,c72d7000,c06e297e) at > assert_vop_locked+0x4a > VOP_OPEN_APV(c0710da0,ebf36a28) at VOP_OPEN_APV+0x8e > union_open(ebf36a78,ebf36b20,c74e0930,ebf36ae4,c04f884b) at union_open+0xe2 > VOP_OPEN_APV(c06f83a0,ebf36a78) at VOP_OPEN_APV+0x9b > exec_check_permissions(ebf36b90,9,1,0,0) at exec_check_permissions+0xeb > do_execve(c6658bd0,ebf36c60,0,ebf36c60,c6658bd0) at do_execve+0x18a > kern_execve(c6658bd0,ebf36c60,0) at kern_execve+0x7c > execve(c6658bd0,ebf36d04,c6bb5d38,c,c6658bd0) at execve+0x2f > syscall(3b,3b,3b,bfbfe90c,0) at syscall+0x27e > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (59, FreeBSD ELF32, execve), eip = 0x280d3dfb, esp = 0xbfbfe35c, > ebp = 0xbfbfe808 --- > VOP_OPEN: 0xc72d7000 is not locked but should be > > Kris -- 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-10 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
On Wed, Apr 05, 2006 at 10:46:59PM +0900, Daichi GOTO wrote: > It is my pleasure and honor to announce the availability of > the unionfs patchset-10. > > Patchset-10: >For 7-current > http://people.freebsd.org/~daichi/unionfs/unionfs-p10.diff > >For 6.x > http://people.freebsd.org/~daichi/unionfs/unionfs6-p10.diff Thanks for your continued work! I get this panic with mount_unionfs -b: kdb_backtrace(ebf369e8,c056b59a,c06c905a,c06e297e,c72d7000) at kdb_backtrace+0x29 vfs_badlock(c06c905a,c06e297e,c72d7000) at vfs_badlock+0x11 assert_vop_locked(c72d7000,c06e297e,c72d7000,c06e297e) at assert_vop_locked+0x4a VOP_OPEN_APV(c0710da0,ebf36a28) at VOP_OPEN_APV+0x8e union_open(ebf36a78,ebf36b20,c74e0930,ebf36ae4,c04f884b) at union_open+0xe2 VOP_OPEN_APV(c06f83a0,ebf36a78) at VOP_OPEN_APV+0x9b exec_check_permissions(ebf36b90,9,1,0,0) at exec_check_permissions+0xeb do_execve(c6658bd0,ebf36c60,0,ebf36c60,c6658bd0) at do_execve+0x18a kern_execve(c6658bd0,ebf36c60,0) at kern_execve+0x7c execve(c6658bd0,ebf36d04,c6bb5d38,c,c6658bd0) at execve+0x2f syscall(3b,3b,3b,bfbfe90c,0) at syscall+0x27e Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (59, FreeBSD ELF32, execve), eip = 0x280d3dfb, esp = 0xbfbfe35c, ebp = 0xbfbfe808 --- VOP_OPEN: 0xc72d7000 is not locked but should be Kris pgpT06o7pznR0.pgp Description: PGP signature
patchset-10 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
It is my pleasure and honor to announce the availability of the unionfs patchset-10. Patchset-10: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p10.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p10.diff Changes in unionfs-p10.diff - Fixed a problem that does not unlock a vnode around some treatments of VOP_RENAME. - Added workaround implementation for panic by umount(8) -f. - Changed around VOP_ADVLOCK treatments to make shadow file into upper layer always to keep lock consistency. The documents of those unionfs patches: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) Attentions: We are getting union_getwritemount rewrite work still now. The p-10 is intermediate step implementation, and some code in not according to style(9) source code style. I want to get active unionfs patchset users to test it. If you want stable implementation, please wait until p-11. However, of course, p-10 is stable rather than p-9 already :) 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)
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)
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)
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)
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)
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)
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)
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)
> 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)
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]"
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)
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)
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]"
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]"
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]"
patchset-8-fix1 for 6.x release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
I have updated the patchset-8-fix1 for 6.x of unionfs. Patchset-8-fix1 for 6.x: For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p8-fix1.diff Changes in unionfs6-p8-fix1.diff - fixed 6.x build failure So sorry, unionfs6-p8 has a build failure unwittingly :( -- 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-8 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Cy Schubert ha scritto: > In message <[EMAIL PROTECTED]>, Dario Freni writes: >> Daichi GOTO ha scritto: >>> I have updated the patchset-8 of unionfs. >>> >>> Patchset-8: >>>For 7-current >>> http://people.freebsd.org/~daichi/unionfs/unionfs-p8.diff >>> >>>For 6.x >>> http://people.freebsd.org/~daichi/unionfs/unionfs6-p8.diff >>> >>>Changes in unionfs-p8.diff >>> - Fixed the issue that user whom has access permission >>>cannot change the directory because he cannot create >>>its shadow directory. As a result of this fixed, now >>>unionfs uses root permission creating shadow directory >>>temporarily. >>> >>> The document of those unionfs patches is pretty improved by Hiroo >>> ONO-san. >>> >>> http://people.freebsd.org/~daichi/unionfs/ (English) >>> http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) >>> >>> Please try -p8 Dario. We are thinking that you cat get it with -p8 :) >> It doesn't compile on 6.x :/ (using unionfs6-p8.diff on a fresh RELENG_6) >> >> cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls >> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 >> -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq >> -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf >> -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd >> -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL >> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common >> -finline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000 -mno-align-long-strings >> -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >> -ffreestanding -Werror /usr/src/sys/ufs/ufs/ufs_lookup.c >> /usr/src/sys/ufs/ufs/ufs_lookup.c: In function `ufs_direnter': >> /usr/src/sys/ufs/ufs/ufs_lookup.c:880: error: `vdp' undeclared (first >> use in this function) >> /usr/src/sys/ufs/ufs/ufs_lookup.c:880: error: (Each undeclared >> identifier is reported only once >> /usr/src/sys/ufs/ufs/ufs_lookup.c:880: error: for each function it >> appears in.) >> *** Error code 1 >> >> Stop in /usr/obj.unionfs-i386/usr/src/sys/FREESBIE. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. > > Replace the line in the patch that says: > > + if (OFSFMT(vdp)) > > with: > > + if (OFSFMT(dvp)) > > Ok, it compiled. New iso is at: http://torrent.freesbie.org/FreeSBIE-unionfs-i386-20060210.iso.torrent It seems better, I can log in and even startx. Further testing is coming :) Thanks, Dario -- 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-8 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
In message <[EMAIL PROTECTED]>, Dario Freni writes: > Daichi GOTO ha scritto: > > I have updated the patchset-8 of unionfs. > > > > Patchset-8: > >For 7-current > > http://people.freebsd.org/~daichi/unionfs/unionfs-p8.diff > > > >For 6.x > > http://people.freebsd.org/~daichi/unionfs/unionfs6-p8.diff > > > >Changes in unionfs-p8.diff > > - Fixed the issue that user whom has access permission > >cannot change the directory because he cannot create > >its shadow directory. As a result of this fixed, now > >unionfs uses root permission creating shadow directory > >temporarily. > > > > The document of those unionfs patches is pretty improved by Hiroo > > ONO-san. > > > > http://people.freebsd.org/~daichi/unionfs/ (English) > > http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) > > > > Please try -p8 Dario. We are thinking that you cat get it with -p8 :) > > It doesn't compile on 6.x :/ (using unionfs6-p8.diff on a fresh RELENG_6) > > cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 > -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq > -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf > -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd > -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -ffreestanding -Werror /usr/src/sys/ufs/ufs/ufs_lookup.c > /usr/src/sys/ufs/ufs/ufs_lookup.c: In function `ufs_direnter': > /usr/src/sys/ufs/ufs/ufs_lookup.c:880: error: `vdp' undeclared (first > use in this function) > /usr/src/sys/ufs/ufs/ufs_lookup.c:880: error: (Each undeclared > identifier is reported only once > /usr/src/sys/ufs/ufs/ufs_lookup.c:880: error: for each function it > appears in.) > *** Error code 1 > > Stop in /usr/obj.unionfs-i386/usr/src/sys/FREESBIE. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. Replace the line in the patch that says: + if (OFSFMT(vdp)) with: + if (OFSFMT(dvp)) Cheers, Cy Schubert <[EMAIL PROTECTED]> Web: http://www.komquats.com and http://www.bcbodybuilder.com FreeBSD UNIX: <[EMAIL PROTECTED]> Web: http://www.FreeBSD.org BC Government: <[EMAIL PROTECTED]> "Lift long enough and I believe arrogance is replaced by humility and fear by courage and selfishness by generosity and rudeness by compassion and caring." -- Dave Draper ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: patchset-8 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Daichi GOTO ha scritto: I have updated the patchset-8 of unionfs. Patchset-8: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p8.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p8.diff Changes in unionfs-p8.diff - Fixed the issue that user whom has access permission cannot change the directory because he cannot create its shadow directory. As a result of this fixed, now unionfs uses root permission creating shadow directory temporarily. The document of those unionfs patches is pretty improved by Hiroo ONO-san. http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) Please try -p8 Dario. We are thinking that you cat get it with -p8 :) It doesn't compile on 6.x :/ (using unionfs6-p8.diff on a fresh RELENG_6) cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/ufs/ufs/ufs_lookup.c /usr/src/sys/ufs/ufs/ufs_lookup.c: In function `ufs_direnter': /usr/src/sys/ufs/ufs/ufs_lookup.c:880: error: `vdp' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_lookup.c:880: error: (Each undeclared identifier is reported only once /usr/src/sys/ufs/ufs/ufs_lookup.c:880: error: for each function it appears in.) *** Error code 1 Stop in /usr/obj.unionfs-i386/usr/src/sys/FREESBIE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
patchset-8 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
I have updated the patchset-8 of unionfs. Patchset-8: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p8.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p8.diff Changes in unionfs-p8.diff - Fixed the issue that user whom has access permission cannot change the directory because he cannot create its shadow directory. As a result of this fixed, now unionfs uses root permission creating shadow directory temporarily. The document of those unionfs patches is pretty improved by Hiroo ONO-san. http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) Please try -p8 Dario. We are thinking that you cat get it with -p8 :) 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-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Hi folks It is congratulations. I must say thank you for two guys. By some efforts by Yoshihiro OTA-san and Hiroo ONO-san, we could get full Egnlish-texted description site. http://people.freebsd.org/~daichi/unionfs/ Thanks! Dario Freni wrote: Daichi GOTO wrote: At this moment, we are making -p8 that solves your problem, Dario. Please wait -p8, I think you get good satisfaction by -p8 :) Thank you and Masanori so much for working on this :) The less I can do is to report feedback and help improving. Bye, Dario -- 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-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Dario Freni wrote: No panics anymore but still got some problems. I have unionfs on /usr and cannot access /usr/home/freesbie directly (i.e.: if i login as 'freesbie' user right after boot I can't access /usr/home at all, getting a permission denied error). To reproduce, download iso from torrent: http://torrent.freesbie.org/FreeSBIE-unionfs-i386-20060205.iso.torrent and log in as freesbie. Bye and thanks, Dario Yes, yes, yes. It is a good and definitely question. This is not a implementation problem, it is a semantics issue be discussed well. By -p7 implementation, only root can make /usr/home/freesbie/ shadow directory bacause the permission of parent directory of /usr/home/freesbie/ is root. /usr/home/ -- root permission /usr/home/freesbie/ -- freesbie permission | --> So only root can make shadow directory of /usr/home/freesbie/. Yes, yes, you should think that freesbie user could make shadow directory of /usr/home/freesbie/ bacause the permission of lower layer is freesbie. We are thinking that the both ways are correct. In first way, permissions of upper layer takes precedence over lower layer, in second way, permissions of lower layer takes precedence over upper layer. We are getting a discussing around this long time. In the meantime, we have made up -p7 with first way. But yes, we are thinking that the first way is not useful and it may be not good as the goal of unionfs. At this moment, we are making -p8 that solves your problem, Dario. Please wait -p8, I think you get good satisfaction by -p8 :) -- 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-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Daichi GOTO wrote: At this moment, we are making -p8 that solves your problem, Dario. Please wait -p8, I think you get good satisfaction by -p8 :) Thank you and Masanori so much for working on this :) The less I can do is to report feedback and help improving. Bye, Dario ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: patchset-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Daichi GOTO ha scritto: I have updated the patches: For 7-current patch http://people.freebsd.org/~daichi/unionfs/unionfs-p5.diff For 6.x patch http://people.freebsd.org/~daichi/unionfs/unionfs6-p5.diff Changes from -p4: - fixed around "can't fifo/vnode bypass -1" panic problem - added some comments into source-code for src-developer - edited style as style(9) saye >>> -- >>>Daichi GOTO, http://people.freebsd.org/~daichi >> >> so far so good! it's not crashing my diskless. >> >> thanks, >> danny > > It's good :) > No panics anymore but still got some problems. I have unionfs on /usr and cannot access /usr/home/freesbie directly (i.e.: if i login as 'freesbie' user right after boot I can't access /usr/home at all, getting a permission denied error). To reproduce, download iso from torrent: http://torrent.freesbie.org/FreeSBIE-unionfs-i386-20060205.iso.torrent and log in as freesbie. Bye and thanks, Dario -- 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-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
I have updated the patches: For 7-current patch http://people.freebsd.org/~daichi/unionfs/unionfs-p5.diff For 6.x patch http://people.freebsd.org/~daichi/unionfs/unionfs6-p5.diff Changes from -p4: - fixed around "can't fifo/vnode bypass -1" panic problem - added some comments into source-code for src-developer - edited style as style(9) saye -- Daichi GOTO, http://people.freebsd.org/~daichi so far so good! it's not crashing my diskless. thanks, danny It's good :) -- 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-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
> I have updated the patchset-7 (of course patchset-6 exists). > > Patchset-7: > For 7-current > http://people.freebsd.org/~daichi/unionfs/unionfs-p7.diff > > For 6.x > http://people.freebsd.org/~daichi/unionfs/unionfs6-p7.diff > > changes -p7 from -p6: > - fixed problem that removes not empty directory. > For fixing this, I fixed a problem (src/sys/ufs/ufs/ufs_lookup.c) > regarding to white-out uncorrect work when fails of making > shadow directory. > - fixed "Returning with 1 locks held." panic problem. > Unfree of vnode lock when it fails making of shadow dirrectory > led the problem. > > Patchset-6: > For 7-current > http://people.freebsd.org/~daichi/unionfs/unionfs-p6.diff > > For 6.x > http://people.freebsd.org/~daichi/unionfs/unionfs6-p6.diff > > changes -p6 from -p5: > - fixed ln(1) fail problem when -f is optioned. And > problems around hardling-specific are fixed > - added VOP_GETWRITEMOUNT treatment. Pre-implementation > has probability of write-fail bacause of unwork of > vn_start_write. > > And now, we have an unionfs explanation site in English: >http://people.freebsd.org/~daichi/unionfs/ (English) >http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) > > Great thanks for Yoshihiro Ota-san :) He gave me that translated > text. Please read the explanation text whom has interest in > around unionfs. > > Thanks! > > Daichi GOTO wrote: > > I have updated the patches: > > > > For 7-current patch > > http://people.freebsd.org/~daichi/unionfs/unionfs-p5.diff > > > > For 6.x patch > > http://people.freebsd.org/~daichi/unionfs/unionfs6-p5.diff > > > > Changes from -p4: > > - fixed around "can't fifo/vnode bypass -1" panic problem > > - added some comments into source-code for src-developer > > - edited style as style(9) saye > > -- >Daichi GOTO, http://people.freebsd.org/~daichi so far so good! it's not crashing my diskless. thanks, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
patchset-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
I have updated the patchset-7 (of course patchset-6 exists). Patchset-7: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p7.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p7.diff changes -p7 from -p6: - fixed problem that removes not empty directory. For fixing this, I fixed a problem (src/sys/ufs/ufs/ufs_lookup.c) regarding to white-out uncorrect work when fails of making shadow directory. - fixed "Returning with 1 locks held." panic problem. Unfree of vnode lock when it fails making of shadow dirrectory led the problem. Patchset-6: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p6.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p6.diff changes -p6 from -p5: - fixed ln(1) fail problem when -f is optioned. And problems around hardling-specific are fixed - added VOP_GETWRITEMOUNT treatment. Pre-implementation has probability of write-fail bacause of unwork of vn_start_write. And now, we have an unionfs explanation site in English: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) Great thanks for Yoshihiro Ota-san :) He gave me that translated text. Please read the explanation text whom has interest in around unionfs. Thanks! Daichi GOTO wrote: I have updated the patches: For 7-current patch http://people.freebsd.org/~daichi/unionfs/unionfs-p5.diff For 6.x patch http://people.freebsd.org/~daichi/unionfs/unionfs6-p5.diff Changes from -p4: - fixed around "can't fifo/vnode bypass -1" panic problem - added some comments into source-code for src-developer - edited style as style(9) saye -- 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-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Daichi GOTO ha scritto: > I have updated the patchset-7 (of course patchset-6 exists). > > Patchset-7: >For 7-current > http://people.freebsd.org/~daichi/unionfs/unionfs-p7.diff > >For 6.x > http://people.freebsd.org/~daichi/unionfs/unionfs6-p7.diff > >changes -p7 from -p6: > - fixed problem that removes not empty directory. >For fixing this, I fixed a problem (src/sys/ufs/ufs/ufs_lookup.c) >regarding to white-out uncorrect work when fails of making >shadow directory. > - fixed "Returning with 1 locks held." panic problem. >Unfree of vnode lock when it fails making of shadow dirrectory >led the problem. > > Patchset-6: >For 7-current > http://people.freebsd.org/~daichi/unionfs/unionfs-p6.diff > >For 6.x > http://people.freebsd.org/~daichi/unionfs/unionfs6-p6.diff > >changes -p6 from -p5: > - fixed ln(1) fail problem when -f is optioned. And >problems around hardling-specific are fixed > - added VOP_GETWRITEMOUNT treatment. Pre-implementation >has probability of write-fail bacause of unwork of >vn_start_write. > > And now, we have an unionfs explanation site in English: > http://people.freebsd.org/~daichi/unionfs/ (English) > http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) > > Great thanks for Yoshihiro Ota-san :) He gave me that translated > text. Please read the explanation text whom has interest in > around unionfs. > > Thanks! Thanks! I'll test it ASAP. -- 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: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
Daichi GOTO ha scritto: > I have updated the patches: > > For 7-current patch > http://people.freebsd.org/~daichi/unionfs/unionfs-p5.diff > > For 6.x patch > http://people.freebsd.org/~daichi/unionfs/unionfs6-p5.diff > > Changes from -p4: > - fixed around "can't fifo/vnode bypass -1" panic problem > - added some comments into source-code for src-developer > - edited style as style(9) saye FreeSBIE test image with a debug kernel patched with -p5 patchset: http://torrent.freesbie.org/FreeSBIE-unionfs-i386-20060116.iso.torrent To obtain a panic, just do normal operations like login as freesbie (/usr/home/freesbie is under unionfs). If you log in as root, you should be able to inspect something in the filesystem without having a panic. The panic is triggered by the chdir syscall: panic: userret: Returning with 1 locks held. cpuid = 0 KDB: enter: panic [thread pid 592 tid 100063 ] Stopped at kdb_enter+0x2c: leave db> bt Tracing pid 592 tid 100063 td 0xc1a8a180 kdb_enter(c08fc650,100,c1a8a180,d,c1f2c000) at kdb_enter+0x2c panic(c08ff985,1,d,c1a8a180,c1f2c000) at panic+0x17f ast(c1a8a180,c83c5d38,43,2,43) at ast syscall(3b,3b,3b,3e8,bfbfe940) at syscall+0x186 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (13, FreeBSD ELF32, fchdir), eip = 0x28131cdb, esp = 0xbfbfe84c, ebp = 0xbfbfe8e8 --- db> Bye, Dario -- 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: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
I have updated the patches: For 7-current patch http://people.freebsd.org/~daichi/unionfs/unionfs-p5.diff For 6.x patch http://people.freebsd.org/~daichi/unionfs/unionfs6-p5.diff Changes from -p4: - fixed around "can't fifo/vnode bypass -1" panic problem - added some comments into source-code for src-developer - edited style as style(9) saye -- 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: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
Matteo Riondato wrote: I think that on sys/fs/unionfs/union_vfsops.c, line 116, done should be size_t, to have unionfs compiled on amd64 (and probably other !32bit archs) Best Regards Yes, you are correct. Danny have pointed out the same problem. It is a careless mistake, so sorry. Please try the latest patch as follow: For 7-current patch: http://people.freebsd.org/~daichi/unionfs/unionfs-p4.diff For 6.x patch: http://people.freebsd.org/~daichi/unionfs/unionfs6-p4.diff -- ONGS Inc. Masanori OZAWA ([EMAIL PROTECTED]) WWW: http://www.ongs.co.jp/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
On Mon, Jan 09, 2006 at 08:21:16PM +0900, Daichi GOTO wrote: > I have updated the patches: > > For 7-current patch: > http://people.freebsd.org/~daichi/unionfs/unionfs-p3.diff > > For 6.x patch: > http://people.freebsd.org/~daichi/unionfs/unionfs6-p3.diff > > changes from -p2 to -p3: > - fixed problem of attribute associated with shadow dir > - fixed lock/unlock problem (-p2 is not enought of this) > - fixed initial treatment problem of some componentnames > > Please do the unionfs test with above new patch. I think that on sys/fs/unionfs/union_vfsops.c, line 116, done should be size_t, to have unionfs compiled on amd64 (and probably other !32bit archs) Best Regards -- Matteo Riondato FreeBSD Volunteer (http://freebsd.org) G.U.F.I. Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
I have updated the patches: For 7-current patch: http://people.freebsd.org/~daichi/unionfs/unionfs-p3.diff For 6.x patch: http://people.freebsd.org/~daichi/unionfs/unionfs6-p3.diff changes from -p2 to -p3: - fixed problem of attribute associated with shadow dir - fixed lock/unlock problem (-p2 is not enought of this) - fixed initial treatment problem of some componentnames Please do the unionfs test with above new patch. And do not forget to include [EMAIL PROTECTED] on Cc: even for mail directory to ozawa. He can not use English well. All mails he sent are written by daichi :) For 7-current patch: http://people.freebsd.org/~daichi/unionfs/unionfs-p2.diff (latest patch) http://people.freebsd.org/~daichi/unionfs/unionfs-p1.diff (old patch) For 6.x patch: http://people.freebsd.org/~daichi/unionfs/unionfs6-p2.diff (latest patch) http://people.freebsd.org/~daichi/unionfs/unionfs6-p1.diff (old patch) HowToInstall: http://people.freebsd.org/~daichi/unionfs/howtoinstall (UTF-8) Detail description: http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese, UTF-8) http://people.freebsd.org/~daichi/unionfs/index.html (English, but not yet, so sorry) Please keep up your interest around unionfs. We need to improve FreeBSD's unionfs I believe :) -- 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: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
Danny Braniss wrote: Okey. I found the cause of this problem. I fixed it :) http://people.freebsd.org/~daichi/unionfs/unionfs-p2.diff can you make the diffs for 6.0? thanks, danny For 7-current patch: http://people.freebsd.org/~daichi/unionfs/unionfs-p2.diff (latest patch) http://people.freebsd.org/~daichi/unionfs/unionfs-p1.diff (old patch) For 6.x patch: http://people.freebsd.org/~daichi/unionfs/unionfs6-p2.diff (latest patch) http://people.freebsd.org/~daichi/unionfs/unionfs6-p1.diff (old patch) HowToInstall: http://people.freebsd.org/~daichi/unionfs/howtoinstall (UTF-8) Detail description: http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese, UTF-8) http://people.freebsd.org/~daichi/unionfs/index.html (English, but not yet, so sorry) Please keep up your interest around unionfs. We need to improve FreeBSD's unionfs I believe :) -- ONGS Inc. Masanori OZAWA ([EMAIL PROTECTED]) WWW: http://www.ongs.co.jp/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
Danny Braniss wrote:
Masanori OZAWA wrote:
[...]
Nice work! This is just a "works for me". In only find some issues with
permissions that were already present in the previous implementation of
unionfs. Some of them are partially corrected in the "useful" copymode.
I mailed the details to the author.
the following will hang the kernel:
root is mounted nfs,
/etc is unionfs'ed so:
from /etc/rc.initdiskless:
...
# Create a generic memory disk
#
mount_md() {
/sbin/mdmfs -i 4096 -s $1 -M md $2
}
kldload unionfs
mount_md 4096 /.etc
mount_unionfs /.etc /etc
...
and now:
cd /etc
mv some-file somefile
and now the system is stuck.
this behaviour is also present in the unpatched unionfs, but would be nice
if it can be fixed.
danny
ps: see http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84107
Okey. I found the cause of this problem. I fixed it :)
http://people.freebsd.org/~daichi/unionfs/unionfs-p2.diff
I am getting a edit of HP around my improvements of unionfs
bacause someone have pointed out that your explanation is
not enough.
--
ONGS Inc.
Masanori OZAWA ([EMAIL PROTECTED])
WWW: http://www.ongs.co.jp/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
> Masanori OZAWA wrote:
> [...]
>
> Nice work! This is just a "works for me". In only find some issues with
> permissions that were already present in the previous implementation of
> unionfs. Some of them are partially corrected in the "useful" copymode.
> I mailed the details to the author.
the following will hang the kernel:
root is mounted nfs,
/etc is unionfs'ed so:
from /etc/rc.initdiskless:
...
# Create a generic memory disk
#
mount_md() {
/sbin/mdmfs -i 4096 -s $1 -M md $2
}
kldload unionfs
mount_md 4096 /.etc
mount_unionfs /.etc /etc
...
and now:
cd /etc
mv some-file somefile
and now the system is stuck.
this behaviour is also present in the unpatched unionfs, but would be nice
if it can be fixed.
danny
ps: see http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84107
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
Masanori OZAWA wrote: [...] Nice work! This is just a "works for me". In only find some issues with permissions that were already present in the previous implementation of unionfs. Some of them are partially corrected in the "useful" copymode. I mailed the details to the author. I'm scheduling a FreeSBIE test build which will use that (RELENG_6 based). Will post the link here when it is completed. Bye, Dario -- Dario Freni ([EMAIL PROTECTED]) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010
6.0-RELEASE needs follow patch:
patch start
diff -urN unionfs.current/fs/union_vfsops.c unionfs/fs/union_vfsops.c
--- unionfs.current/fs/union_vfsops.cWed Dec 28 16:58:04 2005
+++ unionfs/fs/union_vfsops.cWed Dec 28 22:54:20 2005
@@ -435,8 +435,8 @@
unionfs_quotactl(struct mount *mp,
int cmd,
uid_t uid,
- /* caddr_t arg, // for 6.0-R */
- void *arg, // for 7-current
+ caddr_t arg, // for 6.0-R
+ /* void *arg, // for 7-current */
struct thread *td)
{
struct union_mount *um = MOUNTTOUNIONMOUNT(mp);
patch end
--
ONGS Inc.
Masanori OZAWA ([EMAIL PROTECTED])
WWW: http://www.ongs.co.jp/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
