Christian Schmidt wrote:
> I'm having a little problem using a NFS-exported JFS.
>
> The symptom:
>
> The last entry in a directory does not show up when using the midnight
> commander, xmms, find or similar programs. It shows up when using ls or
> "echo *", though.
> This does however not happen with exported ext3 or reiserfs volumes.
> It is independent of the nfs daemon used (linux kernel / userspace nfs
> daemon tried).
I've just found out what makes the difference:
The following little program is supposed to list the complete directory
content:
#include <sys/types.h>
#include <dirent.h>
#include <stdio.h>
int main () {
DIR * work;
struct dirent * current;
work = opendir (".");
if (!work) return 0;
while ((current = readdir (work)) != NULL)
printf ("Found: %s\n", current->d_name);
closedir (work);
}
If compiled with -D_FILE_OFFSET_BITS=64 everything works fine, if compiled
without, the last entry is missing.
Compiling JFS with debugging yielded nothing.
The little difference of -D_FILE_OFFSET_BITS=64 makes me wonder where
the bug is located. On the one hand, with JFS the difference lies on the
client side - compiling a local program with 64bit filesize support
makes all the difference. On the other hand, other exported filesystems
do not make a difference - this indicates server side. Anyway, this is
my first occurance of a program (part) that is 64bit clean, but doesn't
work with 32bit.
Using ethereal I can see the data sent from the server to the client
appears complete - I can see the lookup for every dentry, and the reply
for every request, even those later not shown.
Taking a deeper look into the captured data for an explanation I found a
difference in the result of the READDIR operations on the exported JFS
and the exported EXT3: the "Cookie" field of the last entry of the JFS
is 2^32-1 (-1 for a 32 bit integer), while it's 4096 for EXT3.
Now it's 3am, another sunday is gone, and - the -1 is it. If I change it
in the kernel NFS code to be a positive integer, everything is fine -
but still the question is who to blame.
The JFS folks that push their endofdirectory marker up?
The NFS folks that set their cookies to some arbitrary values from the
FS below (or possibly cause the trouble in their code)?
Or is it just a misinterpretation in glibc? We'll see next weekend...
Regards,
Christian
PS: NFS v3 seems not to have this problem...
_______________________________________________
Jfs-discussion mailing list
[EMAIL PROTECTED]
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
