[Bugs] [Bug 1488120] Moving multiple temporary files to the same destination concurrently causes ESTALE error

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1488120



--- Comment #6 from Raghavendra G <rgowdapp at redhat.com> ---
The initial RCA of failing inodelks while necessary, is not sufficient to get
the use-case working. Over the course of getting testcase working, I found
following issues:

1 Entrylk has to be secured on hashed subvol as cached-subvol can change due to
migration of file. Credits for identifying this during code review goes to
Nithya. This part of the solution is done.
2 After locking, lookup done on dst should handle the error scenario of ESTALE,
as gfid associated with path will change due to rename(s) that happened between
lookup and the time lock is acquired. This part of the solution is done.
3 dht_lookup has to handle the scenario of gfid of linkto and data files
differing during fresh lookup as it might be done in the middle of a rename.
While I've a hacky way of resolving this (by making fuse-bridge retry even
fresh lookup during ESTALE), I need to implement a proper fix (To make
dht_lookup to retry the lookup under locks when it encounters this scenario).
4. linkfile creation during lookup has to be done under lock which synchronizes
linkfile creation with any renames involving the file. This part of the
solution is implemented. But, I am still thinking through whether this locking
is actually required. IOW, I am not able to find the RCA which requires this
solution. But, having this lock gets test working.
5. server_link has to handle the scenario of a stale dentry left in the inode
table due to a racing lookup and rename involving the dentry. I've an hacky
implementation which changes resolve-type to RESOLVE_MAY from RESOLVE_NOT in
server_link. But correct solution would to be enhance RESOLVE_NOT
implementation in server-resolver to check on backend for existance of file
(and then fail if file exists on backend too) before failing the fop on finding
an inode in itable. This part of the solution is still pending.

With the above set of solutions, I am able to get the test working (with 4
clients simultaneously executing the above script and on client continuously
doing lookup on the contents of directory in which renames are being done) for
couple of hours. But after that I end up with rename failing  and two dst data
files in the volume. I am in the process of debugging this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=nyLBEFGYt5&a=cc_unsubscribe