[Gluster-users] Sparse Files and Heal

[Pranith Kumar Karampuri]

On 11/18/2014 05:35 PM, Lindsay Mathieson wrote:
>
> I have a VM image which is a sparse file - 512GB allocated, but only 
> 32GB used.
>
> root at vnb:~# ls -lh /mnt/gluster-brick1/datastore/images/100
>
> total 31G
>
> -rw------- 2 root root 513G Nov 18 19:57 vm-100-disk-1.qcow2
>
> I switched to full sync and rebooted.
>
> heal was started on the image and it seemed to be just transfering the 
> full file from node vnb to vng. iftop showed bandwidth at 500 Mb/s
>
> Eventually the cumulative transfer got to 140GB which seemed odd as 
> the real file size was 31G. I logged onto the second node (vng) and 
> the *real* file size size was up to 191Gb.
>
> It looks like the heal is not handling sparse files, rather it is 
> transferring empty bytes to make up the allocated size. Thats a 
> serious problem for the common habit of over committing your disk 
> space with vm images. Not to mention the inefficiency.
>
Ah! this problem doesn't exist in diff self-heal :-(. Because the 
checksums of the files will match in the sparse regions. In full 
self-heal it just reads from the source file and writes to the sink 
file. What we can change there is if the file is a sparse file and the 
data that is read is all zeros (read will return all zeros as data in 
the sparse region) then read the stale file and compare if it is also 
all zeros. If both are 'zeros' then skip the write. I also checked that 
if the sparse file is created while the other brick is down, then also 
it preserves the holes(i.e. sparse regions). This problem only appears 
when both the files in their full size exist on both the bricks and full 
self-heal is done like here :-(.

Thanks for your valuable inputs. So basically you found 2 issues. I will 
raise 2 bugs one for each of the issues you found. I can CC you to the 
bugzilla, so that you can see the update on the bug once it is fixed. Do 
you want to be CCed to the bug?

Pranith
>
> thanks,
>
> -- 
>
> Lindsay
>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20141118/9891c70e/attachment.html>