On Wed, September 10, 2008 16:52, Daniel Phillips wrote:

quoted text
> 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?

quoted text
>

> 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.

quoted text
>

> 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.

quoted text
> 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@tux3.org

http://tux3.org/cgi-bin/mailman/listinfo/tux3