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
