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
