A play in one act.
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
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
fs mkm vol1 mnt
fs mkm vol2 mnt1
fs mkm vol2 mnt2
cd .. (NOT BASH CD, chdir(..))
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.