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. 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). :-) Cheers, - Ted
