O caso do exFAT.

Dado que o exFAT tem uma especificação pública e facilmente acessível, foi o exemplo mais fácil de resolver.

Usando a ferramenta DMDE sugerida por Joep van Steen, podemos examinar a estrutura exata do sistema de arquivos no disco.

Os discos são divididos em setores no hardware^. Essa é a unidade fundamental dos dados.

Existem vários tipos de metadados e efeitos que determinam a quantidade exata de dados utilizáveis.

1. Particionamento: O esquema de particionamento e os próprios limites de partição dividem os discos em seções utilizáveis ​​de acordo com algumas regras muito simples. 2 dos esquemas mais populares são: MBR e GPT. Eu não examinei o MBR em detalhes.

   • A sobrecarga de GPT ( tabela de partição GUID ) tem um tamanho estático. Ele coloca uma tabela de partição abrangendo 34 setores no início do disco e uma tabela de backup abrangendo 33 setores no final.
   • A primeira partição não é obrigada a começar logo após a partição (ou seja, LBA34). Seu setor inicial (e final) é definido pela entrada da partição (uma daquelas caixinhas no LBA2 no diagrama acima). Deixar lacunas pode ser feito para fins de alinhamento^^.

2. Estrutura do sistema de arquivos: No início de uma partição, começam as estruturas e metadados relacionados ao sistema de arquivos. O primeiro setor é o setor de inicialização do sistema de arquivos (isso não tem nada a ver com a inicialização de sua máquina). Ele define que tipo de sistema de arquivos é e seu layout. Diferentes tipos de sistemas de arquivos colocam diferentes tipos de dados, de acordo com suas necessidades e design. Aqui está o setor de inicialização do meu pen drive:

   

   exFAT é um sistema de arquivos baseado em FAT , então, por exemplo, diz quanto tempo a tabela FAT tem e onde está localizada.
   Ele também diz onde o heap do cluster está localizado. A pilha de cluster é todo o espaço em que o usuário pode colocar vídeos de snowboard e fotos de gatos.

3. Metadados do sistema de arquivos: Até agora, medimos dados e localização em setores . O sistema de arquivos é uma estrutura usada para gerenciar esses setores de maneira fácil e consistente. Cria suas próprias unidades de dados, de acordo com seu design, que gerencia com base em seus mecanismos internos. (Este é um exemplo de adição de uma camada de abstração.) Essas unidades de dados são chamadas de clusters . Cada cluster pode ser um ou mais setores contíguos . Eles só fazem sentido dentro do escopo do sistema de arquivos. O setor de inicialização acima diz o tamanho deles (como uma potência de 2), onde começa esse heap de cluster e quantos deles temos.

   • Os 2 primeiros clusters em um exFAT fs estão sempre vazios.
   • Além disso, o exFAT mantém um bitmap de alocação de cluster ( $BITMAP). Cada bit no bitmap especifica se o cluster correspondente está livre.
   • Uma tabela Up-case (exFAT é um fs que não diferencia maiúsculas de minúsculas, e a tabela ajuda a implementá-lo). Tem um tamanho fixo.

4. Espaço restante: cortamos o espaço na unidade e o espaço em uma partição em pequenos pedaços. Mas às vezes o espaço não se alinha perfeitamente com todas as pequenas peças. Como quando você ladrilha seu banheiro e começa com ladrilhos inteiros, mas no final não pode colocar uma peça inteira, então tem que cortá-la parcialmente.

   Exceto em nosso caso, não podemos cortá-lo, então um pouco (qualquer pequena quantidade de espaço que não cabe em um cluster inteiro ) não é usado. Quanto maior o tamanho do cluster , mais espaço pode potencialmente não ser utilizado.

Resposta completa

Todos os itens acima formam a explicação necessária e suficiente da questão para exFAT.

Em geral, o acima se aplica a todos os sistemas de arquivos, mas os detalhes podem ser diferentes (por exemplo, outro sistema de arquivos pode não deixar os 2 primeiros clusters vazios como exFAT).

Eu criei uma planilha para demonstrar essas relações:

Tamanho do cluster versus espaço utilizável em exFAT

Observações:

• Os números se alinham perfeitamente^^^ com as capacidades relatadas da unidade.

• Não importa que tipo de arquivos você coloca no sistema de arquivos em termos de eficiência de metadados. (Para exFAT de qualquer maneira, e outros sistemas de arquivos de metadados estáticos como ext4.)

• O tamanho do arquivo ainda importa, devido ao problema de ladrilhos (veja 4 acima). Estatisticamente, em média, você desperdiçará
  (número de arquivos) * (metade do tamanho do cluster)
  de espaço

  • Alguns sistemas de arquivos avançados, como btrfssão capazes de usar esse espaço vago.
    Isso é chamado de subalocação de bloco .
  • Além disso, alguns sistemas de arquivos podem armazenar pequenos arquivos "em linha" - junto com o bloco de metadados, em vez de alocar clusters para ele. ( NTFS , btrfs , ext4 )

• Depending on the size of a particular drive/partition, there will be a sweet-spot for metadata efficiency (the bolded column in the spreadsheet). Seek the lowest number.

• You may look to the formulas in each cell to find how each value is calculated.

• There are many additional comments in the sheet

• There are 2 hardcoded parameters (discovered by looking at the formatted results afterwards, rather than calculated from prior data): FAT length and Cluster heap offset.

  • I don't know what algorithms are used to calculate those. I tried looking through Rufus' source code for the answer, but it just calls into a native function (fmifs.dll::FormatEx) to perform the actual operation.
  • There is clearly a pattern to the FAT len values. See the end columns, and also note the same values cropping up in the min FAT len column. However I do not have the math chops to deduce it. I welcome help.

• Edit: Bonus optimization time. There is a point at which the wasted space of a high cluster size becomes greater than savings from metadata. This depends on the number of files on the filesystem. I've added a new column at the end to demonstrate this relationship.

N.B. I welcome contributions to the spreadsheet. If you wish to contribute, request access and ye shall be granted.

^ Existem camadas de abstração aqui, como formato avançado e tamanhos de página NAND, que não abordaremos aqui. Essas abstrações são impostas pelos próprios dispositivos e são (principalmente) transparentes para o sistema operacional.
^^ Os sistemas operacionais podem quebrar a abstração durante a formatação para evitar problemas de alinhamento. Consulte Formato avançado .
^^^ Exceto por 1 cluster = 1 setor, cujas razões não explorei em detalhes.

Esta não é a resposta, mas pode ajudá-lo a determinar o que está acontecendo e expandir meu comentário. Já faz um tempo desde que eu cavei fundo nisso, tão pouco enferrujado ..

Primeiro precisamos de alguns valores do setor de inicialização:

Agora podemos calcular a área de dados, a área do sistema de arquivos que resta após a subtração de metadados como os FATs:

início da área de dados = reservado + (2 * grandes setores por FAT), portanto, início da área de dados = 7166 + (2 * 513) = 8192.

Também podemos determinar setores por cluster, lemos 8 e o total de setores 532480. Portanto, tamanho da área de dados = 524288

Cluster total do clustermap para esta mesma partição:

65538. Multiplique por seita/clus, então 65538 * 8 = 524304

Portanto, vemos a discrepância 524304 - 524288 = 16, que na verdade representa 2 clusters. Hum. Isso pode ser normal, na verdade, eu teria que verificar.

Agora, o que eu queria dizer é que você pode experimentar diferentes clusters e ver o que acontece com os números, ver de onde vem essa estranheza que você observa.

Minha teoria é/era o formato 'brincar' com o valor dos setores reservados para talvez alinhar a área de dados no limite de 4k, por exemplo, no caso de a partição começar em LBA ímpar, mas também pode querer evitar um número ímpar de clusters ou não totalmente colocado em uso Setores FAT.

Os setores reservados são em grande parte 'espaço perdido' e isso pode afetar de alguma forma como a matemática funciona para o número de clusters endereçáveis. Mas note que isso é apenas uma hipótese. Quanto maior esta área, menos espaço para clusters. Portanto, modificando seu tamanho, ele pode alinhar os clusters, evitar um número ímpar de clusters e garantir que todas as entradas do FAT correspondam a um cluster real.

Então, novamente, não é a resposta, mas talvez ajude a restringir a resposta.

Para o NTFS, seria uma história totalmente diferente, pois não possui um conjunto fixo de estruturas de metadados do sistema de arquivos, como o FAT. $ MFT pode crescer/diminuir (embora eu nunca tenha visto isso acontecer), $ Bitmp, suponho, pode ser bastante esparso, desde que haja grandes quantidades de clusters livres, apenas para citar algumas diferenças exFAT <> NTFS.

Para a 'área de dados' como um todo, não importa, pois os próprios metadados do sistema de arquivos são considerados arquivos pelo NTFS. E toda a partição é dividida em clusters, então o primeiro setor também é o primeiro setor do primeiro cluster.

Eu escrevi um pequeno script python para nos dar algumas dicas:

def meh(i):
    cluster_size_in_byte = i[0] * 1024
    cluster_size_divisible_volume_size = 15794682880 - 15794682880 % cluster_size_in_byte
    unknown_taken_up_size_in_byte = cluster_size_divisible_volume_size - i[1]
    unknown_taken_up_size_in_cluster = unknown_taken_up_size_in_byte / cluster_size_in_byte
    print((i[0], unknown_taken_up_size_in_byte, unknown_taken_up_size_in_cluster))

print("exfat:")
for i in [
        (64, 15792537600),
        (128, 15792472064),
        (256, 15792340992),
        (512, 15792078848),
        (1024, 15791554560),
        (2048, 15789457408),
        (4096, 15783165952)
]:
    meh(i)

print("ntfs:")
for i in [
        (4, 15794679808),
        (8, 15794675712),
        (16, 15794667520),
        (32, 15794667520),
        (64, 15794634752),
        (128, 15794569216),
        (256, 15794438144)
]:
    meh(i)

E aqui está a saída:

exfat:
(64, 2097152, 32.0)
(128, 2097152, 16.0)
(256, 2097152, 8.0)
(512, 2097152, 4.0)
(1024, 2097152, 2.0)
(2048, 4194304, 2.0)
(4096, 8388608, 2.0)
ntfs:
(4, 0, 0.0)
(8, 0, 0.0)
(16, 0, 0.0)
(32, 0, 0.0)
(64, 0, 0.0)
(128, 0, 0.0)
(256, 0, 0.0)

A resposta para o caso do NTFS é simples: quando o tamanho do cluster fica maior, o "resto" inutilizável/"não-clusterizável" da partição fica maior.

Para o caso exFAT, esse também é um dos motivos, mas é mais complicado, pois de acordo com a capacidade relatada que você obteve, pelo menos 2MiB seriam usados ​​para fins desconhecidos, e fica ainda mais complicado porque, aparentemente, isso a parte ocupada seria de pelo menos 2 clusters grandes.

No entanto, não estou familiarizado com os componentes internos do exFAT, portanto, não tenho informações sobre esse cluster de 2MiB / 2 para oferecer.

De acordo com algumas pesquisas e testes que fiz (com exfatprogs ), parece que o 2MiB é uma escolha para "Cluster Heap Offset" , que consiste em um "FAT Offset" de meio tamanho . (Basicamente, alinhamento de 1MiB, que é consistente com o comportamento de particionamento no Windows.)

Além disso, aparentemente, "FAT Length" geralmente é do mesmo tamanho que o tamanho do cluster, e a Microsoft parece ter optado por garantir que "FAT Offset" seja sempre metade do "Cluster Heap Offset", portanto, quando o tamanho do cluster e, por sua vez, "FAT Length" exceder 1MiB, "FAT Offset" será igualado a "FAT Length", o que resulta no "Cluster Heap Offset" tornando-se 2 clusters grandes. (O comportamento NÃO é observado / o padrão em exfatprogs' mkfs.exfat.)

EDIT: Como eu havia pensado, mas não escrito, em vez de ter "FAT Offset" sendo metade de "Cluster Heap Offset", "FAT Offset" pode ser 1-MiB all / na maioria das vezes, ou seja, o preenchimento / lacuna restante , se houver, em "Cluster Heap Offset" reside após o FAT em vez de antes.

Eu realmente não verifiquei as formações produzidas no Windows com dump.exfatexfatprogs. Caso queira saber os detalhes exatos e confirmados, você mesmo pode experimentar o programa em um ambiente Linux (talvez até WSL).

A propósito, para dizer o óbvio, as capacidades informadas em suas tabelas são cluster size * number of clusters. Em outras palavras, (tamanhos dos) dados e metadados em qualquer um dos clusters são irrelevantes para os números.

Vou tentar tentar responder a esta pergunta, que realmente à primeira vista parece ser contrária à lógica.

Primeiro para esclarecer a terminologia usada no post. O tamanho do cluster não é o mesmo que o tamanho do bloco, pois o tamanho do bloco é determinado pelo hardware, mas um cluster contém vários blocos e é a unidade de alocação do disco.

Por um lado, quanto maior o tamanho do cluster, menos clusters existem no disco, portanto, menos sobrecarga é necessária para gerenciar os clusters para bitmaps de alocação e entradas FAT.

Por outro lado, o formato de disco exFAT (na verdade, todos os formatos) aloca espaço por clusters, de modo que, se os dados (de qualquer tipo) não ocuparem exatamente um cluster inteiro, o espaço restante será desperdiçado.

Minha ideia é que não apenas os arquivos podem desperdiçar espaço dessa maneira, mas também as tabelas de disco (ou estruturas de dados) alocadas como parte do disco exFAT.

Olhando para a especificação do sistema de arquivos exFAT , tentei contar as áreas definidas (ou regiões).

Minha contagem foi em torno de 15 regiões que são alocadas quando o formato exFAT é criado e que compõem sua estrutura.

Cada uma dessas áreas não contém mais dados quando maiores e menos clusters são definidos, alguns são realmente menores. O espaço ocupado por algumas dessas regiões é contabilizado em clusters, portanto, ao ampliar os clusters, o espaço desperdiçado também é ampliado.

Isso pode explicar parte do desperdício de espaço útil, mas as irregularidades nas medições de desperdício pelo cartaz também podem apontar para erros na alocação dessas tabelas ou para informações ausentes na documentação.