Messages in this thread | | | Date | Tue, 8 Oct 2019 08:46:32 +1100 | From | Dave Chinner <> | Subject | Re: [PATCH 05/11] iomap: zero newly allocated mapped blocks |
| |
On Sun, Oct 06, 2019 at 05:46:02PM +0200, Christoph Hellwig wrote: > File systems like gfs2 don't support delayed allocations or unwritten > extents and thus allocate normal mapped blocks to fill holes. To > cover the case of such file systems allocating new blocks to fill holes > also zero out mapped blocks with the new flag. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> > --- > fs/iomap/buffered-io.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > index 23cc308f971d..4132c0cccb0a 100644 > --- a/fs/iomap/buffered-io.c > +++ b/fs/iomap/buffered-io.c > @@ -207,6 +207,14 @@ iomap_read_inline_data(struct inode *inode, struct page *page, > SetPageUptodate(page); > } > > +static inline bool iomap_block_needs_zeroing(struct inode *inode, > + struct iomap *iomap, loff_t pos) > +{ > + return iomap->type != IOMAP_MAPPED || > + (iomap->flags & IOMAP_F_NEW) || > + pos >= i_size_read(inode);
This is a change of logic - why is the IOMAP_F_NEW check added here and what bug does it fix?
Cheers,
Dave. -- Dave Chinner david@fromorbit.com
| |