From: Matthew Wilcox <willy@infradead.org>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 1/3] fs: Introduce buffered_write_operations
Date: Thu, 1 Feb 2024 04:36:09 +0000 [thread overview]
Message-ID: <ZbsfuaANd4DIVb4w@casper.infradead.org> (raw)
In-Reply-To: <20240130081252.GC22621@lst.de>
On Tue, Jan 30, 2024 at 09:12:52AM +0100, Christoph Hellwig wrote:
> > +struct buffered_write_operations {
> > + int (*write_begin)(struct file *, struct address_space *mapping,
> > + loff_t pos, size_t len, struct folio **foliop,
> > + void **fsdata);
> > + int (*write_end)(struct file *, struct address_space *mapping,
> > + loff_t pos, size_t len, size_t copied,
> > + struct folio *folio, void **fsdata);
> > +};
>
> Should write_begin simply return the folio or an ERR_PTR instead of
> the return by reference?
OK, I've done that. It's a _lot_ more intrusive for the ext4
conversion. There's a higher risk of bugs. BUT I think it does end up
looking a bit cleaner. I also did the same conversion to iomap; ie
-static int iomap_write_begin(struct iomap_iter *iter, loff_t pos,
- size_t len, struct folio **foliop)
+static struct folio *iomap_write_begin(struct iomap_iter *iter, loff_t pos,
+ size_t len)
with corresponding changes. Again, ends up looking slightly cleaner.
> I also wonder if the fsdata paramter should go away - if a fs needs
> to pass forth and back fsdata, generic/filemap_perform_write is
> probably the wrong abstraction for it.
So I could get rid of fsdata in ext4; that works out fine.
We have three filesystems actually using fsdata (unless they call fsdata
something else ...)
fs/bcachefs/fs-io-buffered.c: *fsdata = res;
fs/f2fs/compress.c: *fsdata = cc->rpages;
fs/ocfs2/aops.c: *fsdata = wc;
bcachefs seems to actually be using it for its intended purpose --
passing a reservation between write_begin and write_end.
f2fs also doesn't seem terribly objectional; passing rpages between
begin & end.
ocfs2 is passing a ocfs2_write_ctxt between the two.
I don't know that it's a win to remove fsdata from these callbacks,
only to duplicate __generic_file_write_iter() into ocfs2,
generic_perform_write() into f2fs and ... er, I don't think bcachefs
uses any of the functions which would call back through
write_begin/write_end. So maybe that one's dead code?
Anyway, I'm most inclined to leave fsdata andling the way I had it
in v1, unless you have a better suggestion.
next prev parent reply other threads:[~2024-02-01 4:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 5:54 [PATCH 0/3] Start moving write_begin/write_end out of aops Matthew Wilcox (Oracle)
2024-01-30 5:54 ` [PATCH 1/3] fs: Introduce buffered_write_operations Matthew Wilcox (Oracle)
2024-01-30 8:12 ` Christoph Hellwig
2024-02-01 4:36 ` Matthew Wilcox [this message]
2024-02-01 4:42 ` Christoph Hellwig
2024-02-02 19:54 ` Matthew Wilcox
2024-01-31 3:14 ` kernel test robot
2024-01-30 5:54 ` [PATCH 2/3] fs: Supply optional buffered_write_operations in buffer.c Matthew Wilcox (Oracle)
2024-01-30 5:54 ` [PATCH 3/3] ext4: Convert to buffered_write_operations Matthew Wilcox (Oracle)
2024-01-30 6:13 ` Matthew Wilcox
2024-01-30 8:13 ` Christoph Hellwig
2024-02-01 15:12 ` kernel test robot
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=ZbsfuaANd4DIVb4w@casper.infradead.org \
--to=willy@infradead.org \
--cc=hch@lst.de \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).