Harshavardhana 200caab82b fix: multi-pool setup make sure acquire locks properly (#13280) ... This was a regression introduced in '14bb969782' this has the potential to cause corruption when there are concurrent overwrites attempting to update the content on the namespace. This PR adds a situation where PutObject(), CopyObject() compete properly for the same locks with NewMultipartUpload() however it ends up turning off competing locks for the actual object with GetObject() and DeleteObject() - since they do not compete due to concurrent I/O on a versioned bucket it can lead to loss of versions. This PR fixes this bug with multi-pool setup with replication that causes corruption of inlined data due to lack of competing locks in a multi-pool setup. Instead CompleteMultipartUpload holds the necessary locks when finishing the transaction, knowing the exact location of an object to schedule the multipart upload doesn't need to compete in this manner, a pool id location for existing object.		2021-09-22 21:46:24 -07:00
..
.gitignore	rename all remaining packages to internal/ (#12418)	2021-06-01 14:59:40 -07:00
drwmutex_test.go	rename all remaining packages to internal/ (#12418)	2021-06-01 14:59:40 -07:00
drwmutex.go	fix: multi-pool setup make sure acquire locks properly (#13280)	2021-09-22 21:46:24 -07:00
dsync_test.go	rename all remaining packages to internal/ (#12418)	2021-06-01 14:59:40 -07:00
dsync-server_test.go	rename all remaining packages to internal/ (#12418)	2021-06-01 14:59:40 -07:00
dsync.go	rename all remaining packages to internal/ (#12418)	2021-06-01 14:59:40 -07:00
rpc-client-impl_test.go	rename all remaining packages to internal/ (#12418)	2021-06-01 14:59:40 -07:00
rpc-client-interface.go	rename all remaining packages to internal/ (#12418)	2021-06-01 14:59:40 -07:00