openstack team mailing list archive

[Michael Barton <mike-launchpad@xxxxxxxxxxxxxxxx>]

(re-sent to list)

On Mon, May 30, 2011 at 4:56 PM, Rostyslav Slipetskyy
<rslipetskyy@xxxxxxxxx> wrote:
> It looks like backup/recovery can be easily added to swift without many changes
> in the source code. After successful file upload via PUT method, stored file
> receives name equal to timestamp and all the previous versions of the file are
> deleted by DiskFile#unlinkold method (swift/obj/server.py). If one wants to
> allow keeping up to N backup versions (can be configurable value),
> DiskFile#unlinkold method can be modified to keep last N versions of a file and
> delete all the others. Afterwards,  recovery would mean deleting last version of
> the file based on timestamp and will be allowed up to depth N-1 (this will not
> allow "recovery from recovery" though). Of course, modifications to
> ObjectController will be necessary to allow dedicated HTTP call to recover
> object to

Yeah, we've discussed that basic idea before.  The problem is that
every version would be stored on the same drives, which is gonna screw
with storage distribution.

I don't really know how to make versioning work in Swift.

Another option is changing the hashing and db primary key for objects
to (filename, timestamp) instead of just filename.  But then I don't
think you can serve object GET/HEAD requests without touching the
metadata layer, which I've always thought was pretty hot, and
overwrites are suddenly way more complicated if you still want them,
and POST is gonna raise all sorts of consistency questions.

-- Mike