On Thu, Oct 06, 2016 at 12:44:33PM -0400, Brian Foster wrote: > On Thu, Sep 29, 2016 at 08:09:46PM -0700, Darrick J. Wong wrote: > > When we're freeing blocks (truncate, punch, etc.), clear all CoW > > reservations in the range being freed. If the file block count > > drops to zero, also clear the inode reflink flag. > > > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > --- > > fs/xfs/xfs_inode.c | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > > > > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c > > index 0c25a76..8c971fd 100644 > > --- a/fs/xfs/xfs_inode.c > > +++ b/fs/xfs/xfs_inode.c > > @@ -49,6 +49,7 @@ > > #include "xfs_trans_priv.h" > > #include "xfs_log.h" > > #include "xfs_bmap_btree.h" > > +#include "xfs_reflink.h" > > > > kmem_zone_t *xfs_inode_zone; > > > > @@ -1586,6 +1587,18 @@ xfs_itruncate_extents( > > goto out; > > } > > > > + /* Remove all pending CoW reservations. */ > > + error = xfs_reflink_cancel_cow_blocks(ip, &tp, first_unmap_block, > > + last_block); > > + if (error) > > + goto out; > > + > > + /* > > + * Clear the reflink flag if we truncated everything. > > + */ > > + if (ip->i_d.di_nblocks == 0 && xfs_is_reflink_inode(ip)) > > + ip->i_d.di_flags2 &= ~XFS_DIFLAG2_REFLINK; > > + > > So this implies the reflink flag is more of an optimization than an > accurate assessment of reflink state (e.g., we can have DIFLAG2_REFLINK > w/o shared extents, but we should never have shared extents w/o the > flag) because this wouldn't clear the flag on a partial truncate that > happened to unmap all of the shared extents from the file. Yes, not to mention that (bugs notwithstanding) all the CoW stuff shuts off if the inode flag isn't set. > That seems fine, I'll just note there's one small potential conflict > ahead where we (dis)allow setting the realtime state based on the > reflink flag. Hmm. You're right, if we're able to set the rt flag (i.e. data size is zero) then we ought to just clear the reflink flag. --D > > Brian > > > /* > > * Always re-log the inode so that our permanent transaction can keep > > * on rolling it forward in the log. > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
