Re: [BUG REPORT] ext4: “errors=remount-ro” has become “errors=shutdown”?

Baokun Li
2025-01-08T02:08:32Z

On 2025/1/7 15:08, Darrick J. Wong wrote:
> On Tue, Jan 07, 2025 at 10:01:32AM +0800, Baokun Li wrote:
>> On 2025/1/7 7:49, Darrick J. Wong wrote:
>>> On Sat, Jan 04, 2025 at 10:41:28AM +0800, Baokun Li wrote:
>>>> Hi Ted,
>>>>
>>>> On 2025/1/3 23:54, Theodore Ts'o wrote:
>>>>> On Fri, Jan 03, 2025 at 10:35:17AM -0500, Theodore Ts'o wrote:
>>>>>> I don't see how setting the shutdown flag causes reads to fail. That
>>>>>> was true in an early version of the ext4 patch which implemented
>>>>>> shutdown support, but one of the XFS developers (I don't remember if
>>>>>> it was Dave or Cristoph) objected because XFS did not cause the
>>>>>> read_pages function to fail. Are you seeing this with an upstream
>>>>>> kernel, or with a patched kernel? The upstream kernel does *not* have
>>>>>> the check in ext4_readpages() or ext4_read_folio() (post folio
>>>>>> conversion).
>>>>> OK, that's weird. Testing on 6.13-rc4, I don't see the problem simulating an ext4 error:
>>>>>
>>>>> root@kvm-xfstests:~# mke2fs -t ext4 -Fq /dev/vdc
>>>>> /dev/vdc contains a ext4 file system
>>>>> last mounted on /vdc on Fri Jan 3 10:38:21 2025
>>>>> root@kvm-xfstests:~# mount -t ext4 -o errors=continue /dev/vdc /vdc
>>>> We are discussing "errors=remount-ro," as the title states, not the
>>>> continue mode. The key code leading to the behavior change is as follows,
>>>> therefore the continue mode is not affected.
>>> Hmm. On the one hand, XFS has generally returned EIO (or ESHUTDOWN in a
>>> couple of specialty cases) when the fs has been shut down.
>> Indeed, this is the intended behavior during shutdown.
>>> OTOH XFS also doesn't have errors=remount-ro; it just dies, which I
>>> think has been its behavior for a long time.
>> Yes. As an aside, is there any way for xfs to determine if -EIO is
>> originating from a hardware error or if the filesystem has been shutdown?
> XFS knows the difference, but nothing above it does.
Okay.
>> Or would you consider it useful to have the mount command display
>> "shutdown" when the file system is being shut down?
> Trouble is, will mount get confused and try to pass ",shutdown" as part
> of a remount operation?
The ",shutdown" string is only displayed by show_options when specific
flags are set; it's not actually parsed by remount. Unless the sysadmin
sees it in the mount command output and then mounts with this option.
> I suppose the fs is dead so what does it
> matter...
Since XFS is typically already shut down when it returns EIO, this prompt
may not be important for xfs. However, it's not as straightforward to
distinguish between EIO and shutdown for file systems that support a
continue mode or allow some operations even after shutdown.
>>> To me, it doesn't sound unreasonable for ext* to allow reads after a
>>> shutdown when errors=remount-ro since it's always had that behavior.
>> Yes, a previous bug fix inadvertently changed the behavior of
>> errors=remount-ro,
>> and the patch to correct this is coming.
>>
>> Additionally, ext4 now allows directory reads even after shutdown, is this
>> expected behavior?
> There's no formal specification for what shutdown means, so ... it's not
> unexpected. XFS doesn't allow that.
Okay.
>>> Bonus Q: do you want an errors=fail variant to shut things down fast?
>>>
>>> --D
>> In my opinion, I have not yet seen a scenario where the file system needs
>> to be shut down after an error occurs. Therefore, using errors=remount-ro
>> to prevent modifications after an error is sufficient. Of course, if
>> customers have such needs, implementing this mode is also very simple.
> IO errors, sure. Metadata errors? No, we want to stop the world
> immediately, either so the sysadmin can go run xfs_repair, or the clod
> manager can just kill the node and deploy another.
>
> --D

The remount-ro mode generally only becomes read-only when metadata errors
occur，too. I think if users have no need to read after an error, there is
basically no difference between read-only and shutdown. In fact,
errors=remount-ro does more; it allows users to back up some potentially
lost data after an error and then exit gracefully. However, reading
corrupted metadata does have some risks, for which we have done a lot of
work.

Regards,
Baokun