swiftonfile/doc/markdown/last_write_wins.md

###Last write wins: Swift vs Swift-on-File

**OpenStack Swift:** The timestamp assigned to the request by proxy server
ultimately decides which *last* write wins. A `201 Created` is sent as
response to both the clients. Example:

Transaction T1 at time = t seconds:  
`curl -i http://vm1:8080/v1/AUTH_abc/c1/o1 -X PUT -T /tmp/reallybigfile`  
(Assume it takes 5 seconds to upload the *reallybigfile*)

Transaction T2 at time = (t + 0.01) seconds:  
`curl -i http://vm1:8080/v1/AUTH_abc/c1/o1 -X PUT -d 'tinydata'`  
(Assume it takes 1 second to upload this tiny data)

Here T2 wins although T1 will complete last. This is because T2 was the last
one to reach proxy server (the client facing server process that tags the
request with a timestamp).

Simultaneous PUT and DELETE illustrated: If a client has a long running PUT to
`AUTH_abc/c1/o1` and another client issues a DELETE on `AUTH_abc/c1/o1`
during the ongoing upload:

1. If the object existed earlier, the tombstone(.ts) created by DELETE request
   will have a later timestamp and will eventually take precedence even if the
   other upload finishes after. In effect, to any new clients performing a
   HEAD/GET on `AUTH_abc/c1/o1`, the client would receive a `HTTP 404` response
   as the object stands deleted.
2. If object did not exist earlier, the client doing a DELETE would recieve a
   `HTTP 404` response. The client doing the PUT request will successfully
   upload the object.

**Swift-on-File:** Unlike in vanilla OpenStack Swift, Swift-on-File does not
honour the timestamp set on request by the proxy server to decide which of
the write is the "last" one. In Swift-on-File, the last write to complete
(at the filesystem layer) is the one that wins. Example:

Transaction T1 at time = t seconds:  
`curl -i http://vm1:8080/v1/AUTH_abc/c1/o1 -X PUT -T /tmp/reallybigfile`  
(Assume it takes 5 seconds to upload the *reallybigfile*)

Transaction T2 at time = (t + 0.01) seconds:  
`curl -i http://vm1:8080/v1/AUTH_abc/c1/o1 -X PUT -d 'tinydata'`  
(Assume it takes 1 second to upload this tiny data)

Here T1 wins although T2 is the last transaction among the two to reach the
proxy server. This is because T1 was the last to complete and will overwrite
the object created by T2. For a small duration, between T2 completed and
T1 in progress, clients will be served the object created by T2.

Simultaneous PUT and DELETE illustrated: If a client has a long running PUT to
`AUTH_abc/c1/o1` and another client issues a DELETE on `AUTH_abc/c1/o1` during
the ongoing upload, the DELETE request would be responded with either of these:

* `HTTP 404` as the file does not exist because it's still being uploaded to
   a temp path and rename has not been performed yet.
* `HTTP 204` as an older version of the file existed and the DELETE was
   successful.

In effect, after completion of both PUT and DELETE, to any new client
performing a HEAD/GET on `AUTH_abc/c1/o1`, the client would receive the newer
object uploaded by the last PUT operation.

###Access from fileystem interface

Operations done solely from Swift interface will create/modify the objects
atomically. A PUT would result in data being written to a temporary file and
when the write of data and metadata is complete, the temporary file is renamed
to it's actual name. Hence, any client accessing the file/object from file
interface or Swift interface will see the file in a consistent state (either
the previous version or the newer version).

However, it's different when you create/modify file from filesystem interface.
As the file is written to it's actual path and not some temporary location,
a GET on the file from Swift interface while the file is being written from
filesystem interface might result in the Swift client getting partial file.
In other words, swiftonfile will serve the object present in filesystem
"as is" without checking if the file is being written or not.