Propósito da unidade de tamanho padrão do comando de localização 512 bytes

Question

O comando find permite pesquisar por tamanho, que você pode especificar usando as unidades explicitadas na página man :

File uses n units of space.  The following suffixes can be used:
  'b'    for 512-byte blocks (this is the default if no suffix is used)
  'c'    for bytes
  'w'    for two-byte words
  'k'    for Kilobytes (units of 1024 bytes)
  'M'    for Megabytes (units of 1048576 bytes)
  'G'    for Gigabytes (units of 1073741824 bytes)

Existe uma razão histórica b é escolhido para "bloco" em vez de "byte", que eu suspeito que seria a suposição mais comum? E por que bloquear seria o padrão e não o byte? Quando e por que alguém iria querer usar essa unidade? Convertendo para bytes / kilobytes envolve um pouco de matemática, não parece muito conveniente para ser a unidade padrão.

    

Answer 1

As primeiras versões do Unix passaram a usar blocos de 512 bytes em seus sistemas de arquivos e drivers de disco. O Unix começou como um sistema bem minimalista e de baixo nível, com uma interface que seguia de perto a implementação, e vazou detalhes que deveriam ter permanecido separados, como o tamanho do bloco. É por isso que hoje em dia “bloco” ainda significa 512 bytes em muitos contextos, embora possa haver tamanhos de bloco diferentes, possivelmente tamanhos de bloco diferentes aplicados a um determinado arquivo (um para o sistema de arquivos, um para o gerenciador de volume, um para o disco ...).

A implementação controlava o uso do disco contando quantos blocos de dados eram alocados para um arquivo, então era fácil informar o tamanho de um arquivo como um número de blocos. O uso do disco e o tamanho de um arquivo podem diferir, não apenas porque o uso do disco normalmente é o tamanho arredondado para um número inteiro de blocos, mas também porque arquivos esparsos têm menos blocos do que o tamanho normalmente requer. Até onde eu sei, os primeiros sistemas Unix que implementaram arquivos esparsos tinham find -size usando o número de blocos usados pelo arquivo, não o tamanho do arquivo; as implementações modernas usam o tamanho do arquivo arredondado (há uma observação para esse efeito na especificação POSIX ).

As implementações find mais antigas aceitaram apenas um número de blocos após -size . Em algum momento, find -size começou a aceitar um sufixo c para indicar um número de caracteres c em vez de blocos; Não sei quem começou, mas foi o caso em 4.3BSD . Outros sufixos apareceram mais tarde, por exemplo, no FreeBSD, foi o lançamento 6.2 que introduziu k , M e outros sufixos, mas não b , que eu acho que existe apenas no GNU e no BusyBox.

Historicamente, muitos programas usavam “caractere” e “byte” de forma intercambiável, e tendiam a preferir o termo “caractere”. Por exemplo, wc -c conta bytes. Suporte para caracteres multibyte e, portanto, uma contagem de caracteres que difere da contagem de bytes, é um fenômeno relativamente recente.

Em resumo, não há propósito. O tamanho do bloco de 512 bytes, o fato de ser a unidade padrão e o uso da letra b não surgiram deliberadamente, mas por acaso histórico.

    

Answer 2

Os blocos eram mais importantes que os bytes, porque, desde o início, os arquivos usavam um determinado número de blocos em vez de bytes no sistema de arquivos. Um arquivo com um byte ainda ocupava um bloco no disco.

Por exemplo, a find(1) página de manual da Unix 6ª edição diz

-size n         True if the file is n blocks long (512 bytes
                 per block).

A página de manual não forneceu formas convenientes de representar outras unidades de medida para tamanho.

O POSIX afirma explicitamente na descrição de find que ele usa blocos de 512 bytes :

-size n[c]
The primary shall evaluate as true if the file size in bytes, divided by 512 and rounded up to the next integer, is n. If n is followed by the character 'c', the size shall be in bytes.

Em alguns sistemas mais antigos, por exemplo, o HPUX 10.20 página de manual, não foi explícito.