Un mythe s'effondre, c'est faux !
J'ai une partition formatée en ext3fs avec 21% de « non-contiguous blocks », et qui du coup se traîne à 25% de ses performances habituelles, qui se sont écroulées à un vulgaire 2,5 Mo/s pour du UDMA100 bien configuré (ie DMA activé, etc.)
Mes recherches sur google m'ont prouvé que la fragmentation existe bel et bien sur les différents systèmes de fichiers existants sous Linux, il existe même des utilitaires, tels la commande defrag, pour pallier au problème.
Apparemment, la fragmentation touche principalement l'une de mes partitions sur laquelle aMule écrivait ses données en permanence, et qui était quasi-pleine ces derniers temps. Mais une autre partition qui ne servait à rien d'autre si ce n'est y stocker de gros fichiers de temps en temps, et qui affiche elle aussi pas loin de 20% de non-contiguous blocks. Il est vrai qu'elle aussi avait tendance à être bien pleine.
Cela dit, la partition qui semble être la moins fragmentée, mon /home, affiche quand même pas loin de 5% de blocks non-contigus. À comparer aux 2 ou 3% de taux de fragmentation que j'ai l'habitude d'avoir sur mes PC sous Windows XP (sur lesquels je n'ai jamais défragmenté quoi que ce soit).
Il semblerait cependant que ce problème de fragmentation n'affecte principalement que les disques durs presque pleins (en général, en dessous de 80% de remplissage, pas de problème). Le problème, c'est qu'une fois fragmenté, il n'y a quasiment aucune solution pour s'en sortir ! Ainsi, on peut lire un conseil sur newsforge qui consiste à sauvegarder l'intégralité de la partition, la reformater, et y redescendre ensuite les fichiers sauvegardés. Sacrément long, et pas très logique.
Voilà, c'était la minute coup de gueule, parce que je vais probablement devoir réinstaller ma machine, qui du fait de cette fragmentation, de la lenteur du système engendré, et autre, m'occasionne bien des soucis. Du coup, je vais en profiter pour essayer autre chose qu'ext3fs, vu que je râlais dessus dans un autre journal, suite à de multiples pertes de données avec.
Au passage, mon petit dossier comparatif sur quelques distributions linux et Windows XP avance, publication prochaine en vue ! ;-)
Bonne nuit !
Journal Fait n°1 : Linux n'est pas sujet à la fragmentation...
7
déc.
2005
# Mouah
Posté par farib . Évalué à 10.
# Pas besoin de réinstaller...
Posté par Mathieu Pillard (site web personnel) . Évalué à 10.
Ca dépend evidemment beaucoup du filesystem, et de l'utilisation que tu en as (d'ou l'interet de séparer ses partitions selon ce que tu fais dessus par exemple). Ré-installer me semble un peu beaucoup, tu as divers outils pour t'en sortir (et sauvegarder l'ensemble pour le remettre est au contraire tres logique, sinon, ya aussi convertfs par exemple pour en profiter pour passer a autre chose). Si tu veux des détails sur l'histoire, et une solution potentielle, c'est orienté reiserfs mais tu peux, tu dois lire meme:
http://www.00f.net/php/show-article.php/fragmentation_of_uni(...)
# Fait n˚2 : être un peu plus précis...
Posté par aurel . Évalué à 10.
La partition /home (ext3) de mon laptop (35Go) est pleine a 92%, j'ai 2.1% de "non-contigous blocks", alors que cette partition travaille beaucoup et gère des fichiers plus gros que l'espace disque restant. La performance du système de fichier variant suivant la taille des fichiers, je mesure la performance par la vitesse de lecture par hdparm. Et j'observe 30Mo/s. Je précise que c'est un disque 5400rpm de laptop. Cette machine a été installée sous Fedora Core 4 il y a 6 mois sans réglage particulier.
La partition /home (ext3 aussi) d'un des serveurs que j'ai en exploitation est pleine à 92% elle aussi, pour une taille totale de 459Go, avec des fichiers de plus de 10Go. J'ai 1.0% de non-contigous blocks là aussi. et une vitesse de 81Mo/s en lecture (hdparm tjrs). Cette machine est en production depuis 2 ans et demi environ, allumée 24h/24h. Pas de réglage particulier particulier non plus, tout tourne sous Fedora Core 1.
Donc tu as raison : tu as un souci. Mais je ne crois pas que ce sois linux, mais peut-être plutôt un problème spécifique à ton système, ou alors simplement une conséquence du fait que tu as une multitude de petit fichiers sur cette partition.
Au choix :
- tu continues tes calomnies ?
- tu attends des conseils pour résoudre ton problème, et si oui, les premières questions sont "quelle format pour ta partition ?" puis "comment as-tu mesuré le 25% de ses perfs et le 2.5Mo/s dont tu parles" ?
Ce que tu dis ressemble à quelqu'un qui découvre linux et qui lui tape dessus sans savoir de quoi il parle. Je ne dit pas que c'est le cas, mais que ca y ressemble :)
[^] # Re: Fait n˚2 : être un peu plus précis...
Posté par Frédéric COIFFIER . Évalué à 9.
Si c'est le disque dur, il n'y aucune raison que les performances du disque baissent (de même que la lecture en cache, etc...) quelque soit la fragmentation du disque.
Par contre, si c'est le file system, effectivement, il a un problème.
[^] # Re: Fait n˚2 : être un peu plus précis...
Posté par galactikboulay . Évalué à 10.
par le filesystem. Donc c'est totalement inadapté pour mesure la
perte de performance due à la fragmentation.
[^] # Re: Fait n˚2 : être un peu plus précis...
Posté par Sebastien Binet . Évalué à 0.
Donc si, c'est utile :)
[^] # Re: Fait n˚2 : être un peu plus précis...
Posté par aurel . Évalué à 1.
[^] # Re: Fait n˚2 : être un peu plus précis...
Posté par Bruno Muller . Évalué à 2.
- Pour faire des benchs de fs, on peut par exemple utiliser bonnie++ : http://www.coker.com.au/bonnie++/
[^] # Re: Fait n˚2 : être un peu plus précis...
Posté par Volnai . Évalué à 0.
Bah c'est beaucoup. C'est quoi tes disques ??
[^] # Re: Fait n˚2 : être un peu plus précis...
Posté par aurel . Évalué à 2.
# Un mythe, vraiment ?
Posté par abgech . Évalué à 10.
Pour retrouver des SF n'ayant aucune fragmentation, il faut revenir aux années 1970 et au SE OS/VS d'IBM. Ce SF utilisait des unités d'allocations de taille et d'implantation physique fixes (allocation dite contiguëe) déterminées à la création du fichier. Mais quelle joie pour l'administrateur système de savoir où implanter un fichier (en terme de cylindre-piste) dans une installation qui pouvait comporter plusieurs milliers de fichier ! Et cette absence de fragmentation se payait par la nécessité de connaître, au moment de la création du fichier, la taille maximum que celui-ci pouvait atteindre. On imagine aisément le gaspillage de place disque, surtout à l'époque où une capacité de 128 Mo sur disque était considérée comme le summum du confort. Mais il y avait, pour les grandes installations, des batteries impressionnantes d'unités de disques.
S'il est vrai que la quasi totalité des SF actuels (à ma connaissance et en dehors des SF temps réels devant répondre à des spécifications rigoureuses en terme de temps d'accès disque) travaillent en allocation chaînée (FAT en est une variante dégénérée) ou en allocation indexée (cas de Linux). Ces types d'allocations souffrent, intrinséquement, de fragmentation.
Maintenant reste à voir l'effet de cette fragmentation sur l'efficacité du traitement:
- Sous Windows (et ses dérivés / clones), les lectures / écritures se font selon l'organisation LOGIQUE des données, indépendamment de leurs positions PHYSIQUES sur le disque. Dès lors, il s'ensuit de nombreux déplacement des têtes d'accès en cas d'un taux de fragmentation relativement grand.
Il existe bien un tampon, dont on peut se demander à quoi il sert d'ailleurs. D'ailleurs, si je me souviens bien (mes dernières utilisation de Windows remontent à plusieurs années), si l'on augmente la taille du tampon a cela d'une certaine limite, les performances diminuent, un effet "marrant" qui fait se "bidonner" les spécialiste des SE.
- Sous Linux (Unix et ses dérivés / clones), les lectures / écritures se font selon l'organisation PHYSIQUE des données à partir du tampon. Dès lors, les déplacement des têtes d'accès sont limités drastiquement.
C'est, en fait, un peu plus complexe avec les disques de grande capacité. En effet, à cause de certaines restrictions du BIOS (adresse en cyl-track-sector avec nombre de bits limités), la géométrie physique que "voit" le SE n'a que peut de rapport avec la géométrie physique effective des disques et cela tant que l'adressage se fera en termes absolus (cyl-track-sector) et non pas en terme relatifs (origine+déplacement notés en nombre de secteurs ou, mieux, en nombre de blocs de taille modifiable).
Au surplus, sous Linux, l'allocation d'un nouveau bloc disque à un fichier se fait selon un algorithme qui tend à minimiser la distance physique de ce bloc des autres blocs du fichier.
Par contre, il est parfaitement vrai que cet algorithme perd de son efficacité avec l'augmentation du taux de remplissage du disque (plus difficile de trouver un bloc, ou un ensemble de blocs, contiguës !).
Si, par ailleurs, la taille du tampon est réduite, l'optimisation des déplacements se fera sur un nombre de blocs plus petit et sera par conséquent moins efficace. À la limite, pour un tampon d'un seul bloc, on se trouve ramené au cas de la mise à jour en ordre logique.
Sous Linux, la taille du tampon est automatiquement ajustée en fonction des processus en mémoire.
Donc, sous Linux, mémoire physique relativement faible, nombreux processus actifs, disque presque plein se conjuguent pour diminuer l'efficacité. Mais, amha, ce sont des conditions limites, qui impliquent (si les moyens financiers le permettent) achat de mémoire et / ou de disques.
Et se sont des conditions qui, sous Windows, plantent totalement le système.
# Autre chose, oui mais quoi ?
Posté par Édouard Geuten (site web personnel) . Évalué à 2.
parcqu'il me semble me rapeller (mais peut-être me gourais-je) certain bench ou ext3 étais clairement le plus rapide en fait.
AU fait quelqu'un sait si le "nouveau" ZFS de Sun sera supporté sous GNU/Linux ?
[^] # Re: Autre chose, oui mais quoi ?
Posté par un_brice (site web personnel) . Évalué à 3.
[^] # Re: Autre chose, oui mais quoi ?
Posté par Prosper . Évalué à 2.
[^] # Re: Autre chose, oui mais quoi ?
Posté par Thomas Maurin (site web personnel) . Évalué à 0.
[^] # Re: Autre chose, oui mais quoi ?
Posté par hommelix . Évalué à 2.
Oui il y a une certaine epoque, mais il evolue. Certains le jugent meme meilleure desormais que d'autre.
Pour jouer un peu avec, tu peux faire un tour la bas :
http://changelog.complete.org/node/400
# Avant toute chose, il faut se renseigner...
Posté par Olivier (site web personnel) . Évalué à 10.
La raison pour laquelle les partitions ext2/3 ne fragmentent pas, ou peu, c'est qu'elles gardent en mémoire sur le disque dur, une table indiquant la taille des blocs libres. Ainsi, lorsque l'OS veut écrire un fichier, il choisit le bloc de la plus petite taille possible et qui peut contenir le fichier en un seul morceau. En comparaison, les FAT12/16/32 de Windows n'ont pas ce type de mécanisme (et pour NTFS, je ne sais pas).
Avec un DD presque plein en permanence, surtout contenant des fichiers de grosse taille (j'imagine que ton aMule ne fait que télécharger des images ISO de distributions Linux, au format CD ou DVD...), il ne peut rester comme place sur le disque que des blocs éparses. Donc forcément le FS se fragmente lorsque tu veux rajouter des données, car il ne peut pas trouver un emplacement continue de 700Mo ou 4.7Go.
De plus, aMule (et les autres softs de P2P) amplifie le phénomène de fragmentation, car ils stockent initialement les fichiers téléchargés sous la forme de petits blocs, téléchargés indépendament sur Internet (je suppose par la que tu commences toujours par télécharger des images ISO de distributions Linux, et que tu n'en mets donc pas "spontanement" en partage). Si tu télécharges plusieurs fichiers en parallèle, tu aura donc une partie de ton DD qui sera composé de multiples petits fichiers temporaires
Une fois que qu'une image ISO sera coomplètement téléchargée, *Mule recréera un fichier unique, là où il y a de la place. Et comme ton DD est plein, ce sera à l'emplacement d'anciens petits blocs temporaires
Si tu utilisais un *Mule sous Windows, tu verrais exactement le même phénomène.
Quand à ceci :
Ainsi, on peut lire un conseil sur newsforge qui consiste à sauvegarder l'intégralité de la partition, la reformater, et y redescendre ensuite les fichiers sauvegardés. Sacrément long, et pas très logique
Le "pas très logique" confirme bien que tu ne comprends pas le phénomène de fragmentation. C'est pourtant le seul moyen de ne pas fragmenter un DD, lorsque l'on n'utilise pas un soft qui manipule directement le FS au niveau des blocs (donc un soft de defragmentation)
Au passage, mon petit dossier comparatif sur quelques distributions linux et Windows XP avance, publication prochaine en vue ! ;-)
Au vu de tes journaux, et de ton niveau de connaissances techniques de Linux (je ne parle pas d'experiences, ou d'experimentations), les trollometres vont exploser...
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par Maz (site web personnel) . Évalué à 3.
Euh, je connais pas bien le fonctionnement exact des logiciels qui utilisent le réseau edonkey, ni trop bittorrent, mais justement, il me semble que les 2 créent initialement le fichier complet, mais vide, et le remplisse petit à petit.
Au contraire de WhiteWater, par exemple, qui stocke chaque petit bout, et qui reconstruit le fichier après.
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par Rin Jin (site web personnel) . Évalué à 3.
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Jouer un peu avec l'option "seek" de "du" permet de comprendre un peu ce qu'il se passe.
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par GCN (site web personnel) . Évalué à 2.
Une fois le fichier récupéré, il mouline pour remettre tous les morceaux dans le bon ordre est crée le fichier définitif dans Incoming.
Une bonne grosse source de fragmentation ça :). D'où l'intérêt, AMHA, d'avoir une partoche spécialement dédiée à *Mule (avec un système basé sur LVM ou équivalent, c'est très simple à faire après coup).
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par DPhil (site web personnel) . Évalué à 1.
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par briaeros007 . Évalué à 4.
Exemple avec azureus , peut choisir quel type d'allocation on veut :
allocation dynamique (un fichier qui augmente au fur et a mesure de taille)
une allocation statique( avec une intialisation en le remplissan de 0 meme si on veut éviter la fragmentation)...
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par B16F4RV4RD1N . Évalué à 2.
c'est vrai que c'est ennuyeux cela, lorsque par exemple on télécharge par P2P en même temps la dernière Fedora, la dernière Knoppix, Ubuntu, SuSE, les 9 iso de Debian, les DVD de Solaris, les iso de Slackware, Mandriva etc.... cela en fait un paquet de place alloué sur le système rien que pour ces films iso...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par M . Évalué à 2.
Il y a un test marrant a faire avec dd :
lancer 5/10 dd if=/dev/urandom of=$i count=$x en parallele, puis regarder le taux de fragmentation...
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par Thomas Douillard . Évalué à 3.
Il me semble que cette stratégie (best fit) est au contraire très mauvaise, car elle laisse des tous petits blocs si le fichier est trop petit pour remplir le bloc libre.
La meilleure stratégie si je me souviens bien de mes cours était au contraire "worst fit" (on choisit le plus grand bloc libre et on y met le fichier au bout).
Après il y a surement des trucs plus élaborés, mais worst-fit était meilleure que best-fit.
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par nicodache . Évalué à 3.
[^] # Re: Avant toute chose, il faut se renseigner...
Posté par Franck LUDJET . Évalué à 1.
Sous un SE il faut avoir conscience qu'il faut agir des qu'il ne reste plus que 20% d'espace libre sur une partition qui a tendance à se remplire ;-)
La fragmentation et lié au manque d'espace dans 90% des cas et celui-ci doit s'anticipé !
J'ai eu ce problème une fois plus d'espace sur une partoche
solution :
Ajout d'un disque : ce coup si, j'ai fait un LVM (taille variable) sur ce disque
redémarré en mode single user copié les fichiers sur la nouvelle partition
modification du fstab pour monter la nouvelle partoche à la place de l'ancienne
et c'est reparti ! J'avais mal évalué la taille de cette partition.
elle hébergé les mailbox de mon serveur de messagerie
(certains utlisateurs n'allé jamais retirer leur mail, soit plus de 100000 mails
et allé supprimé 15000 mails sur un compte malgrès une liaison 100Mb devien un parcours du combattant.
sur un compte je l'ai tenté celà à pris 1 journée
(temps de rappatriment sur outlook express, de suppression et vidage corbeille)
# apt-get install defrag
Posté par Ben (site web personnel) . Évalué à 6.
ext1/ext2 (donc ext3) et minix sont supportés.
si tu n'as pas debian ou ubuntu, va ici:
http://linux.maruhn.com/sec/defrag.html
ceci dit, je n'ai pas testé, donclis la man page et vérifie si tu doit sauvegarder tes données..
Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie
# Trop d'extinctions sauvages ?
Posté par Zorro (site web personnel) . Évalué à 2.
# Complément d'info?
Posté par fmaz fmaz . Évalué à 2.
donc que je répète ce qui a déjà été dis.
Avec une partition FAT, quand tu écris un fichier, il est collé au
le plus possible au début du disque. Résultat, même si tu
utilise 10% de ton disque et qu'il y a plein de place, si tu as plein
de petits trous au début de ton disque, ça fragmente pour
remplir tous les trous.
La plupart des système de fichiers un minimum raisonnables
commencent par essayer de caser le fichier sans essayer de
le frangmenter, ce qui semble quand même raisonnable.
J'avais lu un article qui démontrait (avec des vrais maths et tout
et tout) que si un disque était rempli au plus aux 2/3 et que les
fichiers avaient une taille « raisonnable » (je ne me souviens plus
des détails), alors le disque avait tendance à ce défragmenter
tout seul. En gros il se peux qu'on fragmente mais ça n'arrive pas
trop souvent et comme on efface aussi des fichiers, on efface
aussi des fichiers fragmentés.
Donc, effectivement, si tu remplis ton disque à 99%, alors ça va
fragmenter. Ce n'est pas pour autant une raison pour se dire,
puisse que de toute façon, ça fragmente, je reste avec mes
partitions FAT.
# Comment ?
Posté par Thomas Maurin (site web personnel) . Évalué à 3.
Parce qu'un ext3fsck/reiserfsck/... ne donne pas cette info
[^] # Re: Comment ?
Posté par inico (site web personnel) . Évalué à 2.
[^] # Re: Comment ?
Posté par dawar (site web personnel) . Évalué à 2.
[^] # Re: Comment ?
Posté par rdg . Évalué à 1.
http://www.die.net/doc/linux/man/man8/filefrag.8.html
[^] # Re: Comment ?
Posté par tgl . Évalué à 4.
Ce nombre (disons N) est donc à comparer avec le nombre des blocks occupés par le fichier (disons M). Le ratio de fragmentation du fichier est donc à la louche un truc du genre (N-1)/(M-1).
D'où le petit script suivant pour faire plus joli :
% cat fragmentation.sh
#!/bin/bash
filesize=$(ls -s --block-size=4KB "${1}" | cut -d\ -f1)
if [[ ${filesize} -gt 1 ]] ; then
extents=$(/sbin/filefrag "${1}" | sed -n 's/.*: \([0-9]\+\) extents.*/\1/p')
fragmentation=$(bc <<<"scale=1;100*(${extents}-1)/${filesize}" )
else
# pas de division par zero...
extents=${filesize}
fragmentation=0
fi
echo "${1}: ${filesize} blocks, ${extents} extents, ${fragmentation}% fragmentation"
% sudo ./fragmentation.sh linux-2.6.14.tar.bz2
linux-2.6.14.tar.bz2: 9805 blocks, 492 extents, 5.0% fragmentation
Enfin, en espérant que j'ai pas tout compris de travers et que mon raisonnement n'est pas foireux :)
[^] # Re: Comment ?
Posté par tgl . Évalué à 2.
extents=$(/sbin/filefrag "${1}" | sed -n 's/.*: \([0-9]\+\) extent.*/\1/p')
# Réponse groupée
Posté par Anonyme . Évalué à 2.
Effectivement, je découvre :-)
Jusqu'à présent, je m'étais fié à un article de Roberto di Cosmo qui affirmait plus ou moins que sous Linux, la fragmentation n'existait pas.
La réinstallation est de toutes façons rendu nécessaire du fait que je traîne ma cooker depuis un bon moment, et qu'elle commence à craquer de partout ;-)
Pour le côté logique, certes, ça l'est, puisque la copie de fichier se fait de manière séquentielle et linéaire, cela va assurément copier les fichiers sans fragmentation. Mais quel boulot !
Comme signalé dans les commentaires à ta réponse, hdparm ne passe pas par le système de fichiers pour faire ses mesures. Personnellement, hdparm continue de m'annoncer un débit de 40 Mo/s, alors que sur copie de fichiers, ce débit est de l'ordre de 2,5 Mo/s à 5 Mo/s (et jusqu'à récemment encore, lorsque le disque était moins fragmenté, il était encore de 10 Mo/s). Je précise que le disque est sain, cela a été longuement vérifié.
J'aurais plutôt une multitude de gros fichiers sur cette partition.
Tout de suite les gros mots, il ne faut pas s'emporter parce que je souligne un fait, hein :-)
La partition est formatée en ext3fs, et avait tendance à n'avoir que quelques Mo de libre ces derniers temps (parfois moins d'1 Mo). Les 25% et 2,5 Mo sont le résultat d'une comparaison avec le système il y a encore quelques semaines et aujourd'hui, sur copie de fichiers (puisque je suis en train de faire mes sauvegardes intégrales, je m'en rend bien compte).
Effectivement, je découvre encore Linux, bien que cela fasse plus de 3 ans que je l'utilise exclusivement sur ma machine principale. Je dirais même que Linux est pour moi une découverte perpétuelle depuis que je l'utilise. Et certes, mes connaissances Linux ne sont pas encore à la hauteur de celles que j'ai sous Windows, bien que cela soit difficilement mesurable, mais on ne peut pas non plus être expert partout. ;-)
Roberto di Cosmo si, il me semble.
C'est un peu ce que j'ai constaté, et l'achat d'un nouveau disque dur est en prévision. Sinon, effectivement, un Windows sur un disque surchargé ne s'en sort pas mieux.
Personnellement, j'envisage Reiserfs, mais ça n'engage que moi et n'est basé sur rien de concrêt pour l'instant.
Le problème d'un benchmark, c'est qu'il ne mesure pas tout, mais juste une chose, dans des conditions particulières.
C'est d'ailleurs pour cela que je suis bête, et que j'ai émis les hypothèses de cette fragmentation dans mon journal. :-)
Ben figure toi que le fait que j'ai précisé que la partition était pleine et qu'un aMule tournait dessus n'était pas innocent hein... C'était justement pour montrer dans quel cas de figure cela c'était produit, et donner, à mon avis, la raison principale de cet état de fait.
Contrairement à ce que tu as l'air de croire, j'ai parfaitement compris la « logique » derrière la chose. Ce que je ne trouve pas très logique, c'est d'être obligé de faire ce genre de manips à la main, sans avoir un logiciel qui vient réorganiser les fichiers sur le disque. La commande defrag, que j'ai utilisée sur quelques fichiers, m'a semblé peu fiable, ne serait-ce que parce qu'elle semble ne pas accepter les fichiers contenant des caractères accentués dans leur nom.
Ça tombe bien au contraire, puisque le test concerne la prise en main par des débutants. Sinon, ce n'est pas moi qui ai noté les différentes distributions, mais 2 « assistantes sexys » ;-)
[^] # Re: Réponse groupée
Posté par novexz . Évalué à 4.
Est ce que tu parle de cet article là?
--->
http://membres.lycos.fr/conjonction/absurde/piegecyb.htm
Car c'est clairement un article de vulgarisation qui ne rentre pas dans tous les details. Et pourtant meme avec l'analogie de la secretaire tu te doute bien qu'avec un disque plein à 90% tu sera obligé de ranger les gros fichiers en divers endroit!
[^] # Re: Réponse groupée
Posté par abgech . Évalué à 1.
Il me semble que ce n'est pas très compliqué de faire un petit script appelé, comme par hasard, defrag du genre (en admettant, par exemple que ta partition à défragmenter soit sur /dev/hda4 et que tu veuille la transformer en Reiser FS):
cd /répertoire_de_ma_partition_merdique
cp -rdpf * /répertoire_d'une_partition_assez_grande
umount /répertoire_de_ma_partition_merdique
mkfs -t reiserfs /dev/hda4
mount /dev/hda4 /répertoire_de_ma_partition_merdique
cd /répertoire_d'une_partition_assez_grande
cp -rdpf * /répertoire_de_ma_partition_merdique
Aucune garantie quand à d'éventuelles erreurs dans le script ci-dessus, donné juste comme exemple de ce que l'on peut faire.
Bien sûr, à exécuter sous root, alors essaie de faire attention à ce que tu fais.
Si tu parles de cet article:
Moi je lis:
... le disque est toujours très peu fragmenté et plus on l'utilise ...
Comme quoi di Cosmo semble être d'accord avec la plupart des intervenants (lol), le contraire m'aurait surpris. Linux minimise la fragmentation mais ne la supprime pas. La fragmentation tu l'auras toujours, comme je te l'ai dit plus haut, elle est intrinsèque aux systèmes de fichiers modernes. Mais des algorithmes un peu plus futés que d'autres en diminue grandement l'impact.
*humour*
Alors un conseil, puisque tu vas sortir pour acheter un HD, profites-en pour passer chez ton opticien, tu semble avoir besoin de lunettes pour lire convenablement les textes.
*/humour*
[^] # Re: Réponse groupée
Posté par Olivier Jeannet . Évalué à 3.
Il n'y en aurait pas une qui s'appellerait Marie, par hasard ? ;-)
(NB: ceci est une private joke pour les moules attentives :-)
[^] # Re: Réponse groupée
Posté par Anonyme . Évalué à 3.
Elle tient le rôle de la débutante totale à merveille d'ailleurs.
[^] # Re: Réponse groupée
Posté par herodiade . Évalué à 3.
On explique que certains logiciels de p2p (mldonkey fait ça, je ne sait pas trop pour aMule) font volontairement des gros fichiers "à trous" (aka "fragmentation").
Alors moi je trouve très bien que Linux (comme les autres systèmes POSIX en fait) permette de fseek()er comme un salop après la fin d'un fichier lorsque je (ou une appli) le souhaite, et surtout qu'il ne "defragmente" dans mon dos.
On dit souvent que Linux (sur ext3) (et les *BSD sur ffs et ufs2 d'ailleur) ne fragmente pas trop: il faut comprendre qu'il sait bien gérer les fichiers tout seul et se debrouille pour les aranger proprement, lorsqu'on ne lui donne pas de contre-directives à ce sujet.
Celà étant posé, il n'empêche pas la fragmentation intentionelle, volontaire, décidée par l'utilisateur, car elle peut être justifiée.
Bref, la conclusion de tout ce fil, c'est : "les applis de p2p sont de grosses cochonnes avides de ressources", rien de neuf, et pas de quoi fouetter un chat ...
# Mouahaha
Posté par gnumdk (site web personnel) . Évalué à 2.
>Windows XP
http://hibbert.univ-lille3.fr/~cbellegarde/Windows.png
Bah, ca doit être le 10 ieme serveur Windows que je trouve dans cet état la, alors me dire que du à 2 à 3 % de fichier fragmenté sous Windows Xp, ca me fait bien rire ;) Surtout quand Microsoft avoue que Windows fait acutellement n'importe quoi et que seul Windows Vista aura un comportement correcte vis à vis de la fragmentation(en l'évitant comme font tous les autres OS).
Enfin, un Windows qui fait serveur de fichier/auth, tu peux être sur que si tu ne défragmente pas régulierement, tu finieras par avoir un FS comme celui du shot et que à ce moment la, meme en mode sans echec, plus moyen de défragmenter...
# Ext3 + reservation
Posté par rdg . Évalué à 7.
Une option de montage "mount -o reservation" et zou c'est activé.
Ça permet en fait de preallouer une certaine quantité de memoire et de donc de block contigus lors de l'ecriture des données (même très petites).
En conséquence, les fragments de fichiers, si fragmentation il y a, sont de tailles suffisament conséquentes pour ne pas trop pénaliser les performances du système de fichier (y compris dans le cas de lectures /ecritures parallèles!!)
http://people.redhat.com/arjanv/reservations.png
A suivre de près aussi les travaux de Mingming Cao:
http://www.bullopensource.org/ext4/ext4_test_plan.html
[^] # Re: Ext3 + reservation
Posté par Bruno Muller . Évalué à 1.
# hdparm+copie
Posté par Guy Thiry . Évalué à 3.
moi, ça donne 60 MB/sec).
2. En fin de disque, il faut +/- diviser les performances par 2 (chez moi : 32 MB/sec).
3. Tu parles de copies (c'est à dire lecture+écriture). Je suppose qu'il s'agit de copies "mono-disque". Je fais fais souvent des copies mais jamais en mono-disque : c'est bien trop lent. J'ai déjà pu constater que des copies de disque à disque (chez moi sur deux controlleurs ide différent) vont (parfois) 8x plus vite que des copies mono-disque (et ça fait nettement moins de bruit).
4. Tu dis que tu "flirtes" avec moins d'1MB de libre : au prix du GB actuel, on
peut appeler cela de la gourmandise (tu aimes le risque ... un peu trop sans
doute).
5. Oui, il y a de la fragmentation sous Linux (quelques % chez tout le monde, sauf chez toi). Non, on ne passe pas son temps à défragmenter son FS (on le
calibre à ses besoins).
6. Achète-toi un disque externe usb (ou comme moi, récupère un disque IDE
qu'on peut placer dans un container usb) : ça coûte pas cher et ça évite des
trolleries.
J'attends avec impatience ton comparatif sur "quelques" distributions Linux
et Windows XP (et aussi Vista ?) : ça va troller sec !
PS: prends un peu de recul et n'oublie pas aussi les macs, les freebsd, ...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.