[Gluster-devel] Storing list of dentries of children in parent inode

[Raghavendra Gowdappa]

On Fri, Jun 29, 2018 at 12:25 PM, Vijay Bellur <vbellur at redhat.com> wrote:

>
>
> On Wed, Jun 27, 2018 at 10:15 PM Raghavendra Gowdappa <rgowdapp at redhat.com>
> wrote:
>
>> All,
>>
>> There is a requirement in write-behind where during readdirp we may have
>> to invalidate iatts/stats of some of the children of the directory [1]. For
>> lack of better alternatives I added a dentry list to parent inode which
>> contains all children that've been linked (through lookup or readdirp on
>> directory). I myself am not too comfortable with this solution as it might
>> eat up significant memory for large directories.
>>
>> Thoughts?
>>
>
>
> Reading [2] makes me wonder if write-behind is the appropriate place for
> this change. Shouldn't md-cache be made aware of inode generations or
> something similar?
>

Both are independent fixes and cater to different issues. The fix for [2]
is at https://review.gluster.org/20410

The patch which is subject of this mail thread tries to address stat
consistency when readdirp is done on a directory containing files having
cached writes. If readdirp happen to fetch dentries of these files, stats
contained in those dentries can be stale. Consider the following scenario
(All following operations happen in a single thread of the application):

* w1 is done on f1, write syscall completes with success. w1 is cached in
write-behind.
* w2 is done on f2, write syscall completes with success. w2 is cached in
write-behind.
* readdirp on parent directory is done. In response, f1 and f2 are fetched.
stats for f1 and f2 are cached in kernel attribute cache.
* kernel/application does fstat on f1 and f2. Stats returned wouldn't
account for w1 and w2.

What patch does is to not send stats for f1 and f2 in readdirp response, so
that kernel is forced to do a lookup/getattr which will be serialized with
w1 and w2 and fetch correct values.





> Thanks,
> Vijay
>
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1512691#c18
>
>
>
>>
>> [1] https://review.gluster.org/20413
>>
>> regards,
>> Raghavendra
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180629/78f50237/attachment.html>