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
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users