Open Stack

Thanks for the detailed reply Samuel.

The architecture overview of Openstack Swift at [1] mentions: "A deletion
is also treated as a version of the file (a 0 byte file ending with ”.ts”,
which stands for tombstone)". That led me to think that an object delete is
a new version created by truncating and then renaming the file.

I understand that it is more work for the cluster when dealing with
expiring objects, however that work will happen in the background. If the
client perceived performance improves because of this, it might be worth it.

So, with the default options where POST-as-copy is enabled, expiring
objects instead of delete doesn't make sense (would it have been
interesting if the underlying filesystem was supporting dedup which would
have made the file copy cheaper?).

However, if the POST-as-copy option is disabled, setting the X-Delete-After
results in making an entry in the .expiring_objects account and change the
xattrs of the inode for that object. A DELETE request results in unlinking
the file and creating a new one.

Do the same set of operations happen for all the replicas of that object?

Thanks for pointing out that the "-m" option is only for metadata headers.
Is there no way of directly setting this attribute using the swift command
line client? Or should I just use curl?

Thanks in advance.
-Shri

[1] http://docs.openstack.org/developer/swift/overview_architecture.html


On Wed, Oct 9, 2013 at 8:59 PM, Samuel Merritt <sam at swiftstack.com> wrote:

> On 10/9/13 8:28 PM, Shrinand Javadekar wrote:
>
>> Hi,
>>
>> Objects in a swift container can be deleted by either explicitly
>> deleting them or by setting a expiry timestamp on them. Is there a
>> performance difference between the two? For example, when I want to
>> delete an object, instead of deleting it, can I simply set the
>> X-Delete-After attribute of that object to 0? Is one faster than the
>> other?
>>
>> My guess is that setting the object expiry timestamp may be faster since
>> that would only involve changing the xattrs of the object inode. Delete
>> will require creation of a new version of the object, truncating it to a
>> 0 byte file and renaming it to change the extension to ".ts".
>>
>
> Deletion creates a 0-byte tombstone (.ts) file and unlinks the old object
> (the .data file).  It doesn't "creat[e] a new version of the object" only
> to truncate it.
>
>
>  Seems like
>> less work is done when object expiration is set.
>>
>
> Depends on whether or not object POST-as-copy is in use. If it is, then
> you'll wind up copying the entire object to change its metadata.
>
> Default for that is on, BTW, so if you haven't turned it off, you're using
> it.
>
> Further, setting X-Delete-At requires updating a container in the special
> .expiring_objects account. The object expirer periodically walks those
> containers and deletes objects that have expired, so now you've got a full
> copy of the whole object *plus* a container update.
>
> For large objects with POST-as-copy turned off, it might be faster to set
> X-Delete-At, but it is definitely more work for the cluster. If
> POST-as-copy is on, setting X-Delete-At will take longer than issuing a
> DELETE request *and* it'll be more work for the cluster.
>
> Also note that setting X-Delete-At doesn't guarantee that your object is
> really deleted at that time. Requests for that object will get 404s after
> that time, but the disk space won't be reclaimed, nor will the container
> listing be updated, until the object expirer gets around to actually
> deleting the object.
>
>
>  To try this out, I tried setting the X-Delete-After attribute using the
>> swift command line client:
>>
>> $ swift post -m X-Delete-After: 1 <container-name> <object-name>
>>
>> After I did this, when I stat the object, I see the attribute "Meta
>> X-Delete-After: 1". However, the object never got deleted. Any idea what
>> I'm doing wrong?
>>
>
> The -m flag sets metadata on the object; metadata headers are prefaced by
> X-Object-Meta. The above command actually sent the header
> X-Object-Meta-X-Delete-After: 1, which does not trigger object expiration.
>
>
>
> ______________________________**_________________
> Mailing list: http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
> openstack <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
> openstack <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131010/78cee136/attachment.html>