Linux fragmente pas ? Grotesque

Toxico Nimbus a écrit :

Pascal Hambourg a écrit :

Ne serait-il pas plus pertinent d'utiliser pour chaque fichier une
métrique telle que la distance totale entre les fragments, ou plus
simplement le nombre de fragments ?

Quelle distance. On peut essayer de calculer une distance congrue au
temps d'accès d'une donnée à l'autre,

C'est l'idée, oui.

mais alors il faudrait tenir
compte de la géométrie du disque ou de la matrice (RAID ou autre).

Et on ne parle pas de LVM qui fausse encore plus l'équation. J'en suis
conscient, c'est pourquoi j'ai évoqué une métrique plus simple, basée
sur le seul nombre de fragments d'un fichier et non de leur distance. Le
taux de fragmentation global pourrait alors être le nombre de fragments
divisé par le nombre de fichiers ; un taux de 1 signifierait l'absence
de fragmentation ; un taux de 2 signifierait qu'il y a en moyenne deux
fragments par fichier.

Or
comme la plupart des disques durs ne déclarent pas leur géométrie
physique mais une géométrie logique souvent différente (beaucoup de
disques ne déclarent que 2 têtes alors qu'ils en ont 4 ou 8).

C'est plutôt le contraire, les disques ATA déclarent beaucoup plus de
têtes (jusqu'à 255) qu'ils n'en ont en réalité (rarement plus de 6).

Mais même si la géométrie physique réelle est inconnue, l'adressage LBA
d'un disque physique est globalement monotone avec celle-ci. Deux blocs
sont donc d'autant plus éloignés que la différence entre leurs adresses
LBA est grande. Cela pourrait constituer une distance acceptable. Je
pense aussi que ça reste globalement vrai pour du RAID.

A mon avis, le bête pourcentage est
suffisant. Au pire, on peut toujours pondérer avec la fréquence d'accès
aux dits fichiers.

Ce ne serait plus une mesure de la fragmentation du système de fichiers
mais un indice de la performance en fonction de son utilisation.

Pascal Hambourg a écrit :

mais alors il faudrait tenir compte de la géométrie du disque ou de la
matrice (RAID ou autre).

Et on ne parle pas de LVM qui fausse encore plus l'équation. J'en suis
conscient, c'est pourquoi j'ai évoqué une métrique plus simple, basée
sur le seul nombre de fragments d'un fichier et non de leur distance. Le
taux de fragmentation global pourrait alors être le nombre de fragments
divisé par le nombre de fichiers ; un taux de 1 signifierait l'absence
de fragmentation ; un taux de 2 signifierait qu'il y a en moyenne deux
fragments par fichier.

Oui mais cet indice de fragmentation est-il vraiment révélateur de la
perte de performance ?

Or comme la plupart des disques durs ne déclarent pas leur géométrie
physique mais une géométrie logique souvent différente (beaucoup de
disques ne déclarent que 2 têtes alors qu'ils en ont 4 ou 8).

C'est plutôt le contraire, les disques ATA déclarent beaucoup plus de
têtes (jusqu'à 255) qu'ils n'en ont en réalité (rarement plus de 6).

Merci pour cette clarification.

Mais même si la géométrie physique réelle est inconnue, l'adressage LBA
d'un disque physique est globalement monotone avec celle-ci. Deux blocs
sont donc d'autant plus éloignés que la différence entre leurs adresses
LBA est grande. Cela pourrait constituer une distance acceptable. Je
pense aussi que ça reste globalement vrai pour du RAID.

Sans pouvoir en apporter la preuve, je ne suis pas d'accord avec ça.

A mon avis, le bête pourcentage est suffisant. Au pire, on peut
toujours pondérer avec la fréquence d'accès aux dits fichiers.

Ce ne serait plus une mesure de la fragmentation du système de fichiers
mais un indice de la performance en fonction de son utilisation.

Peut-être devrait-on vérifier d'abord en quoi le simple pourcentage ne
serait pas déjà un indice de performance.

Pascal Hambourg wrote:

[...]

Allez, une autre réflexion. On a coutume de dire que Windows fragmente
(beaucoup) et Linux non (ou peu). Mais est-ce qu'un volume FAT ou NTFS
monté sous Linux fragmente, et est-ce qu'un volume ext2/3 monté sous
Windows fragmente ? Autrement dit, le gène de la fragmentation est-il
dans la structure du système de fichiers ou seulement dans la façon de
l'utiliser ?

Si mes souvenirs sont bons la capacité à fragmenter (ou à ne pas fragmenter ;-) est intrinsèque au système de fichiers. Il me semble que les systèmes de fichiers ext* ou autres réservent un certains nombres de blocs adjacents lors de l'écriture d'un fichier (système de pré-allocation) ce qui explique la très faible fragmentation observée.


--
Bruno

Le 28-11-2008, ? propos de
Re: Linux fragmente pas ? Grotesque,
bruno666 ?crivait dans fr.comp.os.linux.debats :

Pascal Hambourg wrote:

[...]

Allez, une autre réflexion. On a coutume de dire que Windows fragmente
(beaucoup) et Linux non (ou peu). Mais est-ce qu'un volume FAT ou NTFS
monté sous Linux fragmente, et est-ce qu'un volume ext2/3 monté sous
Windows fragmente ? Autrement dit, le gène de la fragmentation est-il
dans la structure du système de fichiers ou seulement dans la façon de
l'utiliser ?

Si mes souvenirs sont bons la capacité à fragmenter (ou à ne pas fragmenter ;-) est intrinsèque au système de fichiers. Il me semble que les systèmes de fichiers ext* ou autres réservent un certains nombres de blocs adjacents lors de l'écriture d'un fichier (système de pré-allocation) ce qui explique la très faible fragmentation observée.

Pour information, NTFS fait ça aussi. Autre chose, tes lignes sont
beaucoup trop longues...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB wrote:

Le 28-11-2008, ? propos de
Re: Linux fragmente pas ? Grotesque,
bruno666 ?crivait dans fr.comp.os.linux.debats :

Pascal Hambourg wrote:

[...]

Allez, une autre réflexion. On a coutume de dire que Windows fragmente
(beaucoup) et Linux non (ou peu). Mais est-ce qu'un volume FAT ou NTFS
monté sous Linux fragmente, et est-ce qu'un volume ext2/3 monté sous
Windows fragmente ? Autrement dit, le gène de la fragmentation est-il
dans la structure du système de fichiers ou seulement dans la façon de
l'utiliser ?

Si mes souvenirs sont bons la capacité à fragmenter (ou à ne pas
fragmenter ;-) est intrinsèque au système de fichiers. Il me semble que
les systèmes de fichiers ext* ou autres réservent un certains nombres de
blocs adjacents lors de l'écriture d'un fichier (système de
pré-allocation) ce qui explique la très faible fragmentation observée.

Pour information, NTFS fait ça aussi.

Oui, mais sans pas aussi efficacement...

Autre chose, tes lignes sont
beaucoup trop longues...

Bizarre mon bousin est bien configuré pour des lignes à 76 caractères,
je ne vais regarder ce qui cloche

--
Bruno

bruno666 écrivait

Bizarre mon bousin est bien configuré pour des lignes à 76 caractères,
je ne vais regarder ce qui cloche

Voir aussi à utiliser "ISO-8859-15" et non pas "ISO 8859-15"
Il y a une discussion en cours sur fr.usenet.8bits là dessus.

Patrick Lamaizière écrivait :

bruno666 écrivait

Bizarre mon bousin est bien configuré pour des lignes à 76 caractères,
je ne vais regarder ce qui cloche

Aïe : https://bugs.kde.org/show_bug.cgi?id7996

Voir aussi à utiliser "ISO-8859-15" et non pas "ISO 8859-15"
Il y a une discussion en cours sur fr.usenet.8bits là dessus.

Oui ce n'est pas normal non plus. Merci je vais regarder cela aussi.

--
Bruno

Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:

Stephan Peccini a écrit :
>
> Bon, je viens de faire un test avec un système de fichiers vieux de 4 ans
> en ext3 et aujourd'hui en ext4. Il n'arrête pas de bouger de manière
> intensive puisque j'y mets mes sauvegardes temporaires, mes espaces de
> travail, mes espaces de compilation et qu'il est régulièrement à 100%.
> Aujourd'hui il est à environ 80% et j'obtiens : 220000 fichiers dont
> 11500 sont fragmentés, soit 5,5% après 4 ans.
[...]
> Mon PC professionnel sous NTFS a déjà subi 2 defragmentations en 1 an car
> il avoisinait les 25% de fragmentation sans avoir dépassé 75% de
> remplissage et tout cela sans être mon disque de données.
>
> Donc quand on dit que Linux ne fragmente pas, cela a un sens car il ne
> sert à rien de défragmenter sauf gagner des pouillèmes en général.

Allez, une autre réflexion. On a coutume de dire que Windows fragmente
(beaucoup) et Linux non (ou peu). Mais est-ce qu'un volume FAT ou NTFS
monté sous Linux fragmente, et est-ce qu'un volume ext2/3 monté sous
Windows fragmente ? Autrement dit, le gène de la fragmentation est-il
dans la structure du système de fichiers ou seulement dans la façon de
l'utiliser ?

Il est dans la structure du système de fichiers. Typiquement, quand tu
écris des fichiers dans un système DOS vierge, le système les colle bout
à bout, à priori jusqu'à ce que le disque soit plein. Cependant en cours
de route, tu effaces des fichiers, ce qui crée des trous, dans lesquels
tu colles aussi de nouveaux fichiers s'ils sont assez petits pour
rentrer dans le trou, ou bien répartis sur plusieurs trous. Petit à
petit, les nouveaux fichiers se mettent à s'étaler un peu partout. Quand
tu utilises defrag, il recopie les fichiers au début du disque de
manière contigue, et rend l'espace libre connexe.
Les systèmes comme ext2, ext3, BSD UFS, etc. ne procèdent pas du tout
comme ça. Déjà le disque est découpé en "groupe de cylindres" et le
système essaie de mettre les fichiers d'un même répertoire dans le même
groupe de cylindres pour accroître la localité. Mais en général les
fichiers sont répartis dans tout le disque. Ensuite les fichiers sont
écrits par blocs, tous de même taille (en fait il existe des fragments
dans UFS) ce qui fait que tout bloc libre peut servir de place pour un
nouveau bloc. Utiliser une taille standard fait peut être perdre de la
place à la fin du bloc, mais lutte efficacement contre la fragmentation.
La même stratégie est utiliséee dans les allocateurs mémoires modernes
(le slab allocator de Solaris, recopié dans Linux et FreeBSD). Bon, si
un fichier est gros il ne tient pas dans un bloc et il faut le mettre
dans des blocs indirects, voire dans des blocs à double indirection.
Ceci fait alors évidemment perdre de la localité, mais le système essaie
de garder ces blocs proches. Toujours est-il que pour un système avec de
gros fichiers, il y a là une cause de perte de performance, ce qui
explique pourquoi d'autres systèmes de fichiers essayent encore
d'utiliser des morceaux de disque bien plus gros contigus pour eux,
genre xfs. Mais alors le risque de fragmentation resurgit évidemment, ce
qui tendrait à expliquer pourquoi on a développé des défragmenteurs pour
eux.






--

Michel TALON

--{ Pascal Hambourg a plopé ceci: }--

Allez, une autre réflexion. On a coutume de dire que Windows fragmente
(beaucoup) et Linux non (ou peu). Mais est-ce qu'un volume FAT ou NTFS
monté sous Linux fragmente, et est-ce qu'un volume ext2/3 monté sous
Windows fragmente ? Autrement dit, le gène de la fragmentation est-il
dans la structure du système de fichiers ou seulement dans la façon de
l'utiliser ?

Très bonne question. J'imagine que quelque soit la structure du
système de fichier, il y a des stratégies d'utilisation qui
peuvent faire la différence: first/best fit, statistiques sur
l'utilisation du fs, et même des trucs plus subtils...

Maintenant, certains de ces trucs plus "subtils" sont peut-être
inutilsables dans la vraie vie...


--

Pourquoi les prises « informatique » ne sont pas sur onduleur ?

Parce que le poulet n'était pas sur onduleur quand il a traversé la route.

Ça serait ça l'explication que ça ne m'étonnerait pas.
--{ MW: Je vous laisse trouver un titre. }--

Le 29-11-2008, Thierry B. <tth@prout.stex.invalid> a écrit :

Allez, une autre réflexion. On a coutume de dire que Windows fragmente
(beaucoup) et Linux non (ou peu). Mais est-ce qu'un volume FAT ou NTFS
monté sous Linux fragmente, et est-ce qu'un volume ext2/3 monté sous
Windows fragmente ? Autrement dit, le gène de la fragmentation est-il
dans la structure du système de fichiers ou seulement dans la façon de
l'utiliser ?

Très bonne question. J'imagine que quelque soit la structure du
système de fichier, il y a des stratégies d'utilisation qui
peuvent faire la différence: first/best fit, statistiques sur
l'utilisation du fs, et même des trucs plus subtils...

Je dirais non. Le système, lui, lit ou écrit un fichier. C'est au filesystem
de faire le boulot.

Maintenant, certains de ces trucs plus "subtils" sont peut-être
inutilsables dans la vraie vie...

Honnêtement, je resterai dans la tradition unixienne. Chacun son job.
Le système écrit un fichier, le filesystem se débrouille. Puis le
gestionnaire de disques (LVM, cryptsetup, tout ça), puis enfin le driver
disque qui va déplacer la tête de lecture au bon endroit.
Mais ça n'est qu'une idée en l'air..
--
Kevin