From owner-freebsd-current Wed Nov 27 22:35:36 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7249C37B401; Wed, 27 Nov 2002 22:35:35 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1373843EAF; Wed, 27 Nov 2002 22:35:34 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA14247; Thu, 28 Nov 2002 17:35:23 +1100 Date: Thu, 28 Nov 2002 17:49:01 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson Cc: bsdc@xtremedev.com, Hiten Pandya , Subject: Re: ACLs on the boot partition? In-Reply-To: Message-ID: <20021128173921.Y11276-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 27 Nov 2002, Robert Watson wrote: > On Thu, 28 Nov 2002, Bruce Evans wrote: > > > > > > > On Tue, 26 Nov 2002, Robert Watson wrote: > > > > > > > > Er, what is the mount(..., MNT_RELOAD ...) in tunefs for then? > > > > > > The problem is that some flags can't be changed via MNT_RELOAD and require > > > a from-scratch mount. I'm hoping that with nmount(), we can get a little > > > more expressive regarding what changes are (and aren't) allowed to flags. > > > Right now there's some uncomfortable masking. > > > > Why can't they be changed? All the other tunefs flags except FS_ACLS > > and FS_MULTILABEL are related to writing, so ffs_reload() has to support > > them changing as a side effect of supporting transitions from read-only > > to read-write mode. > > Switching ACLs to support a change shouldn't be a problem, although I'd > generally discourage changing the ACLs flag very much, since you don't > want inconsistent access control and other side effects of using ACLs > inconsistently (they get out of sync, etc). Multilabel can't be changed > because of cache coherency issues: we cache label data in the vnode, and > changing the origin of the label data (what MNT_MULTILABEL effectively > does) would invalidate the contents of the cache. To correct that, we'd > have to support immediately (and atomically) walking the entire vnode list > and re-loading and validating the labels, something that we don't > currently do. We should do this. We already walk the vnode list and reload almost everything else (cached file data and inode data). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message