[Gluster-devel] 1402538 : Assertion failure during rebalance of symbolic links

[Nithya Balachandran]

On 15 December 2016 at 18:07, Xavier Hernandez <xhernandez at datalab.es>
wrote:

> On 12/15/2016 12:48 PM, Raghavendra Gowdappa wrote:
>
>> I need to step back a little to understand the RCA correctly.
>>
>> If I understand the code correctly, the callstack which resulted in
>> failed setattr is (in rebalance process):
>>
>> dht_lookup -> dht_lookup_cbk -> dht_lookup_everwhere ->
>> dht_lookup_everywhere_cbk -> dht_lookup_everywhere_done ->
>> dht_linkfile_create -> dht_lookup_linkfile_create_cbk ->
>> dht_linkfile_attr_heal -> setattr
>>
>> However, this setattr doesn't change the file type.
>>
>> <dht_linkfile_attr_heal>
>>
>>         STACK_WIND (copy, dht_linkfile_setattr_cbk, subvol,
>>                     subvol->fops->setattr, &copy_local->loc,
>>                     &stbuf, (GF_SET_ATTR_UID | GF_SET_ATTR_GID), xattr);
>>
>> </dht_linkfile_attr_heal>
>>
>> As can be seen above, the setattr call only changes UID/GID. So, I am at
>> loss to explain why the file type changed. Has anyone has any other
>> explanation?
>>
>
> Does the inode passed to setattr represent the regular file just created ?
> or does it contain information about the previous file (the one it's being
> replaced) that in this case is a symbolic link ?
>
> Right, IIUC, the reason this fails is the inode for the actual sym link
has type LINK which does not match the stbuf returned in the setattr on the
linkto file. The file does _not_ change types.


> Xavi
>
>
>> regards,
>> Raghavendra
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20161215/a8eecadb/attachment.html>