linux - EXT4 上的触摸时间戳准确性

标签 linux ubuntu touch ext4

更新:事实证明我当时非常愚蠢。当我应该检查访问时间时,我正在检查修改时间。它不可重现的原因是测试文件是用 dd if=/dev/urandom of="$target"bs='1K' count=1 || 创建的exit 1,大部分时间太快,新文件的修改时间(dd 结束)与访问时间(dd 开始时间)不同)。另一件需要注意的事情。

我正在编写一个脚本,将一个文件的访问时间加两年应用于另一个文件。这使用 stat -c %xdate --rfc-3339=nstouch -a --date="$result"statdate 都以纳秒为单位输出日期字符串,例如

2012-11-17 10:22:15.390351800+01:00

info coreutils 'touch invocation' 表示它支持纳秒。但有时在应用触摸时,应用的时间戳与 stat 之后返回的时间戳之间存在细微差别。这是实际运行的数据:

$ for i in {1..100}; do ./t_timecopy.sh 2>/dev/null| grep ASSERT; done
ASSERT:Expecting same access time expected:<2012-11-17 10:58:40.719320935+01:00> but was:<2012-11-17 10:58:40.723322203+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:00:04.342346275+01:00> but was:<2012-11-17 11:00:04.346358718+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:00:39.343348183+01:00> but was:<2012-11-17 11:00:39.347351686+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:01:08.655348312+01:00> but was:<2012-11-17 11:01:08.659347625+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:01:37.930346876+01:00> but was:<2012-11-17 11:01:37.934347311+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:02:16.939319832+01:00> but was:<2012-11-17 11:02:16.943323061+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:02:46.456443149+01:00> but was:<2012-11-17 11:02:46.458379114+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:03:15.487339595+01:00> but was:<2012-11-17 11:03:15.491341426+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:04:04.646335863+01:00> but was:<2012-11-17 11:04:04.650346634+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:04:14.410326608+01:00> but was:<2012-11-17 11:04:14.414331233+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:04:24.159367348+01:00> but was:<2012-11-17 11:04:24.163352418+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:04:33.931387953+01:00> but was:<2012-11-17 11:04:33.935350115+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:05:03.394361030+01:00> but was:<2012-11-17 11:05:03.398320957+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:05:42.054317430+01:00> but was:<2012-11-17 11:05:42.059106497+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:06:40.346320820+01:00> but was:<2012-11-17 11:06:40.350346956+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:08:17.194346778+01:00> but was:<2012-11-17 11:08:17.198338832+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:08:27.102347603+01:00> but was:<2012-11-17 11:08:27.106320380+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:09:16.247322948+01:00> but was:<2012-11-17 11:09:16.251347966+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:09:55.191325266+01:00> but was:<2012-11-17 11:09:55.195320672+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:12:09.915318301+01:00> but was:<2012-11-17 11:12:09.919334099+01:00>
ASSERT:Expecting same access time expected:<2012-11-17 11:12:28.906346914+01:00> but was:<2012-11-17 11:12:28.910348186+01:00>

所以 100 次测试中有 21 次失败,平均值为 3.938 毫秒,中位数为 4.001 毫秒。有什么想法会导致这种情况吗?

$ uname -a
Linux user 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC 2010 i686 GNU/Linux

最佳答案

我使用了一堆(公认的快速和肮脏的)oneliner 在我的系统上测试你的问题 - Mandriva Linux 2010.1 (x86-64):

seq 1 1000 | while read f; do sleep 0.01; touch test-$f-0; done

seq 1 1000 | while read f; do touch -a -d "$(stat -c %x test-$f-0 | sed 's|^2010|2012|')" test-$f-1; done

seq 1 1000 | while read f; do A="$(stat -c %x test-$f-0)"; B="$(stat -c %x test-$f-1)"; if [[ ! "${A#2010}" = "${B#2012}" ]]; then echo test-$f; fi; done

我一次都无法重现您的问题。听起来触摸没有在 -d 参数中提供预期的时间戳,而是以其他方式计算的。

当然,问题可能是系统特定的,在这种情况下,我们需要有关您系统的更多信息(CPU、操作系统是 32 位还是 64 位、内核/glibc/coreutils 版本等)。

更新:

我对 32 位版本的 stat 和 touch 进​​行了同样的尝试。没有出现任何问题。内核仍然是 64 位内核。

更新 2:

我也试过这套 oneliners,它更注重时间:

$ seq 1 1000 | while read f; do sleep 0.01; touch test-$f-0; done
$ seq 1 1000 | while read f; do sleep 0.01; touch test-$f-1; done
$ seq 1 1000 | while read f; do sleep 0.01; cat test-$f-0; done
$ seq 1 1000 | while read f; do touch -a -d "$(stat -c %x test-$f-0 | sed 's|^2010|2012|')" test-$f-1; done
$ seq 1 1000 | while read f; do A="$(stat -c %x test-$f-0)"; B="$(stat -c %x test-$f-1)"; if [[ ! "${A#2010}" = "${B#2012}" ]]; then echo test-$f; fi; done

再次未检测到任何问题。我尝试了 relatime 和 strictatime 挂载选项。

更新 3:

我刚刚在我的 Mandriva i686 笔记本电脑上执行了上述测试。我似乎也没有发现纳秒精度的问题。我还在另一个 32 位系统上验证了如果不支持纳秒精度(例如在 ext3 上),则统计输出中的纳秒字段变为零。

关于linux - EXT4 上的触摸时间戳准确性,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4204443/

相关文章:

linux - Wiki.js 无法通过企业代理

linux - 对符号 'socket@@GLIBC_2.4' 的 undefined reference

ubuntu - 无法登录 Lubuntu 13.10

linux - ubuntu中无法通过curl命令访问localhost?

iphone - 改进触摸事件 UIImageView

ruby - 无法理解 linux 中 ruby​​ 项目的文件夹结构

php - 无法在我的工作开发机器上远程访问 MySQL

iOS 13.0 触摸开始延迟较 iOS 12 有所增加

ios - 将 UILabel 粘贴到 UIView 或 UIImageView

linux - 在 CentOS 中使用 Nginx 作为 Apache 上 wordpress 的反向代理