All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>,
	linux-fsdevel@vger.kernel.org,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: About using on-stack fsdata pointer for write_begin() and write_end() callbacks
Date: Tue, 12 Nov 2024 16:01:42 +1030	[thread overview]
Message-ID: <b595203e-c299-46f8-b79a-185276d53d89@suse.com> (raw)
In-Reply-To: <ZzLiBEA6Sp-P7xoB@infradead.org>



在 2024/11/12 15:35, Christoph Hellwig 写道:
> On Mon, Nov 11, 2024 at 06:06:57PM +1030, Qu Wenruo wrote:
>>> Why?  They aren't exactly efficient, and it's just going to create
>>> more Churn for Goldwyn's iomap work.
>>
>> So it is not recommended to go the write_begin() and write_end() callbacks
>> at all?
>> Or just not recommended for btrfs?
> 
> They aren't a very efficient model, so I would not recommend to add
> new users.

No wonder no one is adding support for IOCB_NOWAIT.

> 
>> I know there are limits like those call backs do not support IOCB_NOWAIT,
>> and the memory allocation inefficient problem (it should only affect ocfs2),
>> but shouldn't we encourage to use the more common paths where all other fses
>> go?
> 
> I'd recommend to use iomap.

Definitely the way we will go in the long run.

Although I'm still struggling on the out-of-band dirty folio (someone 
marked a folio dirty without notifying the fs) handling.

The iomap writepages implementation will just mark all the folio range 
dirty and start mapping.

So I guess there must be some fs specific handling inside the mapping 
function, let me dig it deeper and check Goldwyn's work for details.

Anyway thanks a lot pointing out that the write_begin() model is already 
kinda deprecated.

Thanks,
Qu

  reply	other threads:[~2024-11-12  5:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-11  4:27 About using on-stack fsdata pointer for write_begin() and write_end() callbacks Qu Wenruo
2024-11-11  5:52 ` Christoph Hellwig
2024-11-11  7:36   ` Qu Wenruo
2024-11-12  5:05     ` Christoph Hellwig
2024-11-12  5:31       ` Qu Wenruo [this message]
2024-11-12  5:41         ` Christoph Hellwig
2024-11-12  6:03           ` Qu Wenruo
2024-11-12  6:06             ` Christoph Hellwig
2024-11-12  6:13               ` 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=b595203e-c299-46f8-b79a-185276d53d89@suse.com \
    --to=wqu@suse.com \
    --cc=hch@infradead.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.