Início / unix / Perguntas / 749605
Accepted
Tavian Barnes
Asked: 2023-06-23 04:56:30 +0800 CST

Montagem NFS misturando ctime e mtime

  • 772

Eu tenho uma montagem NFS servida de um servidor Linux para um cliente FreeBSD. Se eu usar touchpara definir o atime e o mtime de um arquivo no cliente FreeBSD,

tavianator@muon $ touch -at "199112140000" ./foo
tavianator@muon $ touch -mt "199112150000" ./foo

em seguida, imprima os tempos estatísticos,

tavianator@muon $ stat -f $'Access: %Sa\nModify: %Sm\nChange: %Sc\n Birth: %SB' ./foo
Access: Dec 14 00:00:00 1991
Modify: Jun 22 16:44:08 2023
Change: Dec 15 00:00:00 1991
 Birth: Jun 22 16:45:56 2023

o ctime e o mtime estão trocados! No entanto, a visualização do servidor Linux está correta:

tavianator@tachyon $ stat /srv/nfs/freebsd/usr/home/tavianator/foo
  File: /srv/nfs/freebsd/usr/home/tavianator/foo
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 0,33    Inode: 54691999    Links: 1
Access: (0640/-rw-r-----)  Uid: ( 1000/tavianator)   Gid: ( 1000/tavianator)
Access: 1991-12-14 00:00:00.000000000 -0500
Modify: 1991-12-15 00:00:00.000000000 -0500
Change: 2023-06-22 16:45:56.731038486 -0400
 Birth: 2023-06-22 16:44:08.075496568 -0400

Alguma ideia do que poderia causar isso, ou como corrigi-lo? Mais algumas informações que podem ser úteis:

root@tachyon ~ # uname -a
Linux tachyon 6.3.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 14 Jun 2023 20:10:31 +0000 x86_64 GNU/Linux
root@tachyon ~ # findmnt -T /srv/nfs/freebsd/usr/home/tavianator 
TARGET
  SOURCE                      FSTYPE OPTIONS
/ /dev/mapper/cryptslash1[/@] btrfs  rw,relatime,ssd,discard=async,space_cache=v2,subvolid=261,subvol=/@
root@tachyon ~ # exportfs -v
/srv/nfs        100.101.179.2/32(sync,wdelay,hide,no_subtree_check,fsid=0,sec=sys,rw,secure,no_root_squash,no_all_squash)
/srv/nfs        100.114.24.115/32(sync,wdelay,hide,no_subtree_check,fsid=0,sec=sys,rw,secure,no_root_squash,no_all_squash)
/srv/nfs/freebsd
                100.101.179.2/32(sync,wdelay,nohide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/srv/nfs/freebsd
                100.114.24.115/32(sync,wdelay,nohide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)

tavianator@muon $ uname -a
FreeBSD muon 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC amd64
tavianator@muon $ mount | grep nfs,
100.107.249.85:/freebsd/usr/home/tavianator on /usr/home/tavianator (nfs, nfsv4acls)
linux

1 respostas

  1. Best Answer

    Olhando para uma captura de pacote no Wireshark, parece que este é um bug no servidor Linux, não no cliente FreeBSD.

    Acredito que seja um bug no kernel Linux commit e377a3e698fb , incluído pela primeira vez na versão 5.18. Esse commit adiciona suporte para relatar TIME_CREATEa hora do nascimento. Após esse commit, o código que grava os carimbos de data/hora do arquivo fica assim:

        if (bmval1 & FATTR4_WORD1_TIME_ACCESS) {
        p = xdr_reserve_space(xdr, 12);
        if (!p)
            goto out_resource;
        p = xdr_encode_hyper(p, (s64)stat.atime.tv_sec);
        *p++ = cpu_to_be32(stat.atime.tv_nsec);
    }
    if (bmval1 & FATTR4_WORD1_TIME_DELTA) {
        ...
    }
    if (bmval1 & FATTR4_WORD1_TIME_METADATA) {
        ...
    }
    if (bmval1 & FATTR4_WORD1_TIME_MODIFY) {
        ...
    }
    if (bmval1 & FATTR4_WORD1_TIME_CREATE) {
        ...
    }

    Acredito que a maneira como o protocolo funciona é que os tempos são escritos em uma ordem que deve corresponder ao bmval1bitmask. Nesse caso, a ordem seria [ACCESS, METADATA, MODIFY, CREATE]. No entanto, vamos ver os valores reais do sinalizador de bit :

    #define FATTR4_WORD1_TIME_ACCESS        (1UL << 15)
#define FATTR4_WORD1_TIME_ACCESS_SET    (1UL << 16)
#define FATTR4_WORD1_TIME_BACKUP        (1UL << 17)
#define FATTR4_WORD1_TIME_CREATE        (1UL << 18)
#define FATTR4_WORD1_TIME_DELTA         (1UL << 19)
#define FATTR4_WORD1_TIME_METADATA      (1UL << 20)
#define FATTR4_WORD1_TIME_MODIFY        (1UL << 21)
#define FATTR4_WORD1_TIME_MODIFY_SET    (1UL << 22)

    Portanto, a ordem em que devem ser escritos é [ACCESS, CREATE, METADATA, MODIFY]. Isso bate com o que estou vendo:

    Linux FreeBSDGenericName
    ACESSO 14/12/1991 00:00:00.000000000 14 de dezembro 00:00:00 1991
    CRIAR 2023-06-23 15:19:21.718006131 23 de junho 15:19:24 2023
    METADADOS 2023-06-23 15:19:24.718067075 15 de dezembro 00:00:00 1991
    MODIFICAR 15/12/1991 00:00:00.000000000 23 de junho 15:19:21 2023
    • 1

relate perguntas