Salut juste une petite question technique,
 
pourquoi on a pas besoin de défragmenter sous linux/UNIX et sous windows (quel que soit les versions ou le type de partition FAT/NTFS) on est "obligé" de le faire
Merci  a+ Betan

Parce que les UNIX sont mieux conçus...

un prof d'université explique ca en terme tres accessible ici :
 
http://www.mmedium.com/dossiers/piege/ .  
 
bonne defragmentation sinon !

parceque linux ne fragmente pas c'est tout

Lebibi a écrit a écrit : parceque linux ne fragmente pas c'est tout

 
Pourquoi ne se fragmente-t'il pas ?

 
parce que le sustème de gestion des fichiers et autres.. sont biens programmés (enfin mieux que celui de Win)

 
Je veux bien, mais comment il fait VRAIMENT ? C'est pas magique, il y a un algo, non ?

Lebibi : si, il fragmente, mais très peu, et la fragmentation n'a pas tendance à augmenter au fur et à mesure de l'utilisation : tu verras, au boot, quand les disques sont scannés par fsck tous les X reboots, y'a marqué le taux de fragmentation à la fin de la manip..généralement, il est de l'ordre de 1 ou 2 %...Si ça monte beaucoup, faut vraiment t'inquiéter!
En gros, si tu lis le bout d'article cité par Marx, tu t'aperçevra que forcément, de temps en temps, on est obligé de fragmenter les fichiers quand le disque est trop plein

Kadreg : bon, l'algo...me rapeller de mes cours d'OS
 
Windows : j'ai un fichier à mettre sur disque -> je parcours la FAT (File Allocation Table) au premier espace non occupé que je rencontre, je met le plus gros bout de mon fichier qui tient dedans...Si il tient entier, le fichier n'est pas fragmenté...Sinon, je prends le reste du fichier, et je continue à parcourir la FAT, jusqu'à ce que j'ai tout mis.
 
Linux : le regarde dans ma liste de trous, et je sélectionne le plus petit trou dans lequel mon fichier tient en totalité. Si je ne trouve pas de trou assez grand, j cherche le plus grand trou disponible pour y mettre le plus grand bout possible de mon fichier, puis, je continue en parcourant la liste des trous selon le même principe, avec le bout ed fichier qui reste..
 
On s'aperçoit assez vite, que effectivement, il peut arriver que des fichiers soient fragmentés sous Linux, mais ça arrive très rarement..Ouala!!

 
Cette explication est celle que j'entend depuis des années, et je ne vois pas comment ça peut marcher dans la vraie vie.
 
- Le FS ne connait pas la taille du fichier avant de l'écrire, donc il ne peut sélectionner le plus petit trou ou tiens le fichier en entier.
 
- la notion de plus grand trou disponible, elle va disjonter si plusieurs fichiers réclament en même temps de quoi s'écrire. On leur donne quoi dans ce cas ?
 
Je pense que l'idée de base est là, mais l'algo doit être plus tordu que ça.

- Le FS ne connait pas la taille du fichier avant de l'écrire, donc il ne peut sélectionner le plus petit trou ou tiens le fichier en entier.
C'est à ça que sert le write back. Tu peux aussi garder de la place après le fichier au cas où il s'agrandisse.
 
- la notion de plus grand trou disponible, elle va disjonter si plusieurs fichiers réclament en même temps de quoi s'écrire. On leur donne quoi dans ce cas ?
C'est là qu'on s'arrache les cheveux...

Ca oui, certainement, c'est simplifié!! Dans nos cours, c'était beaucoup plus complexe, mais je m'en souviens pas en détail, c'était y'a longtemps!!  
Mais sinon, je vois pas pourquoi tu dis que le FS ne connaît pas la taille du fichier avant de l'écrire?? Pour les fichiers "éditables" donc, dont la taille peut changer, d'accord, mais sinon, pour un exécutable, par exemple, ben...je vois pas pourquoi il la connaîtrait pas??
Sinon, pour les accès concurrents, y'a sans doute un mécanisme d'exclusion mutuelle qui fait que deux écritures n'ont jamais lieu exactement en même temps....Déjà, si tu as un disque avec un seul plateau, ben ça me paraît compliqué...Enfin...t'as raison, ça demande plus d'approfondissement, c't'histoire!!

Mais sinon, je vois pas pourquoi tu dis que le FS ne connaît pas la taille du fichier avant de l'écrire?? Pour les fichiers "éditables" donc, dont la taille peut changer, d'accord, mais sinon, pour un exécutable, par exemple, ben...je vois pas pourquoi il la connaîtrait pas??
 
Par ce qu'on parle du moment ou on écrit sur le disque. L'exécutable est écrit lors de la compilation, et au moment ou je lance le link, je sais pas combien il va fairte au final.
 
Sinon, pour les accès concurrents, y'a sans doute un mécanisme d'exclusion mutuelle qui fait que deux écritures n'ont jamais lieu exactement en même temps....Déjà, si tu as un disque avec un seul plateau, ben ça me paraît compliqué...Enfin...t'as raison, ça demande plus d'approfondissement, c't'histoire!!
 
Le noyau  est farci aux mutex. C'est pas à ça que je pensais.  
soir un espace libre :
 
[................................]
 
Je veux écrire un premier fichier, je le met au début, avec un espace derrière au cas ou (le writeback) :
[AAAAAWWW........................]
 
Pendant que je l'écrit, une seconde demande arrive, pour un B. Je le met juste après le write-back, ou je le met plus loin pour limiter les risques de fragmentation ?
 
[AAAAAAAAWWWWBBBBBBWWWWWW........]
ou
[AAAAAAAAWWWW......BBBBBWWWWW....]
 
Question con, on en parle dans le livre sur le noyau linusque de chez oreilly ? Je sens que je vais m'acheter de la lecture si c'est le cas

Je ne suis pas très au fait de ce genre de choses, mais à mon avis, l'écriture sur disque est une opération atomique à la base, donc quand quelque chose va être écrit, le système place un sémaphore pour empêcher quelqu'un d'autre d'écrire, le programme écrit ce qu'il faut, les infos de taille et de place sont mises à jour, et le sémaphore est libéré pour permettre à quelmqu'un d'autre d'écrire. Ce n'est pas spécialement compliqué. Mais ce n'est peut-être pas spécialement performant non plus, il y a peut-être d'autres méthodes sur lesquelles on peut effectivement s'arracher les cheveux.
De toutes façons, je m'en fous, j'en ai presque plus, de cheveux

Bah tiens, y'a mmenal qui a laché des URL sur la gestion de la fragmentation pour ext2, je les remet là :
 
http://salamis.emu.edu.tr/document/sag/node49.html
http://web.mit.edu/tytso/www/linux/ext2intro.html
http://www.linuxplanet.com/linuxpl [...] ls/3174/8/ section 7.3

hum... je suis atterri ici par hasard au gré de mes fulminations envers les imbéciles qui prétendent qu'une défragmentation nuit à la durré de vie d'un HD, passons.
 
J'ai lu l'article de Di Cosmo... ET IL EST TRES INCOMPLET! dans son article, visiblement orienté pro-linux, il ne fait allusion qu'a la fragmentation externe, la première à apparaitre, mais aussi la plus facile à traiter. Non seulement cette fragmentation n'a d'impact réel sur les perf d'un systeme que lorsqu'elle est TRES répendue, mais aussi lorsqu'elle s'attaque aux fichiers courramment utilisé, soit les fichiers systèmes, qui sont censé ne pas bouger trop souvent de place (a moins de réinstaller 15 fois son système par dessus un ancien...).
 
Par contre, il oublie totalement la fragmentation INTERNE, et son role autrement plus important dans les perfs, ainsi que l'acces à la Table of Content, ou FAT, ou tout autre nom qui vous plaise. De plus, il s'est bien gardé de parler de windows NT, qui existait déja à l'époque de son article et qui utilise le NTFS qui ne fonctionne pas du tout comme la FAT16 et son principe de "first fit", et souffre plutot de fragmentation interne, tout comme les FS de type unix comme le fameux ext2, tellement apprécié à l'époque.
 
Si la fragmentation interne arrive bien plus lentement, une fois qu'elle est la, non seulement, il est bien plus difficil de la réguler (car intimement liée à la taille des clusters), mais les dégradations de perf sont bien plus importantes. Heureusement, à l'heure actuelle, on peut remédier assez bien à ce type de fragmentation (qui fut dans un premier temps nié par microsoft et des partisans de Unix). Le problème actuel porte plutot sur le choix d'une défragmentation en temps réel transparente, ce qui dégrade les perf en cas de longs traitements, ou une défragmentation a interval régulier, ce qui immobilise la machine pendant 1 ou 2 heures.
 
Enfin, reste l'acces aux fichier via la TOC. Et c'est LA que se joue principalement la différence. De nouveau, 2 grandes écoles s'affrontent, chacune avec leur variances, leurs points faibles et leurs points forts. D'un coté, les FS à cluster fixe, de l'autre les FS à cluster dynamique. Les clusters fixes sont les plus répendu car plus facil à implémenter, de taille prédéterminée et aux performances golbalement correctes. Je ne pourrais pas vous dire quelle implémentation de ce type de FS est la meilleur, je ne me suis jamais penché dessus. Ce type de FS a comme atout un accès quasi immédiat à tout type de fichier (on limite généralement le nombre de redirection à 4), mais est nettement plus facilement sujet à une fragmentation interne.
De l'autre coté, les systèmes à clusters dynamique, eux n'ont presque pas de fragmentation interne, voir pas du tout dans les cas les plus poussés, mais à quel prix! au prix d'un acces aux fichier nettement plus lent pour des traitements courrant, au prix d'une gestion de la TOC dynamique qui nécessite un réajustement constant pour rester efficace, et d'une place de celle-ci très variable. Dans un autre poste par exemple, quelqu'un a lancé fièrement que son système à base de reiser ne se fragmentait pas, c'est totalement faux, il est défragmenté en permanence, non seulement contre la fragmentation externe, mais en plus, contre une forme de fragmentation propre à ce type même de structure, la fragmentation de la TOC! Et ce pour des performances qui ne se révèlent intéressantes que dans le cas de calculs scientifiques poussés nécessitant le traitement de TRES nombreux fichiers (perso je bosse pas pour la nasa, et vous?)
 
 
Voila, tout cela pour dire que la gestion d'un FS est bien plus complexe que certains on l'air de se l'imaginer ici et sur S&R.

 
ça marque TOC edit sur mon Mini Disc quand j'écris une compil, ça veut dire la meme chose ?
ça veut dire quoi TOC ?
 

TOC = Table Of Contents si ma mémoire est bonne.
 
Et j'allais faire la meme remarque a propos de la fragmentation interne...
 
Prenez un fichier extremement bien rangé, style la lettre que vous avez commencé a rédiger pour moman et ses 50 ans.
 
Vous m'avez rédigé qu'a moitié, par flemme ou manque de temps ( maman est un peu gateuse... ).
 
Vous l'avez enregistrée.
 
Et par manque de bol, le FS l'a placée a un endroit ou il y a JUSTE la place pour le fichier.
 
Pas un tiroir vide avant, pas un tiroir vide apres.
 
Tout content, un beau soir que vous trouvez fort zouli (n'est ce pas), vous reprenez votre lettre avec votre éditeur favori ( Emacs bien entendu ) et vous la terminez.
 
Et vous l'enregistrer...
 
La secrétaire décrite par le gars la bas va etre bien dans la merde pour mettre le reste du fichier dans des tiroirs vides APRES le début de la lettre : y en a pas, c bien simple.
 
Elle va donc foutre ce qu'elle peut dans le dernier tiroir et le reste de la lettre dans un autre endroit.
 
D'ou fragmentation.
 
J'ai bien envie d'expliquer ca  a notre ami intégriste, qui si il est prof d'université ca lui donne pas plus d'intéret a mes yeux.

Ouais, Di Cosmo, il abuse un peu, mais son article date de la grande époque du début du procès Microsoft, au moment où on avait vu, m^eme au JT de TF1, les mecs qui squattaient devant chez Microsoft pour se faire rembourser Windows...Alors forcément, à l'époque, c'était de bon ton, et dans l'air du temps (d'ailleurs, vous noterez qu'il est pas fait allusion à Windows > 95 dans son article, pour la bonne raison que c'était pas sorti)
 
Ouala..

Merci les gars c cool
LINUX C TROP COOOOOOOOOOOOOOOOOOOOOOOOOOOOOL
WIN  C DE LA MEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEERDE

oui enfin je suis asser septique parcque NT4 disait la même chose ; et resultat apres un speeddisk , kan tu voit la gueulle du disk , tu pleure tellement il etait fragmenté !...  
 
Apres C sur ke ca depent de l'utilisation ke tu F de tont PC ...
(si tu passe ton temps a jouter/supprimer etc ...)