[Bugs] [Bug 1256580] New: sharding - VM image size as seen from the mount keeps growing beyond configured size on a sharded volume

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1256580

            Bug ID: 1256580
           Summary: sharding - VM image size as seen from the mount keeps
                    growing beyond configured size on a sharded volume
           Product: GlusterFS
           Version: mainline
         Component: sharding
          Assignee: bugs at gluster.org
          Reporter: kdhananj at redhat.com
        QA Contact: bugs at gluster.org
                CC: bugs at gluster.org



Description of problem:

In the virt-store use case, on a sharded volume the size of what is supposed to
be a 15G image was observed to have grown to 17G (subsequently 21G) as seen on
the mount point, as and when IO was performed within the VM's /home directory,
On inspecting the file copy on the brick(s), the
trusted.glusterfs.shard.file-size was found to match the size presented in the
ls -lh output on the mount point. This means that something went wrong in the
accounting of file size by the sharding translator.
On reading code, I figured this is due to the fact that in inode write fops
(particularly writev), shard translator counts the change in size by
calculating the difference between the postbuf.ia_size and prebuf.ia_size for
each shard where a write() was done, eventually adding up the deltas of all
shards that participated in this write and incrementing the size xattr by that
amount. But if the writes are on hole regions (which means the participant
shard lies somewhere within the actual file size boundary) then there is no
need to add its change in size to the size xattr. In other words, the deltas
need to be taken into account only for writes that cross the current file size
boundary.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.