Tout démarre conformément à mes voeux ... mais au bout de dix bonnes
minutes, je commence à déchanter. En effet, j'ai l'impression que tout
se passe comme si l'archive entière, d'environ 500 Mo à ce moment là,
était lue avant le rajout de chaque nouveau fichier trouvé.
La lenteur de l'opération devient telle que plusieurs dizaines secondes
s'écoulent entre chaque archivage de fichier. Je n'ai pas cru utile de
poursuivre. Bien entendu, l'utilisation de l'option -u n'améliore pas
les temps d'archivage.
Quelqu'un a-t-il une astuce pour accélérer le processus d'archivage ou
une autre stratégie à proposer ?
Quand on peut utiliser + au lieu de ; pour find -exec (et ça semble bien être le cas ici) c'est toujours un gain de temps appréciable. Ça sera sans doute légèrement plus lent que l'autre réponse proposée, mais plus standard.
Quand on peut utiliser + au lieu de ; pour find -exec (et ça semble bien
être le cas ici) c'est toujours un gain de temps appréciable. Ça sera
sans doute légèrement plus lent que l'autre réponse proposée, mais plus
standard.
Quand on peut utiliser + au lieu de ; pour find -exec (et ça semble bien être le cas ici) c'est toujours un gain de temps appréciable. Ça sera sans doute légèrement plus lent que l'autre réponse proposée, mais plus standard.
Quand on peut utiliser + au lieu de ; pour find -exec (et ça semble bien être le cas ici) c'est toujours un gain de temps appréciable. Ça sera sans doute légèrement plus lent que l'autre réponse proposée, mais plus standard.
Attention, il y a un piège ... ;-)
Je suppose que le « find ... -exec ... + » fera la même chose que « find ... | xargs ... », c'est à dire qu'il va construire une ligne de commande aussi longue qu'il le peut, et au moment où cette ligne atteint le maximum (en nombre d'argument), on l'exécute, puis on continue.
Si la commande derrière est un truc du genre "cat", ou "perl -pi -e ...", c'est pas grave, puisque l'exécuter en plusieurs fois ne change pas la fonctionnalité. Mais avec tar, c'est bien différent. Le jour où tu as N+1 fichiers, si N est le max possible, tu vas exécutuer un gros "tar ... fichier1 ... fichierN", puis un deuxième "tar ... fichierN+1" qui va joyeusement écraser l'archive créee par la première commande.
En clair, ça va marcher sur des petits nombres de fichiers, et planter _silencieusement_ sur des grands nombres :-(.
Quand on peut utiliser + au lieu de ; pour find -exec (et ça semble bien
être le cas ici) c'est toujours un gain de temps appréciable. Ça sera
sans doute légèrement plus lent que l'autre réponse proposée, mais plus
standard.
Attention, il y a un piège ... ;-)
Je suppose que le « find ... -exec ... + » fera la même chose que
« find ... | xargs ... », c'est à dire qu'il va construire une ligne
de commande aussi longue qu'il le peut, et au moment où cette ligne
atteint le maximum (en nombre d'argument), on l'exécute, puis on
continue.
Si la commande derrière est un truc du genre "cat", ou "perl -pi
-e ...", c'est pas grave, puisque l'exécuter en plusieurs fois ne
change pas la fonctionnalité. Mais avec tar, c'est bien différent. Le
jour où tu as N+1 fichiers, si N est le max possible, tu vas
exécutuer un gros "tar ... fichier1 ... fichierN", puis un deuxième
"tar ... fichierN+1" qui va joyeusement écraser l'archive créee par la
première commande.
En clair, ça va marcher sur des petits nombres de fichiers, et planter
_silencieusement_ sur des grands nombres :-(.
Quand on peut utiliser + au lieu de ; pour find -exec (et ça semble bien être le cas ici) c'est toujours un gain de temps appréciable. Ça sera sans doute légèrement plus lent que l'autre réponse proposée, mais plus standard.
Attention, il y a un piège ... ;-)
Je suppose que le « find ... -exec ... + » fera la même chose que « find ... | xargs ... », c'est à dire qu'il va construire une ligne de commande aussi longue qu'il le peut, et au moment où cette ligne atteint le maximum (en nombre d'argument), on l'exécute, puis on continue.
Si la commande derrière est un truc du genre "cat", ou "perl -pi -e ...", c'est pas grave, puisque l'exécuter en plusieurs fois ne change pas la fonctionnalité. Mais avec tar, c'est bien différent. Le jour où tu as N+1 fichiers, si N est le max possible, tu vas exécutuer un gros "tar ... fichier1 ... fichierN", puis un deuxième "tar ... fichierN+1" qui va joyeusement écraser l'archive créee par la première commande.
En clair, ça va marcher sur des petits nombres de fichiers, et planter _silencieusement_ sur des grands nombres :-(.
-- Matthieu
kato fong
Marc writes:
kato fong wrote:
$ find /mnt/hd -iname "*.jpg" -exec tar rvf jpegs.tar {} ; Quand on peut utiliser + au lieu de ; pour find -exec (et ça semble bien
être le cas ici) c'est toujours un gain de temps appréciable. Ça sera sans doute légèrement plus lent que l'autre réponse proposée, mais plus standard.
Attention, il y a un piège ... ;-)
Je suppose que le « find ... -exec ... + » fera la même chose que « find ... | xargs ... », c'est à dire qu'il va construire une ligne de commande aussi longue qu'il le peut, et au moment où cette ligne atteint le maximum (en nombre d'argument), on l'exécute, puis on continue.
oui, c'est ce que j'ai observé avec GNU find
Si la commande derrière est un truc du genre "cat", ou "perl -pi -e ...", c'est pas grave, puisque l'exécuter en plusieurs fois ne change pas la fonctionnalité. Mais avec tar, c'est bien différent. Le jour où tu as N+1 fichiers, si N est le max possible, tu vas exécutuer un gros "tar ... fichier1 ... fichierN", puis un deuxième "tar ... fichierN+1" qui va joyeusement écraser l'archive créee par la première commande.
En clair, ça va marcher sur des petits nombres de fichiers, et planter _silencieusement_ sur des grands nombres :-(.
c'est pourquoi il vaut mieux utiliser "tar rvf ..." qui évite ce piège dans lequel je suis tombé en premier en utilisant un "tar cvf ..." ;)
-- kf
Marc <marc.glisse@gmail.com> writes:
kato fong wrote:
$ find /mnt/hd -iname "*.jpg" -exec tar rvf jpegs.tar {} ;
Quand on peut utiliser + au lieu de ; pour find -exec (et ça semble bien
être le cas ici) c'est toujours un gain de temps appréciable. Ça sera
sans doute légèrement plus lent que l'autre réponse proposée, mais plus
standard.
Attention, il y a un piège ... ;-)
Je suppose que le « find ... -exec ... + » fera la même chose que
« find ... | xargs ... », c'est à dire qu'il va construire une ligne
de commande aussi longue qu'il le peut, et au moment où cette ligne
atteint le maximum (en nombre d'argument), on l'exécute, puis on
continue.
oui, c'est ce que j'ai observé avec GNU find
Si la commande derrière est un truc du genre "cat", ou "perl -pi
-e ...", c'est pas grave, puisque l'exécuter en plusieurs fois ne
change pas la fonctionnalité. Mais avec tar, c'est bien différent. Le
jour où tu as N+1 fichiers, si N est le max possible, tu vas
exécutuer un gros "tar ... fichier1 ... fichierN", puis un deuxième
"tar ... fichierN+1" qui va joyeusement écraser l'archive créee par la
première commande.
En clair, ça va marcher sur des petits nombres de fichiers, et planter
_silencieusement_ sur des grands nombres :-(.
c'est pourquoi il vaut mieux utiliser "tar rvf ..." qui évite ce piège
dans lequel je suis tombé en premier en utilisant un "tar cvf ..." ;)
$ find /mnt/hd -iname "*.jpg" -exec tar rvf jpegs.tar {} ; Quand on peut utiliser + au lieu de ; pour find -exec (et ça semble bien
être le cas ici) c'est toujours un gain de temps appréciable. Ça sera sans doute légèrement plus lent que l'autre réponse proposée, mais plus standard.
Attention, il y a un piège ... ;-)
Je suppose que le « find ... -exec ... + » fera la même chose que « find ... | xargs ... », c'est à dire qu'il va construire une ligne de commande aussi longue qu'il le peut, et au moment où cette ligne atteint le maximum (en nombre d'argument), on l'exécute, puis on continue.
oui, c'est ce que j'ai observé avec GNU find
Si la commande derrière est un truc du genre "cat", ou "perl -pi -e ...", c'est pas grave, puisque l'exécuter en plusieurs fois ne change pas la fonctionnalité. Mais avec tar, c'est bien différent. Le jour où tu as N+1 fichiers, si N est le max possible, tu vas exécutuer un gros "tar ... fichier1 ... fichierN", puis un deuxième "tar ... fichierN+1" qui va joyeusement écraser l'archive créee par la première commande.
En clair, ça va marcher sur des petits nombres de fichiers, et planter _silencieusement_ sur des grands nombres :-(.
c'est pourquoi il vaut mieux utiliser "tar rvf ..." qui évite ce piège dans lequel je suis tombé en premier en utilisant un "tar cvf ..." ;)
-- kf
Hugues
Ce cher kato fong a dit :
Bonjour,
Voulant archiver tous les fichiers *.jpg d'un disque dur, j'ai cru habile de passer la commande suivante :
Tout démarre conformément à mes voeux ... mais au bout de dix bonnes minutes, je commence à déchanter. En effet, j'ai l'impression que tout se passe comme si l'archive entière, d'environ 500 Mo à ce moment là, était lue avant le rajout de chaque nouveau fichier trouvé.
c'est effectivement le cas, le -exec va exécuter la commande donnée pour *chaque* fichier trouvé..
-- Hugues - Debianiste avant tout - http://www.hiegel.fr/~hugues/Linux/
Ce cher kato fong <kato@sdf.lonestar.org> a dit :
Bonjour,
Voulant archiver tous les fichiers *.jpg d'un disque dur, j'ai cru habile de
passer la commande suivante :
Tout démarre conformément à mes voeux ... mais au bout de dix bonnes minutes,
je commence à déchanter. En effet, j'ai l'impression que tout se passe comme
si l'archive entière, d'environ 500 Mo à ce moment là, était lue avant le
rajout de chaque nouveau fichier trouvé.
c'est effectivement le cas, le -exec va exécuter la commande donnée pour
*chaque* fichier trouvé..
--
Hugues - Debianiste avant tout - http://www.hiegel.fr/~hugues/Linux/
Tout démarre conformément à mes voeux ... mais au bout de dix bonnes minutes, je commence à déchanter. En effet, j'ai l'impression que tout se passe comme si l'archive entière, d'environ 500 Mo à ce moment là, était lue avant le rajout de chaque nouveau fichier trouvé.
c'est effectivement le cas, le -exec va exécuter la commande donnée pour *chaque* fichier trouvé..
-- Hugues - Debianiste avant tout - http://www.hiegel.fr/~hugues/Linux/
