On Sat, Mar 10, 2001 at 03:27:06PM +0700, Robert Elz wrote:
>     Date:        Fri, 09 Mar 2001 15:28:24 -0500
>     From:        Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
>     Message-ID:  <20010309202830.19F942A2A@orchard.arlington.ma.us>
> 
>   | I would hope that any such scheme would also include support for
>   | efficiently allocating very small files -- perhaps ones as small as 50
>   | bytes or less.
> 
> That's an orthogonal change to the filesystem.   It is certainly one
> that would be useful to have, but it really hasn't got anything much to
> do with any of the rest of this (except that ACLs and similar may
> increase the number of very small non-empty files that exist).

To me, there is a simple and elegant solution available here: to define a
new on-disk filesystem which is efficient for storing and accessing this
kind of "additional metadata".  Then we could use our existing layered
filesystem functionality to layer this new physical filesystem over our
existing physical filesystem in any number of useful ways.

There is an obvious downside here: networked filesystems.  If you can't
extend the basic NFS protocol, then you have a rather unpleasant choice
of whether to do the layering on client or server.  If you do it on the
server, things like ACLs are enforced but can't be manipulated (and
data such as "resource forks" probably can't be accessed at all).  If you
do it on the client, at least for purposes of access control you are
forced to trust that the client will do the same data layering that you
do.

However, using the existing filesystem layering mechanism at least lets
you make this choice as appropriate for each specific application of this
"metadata layering" you might choose to implement and use.  In the "resource
fork" case, you'd NFS-export both filesystems from the server and have the
client layer them, for example.