Hi All, I have upload a new patch (http://review.gluster.org/#/c/15456/),Please do the code review.
Regards Mohit Agrawal On Thu, Sep 8, 2016 at 12:02 PM, Mohit Agrawal <moagr...@redhat.com> wrote: > Hi All, > > I have one another solution to heal user xattr but before implement it > i would like to discuss with you. > > Can i call function (dht_dir_xattr_heal internally it is calling > syncop_setxattr) to heal xattr in dht_getxattr_cbk in last > after make sure we have a valid xattr. > In function(dht_dir_xattr_heal) it will copy blindly all user xattr on > all subvolume or i can compare subvol xattr with valid xattr if there is > any mismatch then i will call syncop_setxattr otherwise no need to call. > syncop_setxattr. > > Let me know if this approach is suitable. > > > > Regards > Mohit Agrawal > > On Wed, Sep 7, 2016 at 10:27 PM, Pranith Kumar Karampuri < > pkara...@redhat.com> wrote: > >> >> >> On Wed, Sep 7, 2016 at 9:46 PM, Mohit Agrawal <moagr...@redhat.com> >> wrote: >> >>> Hi Pranith, >>> >>> >>> In current approach i am getting list of xattr from first up volume and >>> update the user attributes from that xattr to >>> all other volumes. >>> >>> I have assumed first up subvol is source and rest of them are sink as we >>> are doing same in dht_dir_attr_heal. >>> >> >> I think first up subvol is different for different mounts as per my >> understanding, I could be wrong. >> >> >>> >>> Regards >>> Mohit Agrawal >>> >>> On Wed, Sep 7, 2016 at 9:34 PM, Pranith Kumar Karampuri < >>> pkara...@redhat.com> wrote: >>> >>>> hi Mohit, >>>> How does dht find which subvolume has the correct list of >>>> xattrs? i.e. how does it determine which subvolume is source and which is >>>> sink? >>>> >>>> On Wed, Sep 7, 2016 at 2:35 PM, Mohit Agrawal <moagr...@redhat.com> >>>> wrote: >>>> >>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> Gluster-devel mailing list >>>>> Gluster-devel@gluster.org >>>>> http://www.gluster.org/mailman/listinfo/gluster-devel >>>>> >>>> >>>> >>>> >>>> -- >>>> Pranith >>>> >>> >>> >> >> >> -- >> Pranith >> > >
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel