Re: [f2fs-dev] [PATCH 02/14] btrfs: convert get_next_extent_buffer() to take a folio

[Matthew Wilcox <willy@infradead.org>]

On Mon, Aug 26, 2024 at 10:13:01AM -0400, Josef Bacik wrote:
> On Fri, Aug 23, 2024 at 04:38:27PM +0100, Matthew Wilcox wrote:
> > On Fri, Aug 23, 2024 at 11:43:41AM +0930, Qu Wenruo wrote:
> > > 在 2024/8/23 07:55, Qu Wenruo 写道:
> > > > 在 2024/8/22 21:37, Matthew Wilcox 写道:
> > > > > On Thu, Aug 22, 2024 at 08:28:09PM +0930, Qu Wenruo wrote:
> > > > > > But what will happen if some writes happened to that larger folio?
> > > > > > Do MM layer detects that and split the folios? Or the fs has to go the
> > > > > > subpage routine (with an extra structure recording all the subpage flags
> > > > > > bitmap)?
> > > > > 
> > > > > Entirely up to the filesystem.  It would help if btrfs used the same
> > > > > terminology as the rest of the filesystems instead of inventing its own
> > > > > "subpage" thing.  As far as I can tell, "subpage" means "fs block size",
> > > > > but maybe it has a different meaning that I haven't ascertained.
> > > > 
> > > > Then tell me the correct terminology to describe fs block size smaller
> > > > than page size in the first place.
> > > > 
> > > > "fs block size" is not good enough, we want a terminology to describe
> > > > "fs block size" smaller than page size.
> > 
> > Oh dear.  btrfs really has corrupted your brain.  Here's the terminology
> > used in the rest of Linux:
> 
> This isn't necessary commentary, this gives the impression that we're
> wrong/stupid/etc.  We're all in this community together, having public, negative
> commentary like this is unnecessary, and frankly contributes to my growing
> desire/priorities to shift most of my development outside of the kernel
> community.  And if somebody with my experience and history in this community is
> becoming more and more disillusioned with this work and making serious efforts
> to extricate themselves from the project, then what does that say about our
> ability to bring in new developers?  Thanks,

You know what?  I'm disillusioned too.  It's been over two and a half
years since folios were added (v5.16 was the first release with folios).
I knew it would be a long project (I was anticipating five years).
I was expecting to have to slog through all the old unmaintained crap
filesystems doing minimal conversions.  What I wasn't expecting was for
all the allegedly maintained filesystems to sit on their fucking hands and
ignore it as long as possible.  The biggest pains right now are btrfs,
ceph and f2fs, all of which have people who are paid to work on them!
I had to do ext4 largely myself.

Some filesystems have been great.  XFS worked with me as I did that
filesystem first.  nfs took care of their own code.  Dave Howells has
done most of the other network filesystems.  Many other people have
also helped.

But we can't even talk to each other unless we agree on what words mean.
And btrfs inventing its own terminology for things which already exist
in other filesystems is extremely unhelpful.

We need to remove the temporary hack that is CONFIG_READ_ONLY_THP_FOR_FS.
That went in with the understanding that filesystems that mattered would
add large folio support.  When I see someone purporting to represent
btrfs say "Oh, we're not going to do that", that's a breach of trust.

When I'm accused of not understanding things from the filesystem
perspective, that's just a lie.  I have 192 commits in fs/ between 6.6
and 6.10 versus 160 in mm/ (346 commits in both combined, so 6 commits
are double-counted because they touch both).  This whole project has
been filesystem-centric from the beginning.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel