From owner-freebsd-hackers Mon Sep 13 14:53: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fanf.noc.demon.net (fanf.noc.demon.net [195.11.55.83]) by hub.freebsd.org (Postfix) with ESMTP id DA37D14CEE for ; Mon, 13 Sep 1999 14:52:54 -0700 (PDT) (envelope-from fanf@demon.net) Received: from fanf by fanf.noc.demon.net with local (Exim 3.02 #13) id 11Qe1j-000DRT-00; Mon, 13 Sep 1999 22:52:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tony Finch To: Matthew Dillon Cc: Tony Finch , hackers@FreeBSD.ORG Subject: Re: mounting a partition more than once In-Reply-To: <199909132116.OAA25920@apollo.backplane.com> References: <199909132116.OAA25920@apollo.backplane.com> X-Mailer: VM 6.34 under Emacs 19.34.1 Message-Id: Date: Mon, 13 Sep 1999 22:52:43 +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > :Tony Finch wrote: > : > :Well, in the absence of any comments I hacked around a bit and ended > :up with the following patch (against 3.3-RC), which permits the same > :block device to be mounted read-only more than once. The motivation > :for this is to permit multiple chrooted environments to share the same > :/usr partition. > > Hmm... well, there is a problem here. I believe this will allow > you to open the underlying block device read-only as well as mount > the filesystem read-only. This will confuse the buffer cache badly. I don't think so -- spec_open checks whether the block device has been mounted in order to prevent this, and I made sure that that check remains in force except when spec_open is called by ffs_mountfs (by adding the FMOUNTING flag). I assumed that the buffer cache will handle multiple read-only mounts because it handles multiple userland reading file descriptors. > Also, this may not be the best place to put the code. It make sense > to be able to mount a block device multiple times in a read-only > fashion, but the code should be in the open for the block device > rather then in UFS/FFS, so it can be used with other filesystems > and for other purposes. Yes, it's evident that this is true because I had to hack around essentially the same test in both spec_open and ffs_mountfs; removing the checks down from ffs_mountfs so it relies on spec_mount to DTRT would be neater, I think. Tony. -- f.a.n.finch dot@dotat.at fanf@demon.net e pluribus unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message