On Fri, Sep 21, 2007 at 12:09:27PM +0200, Pierre LEBRECH wrote:
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=2048, ...}) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
> getdents64(3, /* 3 entries */, 1024)    = 88
> lstat64("mount-point-test", 0x805c8ac)  = -1 ENOENT (No such file or directory)
> getdents64(3, /* 0 entries */, 1024)    = 0
> close(3)                                = 0

Ok, this is the bit where it opens the directory, reads the contents (3
entries, which I guess are '.', '..', and 'mount-point-test') and then
calls stat on the new mountpoint.

The stat fails with ENOENT, which is why ls shows the strange output.
But I have no idea why we're getting that error. I can't seem to
reproduce that behaviour here.

I wonder if the ENOENT error comes from venus, or if the kernel simply
has cached the fact that that path didn't exist.... Ok, I think I
managed to reproduce the problem,

I managed to reproduce your problem when I do the following,

    ls -l testvol
    cfs mkm testvol testvolume
    ls -l testvol

So the explicit lookup for the non-existing testvol name ended up
populating the kernel cache with a negative dentry. This negative entry
isn't dropped once the mountpoint is created, but I can get it to work
when I force an upcall which tells the kernel to flush the parent
directory and it's children,

    cfs er .
    ls -l testvol

Jan