Início / unix / Perguntas / 759880
Accepted
Alberto Pianon
Asked: 2023-10-26 17:06:44 +0800 CST

Por que o tempo do sistema de arquivos está sempre alguns ms atrás do tempo do sistema no Linux?

  • 772

No Linux, parece que o tempo do sistema de arquivos está sempre alguns milissegundos atrás do tempo do sistema, levando a inconsistências se você quiser verificar se um arquivo foi modificado antes ou depois de um determinado tempo em intervalos de tempo muito estreitos (milissegundos).

Em qualquer sistema Linux com um sistema de arquivos que suporte resolução de nanossegundos (tentei com ext4 com inodes de 256 bytes e ZFS), se você tentar fazer algo como:

date +%H:%M:%S.%N; echo "hello" > test1; stat -c %y test1 | cut -d" " -f 2

o segundo valor de saída (hora de modificação do arquivo) está sempre alguns milissegundos atrás do primeiro (hora do sistema), por exemplo:

17:26:42.400823099
17:26:42.395348462

enquanto deveria ser o contrário, já que o arquivo test1é modificado após chamar o datecomando.

Você pode obter o mesmo resultado em python:

import os, time

def test():
    print(time.time())
    with open("test1", "w") as f:
        f.write("hello")
        print(os.stat("test1").st_mtime)

test()

1698255477.3125281
1698255477.3070245

Por que é tão? E existe uma maneira de evitá-lo, para que a hora do sistema seja consistente com a hora do sistema de arquivos? A única solução alternativa que encontrei até agora é obter o "tempo" do sistema de arquivos (seja lá o que isso signifique na prática) criando um arquivo temporário fictício e obtendo seu horário de modificação, assim:

def get_filesystem_time():
    """
    get the current filesystem time by creating a temporary file and getting
    its modification time.
    """
    with tempfile.NamedTemporaryFile() as f:
        return os.stat(f.name).st_mtime

mas me pergunto se existe uma solução mais limpa.

linux

2 respostas

  1. Best Answer

    A hora usada para carimbos de data e hora do arquivo é a hora do último tique do temporizador, que está sempre um pouco no passado. A current_timefunção nasinode.c chamadas ktime_get_coarse_real_ts64:

    /**
 * current_time - Return FS time
 * @inode: inode.
 *
 * Return the current time truncated to the time granularity supported by
 * the fs.
 *
 * Note that inode and inode->sb cannot be NULL.
 * Otherwise, the function warns and returns time without truncation.
 */
struct timespec64 current_time(struct inode *inode)
{
    struct timespec64 now;

    ktime_get_coarse_real_ts64(&now);

    if (unlikely(!inode->i_sb)) {
        WARN(1, "current_time() called with uninitialized super_block in the inode");
        return now;
    }

    return timestamp_truncate(now, inode);
}

    e o último está documentado da seguinte forma :

    O tempo retornado aqui corresponde ao último tick do temporizador, que pode ter sido de até 10ms no passado (para CONFIG_HZ=100), o mesmo que a leitura da variável 'jiffies'. Essas [funções] só são úteis quando chamadas de maneira rápida e ainda se espera melhor que a segunda precisão, mas não é possível usar 'jiffies' facilmente, por exemplo, para carimbos de data e hora de inode. Ignorar o acesso ao relógio do hardware economiza cerca de 100 ciclos de CPU na maioria das máquinas modernas com um contador de ciclo confiável, mas até vários microssegundos em hardware mais antigo com uma fonte de relógio externa.

    Observe a menção específica aos carimbos de data/hora do inode.

    Não conheço nenhuma maneira de evitar isso completamente, exceto modificar o kernel. Você pode reduzir o impacto aumentando CONFIG_HZ. Houve uma proposta recente para melhorar isso , que ainda está sendo trabalhada .

    • 21

  2. A resposta de Stephen Kitt parece acertada.

    Podemos reproduzir isso muito bem obtendo o mesmo clock "grosso" que o sistema de arquivos usa, pelo menos na configuração do meu kernel; um programa C que sempre obtém o relógio aproximado em tempo real antes de acessar o arquivo leva exatamente o carimbo de data e hora do arquivo ou (raramente) um carimbo de data e hora um tique do sistema anterior:

    // excerpt from the program linked above, not a relicensing
// …
    clock_gettime(CLOCK_REALTIME_COARSE, &now_coarse);
    clock_gettime(CLOCK_REALTIME, &now);
    int fd = open("temp", O_WRONLY | O_CREAT);
    write(fd, data, length);
    close(fd);
    clock_gettime(CLOCK_REALTIME, &now_after);

    stat("temp", &props);

    printf("Differences relative to coarse clock before:\n"
           "Fine Realtime before:   %+8jd ns\n"
           "File Modification Time: %+8jd ns\n"
           "Realtime clock after:   %+8jd ns\n",
           ns_difference(&now_coarse, &now),
           ns_difference(&now_coarse, &props.st_mtim),
           ns_difference(&now_coarse, &now_after));

    produz algo como

    Differences relative to coarse clock before:
Fine Realtime before:   +1551810 ns
File Modification Time:       +0 ns
Realtime clock after:   +1626199 ns

    com a ocorrência rara mencionada acima de um delta de duração de cerca de tick, que acontece quando o tick do sistema cai apenas entre a obtenção now_coarsee a modificação do arquivo:

    Differences relative to coarse clock before:
Fine Realtime before:   +1497562 ns
File Modification Time:  +999992 ns
Realtime clock after:   +1609943 ns

    A propósito, as estatísticas mostram que se fizermos o acima até coletarmos 10.000 ocorrências onde esse “salto de tique” aconteceu, o intervalo de possíveis atrasos é bem pequeno:

    Total processed:     777618
Observed tick progressions:      10000
Percentage:                 0.013
Minimum tick delta:     999992
Maximum tick delta:     999993
Average tick delta: 999992.905900

    Em outras palavras, temos um timing extremamente próximo no que diz respeito aos deltas entre os ticks.

    • 14

relate perguntas