Hi,
> Will need logs in order to say what happened exactly, if that's of any
> interest. You removed some crucial data for the full operation of that
> bucket. It may also be that some of the data was still cached so that
> you were able to complete some operations but not the others.
In this particular case, some rados object were lost, in particular
the .dir.NNNN.N file that described the bucket.
I tried recreating an empty file in its place but that doesn't seem to
be enough.
As I said, they're test scenarios on test data. I expect this case to
happen only on bucket that we mapped on low replication pools (size=1
or 2) and I don't really care if even the entire bucket is lost
(they're used for temporary data transfer between services), but I
need to be able to return to a consistent state.
Because in this case I'm stuck ( can't call create bucket again, it
thinks it's done already. can't call delete on the bucket because it
thinks it doesn't exist ... ).
That's why I needed to know where every trace of a bucket can be so I
can go and wipe it manually to recreate the bucket from scratch.
The loss of rados objects related to S3 objects seems easier to fix:
just rm all rados object for it (seems there can be several with
special prefixes) and then remove it from the entries in the
.dir.NNNN.N object. So it should be fairly easy to write a "fix"
utility that just rescans all objects in a bucket and deletes the
inconsistent ones.
> the users bucket index itself is in .users.uid, where it is kept under
> an object named <uid>.buckets.
Ah yes, I see. Clearing it from there works.
Cheers,
Sylvain
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
