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

[Pranith Kumar Karampuri]

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/
> show_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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180110/1ff8284a/attachment.html>