[Gluster-devel] Query regards to heal xattr heal in dht

[Mohit Agrawal]

Hi,

  I am trying to find out solution of one problem in dht specific to user
xattr healing.
  I tried to correct it in a same way as we are doing for healing dir
attribute but i feel it is not best solution.

  To find a right way to heal xattr i want to discuss with you if anyone
does have better solution to correct it.

  Problem:
   In a distributed volume environment custom extended attribute value for
a directory does not display correct value after stop/start the brick. If
any extended attribute value is set for a directory after stop the brick
the attribute value is not updated on brick after start the brick.

  Current approach:
    1) function set_user_xattr to store user extended attribute in
dictionary
    2) function dht_dir_xattr_heal call syncop_setxattr to update the
attribute on all volume
    3) Call the function (dht_dir_xattr_heal) for every directory lookup in
dht_lookup_revalidate_cbk

  Psuedocode for function dht_dir_xatt_heal is like below

   1) First it will fetch atttributes from first up volume and store into
xattr.
   2) Run loop on all subvolume and fetch existing attributes from every
volume
   3) Replace user attributes from current attributes with xattr user
attributes
   4) Set latest extended attributes(current + old user attributes) inot
subvol.


   In this current approach problem is

   1) it will call heal function(dht_dir_xattr_heal) for every directory
lookup without comparing xattr.
    2) The function internally call syncop xattr for every subvolume that
would be a expensive operation.

   I have one another way like below to correct it but again in this one it
does have dependency on time (not sure time is synch on all bricks or not)

   1) At the time of set extended attribute(setxattr) change time in
metadata at server side
   2) Compare change time before call healing function in dht_revalidate_cbk

    Please share your input on this.
    Appreciate your input.

Regards
Mohit Agrawal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160907/9dc552d9/attachment.html>