gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Serial Thrilla
Subject: Re: [Gluster-devel] glusterfs_open() glusterfs_fstat() glusterfs_readdir() bug?
Date: Fri, 27 Mar 2009 00:45:35 -0700
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

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).

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
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________ Gluster-devel mailing
>>>  list address@hidden
>>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database:
>> 270.11.29/2024 - Release Date: 03/26/09 07:12:00
>>
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
> 
> 
> ------------------------------------------------------------------------
> 
> No virus found in this incoming message.
> Checked by AVG. 
> Version: 7.5.557 / Virus Database: 270.11.28 - Release Date: 3/25/2009 12:00 
> AM
struct dirent
  {
#ifndef __USE_FILE_OFFSET64
    __ino_t d_ino;
    __off_t d_off;
#else
    __ino64_t d_ino;
    __off64_t d_off;
#endif
    unsigned short int d_reclen;
    unsigned char d_type;
    char d_name[256];           /* We must not include limits.h! */
  };

reply via email to

[Prev in Thread] Current Thread [Next in Thread]