Open Stack

It's really more filtering objects with deleted = 1.  The index used to
just be name - but that was not too efficient for sqlite when a container
had a lot of deleted objects (it'd have to page through a bunch of deleted
rows that matched the name index to apply the filter on delete = 0.  Adding
the index for deleted ment for container listings could skip loading a
bunch of rows so that worked out better.

As for why the container listing have to track deleted objects as rows it's
basically the same problem as being solved by tombstones at the object
layer - except this is for container replication/consistency - which is
needed for the container api requests and updates to the account layer.

-Clay

On Tue, Mar 10, 2015 at 11:14 AM, Shrinand Javadekar <
shrinand at maginatics.com> wrote:

> Hi,
>
> I see that Swift creates an index on the object table on the columns
> (deleted, name) in the container server. Where part of Swift queries
> the database for names where 'deleted = true'?
>
> I thought when an object is deleted, Swift synchronously truncates the
> file and renames it with a .ts extension. Is that not enough to
> identify a deleted object?
>
> -Shri
>
> _______________________________________________
> Mailing list:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150310/ea98377a/attachment.html>