Salut.
Au cours d'une recherche sur le forum, j'ai vu beaucoup de gens dire ça, mais jamais expliquer pourquoi.
Le site de bellamy semble mort.
 
Avez-vous des explications ?
Si ca fragmente vraiment moins, peut on considérer que cela compense la relative lenteur de NTFS en écriture (par rapport a FAT) ?

Dans l'absolu la FAT32 est plus rapide. Mais le NTFS a bien d'autres avantages : prends en compte la gestion des gros disque dur > 2To, taille des fichiers illimités(Max 4Go en FAT32), notion de droit d'accès sur les fichiers et sécurité supplémentaires... et il fragmente un peu moins effectivement.

Et aussi :
http://www.commentcamarche.net/repar/fat32.php3

Merci mais cela ne répond absolument pas à ma question.
Je ne demande pas les avantages et inconvénients de NTFS et FAT32, j'ai déja eu le temps de les lire 150 fois lors de ma recherche.
Ce que je veux savoir c'est POURQUOI est-ce que NTFS fragmenterait moins.

ce qui est sûr c'est que le NTFS fragmente de toute façon, et pas qu'un peu. d'autres systèmes de fichiers sous linux/unix (genre ext2, reiserFS ?) ne fragmentent pas

Oui mais pourquoi ?  

LOL on dirait des politiciens    
 
Yen a ici qui maitrisent l'art de la langue de bois  

perso je suis en fat32 pour l os et en ntfs pour mes DDs de stockage
 
ah merde ça répond pas à la question

et moi c'est l'inverse
(mais c'est sur un seul DD)
 
cette histoire de fragmentation moindre c'est peut-être juste de la propagande de Microsoft.

La restauration du système fragmente à mort, quand on la désactive, ça fragmente largement moins mais il faut mieux avoir une image de son disque pour faire ça.  
Mais je ne sais pas non plus pourquoi Fat32 NTFS machin bidule !
 
 

c'est une histoire de taille de secteur je crois
 
fat32 prend (je dis n'importe quoi sur les valeurs je les connais pas) 8k0 qq soit le fichier même si c'est un de 2k0
 
ntfs occupe 4ko (par ex), voila

 
http://patrice.bonnefoy.free.fr/w2 [...] ysfile.htm
 
 

Ca explique pas trop pourquoi M$ aurait mis ce petit bout de code magic pour la gestion de la NTFS et par pour la FAT32... Y'a forcément une raison qui provient du système de fichier lui-même, pas de la façon que l'OS l'utilise
 
Nan, y'a une raison qu'elle est meilleure et que c'est une raison plus valable, même si elle rejoint l'explication ci-dessus : en FAT32, la FAT ne contient pas les infos nécessaires pour se faire une idée de la taille des emplacement innoccupés, et du coup impossible de choisir celui qui correspond le mieu à au fichier qu'on est en train d'écrire. La FAT32 ne contient que l'emplacement de chaque trou, sans plus d'information (donc quand on écrit dans un trou et qu'on s'apperçoit qu'il n'y a pas assez de place ben ça fragmente.
En NTFS, la FAT est plus complexe (et plus grosse aussi), mais référence l'emplacement et la taille de chaque "trou" du disque. Ainsi, si je veux stocker un fichier de 2 Mo, Windows est capable de rechercher le plus petit trou possible de plus de 2 Mo. C'est aussi ebn partie pour cette raison que la NTFS est plus lente : y'a plus d'accès disque pour mettre à jour la FAT. D'autant qu'elle est dupliquée (au début et à la fin du disque), sans parler d'autres conneries qui plombent bien les accès disques, genre la date de dernière accès de chaque fichier, qu'il faut mettre à jour même quand on ne fait que lire un fichier.

Le coup de la date de dernière utilisation est utile lorsqu'on défragmente par contre : defrag est capable de retrouver les fichiers qu'on utilise rarement, et peut les coller dans un endroit lent du disque, alors que les fichiers souvent solicités peuvent être déplacés vers les zones plus rapides.

ce qui flagrant c est lorsqu on fait un clic droit puis "propriétés" sur un répertoire contenant beaucoup de fichiers (par ex. ~30000 fichiers) pour indiquer la taille du répertoire.
sur un Fat32,cela va très vite ce qui n est pas le cas sur du NTFS mème en désactivant certains options

normal dans la NTFS, c'est la MFT qui fragmente le plus

L'OS a cette info  
 
J'ai pas souvent écrit de programme, mais je ne me rappelle pas avoir précisé la taille finale lorsque j'ouvre un fichier en écriture. Lorsque les premières données arrivent, et qu'il faut bien commencer à les écrire, comment l'OS sait si le programme va écrire 2 Mo ou 200 Mo  

bah y'a le cache système pour ça. pour les petits fichiers ça doit normalement marcher sans problème. évidement, si tu dépasses le cache système, là il va chercher logiquement le plus gros espace du disque possible

 
ça je veux qu'on me le prouve ...  
je pense que c'est un abus. Ils ne fragmentent pas trop... voir pas si c'est possible...
allez, un petit TD
 
j'ai une partition vierge de 1Go
je rempli 333Mo avec 1 fichier. il fragment pas, donc il est en 1 morceau
cas 1: le fichier est au début  
> il me reste un bloc de 666Mo de libre
cas 2: le fichier est au milieu  
> j'ai 2 blocs libre dont la somme totale fait 666Mo. Si je mets un autre fichier de 666Mo, comment est-ce possible qu'il ne soit pas fragmenté ? à moins qu'il y est un déplacement complet du premier fichier (et des perfs de merde), je vois pas trop ...  
 
si j'ai eu le cas 1:
ben on continue en rajoutant un fichier de 333Mo, puis un troisième.  
ya forcément un fichier qui est entre les 3 autres...  
je supprime ceux des bords et je rajoute un fichier de 666Mo > il est obligé d'être fragmenté
 
bref, tout ça pour dire que on peut limiter la fragmentation, mais on peut pas l'éviter. D'ailleurs, une légère fragmentation n'est pas génante du tout.  

Il y a au moins : une affaire de taille de granule, et une histoire d'organisation des données sur le disque.
 
Le granule (cluster) est l'espace minimum alloué à un fichier. Un fichier de 1 octet occupe au moins un granule sur le disque (en tous cas sur ces deux systèmes, ReiferFS est différent).
 
Un Fat32 a une taille de granule proportionnelle à la taille du disque (la base est un millionième du disque je crois, puis on prend la puissance de deux supérieure). 12Go => TailleDeGranule = 8Ko, pour un 120Go, ça devrait faire 64Ko ou 128Ko.
 
En NFTS le granule fait 4Ko, quelle que soit la taille du disque : donc on perd au plus 2Ko en moyenne par fichier.
 
Ensuite y'a la façon de gérer la structure des données sur le disque, il y a beaucoup d'algorithmes, et dans l'ensemble c'est la suppression des fichiers qui pose problème. Soit on perd du temps à la suppression, soit il faudra défragmenter plus tard. Sur les deux, il faut défragmenter. Mais comme l'agencement des données en NTFS suit des algorithmes compliqués (arbres équilibrés), c'est beaucoup plus compliqué sur NTFS que sur FAT32.
 
Donc les granules sont plus petits sur NTFS, plus nombreux, la défragmentation est plus complèxe, donc ça dure longtemps.
 
Mais vous pouvez faire tourner un petit linux en VMWare et lui faire partager le disque avec le Windows de la même machine, et utiliser un système de fichiers sérieux (ReiserFS, xfs, jfs).
 
A++
--
Wile

A noter quand même que NTFS ne fait pas forcément 4 Ko par cluster. Ca c'est l'utilisateur qui décide.
 
On peut aller de 512 octets à 64 Ko
Actuellemet, j'ai un disque avec chacun de ces deux paramètres.
 
De plus petits clusters garantissent un espace de stockage plus grand pour des tous petits fichiers, tandis que 64 Ko ganranti des performances très acrues pour des fichiers de grosse taille.
 
Un fichier de 100 octets dans un cluster de 4096 octets, ca fait près de 4000 octets perdus... Donc sur le disque de 100 Go par exemple, ca veut dire que moins de 2 Go seront utilisables si on n'a que de petits fichers !
 
Par contre, un cluster de 64 Ko, pour des fichiers de 100 Mo, ca veut dire qu'il pourra être saussisonné au pire en 1500 clusters. Avec des clusters de 4 Ko, il sera saucissonnable en 25000 clusters ! Autant dire que la fragmentation, même intense, sera moins grave avec des clusters de 64 Ko... Et sur un fichier de 100 Mo, 64 Ko, ça représente même pas 0,001% de la taille, donc on se moque un peu de perdre de la place avec de gros clusters.
 
En fait, le principal atout de la NTFS, que personne n'utilise, c'est ça : on peut adapter la taille des custers à ses besoins. Et c'est pourtant très important, puisque ça permet de gérer soit-même le ratio "fragmentation/perte de place".

en NTFS, la granularité d'allocation est de 512 octets dans la MFT, 4Ko ou autre ailleurs.

voila le meilleur article que j'avais trouvé (il faudrait que je le mette dans mes favoris):
 
http://www.digit-life.com/articles/ntfs/index3.html

sinon pour en revenir a la question initiale ce qui joues c'est:
 
1) la finesse et les diverses stratégies d'allocation possible
 
2) une meilleure visibilité de la distribution des données sur le disque avec de meilleures performances de recherche d'espace libre (l'un allant avec l'autre).
 
(que la fat n'as pas)

Hello à Tous,  
 
@ WileECoyote
============
 

 
Il me semble que tu oublies la notion de secteurs, de pistes, de cylindres et de têtes.
 
De mémoire :
1 secteur = 512 octets.
1 piste = 63 secteurs,
1 cylindre = 255 pistes. Il me semble qu'un cylindre est la représentation en 3D des pistes sur l'ensemble des plateaux qui composent un DD, et que selon la capacité des disques, le nombre  de cylindre est variable.
 
Par contre depuis NTFS, on peut descendre la taille des clusters à la taille du secteur soit 512 octets.
 
Donc la plus petite unité d'allocation que sait adresser un filesystem en ntfs est bien ce que tu dis le cluster qui représente 1 à n "secteurs".
Plus tes clusters sont petits moins tu perds d'espace, donc fragmentation moindre
et
inversement plus les clusters sont grands plus forte est la fragmentation.
 
 
A cela vient s'ajouter ce que j'appelle la dynamique du disque. A savoir que lors de l'ecriture sur un disque il n'est pas intéressant mathématiquement parlant d'écrire 2 clusters à la suite, pour la bonne et simple raison est que à la fin de l'écriture du 1er cluster, du fait de la rotation des plateaux ben il faut attendre de un à n tours de plateaux afin que les têtes se repositionnent correctement, c'est à dire à la suite du 1er secteur écrit.
En clair on a tout intérêt à écrire le second cluster à l'opposé du 1er qui vient d'être écrit. Ainsi de cette façon les têtes ne subissent pas l'inertie du système.
 
Il faut noter également que compte tenu du fait que NTFS est un filesystem journalisé (il conserve une trace de chaque transaction sur les fichiers dans les fichiers cachés du rép "System Volume Information" ) il est plus lent que FAT, à cela il faut ajouter la gestion des quotas, des sécurités et les partages.
Cela dit du fait de l'architecture extrement complexe de la $MFT (Master File Table) et des fichiers $* asociés il reste tout de même beaucoup plus fiable.
 
 
Je pense qu'ensuite la fragmention vient comme tu l'indiques de l'effacement des fichiers au fil de l'eau et donc de la libération des clusters associés. La réallocation des dits clusters pour des nouveaux fichiers est en général le point de départ de la fragmentation compte tenu de ce qui est écrit précédemment : taille du fichier, position des clusters sur les plateaux, vitesse angulaire plateaux/tetes, vitesse lineaire des plateaux.
 
Bref tous les élements qui composent les algo d'attribution/libération des clusters.
 
 

 
Je ne connais pas ces filesystems en quoi sont-ils plus performants que NTFS ?
 
A mon humble avis on touche là l'un des fondamentaux de tout O.S.  L'organisation et l'architecture des données (l'autre étant les processus du noyau).
Avec Micron$oft on est pieds et poings liés. Si j'ai envie d'essayer une autre structure de filesystem je ne peux pas.
C'est FAT ou NTFS ou RIEN.
 
Alors qu'il semble qu'avec Linux, les *BSD (Free, Open, Net) et les Unix en général cette contrainte n'existe pas.
 
 
Or aujourdh'ui il n'est pas rare de trouver des disques dont la taille est de 300 à 500 Go. Evidemment la question de sauvegarde sur des supports se pose pour les utilisateurs.
Malheureusement à part le RAID, la redondance ou les petits NAS la question reste entiere.
 
Comment protéger mes données quand mon disque à une taille de 500 Go ? On voit de suite que le DVD n'est absolument plus le support adapté.
 
Or le début de réponse à cette question est le concept de filesystem, de sa performance (=fragmentation éventuelle) et surtout surtout de sa capacité à restituer les données en cas d'accident. Car quand tout va bien personne ne se pose ces questions.
 
Au contraire, quand il y a un incident ou pertes des données c'est là où l'on est en droit de mesurer les performances du filesystem et de dire s'il est fiable ou non.
 
   
BB94

bon déjà la relation cluster/secteur ne joues que peu sur la fragmentation, cela joues sur l'espace perdu essentiellement.
 
c'est pour ça qu'en NTFS tu as la MFT qui a un pool d'espace pour les fichiers de petite taille.
 
pour rappel la fragmentation c'est la consécutivité des blocs de données impactant les lectures séquentielles.
 
dans le cas de médias non impactés par des contraintes de localité par la mécanique, on se fout royalement de la fragmentation (dans une certaine mesure), ie la ram ou la pagination fragmente les espaces des process, les mémoires dites "solid-state" comme la flash (CompactFlash....)
 
ensuite la gestion du disque est linéarisé par le LBA, l'OS pert la description géométrique du disque, qui est de toutes façon faussé pour respecter les restrictions du bios,  et c'est le firmware du disque dur qui s'occupe de la gestion de l'entrelacement des secteurs vis à vis de nbre de cylindres réels.
 
et justement à l'écriture il est interressant d'écrire de manière consécutive car les donnés sont réparties sur les cylindre ie un cluster de 2Ko (4*512 octets) sera par exemple réparti par le firmware sur les 2 plateaux double-face d'un disque, et quand une rafale arrive, c'est pareil...

gniarf
 
je me disais que mon portable rammait beaucoup ces deniers temps...
 
je vais un petit defrag, analyser et...
 
J'ai un fichier de 3,3 Go (image ISO de MSDN Library, ça m'évite de me trimballer avec les CD) qui fait 12,794 fragments (pas mal...)
Mais aussi des trucs pas mal : un fichier de 3 Mo coupé en 658 fragments !
 
Forcément, avec plus de 250,000 entrées dans la MFT pour environ 20 fois moins de fichiers, ça ne peut que rammer

 
mais pour la MSDN tu te feras moins chier a tout installer en complet sur le HD, que de garder l'ISO.... (d'ailleurs je le trouve pas mal le MSDN qui va avec VS2005).

C'est c'elle de VS 2003, j'ai pas VS 2005 encore (ça ne saurait tarder, Microsoft ils sont lents à valider les inscriptions )
 
Sinon, je préfère avoir une ISO qui ne perds pas un octet sur le disque plutôt que 100000 fichiers de 500 octets qui bouffent un cluster de 4 ko chacuns

bin ça tombe bien en NTFS, les 100000 fichiers de 500 octets seront dans le pool des petit fichiers de la MFT, et prendront 512 octets

Sinon regarde moi sur mon MSDN de Janvier 2006 (VS2003):
Taille: 1,60 Go (1 726 024 917 octets)
Taille disque: 1,61 Go (1 729 646 592 octets)
(1758 fichiers)
 
Celui de VS2005:
Taille: 1,05 Go (1 134 203 854 octets)
Taille disque: 1,05 Go (1 135 616 000 octets)
(642 fichiers)
 
Donc ça va....

mouais mais même, je préfère conserver mon iso, comme ça au pire si j'ai besoin d'en filer une copie à un collègue je l'ai sous la main
 
pis maintenant qu'il est défragmenté, j'ai forcément de très bonnes perfs vu que les fichiers sont tous dans un segment contigüe du disque

 
comment vous faites pour savoir en combien de fragement un fichier est composé ?

dans defrag, tu fais afficher le rapport.

ah ok je savais pas.. moi j'ai un fichier de 398 mo decoupé en 10799 fragments et un fichier de 2mo en 424 fragments sur ma partition ntfs de mon dd 80go...
 
 
Et sinon j'ai 2 partitions sur ce DD.
Un partition de 40 go principale (l'OS est dessus) en fat32
une partition de 40 go secondaire en ntfs.
 
sur fat32 j'ai 1,37 fragment par fichier.
sur ntfs j'ai 1,49 fragment par fichier.
 
Ntfs fragmente moins que fat32 ? ben d'apres moi c'est le contraire..
 
 
Et sinon j'ai acheté recemment un dd de 300go (il y a 2mois) , et windows me conseille deja de le defragmenté.. pourtant il est en ntfs, j'ose meme pas le defragmenter ça doit prendre plusieurs jours et abimer vachement le dd de le faire ecrir non stop... Bref c'est pas trop au point leurs technique encore...

 
2ko en NTFS l'unité d'allocation par défaut il me semble, mais c'est pas le seul paramètre...
 
Si je prend mon disque données là ça me fait 19 787 344 829 octets de fichiers occupant 19 922 071 552 octets d'espace disque, et pourtant y'a de tout dessus...  
 
En tout cas ceux qui disent que le NTFS fragmente moins sont totalement à côté de la plaque, le système en lui-même fragmente plus. De même en ce qui concerne les formats Ext2 et autres, tous fragmentent, c'est inévitable.
 
 
Concernant l'usure pendant la defragmentation, il faut arrêter avec ça aussi, ça l'use, ok, mais si tu ne défragmente pas ça l'usera autant chaque fois que tu lira les fichiers fragmentés, donc beaucoup plus.

salut,
peut on convertir un HDD qui est en fat32, en ntfs et inversement sans perte de données ???
merci.

Quand on est en raid0, la défragmentation "use" t-elle autant les hdd qu'en non-raid ?

et si un disque est fragmenté et que je compte le formater, je suppose que c'est la meilleur solution pour avoir un disque propre ????
merci.