| Message ID | 20191015154345.13052-3-hch@lst.de (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [01/12] xfs: initialize iomap->flags in xfs_bmbt_to_iomap | expand |
On Tue, Oct 15, 2019 at 05:43:35PM +0200, Christoph Hellwig wrote: > Don't set IOMAP_F_NEW if we COW over and existing allocated range, as "..over an existing..." > these aren't strictly new allocations. This is required to be able to > use IOMAP_F_NEW to zero newly allocated blocks, which is required for > the iomap code to fully support file systems that don't do delayed > allocations or use unwritten extents. > > Signed-off-by: Christoph Hellwig <hch@lst.de> Other than that, Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> --D > --- > fs/xfs/xfs_iomap.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c > index 54c9ec7ad337..c0a492353826 100644 > --- a/fs/xfs/xfs_iomap.c > +++ b/fs/xfs/xfs_iomap.c > @@ -707,9 +707,12 @@ xfs_file_iomap_begin_delay( > * Flag newly allocated delalloc blocks with IOMAP_F_NEW so we punch > * them out if the write happens to fail. > */ > - iomap_flags |= IOMAP_F_NEW; > - trace_xfs_iomap_alloc(ip, offset, count, whichfork, > - whichfork == XFS_DATA_FORK ? &imap : &cmap); > + if (whichfork == XFS_DATA_FORK) { > + iomap_flags |= IOMAP_F_NEW; > + trace_xfs_iomap_alloc(ip, offset, count, whichfork, &imap); > + } else { > + trace_xfs_iomap_alloc(ip, offset, count, whichfork, &cmap); > + } > done: > if (whichfork == XFS_COW_FORK) { > if (imap.br_startoff > offset_fsb) { > -- > 2.20.1 >
On Tue, Oct 15, 2019 at 05:43:35PM +0200, Christoph Hellwig wrote: > Don't set IOMAP_F_NEW if we COW over and existing allocated range, as > these aren't strictly new allocations. This is required to be able to > use IOMAP_F_NEW to zero newly allocated blocks, which is required for > the iomap code to fully support file systems that don't do delayed > allocations or use unwritten extents. > > Signed-off-by: Christoph Hellwig <hch@lst.de> looks fine. Reviewed-by: Dave Chinner <dchinner@redhat.com>
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 54c9ec7ad337..c0a492353826 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -707,9 +707,12 @@ xfs_file_iomap_begin_delay( * Flag newly allocated delalloc blocks with IOMAP_F_NEW so we punch * them out if the write happens to fail. */ - iomap_flags |= IOMAP_F_NEW; - trace_xfs_iomap_alloc(ip, offset, count, whichfork, - whichfork == XFS_DATA_FORK ? &imap : &cmap); + if (whichfork == XFS_DATA_FORK) { + iomap_flags |= IOMAP_F_NEW; + trace_xfs_iomap_alloc(ip, offset, count, whichfork, &imap); + } else { + trace_xfs_iomap_alloc(ip, offset, count, whichfork, &cmap); + } done: if (whichfork == XFS_COW_FORK) { if (imap.br_startoff > offset_fsb) {
Don't set IOMAP_F_NEW if we COW over and existing allocated range, as these aren't strictly new allocations. This is required to be able to use IOMAP_F_NEW to zero newly allocated blocks, which is required for the iomap code to fully support file systems that don't do delayed allocations or use unwritten extents. Signed-off-by: Christoph Hellwig <hch@lst.de> --- fs/xfs/xfs_iomap.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)