据说ext3支持文件时间戳精度高达几秒，而ext4支持纳秒...
发生的事情是，我的旧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吗？
我如何找出错误所在并在新的秒中启用纳秒级？
答案 0 :(得分：1)
您看到的是一些实现细节的结果，因此请做好准备，让我们从一些背景入手。
stat 首先，stat -f的工作方式是调用类似statfs()的东西，并使用FS Magic numbers之一的f_type确定文件系统类型。
如果您确实查看magic.h或statfs(2) man page中的内容，则会看到：
EXT2_SUPER_MAGIC 0xEF53
EXT3_SUPER_MAGIC 0xEF53
EXT4_SUPER_MAGIC 0xEF53
它们都具有相同的魔力，因此stat并不能真正区分它们，因此对于所有ext文件系统，它通常表示为“ Type：ext2 / ext3”。
mount 接下来，有mount的输出。
mount的工作方式是转到/proc/self/mountinfo，并且内核提供的信息不包含实际的文件系统类型。相反，它包含mount命令用来装载文件系统的filesystem type。 ext4 registers 3 such types，ext2，ext3和ext4。
即ext4驱动程序可以处理所有3个文件系统，如果内核配置为仅使用ext4驱动程序，那么将使用该驱动程序。
那么您如何知道磁盘上实际具有的文件系统类型？
你不知道。 ext的体系结构不是基于版本，而是基于features。
您可以按以下方式查询文件系统的功能：
# 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-表示文件元数据was originally only 128 bytes的文件系统的数据结构。只是没有足够的空间来提供额外的精度。
默认情况下，时间是256，不是为了纳秒，而是为了扩展属性。
另一方面，ext4从较大的inode开始，它具有纳秒级精确时间戳的空间。
现在我们准备回答问题。
- 为什么我的旧ext3系统支持纳秒精度？
Ubuntu 12.04的mkfs将文件系统的inode设置为256个字节。
然后使用ext3挂载它，但是ext3文件系统类型配置为由ext4驱动程序处理。
但是在挂载之后，ext4不在乎-任何时间戳修改都可以看到它有256个字节，并写入了纳秒级。
- 为什么新的ext4限制为毫秒？它实际上是格式化为ext3吗？
ext3和ext4都不以毫秒为单位。
可能是您的时钟没有纳秒分辨率，可以通过运行来检查
date +%s.%N
- 我该如何找出错误所在并在新的秒中启用纳秒级？
假设您的时钟具有纳秒级分辨率，则可以使用上述工具dumpe2fs和tune2fs来修复文件系统。
此外，e2fsprogs' mkfs实际上是在/etc/mke2fs.conf处查看的，因此您可能还想在下次需要创建文件系统时检查那里的设置。