On 2020/6/11 下午10:11, Goldwyn Rodrigues wrote: > On 13:31 10/06, Qu Wenruo wrote: >> >> >> On 2020/6/6 上午4:48, Goldwyn Rodrigues wrote: >>> In current scenarios, for XFS, it would mean that a page invalidation >>> would end up being a writeback error. So, if iomap returns zero, fall >>> back to biffered I/O. XFS has never supported fallback to buffered I/O. >>> I hope it is not "never will" ;) >>> >>> With mixed buffered and direct writes in btrfs, the pages may not be >>> released the extent may be locked in the ordered extents cleanup thread, >> >> I'm wondering can we handle this case in a different way. >> >> In fact btrfs has its own special handling for invalidating pages. >> Btrfs will first look for any ordered extents covering the page, finish >> the ordered extent manually, then invalidate the page. >> >> I'm not sure why invalidate_inode_pages2_range() used in dio iomap code >> does not use the fs specific invalidatepage(), but only do_lander_page() >> then releasepage(). >> >> Shouldn'y we btrfs implement the lander_page() to handle ordered extents >> properly? >> Or is there any special requirement? >> > > The problem is aops->launder_page() is called only if PG_Dirty is > set. In this case it is not because we just performed a writeback. For the dio iomap code, before btrfs_finish_ordered_io(), the pages in ordered ranges are still dirty. So launder_page() here can still get triggered to finish the ordered extent. > > Also, it is not just ordered ordered extent writeback which may lock > the extent, a buffered read can lock as well. > That's right. But at least that would greatly reduce the possibility for btrfs to fall back to buffered IO, right? Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
