Discussion :

[clavier12AZQSWX]

bonjour,

je suis sur un hébergement mutualisé, quand je fais un rm -rf monsite_bacnkup/ c'est long ? ( entre 20 et 30s )

est-ce normal cette longueur ?

est-ce que l'OS les mes à la poubelles (ça expliquerait la lenteur) où ils sont vraiment supprimer ?

[N_BaH]

Bonjour,

tu devrais plutôt t'adresser à ton hébergeur, dont nous ne savons rien.

[clavier12AZQSWX]

sinon plutôt que d'attendre dans un délai incertain inconnu, n'y-a-t-il pas une commande pour supprimer un dossier et qui affichera le Nb de fichiers avec une jauge ? même une jauge austère avec des caractères ASCII ça m'irait !
une jauge en "texte" comme on voit dans le htop ou encore dans cette page en bas d'écran :
https://archive.org/download/msdos_s...e_fb_DSG11.gif

[tabouret]

Hello

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
rm -rfv monsite_bacnkup | pv -l -s $(du -a monsite_bacnkup | wc -l) > /dev/null

Un truc dans ce genre.

EDIT: la poubelle c'est en graphique, pas en CLI.

[Echap]

Plusieurs facteurs
1- Le type du disque (ancien disques, SSD, NVME)
2- Combien de vcore ou milli vcore a ta disposition
3- le volume à supprimer
4- latence entre ce qui ce passe réellement et l’information que tu reçois
5- la charge sur le serveur, si les disques et très sollicité par les autres applications/sites sur le même serveur.
Mois je trouve normal.
Ce que m’étonne plutôt c’est la capacité à exécuter une commande pareil dans un hébergement partagé!

[clavier12AZQSWX]

Ce que m’étonne plutôt c’est la capacité à exécuter une commande pareil dans un hébergement partagé!

pourquoi ? le rm en SSH devrait être impossible dans un hébergement mutualisé ? si les admins ont bien fait leur virtualisation, ça devrait pas posé de souci je pense...

[ALT]

Il y a quantité d'opérations qui prennent beaucoup de temps chez les hébergeurs & qui sont plutôt rapides sur un ordinateur local.
Alors, est-ce anormal d'attendre pour un rm -rf ?
Sans compter les opérations, pourtant prévues par ledit hébergeur (genre installation d'un logiciel de gestion de contenu), & qui plantent avec succès.

[clavier12AZQSWX]

merci ALT.

après plusieurs test, j'ai compris que ça venait surtout de l'énorme quantité de fichiers/sous-dossier derrière ce que j'essaie de supprimer. Visiblement, les dernières moutures de wordpress sont énormes en Nb de fichiers/dossiers....

[kick54]

merci ALT.

après plusieurs test, j'ai compris que ça venait surtout de l'énorme quantité de fichiers/sous-dossier derrière ce que j'essaie de supprimer. Visiblement, les dernières moutures de wordpress sont énormes en Nb de fichiers/dossiers....

Bonjour,

Tu peux utiliser la commande "du" (Disk Usage) Pour connaître la taille de ton dossier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
du -sh monsite_bacnkup

Sinon "rm" à un mode verbeux avec l'option -v

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
rm -rfv monsite_bacnkup

[clavier12AZQSWX]

Bonjour,

Tu peux utiliser la commande "du" (Disk Usage) Pour connaître la taille de ton dossier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
du -sh monsite_bacnkup

Sinon "rm" à un mode verbeux avec l'option -v

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
rm -rfv monsite_bacnkup

bonjour,

Connaître la capacité d'un dossier est-il vraiment "utile" pour estimer la durée de suppression ?
La durée de suppression dépend surtout du nb de fichiers , non ? pas de la taille des fichiers.... (je peux me tromper...je me base sur mon expérience desktop)

Quand au RM verbeux, par définition il va afficher plus de choses, donc ça va allonger en fait!
c'est juste dommage qu'il n'y ait pas un RM avec "comptage" de fichiers/dossiers avant, et une info mise à jour durant la suppression...
Voir juste le ptit curseur clignoter durant une longue suppression est un peu anxiogène...

[kick54]

bonjour,

Connaître la capacité d'un dossier est-il vraiment "utile" pour estimer la durée de suppression ?
La durée de suppression dépend surtout du nb de fichiers , non ? pas de la taille des fichiers.... (je peux me tromper...je me base sur mon expérience desktop)

Quand au RM verbeux, par définition il va afficher plus de choses, donc ça va allonger en fait!
c'est juste dommage qu'il n'y ait pas un RM avec "comptage" de fichiers/dossiers avant, et une info mise à jour durant la suppression...
Voir juste le ptit curseur clignoter durant une longue suppression est un peu anxiogène...

Bonjour,
Concernant la dépendance taille - durée
Un fichier est découpé en blocs dispersés sur le disque physique.
Selon le type de système de fichiers (SF) les adresses des blocs seront obtenues dans la table des i-nodes avec plus ou moins d'indirections

Par exemple un type de SF qui compterait dans un i-node les adresses de blocs dans une liste de 13 adresses (un cas antédiluvien mais facile à aborder) :
Adressage des blocs :
Direct pour les 10 premières adresses.
Indirect pour la onzième entrée (cette adresse est l'adresse d'un bloc qui contient des adresses de blocs de données).
A deux niveaux d'indirection pour la douzième entrée (cette adresse est l'adresse d'un bloc qui contient des adresses de blocs qui contiennent des adresses de blocs données).
A trois niveaux d'indirection pour la dernière entrée (...).

Donc oui la taille à de l'importance sur le temps de suppression, car lors de celle-ci,
les adresses des blocs libérés devront être placés dans dans la liste des blocs libres du SF (contenue dans le superbloc du SF)
et
la table des i-nodes doit être mise à jour pour l'i-node du fichier supprimé
et
le répertoire qui contient le fichier doit être mis à jour (NB un répertoire est un fichier et a donc lui aussi une entrée dans la table des i-nodes du SF)


concernant le RM verbeux, c'est pour que notre ami ai une idée du temps qui se passe lors de la suppression^.

Concernant la poubelle, une poubelle est un répertoire, donc le placement d'un fichier est comme un move "mv", alors tout dépend du SF où est la poubelle et quelle est sa capacité :
- si elle est sur le même SF, la suppression d'un fichier est identique au renommage du fichier dans un autre répertoire donc au déplacement du lien
- si elle est sur un autre SF, le fichier est dupliqué (dans la limite de la taille de la poubelle) avant d'être supprimé

Concernant le curseur, comme le temps restant dépendant la taille et de la dispersion, le calcul est plus compliquer que savoir combien il reste de fichiers à supprimer, il faudrait parcourir tous les i-node concernés pour avoir la liste des bloc à supprimer et ajuster la jauge au fil des blocs libérés. ça signifierai une multitude d'accès disques qui seraient très coûteux n temps. C'est pourquoi ce n'est pas prévu. Si la jauge ne prennait pas en compte le nombre de bloc mais le nombre de fichiers on gagnerait en phase initiale au détriment de la précision de l'information affichée.

En pratique comme toujours, c'est un peu plus compliqué, car le système d'exploitation tamponne (buffer) les données sur les SF (table des i-node, superbloc) et temporise leurs mises à jour sur disque (synchronisation); je ne parle pas du cas de SF journalisé (ext4, XFS , ReiserFS, ZFS, ...)


Cordialement

PS.
On trouve pas mal de cours qui détaillent tout cela, par exemple : ci-fs.pptx.pdf

[chrtophe]

il y a pv, qui pipeliné avec la commande choisie, permet d'avoir une progression.

[kick54]

il y a pv, qui pipeliné avec la commande choisie, permet d'avoir une progression.

Bonjour chrtophe,
Un processus derrière un pipeline ne peut connaître la taille de ce qu'il reste dans le pipeline qu'en consommant la totalité de ce qui en sort.
Donc ni "pv", ni "dialog --gauge ..." ne peuvent indiquer la progression.

Cordialement

[chrtophe]

Exemple d'utilisation de pv avec rm :

$ rm -rv dirname | pv -l -s 1000 > logfile
562 0:00:07 [79,8 /s] [====================> ] 56% ETA 0:00:05

[kick54]

Exemple d'utilisation de pv avec rm :

On ne compte que les fichiers on ne prend pas en compte leurs tailles, mais c'est une première estimation intéressante.

Toutefois, en indiquant -s 1000, tu présume le nombre de retour ligne (-l), par conséquent l'indication n'est pertinente que si tu le connais par avance :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ ls -lR /usr/ | pv -l -s 1000 >/dev/null
28.3k 0:00:24 [1.17k/s] [====================================] 2830%

Pour cela il faut exécuter deux fois la commande qui parcourt l'arborescence, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
$ ls -lR /usr/ | pv -l -s `(ls -R /usr | wc -l)` >/dev/null
28.3k 0:00:21 [1.32k/s] [=====================================] 104%
 
$ ls -R /usr | wc -l
28302

NB : c'est plus proche, mais il y a encore un peu de rabiot 104% ... je ne sais pas d'où ça vient ?!

[Jipété]

Un lien utile et sympa ; https://www.linuxtricks.fr/wiki/pv-a...ps-d-une-tache

(parce que quand j'ai fait une recherche "pv" dans Synaptic [Debian], ça m'a remonté des milliers de lignes, juste inexploitables)

[clavier12AZQSWX]

Un lien utile et sympa ; https://www.linuxtricks.fr/wiki/pv-a...ps-d-une-tache

(parce que quand j'ai fait une recherche "pv" dans Synaptic [Debian], ça m'a remonté des milliers de lignes, juste inexploitables)

exactement ça ! le vieux afficage ms-dos avec la jauge basique ! nickel!

34,5MiO 0:00:08 [ 6,3MiB/s] [====================> ] 45% ETA 0:00:09

je préfère avoir 10s de plus et avoir cette infos que attendre dans l'incertitude qu'une commande se termine !

Question: est-ce que c'est "silencieux" actif ou passif ?
c-a-d que si je lance la procedure dans un shell ssh windows (ou putty) et que je regarde pas la console pendant 1h, est-ce que ça va maintenir la connexion ou bien ça va l’interrompre ?
L'autre probleme des rm/co long fait à distance dans un shell, c'est qu'il faille revenir toutes les 2 ou 5min faire une touche au clavier pour maintenir la session ouverte active...sinon la connexion ssh est coupée!

[disedorgue]

On ne compte que les fichiers on ne prend pas en compte leurs tailles, mais c'est une première estimation intéressante.

Toutefois, en indiquant -s 1000, tu présume le nombre de retour ligne (-l), par conséquent l'indication n'est pertinente que si tu le connais par avance :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ ls -lR /usr/ | pv -l -s 1000 >/dev/null
28.3k 0:00:24 [1.17k/s] [====================================] 2830%

Pour cela il faut exécuter deux fois la commande qui parcourt l'arborescence, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
$ ls -lR /usr/ | pv -l -s `(ls -R /usr | wc -l)` >/dev/null
28.3k 0:00:21 [1.32k/s] [=====================================] 104%
 
$ ls -R /usr | wc -l
27173

NB : c'est plus proche, mais il y a encore un peu de rabiot 104% ... je ne sais pas d'où ça vient ?!

Moins sauvage que ls:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ du -s --inodes /usr
49725   /usr

[papajoker]

bonjour

j'ai fait une recherche "pv" dans Synaptic

Une recherche d'info sous linux est toujours le man en premier ! un blog ne va que donner un petit apercu...

[Jipété]

bonjour

Une recherche d'info sous linux est toujours le man en premier ! un blog ne va que donner un petit apercu...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ man pv
Aucune entrée de manuel pour pv

Normal car l'outil n'est pas installé, donc recours à Synaptic (qui n'est pas un blog mais le gestionnaire de paquets Debian) et patatras, pv introuvable.