There was a corner case where Etag returned would be incorrect. This
happens when the object is changed from file interface but with object
size remaining the same.
This change introduces an additional metadata that stores the mtime of
object during PUT. This stored mtime is compared with actual mtime
during GET to determine if the file has changed or not. Etag is
recalculated if the file has changed.
The scope of this fix in addressing the above mentioned corner case is
limited to new objects only. Also, refactoring the code further by
moving some methods from utils.py to classes in diskfile.py should
prevent some redundant (f)stat syscalls. These minor optimizations
will be addressed in a separate change.
Change-Id: If724697ef2b17a3c569b60bd81ebf98dab283da6
Signed-off-by: Prashanth Pai <ppai@redhat.com>
This is a manual forward-port of the following change merged into
icehouse branch: https://review.openstack.org/215119
When content of an object is modified from filesystem interface, a GET
on the object will return inconsistent or incomplete content because the
content length originally stored as metadata no longer reflects the
actual length of the file after modification.
The complete fix will have two parts:
(1) Return the entire content of object as is to the client
(2) The Etag returned should reflect the actual md5sum of object content
This change only fixes (1) mentioned above. This means, the client will
always get the complete content of the file.
Fix (2) is not part of this change. This means, if content length of the
object remains same even after modification, the Etag returned would be
incorrect. Fixing (2) involves more invasive changes in the code. So
that is deferred for now and will be sent as a separate change later.
Reference:
https://bugs.launchpad.net/swiftonfile/+bug/1416720https://review.openstack.org/151897
Change-Id: I28d0ec33c59eb520be7d15a60adb968692226e3e
Closes-Bug: #1416720
Signed-off-by: Prashanth Pai <ppai@redhat.com>
SOF can support object names of upto 1024 if it conforms to the
following constraints:
Object names can have forward slashes ('/') in them. Each segment in
between these slashes cannot exceed 255 characters with exception of
the last segment which cannot exceed 221 characters.
This constraint arises from the fact that each segment except the last
one in object name is a directory, the last segment being an actual
file on the filesystem.
Also, restored default constraint values in swift.conf since the SOF
constraints middleware (always in proxy pipeline) will take care of it.
Change-Id: Ia7dc44671a87911c092fecd0344eace92f5c225b
Signed-off-by: Prashanth Pai <ppai@redhat.com>
* Rename references of '/mnt/gluster-object' to '/mnt/swiftonfile'.
* Rename swiftonfile SP name from 'sof' to 'swiftonfile'.
* Retain reseller_prefix in account dir created. This is to comply
with Swift's behavior.
* Cleanup mountpoint after running swiftonfile specific tests.
Signed-off-by: Prashanth Pai <ppai@redhat.com>
* Sync to Swift 2.0.0rc1 release.
* Use separate conf files for functional tests
* Define swiftonfile as policy with index 2
Signed-off-by: Prashanth Pai <ppai@redhat.com>
Added Swift On File specific functional tests that checks SoF's
object naming convention by comparing names of objects PUT and
actual files found over mountpoint.
Remove old reference to keystone functional tests.
Signed-off-by: Prashanth Pai <ppai@redhat.com>
