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é.
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?
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%),
la source
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.
la source