Unfortunately this will be an issue in all versions of the code. I can't speak with authority but I suspect Sam will want to backport the fix to Firefly as well. -Greg On Sat, Jun 13, 2015 at 8:08 PM Paweł Sadowski <c...@sadziu.pl> 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 <g...@gregs42.com> > wrote: > >> On Fri, Jun 12, 2015 at 1:07 AM, Paweł Sadowski <c...@sadziu.pl> 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@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
