File timestamps precision - ext3 with nanoseconds, ext4 with milliseconds

Question

It is said that ext3 supports file timestamp precision up to seconds and ext4 up to nanoseconds...

What happens is that my old VPS running Ubuntu 12.04 with a ext3 filesystem always (as far as I can remember) supported nanoseconds very nicely, like this:

  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 excerpt:

/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

---

Now, I bought a new VPS, updated it to Ubuntu 20.04 (pre-beta), it has a filesystem mounted as 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 excerpt:

/dev/xvda3 on / type ext4 (rw,noatime,nobarrier,errors=remount-ro,stripe=32564)

But strangely stat -f says it is 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

---

Finally, my questions are:

1. Why my old ext3 system supports nanoseconds precision?

2. Why the new ext4 is limited to milliseconds? Is it actually formated as ext3, instead?

3. How can I figure out what is wrong and enable nanoseconds in the new one?

Answer 1

What you're seeing is a result of several implementation details, so brace yourself, and let's start with some background.

stat

First, the way stat -f works is to call something like statfs(), and determine the filesystem type using f_type, which is one of the FS Magic numbers.

If you do look at magic.h or in the statfs(2) man page, you'll see:

EXT2_SUPER_MAGIC 0xEF53
EXT3_SUPER_MAGIC 0xEF53
EXT4_SUPER_MAGIC 0xEF53

They all have the same magic, so stat can't really tell them apart, so it generically says "Type: ext2/ext3" for all ext filesystems.

mount

Next, there's the output of mount.

mount works by going to /proc/self/mountinfo, and the information there, provided by the kernel, does not contain the actual filesystem type. Rather, it contains the filesystem type that the mount command used in order to mount the filesystem. ext4 registers 3 such types, ext2, ext3, and ext4.

Namely, the ext4 driver can handle all 3 filesystems, and if the kernel is configured to only use the ext4 driver, that's the driver which will be used.

Actual on-disk filesystem

So how do you know what filesystems type you actually have on the disk?

You don't. ext's architecture doesn't work based on versions, but rather based on features.

You can query your filesystem's features as follows:

# 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

and you can modify the filesystem's features using tune2fs(8). All these programs are part of the e2fsprogs package.

The initial values for these features are set at the time of mkfs(8).

Implementation of nanoseconds

The reason ext3 couldn't implement nanosecond-precision timestamps is that the inode - the filesystem's data structure which represents a file's metadata, was originally only 128 bytes. There just wasn't enough room for the extra precision.

As time went by the default went to 256, not for the sake of nanoseconds, but rather for the sake of extended attributes.

ext4, on the other hand, started with a larger inode which had room for nanosecond-precision timestamps.

How it all comes together

Now we're ready to answer the questions.

1. Why my old ext3 system supports nanoseconds precision?

Ubuntu 12.04's mkfs set the filesystem's inode to be 256 bytes.

It then mounted it using ext3, but ext3 filesystem type was configured to be handled by the ext4 driver.

But after mount, ext4 didn't care - any timestamp modification saw that it has 256 bytes to work with, and wrote the nanoseconds.

2. Why the new ext4 is limited to milliseconds? Is it actually formated as ext3, instead?

Neither ext3 nor ext4 work with milliseconds.

It might be that your clock doesn't have nanosecond resolution, which you can check by running

date +%s.%N

3. How can I figure out what is wrong and enable nanoseconds in the new one?

Assuming that your clock has nanosecond resolution, you can use the above tools, dumpe2fs and tune2fs, to fix up the filesystem.

In addition, e2fsprogs' mkfs actually looks at /etc/mke2fs.conf, so you might also want to check the settings there for the next time you need to create a filesystem.