Date: Sun, 10 Feb 2002 23:36:51 +0100 (CET) From: BOUWSMA Beery <freebsd-user@dcf77-zeit.netscum.dyndns.dk> To: hackers@freebsd.org Subject: Re: nullfs and unionfs Message-ID: <200202102236.g1AMaps00233@beerswilling.netscum.dyndns.dk> References: <20020210113701.S28078-100000@patrocles.silby.com> <000001c1b24e$ffacea40$0200000a@spencer>
next in thread | previous in thread | raw e-mail | index | archive | help
> > It looks like there are still some serious problems with this. I just > > tried a similar thing on FreeBSD 4.4 and 4.5. I created a directory of > > binaries to use for multiple jails, then null-mounted (read-only) the > > binaries for each of the jails to use. To allow the /etc and other > > parts of the jails to be written, I union-mounted a per-jail writeable > > filesystem over each of the null mounts. It seemed to work well until > If I'm not mistaken, nullfs had been fixed significantly in -current, but > the changes were not MFC'd... I'm not entirely sure on this, you might Boy, that was an old message I sent out... Anyway, I didn't see any significant nullfs changes in -current (grabbing updates as we speak in case something has come in the last day or two), but a couple unionfs files seem to have been updated, though nothing is blindingly obvious to me... I had buildworld failures both with -stable and -current the last I tried, and possibly panics in -current that were enough to scare me away from this way of doing things. Oh, I remember what scared me away... Let's `ls' as a normal user my mounted filesystem: bash-2.05a$ ls -lart ls: bin: Permission denied ls: contrib: Permission denied ls: crypto: Permission denied ls: etc: Permission denied ls: games: Permission denied ls: gnu: Permission denied ls: include: Permission denied ls: kerberos5: Permission denied ls: kerberosIV: Permission denied ls: lib: Permission denied ls: libexec: Permission denied ls: release: Permission denied ls: sbin: Permission denied ls: secure: Permission denied ls: share: Permission denied ls: tools: Permission denied ls: usr.bin: Permission denied total 210 -rw-r--r-- 1 root wheel 9761 Aug 28 1999 Makefile.upgrade -rw-r--r-- 1 root wheel 4735 Sep 5 1999 COPYRIGHT -rw-r--r-- 1 root wheel 2678 Aug 31 2000 README -rw-r--r-- 1 root wheel 7494 Mar 27 2001 Makefile drwxr-xr-x 163 root wheel 512 Dec 27 03:10 usr.sbin drwxr-xr-x 163 root wheel 512 Dec 27 03:10 usr.sbin -rw-r--r-- 1 root wheel 25868 Dec 29 04:04 Makefile.inc1 drwxr-xr-x 51 root wheel 512 Jan 2 03:07 sys drwxr-xr-x 51 root wheel 512 Jan 2 03:07 sys -rw-r--r-- 1 root wheel 51200 Jan 25 10:19 UNHACKS.tar -rw-r--r-- 1 root wheel 51200 Jan 25 10:23 HACKS.tar -rw-r--r-- 1 root wheel 35654 Feb 6 18:44 UPDATING drwxr-xr-x 4 root wheel 512 Feb 7 16:30 DIST drwxr-xr-x 27 root wheel 512 Feb 7 16:32 . drwxr-xr-x 27 root wheel 512 Feb 7 16:32 . drwxr-xr-x 4 root wheel 512 Feb 7 16:33 HACKS drwxr-xr-x 18 root wheel 512 Feb 7 22:33 .. drwxr-xr-x 18 root wheel 512 Feb 7 22:33 .. bash-2.05a$ ls /usr/local/system/src (needless to say, this command on the orig nullfs mount, plus on the original unionfs mount, work splendidly, and I don't see this problem that I know of with -stable) Also, getcwd() still fails in -current too. I've tried things like `truss'ing the failed `make' and such commands on my union-atop-nullfs mount tree, to see if I can make sense of what might be failing as the commands work their way up to the root of the directory. Whatever I see, it's not enough for me to be able to say if the problem is in nullfs or unionfs or elsewhere like getcwd() for my failure. (My -stable failure. -current looks like more a nightmare.) I do, however, have no problem with a simple nullfs mount, though I have not yet tried a simple unionfs mount, which I guess I can do now... (Not that my problem is related to Hr Helmer's) thanks barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202102236.g1AMaps00233>