<div dir="ltr"><div><div><div><div>Hi,<br><br></div>The suggestion you gave was in fact considered at the time of writing shard translator.<br></div>Here are some of the considerations for sticking with a single directory as opposed to a two-tier classification of shards based on the initial chars of the uuid string:<br></div>i) Even for a 4TB disk with the smallest possible shard size of 4MB, there will only be a max of 1048576 entries<br></div><div> under /.shard in the worst case - a number far less than the max number of inodes that are supported by most backend file systems.<br><br></div><div>ii) Entry self-heal for a single directory even with the simplest case of 1 entry deleted/created while a replica is down required crawling the whole sub-directory tree, figuring which entry is present/absent between src and sink and then healing it to the sink. With granular entry self-heal [1], we no longer have to live under this limitation.<br><br></div><div>iii) Resolving shards from the original file name as given by the application to the corresponding shard within a single directory (/.shard in the existing case) would mean, looking up the parent dir /.shard first followed by lookup on the actual shard that is to be operated on. But having a two-tier sub-directory structure means that we not only have to resolve (or look-up) /.shard first, but also the directories '/.shard/d2', '/.shard/d2/18', and '/.shard/d2/18/d218cd1c-4bd9-40d7-9810-86b3f7932509' before finally looking up the shard, which is a lot of network operations. Yes, these are all one-time operations and the results can be cached in the inode table, but still on account of having to have dynamic gfids (as opposed to just /.shard, which has a fixed gfid - be318638-e8a0-4c6d-977d-7a937aa84806), it is trivial to resolve the name of the shard to gfid, or the parent name to parent gfid _even_ in memory.<br><br></div><div><br></div><div>Are you unhappy with the performance? What's your typical VM image size, shard block size and the capacity of individual bricks?<br><br></div><div>-Krutika<br></div><span style="color:rgb(34,34,34);font-family:Roboto-Regular,helvetica,arial,sans-serif;font-size:30px;font-style:normal;font-variant:normal;font-weight:100;letter-spacing:normal;line-height:30px;text-align:left;text-indent:0px;text-transform:none;white-space:nowrap;word-spacing:0px;display:inline!important;float:none;background-color:rgb(255,255,255)"></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 2:43 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2016-07-18 9:53 GMT+02:00 Oleksandr Natalenko <<a href="mailto:oleksandr@natalenko.name">oleksandr@natalenko.name</a>>:<br>
> I'd say, like this:<br>
><br>
> /.shard/d2/18/D218CD1C-4BD9-40D7-9810-86B3F7932509.1<br>
<br>
</span>Yes, something like this.<br>
I was on mobile when I wrote. Your suggestion is better than mine.<br>
<br>
Probably, using a directory for the whole shard is also better and<br>
keep the directory structure clear:<br>
<br>
/.shard/d2/18/D218CD1C-4BD9-40D7-9810-86B3F7932509/D218CD1C-4BD9-40D7-9810-86B3F7932509.1<br>
<br>
The current shard directory structure doesn't scale at all.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-users</a><br>
</div></div></blockquote></div><br></div>