<html><body><div style="font-family: garamond,new york,times,serif; font-size: 12pt; color: #000000"><div><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>"Vijay Bellur" <vbellur@redhat.com><br><b>To: </b>"Krutika Dhananjay" <kdhananj@redhat.com>, "Gluster Devel" <gluster-devel@gluster.org><br><b>Sent: </b>Monday, February 23, 2015 5:25:57 PM<br><b>Subject: </b>Re: [Gluster-devel] Sharding - Inode write fops - recoverability from failures - design<br><div><br></div>On 02/22/2015 06:08 PM, Krutika Dhananjay wrote:<br>> Hi,<br>><br>> Please find the design doc for one of the problems in sharding which<br>> Pranith and I are trying to solve and its solution @<br>> http://review.gluster.org/#/c/9723/1.<br>> Reviews and feedback are much appreciated.<br>><br><div><br></div>Can this feature be made optional? I think there are use cases like <br>virtual machine image storage, hdfs etc. where the number of metadata <br>queries might not be very high. It would be an acceptable tradeoff in <br>such cases to not be very efficient for answering metadata queries but <br>be very efficient for data operations.<br><div><br></div>IOW, can we have two possible modes of operation for the sharding <br>translator to answer metadata queries?<br><div><br></div>1. One that behaves like a regular filesystem where we expect a mix of <br>data and metadata operations. Your document seems to cover that part <br>well. We can look at optimizing behavior for multi-threaded single <br>writer use cases after an initial implementation is in place. Techniques <br>like eager locking can be applied here.<br><div><br></div>2. Another mode where we do not expect a lot of metadata queries. In <br>this mode, we can visit all nodes where we have shards to answer these <br>queries.</blockquote><div>But for sharding translator to be able to visit all shards, it is required to know the last shard number.</div><div>Without this, it will never know when to stop looking up the different shards. For this to happen, we</div><div>still need to maintain the size attribute for each file.</div><div><br></div><div>-Krutika</div><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;"><br><div><br></div>-Vijay<br></blockquote><div><br></div></div></body></html>