Grosse disparition d'espace disque : 80 Go sur un disque de 160 !
21 réponses
pas.de.spam
Bonsoir à tous,
J'ai un copain médecin qui utilise un iMac pour son cabinet. Il s'agit
d'un iMac Intel Core 2 Duo, avec 1 Go de RAM.
Il a un disque dur de 160 Go, 148 Go utilisables.
Il ne lui reste que 13 Go d'espace disponible, alos que la somme de tous
les dossiers visibles ne fait que 50 Go. Il lui manque donc plus de 80
Go.
A votre avis, qu'a-t'il pu se passer pour lui bouffer une telle quantité
de RAM ?
J'ai vérifié la taille des fichiers de swap, et il n'en avait qu'un de
64 Mo. De toute façon, la taille disparue était bien trop grosse pour
que ce ne soit dû qu'à cela.
Je me souviens d'un truc similaire rapporté dans ce forum, il y a pas
mal de temps, où une sauvegarde programmée s'était produite en l'absence
de branchement du disque de destination. Il y avait une histoire de
point de montage.
Mon collègue a effectivement une sauvegarde programmée. Mais, a priori,
le disque est toujours monté, et d'autre part, l'intégralité de ces
donnes ne représentent "que" 10 Go.
Pourriez-vous me raffraîchir la mémoire concernant les opérations à
effectuer pour retrouver la trace de ces Go disparus.
j'ai téléchargé DiskInventory X et j'essayerais de voir ça.
cela dit, si vous avez quelques recettes simples qu'il pourrait
appliquer en mon absence, entre 2 patients, cela pourrait aider.
j'ai téléchargé DiskInventory X et j'essayerais de voir ça.
cela dit, si vous avez quelques recettes simples qu'il pourrait appliquer en mon absence, entre 2 patients, cela pourrait aider.
WhatSize fonctionne très bien pour localiser ce genre de choses.
FiLH -- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
j'ai téléchargé DiskInventory X et j'essayerais de voir ça.
cela dit, si vous avez quelques recettes simples qu'il pourrait
appliquer en mon absence, entre 2 patients, cela pourrait aider.
WhatSize fonctionne très bien pour localiser ce genre de choses.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
j'ai téléchargé DiskInventory X et j'essayerais de voir ça.
cela dit, si vous avez quelques recettes simples qu'il pourrait appliquer en mon absence, entre 2 patients, cela pourrait aider.
WhatSize fonctionne très bien pour localiser ce genre de choses.
FiLH -- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
pas.de.spam
FiLH wrote:
(Pierre-Olivier TAUBATY) writes:
j'ai téléchargé DiskInventory X et j'essayerais de voir ça.
cela dit, si vous avez quelques recettes simples qu'il pourrait appliquer en mon absence, entre 2 patients, cela pourrait aider.
WhatSize fonctionne très bien pour localiser ce genre de choses.
FiLH
j'ai testé, what size n'a strictement rien trouvé. Il ne fait apparaître que les 50 et quelques gigas réellement utilisés (plus quelques dossiers invisibles). -- PO.
j'ai téléchargé DiskInventory X et j'essayerais de voir ça.
cela dit, si vous avez quelques recettes simples qu'il pourrait
appliquer en mon absence, entre 2 patients, cela pourrait aider.
WhatSize fonctionne très bien pour localiser ce genre de choses.
FiLH
j'ai testé, what size n'a strictement rien trouvé. Il ne fait apparaître
que les 50 et quelques gigas réellement utilisés (plus quelques dossiers
invisibles).
--
PO.
j'ai téléchargé DiskInventory X et j'essayerais de voir ça.
cela dit, si vous avez quelques recettes simples qu'il pourrait appliquer en mon absence, entre 2 patients, cela pourrait aider.
WhatSize fonctionne très bien pour localiser ce genre de choses.
FiLH
j'ai testé, what size n'a strictement rien trouvé. Il ne fait apparaître que les 50 et quelques gigas réellement utilisés (plus quelques dossiers invisibles). -- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Nicolas.MICHEL
Pierre-Olivier TAUBATY wrote:
$ sudo du -hs /Volumes/
La réponse de la machine est 43 G. Or il lui manque près du double.
Salut
déjà, c'est
sudo du -hs /Volumes/*
qu'il faut faire. Ensuite il y a quelques trucs à regarder avant d'en arriver là :
- la taille du spool (/var/spool) - l'existance (ou non) de dossiers dans /Volumes - la taille des dossiers /tmp et /var/tmp
Puis tu peux regarder à la racine :
sudo du -hs /*
Mais évidement ici tous les résultats ne seront pas forcément cohérents, par exemple /dev donnera un truc étrange. -- Nicolas
La réponse de la machine est 43 G. Or il lui manque près du double.
Salut
déjà, c'est
sudo du -hs /Volumes/*
qu'il faut faire. Ensuite il y a quelques trucs à regarder avant d'en arriver là :
- la taille du spool (/var/spool) - l'existance (ou non) de dossiers dans /Volumes - la taille des dossiers /tmp et /var/tmp
Puis tu peux regarder à la racine :
sudo du -hs /*
Mais évidement ici tous les résultats ne seront pas forcément cohérents, par exemple /dev donnera un truc étrange. -- Nicolas
Eric Levenez
Le 16/01/07 9:00, dans <1hs17t6.1b887fs1p3xxboN%, « Pierre-Olivier TAUBATY » a écrit :
Je me suis inspiré de cette commande et ait demandé à mon ami de taper la commande suivante :
$ sudo du -hs /Volumes/
La réponse de la machine est 43 G. Or il lui manque près du double.
Il lui manque par rapport à quoi ? /Volumes devrait être vide si il n'y a pas de montage de disques externe.
cette même commande chez moi, fut très longue a aboutir et me retourne un 1,2 T
Il te trouve 1,2 To sur des disques externes.
j'ai 7 disques durs : deux internes SATA de 400 Go, deux externe FW800 de 400 Go, un externe FW400 de 200 GO, et actuellement un seul USB 2 de 250 Go.
Que penser de ces résultats ?
Que tu as 1,2 To de pris sur des disques externes.
Cela ne dit rien de la place prise sur le disque interne de boot.
Il faut démonter tous les disques externes pour avoir une chance de trouver où se trouvent les données en trop sur le disque interne. Ou alors je n'ai aps compris ce que tu recherchais.
Si des fichiers cachés dus à une sauvegarde défectueuse étaient présents, comment pourrait-on les voir.
Si ils sont sous le points de montage, tu ne peux pas.
Il faut démonter tous les disques externes pour voir cela
j'ai tenté une commande $ ls -l /volumes et cela ne donne que la liste des volumes montés.
Oui.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 16/01/07 9:00, dans <1hs17t6.1b887fs1p3xxboN%pas.de.spam@chez.moi>,
« Pierre-Olivier TAUBATY » <pas.de.spam@chez.moi> a écrit :
Je me suis inspiré de cette commande et ait demandé à mon ami de taper
la commande suivante :
$ sudo du -hs /Volumes/
La réponse de la machine est 43 G. Or il lui manque près du double.
Il lui manque par rapport à quoi ? /Volumes devrait être vide si il n'y a
pas de montage de disques externe.
cette même commande chez moi, fut très longue a aboutir et me retourne
un 1,2 T
Il te trouve 1,2 To sur des disques externes.
j'ai 7 disques durs : deux internes SATA de 400 Go, deux externe FW800
de 400 Go, un externe FW400 de 200 GO, et actuellement un seul USB 2 de
250 Go.
Que penser de ces résultats ?
Que tu as 1,2 To de pris sur des disques externes.
Cela ne dit rien de la place prise sur le disque interne de boot.
Il faut démonter tous les disques externes pour avoir une chance de trouver
où se trouvent les données en trop sur le disque interne. Ou alors je n'ai
aps compris ce que tu recherchais.
Si des fichiers cachés dus à une sauvegarde défectueuse étaient
présents, comment pourrait-on les voir.
Si ils sont sous le points de montage, tu ne peux pas.
Il faut démonter tous les disques externes pour voir cela
j'ai tenté une commande $ ls -l /volumes et cela ne donne que la liste
des volumes montés.
Oui.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 16/01/07 9:00, dans <1hs17t6.1b887fs1p3xxboN%, « Pierre-Olivier TAUBATY » a écrit :
Je me suis inspiré de cette commande et ait demandé à mon ami de taper la commande suivante :
$ sudo du -hs /Volumes/
La réponse de la machine est 43 G. Or il lui manque près du double.
Il lui manque par rapport à quoi ? /Volumes devrait être vide si il n'y a pas de montage de disques externe.
cette même commande chez moi, fut très longue a aboutir et me retourne un 1,2 T
Il te trouve 1,2 To sur des disques externes.
j'ai 7 disques durs : deux internes SATA de 400 Go, deux externe FW800 de 400 Go, un externe FW400 de 200 GO, et actuellement un seul USB 2 de 250 Go.
Que penser de ces résultats ?
Que tu as 1,2 To de pris sur des disques externes.
Cela ne dit rien de la place prise sur le disque interne de boot.
Il faut démonter tous les disques externes pour avoir une chance de trouver où se trouvent les données en trop sur le disque interne. Ou alors je n'ai aps compris ce que tu recherchais.
Si des fichiers cachés dus à une sauvegarde défectueuse étaient présents, comment pourrait-on les voir.
Si ils sont sous le points de montage, tu ne peux pas.
Il faut démonter tous les disques externes pour voir cela
j'ai tenté une commande $ ls -l /volumes et cela ne donne que la liste des volumes montés.
Oui.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 16/01/07 10:37, dans <1hs12m5.10jzrka1hpuwoiN%, « Nicolas MICHEL » a écrit :
Pierre-Olivier TAUBATY wrote:
$ sudo du -hs /Volumes/
La réponse de la machine est 43 G. Or il lui manque près du double.
Salut
déjà, c'est
sudo du -hs /Volumes/*
qu'il faut faire.
Ça c'est pour voir la taille prise sur les volumes externes. Or j'ai compris que c'est sur le volume interne qu'il y a un problème.
De plus cette commande ne comptabilise par les répertoires éventuels commençant par un point sous /Volumes.
Ensuite il y a quelques trucs à regarder avant d'en arriver là :
- la taille du spool (/var/spool) - l'existance (ou non) de dossiers dans /Volumes - la taille des dossiers /tmp et /var/tmp
Puis tu peux regarder à la racine :
sudo du -hs /* ll Mais évidement ici tous les résultats ne seront pas forcément cohérents, par exemple /dev donnera un truc étrange.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 16/01/07 10:37, dans <1hs12m5.10jzrka1hpuwoiN%Nicolas.MICHEL@BonBon.net>,
« Nicolas MICHEL » <Nicolas.MICHEL@BonBon.net> a écrit :
Le 16/01/07 10:37, dans <1hs12m5.10jzrka1hpuwoiN%, « Nicolas MICHEL » a écrit :
Pierre-Olivier TAUBATY wrote:
$ sudo du -hs /Volumes/
La réponse de la machine est 43 G. Or il lui manque près du double.
Salut
déjà, c'est
sudo du -hs /Volumes/*
qu'il faut faire.
Ça c'est pour voir la taille prise sur les volumes externes. Or j'ai compris que c'est sur le volume interne qu'il y a un problème.
De plus cette commande ne comptabilise par les répertoires éventuels commençant par un point sous /Volumes.
Ensuite il y a quelques trucs à regarder avant d'en arriver là :
- la taille du spool (/var/spool) - l'existance (ou non) de dossiers dans /Volumes - la taille des dossiers /tmp et /var/tmp
Puis tu peux regarder à la racine :
sudo du -hs /* ll Mais évidement ici tous les résultats ne seront pas forcément cohérents, par exemple /dev donnera un truc étrange.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Nicolas.MICHEL
Eric Levenez wrote:
Ça c'est pour voir la taille prise sur les volumes externes. Or j'ai compris que c'est sur le volume interne qu'il y a un problème.
Non, c'est pour voir s'il existe un dossier qui n'est pas un volume. Dureste, il faudrait pour bien faire débrancher les disques externes et démonter les disques réseau avant.
Si tu as un soft fait pour sauvegarder / sur /Volumes/Disque-ext, et si ce backup se déclanche à un moment où le disque n'est pas présent alors tu disque fort ce créer un dossier /Volumes/Disque-externe.
Au prochain backup, ce dossier /Volumes/Disque-externe risque bien de contennir également le backup de /Volumes/Disque-externe, c'est à dire que tu vas le dupliquer à l'infini.
Si après ça tu rebranche le disque, il prendra le nom /Volumes/Disque-externe-1 mais sur le bureau apparaitra en tant que "Disque-externe" et tu pourrais bien ne pas t'en apercevoir...
J'ai même vu une fois un cas où il y avait /Volumes/Disque-externe /Volumes/Disque-externe-1 /Volumes/Disque-externe-2 /Volumes/Disque-externe-3
soit une duplication de tout ton disque 3x en local et 1x sur le disque externe ...
De plus cette commande ne comptabilise par les répertoires éventuels commençant par un point sous /Volumes.
Oui, ça c'est vrais. Un truc genre % sudo du -sh ./* ./.[^.]* serait mieux, mais pas encore parfait ...
Moi et les regex ... :)
-- Nicolas
Eric Levenez <news@levenez.com> wrote:
Ça c'est pour voir la taille prise sur les volumes externes. Or j'ai compris
que c'est sur le volume interne qu'il y a un problème.
Non, c'est pour voir s'il existe un dossier qui n'est pas un volume.
Dureste, il faudrait pour bien faire débrancher les disques externes et
démonter les disques réseau avant.
Si tu as un soft fait pour sauvegarder / sur /Volumes/Disque-ext,
et si ce backup se déclanche à un moment où le disque n'est pas présent
alors tu disque fort ce créer un dossier /Volumes/Disque-externe.
Au prochain backup, ce dossier /Volumes/Disque-externe risque bien de
contennir également le backup de /Volumes/Disque-externe, c'est à dire
que tu vas le dupliquer à l'infini.
Si après ça tu rebranche le disque, il prendra le nom
/Volumes/Disque-externe-1 mais sur le bureau apparaitra en tant que
"Disque-externe" et tu pourrais bien ne pas t'en apercevoir...
J'ai même vu une fois un cas où il y avait
/Volumes/Disque-externe
/Volumes/Disque-externe-1
/Volumes/Disque-externe-2
/Volumes/Disque-externe-3
soit une duplication de tout ton disque 3x en local et 1x sur le disque
externe ...
De plus cette commande ne comptabilise par les répertoires éventuels
commençant par un point sous /Volumes.
Oui, ça c'est vrais. Un truc genre
% sudo du -sh ./* ./.[^.]*
serait mieux, mais pas encore parfait ...
Ça c'est pour voir la taille prise sur les volumes externes. Or j'ai compris que c'est sur le volume interne qu'il y a un problème.
Non, c'est pour voir s'il existe un dossier qui n'est pas un volume. Dureste, il faudrait pour bien faire débrancher les disques externes et démonter les disques réseau avant.
Si tu as un soft fait pour sauvegarder / sur /Volumes/Disque-ext, et si ce backup se déclanche à un moment où le disque n'est pas présent alors tu disque fort ce créer un dossier /Volumes/Disque-externe.
Au prochain backup, ce dossier /Volumes/Disque-externe risque bien de contennir également le backup de /Volumes/Disque-externe, c'est à dire que tu vas le dupliquer à l'infini.
Si après ça tu rebranche le disque, il prendra le nom /Volumes/Disque-externe-1 mais sur le bureau apparaitra en tant que "Disque-externe" et tu pourrais bien ne pas t'en apercevoir...
J'ai même vu une fois un cas où il y avait /Volumes/Disque-externe /Volumes/Disque-externe-1 /Volumes/Disque-externe-2 /Volumes/Disque-externe-3
soit une duplication de tout ton disque 3x en local et 1x sur le disque externe ...
De plus cette commande ne comptabilise par les répertoires éventuels commençant par un point sous /Volumes.
Oui, ça c'est vrais. Un truc genre % sudo du -sh ./* ./.[^.]* serait mieux, mais pas encore parfait ...
Moi et les regex ... :)
-- Nicolas
Nicolas.MICHEL
Eric Levenez wrote:
Le 16/01/07 9:00, dans <1hs17t6.1b887fs1p3xxboN%,
Si des fichiers cachés dus à une sauvegarde défectueuse étaient présents, comment pourrait-on les voir.
Si ils sont sous le points de montage, tu ne peux pas.
Si c'est un mount fait "normalement", c'est à dire par automount sans bidouillage express, tu ne peux pas monter un disque sur un point de montage existant. Si le dossier existe, il crée un dossier du même nom+1
Il faut démonter tous les disques externes pour voir cela
Oui, c'est mieux.
après, un "simple" "pomme maj G" pour aller au dossier /Volumes te montrera s'il y a un "résidu"
j'ai tenté une commande $ ls -l /volumes et cela ne donne que la liste des volumes montés.
Oui.
Dans ce cas, /Volumes ne contient pas de "résidu" -- Nicolas
Eric Levenez <news@levenez.com> wrote:
Le 16/01/07 9:00, dans <1hs17t6.1b887fs1p3xxboN%pas.de.spam@chez.moi>,
Si des fichiers cachés dus à une sauvegarde défectueuse étaient
présents, comment pourrait-on les voir.
Si ils sont sous le points de montage, tu ne peux pas.
Si c'est un mount fait "normalement", c'est à dire par automount sans
bidouillage express, tu ne peux pas monter un disque sur un point de
montage existant. Si le dossier existe, il crée un dossier du même nom+1
Il faut démonter tous les disques externes pour voir cela
Oui, c'est mieux.
après, un "simple" "pomme maj G" pour aller au dossier /Volumes te
montrera s'il y a un "résidu"
j'ai tenté une commande $ ls -l /volumes et cela ne donne que la liste
des volumes montés.
Oui.
Dans ce cas, /Volumes ne contient pas de "résidu"
--
Nicolas
Si des fichiers cachés dus à une sauvegarde défectueuse étaient présents, comment pourrait-on les voir.
Si ils sont sous le points de montage, tu ne peux pas.
Si c'est un mount fait "normalement", c'est à dire par automount sans bidouillage express, tu ne peux pas monter un disque sur un point de montage existant. Si le dossier existe, il crée un dossier du même nom+1
Il faut démonter tous les disques externes pour voir cela
Oui, c'est mieux.
après, un "simple" "pomme maj G" pour aller au dossier /Volumes te montrera s'il y a un "résidu"
j'ai tenté une commande $ ls -l /volumes et cela ne donne que la liste des volumes montés.
Oui.
Dans ce cas, /Volumes ne contient pas de "résidu" -- Nicolas
pas.de.spam
Nicolas MICHEL wrote:
Eric Levenez wrote:
Ça c'est pour voir la taille prise sur les volumes externes. Or j'ai compris que c'est sur le volume interne qu'il y a un problème.
Non, c'est pour voir s'il existe un dossier qui n'est pas un volume. Dureste, il faudrait pour bien faire débrancher les disques externes et démonter les disques réseau avant.
Si tu as un soft fait pour sauvegarder / sur /Volumes/Disque-ext, et si ce backup se déclanche à un moment où le disque n'est pas présent alors tu disque fort ce créer un dossier /Volumes/Disque-externe.
Au prochain backup, ce dossier /Volumes/Disque-externe risque bien de contennir également le backup de /Volumes/Disque-externe, c'est à dire que tu vas le dupliquer à l'infini.
Si après ça tu rebranche le disque, il prendra le nom /Volumes/Disque-externe-1 mais sur le bureau apparaitra en tant que "Disque-externe" et tu pourrais bien ne pas t'en apercevoir...
J'ai même vu une fois un cas où il y avait /Volumes/Disque-externe /Volumes/Disque-externe-1 /Volumes/Disque-externe-2 /Volumes/Disque-externe-3
soit une duplication de tout ton disque 3x en local et 1x sur le disque externe ...
De plus cette commande ne comptabilise par les répertoires éventuels commençant par un point sous /Volumes.
Oui, ça c'est vrais. Un truc genre % sudo du -sh ./* ./.[^.]* serait mieux, mais pas encore parfait ...
Moi et les regex ... :)
En fait, j'ai eu des précisions supplémentaires. Comme je l'ai dit mon copain est toubib. Sa base de Travail est sur un disque externe NAS, partagé entre son poste de travail et celui de sa secrétaire. Régulièrement il fait une sauvegarde de cette Base (environ 10 Go) sur le disque interne de son Mac (iMac intel), au moyen de Personnal Backup d'intego. Il a en plus un petit disque 2,5" branché en FW 400 (ou USB 2, je ne suis pas sûr).
c'est donc sur le disque interne de son mac qu'un peu plus de 80 Go ont disparus. Son disque de travail a 148,xx Go utilisables. La somme de tous les dossiers visibles, fait environ 50 Go, et il n'a plus "que" 12,xx Go de libre : Il lui manque donc environ 86 Go. Ce sont ces 86 Go que j'aimerait localiser. Je sais bien qu'il y a des dossiers invisibles pour le système, mais en aucun cas cela ne peut atteindre une telle taille.
Pour résumer les procédures à effectuer :
si je démonte tous les disques externes et que je fais un Pomme-G sur /Volumes, j'ai une chance de trouver quelque chose ? Mettre les disques à la corbeille (ou clic-droit : démonter) est-il suffisant ?
Sinon, à quel autre endroit pourraient se trouver ses @#&$*% de 86 Go ?
Je tâcherais également de lui demander de vérifier la taille de /var/spool.
Pourrait-on également envisager qu'un ou plusieurs fichier de log gonflent démesurément à cause d'une entrée répétitive. ceux-ci se trouvent-ils tous dans /var/spool ?
Merci infiniment de votre aide à tous les deux. -- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Nicolas MICHEL <Nicolas.MICHEL@BonBon.net> wrote:
Eric Levenez <news@levenez.com> wrote:
Ça c'est pour voir la taille prise sur les volumes externes. Or j'ai compris
que c'est sur le volume interne qu'il y a un problème.
Non, c'est pour voir s'il existe un dossier qui n'est pas un volume.
Dureste, il faudrait pour bien faire débrancher les disques externes et
démonter les disques réseau avant.
Si tu as un soft fait pour sauvegarder / sur /Volumes/Disque-ext,
et si ce backup se déclanche à un moment où le disque n'est pas présent
alors tu disque fort ce créer un dossier /Volumes/Disque-externe.
Au prochain backup, ce dossier /Volumes/Disque-externe risque bien de
contennir également le backup de /Volumes/Disque-externe, c'est à dire
que tu vas le dupliquer à l'infini.
Si après ça tu rebranche le disque, il prendra le nom
/Volumes/Disque-externe-1 mais sur le bureau apparaitra en tant que
"Disque-externe" et tu pourrais bien ne pas t'en apercevoir...
J'ai même vu une fois un cas où il y avait
/Volumes/Disque-externe
/Volumes/Disque-externe-1
/Volumes/Disque-externe-2
/Volumes/Disque-externe-3
soit une duplication de tout ton disque 3x en local et 1x sur le disque
externe ...
De plus cette commande ne comptabilise par les répertoires éventuels
commençant par un point sous /Volumes.
Oui, ça c'est vrais. Un truc genre
% sudo du -sh ./* ./.[^.]*
serait mieux, mais pas encore parfait ...
Moi et les regex ... :)
En fait, j'ai eu des précisions supplémentaires. Comme je l'ai dit mon
copain est toubib. Sa base de Travail est sur un disque externe NAS,
partagé entre son poste de travail et celui de sa secrétaire.
Régulièrement il fait une sauvegarde de cette Base (environ 10 Go) sur
le disque interne de son Mac (iMac intel), au moyen de Personnal Backup
d'intego. Il a en plus un petit disque 2,5" branché en FW 400 (ou USB 2,
je ne suis pas sûr).
c'est donc sur le disque interne de son mac qu'un peu plus de 80 Go ont
disparus. Son disque de travail a 148,xx Go utilisables. La somme de
tous les dossiers visibles, fait environ 50 Go, et il n'a plus "que"
12,xx Go de libre : Il lui manque donc environ 86 Go. Ce sont ces 86 Go
que j'aimerait localiser. Je sais bien qu'il y a des dossiers invisibles
pour le système, mais en aucun cas cela ne peut atteindre une telle
taille.
Pour résumer les procédures à effectuer :
si je démonte tous les disques externes et que je fais un Pomme-G sur
/Volumes, j'ai une chance de trouver quelque chose ? Mettre les disques
à la corbeille (ou clic-droit : démonter) est-il suffisant ?
Sinon, à quel autre endroit pourraient se trouver ses @#&$*% de 86 Go ?
Je tâcherais également de lui demander de vérifier la taille de
/var/spool.
Pourrait-on également envisager qu'un ou plusieurs fichier de log
gonflent démesurément à cause d'une entrée répétitive. ceux-ci se
trouvent-ils tous dans /var/spool ?
Merci infiniment de votre aide à tous les deux.
--
PO.
Ça c'est pour voir la taille prise sur les volumes externes. Or j'ai compris que c'est sur le volume interne qu'il y a un problème.
Non, c'est pour voir s'il existe un dossier qui n'est pas un volume. Dureste, il faudrait pour bien faire débrancher les disques externes et démonter les disques réseau avant.
Si tu as un soft fait pour sauvegarder / sur /Volumes/Disque-ext, et si ce backup se déclanche à un moment où le disque n'est pas présent alors tu disque fort ce créer un dossier /Volumes/Disque-externe.
Au prochain backup, ce dossier /Volumes/Disque-externe risque bien de contennir également le backup de /Volumes/Disque-externe, c'est à dire que tu vas le dupliquer à l'infini.
Si après ça tu rebranche le disque, il prendra le nom /Volumes/Disque-externe-1 mais sur le bureau apparaitra en tant que "Disque-externe" et tu pourrais bien ne pas t'en apercevoir...
J'ai même vu une fois un cas où il y avait /Volumes/Disque-externe /Volumes/Disque-externe-1 /Volumes/Disque-externe-2 /Volumes/Disque-externe-3
soit une duplication de tout ton disque 3x en local et 1x sur le disque externe ...
De plus cette commande ne comptabilise par les répertoires éventuels commençant par un point sous /Volumes.
Oui, ça c'est vrais. Un truc genre % sudo du -sh ./* ./.[^.]* serait mieux, mais pas encore parfait ...
Moi et les regex ... :)
En fait, j'ai eu des précisions supplémentaires. Comme je l'ai dit mon copain est toubib. Sa base de Travail est sur un disque externe NAS, partagé entre son poste de travail et celui de sa secrétaire. Régulièrement il fait une sauvegarde de cette Base (environ 10 Go) sur le disque interne de son Mac (iMac intel), au moyen de Personnal Backup d'intego. Il a en plus un petit disque 2,5" branché en FW 400 (ou USB 2, je ne suis pas sûr).
c'est donc sur le disque interne de son mac qu'un peu plus de 80 Go ont disparus. Son disque de travail a 148,xx Go utilisables. La somme de tous les dossiers visibles, fait environ 50 Go, et il n'a plus "que" 12,xx Go de libre : Il lui manque donc environ 86 Go. Ce sont ces 86 Go que j'aimerait localiser. Je sais bien qu'il y a des dossiers invisibles pour le système, mais en aucun cas cela ne peut atteindre une telle taille.
Pour résumer les procédures à effectuer :
si je démonte tous les disques externes et que je fais un Pomme-G sur /Volumes, j'ai une chance de trouver quelque chose ? Mettre les disques à la corbeille (ou clic-droit : démonter) est-il suffisant ?
Sinon, à quel autre endroit pourraient se trouver ses @#&$*% de 86 Go ?
Je tâcherais également de lui demander de vérifier la taille de /var/spool.
Pourrait-on également envisager qu'un ou plusieurs fichier de log gonflent démesurément à cause d'une entrée répétitive. ceux-ci se trouvent-ils tous dans /var/spool ?
Merci infiniment de votre aide à tous les deux. -- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Eric Levenez
Le 16/01/07 18:16, dans <1hs1xad.1l69evw6c1i4N%, « Pierre-Olivier TAUBATY » a écrit :
c'est donc sur le disque interne de son mac qu'un peu plus de 80 Go ont disparus. Son disque de travail a 148,xx Go utilisables. La somme de tous les dossiers visibles, fait environ 50 Go, et il n'a plus "que" 12,xx Go de libre : Il lui manque donc environ 86 Go. Ce sont ces 86 Go que j'aimerait localiser. Je sais bien qu'il y a des dossiers invisibles pour le système, mais en aucun cas cela ne peut atteindre une telle taille.
Pour résumer les procédures à effectuer :
si je démonte tous les disques externes et que je fais un Pomme-G sur /Volumes, j'ai une chance de trouver quelque chose ? Mettre les disques à la corbeille (ou clic-droit : démonter) est-il suffisant ?
Sinon, à quel autre endroit pourraient se trouver ses @#&$*% de 86 Go ?
Ce genre de choses, je le gérerai par dichotomie. Ce sera long, mais c'est une solution imparable.
Démonter tous les disques externes, bref couper la machine du monde La commande "mount" ne devrait trouver qu'un disque physique (ici: /dev/disk2) :
$ $ mount /dev/disk2 on / (local, journaled) devfs on /dev (local) fdesc on /dev (union) <volfs> on /.vol automount -nsl [155] on /Network (automounted) automount -fstab [209] on /automount/Servers (automounted) automount -static [209] on /automount/static (automounted)
$ ls -l /Volumes/ total 8 lrwxr-xr-x 1 root admin 1 Jan 16 18:15 Raid-HD -> /
La taille du disque est donnée par df :
$ df -kh / Filesystem Size Used Avail Capacity Mounted on /dev/disk2 468G 207G 260G 44% /
Ce qui dans mon cas fait 207 Go pris.
Ensuite aller à la racine et regarder les répertoire présents :
$ ls -wal /
Tout ce qui commence par "d" est un répertoire qu'il va falloir regarder dedans. Les répertoire à sauter sont dev et .vol. Il ne faut pas oublier les répertoires commençant par un point. La commande suivante fait ce tri :
find / -type d -maxdepth 1 ! -name / ! -name dev ! -name .vol -print
On lance la commande "du" pour regarder la taille de tous ces répertoires. La somme doit donner environ la taille utilisée sur le disque. Cela se fait (à taper sur une ligne et pas 2 comme affiché) :
$ sudo find / -type d -maxdepth 1 ! -name / ! -name dev ! -name .vol -exec du -sh {} ;
Si je somme le tout, j'obtient 206 Go, ce qui correspond aux 207 Go attendus (aux arrondis prêt).
Le truc sera pour toi de trouver quel répertoire est trop gros à ton goût. Il faudra alors aller dedans. Par exemple si tu supposes que c'est /Library alors tu fais :
cd /Library; sudo find . -type d -maxdepth 1 ! -name . -exec du -sh {} ;
Je tâcherais également de lui demander de vérifier la taille de /var/spool.
cd /private/var;sudo find . -type d -maxdepth 1 ! -name . -exec du -sh {} ;
Pourrait-on également envisager qu'un ou plusieurs fichier de log gonflent démesurément à cause d'une entrée répétitive. ceux-ci se trouvent-ils tous dans /var/spool ?
Tout est possible, c'est le jeu de la vie.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 16/01/07 18:16, dans <1hs1xad.1l69evw6c1i4N%pas.de.spam@chez.moi>,
« Pierre-Olivier TAUBATY » <pas.de.spam@chez.moi> a écrit :
c'est donc sur le disque interne de son mac qu'un peu plus de 80 Go ont
disparus. Son disque de travail a 148,xx Go utilisables. La somme de
tous les dossiers visibles, fait environ 50 Go, et il n'a plus "que"
12,xx Go de libre : Il lui manque donc environ 86 Go. Ce sont ces 86 Go
que j'aimerait localiser. Je sais bien qu'il y a des dossiers invisibles
pour le système, mais en aucun cas cela ne peut atteindre une telle
taille.
Pour résumer les procédures à effectuer :
si je démonte tous les disques externes et que je fais un Pomme-G sur
/Volumes, j'ai une chance de trouver quelque chose ? Mettre les disques
à la corbeille (ou clic-droit : démonter) est-il suffisant ?
Sinon, à quel autre endroit pourraient se trouver ses @#&$*% de 86 Go ?
Ce genre de choses, je le gérerai par dichotomie. Ce sera long, mais c'est
une solution imparable.
Démonter tous les disques externes, bref couper la machine du monde
La commande "mount" ne devrait trouver qu'un disque physique (ici:
/dev/disk2) :
$ $ mount
/dev/disk2 on / (local, journaled)
devfs on /dev (local)
fdesc on /dev (union)
<volfs> on /.vol
automount -nsl [155] on /Network (automounted)
automount -fstab [209] on /automount/Servers (automounted)
automount -static [209] on /automount/static (automounted)
$ ls -l /Volumes/
total 8
lrwxr-xr-x 1 root admin 1 Jan 16 18:15 Raid-HD -> /
La taille du disque est donnée par df :
$ df -kh /
Filesystem Size Used Avail Capacity Mounted on
/dev/disk2 468G 207G 260G 44% /
Ce qui dans mon cas fait 207 Go pris.
Ensuite aller à la racine et regarder les répertoire présents :
$ ls -wal /
Tout ce qui commence par "d" est un répertoire qu'il va falloir regarder
dedans. Les répertoire à sauter sont dev et .vol. Il ne faut pas oublier les
répertoires commençant par un point. La commande suivante fait ce tri :
find / -type d -maxdepth 1 ! -name / ! -name dev ! -name .vol -print
On lance la commande "du" pour regarder la taille de tous ces répertoires.
La somme doit donner environ la taille utilisée sur le disque. Cela se fait
(à taper sur une ligne et pas 2 comme affiché) :
$ sudo find / -type d -maxdepth 1 ! -name / ! -name dev ! -name .vol -exec
du -sh {} ;
Si je somme le tout, j'obtient 206 Go, ce qui correspond aux 207 Go attendus
(aux arrondis prêt).
Le truc sera pour toi de trouver quel répertoire est trop gros à ton goût.
Il faudra alors aller dedans. Par exemple si tu supposes que c'est /Library
alors tu fais :
cd /Library; sudo find . -type d -maxdepth 1 ! -name . -exec du -sh {} ;
Je tâcherais également de lui demander de vérifier la taille de
/var/spool.
cd /private/var;sudo find . -type d -maxdepth 1 ! -name . -exec du -sh {} ;
Pourrait-on également envisager qu'un ou plusieurs fichier de log
gonflent démesurément à cause d'une entrée répétitive. ceux-ci se
trouvent-ils tous dans /var/spool ?
Tout est possible, c'est le jeu de la vie.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 16/01/07 18:16, dans <1hs1xad.1l69evw6c1i4N%, « Pierre-Olivier TAUBATY » a écrit :
c'est donc sur le disque interne de son mac qu'un peu plus de 80 Go ont disparus. Son disque de travail a 148,xx Go utilisables. La somme de tous les dossiers visibles, fait environ 50 Go, et il n'a plus "que" 12,xx Go de libre : Il lui manque donc environ 86 Go. Ce sont ces 86 Go que j'aimerait localiser. Je sais bien qu'il y a des dossiers invisibles pour le système, mais en aucun cas cela ne peut atteindre une telle taille.
Pour résumer les procédures à effectuer :
si je démonte tous les disques externes et que je fais un Pomme-G sur /Volumes, j'ai une chance de trouver quelque chose ? Mettre les disques à la corbeille (ou clic-droit : démonter) est-il suffisant ?
Sinon, à quel autre endroit pourraient se trouver ses @#&$*% de 86 Go ?
Ce genre de choses, je le gérerai par dichotomie. Ce sera long, mais c'est une solution imparable.
Démonter tous les disques externes, bref couper la machine du monde La commande "mount" ne devrait trouver qu'un disque physique (ici: /dev/disk2) :
$ $ mount /dev/disk2 on / (local, journaled) devfs on /dev (local) fdesc on /dev (union) <volfs> on /.vol automount -nsl [155] on /Network (automounted) automount -fstab [209] on /automount/Servers (automounted) automount -static [209] on /automount/static (automounted)
$ ls -l /Volumes/ total 8 lrwxr-xr-x 1 root admin 1 Jan 16 18:15 Raid-HD -> /
La taille du disque est donnée par df :
$ df -kh / Filesystem Size Used Avail Capacity Mounted on /dev/disk2 468G 207G 260G 44% /
Ce qui dans mon cas fait 207 Go pris.
Ensuite aller à la racine et regarder les répertoire présents :
$ ls -wal /
Tout ce qui commence par "d" est un répertoire qu'il va falloir regarder dedans. Les répertoire à sauter sont dev et .vol. Il ne faut pas oublier les répertoires commençant par un point. La commande suivante fait ce tri :
find / -type d -maxdepth 1 ! -name / ! -name dev ! -name .vol -print
On lance la commande "du" pour regarder la taille de tous ces répertoires. La somme doit donner environ la taille utilisée sur le disque. Cela se fait (à taper sur une ligne et pas 2 comme affiché) :
$ sudo find / -type d -maxdepth 1 ! -name / ! -name dev ! -name .vol -exec du -sh {} ;
Si je somme le tout, j'obtient 206 Go, ce qui correspond aux 207 Go attendus (aux arrondis prêt).
Le truc sera pour toi de trouver quel répertoire est trop gros à ton goût. Il faudra alors aller dedans. Par exemple si tu supposes que c'est /Library alors tu fais :
cd /Library; sudo find . -type d -maxdepth 1 ! -name . -exec du -sh {} ;
Je tâcherais également de lui demander de vérifier la taille de /var/spool.
cd /private/var;sudo find . -type d -maxdepth 1 ! -name . -exec du -sh {} ;
Pourrait-on également envisager qu'un ou plusieurs fichier de log gonflent démesurément à cause d'une entrée répétitive. ceux-ci se trouvent-ils tous dans /var/spool ?
Tout est possible, c'est le jeu de la vie.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
pas.de.spam
Eric Levenez wrote:
[tout plein de choses]
ben dis donc, moi qui n'avais que peu tâté du terminal, en voila une commande qu'elle est pour un barbu ;-)
je testerais ça et rapporterais ici les résultats des investigations .
[reflexion in petto] pffff ! je sens que c'est pas gagné ;-) -- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Eric Levenez <news@levenez.com> wrote:
[tout plein de choses]
ben dis donc, moi qui n'avais que peu tâté du terminal, en voila une
commande qu'elle est pour un barbu ;-)
je testerais ça et rapporterais ici les résultats des investigations .
[reflexion in petto] pffff ! je sens que c'est pas gagné ;-)
--
PO.
