Je bloque pour supprimer un répertoire récalcitrant

**Flodelarab** · 17/10/2014, 12h39

Bonjour,

Ce problème de la taille des dossiers est une infection. Quand on cherche à faire de la place sur un disque dur, ni une conception, ni l'autre n'est la bonne.

S'il renvoie 0 (ou la description du dossier seul), cela ne permet pas de nettoyer
S'il renvoie la somme de son contenu, ce n'est pas bon non plus car il renverra /, /home, /home/lui, /home/lui/Documents, /home/lui/Documents/Videos, /home/lui/Documents/Videos/gros_fichier.mp4, soit 6 résultats, alors que le seul fichier encombrant est gros_fichier.mp4

Comme il y a deux sortes d'encombrants (les dossiers pleins de nombreux petits fichiers, d'une part, et un gros fichier d'autre part), s'il on veut nettoyer son disque, on n'est obligé de créer son propre outil.

**Sve@r** · 17/10/2014, 17h05

Envoyé par Flodelarab

S'il renvoie la somme de son contenu, ce n'est pas bon non plus car il renverra /, /home, /home/lui, /home/lui/Documents, /home/lui/Documents/Videos, /home/lui/Documents/Videos/gros_fichier.mp4, soit 6 résultats, alors que le seul fichier encombrant est gros_fichier.mp4

Surtout s'il recalcule cette somme à chaque ls !!!

Envoyé par Flodelarab

Comme il y a deux sortes d'encombrants (les dossiers pleins de nombreux petits fichiers, d'une part, et un gros fichier d'autre part), s'il on veut nettoyer son disque, on n'est obligé de créer son propre outil.

Ben c'est aussi le propre d'Unix: offrir des choses certes mais surtout offrir la possibilité de créer ce dont tu as spécifiquement besoin. Ceci dit, il existe des outils déjà tout faits...

**Obsidian** · 17/10/2014, 17h33

Envoyé par c_mon_identifiant

- Dolphin : le voit mais dés que j'essaye de le supprimer Dolphin se bloque
- Krusader : le voit aussi mais se bloque également quand j'ai ouvert ksysguard pendant Krusader : il est en attente disque
quand je relance Dolphin ou Krusader curieusement il ne sont plus opérationnels

Ça peut arriver quand le blocage a lieu en mode noyau pour une raison ou une autre : ouvre un terminal à côté, fais un « ps aux » dedans, trouve le processus qui gère ton rm et vérifie s'il n'est pas à l'état « D ». Si c'est le cas, c'est que c'est le pilote lui-même qui ne répond pas. Ça peut se produire entre autres en cas de défaillance matérielle de ton disque dur, soit parce que ton périphérique est en fait un périphérique externe (comme une clé USB) ou réseau (montage NFS), ou encore un truc hybride tel que fuse, très utilisé par Gnome, mais qui peut montrer des faiblesses en cas de pépins matériels.

Fais aussi un « dmesg » pour obtenir les messages noyau pendant ton rm et dis-nous si tu y lis quelque chose de pertinent.

Enfin, il est possible que ton système de fichiers soit corrompu. Un « fsck » depuis un LiveCD devrait résoudre pas mal de problème.

Par ailleurs, le répertoire concerné se trouve à quel endroit sur l'arborescence de ton disque, il s'agit d'un nom temporaire mais à vue de nez, ça ressemble à un profil Firefox.

**jack-ft** · 17/10/2014, 17h34

Envoyé par Jipété

Environ 320 fichiers et dossiers, comptés à la mano.
3,0G, 3,3G avec du --si -s "photos Raw"

Comme l'a très bien expliqué Sve@r, tu as donc une toute petite armoire (qui pèse toute seule 4096 octets (ce qui est vraiment tout petit)) qui contient 320 fichiers qui pèsent, ensemble, 3Gb, ce qui est plus qu'honorable!
Lorsque tu fais un "ls", Unix n'a besoin que de consulter l'armoire elle-même (pas son contenu), ce qui est très rapide pour un "fichier" de 4096 octets (taille qui est d'ailleurs arrondie au bloc supérieur).
Pour un "ls -l", il faut en plus qu'il récupère la taille de chacun des éléments, ce qui n'est pas très coûteux.
Par contre, si tu devais faire un "grep" dans le contenu des fichiers contenus dans l'armoire, là, ce serait plus long!

L'utilisateur de départ, lui, a parlé d'un répertoire qui pèse 500Mb, à lui tout seul, SANS les fichiers contenus!
C'est vraiment une très grosse armoire!
Il est d'ailleurs tout à fait possible qu'elle ne contienne que 2 ou 3 fichiers de quelques octets!
(avec le jeu des ajouts et suppressions de fichiers)

**Jipété** · 17/10/2014, 18h51

Envoyé par jack-ft

L'utilisateur de départ, lui, a parlé d'un répertoire qui pèse 500Mb, à lui tout seul, SANS les fichiers contenus!
C'est vraiment une très grosse armoire!
Il est d'ailleurs tout à fait possible qu'elle ne contienne que 2 ou 3 fichiers de quelques octets !

Et comment une chose pareille est-elle possible, un rép. qui pèse 500 Mb, à lui tout seul ?

Comment une armoire que contenant que 3 feuilles A4 peut-elle peser des tonnes ? Un truc m'échappe avec l'analogie de l'armoire

**Sve@r** · 17/10/2014, 19h39

Envoyé par Jipété

Et comment une chose pareille est-elle possible, un rép. qui pèse 500 Mb, à lui tout seul ?

Le dossier grossit pour les besoins... mais ne rapetisse jamais. D'ailleurs quand tu as compté tes 320 fichiers dans ton dossier, tu as alors dû le voir changer de taille quand tu y as créé tes fichiers (je présume que "à la mano" doit se lire "via un script").
Et t'as pas remarqué que sa taille restait ensuite la même bien que les fichiers qui s'y trouvaient avaient disparus ? Car je présume qu'après ton test t'as dû effacer les fichiers que t'avais créé pour l'occasion quoi...

Donc il ne "pèse pas" 500Mb, il lui "a été alloué" une taille de 500Mb parce qu'à un moment donné il a eu 500Mb de noms de fichiers à enregistrer. Et si on fait une règle de 3 avec tes 320 fichiers pour 4096 octets (ceci dit j'ai aussi testé avec un script et chez-moi c'est pareil => 320 fichiers ensuite la taille du dossier change), on trouve un total de 40 960 000 fichiers (un peu énorme mais après-tout, pourquoi pas..., je pense même qu'on pourrait obtenir ça assez rapidement avec un bon script rapide...)

Envoyé par Jipété

Comment une armoire que contenant que 3 feuilles A4 peut-elle peser des tonnes ? Un truc m'échappe avec l'analogie de l'armoire

Il faut relativiser avec les analogies car comme le dit M. Spock dans Star Trek VI, terre inconnue "même la logique doit s'effacer devant la physique". Un dossier garde la taille "qu'il a eu un jour" alors que l'armoire, elle, doit se cantonner aux lois physiques et a une masse correspondant à son contenu "actuel".
D'ailleurs si tu relis bien mon post d'hier, tu verras que je n'ai pas fait d'analogie entre "armoire" et "dossier informatique", j'ai juste illustré ton hypothèse parlant du poids du dossier qui était égal au poids de son contenu en disant que ça c'était l'image d'une armoire.
Puis j'ai ensuite enchainé en disant ensuite qu'un dossier ne se comportait pas du tout pareil...

**Flodelarab** · 17/10/2014, 19h59

http://www.cyberciti.biz/faq/unix-di...mand-examples/

J'aime beaucoup le graphique de la figure 2 de Disk Usage Analyzer.
Merci pour cette indication.

**disedorgue** · 17/10/2014, 21h24

Envoyé par Sve@r

Donc il ne "pèse pas" 500Mb, il lui "a été alloué" une taille de 500Mb parce qu'à un moment donné il a eu 500Mb de noms de fichiers à enregistrer. Et si on fait une règle de 3 avec tes 320 fichiers pour 4096 octets (ceci dit j'ai aussi testé avec un script et chez-moi c'est pareil => 320 fichiers ensuite la taille du dossier change), on trouve un total de 40 960 000 fichiers (un peu énorme mais après-tout, pourquoi pas..., je pense même qu'on pourrait obtenir ça assez rapidement avec un bon script rapide...)

Et une partition d'environ 500Go (car il faut au moins 1 inode pour un fichier)
[EDIT]: ou alors en jouant avec les lien hard...

Sinon, en relisant le début du post, je me demande si en fait son répertoire ne serait pas un point de montage (ce qui expliquerait qu'il n'arrive pas à l'effacer)...

**Jipété** · 18/10/2014, 00h27

Envoyé par disedorgue

Sinon, en relisant le début du post, je me demande si en fait son répertoire ne serait pas un point de montage (ce qui expliquerait qu'il n'arrive pas à l'effacer)...

Avec un nom aussi tordu et barbare ? Mmmmh... Et il aurait eu un vrai message d'erreur, non ?

Envoyé par Sve@r

(je présume que "à la mano" doit se lire "via un script").

Ben non, je n'avais de script dispo, et comme je savais qu'il y avait assez peu de sous-dossiers j'ai eu plus vite fait de les parcourir un par un à la souris en regardant combien il y avait de fichiers, plutôt que d'écrire et tester un script.

Envoyé par Sve@r

Et t'as pas remarqué que sa taille restait ensuite la même bien que les fichiers qui s'y trouvaient avaient disparus ? Car je présume qu'après ton test t'as dû effacer les fichiers que t'avais créé pour l'occasion quoi...

Non non, c'est un vrai dossier de "prod" qui contient les photos faites avec l'apn (de mon fils) depuis la mise en prod de cette machine. Donc ça se remplit au gré des prises de vues, du ménage y est fait et voilà.

Envoyé par Sve@r

Donc il ne "pèse pas" 500Mb, il lui "a été alloué" une taille de 500Mb parce qu'à un moment donné il a eu 500Mb de noms de fichiers à enregistrer. Et si on fait une règle de 3 avec tes 320 fichiers pour 4096 octets (ceci dit j'ai aussi testé avec un script et chez-moi c'est pareil => 320 fichiers ensuite la taille du dossier change), on trouve un total de 40 960 000 fichiers (un peu énorme mais après-tout, pourquoi pas..., je pense même qu'on pourrait obtenir ça assez rapidement avec un bon script rapide...)

41 millions de fichiers ! Mais qui peut bien avoir ça à la maison ?

**Sve@r** · 18/10/2014, 09h10

Envoyé par Sve@r

Donc il ne "pèse pas" 500Mb, il lui "a été alloué" une taille de 500Mb parce qu'à un moment donné il a eu 500Mb de noms de fichiers à enregistrer. Et si on fait une règle de 3 avec tes 320 fichiers pour 4096 octets (ceci dit j'ai aussi testé avec un script et chez-moi c'est pareil => 320 fichiers ensuite la taille du dossier change), on trouve un total de 40 960 000 fichiers (un peu énorme mais après-tout, pourquoi pas..., je pense même qu'on pourrait obtenir ça assez rapidement avec un bon script rapide...)

Bon ben j'ai écrit le script (en tenant compte aussi de la remarque de Disedorgue sur les liens hards). A savoir qu'un fichier ne peut avoir que 32000 liens hards max.

Voici le script (en Python pour plus de rapidité)

Code python :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
import sys
import os
import time
 
nb=int(sys.argv[1]) * 320 / 4096
zero=len("%s" % nb)
 
epoch=time.time()
for i in xrange(nb):
	if (i % 32000) == 0:
		base=i
		open("xxx/_%0*d" % (zero, base), "w").close()
	else:
		os.link(
			"xxx/_%0*d" % (zero, base),
			"xxx/_%0*d" % (zero, i),
		)
	# if
	if (i % 100000) == 0:
		print "%s %.02f%% %d/%d" % (
			time.strftime(
				"%Hh %Mmn %Ss",
				time.gmtime(time.time() - epoch),
			),
			i * 100.0 / nb,
			i,
			nb,
		)
	# if
# for

Mais plus de 8h après (lancé hier soir), il n'a créé que 2000000 de fichiers/liens c'est à dire à peine 5% du travail. Et le dossier n'est qu'à 40M

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ ./sizeRep.py $(expr 500 \* 1024 \* 1024)
00h 00mn 00s 0.00% 0/40960000
00h 01mn 20s 0.24% 100000/40960000
00h 05mn 02s 0.49% 200000/40960000
00h 11mn 58s 0.73% 300000/40960000
00h 21mn 55s 0.98% 400000/40960000
00h 34mn 49s 1.22% 500000/40960000
00h 50mn 36s 1.46% 600000/40960000
01h 09mn 14s 1.71% 700000/40960000
01h 30mn 44s 1.95% 800000/40960000
01h 55mn 06s 2.20% 900000/40960000
02h 21mn 58s 2.44% 1000000/40960000
02h 49mn 42s 2.69% 1100000/40960000
03h 19mn 38s 2.93% 1200000/40960000
03h 51mn 54s 3.17% 1300000/40960000
04h 26mn 27s 3.42% 1400000/40960000
05h 03mn 17s 3.66% 1500000/40960000
05h 42mn 28s 3.91% 1600000/40960000
06h 23mn 52s 4.15% 1700000/40960000
07h 07mn 36s 4.39% 1800000/40960000
07h 53mn 33s 4.64% 1900000/40960000
08h 41mn 53s 4.88% 2000000/40960000

Donc pour le script rapide je repasserai

A noter toutefois cet intéressant décalage de temps. 1mn20 pour les 1000000 premiers, puis 3mn40 pour les 100000 suivants, puis presque 7mn pour les suivants, puis 10mn puis 13 puis 16 puis presque 20 jusqu'à presque 50mn pour les 100000 derniers. Agrandir un dossier devient à chaque fois un peu plus difficile...

Envoyé par Jipété

Ben non, je n'avais de script dispo, et comme je savais qu'il y avait assez peu de sous-dossiers j'ai eu plus vite fait de les parcourir un par un à la souris en regardant combien il y avait de fichiers, plutôt que d'écrire et tester un script.

Arf, tu apprendras qu'un geek préfèrera mille fois passer 20mn à écrire un script qui ne tournera qu'une fois plutôt que faire le travail "à la main" même si ce travail ne prend que 5mn

**disedorgue** · 18/10/2014, 10h48

Ouah, interressant tout ça, et un simple "ls" dans ce répertoire cela dure combien de temps (et même un ls <nom_dun_fichier>) ?

Après, pour information, et ceux qui peuvent être interresser, tune2fs, pour l'ext4 peut activer "dir_index" qui semble justement être fait pour les "gros" repertoires de ce genre

**Jipété** · 18/10/2014, 11h04

Salut tout le monde,

Envoyé par Sve@r

Arf, tu apprendras qu'un geek préfèrera mille fois passer 20mn à écrire un script qui ne tournera qu'une fois plutôt que faire le travail "à la main" même si ce travail ne prend que 5mn

lol ! Et pendant les 15 minutes économisées, j'ai farfouillé le web à la recherche de l'outil qui va bien, et mon choix s'est porté sur kDirStat car lui affiche bien, pour un dossier, le contenu et le poids des sous-dossiers et fichiers !
Et accessible par clic-droit sur le dossier que je veux analyser

Le seul truc ennuyeux c'est que pour mon dossier de 3,2 Gb il m'affiche 3,0 et je n'ai trouvé nulle part où paramétrer ça.
Plus le fait qu'il affiche en fin d'analyse un graphique tout moche (pour moi) et inutile. Mais ça n'est pas bien important, ça.

**Sve@r** · 18/10/2014, 15h55

Envoyé par disedorgue

Ouah, interressant tout ça, et un simple "ls" dans ce répertoire cela dure combien de temps (et même un ls <nom_dun_fichier>) ?

Bon ben le ls dure un certain temps. De même avec ls <debut_de_nom*>. En revanche, ls <nom_exact> revient immédiatement

Envoyé par disedorgue

Après, pour information, et ceux qui peuvent être interresser, tune2fs, pour l'ext4 peut activer "dir_index" qui semble justement être fait pour les "gros" repertoires de ce genre

Oui mais c'est pour accélérer les recherches de fichiers, pas pour optimiser l'agrandissement.
J'ai modifié mon script. Maintenant j'ai mis un affichage tous les 1000 fichiers. Et j'affiche non seulement le temps mis depuis le début mais aussi le temps entre deux affichages successifs. Au bout de 6h30 il en est maintenant à 27 secondes pour générer 1000 fichiers.

Je pense le laisser tourner jusqu'à demain puis j'arrêterai

**c_mon_identifiant** · 18/10/2014, 21h48

Bonjour à toutes et à tous

fichtre!
Je ne m'attendais à noircir autant de pages avec mon répertoire.

Merci à tous, j'apprends néanmoins beaucoup de choses avec vous tous; mais de grâce arrêtez de vous chamailler.
Je n'ai pas encore reformater mon DD; aussi je vais essayé vos différentes remarques, mais malheureusement pas de sitôt.

Je vous tiendrai informé.
Bon dimanche à vous.
Georges

**Jipété** · 19/10/2014, 00h18

Envoyé par c_mon_identifiant

(...) mais de grâce arrêtez de vous chamailler. (...)

Mais on ne se chamaille pas ! On s'adore et on se tire la bourre en échangeant nos connaissances

Content que tu sois repassé par là car, oui, on aimerait bien connaître le fin mot de l'histoire.

**jack-ft** · 19/10/2014, 02h33

Hummm....

L'utilisateur disait que les commandes qu'il a essayées "bloquaient" la console!
D'après ce que dit Sve@r et confirmant ma remarque, j'ai bien l'impression que ce n'est pas forcément bloqué, mais juste très lent (voire très très lent (ou même très très très lent...))!
Sve@r, peux-tu nous dire quel est le temps d'un 'ls' sur ton "gros" directory?
c_mon_identifiant, peux-tu lancer et laisser tourner toute la nuit un "rm -rf vrl1e6L88y", juste pour voir!
Mais, au préalable, tu peux aussi tenter la manip qui suit.

Il existe une manière assez violente pour "écrabouiller" un répertoire que j'ai malencontreusement expérimentée il y a quelques lustres à l'insu de mon plein gré et qui m'a vacciné à vie (du moins jusqu'à ce que j'aie Alzheimer (ce qui ne saurait tarder))!
C'est l'effroyable commande "tar" qui, même en mode "noclobber" ne se gêne pas pour écraser là où elle extrait!
Voici la manip à suivre (en supposant que vrl1e6L88y ne se trouve PAS dans /tmp):

Code :

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

1
2
3
4
5
cd /tmp
echo coucou > vrl1e6L88y # pour créer un fichier de même nom que l'indéracinable, mais dans un autre répertoire (/tmp, en l'occurrence)
tar cf vrl1e6L88y.tar vrl1e6L88y # Création d'une archive contenant juste ce fichier
cd le-dir-ou-se-trouve-vrl1e6L88y
tar xf /tmp/vrl1e6L88y.tar   # l'extraction du fichier écrase le répertoire!

Voili voilou...

**Sve@r** · 19/10/2014, 07h10

Envoyé par jack-ft

Sve@r, peux-tu nous dire quel est le temps d'un 'ls' sur ton "gros" directory?
c_mon_identifiant, peux-tu lancer et laisser tourner toute la nuit un "rm -rf vrl1e6L88y", juste pour voir!

A peine 1mn23 pour un dossier de 59M. Et c'est l'affichage qui a pris du temps parce qu'en redirigeant vers /dev/null ça ne prend que 9s. Et ls debut_de_nom* ne prend que 4s. Et le rm, lui aussi, n'a pris que 15 secondes (20h de boulot pour en arriver là !!!). Et c_mon_identifiant n'a jamais donné la taille de son dossier. Donc à mon avis hypothèse à écarter.

Envoyé par jack-ft

Il existe une manière assez violente pour "écrabouiller" un répertoire que j'ai malencontreusement expérimentée il y a quelques lustres à l'insu de mon plein gré et qui m'a vacciné à vie (du moins jusqu'à ce que j'aie Alzheimer (ce qui ne saurait tarder))!
C'est l'effroyable commande "tar" qui, même en mode "noclobber" ne se gêne pas pour écraser là où elle extrait!
Voici la manip à suivre (en supposant que vrl1e6L88y ne se trouve PAS dans /tmp):
[CODE]cd /tmp
echo coucou > vrl1e6L88y # pour créer un fichier de même nom que l'indéracinable, mais dans un autre répertoire (/tmp, en l'occurrence)
tar cf vrl1e6L88y.tar vrl1e6L88y # Création d'une archive contenant juste ce fichier
cd le-dir-ou-se-trouve-vrl1e6L88y
tar xf /tmp/vrl1e6L88y.tar # l'extraction du fichier écrase le répertoire!

Plus maintenant. T'as dû faire ça à une époque de la préhistoire.

Maintenant, tar détecte l'existence du dossier du même nom et se refuse à l'écraser

**Jipété** · 19/10/2014, 10h17

Salut,

Envoyé par Sve@r

Et c_mon_identifiant n'a jamais donné la taille de son dossier. Donc à mon avis hypothèse à écarter.

Et c'est quoi, ça, suite à une demande de disedorgue (ls -lb) ?

Envoyé par c_mon_identifiant

drwxrwxr-x 2 georges georges 495988736 oct. 14 09:03 vrl1e6LK88y/ ( de couleur bleu le rép.- classique)

'reusement que je suis

**jack-ft** · 20/10/2014, 10h46

Envoyé par Sve@r

Plus maintenant. T'as dû faire ça à une époque de la préhistoire.

Maintenant, tar détecte l'existence du dossier du même nom et se refuse à l'écraser

Ben... en fait... je l'ai testé sur mon Terminal juste avant de le poster...
Je sais que Snow Leopard n'est pas très récent...
De là à en déduire qu'il date de la préhistoire...

Et c'est pas le seul:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
$ mkdir vrl1e6L88y
$ mkdir tmp
$ cd tmp
$ echo coucou > vrl1e6L88y
$ tar cf vrl1e6L88y.tar vrl1e6L88y
$ cd ..
$ ls -lR
.:
total 0
drwxrwxr-x+ 1 jduthen mkpasswd 0 20 oct.  09:34 tmp/
drwxrwxr-x+ 1 jduthen mkpasswd 0 20 oct.  09:34 vrl1e6L88y/
 
./tmp:
total 13
-rw-rw-r-- 1 jduthen mkpasswd     7 20 oct.  09:34 vrl1e6L88y
-rw-rw-r-- 1 jduthen mkpasswd 10240 20 oct.  09:34 vrl1e6L88y.tar
 
./vrl1e6L88y:
total 0
$ tar xf tmp/vrl1e6L88y.tar
$ ls -l
total 1
drwxrwxr-x+ 1 jduthen mkpasswd 0 20 oct.  09:34 tmp/
-rw-rw-r--  1 jduthen mkpasswd 7 20 oct.  09:34 vrl1e6L88y
$ uname -a
CYGWIN_NT-6.1 ITEM-73566 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin

**Sve@r** · 20/10/2014, 17h11

Envoyé par jack-ft

Ben... en fait... je l'ai testé sur mon Terminal juste avant de le poster...

Ok, tu m'as convaincu. T'as un tar performant et fiable

T'est-il possible de tester avec GNU tar s'il est dispo ? Et aussi me donner la version de ton tar... De mon coté j'ai aussi testé sur Linux qui utilise par défaut gnu-tar (v1.23 pour moi)...

Je bloque pour supprimer un répertoire récalcitrant

Shell et commandes GNU

Discussions similaires

Partager

Partager