Topic
  • 11 replies
  • Latest Post - ‏2012-09-10T14:47:02Z by SystemAdmin
mduff
mduff
35 Posts

Pinned topic mtime change on directory move

‏2012-09-07T05:00:14Z |
Hello all,

GPFS is updating the mtime when a directory is moved. This doesn't seem to be the case with other filesystems. I have tested with -E yes and no, and with -S yes and no, and nothing makes a difference. Mount options won't do much either, as this is just another way to use the -E and -S options. For the other filesystems I have tested on, the mtime is preserved when moving a directory.

In any case, it seems that moving a directory should not be considered a modification. Does GPFS consider a directory move a "data modification"?
GPFS defines mtime as:
mtime values

mtime is a standard file attribute that represents the time when the file was last modified. The -E
parameter controls when the mtime is updated. The default is -E yes, which results in standard interfaces
including the stat() and fstat() calls reporting exact mtime values. Specifying -E no results in the stat()
and fstat() calls reporting the mtime value available at the completion of the last sync period. This may
result in the calls not always reporting the exact mtime. Setting -E no can affect backup operations that
rely on last modified time or the operation of policies using the MODIFICATION_TIME file attribute.
There are exceptions, but these don't explain why mtime would be updated on a directory move:

Exceptions to Open Group technical standards
GPFS is designed so that most applications written to The Open Group technical standard for file system
calls can access GPFS data with no modification, however, there are some exceptions.
Applications that depend on exact reporting of changes to the following fields returned by the stat() call
may not work as expected:
1. exact mtime
2. mtime
3. ctime
4. atime
Providing exact support for these fields would require significant performance degradation to all
applications executing on the system. These fields are guaranteed accurate when the file is closed.
These values will be accurate on a node right after it accesses or modifies a file, but may not be accurate
for a short while when a file is accessed or modified on some other node.
If 'exact mtime' is specified for a file system (using the mmcrfs or mmchfs commands with the -E yes
flag), the mtime and ctime values are always correct by the time the stat() call gives its answer. If 'exact
mtime' is not specified, these values will be accurate after a couple of minutes, to allow the
synchronization daemons to propagate the values to all nodes. Regardless of whether 'exact mtime' is
specified, the atime value will be accurate after a couple of minutes, to allow for all the synchronization
daemons to propagate changes.
Alternatively, you may use the GPFS calls, gpfs_stat() and gpfs_fstat() to return exact mtime and atime
values.
The delayed update of the information returned by the stat() call also impacts system commands which
display disk usage, such as du or df. The data reported by such commands may not reflect changes that
have occurred since the last sync of the file system. For a parallel file system, a sync does not occur until
all nodes have individually synchronized their data. On a system with no activity, the correct values will
be displayed after the sync daemon has run on all nodes
Here is the information for the mount options:

The GPFS-specific mount options are:
atime
Update inode access time for each access. This is the default. This option can also be controlled
with the -S option on the mmcrfs and mmchfs commands.

mtime
Always return accurate file modification times. This is the default. This option can also be
controlled with the -E option on the mmcrfs and mmchfs commands.

noatime
Do not update inode access times on this file system. This option can also be controlled with the
-S option on the mmcrfs and mmchfs commands.

nomtime
Update file modification times only periodically. This option can also be controlled with the -E
option on the mmcrfs and mmchfs commands.

I also found this in the gpfs_iattr_t Struct:

gpfs_iattr_t Structure
Contains attributes of a GPFS inode.
Library

snip
gpfs_timestruc_t ia_atime; /* time of last access */
gpfs_timestruc_t ia_mtime; /* time of last data modification */
gpfs_timestruc_t ia_ctime; /* time of last status change */
/snip

Again, does GPFS consider a directory move a "data modification"?
Here are the comparisons:
On a GPFS filesystem


[root@gs0 test]# mkdir dir [root@gs0 test]# touch file [root@gs0 test]# ls -l total 32 drwxr-xr-x 2 root root 32768 Sep  5 15:04 dir -rw-r--r-- 1 root root     0 Sep  5 15:04 file [root@gs0 test]# [root@gs0 test]# mkdir tmp [root@gs0 test]# mv dir/ tmp/  [root@gs0 test]# mv file tmp/  [root@gs0 test]# ls -l tmp/  total 32 drwxr-xr-x 2 root root 32768 Sep  5 15:05 dir          <--- note the change here -rw-r--r-- 1 root root     0 Sep  5 15:04 file [root@gs0 test]# ls -lu tmp/  total 32 drwxr-xr-x 2 root root 32768 Sep  5 15:04 dir -rw-r--r-- 1 root root     0 Sep  5 15:04 file [root@gs0 test]# ls -lc tmp/  total 32 drwxr-xr-x 2 root root 32768 Sep  5 15:05 dir -rw-r--r-- 1 root root     0 Sep  5 15:04 file

On an ext3 filesystem


[root@gs0 test]# mkdir dir [root@gs0 test]# touch file [root@gs0 test]# ls -l total 4 drwxr-xr-x 2 root root 4096 Sep  5 15:57 dir -rw-r--r-- 1 root root    0 Sep  5 15:57 file [root@gs0 test]# date Wed Sep  5 15:57:51 PDT 2012 [root@gs0 test]# [root@gs0 test]# mkdir tmp [root@gs0 test]# mv dir/ tmp/  [root@gs0 test]# mv file tmp/  [root@gs0 test]# ls -l tmp/  total 4 drwxr-xr-x 2 root root 4096 Sep  5 15:57 dir -rw-r--r-- 1 root root    0 Sep  5 15:57 file [root@gs0 test]# ls -lc tmp/  total 4 drwxr-xr-x 2 root root 4096 Sep  5 15:58 dir -rw-r--r-- 1 root root    0 Sep  5 15:58 file [root@gs0 test]# ls -lu tmp/  total 4 drwxr-xr-x 2 root root 4096 Sep  5 15:57 dir -rw-r--r-- 1 root root    0 Sep  5 15:57 file
Updated on 2012-09-10T14:47:02Z at 2012-09-10T14:47:02Z by SystemAdmin
  • dlmcnabb
    dlmcnabb
    1012 Posts

    Re: mtime change on directory move

    ‏2012-09-07T13:47:36Z  
    When you move a directory, the ".." parent entry changes, therefore the mtime changes.
  • mduff
    mduff
    35 Posts

    Re: mtime change on directory move

    ‏2012-09-07T15:06:11Z  
    • dlmcnabb
    • ‏2012-09-07T13:47:36Z
    When you move a directory, the ".." parent entry changes, therefore the mtime changes.
    Thank you for that.

    Why don't we see the same behavior for the ext3 filesystem?
  • dlmcnabb
    dlmcnabb
    1012 Posts

    Re: mtime change on directory move

    ‏2012-09-07T15:38:16Z  
    • mduff
    • ‏2012-09-07T15:06:11Z
    Thank you for that.

    Why don't we see the same behavior for the ext3 filesystem?
    I don't know the ext3 design. The Open/X document does not say anything about changing or not changing the directory mtime, so it may be ambiguous.

    A quick search on Google finds that in 2008 XFS had the same "feature" (with the following comment), but they later changed it so mtime does not change.
    
    /* * 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. */
    
  • SystemAdmin
    SystemAdmin
    2092 Posts

    Re: mtime change on directory move

    ‏2012-09-07T18:29:14Z  
    • mduff
    • ‏2012-09-07T15:06:11Z
    Thank you for that.

    Why don't we see the same behavior for the ext3 filesystem?
    Like the mduff, I present an example below of moving /tmp/r to /tmp/q/r.
    Notice the the data in the .. entry of r certainly does change. But ext filesystem does not
    update the modify-time for r.

    So one might argue that ext2/3/4 has got it wrong and GPFS has got it right! ;-)

    
    [root@fin44 tmp]# mkdir q [root@fin44 tmp]# mkdir r [root@fin44 tmp]# ls -ial --full-time r total 72 1512737 drwxr-xr-x   2 root root  4096 2012-09-07 11:24:43.854666552 -0700 . 1438977 drwxrwxrwt. 60 root root 65536 2012-09-07 11:24:43.854666552 -0700 .. [root@fin44 tmp]# stat r File: `r
    ' Size: 4096            Blocks: 8          IO Block: 4096   directory Device: 802h/2050d      Inode: 1512737     Links: 2 Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root) Access: 2012-09-07 11:25:06.174666676 -0700 Modify: 2012-09-07 11:24:43.854666552 -0700 Change: 2012-09-07 11:24:43.854666552 -0700 [root@fin44 tmp]# mv r q [root@fin44 tmp]# ls -ial --full-time q/r total 8 1512737 drwxr-xr-x 2 root root 4096 2012-09-07 11:24:43.854666552 -0700 . 1512736 drwxr-xr-x 3 root root 4096 2012-09-07 11:25:22.885666650 -0700 .. [root@fin44 tmp]# stat q/r File: `q/r
    ' Size: 4096            Blocks: 8          IO Block: 4096   directory Device: 802h/2050d      Inode: 1512737     Links: 2 Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root) Access: 2012-09-07 11:25:35.965666653 -0700 Modify: 2012-09-07 11:24:43.854666552 -0700 Change: 2012-09-07 11:25:22.885666650 -0700 [root@fin44 tmp]# stat -f . File: 
    "." ID: ff4ec398ba4ef3ef Namelen: 255     Type: ext2/ext3 Block size: 4096       Fundamental block size: 4096 Blocks: Total: 7559412    Free: 805050     Available: 421050 Inodes: Total: 1921360    Free: 1662908 [root@fin44 tmp]#
    
  • mduff
    mduff
    35 Posts

    Re: mtime change on directory move

    ‏2012-09-07T19:31:01Z  
    Like the mduff, I present an example below of moving /tmp/r to /tmp/q/r.
    Notice the the data in the .. entry of r certainly does change. But ext filesystem does not
    update the modify-time for r.

    So one might argue that ext2/3/4 has got it wrong and GPFS has got it right! ;-)

    <pre class="jive-pre"> [root@fin44 tmp]# mkdir q [root@fin44 tmp]# mkdir r [root@fin44 tmp]# ls -ial --full-time r total 72 1512737 drwxr-xr-x 2 root root 4096 2012-09-07 11:24:43.854666552 -0700 . 1438977 drwxrwxrwt. 60 root root 65536 2012-09-07 11:24:43.854666552 -0700 .. [root@fin44 tmp]# stat r File: `r ' Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 802h/2050d Inode: 1512737 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2012-09-07 11:25:06.174666676 -0700 Modify: 2012-09-07 11:24:43.854666552 -0700 Change: 2012-09-07 11:24:43.854666552 -0700 [root@fin44 tmp]# mv r q [root@fin44 tmp]# ls -ial --full-time q/r total 8 1512737 drwxr-xr-x 2 root root 4096 2012-09-07 11:24:43.854666552 -0700 . 1512736 drwxr-xr-x 3 root root 4096 2012-09-07 11:25:22.885666650 -0700 .. [root@fin44 tmp]# stat q/r File: `q/r ' Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 802h/2050d Inode: 1512737 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2012-09-07 11:25:35.965666653 -0700 Modify: 2012-09-07 11:24:43.854666552 -0700 Change: 2012-09-07 11:25:22.885666650 -0700 [root@fin44 tmp]# stat -f . File: "." ID: ff4ec398ba4ef3ef Namelen: 255 Type: ext2/ext3 Block size: 4096 Fundamental block size: 4096 Blocks: Total: 7559412 Free: 805050 Available: 421050 Inodes: Total: 1921360 Free: 1662908 [root@fin44 tmp]# </pre>
    I see the same behavior on Apple's HFS as we do on ext3 (see below).

    I don't have access to an AIX box right now, what does JFS2 do?

    
    host1:6029 mduff$ mkdir test.on.mac host1:6029 mduff$ cd test.on.mac/  host1:test.on.mac mduff$ mkdir dir host1:test.on.mac mduff$ touch file host1:test.on.mac mduff$ ls -l total 0 drwxr-xr-x  2 mduff  Group Users  68 Sep  5 23:18 dir -rw-r--r--  1 mduff  Group Users   0 Sep  5 23:18 file host1:test.on.mac mduff$ host1:test.on.mac mduff$ mkdir tmp host1:test.on.mac mduff$ mv dir/ tmp/  host1:test.on.mac mduff$ mv file tmp/  host1:test.on.mac mduff$ ls -l tmp/  total 0 drwxr-xr-x  2 mduff  Group Users  68 Sep  5 23:18 dir -rw-r--r--  1 mduff  Group Users   0 Sep  5 23:18 file host1:test.on.mac mduff$ host1:test.on.mac mduff$ host1:test.on.mac mduff$ ls -l tmp/  total 0 drwxr-xr-x  2 mduff  Group Users  68 Sep  5 23:18 dir -rw-r--r--  1 mduff  Group Users   0 Sep  5 23:18 file host1:test.on.mac mduff$ host1:test.on.mac mduff$ ls -l tmp/  total 0 drwxr-xr-x  2 mduff  Group Users  68 Sep  5 23:18 dir -rw-r--r--  1 mduff  Group Users   0 Sep  5 23:18 file host1:test.on.mac mduff$ sync;sync;sync host1:test.on.mac mduff$ ls -l tmp/  total 0 drwxr-xr-x  2 mduff  Group Users  68 Sep  5 23:18 dir -rw-r--r--  1 mduff  Group Users   0 Sep  5 23:18 file
    
  • dlmcnabb
    dlmcnabb
    1012 Posts

    Re: mtime change on directory move

    ‏2012-09-07T20:25:29Z  
    • mduff
    • ‏2012-09-07T19:31:01Z
    I see the same behavior on Apple's HFS as we do on ext3 (see below).

    I don't have access to an AIX box right now, what does JFS2 do?

    <pre class="jive-pre"> host1:6029 mduff$ mkdir test.on.mac host1:6029 mduff$ cd test.on.mac/ host1:test.on.mac mduff$ mkdir dir host1:test.on.mac mduff$ touch file host1:test.on.mac mduff$ ls -l total 0 drwxr-xr-x 2 mduff Group Users 68 Sep 5 23:18 dir -rw-r--r-- 1 mduff Group Users 0 Sep 5 23:18 file host1:test.on.mac mduff$ host1:test.on.mac mduff$ mkdir tmp host1:test.on.mac mduff$ mv dir/ tmp/ host1:test.on.mac mduff$ mv file tmp/ host1:test.on.mac mduff$ ls -l tmp/ total 0 drwxr-xr-x 2 mduff Group Users 68 Sep 5 23:18 dir -rw-r--r-- 1 mduff Group Users 0 Sep 5 23:18 file host1:test.on.mac mduff$ host1:test.on.mac mduff$ host1:test.on.mac mduff$ ls -l tmp/ total 0 drwxr-xr-x 2 mduff Group Users 68 Sep 5 23:18 dir -rw-r--r-- 1 mduff Group Users 0 Sep 5 23:18 file host1:test.on.mac mduff$ host1:test.on.mac mduff$ ls -l tmp/ total 0 drwxr-xr-x 2 mduff Group Users 68 Sep 5 23:18 dir -rw-r--r-- 1 mduff Group Users 0 Sep 5 23:18 file host1:test.on.mac mduff$ sync;sync;sync host1:test.on.mac mduff$ ls -l tmp/ total 0 drwxr-xr-x 2 mduff Group Users 68 Sep 5 23:18 dir -rw-r--r-- 1 mduff Group Users 0 Sep 5 23:18 file </pre>
    I just checked JFS2 on AIX, and it only changes the ctime.
  • dlmcnabb
    dlmcnabb
    1012 Posts

    Re: mtime change on directory move

    ‏2012-09-07T22:52:34Z  
    • mduff
    • ‏2012-09-07T15:06:11Z
    Thank you for that.

    Why don't we see the same behavior for the ext3 filesystem?
    Why does it matter?
  • mduff
    mduff
    35 Posts

    Re: mtime change on directory move

    ‏2012-09-08T04:34:33Z  
    • dlmcnabb
    • ‏2012-09-07T22:52:34Z
    Why does it matter?
    I don't think that it does matter, but it was information we needed to know. It is interesting that GPFS seems to be the only one in four filesystem (GPFS, ext, HFS, and JFS2) to do it differently.
  • dlmcnabb
    dlmcnabb
    1012 Posts

    Re: mtime change on directory move

    ‏2012-09-08T05:10:54Z  
    • mduff
    • ‏2012-09-08T04:34:33Z
    I don't think that it does matter, but it was information we needed to know. It is interesting that GPFS seems to be the only one in four filesystem (GPFS, ext, HFS, and JFS2) to do it differently.
    So now the question is, would a change break something that somehow depended on this feature. It has been this way since 1998 when GPFS first shipped, and no one asked about the difference.
  • mduff
    mduff
    35 Posts

    Re: mtime change on directory move

    ‏2012-09-08T05:20:13Z  
    • dlmcnabb
    • ‏2012-09-08T05:10:54Z
    So now the question is, would a change break something that somehow depended on this feature. It has been this way since 1998 when GPFS first shipped, and no one asked about the difference.
    I usually stick with the adage "If it's not broken...". And I haven't heard any "complaints", just questions.
  • SystemAdmin
    SystemAdmin
    2092 Posts

    Re: mtime change on directory move

    ‏2012-09-10T14:47:02Z  
    • mduff
    • ‏2012-09-08T05:20:13Z
    I usually stick with the adage "If it's not broken...". And I haven't heard any "complaints", just questions.
    Like Dan, I googled mtime, directory and such and found the xfs patch from the year 2008.
    Apparently someone did complain the xfs was different then ext in this regard and for xfs it was an easy enough patch.

    One could argue that directories are a special case and that the "".."" entry is very special...

    Yes, in life one must make allowances for special cases, BUT IMO that should only be when there is a special, compelling need to be different,
    otherwise simpler and consistent is better. A simple explanation is that all the entries in a directory are its data, and that if any of that data changes, the mtime should be
    updated. Adding a special rule that if only .. is updated, then don't update mtime -- seems an unnecessary complication, to the simple rule: data changes => mtime changes.

    One of the complaints was from a user/admin who did a backup job with logic ...
    after I backup a directory, the I change its name so I know it is backed up...

    Notice that if you change the name of a GPFS directory BUT do not change its parent, then you get the expected behaviour with GPFS.

    
    [root@fin44 tdir]# mkdir x/q   [root@fin44 tdir]# stat x/q File: `x/q
    ' Size: 512             Blocks: 0          IO Block: 32768  directory Device: 26h/38d Inode: 56420353    Links: 2 Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root) Access: 2012-09-10 07:36:26.736520000 -0700 Modify: 2012-09-10 07:36:26.771669000 -0700 Change: 2012-09-10 07:36:26.736520000 -0700   [root@fin44 tdir]# mv x/q x/q2 [root@fin44 tdir]# stat x/q2 File: `x/q2
    ' Size: 512             Blocks: 0          IO Block: 32768  directory Device: 26h/38d Inode: 56420353    Links: 2 Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root) Access: 2012-09-10 07:36:26.736520000 -0700 Modify: 2012-09-10 07:36:26.771669000 -0700 Change: 2012-09-10 07:36:26.736520000 -0700   [root@fin44 tdir]# stat --file-system x File: 
    "x" ID: ef970000000a Namelen: 255     Type: UNKNOWN (0x47504653) Block size: 262144     Fundamental block size: 262144 Blocks: Total: 2784720    Free: 2555501    Available: 2555501 Inodes: Total: 75224064   Free: 18102254