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

[Alexander Bergolth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/30/2006 07:42 PM, chas williams - CONTRACTOR wrote:
> 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.

Hmm - I didn't get it...
Working directory is /afs/wu-wien.ac.at/home/edvz/skamrada and I'm
referencing . backup and backup/backup, so it's 3 paths (and 3 mount
points), isn't it?

/afs/wu-wien.ac.at/home/edvz/skamrada/logs
/afs/wu-wien.ac.at/home/edvz/skamrada/logs/backup
/afs/wu-wien.ac.at/home/edvz/skamrada/logs/backup/backup

>>$ 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.

Why does pwd cause this?

>>193265714 backup
>>193265714 backup/backup
>>-------------------- snip! --------------------
> 
> i dont have a good answer for this other than "dont do that".  the aix
> behavior is interesting.

The problem is that we are not able to control what users are doing. Of
course this mount-point loops are not desirable but the problem is that
one user may add such a mount-point and render other user's applications
that traverse the filesystem (like find) unusable.

In the first case
278020792 .
193265714 backup
193265714 backup/backup
... find detects the loop not until entering backup/backup and tries to
skip this directory. But when going back, the inode number of . also
changes so find walks up one level too much which brings it out of sync.

If the inode number of the first directory at least didn't change, as it
was the case in OpenAFS 1.3.8x, some applications wouldn't break.

Cheers,
- --leo
- --
- -----------------------------------------------------------------------
Alexander.Bergolth@wu-wien.ac.at                Fax: +43-1-31336-906050
Zentrum fuer Informatikdienste - Wirtschaftsuniversitaet Wien - Austria


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEfvtlsYaksEkoAQMRAia+AJ9HU1IzXxkCjO8dbhKRpQGgHiNJvgCePRZw
tnrY0oH8UYxdCnegvmFT8hQ=
=ZXHz
-----END PGP SIGNATURE-----