[Gluster-devel] Non-blocking lock for renames

[Vijay Bellur]

DHT developers,

We introduced a non-blocking lock prior to a rename operation in dht and 
fail the rename if the lock acquisition is not successful with 3.6. I 
ran into an user in IRC yesterday who is affected by this behavior change:

"We're seeing a behavior in Gluster 3.7.x that we did not see in 3.4.x 
and we're not sure how to fix it. When multiple processes are attempting 
to rename a file to the same destination at once, we're now seeing 
"Device or resource busy" and "Stale file handle" errors. Here's the 
command to replicate it: cd /mnt/glustermount; while true; do 
FILE=$RANDOM; touch $FILE; mv $FILE file-fv; done. The above command 
would be ran on two or three servers within the same gluster cluster. In 
the output, one would always be sucessfull in the rename, while the 2 
other ones would fail with the above error."

The use case for concurrent renames was described as:

"we generate files and push them to the gluster cluster. Some are 
generated multiple times and end up being pushed to the cluster at the 
same time by different data generators; resulting in the 'rename 
collision'. We use also the cluster.extra-hash-regex to make sure the 
data is written in place. And this does the rename."

Is a non-blocking lock essential? Can we not use a blocking lock instead 
of a non-blocking lock or fallback to a blocking lock if the original 
non-blocking lock acquisition fails?

Thanks,
Vijay