[OpenAFS-devel] mount-point inode-number inconsistencies with openafs-1.4.1

[chas williams - CONTRACTOR]

In message <447C75A0.60003@strike.wu-wien.ac.at>,Alexander Bergolth writes:
>When determining the inode-numbers of the mount-points and using
>relative path names, different inode numbers are shown when called for
>the first time. On subsequent calls the same inode numbers are shown (!)
>until I do a "pwd", then the behavior is reset and the next call prints
>different inode numbers again:

linux doesnt handle having a directory inode mounted twice in the
same filesystem very well.  the linux vfs operates on pathnames
more than inodes, so there needs to be only one dcache entry per
inode directory.  since you have two paths to the same inode,
we need to pick which dcache entry to keep current.  in 1.4.1
this is now the latest dcache entry (it cured a different bug
in the vfs filesystem) instead of the "first found" dcache entry.

when a new dcache entry is chosen, the inode number is updated.
i believe the inode number is based on the mount point so this is
going to lead to different inode numbers.

>-------------------- snip! --------------------
>$ ls -id1 . backup backup/backup
>278020792 .
>193265714 backup
>193265714 backup/backup

here you switch to from the original path to a new path so
the inode number changed.

>$ ls -id1 . backup backup/backup
>193265714 .
>193265714 backup
>193265714 backup/backup

referencing . still stays on the current path.

>$ pwd
>/afs/wu-wien.ac.at/home/edvz/skamrada/logs
>$ ls -id1 . backup backup/backup
>278020792 .

ah, you found a "new" (different) path to the same volume.
we switch back.  but again, you reference the other path
and we switch the inode back.

>193265714 backup
>193265714 backup/backup
>-------------------- snip! --------------------

i dont have a good answer for this other than "dont do that".  the aix
behavior is interesting.

>P.S.: I also noticed several hangs with 1.4.1. where one filesystem
>operation blocks forever and seems to lock out any other openafs
>file-operations until a reboot. I can send you some kernel-stack-traces
>of hanging processes on request.

this might be interesting.  what are you doing to make this
happen?