On Fri, Oct 9, 2015 at 5:49 PM, Francois Lafont <flafdivers@xxxxxxx> wrote: > Hi, > > Thanks for your answer Greg. > > On 09/10/2015 04:11, Gregory Farnum wrote: > >> The size of the on-disk file didn't match the OSD's record of the >> object size, so it rejected it. This works for that kind of gross >> change, but it won't catch stuff like a partial overwrite or loss of >> data within a file. > > Ok, however during my tests I had been careful to replace the correct > file by a bad file with *exactly* the same size (the content of the > file was just a little string and I have changed it by a string with > exactly the same size). I had been careful to undo the mtime update > too (I had restore the mtime of the file before the change). Despite > this, the "repair" command worked well. Tested twice: 1. with the change > on the primary OSD and 2. on the secondary OSD. And I was surprised > because I though the test 1. (in primary OSD) will fail. Hm. I'm a little confused by that, actually. Exactly what was the path to the files you changed, and do you have before-and-after comparisons on the content and metadata? > Greg, if I understand you well, I shouldn't have too much confidence in > the "ceph pg repair" command, is it correct? > > But, if yes, what is the good way to repair a PG? Usually what we recommend is for those with 3 copies to find the differing copy, delete it, and run a repair — then you know it'll repair from a good version. But yeah, it's not as reliable as we'd like it to be on its own. -Greg _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |