Si je ne me trompe, le problème n'est pas tant au niveau de la fragmentation que de la capacité à lire fragmenté.
Heu non tu fais fausse route à 100%. Si on parle de support mécanique ce qui coute cher c'est le déplacement des têtes: grosso modo 10ms le seek, 1ms au mieux. La seul façon d'augmenter la perf est donc d'avoir à bouger les têtes le moins possible. Ce qui implique d'éviter la fragmentation des fichiers (plusieurs blocs non contigus) et d'éviter d'avoir à bouger les têtes entre des fichiers fréquemment accéder ensemble.
Les FS ext* sont historiquement pas mauvais pour la première partie tant qu'il leur reste beaucoup de place libre et que tu n'as pas un usage pathologique. Il y a eu quelques avancées avec ext4. Pour la deuxième partie c'est plus mitigé, je ne connais pas exactement l'algo mais le système n'a aucun moyen au préalable de savoir ou mettre quoi. Si tu fais deux cp en même temps, le système n'a aucun moyen de connaitre la sémantique des opérations que tu es en train de faire et va donc certainement entremêler plusieurs fichiers.
Les deux seules approches sont préventives et curatives.
Préventive: Éviter les opérations qui vont mélanger les fichiers et éviter les usages qui vont fragmenter les fichiers. Par exemple tu vas pré-allouer l'espace d'une ISO que tu vas récupérer par bittorrent.
Curative: Au minimum tu vas réarranger ton FS pour que tout les blocs d'un même fichier soient contigus et au mieux tu vas essayer de tenir compte de la localité d'accès des fichiers. Pour éviter de bouger la tête 1000 fois quand tu lances une appli ou boot. Ton FS va compacter des régions pour éviter d'avoir à fragmenter des fichiers dans des trous.
Linux à toujours choisi l'option de ne pas fournir de curatif au niveau système mais de laisser le taff à l'userland (qui n'a jamais été vraiment fait). Un solution est simplement de retirer remettre les données (il faut avoir de l'espace en rab). Mais on pourrait faire bien mieux en profilant l'usage et en s'en servant pour placer les fichiers. Je sais pas si un système à déjà fait cela. Et ça pourrait être marrant de faire tourner des algo de data-mining sur les accès non cachés aux fichiers.
Mais, vous ressentez (encore mieux, mesurez) réellement des problèmes de fragmentation sous linux ? (car c'est la vrai question)
Selon les usages oui. Il y a 2/3 ans je faisais un gzip/gunzip de mon home sur ma station de dev tout les 6 mois et je sentais la différence à l'usage.
Après avec un SSD c'est complétement différent. En règle général plus ton disque est moisi (laptop) plus ça se sent.
[^] # Re: Utilité d'un outil comme celui-ci ?
Posté par ckyl . En réponse à la dépêche Sortie de Ultracopier 1.0. Évalué à 2.
Heu non tu fais fausse route à 100%. Si on parle de support mécanique ce qui coute cher c'est le déplacement des têtes: grosso modo 10ms le seek, 1ms au mieux. La seul façon d'augmenter la perf est donc d'avoir à bouger les têtes le moins possible. Ce qui implique d'éviter la fragmentation des fichiers (plusieurs blocs non contigus) et d'éviter d'avoir à bouger les têtes entre des fichiers fréquemment accéder ensemble.
Les FS ext* sont historiquement pas mauvais pour la première partie tant qu'il leur reste beaucoup de place libre et que tu n'as pas un usage pathologique. Il y a eu quelques avancées avec ext4. Pour la deuxième partie c'est plus mitigé, je ne connais pas exactement l'algo mais le système n'a aucun moyen au préalable de savoir ou mettre quoi. Si tu fais deux cp en même temps, le système n'a aucun moyen de connaitre la sémantique des opérations que tu es en train de faire et va donc certainement entremêler plusieurs fichiers.
Les deux seules approches sont préventives et curatives.
Préventive: Éviter les opérations qui vont mélanger les fichiers et éviter les usages qui vont fragmenter les fichiers. Par exemple tu vas pré-allouer l'espace d'une ISO que tu vas récupérer par bittorrent.
Curative: Au minimum tu vas réarranger ton FS pour que tout les blocs d'un même fichier soient contigus et au mieux tu vas essayer de tenir compte de la localité d'accès des fichiers. Pour éviter de bouger la tête 1000 fois quand tu lances une appli ou boot. Ton FS va compacter des régions pour éviter d'avoir à fragmenter des fichiers dans des trous.
Linux à toujours choisi l'option de ne pas fournir de curatif au niveau système mais de laisser le taff à l'userland (qui n'a jamais été vraiment fait). Un solution est simplement de retirer remettre les données (il faut avoir de l'espace en rab). Mais on pourrait faire bien mieux en profilant l'usage et en s'en servant pour placer les fichiers. Je sais pas si un système à déjà fait cela. Et ça pourrait être marrant de faire tourner des algo de data-mining sur les accès non cachés aux fichiers.
Selon les usages oui. Il y a 2/3 ans je faisais un gzip/gunzip de mon home sur ma station de dev tout les 6 mois et je sentais la différence à l'usage.
Après avec un SSD c'est complétement différent. En règle général plus ton disque est moisi (laptop) plus ça se sent.