On Sun, 8 Apr 2001, Attila Nagy wrote:
> With the appearing of the jail() in 4.0 I think it would be very good to
> have the functionality of mounting already mounted (RW) filesystems read
> only to another directory.
Many people agree with you -- this is one reason why the fixing of nullfs
in -CURRENT was so desirable. However, most consumers of jail are
actually looking to replicate only a portion of their jails--usually the
/usr tree, as it's the most sizable chunk, and then symlink bin and sbin
into it. This preserves /, /var, /etc, and /tmp as running inside the
jail. Jail is really intended to virtualize whole environments, rather
than particular daemons, however (doesn't mean you can't, but that was the
thrust).
> For example there are several daemons which can run on a read only
> filesystem, like an anonymous FTP daemon for extra security in a jail.
>
> nullfs and unionfs would be suitable for these tasks but they have
> problems in at least -STABLE, so there are only hacks for doing this,
> like NFS mounted filesystems and partition "magic" (defining a lot of
> partitions onto the same physical space).
>
> So I am wondering, why the unices block mounting an already mounted
> partition read only again.
Well, you certainly don't want to mount the same partition writable and
read-only at the same time. It's an arbitrary design choice to prevent
simultaneous mounting of read-only file systems on one vnode, and one that
I think Poul-Henning was going to look at removing as part of his device
layer restructuring.
> Would it be possible to solve this under FreeBSD?
It seems like there are a number of solutions to the problem that have
been considered:
nullfs fixed in 5.0-CURRENT
nfs loopback works
multiple mounting not implemented
nullfs is probably the best choice, as it prevents redundant caching in
the vm/buffer cache. nfs loopback introduces a substantial performance
overhead, but at least works. And multiple mounting won't provide the
RW/RO behavior you want, only multiple RO mounts, although it should be
straight-forward to implement it. You could hack that in now by futzing
with the vfs_mountedon() behavior, it's just not clear it provides what
you actually want. The best bet may be to backport the nullfs fixes to
4.x, or to wait for 5.x.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
