Hum l'idée est là, mais l'efficacité serait celle à peu près celle de shake 0.5 .
Pour commencer, Filefrag, à mon avis, a été crée à des fins de déboguage, et pas dans le but d'évaluer l'impact de la fragmentation sur les performances.
Par exemple, il considère que deux "morceaux" distants d'un unique block sont des fragments, alors qu'en pratique la taille du trou peut être négligeable en terme de performances. De même, il ne tient pas compte des liens qui existent entre les fichiers ayant un atime proche, ni de la taille des fragments relativement à celle du fichier, ni de la date des fichiers.
Ensuite, le couple cp/rm a plusieurs inconvénients. Par exemple si ton fichier "A" est hardlinké vers "B" et que tu fait un "cp A TEMP; rm A; cp TEMP A", le lien dur entre "A" et "B" sera perdu. De même, pour les éventuelles métadonnés.
Tu me diras, un "cat A > TEMP" n'auras pas certains de ces inconvénients. C'est vrai, mais il ne géreras pas les fichiers sparses.
Je suppose aussi qu'on pourrait en fait contourner les problèmes liés à filefrag avec un gros script (awk ? perl ?) qui en parserait la sortie et recalculerais des informations de fragmentation plus utilisables. De meme, on pourrait effectivement utiliser ls pour trier les fichier par atime, puis réutiliser les informations extraites par le script parsant filefrag pour calculer (comme je le fait) la position idéale et ainsi de suite.
Les difficultés liées à cp me paraissent plus difficilement contournables... et il faudrais encore s'occuper de la gestion des erreurs, penser à éviter les liens symboliques etc.
Déjà à ce stade, je pense que le code serait beaucoup plus lourd et complexe que celui de shake, tout en ayant des performances moindre, et (au choix) le problème des fichiers sparses ou des métadonnées. Et il resterais encore à tenir compte du coût lié à la copie de gros fichiers, de la différence d'atime dans le calcul des corrélations entre les fichiers... sans parler du fait qu'aparement filefrag soit destiné à Linux uniquement (bon, shake aussi actuellement, mais pas à terme).
Alors que, finalement, shake c'est juste trois fichiers de 300 lignes en C, qui se veulent propres, abondament commentées et documentées dans un joli PDF.
En plus shake vient avec des routines spécialisées, notement un système de copie des fichiers sparse qui essaie de tenir compte d'une évaluation de la lecture anticipée de la plupart des disques, une routine pour modifier le ctime et un joli mode verbose.
Et j'en ai mis un coup à mon /usr/bin sans même le casser !
Mangez-en !
Ceci dit, en toute honnêteté, je doit dire que le choix du langage était aussi guidé par le fait que l'UE soit intitulée "Programation en C" -_^. Il reste que je suis sincère quand j'affirme penser que le langage était adapté.
[^] # Re: ...
Posté par un_brice (site web personnel) . En réponse au journal Shake : secouez vos fichiers, c'est pour leur bien !. Évalué à 10.
Pour commencer, Filefrag, à mon avis, a été crée à des fins de déboguage, et pas dans le but d'évaluer l'impact de la fragmentation sur les performances.
Par exemple, il considère que deux "morceaux" distants d'un unique block sont des fragments, alors qu'en pratique la taille du trou peut être négligeable en terme de performances. De même, il ne tient pas compte des liens qui existent entre les fichiers ayant un atime proche, ni de la taille des fragments relativement à celle du fichier, ni de la date des fichiers.
Ensuite, le couple cp/rm a plusieurs inconvénients. Par exemple si ton fichier "A" est hardlinké vers "B" et que tu fait un "cp A TEMP; rm A; cp TEMP A", le lien dur entre "A" et "B" sera perdu. De même, pour les éventuelles métadonnés.
Tu me diras, un "cat A > TEMP" n'auras pas certains de ces inconvénients. C'est vrai, mais il ne géreras pas les fichiers sparses.
Je suppose aussi qu'on pourrait en fait contourner les problèmes liés à filefrag avec un gros script (awk ? perl ?) qui en parserait la sortie et recalculerais des informations de fragmentation plus utilisables. De meme, on pourrait effectivement utiliser ls pour trier les fichier par atime, puis réutiliser les informations extraites par le script parsant filefrag pour calculer (comme je le fait) la position idéale et ainsi de suite.
Les difficultés liées à cp me paraissent plus difficilement contournables... et il faudrais encore s'occuper de la gestion des erreurs, penser à éviter les liens symboliques etc.
Déjà à ce stade, je pense que le code serait beaucoup plus lourd et complexe que celui de shake, tout en ayant des performances moindre, et (au choix) le problème des fichiers sparses ou des métadonnées. Et il resterais encore à tenir compte du coût lié à la copie de gros fichiers, de la différence d'atime dans le calcul des corrélations entre les fichiers... sans parler du fait qu'aparement filefrag soit destiné à Linux uniquement (bon, shake aussi actuellement, mais pas à terme).
Alors que, finalement, shake c'est juste trois fichiers de 300 lignes en C, qui se veulent propres, abondament commentées et documentées dans un joli PDF.
En plus shake vient avec des routines spécialisées, notement un système de copie des fichiers sparse qui essaie de tenir compte d'une évaluation de la lecture anticipée de la plupart des disques, une routine pour modifier le ctime et un joli mode verbose.
Et j'en ai mis un coup à mon /usr/bin sans même le casser !
Mangez-en !
Ceci dit, en toute honnêteté, je doit dire que le choix du langage était aussi guidé par le fait que l'UE soit intitulée "Programation en C" -_^. Il reste que je suis sincère quand j'affirme penser que le langage était adapté.