From patchwork Sun Jan 5 23:02:51 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gerhard Heift X-Patchwork-Id: 3435021 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id AF59DC02DC for ; Sun, 5 Jan 2014 23:02:58 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 12E7C20136 for ; Sun, 5 Jan 2014 23:02:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0C6B620122 for ; Sun, 5 Jan 2014 23:02:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751737AbaAEXCx (ORCPT ); Sun, 5 Jan 2014 18:02:53 -0500 Received: from mail-vc0-f174.google.com ([209.85.220.174]:40848 "EHLO mail-vc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751448AbaAEXCw (ORCPT ); Sun, 5 Jan 2014 18:02:52 -0500 Received: by mail-vc0-f174.google.com with SMTP id if17so8070226vcb.19 for ; Sun, 05 Jan 2014 15:02:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=r5BkVXAWNSG4Kss6OTmpr0uv26xBiHg4VTr1RlXICyo=; b=Kv0k00Jolv+OFn3B8e/ogAc0t+mZUBQO5JzGwenlSbfAlsgV5lAqC2DMZSFVGV4h77 N37e1q0+Nn60Wsw1zdkuydUwDv9VrtfEeuy0z5YVuy3wUBxftn91up+vd8ITswAgHCco ILNTHOnd6zu4Q+KhLD4TeEgurY7GRc8E5Nt6+tPv5TI718gYSXjsHhrh4KFuT/jHtzIK q4iurGTYbl4JuCt/OZwt2FFTBouwSbtp3pB6VUeksx2XJD3EZF63vX+kq9MgRdIi6YZB 3as2PR6+alnwSU1oKlBsFFq6y48jh/eE/RY0xl+wecD1iCnpB7FjVz6BDp2qYgPY39Gv A2Kg== X-Gm-Message-State: ALoCoQldRmXhfIVubLX4io86PVtiR3mzE/CHNQoQzmYeT1HGz+RdNVUjOt/mt3yU1r8BZnf/SbP4 MIME-Version: 1.0 X-Received: by 10.220.58.1 with SMTP id e1mr63117902vch.0.1388962971694; Sun, 05 Jan 2014 15:02:51 -0800 (PST) Received: by 10.58.253.72 with HTTP; Sun, 5 Jan 2014 15:02:51 -0800 (PST) X-Originating-IP: [134.130.115.115] Date: Mon, 6 Jan 2014 00:02:51 +0100 Message-ID: Subject: FILE_EXTENT_SAME changes mtime and ctime From: Gerhard Heift To: linux-btrfs@vger.kernel.org Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hello, I am currently playing with snapshots and manual deduplication of files. During these tests I noticed the change of ctime and mtime in the snapshot after the deduplication with FILE_EXTENT_SAME. Does this happens on purpose? Otherwise I would like to have ctime and mtime left unmodified, because on a read only snapshot I cannot change them back after the ioctl call. I attached a very basic patch, which illustrates my idea. Thanks, Gerhard diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 9d46f60..975d207 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -59,7 +59,7 @@ #include "dev-replace.h" static int btrfs_clone(struct inode *src, struct inode *inode, - u64 off, u64 olen, u64 olen_aligned, u64 destoff); + u64 off, u64 olen, u64 olen_aligned, u64 destoff, int update_time); /* Mask out flags that are inappropriate for the given type of inode. */ static inline __u32 btrfs_mask_flags(umode_t mode, __u32 flags) @@ -2683,7 +2683,7 @@ static int btrfs_extent_same(struct inode *src, u64 loff, u64 len, ret = btrfs_cmp_data(src, loff, dst, dst_loff, len); if (ret == 0) - ret = btrfs_clone(src, dst, loff, len, len, dst_loff); + ret = btrfs_clone(src, dst, loff, len, len, dst_loff, /* update time */ 0); out_unlock: btrfs_double_unlock(src, loff, dst, dst_loff, len); @@ -2836,9 +2836,10 @@ out: * @olen_aligned: Block-aligned value of olen, extent_same uses * identical values here * @destoff: Offset within @inode to start clone + * @update_time: Should we update ctime and mtime of @inode? */ static int btrfs_clone(struct inode *src, struct inode *inode, - u64 off, u64 olen, u64 olen_aligned, u64 destoff) + u64 off, u64 olen, u64 olen_aligned, u64 destoff, int update_time) { struct btrfs_root *root = BTRFS_I(inode)->root; struct btrfs_path *path = NULL; @@ -3081,8 +3082,10 @@ static int btrfs_clone(struct inode *src, struct inode *inode, btrfs_mark_buffer_dirty(leaf); btrfs_release_path(path); - inode_inc_iversion(inode); - inode->i_mtime = inode->i_ctime = CURRENT_TIME; + if (update_time) { + inode_inc_iversion(inode); + inode->i_mtime = inode->i_ctime = CURRENT_TIME; + } /* * we round up to the block size at eof when @@ -3227,7 +3230,7 @@ static noinline long btrfs_ioctl_clone(struct file *file, unsigned long srcfd, lock_extent_range(src, off, len); - ret = btrfs_clone(src, inode, off, olen, len, destoff); + ret = btrfs_clone(src, inode, off, olen, len, destoff, /* update time */ 1); unlock_extent(&BTRFS_I(src)->io_tree, off, off + len - 1); out_unlock: