Re: [PATCH 02/10] iomap: remove iomap_file_buffered_write_punch_delalloc

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

 



On Mon, Sep 23, 2024 at 11:05:16PM -0700, Darrick J. Wong wrote:
> Yeah, please do.  What do you think of:
> 
> "When a short write occurs, the filesystem might need to use ->iomap_end
> to remove space reservations created in ->iomap_begin." ?

Sounds good, I'll update it again.

> > > Unrelated question about iomap_write_begin: Can we get rid of the
> > > !mapping_large_folio_support if-body just prior to __iomap_get_folio?
> > > filemap_get_folio won't return large folios if
> > > !mapping_large_folio_support, so I think the separate check in iomap
> > > isn't needed anymore?
> > 
> > From the iomap POV it seems like we could (after checking no one
> > is doing something weird with len in ->get_folio).
> 
> The only user I know of is gfs2, which allocates a transaction and then
> calls iomap_get_folio with pos/len unchanged.

Yeah, so it _should_ be fine.  Not really feeling like changing it now
with all the other stuff in flight, though.  And eventually I really
want to sort out a few things in the area, like confusing
__iomap_get_folio naming for the wrapper with iomap_get_folio as
the default instance, and the fact that the get_folio and invalidation
are indirect calls right next to each other.

> 
> --D
---end quoted text---




[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