Compresser chaque répertoire et l'effacer

Version imprimable

Voir 40 message(s) de cette discussion en une page

18/11/2016, 09h46
Christophe

Citation:

Sinon je m'apprêtais à lui proposer de compresser avec mksquashfs. C'est en lecture bien sûr au montage, mais avec une combinaison d'union avec aufs, il peut écrire olà dessus et compresser à nouveau sans avoir vraiment décompresser l'archive source.

Dans ce cas, autant créer un fichier image contenant un FS monté en loopback. Pas de compression avec ce système, adapté à ce cas.
18/11/2016, 13h25
NVCfrm
Citation:

Envoyé par chrtophe

Dans ce cas, autant créer un fichier image contenant un FS monté en loopback. Pas de compression avec ce système, adapté à ce cas.

Salut. Tu n'as sans doute pas compris les fonds de la suggestion, ou je ne comprends le fond de ta remarque.
Vu qu'il fait de l'archivage compressé, pourquoi créer un fichier image d'une autre façon dans ce cas précis ? Le fichier de type Squashfs étant en quelque sorte un fichier image, un filesystem compressé. Squashfs permet d'archiver justement les contenus d'un ou plusieurs répertoires avec un plus par rapport à tar voir, la doc de Squashfs pour plus de détails à ce sujet.

Un exemple d'utilisation les plus simples, pour archiver :
Code:

1 2 3 $ mksquashfs ~/rep_racine racine.sqh $ mksquashfs ~/rep1 rep2 rep3 repmultiple.sqh $ mksquashfs ~/source source.sqh -e excludir1 -e excludir2 -e exclufile1
Il y a l'outil unsquashfs pour extraire une donnée précise, voir restaurer un répertoire en écrasant celui d'en cours avec l'option -f.

En ayant par exemple compressé des données avec cette méthode dans un fichier archive.sqh, pour la manip qui s'inspire des exemples de la doc:

Code:

$ mkdir mnt_rw mnt_ro mnt_unfs

mnt_ro sera le point de montage du fgichier archive.sqh en lecture.

mnt_rw servira à aufs d'écrire ses modifications telles que suppression ou ajouts.

mnt_unfs sera le point de montage de l'union en écriture

Code:

# mount -t squashfs archive.sqh mnt_ro

Il ne souhaiterait pas ajouter des données, voudrait juste supprimer certaines choses, ce qui suit ne s'applique pas. Il suffit de faire un mksquashfs archive_mount_point archive.new.sqh en excluant les repertoires ou fichiers non désirés ave l'option -e.

Code:

# mount -t aufs -o dirs=mnt_rw=rw:mnt_ro=ro unionfs mnt_unfs

une fois terminée ses écritures il suffit de faire un mksquashfs mnt_unfs new_archive.sqhLes lives systems avec l'option persistance sont aussi basées sur ce principe
18/11/2016, 15h37
Christophe

Si, j'ai bien compris.

Je trouve juste que cette solution manque de souplesse, car avec un squashfs, le delta est enregistré dans un fichier secondaire, ce fichier contenant toutes les modifs effectués. En cas de modif d'un seul fichier, toute la partie RW doit être resauvegardée En cas de suppression de fichier, le squashfs garde la même taille, il est juste masqué via une info dans la partie en RW, et en cas de modification, le fichier source reste dans le squashfs, et la nouvelle version est stockée dans le fichier RW. Pöur une image de 200 Mo, la taille réeille occupée (en comptant la partie lecture seule plus la partie RW) sera de 200 Mo plus la taille de l'image modifiée.

La meilleure solution pour ce cas de figure reste pour moi RSync, bien qu'il ne convienne pas au demandeur.
18/11/2016, 17h33
Sve@r
Citation:

Envoyé par disedorgue

Je pense qu'il y a une typo ici, tar tfz, en principe ne fonctionne pas, car c'est le connecteur f qui prend un paramètre...

En fait, l'ordre des options importe peu car les valeurs (pour les options qui en demandent une) sont placées après. Toutefois si deux (ou plus) options demandent une valeur, alors les valeurs correspondantes devront être placées dans le même ordre que les options auxquelles elles sont rattachées.

Exemple: l'option "f" demande un fichier, et l'option "b" demande un facteur de blocage (utile quand on utilise des bandes magnétiques). Les options "c" et "v" ne demandent rien. Si on veut archiver "/etc" dans "fic.tar" avec un facteur de blocage de 20, on a alors le droit d'écrire:
- tar cvbf 20 fic.tar /etc
- tar cvfb fic.tar 20 /etc
- tar fcvb fic.tar 20 /etc
et toute autre combinaison de son choix (avec éventuellement des "tirets" pour ceux qui aiment les options "classiques" comme l'a dit jlliagre). Les seules choses à bien vérifier c'est l'ordre relatif de "f" et "b" qui imposeront l'ordre relatif de "fic.tar" et "20" qu'on placera après. Et bien entendu ensuite les noms des fichiers à archiver (ici "/etc") en fin de commande.

A noter aussi la possibilité de remplacer le nom de l'archive par un "-" (tiret). Cela a pour effet d'envoyer l'archive sur "stdout" ce qui permet (par exemple) de la récupérer dans un autre "tar" (là aussi depuis le fichier "-" devenant alors "stdin").
Exemple: copier un dossier "dirA" (et toute son arborescence) dans un autre dossier "dest": tar cf - dirA | (cd dest; tar xpvf -) (fonctionne mieux qu'un "cp -r" car avec "cp -r", si le dossier "dirA" contient 2 liens X et Y, le "cp" génèrera 2 fichiers distincts "X" et "Y" dans la nouvelle arborescence alors que "tar", lui, respecte la nature des fichiers d'origine).
Exemple: copier un dossier "dirA" (et toute son arborescence) sur un "hostX" distant: tar cf - dirA | ssh hostX "tar xpvf -".
29/11/2016, 21h05
junior76

Merci à tous pour vos éclairages.

J'ai lu, et relu tout ce qui a été dit. Je pense que dans mon cas, le plus simple sera de créer des TAR non compressés car je n’archive que des JPEG et ne gagne en moyenne que 1% lors de la compression pour un temps de traitement vraiment plus long. Lorsque je voudrais travaillais sur le contenu, je décompresserai le TAR et le recompresserai à la fin du traitement.

Toutes les solution pour monter tel ou tel type de fichier de compression ou d'archive ne sont pas "user friendly" donc à choisir, autant faire le simple. En tout cas, j'ai appris beaucoup grace à vous tous. Merci :)
30/11/2016, 10h17
jack-ft

Citation:

Envoyé par junior76

Je pense que dans mon cas, le plus simple sera de créer des TAR non compressés car je n’archive que des JPEG et ne gagne en moyenne que 1% lors de la compression pour un temps de traitement vraiment plus long.

Tout à fait d'accord.

Citation:

Lorsque je voudrais travaillais sur le contenu, je décompresserai le TAR et le recompresserai à la fin du traitement.

Les termes "compresser/décompresser" ne sont pas exacts. Comme tu l'as dit, il n'y a pas de compression, juste un archivage. J'aurais plutôt dit:
"Lorsque je voudrai travailler sur le contenu, je désarchiverai le TAR et réarchiverai les fichiers à la fin du traitement."

Juste pour info, il faut savoir que le "tar" est quasiment identique à un "cat": si tu regardes le contenu d'un fichier "tar", tu retrouves tel quel le contenu des différents fichiers concaténés (facile à voir avec des fichiers texte). La commande "tar" ajoute juste (en codage binaire) des informations concernant les attributs des fichiers (nom, dates, droits, structure de répertoire, et j'en oublie peut-être).
30/11/2016, 10h33
junior76

Citation:

Envoyé par jack-ft

Les termes "compresser/décompresser" ne sont pas exacts. Comme tu l'as dit, il n'y a pas de compression, juste un archivage. J'aurais plutôt dit:
"Lorsque je voudrai travailler sur le contenu, je désarchiverai le TAR et réarchiverai les fichiers à la fin du traitement."

Juste pour info, il faut savoir que le "tar" est quasiment identique à un "cat": si tu regardes le contenu d'un fichier "tar", tu retrouves tel quel le contenu des différents fichiers concaténés (facile à voir avec des fichiers texte). La commande "tar" ajoute juste (en codage binaire) des informations concernant les attributs des fichiers (nom, dates, droits, structure de répertoire, et j'en oublie peut-être).

Oui, tu as raison, c'est un abus de language de ma part.

Merci pour l'info conernant le TAR et le CAT.
30/11/2016, 18h22
Christophe

Pour l'en-tête ajouté par tar :
https://fr.wikipedia.org/wiki/Tar_(i...27en-t.C3.AAte

Voir 40 message(s) de cette discussion en une page