openSUSE/snapper — pull request #46 by oniko (2014-02-17 13:53:50+00:00)
Title: - add 'norecovery' among xfs mount options

Well, I'm aware this one requires longer explanation:

Originally it emerged as an issue claiming all read-only snapshots made from mounted (but frozen) XFS filesystem were broken. Right now trying to mount such filesystem (w/o -o norecovery option) you will end up with following message in syslog:

[24551.970142] XFS (dm-6): Mounting Filesystem
[24552.620112] XFS (dm-6): recovery required on read-only device.
[24552.620119] XFS (dm-6): write access unavailable, cannot proceed.
[24552.620123] XFS (dm-6): log mount/recovery failed: error 30
[24552.620361] XFS (dm-6): log mount failed

I had some discussion with XFS devs and they explained me XFS required to add sort of dummy entry in XFS log (after the successful freeze) to be able to got rid off of unlinked (but in time of fs freeze) open files after a eventual system crash during time fs was frozen. So, they suggested adding norecovery option for RO snapshots made from frozen XFS . (IOW they won't give up the dummy log entry:) ) Also they reassured me the XFS behaved like that since circa 2005.

If one creates RW snaphost (RW device) it's fine since xfs is able to erase/modify such log entry even if it's required to mount read only. Unfortunately, If the device is RO xfs can't replay/erase such dummy entry and will fail to mount.

The fix is (*should* be) safe for snapper use case :

1) dm issues fs freeze during suspend (pre-snapshot operation) (right now the xfs log is in the exact state like after successful umount)
^^^ If successful, XFS now ensures filesystem consistency ^^^^^
2) XFS adds dummy log entry
3) snapshot is created

4) snapshot is mounted from read-only device with -ro,norecovery option (which effects in skipping only the dummy log entry)

But, obviously, it's far from being safe (in my opinion) to mount generally all read-only snapshot with 'norecovery' option (it could be unmounted, with real xfs log being unreplayed, whatever). In such case, one would risk hiding serious problems behind norecovery option which would result in snapshot having some unaccessible files/directories, etc.