Open Stack

Got it, thanks!


Thanks

Changbin

On Wed, Jul 22, 2015 at 4:19 PM, Clay Gerrard <clay.gerrard at gmail.com>
wrote:

>
>
> On Wed, Jul 22, 2015 at 12:24 PM, Changbin Liu <changbin.liu at gmail.com>
> wrote:
>
>>
>> But now I wonder: is it "by design" that EC does not handle an accidental
>> deletion of just the data file?
>>
>
> Well, the design goal was not "do not handle the accidental deletion of
> just the data file" - it was "make replication fast enough that it works" -
> and that required not listing all the dirs all the time.
>
>
>> Deleting both data file and hashes.pkl file is more like a
>> deliberately-created failure case instead of a normal one.
>>
>
> To me deleting some file that swift wrote to disk without updating (or
> removing) the index it normally updates during write/delete/replicate to
> accelerate replication seems like a deliberately created failure case?  You
> could try to flip a bit or truncate a data file and let the auditor pick it
> up.  Or rm a suffix and wait for the every-so-often suffixdir listdir to
> catch it, or remove an entire partition, or wipe a new filesystem onto the
> disk.  Or shutdown a node and do a PUT, then shutdown the handoff node, and
> run the reconstructor.  Any of the "normal" failure conditions like that
> (and plenty more!) are all detected by and handled efficiently.
>
> To me Swift EC repairing seems different from the triple-replication mode,
>> where you delete any data file copy, it will be restored.
>>
>>
>
> Well, replication and reconstruction are different in lots of ways - but
> not this part.  If you rm a .data file without updating the index you'll
> need some activity (post/copy/put/quarantine) in the suffix before the
> replication engine can notice.
>
> Luckily (?) people don't often go under the covers into the middle of the
> storage system and rm data like that?
>
> -Clay
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150722/e3f19b3e/attachment.html>