[Tux3] More xattr design details

[Benjamin K. Stuhl]

On Wed, September 10, 2008 16:52, Daniel Phillips wrote:
> The parallel design/implementation effort for xattrs is now well under
way.  There was a lot of obsessing over the wisdom of the xattr atom
idea vs storing the literal ascii xattr names.  A nasty problem with
atoms is, how can we know the filesystem will never fill up with atom
names that were once used and now are just historical garbage?
>
> Choose a solution:
>
>   1) Ignore the problem and hope it never bites (typical)
>
>   2) Refcount all atoms and delete any that fall to zero
>
>   3) Garbage collect unused atoms from time to time
>
> For the immediate future Tux3 is using solution number 1, which is to
say, just let the on-disk atom table grow as new attribute types arrive
and do not worry too much about how big it gets.
>
> For production Tux3 we need a better solution that acts just like the
traditional method of storing literal ascii strings.  It looks like
refcounting is the best idea, but we have to do it efficiently.
> Fortunately, that looks pretty easy, and even better, the methods we
need to apply are almost the same as for file atimes.  So there is some
design synergy there, which helps ameliorate the pain.

I have an argument for going with solution 1 or 3, maybe depending on
filesystem size: we basically have to keep a copy of the atom table in
memory at all times, otherwise we have to fetch a bunch of blocks
everytime someone calls setxattr(). I see two general cases for
filesystems:
  1. filesystem size >> RAM: this is the common case for everything except
USB thumb drives, and if the atom table is large enough to matter in terms
of disk usage, it's already getting cramped by main memory
  2. filesystem size <= RAM: for all modern media, this is small enough
that garbage collection should feasible in a reasonable amount of time

So if we accept that caching constraints for the atom table reasonably
bound it by main memory size, it seems to me that there is no reason to
bother with reference counting. (Plus, that means that the atom table
takes up one less word per atom.)

All that said, this may simply be an argument against having a global atom
table at all: the atom table constitutes an unprivileged DoS. Especially
since I can't think of a sane way to charge quota for shared xattr names.

Maybe the solution is to have the xattr atom table be per-directory or
per-user? (A per-user atom table could then be integrated with the
per-user quota information and also makes it crystal clear who gets
charged for the atom table blocks. But then it might make sense to
refcount or GC atoms again, so that users can reclaim their quota blocks.
Hmm. Or maybe 1-bit refcounting: any name used more than once never goes
away, unless we have some sort of GC?)

-- BKS



_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3