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

10

No Windows XP 64, eu 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 eu desfragmentava os outros arquivos, então você não pode ver o estado exato no ponto em que o arquivo foi escrito. No entanto, o disco estava o tempo todo tão vazio quanto agora (25% usado) e dificilmente fragmentado.

QualalgoritmodealocaçãodeblocosoNTFSusa?Parecealeatóriooutalvezcolocá-loondeacabeçadodiscorealmenteestá.

UPDATE:

Foioqueaconteceuhojedepoisdeescrever67MiBdeumnovoarquivo.Elefoidivididoem731fragmentos,comtamanhomédiodeapenas95KiB.Oarquivofoiusadoparapreencheralgumaslacunas,masnemtodaselas,tambémnãousamoenormeespaçolivrecontínuo.Estranho,nãoé?

UPDATE2:

Aocontráriodo PC Guru , eu realmente não acho que o Opera seja o culpado. Eu acho que (ao contrário do Google Chrome) não diz ao Windows o tamanho esperado, no entanto, há muitos casos em que isso não é possível e é responsabilidade do SO lidar com isso de uma maneira sã. 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 aqueles gerenciados pelo Windows) estão localizados em outro lugar. O próprio Windows parece não usar SetEndOfFile e fragmenta seus próprios arquivos de maneira terrível (600 fragmentos para um pequeno arquivo de cerca de 40 MB). O NTFS não parece usar o primeiro setor disponível, pois há arquivos no meio e também perto do final do disco vazio (uso de 23%), então o algoritmo exato ainda é desconhecido.

    
por maaartinus 24.04.2011 / 17:56

2 respostas

11

IIRC, o sistema de arquivos NTFS tenta alocar o arquivo no armazenamento contíguo. No entanto, só pode fazer isso se o sistema de arquivos souber o tamanho do arquivo. Se você abrir um arquivo e começar a escrever nele, ele escreverá no "melhor" lugar para encaixar o arquivo (normalmente na parte externa do disco). Mas esse lugar "melhor" 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 pode fazer um trabalho melhor de localizar espaço contíguo para o arquivo (a API SetEndOfFile faz com que o NTFS aloque armazenamento para o arquivo inteiro).

    
por 24.04.2011 / 18:57
2

Seu problema deve estar no Opera. Acabei de ver um monte de arquivos em uma unidade muito completa e fragmentada. Grandes arquivos baixados usando o Chrome eram todos contíguos.

Isso sugere que o Chrome conhecia o tamanho do arquivo no início do download, então disse ao NTFS o tamanho do arquivo a ser 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. É interessante que sempre use esses fragmentos em ordem decrescente de tamanho, de modo que arquivos grandes copiados pelo Explorer em uma unidade fragmentada possam passar por toda a unidade.

Onde o programa não sabe o tamanho do arquivo, ou não se incomoda em dizer ao NTFS, mas apenas abre um arquivo e começa a gravar dados sequenciais, parece que o NTFS age muito similar ao FAT32, que simplesmente começa no primeiro disponível cluster (ou o primeiro disponível após o último alocado naquela sessão), em seguida, usa o que estiver disponível a partir daí para a frente. Como exemplo, mais ou menos na mesma época, pedi ao CCleaner para verificar o registro, fazendo com que ele fizesse backup em um arquivo ".Reg" de texto grande. Este arquivo começou perto do 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 examinei, os clusters foram alocados em ordem crescente.

Para esta pesquisa, usei o Winhex (versão de avaliação gratuita disponível no 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, List Clusters, para ver a lista de clusters usados por esse arquivo.

    
por 01.05.2011 / 22:01