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.
Je pense sincèrement que statistiquement il y a largement plus d'inode avec un unique lien dur qu'autres chose (bien sûr on peu trouver des cas particuliers comme des gestions de backup incrémentales qui utilisent massivement les liens en dur). Si je prends tes chiffres, il suffirait que 20 % des fichiers n'aient qu'un seul lien en dur pour que ce soit intéressant, c'est AMHA une hypothèse tout à fait acceptable.
A minima ne pas garder les inodes qui n'ont qu'un seul lien ne coûte rien (c'est un test lors de l'insertion).
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.
Si on considère le compteur de lien, on peut garder en mémoire les n inodes qui ont le plus grand nombre de liens restant. si un fichier à 17 000 liens dur il est probablement plus intéressant de le garder que celui qui en a 3. Bien sûr c'est statistique tout ça.
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.
En effet.
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)?
Je ne connais dump que de nom, lui parle d'outil lié au système de fichier. dd est vraiment lent pour faire ça même s'il est probablement moins consommateur en mémoire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: cp
Posté par barmic . En réponse au journal Journal Bookmark #1. Évalué à 2.
Je pense sincèrement que statistiquement il y a largement plus d'inode avec un unique lien dur qu'autres chose (bien sûr on peu trouver des cas particuliers comme des gestions de backup incrémentales qui utilisent massivement les liens en dur). Si je prends tes chiffres, il suffirait que 20 % des fichiers n'aient qu'un seul lien en dur pour que ce soit intéressant, c'est AMHA une hypothèse tout à fait acceptable.
A minima ne pas garder les inodes qui n'ont qu'un seul lien ne coûte rien (c'est un test lors de l'insertion).
Si on considère le compteur de lien, on peut garder en mémoire les n inodes qui ont le plus grand nombre de liens restant. si un fichier à 17 000 liens dur il est probablement plus intéressant de le garder que celui qui en a 3. Bien sûr c'est statistique tout ça.
En effet.
Je ne connais
dumpque de nom, lui parle d'outil lié au système de fichier.ddest vraiment lent pour faire ça même s'il est probablement moins consommateur en mémoire.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)