Thanks for the reply, Ted. On Mon, Jun 23, 2025 at 10:17:53AM -0400, Theodore Ts'o wrote: > If you want to review and test the ext4/iomap changes, that would be > great. Be aware, though, that there are some features of ext4 > (example: data journalling, fscrypt, fsverity, etc.) that the current > iomap buffered I/O code may not support today. The alternatives are > to keep the existing ext4 code paths for those file system features, > or to try to add that functionality into iomap. There are of course > tradeoffs to both alternatives; one might result in more code that we > have to maintain; the other might require a lot more work. > > It _might_ be less effort to add LBS support to native ext4 code. I > think the main thing is to make sure that we always we use a large > folio and not fall back to a sub-blocksize set of pages. So again, > it's all about tradeoffs and what you consider to be the highest > priority. @Baokun are your LBS patches based on the native ext4 code or on top of Zhang's iomap patches. > > For myself, my primary concern is to keep the code maintainable and to > not result in any test regressions. If your goal is to get more file > systems to use iomap for buffered I/O, that might be different than > those who are aiming to get performance or improved hardware support > ASAP as your higher priority. I will say that in the ideal world, we > would eventually migrate to use the iomap code for buffered I/O for at > least the most common case. But if we end up having an intermediate > way station where we have large folio support for LBS before we get to > that desired end state, I'm open to that, so long as the code stays > maintainable and bug-free(tm). :-) > This makes sense. Thanks, Ted. -- Pankaj Raghav
