<html><body><div style="font-family: garamond,new york,times,serif; font-size: 12pt; color: #000000"><div>You are right!<br></div><div><br></div><div>So this is what I ran on the volume with bricks in ext4 partition: dd if=/dev/urandom of=file bs=1024 seek=3072 count=2048 conv=notrunc<br></div><div><br></div><div>with shard-block-size being 4M. As you can see, the command creates a sparse 5M file with holes in first 3M.</div><div>This means the first block file will mostly be sparse, with the second block file (the one holding the last 1M of data) looking like a normal file.<br></div><div><br></div><div>[root@calvin mnt]# dd if=/dev/urandom of=file bs=1024 seek=3072 count=2048 conv=notrunc<br>2048+0 records in<br>2048+0 records out<br>2097152 bytes (2.1 MB) copied, 0.875319 s, 2.4 MB/s<br>[root@calvin mnt]# du file<br>2052 file<br><br></div><div> ... while on the volume with xfs bricks, the number reads 3012.<br></div><div>I added trace logs to see what his happening in the latter case. The posix translator in gluster seems to return more blocks than actually written to if the file is sparse (in this case for the first block file).<br></div><div>And for the second file, it is returning blocks as 1 block per 512bytes of data written. And sharding relies on the values returned by posix translator to keep an account of the size and block count.</div><div><br></div><div> I will need some more time to understand why this is so. I will let you know soon as I've figured it out.<br></div><div><br></div><div>Thanks for the report.<br></div><div><br></div><div>-Krutika<br></div><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Lindsay Mathieson" <lindsay.mathieson@gmail.com><br><b>To: </b>"Krutika Dhananjay" <kdhananj@redhat.com><br><b>Cc: </b>"gluster-users" <gluster-users@gluster.org><br><b>Sent: </b>Friday, November 6, 2015 7:58:42 PM<br><b>Subject: </b>Re: [Gluster-users] Shard file size (gluster 3.7.5)<br><div><br></div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 6 November 2015 at 17:22, Krutika Dhananjay <span dir="ltr"><<a href="mailto:kdhananj@redhat.com" target="_blank" data-mce-href="mailto:kdhananj@redhat.com">kdhananj@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" data-mce-style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;"><div>Sure. So far I've just been able to figure that GlusterFS counts blocks in multiples of 512B while XFS seems to count them in multiples of 4.0KB.<br></div><div>Let me again try creating sparse files on xfs, sharded and non-sharded gluster volumes and compare the results. I'll let you know what I find.<br></div><div><br></div></blockquote></div><br><div><br></div><br></div><div class="gmail_extra">I repeated the tests with a single gluster brick on a ext4 partition - disk usage (du) and file size were exactly right.<br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature">Lindsay</div></div></div></blockquote><div><br></div></div></body></html>