Re: [PATCH 18/32] fs: Provide operation for fetching mapping_metadata_bhs
Jan Kara <[email protected]> Wed, 4 Mar 2026 14:38:41 +0100
| Newsgroups | gmane.linux.kernel.aio.general,gmane.linux.file-systems,gmane.comp.file-systems.ext4,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <4ji4ihp7tzhxr35t2vgnswfskrjnsuo4eys4klblnor2b663pp@x3khuzh7cxhv> |
On Wed 04-03-26 05:19:15, Christoph Hellwig wrote: > On Tue, Mar 03, 2026 at 11:34:07AM +0100, Jan Kara wrote: > > When we move mapping_metadata_bhs to fs-private part of an inode the > > generic code will need a way to get to this struct from general struct > > inode. Add inode operation for this similarly to operation for grabbing > > offset_ctx. > > Do we even need this? With your previous cleanups almost all of the > places that need the buffers list are called more or less directly > from the file systems. Can we take it all the way and just pass the > mapping_metadata_bhs to those functions? I was looking into that. Passing these to sync_mapping_buffers(), invalidate_inode_buffers() is easy. Passing to mark_buffer_dirty_inode() is relatively tedious but doable. Where it gets difficult are calls like bforget() and most importantly try_to_free_buffers() on bdev mapping where you currently have no way to get to the mmb struct... We do have b_assoc_map pointer in buffer_head which we could switch to point to mmb instead but IO error handling on bhs needs to get to the mapping from bh so we'd then have to add address_space pointer to mmb for these uses. All in all it's doable but I've decided it isn't really worth it. Honza -- Jan Kara <[email protected]> SUSE Labs, CR -- To unsubscribe, send a message with 'unsubscribe linux-aio' in the body to [email protected]. For more info on Linux AIO, see: http://www.kvack.org/aio/ Don't email: <a href=mailto:"[email protected]">[email protected]</a>