Bonjour,
j'ai l'impression que mon g4 800 1,25 RAM swappe beaucoup plus depuis le
passage à Panther.
Quand je regarde les activités, on distingue la RAM en quatre catégories
- réservée - utilisée - inactive et libre.
Quelqu'un peut me dire ce qui est la différence entre les deux
dernières.
Est-ce que ça commence à swapper quand il n'y a plus de mémoire libre?
Merci de vos lumières
martin
--
So have I heard and do in part believe it. - Horatio
Le 23/01/04 14:36, dans , « Patrick Stadelmann » a écrit :
In article <BC36DBF0.66B27%, Éric Lévénez wrote:
Cette astuce est très utilisée sous unix pour avoir un fichier temporaire sur disque que l'application n'aura pas à effacer : le programme crée un fichier et l'ouvre pour y écrire, puis le programme efface le fichier sans avoir fermé celui-ci. Le nom du fichier est alors effacé du répertoire, mais l'inode est toujours actif
Y a un moyen de voir que le fichier est en fait toujours là ? Sur Sun, je me souviens que dans ce cas je voyais un .nfsXXXX à la place du fichier, mais seulement en NFS, pas en local.
La commande "lsof" devrait le dire. Mais une fois que le nom du fichier a été effacé, même si l'inode est toujours en activité, on aura l'info sur l'inode, mais pas le ou les noms du fichier.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 23/01/04 14:36, dans
<Patrick.Stadelmann-2752AF.14360523012004@news.fu-berlin.de>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
In article <BC36DBF0.66B27%news@levenez.com>,
Éric Lévénez <news@levenez.com> wrote:
Cette astuce est très utilisée sous unix pour avoir un fichier temporaire
sur disque que l'application n'aura pas à effacer : le programme crée un
fichier et l'ouvre pour y écrire, puis le programme efface le fichier sans
avoir fermé celui-ci. Le nom du fichier est alors effacé du répertoire, mais
l'inode est toujours actif
Y a un moyen de voir que le fichier est en fait toujours là ? Sur Sun,
je me souviens que dans ce cas je voyais un .nfsXXXX à la place du
fichier, mais seulement en NFS, pas en local.
La commande "lsof" devrait le dire. Mais une fois que le nom du fichier a
été effacé, même si l'inode est toujours en activité, on aura l'info sur
l'inode, mais pas le ou les noms du fichier.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 23/01/04 14:36, dans , « Patrick Stadelmann » a écrit :
In article <BC36DBF0.66B27%, Éric Lévénez wrote:
Cette astuce est très utilisée sous unix pour avoir un fichier temporaire sur disque que l'application n'aura pas à effacer : le programme crée un fichier et l'ouvre pour y écrire, puis le programme efface le fichier sans avoir fermé celui-ci. Le nom du fichier est alors effacé du répertoire, mais l'inode est toujours actif
Y a un moyen de voir que le fichier est en fait toujours là ? Sur Sun, je me souviens que dans ce cas je voyais un .nfsXXXX à la place du fichier, mais seulement en NFS, pas en local.
La commande "lsof" devrait le dire. Mais une fois que le nom du fichier a été effacé, même si l'inode est toujours en activité, on aura l'info sur l'inode, mais pas le ou les noms du fichier.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article <BC36EAAC.66B4E%, Éric Lévénez wrote:
La commande "lsof" devrait le dire. Mais une fois que le nom du fichier a été effacé, même si l'inode est toujours en activité, on aura l'info sur l'inode, mais pas le ou les noms du fichier.
Avec "lsof +L1" on obtient en effet la liste de ces fichiers, mais seul le volume est indiqué (eg / alors que le fichier se trouvait dans /tmp). Y aurait pas un moyen de retrouver le chemin complet (sans le nom, bien sûr) ?
Patrick -- Patrick Stadelmann
In article <BC36EAAC.66B4E%news@levenez.com>,
Éric Lévénez <news@levenez.com> wrote:
La commande "lsof" devrait le dire. Mais une fois que le nom du fichier a
été effacé, même si l'inode est toujours en activité, on aura l'info sur
l'inode, mais pas le ou les noms du fichier.
Avec "lsof +L1" on obtient en effet la liste de ces fichiers, mais seul
le volume est indiqué (eg / alors que le fichier se trouvait dans /tmp).
Y aurait pas un moyen de retrouver le chemin complet (sans le nom, bien
sûr) ?
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
La commande "lsof" devrait le dire. Mais une fois que le nom du fichier a été effacé, même si l'inode est toujours en activité, on aura l'info sur l'inode, mais pas le ou les noms du fichier.
Avec "lsof +L1" on obtient en effet la liste de ces fichiers, mais seul le volume est indiqué (eg / alors que le fichier se trouvait dans /tmp). Y aurait pas un moyen de retrouver le chemin complet (sans le nom, bien sûr) ?
Patrick -- Patrick Stadelmann
Éric Lévénez
Le 23/01/04 15:51, dans , « Patrick Stadelmann » a écrit :
In article <BC36EAAC.66B4E%, Éric Lévénez wrote:
La commande "lsof" devrait le dire. Mais une fois que le nom du fichier a été effacé, même si l'inode est toujours en activité, on aura l'info sur l'inode, mais pas le ou les noms du fichier.
Avec "lsof +L1" on obtient en effet la liste de ces fichiers, mais seul le volume est indiqué (eg / alors que le fichier se trouvait dans /tmp). Y aurait pas un moyen de retrouver le chemin complet (sans le nom, bien sûr) ?
L'inode ne conserve pas le nom des fichiers.
Pour rechercher les noms d'un fichier connaissant sont numéro d'inode, on peut utiliser par exemple une commande du type :
find / -inum 987494 -ls
Comme l'identification d'un fichier est en fait un couple numéro d'inode + numéro de partition, la commande précédente affichera tous les noms des fichiers correspondant à l'inode 987494. Il faudrait en fait limiter le find sur la partition correspondant au numéro d'inode.
L'inode 987494 peut très bien correspondre au fichier /tmp/toto et /Users/truc/machin. Il aura donc un compteur de liens à 2. L'inode ne conserve rien comme nom, même par /tmp ou /users/truc. Cela ne serait pas faisable de plus si le fichier avait des milliers de liens.
Avec un inode qui n'a plus de nom (le nom a été effacé, et le compteur de lien est à 0) on ne peut retrouver ni son nom, ni son répertoire. Seul son numéro de partition sera gardé.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 23/01/04 15:51, dans
<Patrick.Stadelmann-F58FFD.15511523012004@news.fu-berlin.de>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
In article <BC36EAAC.66B4E%news@levenez.com>,
Éric Lévénez <news@levenez.com> wrote:
La commande "lsof" devrait le dire. Mais une fois que le nom du fichier a
été effacé, même si l'inode est toujours en activité, on aura l'info sur
l'inode, mais pas le ou les noms du fichier.
Avec "lsof +L1" on obtient en effet la liste de ces fichiers, mais seul
le volume est indiqué (eg / alors que le fichier se trouvait dans /tmp).
Y aurait pas un moyen de retrouver le chemin complet (sans le nom, bien
sûr) ?
L'inode ne conserve pas le nom des fichiers.
Pour rechercher les noms d'un fichier connaissant sont numéro d'inode, on
peut utiliser par exemple une commande du type :
find / -inum 987494 -ls
Comme l'identification d'un fichier est en fait un couple numéro d'inode +
numéro de partition, la commande précédente affichera tous les noms des
fichiers correspondant à l'inode 987494. Il faudrait en fait limiter le find
sur la partition correspondant au numéro d'inode.
L'inode 987494 peut très bien correspondre au fichier /tmp/toto et
/Users/truc/machin. Il aura donc un compteur de liens à 2. L'inode ne
conserve rien comme nom, même par /tmp ou /users/truc. Cela ne serait pas
faisable de plus si le fichier avait des milliers de liens.
Avec un inode qui n'a plus de nom (le nom a été effacé, et le compteur de
lien est à 0) on ne peut retrouver ni son nom, ni son répertoire. Seul son
numéro de partition sera gardé.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 23/01/04 15:51, dans , « Patrick Stadelmann » a écrit :
In article <BC36EAAC.66B4E%, Éric Lévénez wrote:
La commande "lsof" devrait le dire. Mais une fois que le nom du fichier a été effacé, même si l'inode est toujours en activité, on aura l'info sur l'inode, mais pas le ou les noms du fichier.
Avec "lsof +L1" on obtient en effet la liste de ces fichiers, mais seul le volume est indiqué (eg / alors que le fichier se trouvait dans /tmp). Y aurait pas un moyen de retrouver le chemin complet (sans le nom, bien sûr) ?
L'inode ne conserve pas le nom des fichiers.
Pour rechercher les noms d'un fichier connaissant sont numéro d'inode, on peut utiliser par exemple une commande du type :
find / -inum 987494 -ls
Comme l'identification d'un fichier est en fait un couple numéro d'inode + numéro de partition, la commande précédente affichera tous les noms des fichiers correspondant à l'inode 987494. Il faudrait en fait limiter le find sur la partition correspondant au numéro d'inode.
L'inode 987494 peut très bien correspondre au fichier /tmp/toto et /Users/truc/machin. Il aura donc un compteur de liens à 2. L'inode ne conserve rien comme nom, même par /tmp ou /users/truc. Cela ne serait pas faisable de plus si le fichier avait des milliers de liens.
Avec un inode qui n'a plus de nom (le nom a été effacé, et le compteur de lien est à 0) on ne peut retrouver ni son nom, ni son répertoire. Seul son numéro de partition sera gardé.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
tino
Éric Lévénez wrote:
Pourquoi ne serait-ce pas fiable ?
Parce qu'il m'a déjà fallu redémarrer l'appli finder pour qu'il prenne en compte les changements, je n'ai plus d'exemple concret quant à l'indication espace disque :-(
l'espace disponible sur le disque en question. Donc un swapfile énorme va se répercuter dans cette indication. Par contre si on le vire, même en redémarrant le finder l'espace "gagné" ne s'y repercute pas.
C'est normal.
Bon alors un petit cours unix.
Merci pour ton petit cours très instructif, c'est archivé ;-)
-- So have I heard and do in part believe it. - Horatio
Éric Lévénez <news@levenez.com> wrote:
Pourquoi ne serait-ce pas fiable ?
Parce qu'il m'a déjà fallu redémarrer l'appli finder pour qu'il prenne
en compte les changements, je n'ai plus d'exemple concret quant à
l'indication espace disque :-(
l'espace disponible sur le disque en question.
Donc un swapfile énorme va se répercuter dans cette indication.
Par contre si on le vire, même en redémarrant le finder l'espace "gagné"
ne s'y repercute pas.
C'est normal.
Bon alors un petit cours unix.
Merci pour ton petit cours très instructif, c'est archivé ;-)
--
So have I heard and do in part believe it. - Horatio
Parce qu'il m'a déjà fallu redémarrer l'appli finder pour qu'il prenne en compte les changements, je n'ai plus d'exemple concret quant à l'indication espace disque :-(
l'espace disponible sur le disque en question. Donc un swapfile énorme va se répercuter dans cette indication. Par contre si on le vire, même en redémarrant le finder l'espace "gagné" ne s'y repercute pas.
C'est normal.
Bon alors un petit cours unix.
Merci pour ton petit cours très instructif, c'est archivé ;-)
-- So have I heard and do in part believe it. - Horatio
pmanet
Éric Lévénez wrote:
C'est bien si tu sais ce que tu fais. Un second disque avec le swap dessus accélère de façon "dramatique" les accès.
meme si le disque en question est un vieux disque lent (en SCSI, pour mon 8600/G3...) ? -- Philippe Manet
Éric Lévénez <news@levenez.com> wrote:
C'est bien si tu sais ce que tu fais. Un second disque avec le swap dessus
accélère de façon "dramatique" les accès.
meme si le disque en question est un vieux disque lent (en SCSI, pour
mon 8600/G3...) ?
--
Philippe Manet
C'est bien si tu sais ce que tu fais. Un second disque avec le swap dessus accélère de façon "dramatique" les accès.
meme si le disque en question est un vieux disque lent (en SCSI, pour mon 8600/G3...) ? -- Philippe Manet
Éric Lévénez
Le 24/01/04 14:07, dans <2004012414070911045415@[10.0.0.1]>, « manet » a écrit :
Éric Lévénez wrote:
C'est bien si tu sais ce que tu fais. Un second disque avec le swap dessus accélère de façon "dramatique" les accès.
meme si le disque en question est un vieux disque lent (en SCSI, pour mon 8600/G3...) ?
Ça je ne sais pas, si on compare une machine avec un disque rapide et le swap dessus et une deuxième machine avec le swap sur un deuxième disque lent, je ne peux te dire laquelle ira le plus vite. Mais en règle générale ce sera quand même celle qui a 2 disques. Si c'est en plus en SCSI cela ne devrait pas être un mal.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 24/01/04 14:07, dans <2004012414070911045415@[10.0.0.1]>, « manet »
<pmanet@invivo.edu> a écrit :
Éric Lévénez <news@levenez.com> wrote:
C'est bien si tu sais ce que tu fais. Un second disque avec le swap dessus
accélère de façon "dramatique" les accès.
meme si le disque en question est un vieux disque lent (en SCSI, pour
mon 8600/G3...) ?
Ça je ne sais pas, si on compare une machine avec un disque rapide et le
swap dessus et une deuxième machine avec le swap sur un deuxième disque
lent, je ne peux te dire laquelle ira le plus vite. Mais en règle générale
ce sera quand même celle qui a 2 disques. Si c'est en plus en SCSI cela ne
devrait pas être un mal.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 24/01/04 14:07, dans <2004012414070911045415@[10.0.0.1]>, « manet » a écrit :
Éric Lévénez wrote:
C'est bien si tu sais ce que tu fais. Un second disque avec le swap dessus accélère de façon "dramatique" les accès.
meme si le disque en question est un vieux disque lent (en SCSI, pour mon 8600/G3...) ?
Ça je ne sais pas, si on compare une machine avec un disque rapide et le swap dessus et une deuxième machine avec le swap sur un deuxième disque lent, je ne peux te dire laquelle ira le plus vite. Mais en règle générale ce sera quand même celle qui a 2 disques. Si c'est en plus en SCSI cela ne devrait pas être un mal.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
