Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

> There actually are 2 objects in the same location. One is the mount link
> which exists in the parent volume, the other is the root directory of
> the mounted volume that 'covers' the mount link object. In this case the
> lookup is passed to venus and it will traverse to the root directory
> object whenever it ends on the mount link. The ls -ai output will also
> be correct because ls calls stat(2) on each object, in which case venus
> will traverse to the root directory object if we end on the mount link.
>
> The problem with pwd is that it uses the inode numbers that are stored
> in the parent directory, which for mount points is actually the hashed
> fid of the mount link object instead of the root directory of the
> mounted volume.

So how does this work on for a regular ufs-on-ufs mount?  It seems that
the inode number in the directory is fixed up before readdir.

poblano gdt 6 / > l -aid usr
2 drwxr-xr-x  25 root  wheel  1024 Aug 23 16:17 usr
poblano gdt 7 / > l -aid usr/.
2 drwxr-xr-x  25 root  wheel  1024 Aug 23 16:17 usr/.

But, venus mount points aren't unix mount points, so the kernel vfs
layer doesn't get to deal.

I suppose the real problem is that venus is passing a directory
container file.  Perhaps it has to cons one up.  Or perhaps modify the
inode in the on-disk directory entry (presumably after reading from
server and before writing to container file), because there's no need to
have the old inode number in the container file.

> So when pwd wants to figure out which directory entry we are in the
> parent, it gets the inode number from '.' and then does a readdir on
> '..' until it finds an entry with a matching inode number. But there
> really isn't a match because the parent directory really contains a
> symbolic link object. If pwd were to call stat on every directory entry
> it would be able to find a match because venus would return the
> attributes of the mounted object instead, but calling stat on every
> directory entry is more expensive.

So if I run through again and stat on failure, then maybe that's ok.
But that feels like adding workarounds to the kernel for what feels to
me like a venus bug.

> And this doesn't only happen for the root of a volume, but also in other
> situations where an object from a different volume ends up mounted over
> an existing object, for instance when we expand a conflict.

OK, but pwd not working during conflicts is not as big a bug.  pwd not
working means that lots of programs fail, like gnumeric,
soffice, acroread.