From: Ming Lei <ming.lei@redhat.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Theodore Ts'o <tytso@mit.edu>,
linux-ext4@vger.kernel.org,
Andreas Dilger <adilger.kernel@dilger.ca>,
linux-block@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
Dave Chinner <dchinner@redhat.com>,
Eric Sandeen <sandeen@redhat.com>, Christoph Hellwig <hch@lst.de>,
Zhang Yi <yi.zhang@redhat.com>,
ming.lei@redhat.com
Subject: Re: [ext4 io hang] buffered write io hang in balance_dirty_pages
Date: Thu, 27 Apr 2023 12:50:48 +0800 [thread overview]
Message-ID: <ZEn/KB0fZj8S1NTK@ovpn-8-24.pek2.redhat.com> (raw)
In-Reply-To: <ZEny7Izr8iOc/23B@casper.infradead.org>
Hello Matthew,
On Thu, Apr 27, 2023 at 04:58:36AM +0100, Matthew Wilcox wrote:
> On Thu, Apr 27, 2023 at 10:20:28AM +0800, Ming Lei wrote:
> > Hello Guys,
> >
> > I got one report in which buffered write IO hangs in balance_dirty_pages,
> > after one nvme block device is unplugged physically, then umount can't
> > succeed.
>
> That's a feature, not a bug ... the dd should continue indefinitely?
Can you explain what the feature is? And not see such 'issue' or 'feature'
on xfs.
The device has been gone, so IMO it is reasonable to see FS buffered write IO
failed. Actually dmesg has shown that 'EXT4-fs (nvme0n1): Remounting
filesystem read-only'. Seems these things may confuse user.
>
> balance_dirty_pages() is sleeping in KILLABLE state, so kill -9 of
> the dd process should succeed.
Yeah, dd can be killed, however it may be any application(s), :-)
Fortunately it won't cause trouble during reboot/power off, given
userspace will be killed at that time.
Thanks,
Ming
next prev parent reply other threads:[~2023-04-27 4:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-27 2:20 Ming Lei
2023-04-27 3:58 ` Matthew Wilcox
2023-04-27 4:50 ` Ming Lei [this message]
2023-04-27 6:36 ` Baokun Li
2023-04-27 7:33 ` Baokun Li
2023-04-27 10:01 ` Ming Lei
2023-04-27 11:19 ` Baokun Li
2023-04-27 11:27 ` Ming Lei
2023-04-28 1:41 ` Ming Lei
2023-04-28 3:47 ` Baokun Li
2023-04-28 5:47 ` Theodore Ts'o
2023-04-29 3:16 ` Ming Lei
2023-04-29 4:40 ` Christoph Hellwig
2023-04-29 5:10 ` Ming Lei
2023-05-01 4:47 ` Christoph Hellwig
2023-05-02 0:57 ` Ming Lei
2023-05-02 1:35 ` Dave Chinner
2023-05-02 15:35 ` Darrick J. Wong
2023-05-02 22:33 ` Dave Chinner
2023-05-02 23:27 ` Darrick J. Wong
2023-04-29 4:56 ` Theodore Ts'o
2023-05-01 2:06 ` Dave Chinner
2023-05-04 3:09 ` Baokun Li
2023-04-27 23:33 ` Dave Chinner
2023-04-28 2:56 ` Matthew Wilcox
2023-04-28 5:24 ` Dave Chinner
2023-05-04 15:59 ` Keith Busch
2023-05-04 16:21 ` Matthew Wilcox
2023-05-05 2:06 ` Ming Lei
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=ZEn/KB0fZj8S1NTK@ovpn-8-24.pek2.redhat.com \
--to=ming.lei@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
--cc=willy@infradead.org \
--cc=yi.zhang@redhat.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