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
