Meta-Data & stackable FS

[Marius Bendiksen]

> Actually, this is a little inaccurate :-).  It's important to distinguish
> (a) the API and (b) the implementation in a specific file system.  It is

Okay. But I must say the suggested API was, IIRC, not very conductive to
large attributes, nor was the general consensus in favour of supporting
EAs of useful size.

And as to implementation, your mostly excellent FFS code has a limit of
1500 bytes or so.

> our belief that while the semantics of the extended attribute call are
> limited, and intentionally so (atomic replacement, etc), they do not bound

Atomic replacement is really not an issue at all. *Any* decent
implementation can do this, even for a BLOB.

> potential size.  In fact, the API can quite happily front a number of
> underlying implementations, including the Linux variable-size
> implementation.  I believe that implementation places a bound of 256k per
> attribute, but that is an implementation detail.  The FreeBSD

This should be mostly sufficient for most people's needs. Personally, I'm
happy as long as you support ~64k per attribute.

> implementation is optimized for fixed-size attributes (such as security
> labels), but could easily be replaced with something more flexible.

Indeed. Your implementation is very good. However, I'd suggest adding the
option of indirecting/clustering EA blocks, for example, to give at least
an overflow mechanism for huge EAs.

> Patches are, as they say, welcome :-).  The POSIX.1e mailing list has had
> the specific goal of having relatively well-defined semantics for the API
> while retaining the ability to support different underlying
> implementations.

I proposed a well-defined set of semantics that could support even more
underlying implementations than what was proposed by the POSIX.1e list.

> One thing you may want to do is take a look at the Linux EA
> implementation, which behaves in approximately that manner.  With
> snapshots and soft updates in FFS, there's a bit more work involved than
> the ext2fs implementation as you have to work out dependencies and
> copy-on-write vnodes.

*nod*

I will hopefully have this fixed soon, in that me and Adrian are working
on rewriting the work I lost re/myfs. This will bring us a filesystem
which should be the next standard, once the code has been tested enough to
satisfy people. (Though I don't see why they want 3 months testing for
this after me, adrian and poul finish testing it, when they MFC kqueues
before the interface was crystallized, as well as MFC'ing Dillon's SMP
patches which broke all UP support... I mean, I haven't exactly suggested
an MFC of this stuff)

Marius

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message