Répondre à la discussion
Affichage des résultats 1 à 7 sur 7

defragmentation



  1. #1
    alaink
    Bonsoir a tous!

    Voila, j'ai encore lancé l'utilitaire de defragmentation de mes disques durs sous windows XP.

    Je le fait en moyenne tous les deux ou trois mois quand ma machine "rame" trop et c'est generalement efficace.

    J'ai entendu dire que les machines sous Unix ne rencontraient pas autant de problemes de fragmentation.


    Est-ce vrai? Si oui, a quoi est due la difference? Pourquoi windows qui en est a la Nieme version n'utilise pas la meme techno?

    De plus, si j'ai bien compris le phenomene a l'origine de la fragmentation des donnees (cycles lecture/ecriture/effacement de donnees dans un espace memoire limite), il devrait se produire aussi en memoire vive avec des effets sur les performances tout aussi notables. Est-ce le cas? Comment contourner le probleme?

    -----

  2. Publicité
  3. #2
    Mouquiette
    On va prendre ton message dans l'autre sens : Seul les systemes FAT et NTFS se fragmente. Cela vient en partie d'une mauvaise conception de ces systemes de fichiers. On va faire un petit exemple pour illustrer comment marche les 2 systemes :

    FAT & NTFS :
    Soit un tirroir, avec pleins de dossiers. Quand un nouveau fichier est a mettre dans le tiroir, la secretaire (une fénéante de premiere ) cherche le trou le plus proche possible du début du tirroir. Si elle a pas la place, elle découpe son fichier, met ce qu'il faut pour remplir le trou, puis recommence ca recherche. Elle note ensuite dans un calepin les endroits ou trouver le dossier.

    Autres :
    Soit un tirroir, avec pleins de dossiers. Quand un nouveau fichier est a mettre dans le tiroir, la secretaire (cette fois ci plus intelligente ) cherche le premier trou qui pourrait contenir son dossier, et parfois tente d'estimer si elle pourrait pas en trouver de taille inférieur mais suffisante. Bien entendu, elle note tout ca sur son calepin.

    Résultat du rangement : la premiere, ca a été rapide, mais c'est le bordel (donc long pour resortir le dossier ultra urgent), la seconde, ca a été (un peu mais pas bcp) plus long, avec un traitement très propre, donc très rapide pour sortir le meme dossier

    Donc pour conclure : un disque idéal sous win : début plein sans trou, fin vide, sous les autres, un disque rempli de facon homogène.

    PS : pour la RAM c'est la meme chose, je referrais pas d'exemple

  4. #3
    JPL
    Le système FAT hérité du DOS et même le système NTFS apparu avec Windows NT héritent d'une époque où il fallait économiser de la place sur des disquettes et des disques trop petits : donc ils fractionnent les fichiers pour utiliser tous les espaces libres aussi petits soient ils. Un système comme Linux recherche un espace suffisant pour que le fichier soit enregistré d'un seul tenant. Cela peut aboutir à un certain gaspillage de place, mais avec les disques actuels ce n'est pas un problème. Mouquiette se fera sans doute un plaisir d'expliquer comment Linux optimise l'utilisation des plages libres.
    Pour la mémoire, c'est exact, il y a des problèmes de fragmentation. Je crois qu'il y a des routines d'optimisation qui sont plus ou moins efficaces selon les systèmes d'exploitation, mais ce n'est pas de mon domaine de compétence et je lance un appel pour avoir des infos sur la question.
    Merci par avance.
    Rien ne sert de penser, il faut réfléchir avant - Pierre Dac

  5. #4
    Mouquiette
    Eh eh en retard

    Juste comme ca, les systeme de fichiers des anciens Unix (donc bien avant MS) n'était pas fragmenté ou très peu.

  6. #5
    alaink
    Y a t-il la meme difference entre Unix et windows pour la fragmentation de la memoire vive?

    L'OS realise t-il regulierement des defragmentations de la memoire RAM?

  7. A voir en vidéo sur Futura
  8. #6
    Mouquiette
    Je sais que sous linux, il défragmente pas la mémoire (mais il ne la fragmente pas non plus ) Alors que windows ne la défragmente pas mais la fragmente ...

    Linux utilise 100% de ta RAM alors que windows bcp moins.

    Ex :
    Je lances OpenOffice sous linux le matin avant d'aller en cours. Je le ferme. 6h plus tard, s'il linux n'a pas eu besoin de vider la RAM (ie il en restait suffisament de libre a chaque allocation), j'aurais toujours OOo en cache dans la RAM. Sous windows, il fait des purges automatiques, donc OOo sera plus long à relancer sous win que sous linux.
    D'ailleurs, c'est pour ca que j'ai en permance au moins 700Mo de RAM occupé sous linux (chose qui ferait hurler n'importe quel windosien qui vide sa RAM des que le PC en utilise plus de 200Mo )

  9. Publicité
  10. #7
    JPL
    Eh eh en retard
    Je sais.
    Juste comme ca, les systeme de fichiers des anciens Unix (donc bien avant MS) n'était pas fragmenté ou très peu.
    Oui, mais les anciens Unix fonctionnaient sur ce qu'on appelait des mini-ordinateurs, puis sur des stations de travail dont la taille des disques était sans comparaison avec ceux qui ont été utilisés sur les micro pendant longtemps. Cela explique pourquoi les deux familles de système ont hérité de caractéristiques si différentes. Et c'est vrai que maintenant, c'est un peu galère de traîner ça avec Windows.
    Rien ne sert de penser, il faut réfléchir avant - Pierre Dac

Sur le même thème :

Discussions similaires

  1. logiciel de défragmentation ??
    Par denisenee dans le forum Logiciel - Software - Open Source
    Réponses: 18
    Dernier message: 07/02/2007, 09h45
  2. Probleme de défragmentation
    Par poetic_boy972 dans le forum Matériel - Hardware
    Réponses: 2
    Dernier message: 18/06/2006, 22h49
  3. Défragmentation
    Par dans le forum Logiciel - Software - Open Source
    Réponses: 24
    Dernier message: 05/08/2005, 14h49
  4. pb de defragmentation
    Par Tomzack dans le forum Logiciel - Software - Open Source
    Réponses: 22
    Dernier message: 16/01/2004, 10h37
  5. défragmentation
    Par bela dans le forum Logiciel - Software - Open Source
    Réponses: 8
    Dernier message: 30/12/2003, 00h35
Découvrez nos comparatifs produits sur l'informatique et les technologies.