[Gluster-devel] Duplicate entries and other weirdness in a 3*4 volume

[Soumya Koduri]

On 07/21/2014 05:35 PM, Xavier Hernandez wrote:
> On Monday 21 July 2014 13:53:19 Anders Blomdell wrote:
>> On 2014-07-21 13:49, Pranith Kumar Karampuri wrote:
>>> On 07/21/2014 05:17 PM, Anders Blomdell wrote:
>>>> On 2014-07-21 13:36, Pranith Kumar Karampuri wrote:
>>>>> On 07/21/2014 05:03 PM, Anders Blomdell wrote:
>>>>>> On 2014-07-19 04:43, Pranith Kumar Karampuri wrote:
>>>>>>> On 07/18/2014 07:57 PM, Anders Blomdell wrote:
>>>>>>>> During testing of a 3*4 gluster (from master as of yesterday), I
>>>>>>>> encountered>>>>>>
>>>>>>>> two major weirdnesses:
>>>>>>>>       1. A 'rm -rf <some_dir>' needed several invocations to finish,
>>>>>>>>       each time
>>>>>>>>
>>>>>>>>          reporting a number of lines like these:
>>>>>>>>                rm: cannot remove ‘a/b/c/d/e/f’: Directory not empty
>>>>>>>>
>>>>>>>>       2. After having successfully deleted all files from the volume,
>>>>>>>>
>>>>>>>>          i have a single directory that is duplicated in gluster-fuse,
>>>>>>>>
>>>>>>>>          like this:
>>>>>>>>        # ls -l /mnt/gluster
>>>>>>>>
>>>>>>>>             total 24
>>>>>>>>             drwxr-xr-x 2 root root 12288 18 jul 16.17 work2/
>>>>>>>>             drwxr-xr-x 2 root root 12288 18 jul 16.17 work2/
>>>>>>>>
>>>>>>>> any idea on how to debug this issue?
>>>>>>>
>>>>>>> What are the steps to recreate? We need to first find what lead to
>>>>>>> this. Then probably which xlator leads to this.>>>>
>>>>>> Would a pcap network dump + the result from 'tar -c --xattrs
>>>>>> /brick/a/gluster' on all the hosts before and after the following
>>>>>> commands are run be of>>>>
>>>>>> any help:
>>>>>>      # mount -t glusterfs gluster-host:/test /mnt/gluster
>>>>>>      # mkdir /mnt/gluster/work2 ;
>>>>>>      # ls /mnt/gluster
>>>>>>      work2  work2
>>>>>
>>>>> Are you using ext4?
>>>>
>>>> Yes
>>>>
>>>>> Is this on latest upstream?
>>>>
>>>> kernel is 3.14.9-200.fc20.x86_64, if that is latest upstream, I don't
>>>> know.
>>>> gluster is from master as of end of last week
>>>>
>>>> If there are known issues with ext4 i could switch to something else, but
>>>> during the last 15 years or so, I have had very little problems with
>>>> ext2/3/4, thats the reason for choosing it.
>>>
>>> The problem is afrv2 + dht + ext4 offsets. Soumya and Xavier were working
>>> on it last I heard(CCed)
>> Should I switch to xfs or be guinea pig for testing a fixed version?
>
> There is a patch for this [1]. It should work for this particular
> configuration, but there are some limitations in the general case, specially
> for future scalability, that we tried to solve but it seems quite difficult.
> Maybe Soumya has newer information about that.
>
> XFS should work without problems if you need it.
>

Thats right. This patch works fine with the current supported/limited 
configuration. But we need a much more generalized approach or maybe a 
design change as Xavi had suggested to make it more scalable.

The problem in short --
'ext4' uses large offsets/the bits which even GlusterFS may need to 
store subvol id along with the offset. This could be end up in few 
offsets being modified when given back to the filesystem resulting in 
missing files etc.
Avati has proposed a solution to overcome this issue based on the 
assumption that "both EXT4/XFS are tolerant in terms of the accuracy of 
the value presented back in seekdir(). i.e, a seekdir(val) actually 
seeks to the entry which has the "closest" true offset. For more info, 
please check http://review.gluster.org/#/c/4711/.

But this offset gap widens as and when more translators (which need to 
store subvol-id) get added to the gluster stack which may eventually 
result in the similar issue which you are facing now.

Thanks,
Soumya

> Xavi
>
> [1] http://review.gluster.org/8201/
>