[Gluster-devel] Design for lookup-optimize made default

Shyam srangana at redhat.com
Mon Dec 14 17:10:09 UTC 2015


In the doc. there is reference to the fact that when a client fixes a 
layout it assigns the same dircommit hash to the layout which is 
equivalent to the vol commit hash. I think this assumption is incorrect, 
when a client heals the layout, the commit hash is set to 1 

What the above basically means is that when anyone other than rebalance 
changes the layout of an existing directory, it's commit-hash will start 
disagreeing with the volume commit hash. So that part is already handled 
(unless I am missing something, which case it is a bug and we need it 

The other part of the self-heal, I would consider *not* needed. If a 
client heals a layout, it is because a previous layout creator 
(rebalance or mkdir) was incomplete, and hence the client needs to set 
the layout. If this was by rebalance, the rebalance process would have 
failed and hence would need to be rerun. For abnormal failures on 
directory creations, I think the proposed solution is heavy weight, as 
lookup-optimize is an *optimization* and so it can devolve into 
non-optimized modes in such cases. IOW, I am stating we do not need to 
do this self healing.

I think we still need to handle stale layouts and the lookup (and other 


On 12/11/2015 06:08 AM, Sakshi Bansal wrote:
> The above link may not be accessible to all. In that case please refer to this:
> https://public.pad.fsfe.org/p/dht_lookup_optimize
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel

More information about the Gluster-devel mailing list