Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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

  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