Date: Thu, 28 Nov 2002 17:49:01 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: bsdc@xtremedev.com, Hiten Pandya <hiten@angelica.unixdaemons.com>, <current@FreeBSD.ORG> Subject: Re: ACLs on the boot partition? Message-ID: <20021128173921.Y11276-100000@gamplex.bde.org> In-Reply-To: <Pine.NEB.3.96L.1021127143405.50233C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021128173921.Y11276-100000>