-Greg
On Sat, Jun 13, 2015 at 8:08 PM Paweł Sadowski <ceph@xxxxxxxxx> wrote:
Thanks for taking care of this so fast. Yes, I'm getting broken object.
I haven't checked this on other versions but is this bug present
only in Hammer or in all versions?
W dniu 12.06.2015 o 21:43, Gregory Farnum pisze:
> Okay, Sam thinks he knows what's going on; here's a ticket:
> http://tracker.ceph.com/issues/12000
>
> On Fri, Jun 12, 2015 at 12:32 PM, Gregory Farnum <greg@xxxxxxxxxxx> wrote:
>> On Fri, Jun 12, 2015 at 1:07 AM, Paweł Sadowski <ceph@xxxxxxxxx> wrote:
>>> Hi All,
>>>
>>> I'm testing erasure coded pools. Is there any protection from bit-rot
>>> errors on object read? If I modify one bit in object part (directly on
>>> OSD) I'm getting *broken*object:
>> Sorry, are you saying that you're getting a broken object if you flip
>> a bit in an EC pool? That should detect the chunk as invalid and
>> reconstruct on read...
>> -Greg
>>
>>> mon-01:~ # rados --pool ecpool get `hostname -f`_16 - | md5sum
>>> bb2d82bbb95be6b9a039d135cc7a5d0d -
>>>
>>> # modify one bit directly on OSD
>>>
>>> mon-01:~ # rados --pool ecpool get `hostname -f`_16 - | md5sum
>>> 02f04f590010b4b0e6af4741c4097b4f -
>>>
>>> # restore bit to original value
>>>
>>> mon-01:~ # rados --pool ecpool get `hostname -f`_16 - | md5sum
>>> bb2d82bbb95be6b9a039d135cc7a5d0d -
>>>
>>> If I run deep-scrub on modified bit I'm getting inconsistent PG which is
>>> correct in this case. After restoring bit and running deep-scrub again
>>> all PGs are clean.
>>>
>>>
>>> [ceph version 0.94.1 (e4bfad3a3c51054df7e537a724c8d0bf9be972ff)]
--
PS
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com