CentOS 7下atime如何变化的问题（转）

转自：https://blog.csdn.net/cjf_iceking/article/details/11988525

1. atime, ctime 以及mtime

这三个名词属于文件/文件夹的属性，存在于inode数据结构之中。

通过系统调用stat可以获取stat结构，其中包括：atime(accesstime), ctime(create time) 以及mtime(modify time)的信息，man stat后的信息：

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

atime: The field st_atime is changed by file accesses, e.g. byexecve, mknod, pipe, utime and read (of more than zero bytes).

ctime: The field st_ctime is changed by writing or by settinginode information (i.e., owner, group, link count, mode, etc.).

mtime: The field st_mtime is changed by file modifications, e.g.by mknod, truncate, utime and write (of more than zero bytes).  Moreover, st_mtime of a directory is changedby the creation or deletion of files in that directory. The st_mtime field isnot changed for changes in owner, group, hard link count, or mode.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

值得注意的是，严格意义上说，ctime并不是创建文件的时间。

同样我们也可以通过ls命令来获取文件的atime,ctime, mtime:

[plain]  view plain  copy

1. 获取atime:ls –lu [filename]  
2. 获取ctime:ls –lc [filename]  
3. 获取mtime:ls –l [filename]  

 

2. atime未发生变化的情况

在Centos6或者Redhat6的平台下，产品对文件扫描后，发现文件的atime并没有变化，接着自己也用命令”cat [filename]”之后，atime也没有发生变化。这些操作都会对文件进行读操作，但是为何atime没有发生变化了呢？

但是这些操作在Redhat5等平台上都能够正常的改变atime。那为何在Centos6/Redhat6上没有改变呢？

3. 根本原因

起初我也怀疑过是不是OS的bug导致的，后来发现，在kernel版本2.6.30之前，linux的核心开发人员针对Ext3/Ext4文件系统的性能进行了讨论，其中包括atime。在kernel 2.6.30之前，文件系统中默认会及时的更新atime，这样会带来两个问题：

(1)    系统中大量的文件访问，将atime写入到磁盘中，消耗时间，从而降低性能

(2)    这样的操作也会消耗电能

在Linux上运行的，很少的应用程序需要获取精确的atime时间，并且Linux核心开发人员从Ext3/Ext4文件系统的性能角度出发，决定在2.6.30版本的内核中修改atime的更新方式，只有在以下三种情况之一才会更新atime:

(1)    如果将分区mount的挂载的时候指定采用非relatime方式(默认采用relatime方式)，如strictatime.

补充：在OS启动的时候，将各个分区挂载到不同的目录，在挂载(mount)的参数中采用strictatime，表明及时更新atime。在2.6.30之后mount添加了”relatime”和”strictatime”两个选项，详细的可以通过”man mount”查看。

(2) atime小于ctime或者小于mtime的时候

(3) 本次的access time和上次的atime超过24个小时

这种做法避免了频繁的更新atime，提高了文件系统的性能。果然做Linux内核的大牛无不从每一个细节抓起呢，敬佩。

然后我查看了我使用的CentOS6和Redhat6的kernel版本是2.6.32的，而我用的Redhat5是2.6.30之前的内核版本，果不其然，然后下载了2.6.32.22的kernel代码，查看到了更新atime之前调用的一个检查函数relatime_need_update：

[cpp]  view plain  copy

1. /* 
2.  *With relative atime, only update atime if the previous atime is 
3.  *earlier than either the ctime or mtime or if at least a day has 
4.  *passed since the last atime update. 
5.  */  
6. static int relatime_need_update(structvfsmount *mnt, struct inode *inode,  
7.                                  struct timespec now)  
8. {  
9.    
10.          if(!(mnt->mnt_flags & MNT_RELATIME))  
11.                    return1;  
12.          /* 
13.           * Is mtime younger than atime? If yes, updateatime: 
14.           */  
15.          if(timespec_compare(&inode->i_mtime, &inode->i_atime) >= 0)  
16.                    return1;  
17.          /* 
18.           * Is ctime younger than atime? If yes, updateatime: 
19.           */  
20.          if(timespec_compare(&inode->i_ctime, &inode->i_atime) >= 0)  
21.                    return1;  
22.    
23.          /* 
24.           * Is the previous atime value older than aday? If yes, 
25.           * update atime: 
26.           */  
27.          if((long)(now.tv_sec - inode->i_atime.tv_sec) >= 24*60*60)  
28.                    return1;  
29.          /* 
30.           * Good, we can skip the atime update: 
31.           */  
32.          return0;  
33. }  

4. 获取精确的atime时间

但是在kernel 2.6.30之后，如果你的产品需要获取atime的精确时间呢？

OS启动的时候会读取/etc/fstab文件，对磁盘分区进行挂载我们可以添加strictatime选项：

[plain]  view plain  copy

1. UUID=d2a07167-d979-4cb8-a50e-dde36f4c7139/                       ext4    defaults,strictatime        1 1  

但是这种做法需要重启OS，如果不重启OS我们可以使用remount(以挂载在”/”的文件系统为例)：

[plain]  view plain  copy

1. mount -o remount,rw,strictatime /  

这样挂载在”/”目录的文件系统就能够及时的更新atime了。

5. 参考

1. http://stackoverflow.com/questions/15547649/is-it-necessary-to-enable-atime-in-etc-fstab-to-get-the-correct-last-accessed

2. http://www.h-online.com/open/news/item/Kernel-Log-What-s-coming-in-2-6-30-File-systems-New-and-revamped-file-systems-741319.html