From: Jan Kara <jack@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@lst.de>,
clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] btrfs: remove btrfs_writepage_cow_fixup
Date: Tue, 28 Jun 2022 10:00:35 +0200 [thread overview]
Message-ID: <20220628080035.qlbdib7zh3zd2zfq@quack3> (raw)
In-Reply-To: <e73be42e-fce5-733a-310d-db9dc5011796@gmx.com>
On Tue 28-06-22 08:24:07, Qu Wenruo wrote:
> On 2022/6/27 18:19, Jan Kara wrote:
> > On Sat 25-06-22 11:11:43, Christoph Hellwig wrote:
> > > On Fri, Jun 24, 2022 at 03:07:50PM +0200, Jan Kara wrote:
> > > > I'm not sure I get the context 100% right but pages getting randomly dirty
> > > > behind filesystem's back can still happen - most commonly with RDMA and
> > > > similar stuff which calls set_page_dirty() on pages it has got from
> > > > pin_user_pages() once the transfer is done. page_maybe_dma_pinned() should
> > > > be usable within filesystems to detect such cases and protect the
> > > > filesystem but so far neither me nor John Hubbart has got to implement this
> > > > in the generic writeback infrastructure + some filesystem as a sample case
> > > > others could copy...
> > >
> > > Well, so far the strategy elsewhere seems to be to just ignore pages
> > > only dirtied through get_user_pages. E.g. iomap skips over pages
> > > reported as holes, and ext4_writepage complains about pages without
> > > buffers and then clears the dirty bit and continues.
> > >
> > > I'm kinda surprised that btrfs wants to treat this so special
> > > especially as more of the btrfs page and sub-page status will be out
> > > of date as well.
> >
> > I agree btrfs probably needs a different solution than what it is currently
> > doing if they want to get things right. I just wanted to make it clear that
> > the code you are ripping out may be a wrong solution but to a real problem.
>
> IHMO I believe btrfs should also ignore such dirty but not managed by fs
> pages.
>
> But I still have a small concern here.
>
> Is it ensured that, after RDMA dirtying the pages, would we finally got
> a proper notification to fs that those pages are marked written?
So there is ->page_mkwrite() notification happening when RDMA code calls
pin_user_pages() when preparing buffers. The trouble is that although later
page_mkclean() makes page not writeable from page tables, it may be still
written by RDMA code (even hours after ->page_mkwrite() notification, RDMA
buffers are really long-lived) and that's what eventually confuses the
filesystem. Otherwise set_page_dirty() is the notification that page
contents was changed and needs writing out...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2022-06-28 8:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-24 12:23 [PATCH] btrfs: remove btrfs_writepage_cow_fixup Christoph Hellwig
2022-06-24 12:30 ` Qu Wenruo
2022-06-24 12:51 ` Christoph Hellwig
2022-06-24 13:07 ` Jan Kara
2022-06-24 13:19 ` Qu Wenruo
2022-06-24 13:40 ` Jan Kara
2022-06-24 13:56 ` Qu Wenruo
2022-06-27 10:15 ` Jan Kara
2022-06-25 9:11 ` Christoph Hellwig
2022-06-27 10:19 ` Jan Kara
2022-06-28 0:24 ` Qu Wenruo
2022-06-28 8:00 ` Jan Kara [this message]
2022-06-29 1:33 ` Qu Wenruo
2022-06-29 10:03 ` Jan Kara
2022-06-28 11:53 ` David Sterba
2022-06-29 7:58 ` Christoph Hellwig
2022-07-05 14:21 ` Gerald Schaefer
2022-06-28 11:46 ` David Sterba
2022-06-28 14:29 ` Chris Mason
2022-06-29 1:20 ` Qu Wenruo
2022-06-29 8:40 ` Christoph Hellwig
2022-06-29 8:38 ` Christoph Hellwig
2022-06-29 9:45 ` Jan Kara
2022-06-29 13:59 ` Christoph Hellwig
2022-06-24 12:49 ` David Sterba
2022-06-24 13:12 ` Qu Wenruo
2022-06-24 13:27 ` David Sterba
2022-06-24 13:50 ` Qu Wenruo
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=20220628080035.qlbdib7zh3zd2zfq@quack3 \
--to=jack@suse.cz \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=hch@lst.de \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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