62.7% non contigus

Le
Luxpopuli Open source
Bonjour,

J'ai un disque dur externe en ext3 et la commande:

fsck -y /dev/sda1

me renvoie:

/dev/sda1 : 13069/61048832 fichiers (62.7% non contigus),
462232110/488384000 blocs

C'est tout de même beaucoup !
C'est la première fois que je vois un tel score en 15 ans.

Si je relance la commande, elle se termine immédiatement en me disant
que le disque est propre.

Ce média est un média de sauvegarde et ne comporte que des gros
fichiers de plusieurs 100aines de mega.

Ai-je une solution pour remédier à cette fragmentation intempestive .

Pascal
--
Linuxorable: création de sites web, cours d'informatique à domicile, d=
épannage,
http://linuxorable.fr
--
http://www.luxpopuli.fr - documentation de eZ Publish traduite en françai=
s

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
François Cerbelle
Le #16578751
Le Mar 19 août 2008 17:10, Luxpopuli Open source a écrit :
J'ai un disque dur externe en ext3 et la commande:
fsck -y /dev/sda1
me renvoie:
/dev/sda1 : 13069/61048832 fichiers (62.7% non contigus),
462232110/488384000 blocs
C'est tout de même beaucoup !
C'est la première fois que je vois un tel score en 15 ans.



Ton disque ne serait-il pas plein aux environ de 90% ? L'algo de gestion
des extends utilisé par ext, aussi bien soit-il, doit pouvoir être mis en
défaut. Si tu remplis ton disque de petits fichiers à la suite, que tu en
supprimes un sur deux, que tu le reremplis avec des fichiers un tout petit
peu plus gros que les précédents, et que tu recommences plusieurs fois
(c'est à peu pres l'idée d'un disque de sauvegarde), tu finis par avoir de
la fragmentation.

Si je relance la commande, elle se termine immédiatement en me disant
que le disque est propre.


Oui, ca n'a pas de rapport avec la cohérence du systeme de fichiers. Tu
peux toujours utiliser l'option "-f" pour forcer un fsck, mais ça ne
changera rien.

Ce média est un média de sauvegarde et ne comporte que des gros
fichiers de plusieurs 100aines de mega.
Ai-je une solution pour remédier à cette fragmentation intempestive .



Tu n'en as pas vraiment besoin, le temps d'accès n'a pas une grande
importance :
- c'est un disque de sauvegarde
- c'est un disque externe (USB, je suppose) et ce n'est pas la
fragmentation qui doit entraîner le plus grand ralentissement lors de
l'accès aux données, à mon avis, mais le bus USB.

Si tu y tiens absolument, je vois deux solutions :
- il existe un petit outil de defragmentation qui doit s'appeler e2defrag
(de mémoire), mais je ne sais pas s'il gère correctement le journal ext3
(a vérifier avant tout) ;
- Copier tes sauvegardes ailleurs, les supprimer du disque externe (apres
avoir vérifié qu'elles sont bien copiées) et les y replacer.

Mais je pense que, si mon hypothèse de début sur la gestion des extends
est bonne, ton utilisation de ce disque comme moyen de sauvegarde et que
ta stratégie de sauvegarde vont faire regrimper le taux de fragmentation.

A+
Francois Cerbelle

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Jean-Yves F. Barbier
Le #16578741
Luxpopuli Open source a écrit :
Bonjour,

J'ai un disque dur externe en ext3 et la commande:

fsck -y /dev/sda1

me renvoie:

/dev/sda1 : 13069/61048832 fichiers (62.7% non contigus),
462232110/488384000 blocs

C'est tout de même beaucoup !
C'est la première fois que je vois un tel score en 15 ans.

Si je relance la commande, elle se termine immédiatement en me disant
que le disque est propre.

Ce média est un média de sauvegarde et ne comporte que des gros
fichiers de plusieurs 100aines de mega.

Ai-je une solution pour remédier à cette fragmentation intempestive .



oui: lire les docs sur la structure d'ext2/ext3 pour comprendre que ça
n'a aucune importance.

JY
--
Some people seem to think that "damn" is God's last name.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Luxpopuli Open source
Le #16578881
Bonjour jean-Yves,

Les docs j'en ai lu quelques unes.

La vraie question que je me posais était:

A quoi est-ce du ?

Ensuite, entre ce que disent les docs et la pratique ou l'expérience
de certains, il peut y avoir des choses à apprendre.
En substance, les docs disent surtout qu'en théorie on ne dépasse
pratiquement jamais les quelques % de fragmentation. Ce qui jusqu'à
aujourd'hui est bien ce que j'ai toujours pu observer.
Jusqu'à aujourd'hui....

Pascal

Le 19 août 2008 17:18, Jean-Yves F. Barbier
Luxpopuli Open source a écrit :

Bonjour,

J'ai un disque dur externe en ext3 et la commande:

fsck -y /dev/sda1

me renvoie:

/dev/sda1 : 13069/61048832 fichiers (62.7% non contigus),
462232110/488384000 blocs

C'est tout de même beaucoup !
C'est la première fois que je vois un tel score en 15 ans.

Si je relance la commande, elle se termine immédiatement en me disant
que le disque est propre.

Ce média est un média de sauvegarde et ne comporte que des gros
fichiers de plusieurs 100aines de mega.

Ai-je une solution pour remédier à cette fragmentation intempestive .



oui: lire les docs sur la structure d'ext2/ext3 pour comprendre que ça
n'a aucune importance.

JY
--
Some people seem to think that "damn" is God's last name.






--
Linuxorable: création de sites web, cours d'informatique à domicile, d épannage,
http://linuxorable.fr
-----
http://www.luxpopuli.fr - documentation de eZ Publish traduite en françai s

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Jean-Yves F. Barbier
Le #16579471
Luxpopuli Open source a écrit :
Bonjour jean-Yves,

Les docs j'en ai lu quelques unes.

La vraie question que je me posais était:

A quoi est-ce du ?



François t'as donné la réponse

Ensuite, entre ce que disent les docs et la pratique ou l'expérience
de certains, il peut y avoir des choses à apprendre.
En substance, les docs disent surtout qu'en théorie on ne dépasse
pratiquement jamais les quelques % de fragmentation. Ce qui jusqu'à
aujourd'hui est bien ce que j'ai toujours pu observer.
Jusqu'à aujourd'hui....



la disposition des inodes sur le disque fait que même fragmenté fortement,
la lecture ne fait que peu déplacer les têtes (sauf cas extrèmes)

JY
--
In the eyes of my dog, I'm a man.
-- Martin Mull

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Luxpopuli Open source
Le #16579571
Bonjour François,

Merci pour tes explications claires.

Juste pour info, mon disque est en effet plein (100%).

Pourquoi le fait de faire une «réinstall» de mes fichiers sur le
disque pourraient changer quelque chose ?
Les gros fichiers engendrent-ils plus de fragmentation que les petits
? (je comprends bien que des fichiers tous inférieurs à 4096 Octets
n'engendreront aucune fragmentation sur un disque dont les blocs font
4096 Octets, mais de là à obtenir 63%....)

Pascal

Le 19 août 2008 17:24, François Cerbelle

Le Mar 19 août 2008 17:10, Luxpopuli Open source a écrit :
J'ai un disque dur externe en ext3 et la commande:
fsck -y /dev/sda1
me renvoie:
/dev/sda1 : 13069/61048832 fichiers (62.7% non contigus),
462232110/488384000 blocs
C'est tout de même beaucoup !
C'est la première fois que je vois un tel score en 15 ans.



Ton disque ne serait-il pas plein aux environ de 90% ? L'algo de gestion
des extends utilisé par ext, aussi bien soit-il, doit pouvoir être mi s en
défaut. Si tu remplis ton disque de petits fichiers à la suite, que t u en
supprimes un sur deux, que tu le reremplis avec des fichiers un tout peti t
peu plus gros que les précédents, et que tu recommences plusieurs foi s
(c'est à peu pres l'idée d'un disque de sauvegarde), tu finis par avo ir de
la fragmentation.

Si je relance la commande, elle se termine immédiatement en me disant
que le disque est propre.


Oui, ca n'a pas de rapport avec la cohérence du systeme de fichiers. Tu
peux toujours utiliser l'option "-f" pour forcer un fsck, mais ça ne
changera rien.

Ce média est un média de sauvegarde et ne comporte que des gros
fichiers de plusieurs 100aines de mega.
Ai-je une solution pour remédier à cette fragmentation intempestive .



Tu n'en as pas vraiment besoin, le temps d'accès n'a pas une grande
importance :
- c'est un disque de sauvegarde
- c'est un disque externe (USB, je suppose) et ce n'est pas la
fragmentation qui doit entraîner le plus grand ralentissement lors de
l'accès aux données, à mon avis, mais le bus USB.

Si tu y tiens absolument, je vois deux solutions :
- il existe un petit outil de defragmentation qui doit s'appeler e2defrag
(de mémoire), mais je ne sais pas s'il gère correctement le journal e xt3
(a vérifier avant tout) ;
- Copier tes sauvegardes ailleurs, les supprimer du disque externe (apres
avoir vérifié qu'elles sont bien copiées) et les y replacer.

Mais je pense que, si mon hypothèse de début sur la gestion des exten ds
est bonne, ton utilisation de ce disque comme moyen de sauvegarde et que
ta stratégie de sauvegarde vont faire regrimper le taux de fragmentatio n.

A+
Francois Cerbelle






--
Linuxorable: création de sites web, cours d'informatique à domicile, d épannage,
http://linuxorable.fr
-----
http://www.luxpopuli.fr - documentation de eZ Publish traduite en françai s

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Serge Cavailles
Le #16579931
Bonjour Pascal,

Le mardi 19 août 2008 19:17, Luxpopuli Open source a écrit :
Bonjour François,

Merci pour tes explications claires.

Juste pour info, mon disque est en effet plein (100%).

Pourquoi le fait de faire une «réinstall» de mes fichiers sur le
disque pourraient changer quelque chose ?



Parce que l'origine de la fragmentation est la _suppression_ de fichiers
(qui laissent des "trous" (espace libéré), lesquels seront utilisés p our
copier ensuite d'autres fichiers, qui, s'ils sont plus gros que le plus
gros des trous, devront être fragmentés). Pas de trous liés à une
suppression => tout l'espace libre en un bloc, donc pas de nécessité de
fragmenter.


Les gros fichiers engendrent-ils plus de fragmentation que les petits
? (je comprends bien que des fichiers tous inférieurs à 4096 Octets
n'engendreront aucune fragmentation sur un disque dont les blocs font
4096 Octets, mais de là à obtenir 63%....)



Il y a d'autant plus de chances qu'il faille fragmenter le fichier pour le
caser dans les trous que sa taille est importante.

Cordialement,
--
Serge

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
François Cerbelle
Le #16581281
Luxpopuli Open source a écrit :
Pourquoi le fait de faire une «réinstall» de mes fichiers sur le
disque pourraient changer quelque chose ?
Les gros fichiers engendrent-ils plus de fragmentation que les petits
? (je comprends bien que des fichiers tous inférieurs à 4096 Octets
n'engendreront aucune fragmentation sur un disque dont les blocs font
4096 Octets, mais de là à obtenir 63%....)



Par ce que si tu sauvegardes un fichier A de 10Mo, puis un fichier B de
10Mo, tu occupes les 20 premiers Mo de ton disque. Tu travailles sur ton
PC, sur le fichier A et il grossi a 11 Mo... A la prochaine sauvegarde,
il ne peut pas techniquement tenir à la place de l'ancienne sauvegarde
de A. Comme il doit le remplacer, il faut supprimer A (10Mo), puis
ecrire le nouveau A (11Mo). l'algo cherche un emplacement disponible qui
soit le plus proche de la taille du nouveau fichier (algo fortement
simplifié). Il y a deux cas :
- Le disque n'est pas plein et l'emplacement libre le plus proche de 11
Mo se trouve APRES B. Le systeme peut prendre 11 Mo contigus et y placer
le nouveau A.
- le disque est presque plein. le systeme ne dispose pas de 11Mo
contigus apres B, mais d'un peu moins (peu importe combien du moment que
ce soit compris entre 1Mo et 10Mo). Il doit donc placer les premiers
10Mo de A avant et le dernier Mo apres B.


J'ai fait court car je ne vais pas reecrire les documentations dans un
courriel. Par contre, je te suggère fortement de lire le premier tier
d'un article qui date un peu mais qui explique merveilleusement bien,
avec des mots simples et un immense sens de l'humour ce fonctionnement :
"Piege dans le cyberespace" de Roberto di Cosmo (Google t'en trouvera
facilement une copie).

Bonne soirée
François
--
François - Batiment B10 - 6, rue d'Andilly - 95600 Eaubonne
SFR : +33 6 03 01 55 12 - Freebox : +33 8 71 77 77 56
http://www.cerbelle.net - http://www.wideopenportal.org

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme