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, Josef _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
