[OpenAFS] home on afs woes

[Rainer Toebbicke]

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

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

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985       Fax: +41 22 767 7155