On 11/18/2014 06:56 AM, Pranith Kumar Karampuri wrote:
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@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?
Hey, nice. This will really speed up full heals for most common vm images.
_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users
