On Mon, Sep 23, 2024 at 11:05:16PM -0700, Darrick J. Wong wrote: > Yeah, please do. What do you think of: > > "When a short write occurs, the filesystem might need to use ->iomap_end > to remove space reservations created in ->iomap_begin." ? Sounds good, I'll update it again. > > > Unrelated question about iomap_write_begin: Can we get rid of the > > > !mapping_large_folio_support if-body just prior to __iomap_get_folio? > > > filemap_get_folio won't return large folios if > > > !mapping_large_folio_support, so I think the separate check in iomap > > > isn't needed anymore? > > > > From the iomap POV it seems like we could (after checking no one > > is doing something weird with len in ->get_folio). > > The only user I know of is gfs2, which allocates a transaction and then > calls iomap_get_folio with pos/len unchanged. Yeah, so it _should_ be fine. Not really feeling like changing it now with all the other stuff in flight, though. And eventually I really want to sort out a few things in the area, like confusing __iomap_get_folio naming for the wrapper with iomap_get_folio as the default instance, and the fact that the get_folio and invalidation are indirect calls right next to each other. > > --D ---end quoted text---
