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

[Josef Bacik <josef@toxicpanda.com>]

On Mon, Aug 26, 2024 at 05:56:01PM +0100, Matthew Wilcox wrote:
> 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.

I'm not talking about the pace of change, I'm talking about basic, professional
communication standards.  Being frustrated is one thing, taking it out on a
developer or a project in a public forum is another.  Thanks,

Josef


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