+++ This bug was initially created as a clone of Bug #1720633 +++

+++ This bug was initially created as a clone of Bug #1718338 +++

Description of problem:

For nameless LOOKUPs, server creates a new inode which shall remain invalid until the fop is successfully processed post which it is linked to the inode table. 

But incase if there is an already linked inode for that entry, it discards that newly created inode which results in upcall notification. This may result in client being bombarded with unnecessary upcalls affecting performance if the data set is huge.

This issue can be avoided by looking up and storing the upcall context in the original linked inode (if exists), thus saving up on those extra callbacks.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from Worker Ant on 2019-06-07 14:10:52 UTC ---

REVIEW: https://review.gluster.org/22840 (upcall: Avoid sending notifications for invalid inodes) posted (#1) for review on master by soumya k

--- Additional comment from Worker Ant on 2019-06-14 12:48:34 UTC ---

REVIEW: https://review.gluster.org/22873 (upcall: Avoid sending notifications for invalid inodes) posted (#1) for review on release-6 by soumya k

--- Additional comment from Pasi Karkkainen on 2019-06-24 09:55:02 UTC ---

Hmm.. it seems merge to 6.x branch is "blocked" due to a build failure regression?

https://review.gluster.org/#/c/glusterfs/+/22873/

--- Additional comment from Amar Tumballi on 2019-07-05 08:06:20 UTC ---

It got fixed now. Good to get merged soon.

--- Additional comment from Worker Ant on 2019-07-05 09:19:24 UTC ---

REVIEW: https://review.gluster.org/22873 (upcall: Avoid sending notifications for invalid inodes) merged (#6) on release-6 by hari gowtham