[Gluster-devel] a link issue maybe introduced in a bug fix " Don't let NFS cache stat after writes"

[Raghavendra G]

+csaba for fuse. +poornima, if the issue turns out to be an issue in
md-cache caching.

On Wed, Jan 10, 2018 at 5:37 PM, Pranith Kumar Karampuri <
pkarampu at redhat.com> wrote:

>
>
> On Wed, Jan 10, 2018 at 11:09 AM, Lian, George (NSB - CN/Hangzhou) <
> george.lian at nokia-sbell.com> wrote:
>
>> Hi, Pranith Kumar,
>>
>>
>>
>> I has create a bug on Bugzilla https://bugzilla.redhat.com/sh
>> ow_bug.cgi?id=1531457
>>
>> After my investigation for this link issue, I suppose your changes on
>> afr-dir-write.c with issue " Don't let NFS cache stat after writes" , your
>> fix is like:
>>
>> --------------------------------------
>>
>>        if (afr_txn_nothing_failed (frame, this)) {
>>
>>                         /*if it did pre-op, it will do post-op changing
>> ctime*/
>>
>>                         if (priv->consistent_metadata &&
>>
>>                             afr_needs_changelog_update (local))
>>
>>                                 afr_zero_fill_stat (local);
>>
>>                         local->transaction.unwind (frame, this);
>>
>>                 }
>>
>> In the above fix, it set the ia_nlink to ‘0’ if option
>> consistent-metadata is set to “on”.
>>
>> And hard link a file with which just created will lead to an error, and
>> the error is caused in kernel function “vfs_link”:
>>
>> if (inode->i_nlink == 0 && !(inode->i_state & I_LINKABLE))
>>
>>              error =  -ENOENT;
>>
>>
>>
>> could you please have a check and give some comments here?
>>
>
> When stat is "zero filled", understanding is that the higher layer
> protocol doesn't send stat value to the kernel and a separate lookup is
> sent by the kernel to get the latest stat value. In which protocol are you
> seeing this issue? Fuse/NFS/SMB?
>
>
>>
>>
>> Thanks & Best Regards,
>>
>> George
>>
>
>
>
> --
> Pranith
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180111/d51ad14b/attachment.html>