On 09/19/2016 10:08 AM, Niels de Vos wrote:
Duh, and now with the attachment. I'm going to get some coffee now.
On Mon, Sep 19, 2016 at 06:22:58AM +0200, Niels de Vos wrote:
Hey Soumya,
do we have a description of the different actions that we expect/advise
users of upcall to take? I'm looking at the flags that are listed in
libglusterfs/src/upcall-utils.h and api/src/glfs-handles.h and passed in
the glfs_callback_inode_arg structure from api/src/glfs-handles.h.
Not very detailed. But a minimal description of each of these flags is
provided in the definitions of these flags (now moved to the
file:upcall-utils.h).
We have a NLINK flag, but that does not seem to carry the stat/iatt
attributes for the changed inode. It seems we send an upcall on file
removal that incudes NLINK, and just after that we send an other one
with FORGET.
From the code, I see that it does seem to be sending stat of the inode
being (un)linked. May be if it is the last link to be removed, stat
structure could have been NULL. Could you please check with files with
link count >1?
FORGET was not exactly related to removal/unlink of the file. It is to
be sent whenever (protocol/)server does inode_forget which could be for
various other reasons. But yeah, as you have said, when the last link is
removed, since a FORGET gets definitely sent which invalidates the inode
cache entry, there is no point sending NLINK flag just before that. We
could have a check to avoid NLINK upcall if it is the last link of the
file being removed.
Thanks,
Soumya
This attachment in Bugzilla shows the behaviour:
https://bugzilla.redhat.com/attachment.cgi?id=1202190
You'll need https://code.wireshark.org/review/17776 to decode the flags,
so I'll attach the tshark output to this email for your convenience.
$ tshark -r /tmp/upcall_xid.1474190284.pcap.gz -V 'glusterfs.cbk'
Question: For the NLINK flag, should we not include the stat/iatt of the
modified inode? And only if the iatt->nlink is 0, a FORGET should get
sent? NLINK would then only happen when a (not the last) hardlink is
removed.
Thanks,
Niels
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
