... reports different sector size (aren't the terms sector and block interchangeable?)
"Bloco" foi usado para significar muitas coisas diferentes. Você tem que olhar para o contexto específico.
df aumenta ainda mais, dizendo "blocos 1K" para significar unidades de 1 Kilobyte, mesmo quando o (s) sistema (s) de arquivos usam tamanhos de bloco diferentes.
"Setor" significa originalmente o tamanho de bloco que um disco usa. Mas observe que fdisk relata dois tipos diferentes de tamanho de setor, "físico" e "lógico" :-). Então você precisa olhar para o contexto aqui também. [*]
Qual é o tamanho do bloco do sistema de arquivos?
Como as primeiras ferramentas mencionadas foram df e dumpe2fs , imaginei que você esteja procurando o tamanho do bloco do sistema de arquivos. Nesse caso, você quer o valor que dumpe2fs mostra como "Tamanho do bloco".
dumpe2fs é uma ferramenta específica para ext2 / 3/4, mas acredito que isso seja a abordagem mais robusta. Dito isto, isso significa que se você usar um sistema de arquivos diferente, você terá que usar uma ferramenta diferente e confirmar exatamente o que ele usa para "tamanho de bloco".
Pode haver algumas exceções ao tamanho normal do bloco do sistema de arquivos. Um ext4 muito recente pode suportar o armazenamento de dados em linha no inode. Ou seja, arquivos menores que um determinado tamanho podem ser armazenados no inode do arquivo, sem alocar nenhum bloco de dados. Veja Como usar o novo recurso Ext4 Inline Data? (armazenando dados diretamente no inode)
Método de consulta alternativa: statvfs ()
Como alternativa, você pode executar stat -f / para mostrar as informações de statvfs() para seu sistema de arquivos raiz. Foi discutido aqui: tamanhos do sistema de arquivos estatísticos .
stat -f output inclui dois campos diferentes, "Tamanho fundamental do bloco" e "Tamanho do bloco": -).
O tamanho do bloco "fundamental" é a granularidade em que o uso do espaço é relatado - isso se aplicará a df . Você pode esperar que essa seja a mesma granularidade usada para alocar espaço no arquivo. Pelo menos isso é verdade para o seu ext2 / 3/4 e em muitos outros casos.
stat afirma que o outro tamanho de bloco deve ser usado "para transferências rápidas". No ext2 / 3/4, esses dois tamanhos de bloco serão sempre os mesmos.
Se o ext2 já tivesse implementado fragmentos, como o UFS do BSD UNIX, seria possível que os dois tamanhos fossem diferentes. Isso é refletido em dumpe2fs sempre mostrando um valor "Tamanho do fragmento" igual a "Tamanho do bloco". Consulte O que pode f_bsize ser usado para? (É semelhante a st_blksize?)
Como uma ferramenta mais genérica, stat -f pode induzir em erro em alguns casos.
Também não é muito usado; isso pode aumentar o risco. Não ajuda informar dois valores diferentes, nos quais os significados originais não são relevantes para os sistemas de arquivos nativos do Linux. FWIW, os usuários deste site odiavam minha pergunta pedindo para confirmar seu comportamento (o link acima). Eu costumo supor que isso significa que eles ficaram com raiva porque ninguém sabe como responder à pergunta.
stat -f é um recurso do GNU coreutils. (Não é suportado por stat do FreeBSD 7.2).
O "tamanho do bloco" para transferências rápidas "é significativo?
Esta descrição pode ser relevante para sistemas de arquivos que implementam fragmentos. Se eles não implementarem a "alocação atrasada", talvez seja mais eficiente garantir que você use um buffer de gravação do tamanho de um bloco quando aumentar o tamanho de um arquivo. Como sempre, se você está pensando em fazer uma mudança para melhorar o desempenho, você deve confirmar a melhoria com as medidas.
Nos sistemas de arquivos Linux, os dois tamanhos de bloco serão o mesmo valor. Nesse caso, não conheço nenhum motivo para usar esse valor específico para otimização.
Na maioria das vezes, o espaço do usuário não precisa se preocupar muito com o dimensionamento de chamadas de E / S "para transferências rápidas". O agendador de IO pode coalescer I / Os adjacentes para eficiência. O IO não sincronizado através do cache de páginas obtém enormes benefícios de desempenho com o cache de write-back e a leitura antecipada automática. Você pode percorrer um longo caminho usando apenas o tamanho do cache da página ou o 4KB de codificação: -).
Na maioria das transferências, o cache de páginas impõe um tamanho mínimo para o IO físico. O tamanho da página é de 4KB na maioria dos sistemas, e geralmente o IO do arquivo passa pelo cache da página. (Novamente, arquivos pequenos são um caso especial. Ou melhor, a última página de um arquivo é um caso especial, se o tamanho do arquivo não for um múltiplo exato de 4KB).
[*] Por exemplo Considerando as camadas de abstração modernas, às vezes você pode ver um campo que diz "tamanho do setor" relatado como 512, em um disco moderno de "formato avançado" que usa setores físicos de 4KB.