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. 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. 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
