<div dir="ltr">Please find my response inline:<br><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 4:03 PM, Gandalf Corvotempesta <span dir="ltr"><<a href="mailto:gandalf.corvotempesta@gmail.com" target="_blank">gandalf.corvotempesta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>2016-07-18 12:25 GMT+02:00 Krutika Dhananjay <<a href="mailto:kdhananj@redhat.com" target="_blank">kdhananj@redhat.com</a>>:<br>
> Hi,<br>
><br>
> The suggestion you gave was in fact considered at the time of writing shard<br>
> translator.<br>
> Here are some of the considerations for sticking with a single directory as<br>
> opposed to a two-tier classification of shards based on the initial chars of<br>
> the uuid string:<br>
> i) Even for a 4TB disk with the smallest possible shard size of 4MB, there<br>
> will only be a max of 1048576 entries<br>
> under /.shard in the worst case - a number far less than the max number of<br>
> inodes that are supported by most backend file systems.<br>
<br>
</span>This with just 1 single file.<br>
What about thousands of huge sharded files? In a petabyte scale cluster, having<br>
thousands of huge file should be considered normal.<br>
<span><br>
> iii) Resolving shards from the original file name as given by the<br>
> application to the corresponding shard within a single directory (/.shard in<br>
> the existing case) would mean, looking up the parent dir /.shard first<br>
> followed by lookup on the actual shard that is to be operated on. But having<br>
> a two-tier sub-directory structure means that we not only have to resolve<br>
> (or look-up) /.shard first, but also the directories '/.shard/d2',<br>
> '/.shard/d2/18', and '/.shard/d2/18/d218cd1c-4bd9-40d7-9810-86b3f7932509'<br>
> before finally looking up the shard, which is a lot of network operations.<br>
> Yes, these are all one-time operations and the results can be cached in the<br>
> inode table, but still on account of having to have dynamic gfids (as<br>
> opposed to just /.shard, which has a fixed gfid -<br>
> be318638-e8a0-4c6d-977d-7a937aa84806), it is trivial to resolve the name of<br>
> the shard to gfid, or the parent name to parent gfid _even_ in memory.<br>
<br>
</span>What about just 1 single level?<br>
/.shard/d218cd1c-4bd9-40d7-9810-86b3f7932509/d218cd1c-4bd9-40d7-9810-86b3f7932509.1<br>
?<br>
<br>
You have the GFID, thus there is no need to crawl multiple levels,<br>
just direct-access to the proper path.<br>
<br>
With this soulution, you have 1.048.576 entries with a 4TB shared file<br>
with 4MB shard size.<br>
With the current implementation, you have 1.048.576 for each sharded<br>
file. If I have 100 4TB files, i'll end<br>
with 1.048.576*100 = 104.857.600 files in a single directory.<br></blockquote><div><br></div><div>No. Note that all files and directories under /.shard are like normal files and directories to the file-system, it is just<br></div><div>shard translator that has a special way of interpreting this layout of files. What this means is that each file and directory at and under /.shard will need to have its own unique gfid. In other words, for this layout you suggested:<br><br>/.shard/d218cd1c-4bd9-40d7-9810-86b3f7932509/d218cd1c-4bd9-40d7-9810-86b3f7932509.1<br><br></div><div>the sub-directory /.shard/d218cd1c-4bd9-40d7-9810-86b3f7932509/ will not have the gfid d218cd1c-4bd9-40d7-9810-86b3f7932509 because this is already assigned to the original file that was sharded based on whose gfid we are naming the rest of the shards. This means the subdir will have a new gfid assigned to it, as will the file d218cd1c-4bd9-40d7-9810-86b3f7932509.1. Does that make sense? You can actually create a file and do writes so that it gets sharded and go to /.shard directory and see how the block file (<gfid>.N where N=1,2,3...) gets a new gfid. That should give you some understanding of inodes and gfids in gluster maybe.<br><br></div><div>I agree with the math that you did above. It's just that I am not particularly sure to what extent this new classification approach will actually improve the performance, not discounting the price we pay in terms of the number of lookups needed to initially resolve shards with the new solution.<br></div><div><br></div><div>-Krutika<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> Are you unhappy with the performance? What's your typical VM image size,<br>
> shard block size and the capacity of individual bricks?<br>
<br>
</span>No, i'm just thinking about this optimization.<br>
</blockquote></div><br></div></div>