Je pense qu'il est surtout pas nécessaire d'avoir la totalité de la map en mémoire, on peut garder en mémoire un cache des inodes et devoir recharger la partie nécessaire de la map depuis le disque en cas de besoin1.
Je ne comprends pas très bien ce que tu veux dire: c'est exactement ce qui se passe avec la swap memory, du coup je suppose que tu penses à implémenter une stratégie de swap explicite, plus efficace que celle de l'OS dans le cas de cp. Mais je ne vois pas trop sur quelle hypothèse plausible sur l'input pourrait s'appuyer cette stratégie pour être plus maline que l'OS.
On peut aussi utiliser le compteur de liens en dur qui se trouve dans l'inode pour savoir quand libérer cet inode de la map (ou savoir s'il est vraiment nécessaire de l'ajouter à la map).
La commande GNU cp ne fait pas cela (je viens de vérifier). Ceci dit, comme il y a 400 millions de fichiers ajouter le compte des références à la table ajoute 1,6 ou 3,2 Go de données dans la structure! (Dans ext4 le nombre de hard-links est compté dans 16 bits mais d'autres systèmes utilisent la taille du mot machine.) Donc pour savoir si conserver ce nombre augmente la performance dans le cas général il faut y passer un peu plus de temps que 5 minutes autour d'un café — ce que je ne suis pas prêt à faire aujourd'hui.
Il y a à mon avis pas mal de chose qui peuvent être des axes d'amélioration et il est possible que rsync soit testé avec dans ce genre de cas (je ne peux pas pas tester personnellement)
Très spontanément, j'aurais plutôt pensé à rsync qu'à cp et on s'imagine effectivement que rsync est plus testé pour le transfert de volumes important. Cependant, l'admin qui relate son expérience démontre un très bon niveau de compétence, il a donc très certainement considéré l'hypothèse de rsync et finalement décidé d'utiliser cp.
Ce que démontre assez bien l'article est un effet inattendu de l'utilisation des hard-links sur la maintenance! Utiliser des soft-links aurait permis de copier beaucoup plus bêtement le système — mais il ont sûrement de bonnes raisons d'utiliser des hard-links dans leur système.
L'admin mentionne qu'il a préféré ne pas utiliser dd à cause des erreurs de disque et faire un copie logique avec cp au lieu d'utiliser une copie bit à bit. Mais n'aurai-t-il pas eu intérêt à utiliser un outil travaillant sur une représentation intermédiaire du système de fichiers, de type dump (FreeBSD)?
[^] # Re: cp
Posté par Michaël (site web personnel) . En réponse au journal Journal Bookmark #1. Évalué à 2.
Je ne comprends pas très bien ce que tu veux dire: c'est exactement ce qui se passe avec la swap memory, du coup je suppose que tu penses à implémenter une stratégie de swap explicite, plus efficace que celle de l'OS dans le cas de
cp. Mais je ne vois pas trop sur quelle hypothèse plausible sur l'input pourrait s'appuyer cette stratégie pour être plus maline que l'OS.La commande GNU
cpne fait pas cela (je viens de vérifier). Ceci dit, comme il y a 400 millions de fichiers ajouter le compte des références à la table ajoute 1,6 ou 3,2 Go de données dans la structure! (Dansext4le nombre dehard-linksest compté dans 16 bits mais d'autres systèmes utilisent la taille du mot machine.) Donc pour savoir si conserver ce nombre augmente la performance dans le cas général il faut y passer un peu plus de temps que 5 minutes autour d'un café — ce que je ne suis pas prêt à faire aujourd'hui.Très spontanément, j'aurais plutôt pensé à
rsyncqu'àcpet on s'imagine effectivement quersyncest plus testé pour le transfert de volumes important. Cependant, l'admin qui relate son expérience démontre un très bon niveau de compétence, il a donc très certainement considéré l'hypothèse dersyncet finalement décidé d'utilisercp.Ce que démontre assez bien l'article est un effet inattendu de l'utilisation des hard-links sur la maintenance! Utiliser des soft-links aurait permis de copier beaucoup plus bêtement le système — mais il ont sûrement de bonnes raisons d'utiliser des hard-links dans leur système.
L'admin mentionne qu'il a préféré ne pas utiliser
ddà cause des erreurs de disque et faire un copie logique aveccpau lieu d'utiliser une copie bit à bit. Mais n'aurai-t-il pas eu intérêt à utiliser un outil travaillant sur une représentation intermédiaire du système de fichiers, de typedump(FreeBSD)?