From: Matthew Wilcox <willy@infradead.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-fsdevel@vger.kernel.org,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
kvm@vger.kernel.org, Zi Yan <ziy@nvidia.com>,
Christian Brauner <brauner@kernel.org>,
"Darrick J. Wong" <djwong@kernel.org>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Thomas Huth <thuth@redhat.com>
Subject: Re: [ISSUE] split_folio() and dirty IOMAP folios
Date: Thu, 7 Nov 2024 16:09:53 +0000 [thread overview]
Message-ID: <ZyzmUW7rKrkIbQ0X@casper.infradead.org> (raw)
In-Reply-To: <4febc035-a4ff-4afe-a9a0-d127826852a9@redhat.com>
On Thu, Nov 07, 2024 at 04:07:08PM +0100, David Hildenbrand wrote:
> I'm debugging an interesting problem: split_folio() will fail on dirty
> folios on XFS, and I am not sure who will trigger the writeback in a timely
> manner so code relying on the split to work at some point (in sane setups
> where page pinning is not applicable) can make progress.
You could call something like filemap_write_and_wait_range()?
> ... or is there a feasible way forward to make iomap_release_folio() not
> bail out on dirty folios?
>
> The comment there says:
>
> "If the folio is dirty, we refuse to release our metadata because it may be
> partially dirty. Once we track per-block dirty state, we can release the
> metadata if every block is dirty."
With the data structures and callbacks we have, it's hard to do.
Let's see if getting writeback kicked off will be enough to solve the
problem you're working on.
next prev parent reply other threads:[~2024-11-07 16:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-07 15:07 David Hildenbrand
2024-11-07 16:09 ` Matthew Wilcox [this message]
2024-11-07 16:34 ` David Hildenbrand
2024-11-07 20:20 ` Matthew Wilcox
2024-11-08 9:11 ` David Hildenbrand
2024-11-11 15:19 ` David Hildenbrand
2024-11-21 12:15 ` David Hildenbrand
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=ZyzmUW7rKrkIbQ0X@casper.infradead.org \
--to=willy@infradead.org \
--cc=borntraeger@linux.ibm.com \
--cc=brauner@kernel.org \
--cc=david@redhat.com \
--cc=djwong@kernel.org \
--cc=frankja@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=thuth@redhat.com \
--cc=ziy@nvidia.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