Qual algoritmo de alocação de bloco o NTFS usa?

No Windows XP 64, baixei um arquivo de 1,2 GB e ele acabou fragmentado, como mostra a imagem. Infelizmente, antes de tirar o instantâneo do Piriform Defraggler, desfragmentei os outros arquivos, para que você não possa ver o estado exato no momento em que o arquivo foi gravado. No entanto, o disco estava o tempo todo vazio agora (25% usado) e dificilmente fragmentado.

Qual algoritmo de alocação de bloco o NTFS usa? Parece aleatório ou talvez colocá-lo onde está a cabeça do disco.

ATUALIZAR:

Foi o que aconteceu hoje depois de escrever 67 MiB de um novo arquivo. Foi dividido em 731 fragmentos, tamanho médio de apenas 95 KiB. O arquivo foi usado para preencher algumas lacunas, mas nem todas, também não usa o enorme espaço livre contínuo. Estranho, não é?

ATUALIZAÇÃO 2:

Ao contrário do PC Guru , eu realmente não acho que o Opera seja o culpado. Eu acho que (ao contrário do Google Chrome) não informa ao Windows o tamanho esperado, no entanto, existem muitos casos em que isso não é possível e é responsabilidade do sistema operacional lidar com isso de maneira sadia. A figura a seguir mostra o que aconteceu depois de alguns dias sem fazer quase nada nessa partição - o diretório TEMP e todos os meus dados (exceto os gerenciados pelo Windows) estão localizados em outro lugar. O próprio Windows parece não usar SetEndOfFilee fragmenta seus próprios arquivos de maneira terrível (600 fragmentos para um pequeno arquivo de cerca de 40 MB). O NTFS parece não usar o primeiro setor disponível, pois há novamente arquivos no meio e também perto do final do disco vazio (uso 23%),

IIRC, o sistema de arquivos NTFS tenta alocar o arquivo no armazenamento contíguo. No entanto, isso só pode ser feito se o sistema de arquivos souber o tamanho do arquivo. Se você abrir um arquivo e começar a gravá-lo, ele será gravado no "melhor" local para caber no arquivo (geralmente na parte externa da bandeja). Mas esse "melhor" lugar pode não ser grande o suficiente para caber no arquivo.

Se o aplicativo informar ao NTFS o tamanho real do arquivo (com SetEndOfFile ()), o NTFS poderá executar um trabalho melhor ao encontrar espaço contíguo para o arquivo (a API SetEndOfFile faz com que o NTFS aloque armazenamento para o arquivo inteiro).

Seu problema deve estar com o Opera. Acabei de analisar um monte de arquivos em uma unidade muito cheia e fragmentada. Os arquivos grandes baixados usando o Chrome eram todos contíguos.

Isso sugere que o Chrome sabia o tamanho do arquivo no início do download, então disse ao NTFS o tamanho do arquivo esperado. Se você fizer isso, o NTFS tentará colocar o arquivo em um único fragmento, ou quando nenhum fragmento for grande o suficiente, nos maiores fragmentos disponíveis. Curiosamente, ele sempre usa esses fragmentos em ordem decrescente de tamanho, para que arquivos grandes copiados pelo Explorer em uma unidade fragmentada possam saltar por toda a unidade.

Onde o programa não sabe o tamanho do arquivo ou não se preocupa em informar o NTFS, mas apenas abre um arquivo e começa a gravar dados sequenciais, parece que o NTFS age de maneira muito semelhante ao FAT32, que simplesmente inicia no primeiro cluster disponível (ou o primeiro disponível após o último alocado nessa sessão) usa o que estiver disponível a partir daí. Por exemplo, na mesma época, pedi ao CCleaner para verificar o registro, fazendo com que ele fizesse backup em um arquivo txt ".Reg" grande. Este arquivo começou próximo ao início da unidade e, em seguida, foi espalhado por 127 fragmentos diferentes. Ao contrário dos arquivos copiados com o Explorer ou baixados com o Chrome, em todos os arquivos que eu observei, os clusters foram alocados em ordem crescente.

Para esta pesquisa, usei o Winhex (versão de teste gratuita disponível em Winhex.com). Ao olhar para uma entrada de diretório. clique com o botão direito do mouse em um nome de arquivo e escolha Posição, Listar Clusters, para ver a lista de clusters usados ​​por esse arquivo.