[OpenAFS-devel] Re: openafs / opendfs collaboration

[Ivan Popov]

Thanks Tom,

now I understand your point better.

On Fri, Jan 21, 2005 at 04:56:16PM -0500, Tom Keiser wrote:
> cache manager:
> - responsible for storage of data and metadata
> - responsible for cache replacement strategy
> - API for interaction with implementation of VFS interface
> - API for access by RPC endpoint for things like cache invalidation

On Coda list we have had a small discussion about splitting out cache space
reclaimation from the (user space) cache manager.
It seems feasible, and possible in a portable way.
I doubt though that a similar approach would work for AFS or DFS as their
cache is a lot more complicated.

> credential manager:
> - example would be the linux 2.6 keyring implementation

<skippable>
I think all that keyring business is a try to "work around" a basic
Unix principle - that credentials are tied to an UID, that's it.
It can work as a conveniency feature, but it just hides the fact -
if you need separate security domains for different processes, they
have to be of different UIDs, otherwise the system cannot protect them
from each other (except possibly for special cases like jailed/chrooted).
The rights management in a Unix-like system is tied to UIDs, not to PAGs
or alike. We'd have to redesign all syscalls to be able to securely use PAGs.
</skippable>

> implementation of VFS interface:
> - very os-specific stuff
> - probably in-kernel unless something like LUFS takes off

LUFS seems to mean "Linux Userland File System" which does not promise a lot
about portability?

> I'm advocating
> something that sacrifices performance for OS agnosticism (sounds a bit
> like the ARLA philosophy...).

Me too. It may actually improve performance, as one invests development
time into doing the real things instead of catching up with all kernels
specialities.

> there's not much reason for hope right now, but it sure would make
> everyone's lives easier if a good userspace filesystem driver API
> existed on multiple platforms.  Yes, it will always be slower than

You are so right.
Alas, the world in far from being perfect...

Regards,
--
Ivan