Re: [Gluster-devel] glusterfs_open() glusterfs_fstat() glusterfs_readdir() bug?

[Serial Thrilla]

Which system do you use?

I checked CentOS4, CentOS5, and CentOS5-x86_64 and all d_reclen members 
are "unsigned short int".

I think we may also have to be careful because there are d_reclen and 
d_namlen. It appears that d_reclen can be the size of the dirent struct 
or it can be the length of d_name depending if d_namlen exists or not.

I checked other systems (http://fxr.watson.org/) and it looked like most 
of them had a d_reclen of 16bits and I noticed one even had a d_namlen 
of 8 bits.

Thanks Shehjar!

Rob Olmos


Shehjar Tikoo wrote:
> Serial Thrilla wrote:
> > I was doing some investigation into the glusterfs_readdir() issue:
> >
> > On my system, dirent struct member "d_reclen" is an "unsigned short int"
> > but the _gf_dirent_t dirent struct "d_len" member is a uint32_t
> > (unsigned long int).
>
> That seems to be an indicator of a problem because the second
> glfs.c test works fine on an empty directory on my system.
>
> I'll be looking into this next week.
>
> Thanks
> -Shehjar
>
> > libglusterfsclient.c line 2438 has:
> >
> > dirp->d_reclen = entry->d_len;
> >
> > It looks to me like that value is too big and possibly not storing the
> > correct record length. May also explain why the line before:
> >
> > /* dirp->d_type = entry->d_type; */
> >
> > is commented out because it was being overwritten by the d_reclen
> > assignment.
> >
> > Since this value is being stored incorrectly, line 2440 then uses the
> > reclen from dirent for the null byte. Might explain why I get a huge
> > reclen and only get one random character as the entry name.
> >
> > Attached is my system's dirent struct.
> >
> > Thanks!
> > Rob
> >
> >
> > Serial Thrilla wrote:
> > > Thanks! That patch fixes the glusterfs_fstat() call.
> > > Unfortunately, glusterfs_readdir() wasn't fixed.
> > >
> > > Attached is the new code, output, and logs. At the moment there are no
> > > entries in /home/export/ so I'm not sure why it is returning "f" and
> > > then another return with no name.
> > >
> > > I had an issue before with 3 entries in /home/export (test, test2,
> > > test3). It was returning 4 items from glusterfs_readdir() and they were
> > > all one letter names like "P", "[".
> > >
> > > The "count" parameter for glusterfs_readdir() doesn't appear to be used
> > > so I made it 0 for now. Changing it to other values has no effect.
> > >
> > >
> > > Thanks
> > > Rob
> > >
> > >
> > > Shehjar Tikoo wrote:
> > > > Hi
> > > >
> > > > Thanks for the report. The attached patch should fix this problem
> > > > for rc7. The test program, glfs.c, works fine for me with this
> > > > patch applied while using the volfiles supplied. Could you please
> > > > confirm if this works for your setup?
> > > >
> > > > Thanks
> > > > Shehjar
> > > >
> > > > Serial Thrilla wrote:
> > > > > Hey all, attached are the code and output of server and client.
> > > > >
> > > > > *Please be aware that the server and client run on the same machine*
> > > > >
> > > > > glusterfs_open() will return a file descriptor but glusterfs_fstat()
> > > > >  returns -1 for that descriptor.
> > > > >
> > > > > Is it normal for the file descriptor to change on each call to
> > > > > glusterfs_open() despite the same parameters?
> > > > >
> > > > > Also, I was having issues with glusterfs_readdir() but that wasn't
> > > > > working either so I suspect there's an issue with the descriptor.
> > > > >
> > > > > Please let me know if you need any more info.
> > > > >
> > > > > Attn core developers: Please let me know if you would like access to
> > > > > my dev box and I'll be happy to provide it.
> > > > >
> > > > > Thanks Rob
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.0.238 / Virus Database: 270.11.30/2026 - Release Date: 03/27/09 07:13:00