Hi Matthew, I'm interested in enabling large folios support in overlayfs. I've been doing some digging and it looked like it should JustWork already, but testing suggests that's not the case. Given that's not the case, then I think there may be a bug relating to BS > PS when XFS is providing one of the layers. So overlayfs has a "lower layer" and an "upper layer". Both are just directories on other file systems. The lower layer is read-only. The upper layer contains any created files as well as any modified files (when modified, the whole file is "copied up" to the upper then modified). The upper layer also contains "white-outs"; meta data to describe a deleted file. The final view is the merged views of these 2 layers. Anyway, overlayfs creates/maintains its own inodes (and mappings), but delegates IO (.read_iter/.write_iter) down to the "real" file on the real filesystem; one of the 2 layers. overlayfs never calls mapping_set_large_folios() for it's mappings. But it also doesn't implement any of the mapping ops (except direct_IO). overlayfs's read_iter() will delegate into the real file's read_iter() (via backing_file_read_iter()). For XFS that means it will end up calling generic_file_read_iter() to interact with the page cache which will use the mapping ops for the real mapping (i.e. XFS). Since XFS should have called mapping_set_large_folios(), we should get large folios, right? Except, testing this from user space shows the folios are small when coming from overlayfs, backed by XFS. The same test case shows the folios are large when the file is pulled directly from XFS. So I guess my unserstanding of this is wrong and for some reason we need to call mapping_set_large_folios() for overlayfs's mapping, or do something else? Although I don't really get why that would even be used... But the fact that this doesn't all JustWork, makes me concerned that this is all broken for BS > PS? If the underlying FS requires all folios to be bigger than order-0, but overlayfs is somehow fixing it so that all folios are order-0, don't we have a mismatch? FWIW, ChatGPT was suggesting that mapping_set_large_folios() DOES need to be called for the overlayfs mapping, but from code inspection I don't see why. If needed, it also opens up the problem that if the file needs to be copied up to the upper layer in future, we don't know if that can support large folios (or more generally we don't know if there is a single configuration that can be supported by both layers). So it would suggest a need to change the large folio configuration on an active mapping, which I don't think is currently allowed. Anyway, from my rambling, you can probably tell there are a bunch of holes in my mental model. Any clarifications/suggestions you have would be gratefully received! Thanks Ryan
