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>