Re: [PATCH RFC 02/29] iomap: introduce iomap_read/write_region interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2025-08-11 13:43:37, Christoph Hellwig wrote:
> On Tue, Jul 29, 2025 at 03:22:52PM -0700, Darrick J. Wong wrote:
> > ...and these sound a lot like filemap_read and iomap_write_iter.
> > Why not use those?  You'd get readahead for free.  Though I guess
> > filemap_read cuts off at i_size so maybe that's why this is necessary?
> > 
> > (and by extension, is this why the existing fsverity implementations
> > seem to do their own readahead and reading?)
> > 
> > ((and now I guess I see why this isn't done through the regular kiocb
> > interface, because then we'd be exposing post-EOF data hiding to
> > everyone in the system))
> 
> Same thoughts here.  It seems like we should just have a beyond-EOF or
> fsverity flag for ->read_iter / ->write_iter and consolidate all this
> code.  That'll also go along nicely with the flag in the writepage_ctx
> suggested by Joanne.
> 

In addition to being bound by the isize the fiemap_read() copies
data to the iov_iter, which is not really needed for fsverity. Also,
even on fsverity systems this function will not be called on the
fsverity metadata, not sure how much overhead these checks would add
but this is probably not desired anyway.

Is adding something like fiemap_fetch or fiemap_read_unbound to just
call filemap_get_pages() would be better? A filemap_read() without
isize check and copying basically

The write path seems to be fine, adding kiocb->ki_flags and
iomap_iter->flags flag to work beyond EOF to skip inode size updates
in iomap_write_iter() seems to be enough.

-- 
- Andrey





[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux