Re: About using on-stack fsdata pointer for write_begin() and write_end() callbacks

[Qu Wenruo <wqu@suse.com>]

在 2024/11/11 16:22, Christoph Hellwig 写道:
> On Mon, Nov 11, 2024 at 02:57:06PM +1030, Qu Wenruo wrote:
>> Hi,
>>
>> Recently I'm working on migrating btrfs_buffered_write() to utilize
>> write_begin() and write_end() callbacks.
> 
> 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?

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?

> 
>> Currently only the following filesystems really utilizing that pointer:
>>
>> - bcachefs
>>    Which is a structure of 24 bytes without any extra pointer.
> 
> And as pointed out last time willy and I did go through the users of
> write_begin/end this is just dead code that is never called.
> 
>> Thus I'm wondering should we make perform_generic_write() to accept a
>> *fsdata pointer, other than making write_begin() to allocate one.
>> So that we only need to allocate the memory (or use the on-stack one)
>> once per write, other than once per folio.
> 
> And that scheme was one of my suggestions back then, together with
> removing write_begin/end from address_space_operations because they
> aren't operations called by MM/pagecache code, but just callbacks
> provided by the file system to perform_generic_write.
>

Mind to point me to the old discussion thread? I'd like to know why we 
didn't go that path.

Thanks,
Qu