Directory mtime update issue (kernel 2.6.25)

Directory mtime update issue (kernel 2.6.25)

[Michael-John Turner]

Hi all,

I'm a recent convert to XFS and am experiencing something that I consider
rather odd. When I move a directory on the same filesystem, XFS updates the
directory's mtime, which is something I wouldn't expect to happen. I tested
the same set of commands on a tmpfs filesystem and the renamed directory's
mtime doesn't change. Similarly, when I move a file between directories on
an XFS filesystem, the file's mtime doesn't change (as expected).

Is this behaviour correct? I'm running Linux kernel 2.6.25.6 on an x86_64
system, filesystem mounted with the standard options (see below).

For example (~ and ~/tmp are the same filesystem, /home):

[0] mj@majestic:~/tmp$ mount |grep home
/dev/mapper/data-home on /home type xfs (rw)
[0] mj@majestic:~/tmp$ mkdir test
[0] mj@majestic:~/tmp$ ls -ld test
drwxr-sr-x 2 mj mj 6 Jun 18 15:28 test
[0] mj@majestic:~/tmp$ touch -t 200801011530 test
[0] mj@majestic:~/tmp$ ls -ld test
drwxr-sr-x 2 mj mj 6 Jan  1 15:30 test
[0] mj@majestic:~/tmp$ stat test
  File: `test'
  Size: 6               Blocks: 0          IO Block: 4096   directory
Device: fd00h/64768d    Inode: 951267331   Links: 2
Access: (2755/drwxr-sr-x)  Uid: ( 1000/      mj)   Gid: ( 1000/      mj)
Access: 2008-01-01 15:30:00.000000000 +0000
Modify: 2008-01-01 15:30:00.000000000 +0000
Change: 2008-06-18 15:29:08.173750666 +0100
[0] mj@majestic:~/tmp$ mv test test1
[0] mj@majestic:~/tmp$ ls -ld test1
drwxr-sr-x 2 mj mj 6 Jan  1 15:30 test1
[0] mj@majestic:~/tmp$ mv test1 ..
[0] mj@majestic:~/tmp$ ls -ld ../test1
drwxr-sr-x 2 mj mj 6 Jun 18 15:30 ../test1
  File: `../test1'
  Size: 6               Blocks: 0          IO Block: 4096   directory
Device: fd00h/64768d    Inode: 951267331   Links: 2
Access: (2755/drwxr-sr-x)  Uid: ( 1000/      mj)   Gid: ( 1000/      mj)
Access: 2008-01-01 15:30:00.000000000 +0000
Modify: 2008-06-18 15:30:02.814078187 +0100
Change: 2008-06-18 15:30:02.814078187 +0100

-mj
-- 
Michael-John Turner 
mj@mjturner.net      <>  http://mjturner.net/

Re: Directory mtime update issue (kernel 2.6.25)

[Christoph Hellwig]

On Wed, Jun 18, 2008 at 03:45:34PM +0100, Michael-John Turner wrote:
> Hi all,
> 
> I'm a recent convert to XFS and am experiencing something that I consider
> rather odd. When I move a directory on the same filesystem, XFS updates the
> directory's mtime, which is something I wouldn't expect to happen. I tested
> the same set of commands on a tmpfs filesystem and the renamed directory's
> mtime doesn't change. Similarly, when I move a file between directories on
> an XFS filesystem, the file's mtime doesn't change (as expected).
> 
> Is this behaviour correct? I'm running Linux kernel 2.6.25.6 on an x86_64
> system, filesystem mounted with the standard options (see below).

Posix says about rename(2):

Upon successful completion, rename() shall mark for update the st_ctime
and st_mtime fields of the parent directory of each file.

It doesn't mention anything about timestampt updates on the renamed
file nor the victim.  Ext2 and friends update ctime on the renamed
inode and victim and have this comment:

/*
 * Like most other Unix systems, set the ctime for inodes on a
 * rename.
 * inode_dec_link_count() will mark the inode dirty.
 */

XFS does indeed updated the mtime too for the case when the source is
a directory and we get a new parent but just the ctime in all other
cases, which seems highly dubious to me.

XFS also has an interesting comment on why ctime is updated at all:

		/*      
		 * We always want to hit the ctime on the source inode.
		 * We do it in the if clause above for the 'new_parent &&
		 * src_is_directory' case, and here we get all the other
		 * cases.  This isn't strictly required by the standards
		 * since the source inode isn't really being changed,
		 * but old unix file systems did it and some incremental
		 * backup programs won't work without it.
		 */

Below is an untested patch to always just update the ctime:


Index: linux-2.6-xfs/fs/xfs/xfs_rename.c
===================================================================
--- linux-2.6-xfs.orig/fs/xfs/xfs_rename.c	2008-06-18 18:24:38.000000000 +0200
+++ linux-2.6-xfs/fs/xfs/xfs_rename.c	2008-06-18 18:30:17.000000000 +0200
@@ -336,22 +336,18 @@ xfs_rename(
 		ASSERT(error != EEXIST);
 		if (error)
 			goto abort_return;
-		xfs_ichgtime(src_ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG);
-
-	} else {
-		/*
-		 * We always want to hit the ctime on the source inode.
-		 * We do it in the if clause above for the 'new_parent &&
-		 * src_is_directory' case, and here we get all the other
-		 * cases.  This isn't strictly required by the standards
-		 * since the source inode isn't really being changed,
-		 * but old unix file systems did it and some incremental
-		 * backup programs won't work without it.
-		 */
-		xfs_ichgtime(src_ip, XFS_ICHGTIME_CHG);
 	}
 
 	/*
+	 * We always want to hit the ctime on the source inode.
+	 *
+	 * This isn't strictly required by the standards since the source
+	 * inode isn't really being changed, but old unix file systems did
+	 * it and some incremental backup programs won't work without it.
+	 */
+	xfs_ichgtime(src_ip, XFS_ICHGTIME_CHG);
+
+	/*
 	 * Adjust the link count on src_dp.  This is necessary when
 	 * renaming a directory, either within one parent when
 	 * the target existed, or across two parent directories.

Re: Directory mtime update issue (kernel 2.6.25)

[Michael-John Turner]

On Wed, Jun 18, 2008 at 12:33:56PM -0400, Christoph Hellwig wrote:
> XFS does indeed updated the mtime too for the case when the source is
> a directory and we get a new parent but just the ctime in all other
> cases, which seems highly dubious to me.

Thanks for the prompt reply and the patch. I'm surprised this hasn't been
mentioned before as every other Unix filesystem I've used has not updated
the moved file's mtime during a rename(2). It's also odd that XFS only
changes the mtime when there's a new parent.

What does everyone else think? Would it be possible to have this patch or a
similar one committed upstream?

-mj
-- 
Michael-John Turner 
mj@mjturner.net      <>  http://mjturner.net/

Re: Directory mtime update issue (kernel 2.6.25)

[Michael-John Turner]

On Wed, Jun 18, 2008 at 12:33:56PM -0400, Christoph Hellwig wrote:
> Below is an untested patch to always just update the ctime:

Just a quick update - the patch does the trick and changes the rename(2)
behaviour to be what I expect. Now, when a directory is renamed, its mtime
doesn't change, even if it has a new parent.

-mj
-- 
Michael-John Turner 
mj@mjturner.net      <>  http://mjturner.net/

Re: Directory mtime update issue (kernel 2.6.25)

[Christoph Hellwig]

On Wed, Jun 18, 2008 at 08:10:45PM +0100, Michael-John Turner wrote:
> Thanks for the prompt reply and the patch. I'm surprised this hasn't been
> mentioned before as every other Unix filesystem I've used has not updated
> the moved file's mtime during a rename(2). It's also odd that XFS only
> changes the mtime when there's a new parent.
> 
> What does everyone else think? Would it be possible to have this patch or a
> similar one committed upstream?

The patch also passes xfsqa, so it should be ready now.