While looking for an entirely unrelated bug, I stumbled onto something
odd. I found a test system that would fail to find some directory
entries when doing a readdir if there were more than 32 files in the
directory. On other test systems it worked fine.
Looking at strace, I saw that the system that was failing had one or
more lseek calls on the directory file descriptor. These were not
generated directly by my test program.
It turns on that glibc will do seeks in some cases as part of
implementing readdir, but I haven't tried to understand why yet. The
code is in the glibc source at sysdeps/unix/sysv/linux/getdents.c.
At any rate, seeking on pvfs2 directories doesn't work because we assign
special meaning to the f_pos field on the directory in order to keep up
with directory tokens. I implemented a pvfs_dir_llseek() to work around
this by translating f_pos into something pvfs will understand. It
handles probably all of the cases that glibc will generate, but there
are certain positions that we can't handle without bigger changes if I
understand the code correctly.
I don't know if there is anything else floating around out there that
will try to seek on pvfs directories. I'm curious if it has anything to
do with the weird "nfs export 26th entry" bug:
http://www.beowulf-underground.org/pipermail/pvfs2-users/2007-December/002221.html
I'm only checking this dir seek implementation into trunk for now until
to make sure it doesn't have any unexpected side effects.
-Phil
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
