Sakshi,
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
(DHT_LAYOUT_HASH_INVALID) [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
fixed).
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
problems).
[1]
https://github.com/gluster/glusterfs/blob/master/xlators/cluster/dht/src/dht-selfheal.c#L1685
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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
