Jan Kara <[email protected]> writes: > On Wed 25-02-26 07:20:38, Ackerley Tng wrote: >> Add .unaccount_folio callback to allow filesystems to do accounting-related >> updates to the inode or struct address_space mapping, when the folio is >> about to be removed from the filemap/page_cache. >> >> .free_folio cannot be used since .free_folio cannot assume that struct >> address_space mapping still exists. > > I agree .free_folio isn't the right place. > >> From the name, .invalidate_folio and .release_folio seem suitable, but >> those are meant only to handle freeing of a folio's private >> data. .release_folio is also not called in the truncation path. > > But this I don't quite understand. .invalidate_folio is called when > the file is truncated (or when the whole inode is being evicted from > memory). Filesystem can do whatever it wishes there, not just free folio > private data. Are you pointing at folio_needs_release() check? But you can > mark your mappings with mapping_release_always() - it's there exactly for > such usecases... Am I missing something? >
Looking at it again, mapping_release_always() gates both .release_folio() in filemap_release_folio() and .invalidate_folio() in truncate_cleanup_folio() and truncate_inode_partial_folio(). Let me try that out in the next revision. Thanks for pointing this out! > Honza > -- > Jan Kara <[email protected]> > SUSE Labs, CR
