Racine presque pleine

[mézig]

Dernier message de la page précédente :

bien Mezig,
mais pourquoi vouloir absolument installer un log

93 Ko le logiciel
et j'ai proposé Baobab, meme si je prefere ncdu
les deux font le meme boulot

alors "df" qu'installé de base, fait aussi bien le boulot voir mieux.

Pas mieux et il ne permet pas de supprimer les fichiers
ncdu permet d'ouvrir les dossier d'y navigué et supprimer ce qui est encombrant plus légèrement qu'une interface graphique , la ce n'est pas vraiment nécessaire mais des fois !...

On dirait que c'est les sauvegardes que je fais sur un second disque (sdb) qui se sont placés dans corbeille

De forte chance ta partition sauvegarde est pleine aussi

33 Go de gagné , ça vaut le coup

[zeb]

Super zeb pour l'hébergement, t'es un chef

oui, je sais

[Mia88]

C'est cool que tu es pu identifié d'où venait la "prise de poids" de ton système

Oui, mais le dossier volumineux 322E0F4B7C7E5E4C refusait d'être supprimé, que ça soit en utilisant nemo avec privilèges élevés, ou en root depuis le terminal.

Je me suis finalement rendue compte que ce dossier, qui d'après Baobad se trouve dans /root/.local/share/Trash/files, apparaît aussi dans /.Trash-0/files.
Et depuis cet endroit, j'ai enfin pu le supprimer ! (avec sudo nemo sinon le dossier apparaît comme vide).



Petit apparté à propos de nemo : quand je l'ouvre en root j'ai ces messages d'erreur, mais ça s'ouvre, c'est gênant ?

Code : Tout sélectionner

mia@mia-PC4 ~ $ sudo nemo

(nemo:17382): Gtk-WARNING **: Failed to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

** (nemo:17382): WARNING **: Could not inhibit power management: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.gnome.SessionManager" does not exist

** (xed:19449): WARNING **: Set document metadata failed: La définition de l’attribut metadata::xed-position n’est pas prise en charge

** (xed:19486): WARNING **: Set document metadata failed: La définition de l’attribut metadata::xed-position n’est pas prise en charge

D'après Google Traduction : "Message Gtk: GtkDialog mappé sans parent transitoire. Ceci est découragé."

Par contre, je suis curieux de savoir pourquoi le dossier trash enregistré tes sauvegardes ?

J'ai une tite idée : j'ai changé l'emplacement des sauvegardes il y a un ou deux mois, j'ai donc supprimé l'ancienne sauvegarde pour recommencer à zéro.

De forte chance ta partition sauvegarde est pleine aussi

Elle n'est pas tout à fait pleine, il restait 2 Gio hier, mais ta remarque mérite réflexion parce qu'il se passe des trucs bizarres avec TimeShift.

Je sauvegarde tout, système+home+root, en programmation horaire.
380 Go sont utilisés sur mon disque sda.
Or, sa sauvegarde sur sdb fait 464.13 Gio, comment est-ce possible ?

Comme je l'explique plus haut, il y a quelque temps, j'ai du recommencer une nouvelle sauvegarde parce-que la partition était quasiment pleine, je lui ai cette fois attribué 500 Go, les premières sauvegardes correspondent à peu près au poids de sda, puis s'en éloignent au fur et à mesure, alors que je garde très peu d'instantanés.
On dirait que la sauvegarde n'est pas vraiment incrémentielle...
Et la suppression d'instantanés ne permet pas de récupérer grand chose comme place.

Mais le problème de racine pleine est résolu ! Elle fait maintenant 11 Go, c'est tout bon
J'ai été bien avisée de vous demander votre avis avant d'agrandir la partition
Merci à tous

[mézig]

Elle n'est pas tout à fait pleine, il restait 2 Gio hier, mais ta remarque mérite réflexion parce qu'il se passe des trucs bizarres avec TimeShift.

Je n'en suis pas encore la avec Timeshift ( mon dd est a la moitié) , mais je pense qu'il supprime les plus anciens "points de restauration"
mais dans ce cas c'est curieux qu'il ne les supprime pas définitivement

Et la suppression d'instantanés ne permet pas de récupérer grand chose comme place.

le probleme vient peut etre de ça , tu as supprimé des instantanés

[Mia88]

le probleme vient peut etre de ça , tu as supprimé des instantanés

Il me semble que c'est étudié pour, sinon pourquoi il y aurait l'option par clic droit ?



Ça doit fonctionner un peu comme les instantanés de VirtualBox, lorsque tu en supprimes un, l'attachement se refait proprement.
Je peux me tromper, mais il me semble que le problème est ailleurs.
En fait, ça merdouille depuis que j'ai voulu faire d'une pierre deux coups en incluant le home et root dans la sauvegarde.

[zeb]

Coucou Mia
Il me semble que quand tu supprimes, le fichier est simplement déplacé dans la corbeille, donc il occupe toujours la même place.
Pour ce faire, tu vas dans la corbeille et tu supprimes, cette fois ci, il sera bien supprimer

[tyrry]

Slt ,

Je me suis finalement rendue compte que ce dossier, qui d'après Baobad se trouve dans /root/.local/share/Trash/files, apparaît aussi dans /.Trash-0/files.

Du coup je comprend mieux pourquoi la commande ne fonctionnait pas , puisque pas le bon chemin
@+

[Mia88]

Coucou Zebulon et Tyrry

Il me semble que quand tu supprimes, le fichier est simplement déplacé dans la corbeille

Je viens de faire le tour des corbeilles (avec privilèges élevés) :

./Trash-0 qui est à la racine du système doit être la corbeille du système.
C'est là que s'est retrouvé la totalité du contenu de TimeShift quand je l'ai supprimé pour recommencer tout depuis le début.
Le dossier file à présent vide.
Le dossier info indique bien que je l'ai supprimé hier.


/home/mia/.local/share/Trash qui est la corbeille partagée des users.
J'y retrouve les fichiers courants que j'ai supprimés depuis ma session.
Il n'y a aucun instantané à cet endroit.

/root/.local/share/Trash qui est la corbeille de root.
C'est vide, je n'ai jamais crée ou supprimé de fichiers puisque je ne me logue pas en root.

Je ne sais pas où sont envoyés les instantanés supprimés, je cherche...

Du coup je comprend mieux pourquoi la commande ne fonctionnait pas , puisque pas le bon chemin

Oui, mais c'est curieux que l'analyseur de disques indique un chemin alors que le fichier se trouve ailleurs
Il n'y a apparemment pas de relation entre les 2 emplacements, je l'ai vérifié, le fichier se trouve uniquement dans /.Trash.0 et n'est pas lié dans /root/.local/share/Trash

J'essaye de comprendre pourquoi les sauvegardes de Timeshift occupent plus de place que la cible.
Et en prenant le temps de m'y attarder, je m'aperçois que baobad est pas mal du tout

Ce matin,depuis GParted :

- ma sauvegarde Timeshift (sdb1) occupe 433.19 Gio et 32.97 Gio sont inutilisés
- la racine sda2 11.71 Gio et le home sda5 367.11 Gio, soit 378.82 Gio
Il y a 54 Gio de trop.

Depuis baobad pour sdb1 je vois 3 snapshots (ça correspond bien depuis Timeshift) :

1 - svg auto horaire 23/08/2018 à 19h = 389.7 Go dont home 376.1 Go = 362.28 Gio dont home 350.18 Gio
Je développe, toujours depuis baobab, le fichier /.trash-0, et constate qu'il y a un élément, or cet élément n'est pas visible depuis nemo en root !
Je ne peux pas l'ouvrir depuis baobad, mais je récupère le chemin :
/media/root/SVG TimeShift/timeshift/snapshots/2018-08-23_19-00-01/localhost/.Trash-0/files

Ce qui m'a permis de trouver où se trouve la corbeille des instantanés de TimeShift,


2 - svg à la demande 13/08/2018 = 67.9 Go = 62.4 Gio
3 - svg auto horaire 23/08//2018 à 20h = 672 Mo = 0.63 Gio

Bon, ça a l'air de se tenir tout de même.

Comme j'ai mis en place une programmation horaire, et que j'ai paramétré le planning pour conserver uniquement 3 instantanés, ça a bougé depuis que j'ai commencé la rédaction du message.
Je constate que les instantanés qui sont supprimés automatiquement par TimeShift n'apparaissent plus nulle part.
Et la place libre reste à peu près identique (34.1 GB).