Date: Tue, 10 Apr 2001 10:44:42 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Attila Nagy <bra@fsn.hu> Cc: freebsd-hackers@freebsd.org Subject: Re: Mounting partitions with RO flag Message-ID: <Pine.NEB.3.96L.1010410103733.70711B-100000@fledge.watson.org> In-Reply-To: <20010408210425.J45749-100000@scribble.fsn.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 robert@fledge.watson.org NAI Labs, Safeport Network Services 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?Pine.NEB.3.96L.1010410103733.70711B-100000>