MyFavMirrors/minio
1
0
Fork 0
mirror of https://github.com/minio/minio.git synced 2025-11-08 21:24:55 -05:00
Code Issues Packages Projects Releases Wiki Activity

Remove white spaces (#3922)

Browse Source
This commit is contained in:
Nitish Tiwari
2017-03-17 21:53:22 +05:30
committed by Harshavardhana
parent e55421ebdd
commit d4eea224d4
4 changed files with 18 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/shared-backend/DESIGN.md
View File

@@ -79,8 +79,8 @@ This doesn't apply for the writes because there is always one writer and many re
An example here shows how the contention is handled with GetObject().
GetObject() holds a read lock on `fs.json`.
```go
```go
fsMetaPath := pathJoin(fs.fsPath, minioMetaBucket, bucketMetaPrefix, bucket, object, fsMetaJSONFile)
rlk, err := fs.rwPool.Open(fsMetaPath)
if err != nil {
@@ -93,7 +93,6 @@ GetObject() holds a read lock on `fs.json`.
_, err = io.CopyBuffer(writer, reader, buf)
... after successful copy operation unlocks the read lock ...
```
A concurrent PutObject is requested on the same object, PutObject() attempts a write lock on `fs.json`.
@@ -134,4 +133,4 @@ On minio3
Once lock is acquired the minio2 validates if the file really exists to avoid obtaining lock on an fd which is already deleted. But this situation calls for a race with a third server which is also attempting to write the same file before the minio2 can validate if the file exists. It might be potentially possible `fs.json` is created so the lock acquired by minio2 might be invalid and can lead to a potential inconsistency.
This is a known problem and cannot be solved by POSIX fcntl locks. These are considered to be the limits of shared filesystem.
This is a known problem and cannot be solved by POSIX fcntl locks. These are considered to be the limits of shared filesystem.