From owner-freebsd-hackers Fri Sep 17 16:15:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id 8CA3615A14 for ; Fri, 17 Sep 1999 16:15:07 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id QAA04451 for ; Fri, 17 Sep 1999 16:12:40 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA25920; Mon, 13 Sep 1999 14:16:25 -0700 (PDT) (envelope-from dillon) Date: Mon, 13 Sep 1999 14:16:25 -0700 (PDT) From: Matthew Dillon Message-Id: <199909132116.OAA25920@apollo.backplane.com> To: Tony Finch Cc: hackers@FreeBSD.ORG Subject: Re: mounting a partition more than once References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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. : :Some things I wonder about this change is whether the mounts will share :the same pages in the buffer cache, and whether the resource :accounting is still right. I've subtly funted the meaning of :v_specmountpoint when multiple mounts happen; does this matter? : :Tony. :-- :f.a.n.finch dot@dotat.at fanf@demon.net e pluribus unix 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. 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message