[openstack-dev] [swift] what does swift do if the auditor find that all 3 replicas are corrupt?
Daniel Li
abblly.daniel at gmail.com
Sat Nov 9 11:45:53 UTC 2013
Got it, thanks very much.
On Fri, Nov 8, 2013 at 2:32 AM, Samuel Merritt <sam at swiftstack.com> wrote:
> On 11/7/13 5:59 AM, Daniel Li wrote:
>
>>
>> Thanks very much for your help, and please see my inline
>> comments/questions.
>>
>> On Thu, Nov 7, 2013 at 2:30 AM, Samuel Merritt <sam at swiftstack.com
>> <mailto:sam at swiftstack.com>> wrote:
>>
>> On 11/6/13 7:12 AM, Daniel Li wrote:
>>
>> Hi,
>> I have a question about swift: what does swift do if the
>> auditor
>> find that all 3 replicas are corrupt?
>> will it notify the owner of the object(email to the account
>> owner)?
>> what will happen if the GET request to the corrupted object?
>> will it return a special error telling that all the replicas are
>> corrupted?
>> Or will it just say that the object is not exist?
>> Or it just return one of the corrupted replica?
>> Or something else?
>>
>>
>> If all 3 (or N) replicas are corrupt, then the auditors will
>> eventually quarantine all of them, and subsequent GET requests will
>> receive 404 responses.
>>
>> No notifications are sent, nor is it really feasible to start
>> sending them. "The auditor" is not a single process; there is one
>> Swift auditor process running on each node in a cluster. Therefore,
>> when an object is quarantined, there's no way for its auditor to
>> know if the other copies are okay or not.
>>
>> Note that this is highly unlikely to ever happen, at least with the
>> default of 3 replicas. When an auditor finds a corrupt object, it
>> quarantines it (moves it to a "quarantines" directory).
>>
>> Did you mean that when the auditor found the corruption, it did not
>> copy good replica from other object server to overwrite the corrupted
>> one, it just moved it to a quarantines directory?
>>
>
> That is correct. The object auditors don't perform any network IO, and in
> fact do not use the ring at all. All they do is scan the filesystems and
> quarantine bad objects in an infinite loop.
>
> (Of course, there are also container and account auditors that do similar
> things, but for container and account databases.)
>
>
> Then, since that object is missing, the replication processes will
>> recreate the object by copying it from a node with a good copy.
>>
>> When did the replication processes recreated the object by copying it
>> from a node with a good copy? Does the auditor send a message to
>> replication so the replication will do the copy immediately? And what is
>> a 'good' copy? Does the good copy's MD5 value is checked before copying?
>>
>
> It'll happen whenever the other replicators, which are running on other
> nodes, get around to it.
>
> Replication in Swift is push-based, not pull-based; there is no receiver
> here to which a message could be sent.
>
> Currently, a "good" copy is one that hasn't been quarantined. Since
> replication uses rsync to push files around the network, there's no
> checking of MD5 at copy time. However, there is work underway to develop a
> replication protocol that avoids rsync entirely and uses the object server
> throughout the entire replication process, and that would give the object
> server a chance to check MD5 checksums on incoming writes.
>
> Note that this is only important should 2 replicas experience
> near-simultaneous bitrot; in that case, there is a chance that bad-copy A
> will get quarantined and replaced with bad-copy B. Eventually, though, a
> bad copy will get quarantined and replaced with a good copy, and then
> you've got 2 good copies and 1 bad one, which reduces to a
> previously-discussed scenario.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131109/a2d1e284/attachment.html>
More information about the OpenStack-dev
mailing list