qual é a relação entre tamanho de bloco e IO?

Question

Eu tenho lido recentemente sobre disco, o que me levou a 3 dúvidas diferentes. E eu não sou capaz de ligá-los juntos. Três termos diferentes com os quais estou confuso são block size , IO e Performance .

Eu estava lendo sobre superblocos em slashroot quando encontrei a declaração

Less IOPS will be performed if you have larger block size for your file system.

A partir disso, eu entendo que se eu quiser ler 1024 KB de dados, um disco (digamos A) com tamanho de bloco 4KB / 4096B levaria mais IO que um disco (Dizer B) com tamanho de bloco de 64KB.

Agora, minha pergunta é quanto mais IO precisaria do disco A?

Até onde eu entendo, o número de solicitações de E / S necessárias para ler esses dados também dependeria do tamanho de cada solicitação de E / S.

• So who is deciding what is the size of the IO request? Is it equal to the block size? Algumas pessoas dizem que seu aplicativo decide o tamanho da solicitação de E / S que parece bastante justa, mas como, então, o sistema operacional divide a única solicitação em vários pedidos de inserção. %código%
• There must be a limit after which the request splits in more then one IO. How to find that limit ?
• Is it possible that in both disk (A and B) the data can be read in same number of IO?
• Does reading each block means a single IO ? If not how many blocks can be maximum read in a single IO?

num of IOPS possible = 1 /(average rotational delay + avg seek time)

Throughput = IOPS * IO size

Acima, o IOPS de um disco seria sempre corrigido, mas o tamanho do IO pode ser variável. Então, para calcular a taxa de transferência máxima possível, precisaríamos do tamanho máximo de E / S. E, a partir disso, o que eu entendo é que, se eu quiser aumentar a taxa de transferência de um disco, eu faria solicitações com dados máximos para enviar uma solicitação. Esta suposição está correta?

Peço desculpas por muitas perguntas, mas tenho lido sobre isso há algum tempo e não consegui obter respostas satisfatórias. Eu encontrei diferentes visões sobre o mesmo.

    

Answer 1

Acho que o artigo da Wikipédia explica bem:

Absent simultaneous specifications of response-time and workload, IOPS are essentially meaningless.
...
Like benchmarks, IOPS numbers published by storage device manufacturers do not directly relate to real-world application performance. ...

Agora, as suas perguntas:

So who is deciding what is the size of the IO request?

Essa é uma pergunta fácil e difícil de responder por um não programador como eu.

Como de costume, a resposta é insatisfatória " depende " ...

As operações de E / S com relação ao armazenamento em disco por um aplicativo geralmente são chamadas do sistema para o sistema operacional e seu tamanho depende de qual chamada de sistema é feita ...

Estou mais familiarizado com o Linux do que com outros sistemas operacionais, então vou usar isso como referência.

O tamanho das operações de E / S, como open() , stat() , chmod() e similar é quase insignificante.
Em um disco giratório, o desempenho dessas chamadas depende principalmente de quanto o atuador de disco precisa mover o braço e ler a posição correta no disco.

Por outro lado, o tamanho de um read() e de write() chamadas são inicialmente definidas pelo aplicativo e podem variar entre 0 e 0x7ffff000 (2.147.479.552) bytes em uma única solicitação de E / S ...

É claro que, uma vez que uma chamada desse sistema tenha sido feita pelo aplicativo e recebida pelo sistema operacional, a chamada receberá programada e enfileirado (dependendo de se o flag O_DIRECT foi ou não usado para contornar o cache de páginas e os buffers e a E / S direta foi selecionada).

A chamada abstrata do sistema precisará ser mapeada para / de operações no sistema de arquivos subjacente que é ordenado em blocos (cujo tamanho geralmente é definido quando o sistema de arquivos foi criado) e, eventualmente, o driver de disco opera em disco rígido setores de disco de 512 ou 4096 bytes ou páginas de memória SSD de 2K, 4K, 8K ou 16K.

(Para benchmarks normalmente as chamadas de leitura e gravação são geralmente definidas como 512B ou 4KB, que se alinham muito bem com o disco subjacente, resultando em desempenho ideal.)

There must be a limit after which the request splits in more then one IO. How to find that limit ?

Sim, há um limite, no Linux, conforme documentado no manual, um único read() < A / a> ou write() chamada do sistema retornará um máximo de 0x7ffff000 ( 2.147.479.552) bytes. Para ler arquivos maiores, você precisará de mais chamadas do sistema.

Does reading each block means a single IO ?

Tanto quanto eu entendo, tipicamente cada ocorrência de uma chamada de sistema é o que conta como um evento IO.

Uma única chamada de sistema read() conta como um evento de I / 0 e X nem Y IO, independentemente de como essa chamada de sistema é traduzida / implementada para acessar blocos X de um sistema de arquivos ou lendo setores Y de um disco rígido giratório.

    

Answer 2

Parece que você está tentando decodificar essa afirmação:

"Menos IOPS será executado se você tiver um tamanho de bloco maior para o seu sistema de arquivos."

Deixe-me tentar reformular essa declaração para deixar o significado do autor original mais claro:

"Para ler um determinado arquivo com um tamanho específico (digamos, 10MB), um sistema de arquivos formatado com um tamanho de bloco maior provavelmente precisará executar um número menor de operações de leitura do que um sistema de arquivos formatado com um tamanho de bloco menor. "

Espero que minha reformulação faça um pouco mais de sentido do que o original.

Para analisar apropriadamente essa declaração e entender o motivo de a) usar o termo "sistema de arquivos" em vez de disco eb) essa "provavelmente" incômoda, você precisará aprender muito mais sobre todas as camadas de software entre os dados em um disco (ou SSD) e os aplicativos da área de usuário. Posso dar algumas dicas para começar a pesquisar:

Para discos giratórios:

• tamanho do setor (disco) em relação ao tamanho do bloco (sistema de arquivos)

Aprenda sobre o armazenamento em cache:

• Página / cache de buffer no kernel do sistema operacional

• Armazenamento em cache de E / S em bibliotecas de nível de usuário (as mais importantes são libc e libc ++)

Para armazenamento SSD ou outro armazenamento baseado em flash, existem algumas complicações adicionais. Você deve pesquisar como o armazenamento em flash funciona em unidades do Pages e por que qualquer armazenamento baseado em flash requer um processo de coleta de lixo.