1 |
On Tue, Dec 23, 2014 at 4:08 PM, Holger Hoffstätte |
2 |
<holger.hoffstaette@××××××××××.com> wrote: |
3 |
> On Tue, 23 Dec 2014 21:54:00 +0100, Stefan G. Weichinger wrote: |
4 |
> |
5 |
>> In the other direction: what protects against these errors you mention? |
6 |
> |
7 |
> ceph scrub :) |
8 |
> |
9 |
|
10 |
Are you sure about that? I was under the impression that it just |
11 |
checked that everything was retrievable. I'm not sure if it compares |
12 |
all the copies of everything to make sure that they match, and if they |
13 |
don't match I don't think that it has any way to know which one is |
14 |
right. I believe an algorithm just picks one as the official version, |
15 |
and it may or may not be identical to the one that was originally |
16 |
stored. |
17 |
|
18 |
If the data is on btrfs then it is protected from silent corruption |
19 |
since the filesystem will give an error when that node tries to read a |
20 |
file, and presumably the cluster will find another copy elsewhere. On |
21 |
the other hand if the file were logically overwritten in some way |
22 |
above the btrfs layer then btrfs won't complain and the cluster won't |
23 |
realize the file has been corrupted. |
24 |
|
25 |
If I'm wrong on this by all means point me to the truth. From |
26 |
everything I read though I don't think that ceph maintains a list of |
27 |
checksums on all the data that is stored while it is at rest. |
28 |
|
29 |
-- |
30 |
Rich |