[Ubuntu-QC] Défi à toute la francophonie des spécialistes de Linux...

[Mathieu Trudel-Lapierre]

2011/2/6 Lami René <lami at webestrie.com>:
[...]
> L'une des meilleures manières de convaincre un utilisateur de l'autre monde
> de migrer à Linux et aux logiciels ouverts et libres, c'est quand il nous
> voit ne pas avoir ses problèmes ! Par exemple, la sécurité, les pirates, la
> vie privée, les virus, l'intégration des dépôts logiciels, les mises à jour
> de distribution, et parfois Linux pourra même les aider en corrigent certain
> de leurs problèmes de base.
>

Que je sache, c'est déjà le cas. Comme vous le dîtes, on a "pas de
virus", "pas de lenteurs", etc...

> Pour ce qui est de la défragmentation, on repassera, car pour le moment, on
> passe complètement à côté de cette superbe opportunité de les séduire. Je
> sais que sous les partitions Linux ext3 et ext4 le problème ne se pose pas,
> mais cela ne suffit pas, leur montrer qu'on n'a pas le problème, c'est bien,
> mais quand plus on peu corriger leurs problèmes, alors si Linux peu faire
> ça, c'est qu'il est franchement meilleur et supérieur, alors pourquoi payer
> pour...

Je comprends l'idée, mais en même temps, le problème est dû à une
interaction beaucoup plus complexe que présentée ici.

[...]

> 2) La distribution des adresses de secteur est séquentielle. Cela implique
> que quand un fichier est effacé ou mise à jour ou écrasé (remplacer sur
> place), sont adresse de secteur ne sera pas réutilisé, temps que toutes les
> adresses n'auront pas été utilisées au moins une fois, puis deux, puis trois

En effet. Et plus ou moins pour les raisons mentionnées par la suite.
Mais ce n'est pas si simple: NTFS laisse aussi de la place libre
*entre* les fichiers, ce qui a également tendance à augmenter le
niveau de fragmentation.

[...]
> successives, mais les gros fichiers vidéo ou images ISO entre 200 Mo et 4.2
> Go restent très fractionnés, malgré que les partitions de 160 Go ont au
> minimum 60 Go de libres.

Quelle taille de cluster à été utilisée? Il s'agit là d'une donnée
essentielle qui peut grandement affecter les résultats.

[...]

> Mes partitions de partage des données sont fragmentées à au moins 60 % sur
> tous les systèmes ! J'ai utilisé PC-Cloneur 8 et Acronis True Image 2010
> avec les mêmes résultats.

Et s'agit-t-il de tout plein de petits fichiers, ou que des gros? Un mélange?

[...]

> J'ai fait d'innombrables essais et le dernier en cours est de formater un
> disque dur USB qui était en NTFS en ext4 pour détruire complètement la table
> d'allocation des fichiers, pour ensuite la reformater en NTFS et y copier
> les dossiers et fichiers de ma partition de partage des données
> (Windows-Linux) avec GRsync (entre 3 et 7 heures de transfère selon
> l'ordi.). Si cela ne fonctionne pas, je pense formater sur disque USB, ma
> partition de partage NTFS en Ext4 temporairement, y copier les dossiers et
> fichiers et avec GParted ou PartionManager, recréer la table de partions
> NTFS de synchronisation d'un disque d'un ordinateur, mais tout cela est très
> lourd et prend énormément de temps et de ressources. Ce n'est vraiment pas
> pratique.
>

En principe, ca devrait fonctionner plus ou moins bien, mais il y aura
toujours un certain niveau de fragmentation. En partie à cause de ce
que j'ai mentionné plus haut, mais aussi par le design du système de
fichier, de la taille des fichiers, etc. À ne pas oublier que les
systèmes d'accès NTFS sont créés à partir des spécifications du
système de fichiers fournies par Microsoft, et donc, entièrement à la
merci de l'exactitude de ces spécifications.

Pas que je crois que ce soit une mauvaise idée, mais difficile à
implémenter, pour toutes sortes de raisons assez bien connues et
documentées.

À titre de recherche intéressante pour aller avec vos tests, on
pourrait comparer les résultats avec du FAT32. Vérifier si les
problèmes sont aussi apparents avec différentes tailles de "cluster"
(c'est configurable quand on formate).

Mathieu Trudel-Lapierre <mathieu-tl at ubuntu.com>
Freenode: cyphermox, Jabber: mathieu.tl at gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93