From owner-freebsd-hackers Tue Apr 10 7:44:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C376437B423 for ; Tue, 10 Apr 2001 07:44:10 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3AEigf71345; Tue, 10 Apr 2001 10:44:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 10 Apr 2001 10:44:42 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Attila Nagy Cc: freebsd-hackers@freebsd.org Subject: Re: Mounting partitions with RO flag In-Reply-To: <20010408210425.J45749-100000@scribble.fsn.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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