Re: unionfs and getcwd problem.
Takanori Watanabe <[EMAIL PROTECTED]> wrote: > Hi, I had trouble with unionfs when it calles getcwd(3) when > I mount some directory on the directry in same file system,like > mount -t union /usr/home/foo/bar /usr/src/sys/ . > > I investigate the problem by inserting debug print in getcwd.c. > Then I found issuing __getcwd(2) in getcwd(3) failed, and > climb up filesystem tree as the next way. But it failed when > it reaches to mount point. It seems that st_dev and st_ino > member returns the same number as the underlying filesystem > so it failed to recognize mount point. So I tried the patch as > follows taken from nullfs. Are there any problem with this patch? It looks fine to me. I know you definitely need to provide this behavior when doing a "wrapper" filesystem to behave like the system's stat() :) > Takanori Watanabe > http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html";> > Public Key > Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A > > > --- union_vnops.c~Tue Oct 2 00:01:37 2001 > +++ union_vnops.c Mon Feb 25 22:44:51 2002 > @@ -957,6 +957,8 @@ > union_newsize(ap->a_vp, VNOVAL, vap->va_size); > } > > + ap->a_vap->va_fsid = ap->a_vp->v_mount->mnt_stat.f_fsid.val[0]; > + > if ((vap != ap->a_vap) && (vap->va_type == VDIR)) > ap->a_vap->va_nlink += vap->va_nlink; > return (0); -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: unionfs and getcwd problem.
On Mon, 2002-02-25 at 17:35, Takanori Watanabe wrote: > Hi, I had trouble with unionfs when it calles getcwd(3) when > I mount some directory on the directry in same file system,like > mount -t union /usr/home/foo/bar /usr/src/sys/ . > > I investigate the problem by inserting debug print in getcwd.c. > Then I found issuing __getcwd(2) in getcwd(3) failed, and > climb up filesystem tree as the next way. But it failed when > it reaches to mount point. It seems that st_dev and st_ino > member returns the same number as the underlying filesystem > so it failed to recognize mount point. So I tried the patch as > follows taken from nullfs. Are there any problem with this patch? patch below will turn on caching on unionfs, and solve getcwd problem, patch against -CURRENT --- /usr/src/sys/fs/unionfs/union_vnops.c Sat Feb 23 13:54:45 2002 +++ union_vnops.c Wed Mar 6 14:44:59 2002 @@ -561,6 +561,9 @@ */ out: + if ((error == 0 || error == ENOENT) && saveflags & MAKEENTRY && cnp->cn_nameiop != CREATE) { + cache_enter(dvp, *ap->a_vpp, cnp); + } if (upperdvp) { if (upperdvp == uppervp || upperdvp == *ap->a_vpp) vrele(upperdvp); @@ -1931,7 +1934,8 @@ { &vop_lease_desc, (vop_t *) union_lease }, { &vop_link_desc, (vop_t *) union_link }, { &vop_lock_desc, (vop_t *) union_lock }, - { &vop_lookup_desc, (vop_t *) union_lookup }, + { &vop_cachedlookup_desc, (vop_t *) union_lookup }, + { &vop_lookup_desc, (vop_t *) vfs_cache_lookup }, { &vop_mkdir_desc, (vop_t *) union_mkdir }, { &vop_mknod_desc, (vop_t *) union_mknod }, { &vop_open_desc, (vop_t *) union_open > Takanori Watanabe -- TSB "Russian Express", Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: unionfs and getcwd problem.
[replies sent directly to me may timeout and bounce, since I'm not online as often as I should be, but I'll check the list archives] Moin, moin! %s wrote on %.3s, %lld Sep 1993 > On Mon, 2002-02-25 at 17:35, Takanori Watanabe wrote: > > Hi, I had trouble with unionfs when it calles getcwd(3) when > > I mount some directory on the directry in same file system,like > > mount -t union /usr/home/foo/bar /usr/src/sys/ . [...] > > so it failed to recognize mount point. So I tried the patch as > > follows taken from nullfs. Are there any problem with this patch? Thanks! I'm pleased to report that I applied your patch to my -stable source, and now I'm able to `make buildworld' with my rw unionfs mount of my local hacks, atop a ro nullfs mount with unaltered source, which I'm doing right now. The only obvious `problem' is when a non-r00t user attempts to access the union-mounted fs when the shadow directories have not yet been created, and `permission denied' is returned for all directories that exist below, but not in the unionfs fs. E.g.: | bash-2.05a$ ls -l /usr/src/sys/boot/ | ls: alpha: Permission denied | ls: arc: Permission denied | ls: forth: Permission denied | ls: pc98: Permission denied | total 20 | -rw-r--r-- 1 root wheel516 Nov 15 1999 Makefile | -rw-r--r-- 1 root wheel 11542 Jul 7 2000 README | drwxr-xr-x 4 root wheel512 Mar 9 17:15 common [...] > patch below will turn on caching on unionfs, and solve getcwd problem, > patch against -CURRENT > + if ((error == 0 || error == ENOENT) && saveflags & MAKEENTRY && > cnp->cn_nameiop != CREATE) { This apparently doesn't want to work for -stable, with `saveflags' causing a problem. Once I finish my -stable build, I'll see how this changes the behaviour in -current. Thanks! -*- Hmmm, it has the same `saveflags' problem with my -current (from a few days ago). Also, the first patch above, which worked well for me in -stable, also seems to work for the getcwd() problem (csh, make) in -current, but two minor problems remain -- * non-r00t users get errors as in -stable for missing directories ls: share: Permission denied ls: tools: Permission denied ls: usr.bin: Permission denied * existing directories show up twice in -current (not a problem with -stable) with `ls -li' here: 41032 drwxr-xr-x 53 root wheel512 Mar 10 22:22 sys 41032 drwxr-xr-x 53 root wheel512 Mar 10 22:22 sys 41029 drwxr-xr-x 164 root wheel512 Dec 27 03:10 usr.sbin 41029 drwxr-xr-x 164 root wheel512 Dec 27 03:10 usr.sbin (heh, I haven't checked to see how identical files in both layers are handled) Also, this is a unionfs mount atop a nullfs mount within the same filesystem, /usr, /usr/local/system/src nullfs atop /usr/src, with /usr/local/source-hacks unionfs atop the nullfs /usr/src, if it matters. thanks, barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: unionfs and getcwd problem.
On Mon, 2002-03-11 at 00:47, BOUWSMA Beery wrote: > Thanks! I'm pleased to report that I applied your patch to my > -stable source, and now I'm able to `make buildworld' with my > rw unionfs mount of my local hacks, atop a ro nullfs mount with > unaltered source, which I'm doing right now. > > The only obvious `problem' is when a non-r00t user attempts to > access the union-mounted fs when the shadow directories have not > yet been created, and `permission denied' is returned for all > directories that exist below, but not in the unionfs fs. E.g.: Yes, it is because of feature of unionfs to create shadow directories with credentionals of proceses doing "rise" operation. And if process have no permissions to write into parent directory operation fail. One of possible workarounds do as root find /union/mount/point to create all shadow directories. Another solution is to change behaviour of unionfs to use root-cred while make shadows, and then put attributes/ownership from lower layer to shadows. (but this will take a bit of kernel hacking) > thanks, > barry bouwsma -- TSB "Russian Express", Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: unionfs and getcwd problem.
> > The only obvious `problem' is when a non-r00t user attempts to > > access the union-mounted fs when the shadow directories have not > > yet been created, and `permission denied' is returned for all > > directories that exist below, but not in the unionfs fs. E.g.: > Yes, it is because of feature of unionfs to create shadow directories > with credentionals of proceses doing "rise" operation. > > And if process have no permissions to write into parent directory > operation fail. I have thought about what is best to do in a case like this. At first, I was thinking that if a directory like this does not presently exist in the upper (unionfs) layer, then for the case of a read-only operation like `ls', simply fall through to display what is present in the lower layer. This, if it is possible (I have no idea; I'm no hacker), would avoid the ``hey, why can't I do a simple `ls'?!?'' type of question. Of course, there would be a problem when some actual writes need to be performed in the unionfs layer. For example, suppose the ownerships in a directory path are something like mountpoint/root/r00t/user/FILE and the user is then able to `ls' all the directories down to the one s/he owns, seeing the contents of the lower layer, but then, due to being unable to create the r00t-owned directories in the path that do not yet exist in the upper unionfs layer, any attempt to do `work' in the user-owned directory will fail. So you just get the same sort of questions, only later. ``I have permission, why do I get permission denied?!?'' I do not know if this is even possible in the case of a command or operation that needs not modify the contents of the unionfs later, because I do not know the details of the internals of what happens, so I could be completely wrong to suggest this. > Another solution is to change behaviour of unionfs to use root-cred > while make shadows, and then put attributes/ownership from lower layer > to shadows. > (but this will take a bit of kernel hacking) This is another thing that I have wondered if it could be done. As it is, one of the `quirks' about the shadow directories, is that they get created with the timestamps of the first access which required their creation, and not the timestamps of the underlying filesystem. This can be both a bug and a feature, because it can be used to see immediately when a union-mounted directory was created when looking at a filesystem, when this is useful. On the other hand, the actual attributes of the underlying directory may easily change while the unionfs-mounted shadow gets unchanged, and this change may not be visible to the user. I will be quiet now, because I don't know of what I speak. Anyway, I just did a few more things on a slightly-older -current, built 07.Mar (sorry, I've had no time...), with a unionfs mount atop a read-only nullfs mount, and I do in fact see a problem with files present in both the upper and lower layer, just as I saw the duplicate directories shown by `ls'. Also, certain commands that work on a file only present in the lower layer fail until the file in question has been touched into the unionfs layer, with -current (I don't remember if this was a -stable problem too). This may be well-known and already-solved because I am almost three weeks out of date; if so, sorry. Here are the notes I made about this: unionfs mounted dir atop nullfs dir [10:06:25][EMAIL PROTECTED]:/usr/src/sys/modules/splash/bmp{535}# ls -lart total 52 -rw-r--r-- 1 root wheel 17634 Mar 6 2001 splash_bmp.c -rw-r--r-- 1 root wheel 17634 Mar 6 2001 splash_bmp.c-DIST -rw-r--r-- 1 root wheel194 Jan 24 22:37 Makefile drwxr-xr-x 7 root wheel512 Mar 25 10:03 .. drwxr-xr-x 7 root wheel512 Mar 25 10:03 .. -rw-r--r-- 1 root wheel 4918 Mar 25 10:05 splash_bmp.c-patch drwxr-xr-x 4 root wheel512 Mar 25 10:05 . drwxr-xr-x 4 root wheel512 Mar 25 10:05 . contents of nullfs-remounted (original) dir: [10:08:19][EMAIL PROTECTED]:/usr/src/sys/modules/splash/bmp{543}# ls -lart /usr/local/system/src/sys/modules/splash/bmp/ total 24 -rw-r--r-- 1 root wheel 17634 Mar 6 2001 splash_bmp.c drwxr-xr-x 4 root wheel512 Nov 23 00:21 .. drwxr-xr-x 2 root wheel512 Jan 24 22:37 . -rw-r--r-- 1 root wheel194 Jan 24 22:37 Makefile Contents of unionfs atop that: [10:05:59][EMAIL PROTECTED]:/usr/local/source-hacks/sys/modules/splash/bmp{533}# ls -lart total 28 -rw-r--r-- 1 root wheel 17634 Mar 6 2001 splash_bmp.c-DIST drwxr-xr-x 3 root wheel512 Mar 25 10:03 .. -rw-r--r-- 1 root wheel 4918 Mar 25 10:05 splash_bmp.c-patch drwxr-xr-x 2 root wheel512 Mar 25 10:05 . Attempt to use patch: [10:07:00][EMAIL PROTECTED]:/usr/src/sys/modules/splash/bmp{539}# patch < splash_bmp.c-patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- /FreeBSD-4/usr/local/source-hacks/sys/modules/splash/bmp/splash_bmp.c-DIST Tue Oct 31 09:00:06
Re: unionfs and getcwd problem.
On Mon, 2002-03-25 at 18:28, BOUWSMA Beery wrote: > > > > The only obvious `problem' is when a non-r00t user attempts to > > > access the union-mounted fs when the shadow directories have not > > > yet been created, and `permission denied' is returned for all > > > directories that exist below, but not in the unionfs fs. E.g.: > > > Yes, it is because of feature of unionfs to create shadow directories > > with credentionals of proceses doing "rise" operation. > > > > And if process have no permissions to write into parent directory > > operation fail. > > I have thought about what is best to do in a case like this. > At first, I was thinking that if a directory like this does not > presently exist in the upper (unionfs) layer, then for the case > of a read-only operation like `ls', simply fall through to display > what is present in the lower layer. > > This, if it is possible (I have no idea; I'm no hacker), would > avoid the ``hey, why can't I do a simple `ls'?!?'' type of > question. May be you will be interested in -o union flag to any standart mount It works a bit different from special union FS. > thanks, > barry bouwsma -- TSB "Russian Express", Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message