Qual é o tamanho de uma gravação atômica em disco no meu sistema?

10

Na documentação da access_logdiretiva , a documentação nginx diz

O tamanho do buffer não deve exceder o tamanho de uma gravação atômica em um arquivo de disco.

Como posso determinar qual é esse tamanho no meu sistema?

linux nginx

— Bdesham
fonte

@mdpc No documento vinculado, é bastante claro que não se trata de tamanhos de setor, o que é verdade. tem 512 bytes na maioria das mídias desde o final dos anos 80 até agora. Há uma mudança para tamanhos de setor 4K em novas unidades.

— Kasperd # 29/14

Esta especificação pode ser relevante. Embora não parece dar qualquer resposta exata para a pergunta: pubs.opengroup.org/onlinepubs/7908799/xsh/write.html

— kasperd

3

Antes tarde do que nunca :)

A resposta rápida é: "2.147.479.552 bytes, se a versão do kernel for 3.14 ou mais recente"

resposta detalhada:

Tanto quanto eu entendo, trata-se de escrever syscall:

http://man7.org/linux/man-pages/man2/write.2.html

1) todos os sistemas POSIX (linux, bsd, todos unix) têm a garantia de poder gravar MAX_SSIZE bytes

De acordo com o POSIX.1, se a contagem for maior que SSIZE_MAX, o resultado será definido pela implementação; veja NOTAS para o limite superior no Linux.

# getconf SSIZE_MAX
32767

2) linux garantido para poder gravar até 1,99 GiB (e é operação atômica para o kernel do linux versão 3.14 e mais recente)

No Linux, write () (e chamadas de sistema similares) transferem no máximo 0x7ffff000 (2.147.479.552) bytes, retornando o número de bytes realmente transferidos. (Isso é verdade nos sistemas de 32 e 64 bits.)

Mas é uma operação atômica justa apenas do kernel 3.14 do linux

De acordo com a Seção XSI 2.9.7 do POSIX.1-2008 / SUSv4 ("Interações de encadeamento com operações regulares de arquivos"):

Todas as funções a seguir devem ser atômicas entre si nos efeitos especificados no POSIX.1-2008 quando operarem em arquivos regulares ou links simbólicos: ...

Entre as APIs listadas posteriormente estão write () e writev (2). E entre os efeitos que devem ser atômicos entre threads (e processos) estão as atualizações do deslocamento do arquivo. No entanto, no Linux anterior à versão 3.14, esse não era o caso: se dois processos que compartilham uma descrição de arquivo aberto (consulte open (2)) executam uma gravação () (ou writev (2)) ao mesmo tempo, I As operações de / O não eram atômicas com relação à atualização do deslocamento do arquivo, com o resultado de que os blocos de dados gerados pelos dois processos podem (incorretamente) se sobrepor. Este problema foi corrigido no Linux 3.14.

— Oleg Korchagin
fonte

1

Essa resposta do superusuário tinha uma boa definição do tamanho da gravação atômica.

Isso é pelo menos tão grande quanto o tamanho do setor de hardware, que é o tamanho atômico de leitura / gravação.

— mlw4428
fonte

1

OK, então como determino o tamanho de um setor de disco?

— Bdesham # 29/14

9

A documentação do nginx e a resposta do superusuário não estão falando da mesma camada na pilha de armazenamento. A documentação do nginx fala sobre a maior gravação atômica na camada do sistema de arquivos, que depende do sistema operacional e do FS. A resposta do superusuário está falando sobre a maior gravação atômica no nível do bloco, que depende do hardware.

— Kasperd