据说 ext3 支持文件时间戳精度高达 秒，ext4 支持高达 nano秒...
发生的情况是，我的旧VPS运行Ubuntu 12.04和ext3文件系统总是(据我所知)很好地支持纳秒，如下所示：
File: `auth.log'
Size: 147744 Blocks: 304 IO Block: 4096 regular file
Device: 800h/2048d Inode: 32019 Links: 1
Access: (0640/-rw-r-----) Uid: ( 101/ syslog) Gid: ( 4/ adm)
Access: 2020-03-20 00:18:33.634687690 -0300
Modify: 2020-03-24 05:12:48.777610222 -0300
Change: 2020-03-24 05:12:48.777610222 -0300
Birth: -
mount摘录：
/dev/sda on / type ext3 (rw,noatime,errors=remount-ro)
stat -f：
File: "auth.log"
ID: 5483af2794a91010 Namelen: 255 Type: ext2/ext3
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 3870084 Free: 272230 Available: 75643
Inodes: Total: 923520 Free: 829980
root@mail:~# df -mT
Filesystem Type 1M-blocks Used Available Use% Mounted on
/dev/sda ext3 15118 14055 296 98% /
devtmpfs devtmpfs 1973 1 1973 1% /dev
none tmpfs 395 1 395 1% /run
none tmpfs 5 0 5 0% /run/lock
none tmpfs 1973 0 1973 0% /run/shm
现在，我买了一个新的VPS，将其更新到Ubuntu 20.04(预测试版)，它有一个挂载为ext4的文件系统......
File: auth.log
Size: 723967 Blocks: 1424 IO Block: 4096 regular file
Device: ca03h/51715d Inode: 398412 Links: 1
Access: (0640/-rw-r-----) Uid: ( 104/ syslog) Gid: ( 4/ adm)
Access: 2020-03-24 00:00:05.676000000 -0300
Modify: 2020-03-24 05:14:56.644000000 -0300
Change: 2020-03-24 05:14:56.644000000 -0300
Birth: -
mount摘录：
/dev/xvda3 on / type ext4 (rw,noatime,nobarrier,errors=remount-ro,stripe=32564)
但奇怪的是，stat -f说它是ext3：
File: "auth.log"
ID: 7e8a03105e52b018 Namelen: 255 Type: ext2/ext3
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 9857995 Free: 7434726 Available: 7007355
Inodes: Total: 2505120 Free: 2403794
root@mailnew:~# df -mT
Filesystem Type 1M-blocks Used Available Use% Mounted on
udev devtmpfs 430 0 430 0% /dev
tmpfs tmpfs 95 2 94 2% /run
/dev/xvda3 ext4 38508 9466 27373 26% /
tmpfs tmpfs 473 0 473 0% /dev/shm
tmpfs tmpfs 5 0 5 0% /run/lock
tmpfs tmpfs 473 0 473 0% /sys/fs/cgroup
/dev/loop0 squashfs 54 54 0 100% /snap/lxd/11348
/dev/loop1 squashfs 92 92 0 100% /snap/core/8689
/dev/xvda1 ext4 727 183 502 27% /boot
tmpfs tmpfs 95 0 95 0% /run/user/0
最后，我的问题是：
为什么我的旧 ext3 系统支持纳秒精度？
为什么新的 ext4 限制为毫秒？它实际上是否格式化为 ext3？
我怎样才能找出问题所在并在新的中启用纳秒？
您所看到的是几个实现细节的结果，因此请振作起来，让我们从一些背景开始。
stat
首先，stat -f的工作方式是调用类似statfs()的东西，并使用f_type来确定文件系统类型，这是 FS 幻数之一。
如果你看过 magic.h 或 statfs(2) 手册页，你会看到：
EXT2_SUPER_MAGIC 0xEF53
EXT3_SUPER_MAGIC 0xEF53
EXT4_SUPER_MAGIC 0xEF53
它们都具有相同的魔力，因此stat无法真正区分它们，因此对于所有ext文件系统，它通常都说"Type：ext2/ext3"。
mount
接下来是mount的输出。
mount通过转到/proc/self/mountinfo来工作，并且内核提供的信息不包含实际的文件系统类型。相反，它包含mount命令用于挂载文件系统的文件系统类型。ext4 注册了 3 种这样的类型，ext2、ext3 和 ext4。
也就是说，ext4 驱动程序可以处理所有 3 个文件系统，如果内核配置为仅使用 ext4 驱动程序，那就是将使用的驱动程序。
实际磁盘文件系统
那么，您如何知道磁盘上实际具有的文件系统类型呢？
ext的架构不是基于版本，而是基于功能。
您可以按如下方式查询文件系统的功能：
# dumpe2fs /dev/sda | grep -e 'Filesystem features:' -e 'Inode size:'
dumpe2fs 1.42.9 (28-Dec-2013)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super
Inode size: 256
您可以使用tune2fs(8)修改文件系统的功能。所有这些程序都是e2fsprogs软件包的一部分。
这些功能的初始值在mkfs(8)时设置。
纳秒的实现
ext3 无法实现纳秒精度时间戳的原因是 inode(表示文件元数据的文件系统数据结构)最初只有 128 个字节。只是没有足够的空间来提供额外的精度。
随着时间的流逝，默认变为 256，不是为了纳秒，而是为了扩展属性。
另一方面，ext4 从一个更大的 inode 开始，它有纳秒级精度时间戳的空间。
这一切是如何结合在一起的
现在我们准备回答这些问题。
- 为什么我的旧 ext3 系统支持纳秒精度？
Ubuntu 12.04 的 mkfs 将文件系统的索引节点设置为 256 字节。
然后它使用 ext3 挂载它，但 ext3 文件系统类型配置为由 ext4 驱动程序处理。
但是挂载后，ext4 并不在乎 - 任何时间戳修改都看到它有 256 个字节可以使用，并写入了纳秒。
- 为什么新的ext4限制为毫秒？它实际上是否格式化为 ext3？
ext3 和 ext4 都无法使用毫秒。
可能是您的时钟没有纳秒分辨率，您可以通过运行来检查
date +%s.%N
- 如何找出问题所在并在新的中启用纳秒？
假设您的时钟具有纳秒分辨率，您可以使用上述工具，dumpe2fs和tune2fs，来修复文件系统。
此外，e2fsprogs 的 mkfs 实际上查看/etc/mke2fs.conf，因此您可能还想在下次需要创建文件系统时检查那里的设置。