Thanks Nathan. On Fri, Mar 27, 2020 at 7:10 PM Nathan Fish <lordcirth@xxxxxxxxx> wrote: > The error is silently corrected and the correct data rewritten to the > bad sector. There may be a slight latency increase on the read. > The checksumming is implemented at the Bluestore layer, what you are > storing makes no difference. > > On Fri, Mar 27, 2020 at 5:12 AM Priya Sehgal <priya.sehgal@xxxxxxxxx> > wrote: > > > > Hi, > > I am trying to find out whether Ceph has a method to detect silent > > corruption such as bit rot. I came across this text in a book - > "Mastering > > Ceph : Infrastructure Storage Solution with the latest Ceph release" by > > Nick Fisk - > > > > > > Luminous release of Ceph employs ZFS-like ability to checksum data at > every > > read. BlueStore calculates and stores the crc32 checksum of any data that > > is written. On each read request, BlueStore reads the checksum and > compares > > it with the data read from the device. If there is a mismatch, BlueStore > > will report read error and repair damage. Ceph will then retry the read > > from another OSD holding the object. > > > > I have two questions: > > 1. If there is a mismatch will the ceph user (who initiated GET) receive > > any error message and he has to retry OR will this error be > auto-corrected > > by Ceph and the data would be returned from the other OSD (user will > never > > know what went wrong underneath? > > 2. Does this feature work for Multi-part upload objects also? > > > > -- > > Regards, > > Priya > > _______________________________________________ > > ceph-users mailing list -- ceph-users@xxxxxxx > > To unsubscribe send an email to ceph-users-leave@xxxxxxx > -- Regards, Priya _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |