Bonjour,
J'ai un répertoire où je stock mes fichiers sauvegardés copiés avec rsync. La structure est la suivante :
- backup
\_ 2014-06-03
\_ 2014-06-04
\_ 2014-06-05
\_ currentLes dossiers 2014-06-* correspondent aux sauvegardes des jours précédent et current à la dernière sauvegarde. Afin de mettre en place une sorte de déduplication, si un fichier dans current est identique avec celui d'une précédente sauvegarde alors un hardlink est créé, c'est rsync qui gère ça avec l'option link-dest.
Maintenant j'ai besoin d'évaluer la place prise par le dossier current et un dossier d'une précédente sauvegarde. Si j'utilise
$ du -hs current
332 Go
$ du -hs 2014-06-05
332 GoJ'ai comme l'impression qu'il y a un truc qui va pas, est-ce qu'il y a un moyen d'exclure pour 2014-06-05 le hardlink de façon à ne pas les prendre en compte dans le calcul ?
# Il n'y a pas moyen de le savoir
Posté par Renault (site web personnel) . Évalué à 7.
Un lien physique entre deux fichiers est fondamentalement différent d'un lien symbolique et ses caractéristiques rend ton opération impossible.
En effet, un lien physique partage le même inode dans le système de fichier que sur le fichier qu'il point. Ce fichier référencera bien le fait qu'il y a 2 pointeurs (de chemins différents) vers cet inode. Mais comme c'est le même inode, à partir du moment où le lien physique est crée, le lien physique est strictement identique que celui à l'origine, car comme ils ont le même inode, ils partagent tous les points en commun. Sauf le nom d'accès au fichier, car le nom n'est pas stocké dans l'inode.
D'ailleurs pour t'en convaincre, tu fais un lien physique avec un autre fichier dans le même dossier, avec un ls -l tu verras bien que les 2 noms pour ce fichier ont tous les 2 le compteurs à 2 (voire plus) de références d'accès, et aucun des d'eux n'aura une mention spéciale de type s (contrairement au lien symbolique qui est un fichier plus spécial).
Bref, ta requête est fondamentalement impossible à satisfaire à cause du lien physique. La meilleure solution pour toi serait presque de faire un système différentiel avec rsync ce qui n'utilise pas de liens physiques, permet de visualiser ce que tu veux, ne prends pas plus d'espace sur le disque, etc.
[^] # Re: Il n'y a pas moyen de le savoir… quoique
Posté par JJD . Évalué à 7.
J'aurais eu tendance à dire la même chose que Renault, puis j'ai testé.
J'ai deux répertoires dir1 et dir2. Dans dir1, je mets un fichier file1 de quelques gigaoctets.
Dans dir2, je crée un lien hard vers le fichier dir1/file1 :
Je suis
sur le culvachement surpris.Pour info, j'ai un noyau 3.14 et les GNU coreutils en version 8.21.
Il semblerait donc que du dédoublonne.
D'ailleurs, du a une option "-l" ou "--count-links" pour «comptabiliser les tailles plusieurs fois dans le cas des liens directs» (extrait du man et en anglais ça donne «count sizes many times if hard linked») et l'option est déjà présente dans la version 5.97.
Donc, pour répondre à Philippe, il suffit d'exécuter la commande du une seule fois pour les deux répertoires :
[^] # Re: Il n'y a pas moyen de le savoir… quoique
Posté par Philippe M (site web personnel) . Évalué à 2. Dernière modification le 05 juin 2014 à 16:47.
ah bah vi étonnant je viens de tester sur mon serveur et ça marche :
Moi qui m'étais lancé dans des trucs compliqué à coups de find et autre sed… Ce qui est encore plus perturbant c'est quand j'ajoute un 3eme répertoire :
du -hs 2014-06-03 2014-06-04 current/
331G 2014-06-03
27G 2014-06-04
263G current/
Born to Kill EndUser !
[^] # Re: Il n'y a pas moyen de le savoir… quoique
Posté par Renault (site web personnel) . Évalué à 2.
Cela ne contredit pas ce que je dis, apparemment les fichiers avec le compteurs de lien à 2 ou plus, il compare les inodes et si c'est le même il remplace l'un des deux chemins par une taille d'un block car ils sont identiques.
Mais comme tu le vois, selon l'ordre de l'appel, ce n'est pas le même dossier qui est accrédité comme "celui qui possède véritablement le fichier", ce qui rend bien indiscernable le chemin de fichier d'origine et le nouveau.
Mais c'est vrai qu'en comparer les inodes, il est possible de faire quelque chose comme ça, je n'y avais pas pensé. Cela ne change pas la réalité sous jacente pour le système de fichier.
[^] # Re: Il n'y a pas moyen de le savoir… quoique
Posté par Philippe M (site web personnel) . Évalué à 1.
Dans mon cas peut importe la "source" réelle puisque c'est la taille qui m'importe.
D'un autre côté puisque c'est un lien la notion de fichier source n'est pas vraiment nécessaire et particulièrement dans le cas des hardlink.
Born to Kill EndUser !
[^] # Re: Il n'y a pas moyen de le savoir
Posté par Philippe M (site web personnel) . Évalué à 2. Dernière modification le 05 juin 2014 à 16:43.
Merci pour l'explication clair et précise.
Born to Kill EndUser !
# du find links
Posté par steph1978 . Évalué à 3.
du ne compte les blocks qu'un seule fois.
si tu as deux fichiers qui pointent sur les mêmes blocks, il ne compte que le premier :
tu peux utiliser find pour avoir les blocks pointés par un seul fichier :
combiné à du, tu aura ta réponse.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.