Re: [PATCH V3 07/10] xfs: Check for extent overflow when inserting a hole

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

 



On Monday 31 August 2020 10:16:35 PM IST Darrick J. Wong wrote:
> On Thu, Aug 20, 2020 at 11:13:46AM +0530, Chandan Babu R wrote:
> > The extent mapping the file offset at which a hole has to be
> > inserted will be split into two extents causing extent count to
> > increase by 1.
> > 
> > Signed-off-by: Chandan Babu R <chandanrlinux@xxxxxxxxx>
> > ---
> >  fs/xfs/libxfs/xfs_inode_fork.h | 6 ++++++
> >  fs/xfs/xfs_bmap_util.c         | 9 +++++++++
> >  2 files changed, 15 insertions(+)
> > 
> > diff --git a/fs/xfs/libxfs/xfs_inode_fork.h b/fs/xfs/libxfs/xfs_inode_fork.h
> > index 83ff90e2a5fe..d0e49b015b62 100644
> > --- a/fs/xfs/libxfs/xfs_inode_fork.h
> > +++ b/fs/xfs/libxfs/xfs_inode_fork.h
> > @@ -73,6 +73,12 @@ struct xfs_ifork {
> >   * Hence extent count can increase by 2.
> >   */
> >  #define XFS_IEXT_WRITE_UNWRITTEN_CNT	(2)
> > +/*
> > + * The extent mapping the file offset at which a hole has to be inserted will be
> > + * split into two extents causing extent count to increase by 1.
> > + */
> > +#define XFS_IEXT_INSERT_HOLE_CNT	(1)
> 
> Given my earlier comments about how patch 3 is really only testing the
> hole punching case, maybe it should be folded into this one?  They're
> both inserting holes in the extent map.
>
I agree. I will make the required changes.

-- 
chandan






[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