Точность временных меток файлов - ext3 с наносекундами, ext4 с миллисекундами

Говорят, что 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

Наконец, мои вопросы:

  1. Почему моя старая система ext3 поддерживает точность до наносекунд?

  2. Почему новый ext4 ограничен миллисекундами? Вместо этого он действительно отформатирован как ext3?

  3. Как я могу понять, что не так, и включить наносекунды в новом?


timestamp filesystems ext3 ext4
person Ricardo    schedule 25.03.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

То, что вы видите, является результатом нескольких деталей реализации, так что приготовьтесь и давайте начнем с предыстории.

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 указывается "Тип: 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, в котором было место для меток времени с точностью до наносекунды.

Как все это сочетается

Теперь мы готовы ответить на вопросы.

  1. Почему моя старая система ext3 поддерживает точность до наносекунд?

mkfs Ubuntu 12.04 устанавливает индекс файловой системы равным 256 байтам.

Затем он смонтировал его с помощью ext3, но тип файловой системы ext3 был настроен для обработки драйвером ext4.

Но после монтирования ext4 было все равно - любая модификация временной метки видела, что у нее есть 256 байт для работы, и записывала наносекунды.

  1. Почему новый ext4 ограничен миллисекундами? Вместо этого он действительно отформатирован как ext3?

Ни ext3, ни ext4 не работают с миллисекундами.

Возможно, ваши часы не имеют наносекундного разрешения, что вы можете проверить, запустив

date +%s.%N
  1. Как я могу понять, что не так, и включить наносекунды в новом?

Предполагая, что ваши часы имеют разрешение в наносекундах, вы можете использовать вышеупомянутые инструменты, dumpe2fs и tune2fs, для исправления файловой системы.

Кроме того, mkfs e2fsprogs фактически просматривает /etc/mke2fs.conf, так что вы также можете проверить настройки там в следующий раз, когда вам понадобится создать файловую систему.

person root    schedule 25.03.2020
comment
Спасибо за хороший ответ :) Разрешение даты в порядке: # date +%s.%N 1585131622.550162572 Файловая система тоже кажется в порядке (я думаю, что «extra_isize» — это то, что может помочь точности штампов, верно?): Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Inode size: 256 Может ли это ограничение, эксклюзивное для файловых штампов, быть связано с виртуализацией хост использует? - person Ricardo; 25.03.2020