On Thu, 8 Mar 2001, David Brownlee wrote:

# Date: Thu, 8 Mar 2001 17:31:26 +0000 (GMT)
# From: David Brownlee <abs@netbsd.org>
# To: Lord Isildur <mrfusion@umbar.vaxpower.org>
# Cc: der Mouse <mouse@rodents.montreal.qc.ca>, tech-kern@netbsd.org
# Subject: Re: Support for ACLs
#
# On Thu, 8 Mar 2001, Lord Isildur wrote:
#
# > Since the talk is of ACLs specifically in FFS, why not copy the FFS
# > support and fork off an ACL-ified FFS and keep it _separate_ from the
# > plain FFS code. Think it through so that an ACL'ed FFS filesystem can be
# > mounted by a kernel that does not support the ACLs.
# > That's my .02 on it.
#
# 	Any such filesystem should be able to share the vast majority of
# 	FFS code, probably even down to the point of 'everything, just
# 	with ifdefs'.
#
# 	Hmm - why is ACL support any more 'unhealthy' than say quota
# 	support with options QUOTA?

Responding to the question,

Because the metadata association becomes a little more deeply entangled,
I think.  The quota system is really, really simple because all you're
doing is keeping track of how many blocks/inodes are attached to each
user, at a rate of one quota descriptor file for each filesystem, and
since the quota file is read into the kernel manually with a userland
call (scripted != automatic, in this case), comparing the two is really
like comparing grapefruit and pomegranates.

ACLs are on a per-inode basis, and have the potential to really screw up
ffs if not done right.  It will, as noted, probably affect portability,
as systems which don't recognize ACLs will probably find a bunch of un-
claimed blocks or other inconsistencies on running fsck.

This is not saying that it shouldn't be done.

#
# 	Another option might be a 'metadata' filesystem layer that could
# 	be mounted over any other filesystem to give ACL, MacOS 'resource
# 	forks' and anything else required. Keeping things in sync if
# 	anything ever modifies the lower filesystem without going through
# 	the metadata layer would be a nightmare though. Ick.

Also, WRT metadata layer, can you say "latency" and/or "performance issue"?
I knew you could.

We'd have to pretty much design a new fs.

Speaking of new filesystems, are we planning to support ReiserFS at all?
Does anyone think it's a gross hack?  I'm ignorant in this realm, but
I've done some reading on it and it looks like it could have some
possibilities.

I'm going to stop now before I get too far afield, but I've got quite
a bit of material for that field.

# 		David/absolute		-- www.netbsd.org: No hype required --

				--*greywolf;
--
*BSD: Stable and strong!