The Cast:

Linux, played by a happy little penguin.

OpenAFS, played by a herd of longhorn cattle

chroot, played by a yak

ln, played by another yak

The Scene:

OpenAFS running on any server platform, probably Linux. Several AFS Volumes exist across multiple servers. With many clients.

Act The First.

The Penguin acts friendly but is very deceiving. It pretends to be friendly and clean. But when you look really close you see it hasn’t had a bath in years. OpenAFS deals with him pretty well though, being itself, just a herd of cattle.

Act The Second.

The Penguin acts as a jail keeper, with the yak, chroot, herding the cattle into the jail (I’m stretching WORK WITH ME DAMNIT). The Penguin though isn’t a very good jail keeper. Because the cattle can leave any time they want, as long as they don’t try to go out the way they came in. EG: Linux only compares the inode you’re traversing with the inode you were chrooted to. This is fine in many cases. In AFS’ case, when you mount a volume multiple times, it’s inode will show up in multiple places. So if you traverse up you can get out of your jail first, and second, you’ll end up somewhere you don’t expect.

vos create volume1

vos create volume2

cd /afs/cell

fs mkm vol1 mnt

cd mnt

fs mkm vol2 mnt1

cd ..

mkdir b

cd b

fs mkm vol2 mnt2

cd /afs/cell/mnt/mnt1

stat .

cd /afs/cell/b/mnt2

cd .. (NOT BASH CD, chdir(..))

pwd

/afs/cell/mnt

WTF. Well after deep investigation by myself I figure out it’s definitely a Linux only issue. David Brashear looked into it really closely and came tot eh conclusion I did, it’s basically impossible to fix since Linux doesn’t allow aliases of directory inodes, only files.

So. Basically any time you have an AFS volume mounted in more than one place you’ll end up in an apparently random location when you traverse it’s .. (parent) reference.

And this sounded so much better in my head. Ahwel.