> Ook, so you depend on AFS. Do you need speed? If you can afford to
> loose a _lot_ of speed, you can develop userland nfs daemon that will
> re-export AFS. That way, you'll have portable & kernel-change-proof
> solution.
Er, no.
That's actually far less useful than you'd think. It'll allow
read-only unauthenticated access. No writing to any directories that
aren't world-writable, no reading anything that isn't world-readable.
Here at CMU, where user home directories are in AFS and by default not
world-readable, it'd be utterly unworkable.
You could get around that for a single user by running the NFS server
doing the re-exporting with tokens for that user, but that ends up
meaning that anyone mounting that NFS partition can write to AFS as
the user in question. So that's not so useful for multi-user machines.
I suppose if you were willing to accept that machines using this hack
would be single-user only, you could hack /bin/login to start an NFS
server on your special AFS re-exporting machine and then mount
appropriately. But them you have to play games with exporting tickets
and tokens across the network, which doesn't work in all environments.
And even if you _could_ get forwarding tickets and tokens to work
flawlessly, you still wouldn't have all the functionality of AFS. You
wouldn't be able to change protections on directories. You wouldn't be
able to use any of the standard AFS utilities. Additionally, once your
files hit NFS, they'd go over the network in the clear. Since AFS can
do encrypted transfers, thic can also be a significant lose.
So really, this export-AFS-over-NFS trick isn't useful for anything
other than "I need to read these publically-readable files"
emergencies. Here at CMU SCS we use it to bootstrap machines during
the install process, but not for much else.
It's portable, it's kernel-change-proof, but it isn't really anywhere
near a solution. If speed was the only thing you lost, it might
be. But you also lose authentication, security, and the ability to
make significant changes to AFS space, which are far more important.
--nat
-- nat lanza --------------------- research programmer, parallel data lab, cmu scs magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/