[OpenAFS] home on afs woes
Tue, 10 Jan 2006 13:44:54 +0100
Jeffrey Hutzelman wrote:
>> Support for directory
>> entries pointing to files in located in *other* volumes (and with what
>> type of ACL semantics)?
> Huh? Why would we do that?
> Directory entries describe files within a single directory.
Well, you're redesigning so this is the time to ask why all files in a
directory should be in the same "volume"?
The term "volume" is today overloaded with
1. a [relative] position in the name space
2. the quota management
3. a physical location
4. a replication factor
5. a backup entity (if you use AFS backup)
6. a management unit, with a role e.g. in data placement.
That's a lot and makes AFS relatively cumbersome to manage. My last
attempt to 'vos move' a small(!) volume with 1 million files lasted
about 11 hours, and most of the time the volume wasn't writeable!
The client actually handles files (or vnodes), not volumes and most of
the time does not care about volumes. The lookup hard-smashes the
volume ID into the Fid and only takes the Vnode.Vunique out of the
directory. If the directory were *allowed* to contain the something
else as well, then the path were open for subsequently unloading the
[In the Apollo Domain file system every name in a directory resolved
to a UUID and I'm sure some still remember all the fancy things that
were thus possible - including screwing it up of course :-) ].
I'm just pleading for increased flexibility: currently too many ideas
to scale up AFS stop at a 20 year-old directory design which you'd
have to redesign as well.
So while you're at it...
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985 Fax: +41 22 767 7155