[Gluster-users] Vol full of .*.gfs* after migrate-data

Dan Bretherton d.a.bretherton at reading.ac.uk
Sun Jan 1 23:35:38 UTC 2012


> On 03/10/11 19:08, Dan Bretherton wrote:
>>
>> On 02/10/11 02:12, Amar Tumballi wrote:
>>> Dan,
>>>
>>> Answer inline.
>>>
>>> On 02-Oct-2011, at 1:26 AM, Dan 
>>> Bretherton<d.a.bretherton at reading.ac.uk>  wrote:
>>>
>>>> Hello All,
>>>> I have been testing rebalance...migrate-data in GlusterFS version 
>>>> 3.2.3, following add-brick and fix-layout.  After migrate-data the 
>>>> the volume is 97% full with some bricks being 100% full.  I have 
>>>> not added any files to the volume so there should be an amount of 
>>>> free space at least as big as the new bricks that were added.  
>>>> However, it seems as if all the extra space has been taken up with 
>>>> files matching the pattern .*.gfs*.  I presume these are temporary 
>>>> files used for the transfer real files, which should have been 
>>>> renamed once the transfers were completed and verified, and the 
>>>> original versions deleted.  The new bricks contain mostly these 
>>>> temporary files, and zero byte link files pointing to the 
>>>> corresponding real files on other bricks.  An example of such a 
>>>> pair is shown below.
>>>>
>>>> ---------T 1 root root 0 Sep 30 03:14 
>>>> /mnt/local/glusterfs/root/backup/behemoth_system/bin
>>>> -rwxr-xr-x 1 root root 60416 Sep 30 18:20 
>>>> /mnt/local/glusterfs/root/backup/behemoth_system/bin/.df.gfs60416
>>>>
>>>> Is this a known bug, and is there a work-around?  If not, is it 
>>>> safe to delete the .*.gfs* files so I can at least use the volume?
>>>>
>>> This is not a known issue but surely seems like a bug. If the source 
>>> file is intact you can delete the temp file to get the space back. 
>>> Also if md5sum is same, you can rename temp file to original, so you 
>>> get space in existing bricks.
>>>
>>> Regards,
>>> Amar
>>>
>>>
>>>> Regards
>>>> Dan Bretherton
>>>>
>>>> _______________________________________________
>>>> Gluster-users mailing list
>>>> Gluster-users at gluster.org
>>>> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>> Amar- Thanks for the information and the patch.  The 
>> etc-glusterd-mount-<volname>.log file can be downloaded from here:
>>
>> http://www.nerc-essc.ac.uk/~dab/etc-glusterd-mount-backup.log.tar.gz
>>
>> I am using CentOS 5.5 by the way.
>>
>> -Dan.
>>
> Hello again-
> I tested the patch and I confirm that it works; there are no *.gfs* 
> files in my volume after performing a migrate-data operation.  However 
> there is still something not quite right.  One of the replicated brick 
> pairs is 100% full, whereas the others are approximately 50% full.  I 
> would have expected all the bricks to contain roughly the same amount 
> of data after migrate-data, and this effect is mainly what I want to 
> use migrate-data for.  Do you why this might have happened or how to 
> avoid it?  The log files from the latest migrate-data operation can be 
> downloaded from here:
>
> http://www.nerc-essc.ac.uk/~dab/backup_migrate-data_logs.tar.gz
>
> -Dan.

Hello Amar and gluster-users,

I have tested rebalance...migrate-data in version 3.2.5 and found three 
serious problems still present.

1) There are lots of *.gfs* files after migrate-data.  This didn't 
happen when I tested the patched version of 3.2.4.
2) There are lots of duplicate files after migrate-data, i.e. lots of 
files seen twice at the mount point.  I have never seen this happen 
before, and I would really like to know how to repair the volume.  There 
are ~6000 duplicates out of a total of ~1 million files in the volume, 
so dealing with each one individually would be impractical.
3) A lot of files have wrong permissions after migrate-data.  For 
example, -rwsr-xr-x commonly becomes -rwxr-xr-x, and -rw-rw-r-- commonly 
becomes -rw-r--r--.

Are these known problems, and if so is there a new version with fixes in 
the pipeline?

Regards
Dan.




More information about the Gluster-users mailing list