Re: [PATCH 1/1] xfs: fallback to readonly during recovery

[Eric Sandeen <sandeen@sandeen.net>]

On 2/10/20 4:31 PM, Aaron Sierra wrote:
>> From: "Eric Sandeen" <sandeen@sandeen.net>
>> Sent: Monday, February 10, 2020 3:43:50 PM
> 
>> On 2/10/20 3:10 PM, Vincent Fazio wrote:
>>> Previously, XFS would fail to mount if there was an error during log
>>> recovery. This can occur as a result of inevitable I/O errors when
>>> trying to apply the log on read-only ATA devices since the ATA layer
>>> does not support reporting a device as read-only.
>>>
>>> Now, if there's an error during log recovery, fall back to norecovery
>>> mode and mark the filesystem as read-only in the XFS and VFS layers.
>>>
>>> This roughly approximates the 'errors=remount-ro' mount option in ext4
>>> but is implicit and the scope only covers errors during log recovery.
>>> Since XFS is the default filesystem for some distributions, this change
>>> allows users to continue to use XFS on these read-only ATA devices.
>>
>> What is the workload or scenario where you need this behavior?
>>
>> I'm not a big fan of ~silently mounting a filesystem with latent errors,
>> tbh, but maybe you can explain a bit more about the problem you're solving
>> here?
> 
> Hi Eric,
> 
> We use SSDs from multiple vendors that can be configured at power-on (via
> GPIO) to be read-write or write-protected. When write-protected we get I/O
> errors for any writes that reach the device. We believe that behavior is
> correct.
> 
> We have found that XFS fails during log recovery even when the log is clean
> (apparently due to metadata writes immediately before actual recovery).

There should be no log recovery if it's clean ...

And I don't see that here - a clean log on a readonly device simply mounts
RO for me by default, with no muss, no fuss.

# mkfs.xfs -f fsfile
...
# losetup /dev/loop0 fsfile
# mount /dev/loop0 mnt
# touch mnt/blah
# umount mnt
# blockdev --setro /dev/loop0
# dd if=/dev/zero of=/dev/loop0 bs=4k count=1
dd: error writing ‘/dev/loop0’: Operation not permitted
# mount /dev/loop0 mnt
mount: /dev/loop0 is write-protected, mounting read-only
# dmesg
[  419.941649] /dev/loop0: Can't open blockdev
[  419.947106] XFS (loop0): Mounting V5 Filesystem
[  419.952895] XFS (loop0): Ending clean mount
# uname -r
5.5.0

> Vincent and I believe that mounting read-only without recovery should be
> fine even when the log is not clean, since the filesystem will be consistent,
> even if out-of-date.

I think that you may be making too many assumptions here, i.e. that "log
recovery failure leaves the filesystem in a consistent state" - and that
may not be true in all cases.

IOWS, transitioning to a new RO state for your particular case may be safe,
but I'm not sure that's universally true for all log replay failures.

> Our customers' use often requires nonvolatile memory to be write-protected
> or not based on the device being installed in a development or deployed
> system. It is ideal for them to be able to mount their filesystems read-
> write when possible and read-only when not without having to alter mount
> options.

From my example above, I'd like to understand more why/how you have a
clean log that fails to mount by default on a readonly block device...
in my testing, no writes get sent to the device when mounting a clean
log.

-Eric