On 09/14/2016 02:55 PM, Ilya Dryomov wrote:
> On Wed, Sep 14, 2016 at 9:01 AM, Nikolay Borisov <kernel@xxxxxxxx> wrote:
>>
>>
>> On 09/14/2016 09:55 AM, Adrian Saul wrote:
>>>
>>> I found I could ignore the XFS issues and just mount it with the appropriate options (below from my backup scripts):
>>>
>>> #
>>> # Mount with nouuid (conflicting XFS) and norecovery (ro snapshot)
>>> #
>>> if ! mount -o ro,nouuid,norecovery $SNAPDEV /backup${FS}; then
>>> echo "FAILED: Unable to mount snapshot $DATESTAMP of $FS - cleaning up"
>>> rbd unmap $SNAPDEV
>>> rbd snap rm ${RBDPATH}@${DATESTAMP}
>>> exit 3;
>>> fi
>>> echo "Backup snapshot of $RBDPATH mounted at: /backup${FS}"
>>>
>>> It's impossible without clones to do it without norecovery.
>>
>> But shouldn't freezing the fs and doing a snapshot constitute a "clean
>> unmount" hence no need to recover on the next mount (of the snapshot) -
>> Ilya?
>
> I *thought* it should (well, except for orphan inodes), but now I'm not
> sure. Have you tried reproducing with loop devices yet?
Unfortunately not yet since this is being tested in our production setup
which is non-trivial to replicate in a test environment. Tonight the
results of the checksumming experiments should be available.
While on the topic this might very well be caused by a race in the
fsfreeze code as seen here: https://lkml.org/lkml/2016/9/12/337
Also this is observed only on large and busy volumes (e.g. testing with
a 10g volume which is not very busy doesn't exhibit the corruption).
>
> Thanks,
>
> Ilya
>
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
