public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: Baokun Li <libaokun1@huawei.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	sunyongjian1@huawei.com, Yang Erkun <yangerkun@huawei.com>,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [BUG REPORT] ext4: “errors=remount-ro” has become “errors=shutdown”?
Date: Fri, 3 Jan 2025 10:35:17 -0500	[thread overview]
Message-ID: <20250103153517.GB1284777@mit.edu> (raw)
In-Reply-To: <umpsdxhd2dz6kgdttpm27tigrb3ytvpf3y3v73ugavgh4b5cuj@dnacioqwq4qq>

On Fri, Jan 03, 2025 at 11:42:13AM +0100, Jan Kara wrote:
> [CCed XFS and fsdevel list in case people have opinion what would be the
> best interface to know the fs has shutdown]
>  
> > Sorry for the lack of clarity in my previous explanation. The key point
> > is not about removing EXT4_MF_FS_ABORTED, but rather we will set
> > EXT4_FLAGS_SHUTDOWN bit, which not only prevents writes but also prevents
> > reads. Therefore, saying it's not read-only actually means it's completely
> > unreadable.
> 
> Ah, I see. I didn't think about that. Is it that you really want reading to
> work from a filesystem after error? Can you share why (I'm just trying to
> understand the usecase)? Or is this mostly a theoretical usecase?

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).

					- Ted

  parent reply	other threads:[~2025-01-03 15:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <22d652f6-cb3c-43f5-b2fe-0a4bb6516a04@huawei.com>
     [not found] ` <z52ea53du2k66du24ju4yetqm72e6pvtcbwkrjf4oomw2feffq@355vymdndrxn>
     [not found]   ` <17108cad-efa8-46b4-a320-70d7b696f75b@huawei.com>
2025-01-03 10:42     ` [BUG REPORT] ext4: “errors=remount-ro” has become “errors=shutdown”? Jan Kara
2025-01-03 13:19       ` Baokun Li
2025-01-03 14:34         ` Jan Kara
2025-01-04  3:15           ` Baokun Li
2025-01-03 15:35       ` Theodore Ts'o [this message]
2025-01-03 15:54         ` Theodore Ts'o
2025-01-04  2:41           ` Baokun Li
2025-01-06 23:49             ` Darrick J. Wong
2025-01-07  2:01               ` Baokun Li
2025-01-07  7:08                 ` Darrick J. Wong
2025-01-08  2:08                   ` Baokun Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250103153517.GB1284777@mit.edu \
    --to=tytso@mit.edu \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=libaokun1@huawei.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sunyongjian1@huawei.com \
    --cc=yangerkun@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox