[PATCH] xfs: update ctime and mtime on clone destinatation inodes

[PATCH] xfs: update ctime and mtime on clone destinatation inodes

[Christoph Hellwig]

We're changing both metadata and data, so we need to update the
timestamps.   This follows existing btrfs behavior.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_reflink.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
index d5a2cf2b469b..8877e6f5e35d 100644
--- a/fs/xfs/xfs_reflink.c
+++ b/fs/xfs/xfs_reflink.c
@@ -967,9 +967,6 @@ xfs_reflink_update_dest(
 	struct xfs_trans	*tp;
 	int			error;
 
-	if (newlen <= i_size_read(VFS_I(dest)) && cowextsize == 0)
-		return 0;
-
 	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_ichange, 0, 0, 0, &tp);
 	if (error)
 		goto out_error;
@@ -988,6 +985,7 @@ xfs_reflink_update_dest(
 		dest->i_d.di_flags2 |= XFS_DIFLAG2_COWEXTSIZE;
 	}
 
+	xfs_trans_ichgtime(tp, dest, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG);
 	xfs_trans_log_inode(tp, dest, XFS_ILOG_CORE);
 
 	error = xfs_trans_commit(tp);
-- 
2.11.0

Re: [PATCH] xfs: update ctime and mtime on clone destinatation inodes

[Darrick J. Wong]

On Thu, Feb 02, 2017 at 05:24:56PM +0100, Christoph Hellwig wrote:
> We're changing both metadata and data, so we need to update the
> timestamps.   This follows existing btrfs behavior.

/me wonders, should the mtime change if we're deduping?  We're
definitely changing metadata, but we shouldn't be making any
user-visible changes to the file data.

--D

> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/xfs/xfs_reflink.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
> index d5a2cf2b469b..8877e6f5e35d 100644
> --- a/fs/xfs/xfs_reflink.c
> +++ b/fs/xfs/xfs_reflink.c
> @@ -967,9 +967,6 @@ xfs_reflink_update_dest(
>  	struct xfs_trans	*tp;
>  	int			error;
>  
> -	if (newlen <= i_size_read(VFS_I(dest)) && cowextsize == 0)
> -		return 0;
> -
>  	error = xfs_trans_alloc(mp, &M_RES(mp)->tr_ichange, 0, 0, 0, &tp);
>  	if (error)
>  		goto out_error;
> @@ -988,6 +985,7 @@ xfs_reflink_update_dest(
>  		dest->i_d.di_flags2 |= XFS_DIFLAG2_COWEXTSIZE;
>  	}
>  
> +	xfs_trans_ichgtime(tp, dest, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG);
>  	xfs_trans_log_inode(tp, dest, XFS_ILOG_CORE);
>  
>  	error = xfs_trans_commit(tp);
> -- 
> 2.11.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] xfs: update ctime and mtime on clone destinatation inodes

[Christoph Hellwig]

On Thu, Feb 02, 2017 at 09:45:47AM -0800, Darrick J. Wong wrote:
> On Thu, Feb 02, 2017 at 05:24:56PM +0100, Christoph Hellwig wrote:
> > We're changing both metadata and data, so we need to update the
> > timestamps.   This follows existing btrfs behavior.
> 
> /me wonders, should the mtime change if we're deduping?  We're
> definitely changing metadata, but we shouldn't be making any
> user-visible changes to the file data.

Good point - we're hitting this from the dedup path as well.
I think we should not be updating mtime for dedupe.

Re: [PATCH] xfs: update ctime and mtime on clone destinatation inodes

[Amir Goldstein]

On Thu, Feb 2, 2017 at 7:47 PM, Christoph Hellwig <hch@lst.de> wrote:
> On Thu, Feb 02, 2017 at 09:45:47AM -0800, Darrick J. Wong wrote:
>> On Thu, Feb 02, 2017 at 05:24:56PM +0100, Christoph Hellwig wrote:
>> > We're changing both metadata and data, so we need to update the
>> > timestamps.   This follows existing btrfs behavior.
>>
>> /me wonders, should the mtime change if we're deduping?  We're
>> definitely changing metadata, but we shouldn't be making any
>> user-visible changes to the file data.
>
> Good point - we're hitting this from the dedup path as well.
> I think we should not be updating mtime for dedupe.

Since CAP_ADMIN is allowed to dedup to an O_RDONLY dest
updating mtime would be even creepier.