Quel algorithme d'allocation de blocs utilise NTFS?


10

Sur Windows XP 64, j'ai téléchargé un fichier de 1,2 Go et il s'est retrouvé fragmenté, comme le montre l'image. Malheureusement, avant de prendre l'instantané de Piriform Defraggler, j'ai défragmenté les autres fichiers, vous ne pouvez donc pas voir l'état exact au moment où le fichier a été écrit. Cependant, le disque était toujours aussi vide que maintenant (25% utilisé) et à peine fragmenté.

capture d'écran 1

Quel algorithme d'allocation de blocs utilise NTFS? Il semble aléatoire ou peut-être le placer là où se trouve réellement la tête de disque.

METTRE À JOUR:

C'est ce qui s'est passé aujourd'hui après avoir écrit 67 Mo d'un nouveau fichier. Il a été divisé en 731 fragments, d'une taille moyenne de seulement 95 Ko. Le fichier a été utilisé pour combler certaines lacunes, mais pas toutes, il n'utilise pas non plus l'énorme espace libre continu. Étrange, non?

capture d'écran 2

MISE À JOUR 2:

Contrairement à PC Guru , je ne pense vraiment pas qu'Opera soit le coupable. Je pense que (contrairement à Google Chrome) ne dit pas à Windows la taille attendue, cependant, il y a de nombreux cas où ce n'est pas possible et il est de la responsabilité de l'OS de le gérer de manière saine. L'image suivante montre ce qui s'est passé après quelques jours alors que je n'ai pratiquement rien fait sur cette partition - le répertoire TEMP et toutes mes données (à l'exception de celles gérées par Windows) sont tous deux situés ailleurs. Windows lui-même ne semble pas utiliser SetEndOfFileet fragmente ses propres fichiers de manière terrible (600 fragments pour quelques petits fichiers d'environ 40 Mo). NTFS ne semble pas utiliser le premier secteur disponible, car il y a encore des fichiers au milieu et aussi près de la fin du disque assez vide (utilisation 23%),

capture d'écran 3

Réponses:


12

IIRC, le système de fichiers NTFS tente d'allouer le fichier dans un stockage contigu. Cependant, il ne peut le faire que si le système de fichiers connaît la taille du fichier. Si vous ouvrez un fichier et commencez à y écrire, il écrira au "meilleur" endroit pour ajuster le fichier (généralement vers l'extérieur du plateau). Mais ce «meilleur» endroit n'est peut-être pas assez grand pour contenir le fichier.

Si l'application indique à NTFS la taille réelle du fichier (avec SetEndOfFile ()), NTFS peut faire un meilleur travail de recherche d'espace contigu pour le fichier (l'API SetEndOfFile oblige NTFS à allouer du stockage pour l'ensemble du fichier).


Mais il semble que NTFS ait comblé toutes les lacunes et réparti le reste uniformément sur tout le disque. Comme je l'ai dit, le disque n'a jamais été aussi plein que maintenant, certaines parties du fichier ont été écrites dans certains des derniers secteurs (c'est-à-dire dans les pires emplacements). D'autres parties ont été serrées dans de petites zones entre deux secteurs occupés bien qu'il y ait beaucoup de place libre ailleurs.
maaartinus

Avez-vous appelé setEndOfFile avant d'écrire le fichier sur le disque? si vous ne l'avez pas fait, NTFS n'a aucun moyen de connaître la taille réelle du fichier, il augmentera donc le fichier en utilisant le stockage disponible.
ReinstateMonica Larry Osterman du

Ce n'était pas moi, c'était Opera. Probablement pas. Néanmoins, il n'y a aucune raison de faire quelque chose d'aussi étrange.
maaartinus

Que voulez-vous dire "cet étrange"? Si NTFS connaît la taille du fichier que vous écrivez, il fera des choses intelligentes sur le fichier. S'il ne connaît pas la taille du fichier, il ne peut pas faire un aussi bon travail d'allocation de stockage.
ReinstateMonica Larry Osterman

@ Larry Osterman: Bien sûr, sans connaître la taille du fichier, il est difficile de le faire correctement. Mais le faire aussi mal est difficile aussi.
maaartinus

2

Votre problème doit être avec Opera. Je viens de regarder un tas de fichiers sur un lecteur très complet et fragmenté. Les gros fichiers téléchargés à l'aide de Chrome étaient tous contigus.

Cela suggère que Chrome connaissait la taille du fichier au début du téléchargement, et a donc indiqué à NTFS la taille du fichier à attendre. Si vous faites cela, NTFS essaiera de placer le fichier dans un seul fragment, ou quand aucun fragment n'est assez grand, dans les plus grands fragments disponibles. Fait intéressant, il utilise toujours ces fragments par ordre décroissant de taille, de sorte que les gros fichiers copiés par Explorer sur un lecteur fragmenté peuvent sauter partout sur le lecteur.

Lorsque le programme ne connaît pas la taille du fichier ou ne prend pas la peine de le dire à NTFS, mais ouvre simplement un fichier et commence à écrire des données séquentielles, il apparaît que NTFS agit de manière très similaire à FAT32, qui démarre simplement au premier cluster disponible (ou le premier disponible après le dernier alloué dans cette session) utilise ensuite tout ce qui est disponible à partir de là. Par exemple, à peu près au même moment, j'ai demandé à CCleaner d'analyser le registre, le faisant le sauvegarder dans un grand fichier txt ".Reg". Ce fichier a commencé vers le début du lecteur, puis a été dispersé sur 127 fragments différents. Contrairement aux fichiers copiés avec Explorer ou téléchargés avec Chrome, dans chaque fichier que j'ai consulté, les clusters ont été alloués dans l'ordre croissant.

Pour cette recherche, j'ai utilisé Winhex (version d'essai gratuite disponible sur Winhex.com). Lorsque vous regardez une entrée de répertoire. faites un clic droit sur un nom de fichier et choisissez Position, Liste des clusters, pour voir la liste des clusters utilisés par ce fichier.


J'ai commenté votre réponse dans ma question, car mon commentaire est long et j'ai ajouté une image.
maaartinus
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.