Precisão de carimbos de data/hora do arquivo - ext3 com nanossegundos, ext4 com milissegundos

Precisão de carimbos de data/hora do arquivo - ext3 com nanossegundos, ext4 com milissegundos

As pessoas dizem que ext3 suporta precisão de carimbo de data/hora de arquivo de até segundos e ext4 de até nanossegundos.

O que acontece é que meu antigo VPS rodando Ubuntu 12.04 com um sistema de arquivos ext3 sempre (até onde me lembro) suportou muito bem nanossegundos, assim:

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

mountexcerto:

/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

Agora comprei um novo VPS, atualizei para Ubuntu 20.04 (pré-beta), ele tem um sistema de arquivos montado como 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: -

mountexcerto:

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

Mas estranhamente stat -fdiz que é 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

Minhas perguntas são:

  1. Por que meu antigo sistema ext3 suporta precisão de nanossegundos?

  2. Por que o novo ext4 está limitado a milissegundos? Em vez disso, ele está formatado como ext3?

  3. Como posso descobrir o que está errado e ativar nanossegundos no novo?

Responder1

O suporte real para resolução de nanossegundos versus segundos depende do tamanho do inode escolhido no momento da formatação. Inodes de 128 bytes suportam apenas segunda resolução, inodes de 256 bytes suportam resolução de nanossegundos. O driver do sistema de arquivos ext3 no kernel está executando o módulo ext4 por muitos anos, portanto, suporta carimbos de data e hora de nanossegundos.

Quanto aos carimbos de data/hora com resolução de milissegundos, isso provavelmente é resultado do fato de a virtualização fornecer apenas um relógio de resolução ms para o sistema de arquivos.

informação relacionada