J'ai essayé de faire une recopie d'écran avec les touches
Commande-majuscule-3. Cela donne un document au format pdf de 544 ko
environ. Là où c'est drôle c'est que j'ai un écran de 1280 x 1024
pixels, or à l'ouverture dans GraphicCinverter je trouve une image de,
tenez-vous bien, 5 333 x 4 226 points qui occupe en mémoire 86 Mo et qui
est à 300 ppi. Les singes ont encore frappé !
On Sat, 26 Aug 2006 22:59:15 +0200, Eric Levenez wrote:
Mac OS X gère le swap dans des fichiers sur la partition de boot (dans le répertoire /var/vm). On peut déplacer ces fichiers 'swapfile*" vers un autre disque, mais pas simplement. Si je peux oser... ce comportement sur la même partition me semble
plus normal et simple, d'où vient cette habituelle unixienne de partitions dédiées au swap ?
Avec une partition de swap le swap accède directement aux blocs disque. Dans un fichier il faut passer par la couche de gestion du fichier. C'est donc plus long tout bêtement.
Un OS pro comme Solaris permet d'utiliser les deux, mais en général on n'ajoute de fichier que comme pis à lait...
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est normal qu'en plus ils utilisent la méthode la moins performante...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Nina Popravka <Nina@nospam> wrote:
On Sat, 26 Aug 2006 22:59:15 +0200, Eric Levenez <news@levenez.com>
wrote:
Mac OS X gère le swap dans des fichiers sur la partition de boot (dans le
répertoire /var/vm). On peut déplacer ces fichiers 'swapfile*" vers un autre
disque, mais pas simplement.
Si je peux oser... ce comportement sur la même partition me semble
plus normal et simple, d'où vient cette habituelle unixienne de
partitions dédiées au swap ?
Avec une partition de swap le swap accède directement aux blocs disque.
Dans un fichier il faut passer par la couche de gestion du fichier.
C'est donc plus long tout bêtement.
Un OS pro comme Solaris permet d'utiliser les deux, mais en général on
n'ajoute de fichier que comme pis à lait...
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est
normal qu'en plus ils utilisent la méthode la moins performante...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
On Sat, 26 Aug 2006 22:59:15 +0200, Eric Levenez wrote:
Mac OS X gère le swap dans des fichiers sur la partition de boot (dans le répertoire /var/vm). On peut déplacer ces fichiers 'swapfile*" vers un autre disque, mais pas simplement. Si je peux oser... ce comportement sur la même partition me semble
plus normal et simple, d'où vient cette habituelle unixienne de partitions dédiées au swap ?
Avec une partition de swap le swap accède directement aux blocs disque. Dans un fichier il faut passer par la couche de gestion du fichier. C'est donc plus long tout bêtement.
Un OS pro comme Solaris permet d'utiliser les deux, mais en général on n'ajoute de fichier que comme pis à lait...
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est normal qu'en plus ils utilisent la méthode la moins performante...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Nina Popravka
On Sun, 27 Aug 2006 19:51:21 +0200, (FiLH) wrote:
Avec une partition de swap le swap accède directement aux blocs disque. Dans un fichier il faut passer par la couche de gestion du fichier. C'est donc plus long tout bêtement. Ca, ça me plaît...
Mais avec un FileSystem efficace, ça devrait pas faire grande différence, non ? Si ? -- Nina
On Sun, 27 Aug 2006 19:51:21 +0200, filh@filh.orgie (FiLH) wrote:
Avec une partition de swap le swap accède directement aux blocs disque.
Dans un fichier il faut passer par la couche de gestion du fichier.
C'est donc plus long tout bêtement.
Ca, ça me plaît...
Mais avec un FileSystem efficace, ça devrait pas faire grande
différence, non ? Si ?
--
Nina
Avec une partition de swap le swap accède directement aux blocs disque. Dans un fichier il faut passer par la couche de gestion du fichier. C'est donc plus long tout bêtement. Ca, ça me plaît...
Mais avec un FileSystem efficace, ça devrait pas faire grande différence, non ? Si ? -- Nina
filh
Nina Popravka wrote:
On Sun, 27 Aug 2006 19:51:21 +0200, (FiLH) wrote:
Avec une partition de swap le swap accède directement aux blocs disque. Dans un fichier il faut passer par la couche de gestion du fichier. C'est donc plus long tout bêtement. Ca, ça me plaît...
Mais avec un FileSystem efficace, ça devrait pas faire grande différence, non ? Si ?
Hum... faudrait voir ce que dit zfs de chez sun sur le sujet, et j'avoue que je n'ai pas trop d'infos sur ce qu'il s'y fait dedans.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Nina Popravka <Nina@nospam> wrote:
On Sun, 27 Aug 2006 19:51:21 +0200, filh@filh.orgie (FiLH) wrote:
Avec une partition de swap le swap accède directement aux blocs disque.
Dans un fichier il faut passer par la couche de gestion du fichier.
C'est donc plus long tout bêtement.
Ca, ça me plaît...
Mais avec un FileSystem efficace, ça devrait pas faire grande
différence, non ? Si ?
Hum... faudrait voir ce que dit zfs de chez sun sur le sujet, et j'avoue
que je n'ai pas trop d'infos sur ce qu'il s'y fait dedans.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Avec une partition de swap le swap accède directement aux blocs disque. Dans un fichier il faut passer par la couche de gestion du fichier. C'est donc plus long tout bêtement. Ca, ça me plaît...
Mais avec un FileSystem efficace, ça devrait pas faire grande différence, non ? Si ?
Hum... faudrait voir ce que dit zfs de chez sun sur le sujet, et j'avoue que je n'ai pas trop d'infos sur ce qu'il s'y fait dedans.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Eric Levenez
Le 27/08/06 18:46, dans , « Nina Popravka » a écrit :
On Sun, 27 Aug 2006 18:45:20 +0200, (FiLH) wrote:
Sinon on a même eu des écrans postscript. Uniquement sur NeXT, non ?
Sur NeXSTEP et OPENSTEP le système d'affichage était bien Display PostScript, mais l'écran en lui même était bitmap. Il ne faut pas croire que l'on pouvait zoomer sur une partie de l'écran en gardant le vectoriel. C'est comme une page imprimé sur une imprimante PostScript : si on zoom après coup dessus, on voit des escaliers.
Le système Display PostScript (DPS) a été utilisé par NeXT sur NeXTSTEP et OPENSTEP, par SUN avec OpenStep sur Solaris, par Apple avec Mac OS X Server version 1. Mmais comme il a été co-développé par Adobe il a été aussi vendu comme solution (DPS/X) tournant dans X Window System à des boîtes comme IBM (pour AIX), SGI.
Il faut aussi noter que PostScript (pas "Display") a aussi servi de base à NeWS de SUN.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 27/08/06 18:46, dans <l2j3f2ttno2fapqtrgv6d176olbemmbtjc@4ax.com>, « Nina
Popravka » <Nina@nospam> a écrit :
On Sun, 27 Aug 2006 18:45:20 +0200, filh@filh.orgie (FiLH) wrote:
Sinon on a même eu des écrans postscript.
Uniquement sur NeXT, non ?
Sur NeXSTEP et OPENSTEP le système d'affichage était bien Display
PostScript, mais l'écran en lui même était bitmap. Il ne faut pas croire que
l'on pouvait zoomer sur une partie de l'écran en gardant le vectoriel. C'est
comme une page imprimé sur une imprimante PostScript : si on zoom après coup
dessus, on voit des escaliers.
Le système Display PostScript (DPS) a été utilisé par NeXT sur NeXTSTEP et
OPENSTEP, par SUN avec OpenStep sur Solaris, par Apple avec Mac OS X Server
version 1. Mmais comme il a été co-développé par Adobe il a été aussi vendu
comme solution (DPS/X) tournant dans X Window System à des boîtes comme IBM
(pour AIX), SGI.
Il faut aussi noter que PostScript (pas "Display") a aussi servi de base à
NeWS de SUN.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 27/08/06 18:46, dans , « Nina Popravka » a écrit :
On Sun, 27 Aug 2006 18:45:20 +0200, (FiLH) wrote:
Sinon on a même eu des écrans postscript. Uniquement sur NeXT, non ?
Sur NeXSTEP et OPENSTEP le système d'affichage était bien Display PostScript, mais l'écran en lui même était bitmap. Il ne faut pas croire que l'on pouvait zoomer sur une partie de l'écran en gardant le vectoriel. C'est comme une page imprimé sur une imprimante PostScript : si on zoom après coup dessus, on voit des escaliers.
Le système Display PostScript (DPS) a été utilisé par NeXT sur NeXTSTEP et OPENSTEP, par SUN avec OpenStep sur Solaris, par Apple avec Mac OS X Server version 1. Mmais comme il a été co-développé par Adobe il a été aussi vendu comme solution (DPS/X) tournant dans X Window System à des boîtes comme IBM (pour AIX), SGI.
Il faut aussi noter que PostScript (pas "Display") a aussi servi de base à NeWS de SUN.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 27/08/06 19:51, dans <1hkquua.exbv181cz3r57N%, « FiLH » a écrit :
Avec une partition de swap le swap accède directement aux blocs disque.
Disons que l'on passe par le driver bloc pour les accès disque.
Dans un fichier il faut passer par la couche de gestion du fichier.
On passe en théorie par le driver caractère (passage par le cache disque)...
C'est donc plus long tout bêtement.
... mais en fait le noyau accède directement aux blocs des fichiers préalloués par un démon, cela n'est pas plus long (sauf au moment de l'allocation d'un nouveau fichier).
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est normal qu'en plus ils utilisent la méthode la moins performante...
C'est pas clair, là tu critiques la gestion du swap ou de la mémoire virtuelle ? Pour le swap je comprends bien, mais pour la mémoire virtuelle quelles sont très critiques ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 27/08/06 19:51, dans <1hkquua.exbv181cz3r57N%filh@filh.orgie>, « FiLH »
<filh@filh.orgie> a écrit :
Avec une partition de swap le swap accède directement aux blocs disque.
Disons que l'on passe par le driver bloc pour les accès disque.
Dans un fichier il faut passer par la couche de gestion du fichier.
On passe en théorie par le driver caractère (passage par le cache disque)...
C'est donc plus long tout bêtement.
... mais en fait le noyau accède directement aux blocs des fichiers
préalloués par un démon, cela n'est pas plus long (sauf au moment de
l'allocation d'un nouveau fichier).
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est
normal qu'en plus ils utilisent la méthode la moins performante...
C'est pas clair, là tu critiques la gestion du swap ou de la mémoire
virtuelle ? Pour le swap je comprends bien, mais pour la mémoire virtuelle
quelles sont très critiques ?
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 27/08/06 19:51, dans <1hkquua.exbv181cz3r57N%, « FiLH » a écrit :
Avec une partition de swap le swap accède directement aux blocs disque.
Disons que l'on passe par le driver bloc pour les accès disque.
Dans un fichier il faut passer par la couche de gestion du fichier.
On passe en théorie par le driver caractère (passage par le cache disque)...
C'est donc plus long tout bêtement.
... mais en fait le noyau accède directement aux blocs des fichiers préalloués par un démon, cela n'est pas plus long (sauf au moment de l'allocation d'un nouveau fichier).
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est normal qu'en plus ils utilisent la méthode la moins performante...
C'est pas clair, là tu critiques la gestion du swap ou de la mémoire virtuelle ? Pour le swap je comprends bien, mais pour la mémoire virtuelle quelles sont très critiques ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
filh
Eric Levenez wrote:
Le 27/08/06 19:51, dans <1hkquua.exbv181cz3r57N%, « FiLH »
Avec une partition de swap le swap accède directement aux blocs disque.
Disons que l'on passe par le driver bloc pour les accès disque.
On peut le dire, mais est-ce vraiment une réponse compréhensible par le commun des non unixiens ?
C'est donc plus long tout bêtement.
... mais en fait le noyau accède directement aux blocs des fichiers préalloués par un démon, cela n'est pas plus long (sauf au moment de l'allocation d'un nouveau fichier).
Ouais ben le démon il prend quand même du temps d'exécution hein :)
Mais quand t'as un swap sur le réseau tu fais comment pour accéder aux blocs ? (Si si le swap over nfs ça existe)
Et bon dans d'autres unix les fichiers sont préalloués mais on préfère quand même les fs spécialisés. Il doit bien y avoir une raison.
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est normal qu'en plus ils utilisent la méthode la moins performante...
C'est pas clair, là tu critiques la gestion du swap ou de la mémoire virtuelle ? Pour le swap je comprends bien, mais pour la mémoire virtuelle quelles sont très critiques ?
Ben l'un est l'autre sont assez complémentaires... et je dois avouer que sous OSX les gigas de mémoire virtuelles alloués. Heureusement qu'on n'a pas ça sur de vrais serveurs...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Eric Levenez <news@levenez.com> wrote:
Le 27/08/06 19:51, dans <1hkquua.exbv181cz3r57N%filh@filh.orgie>, « FiLH »
Avec une partition de swap le swap accède directement aux blocs disque.
Disons que l'on passe par le driver bloc pour les accès disque.
On peut le dire, mais est-ce vraiment une réponse compréhensible par le
commun des non unixiens ?
C'est donc plus long tout bêtement.
... mais en fait le noyau accède directement aux blocs des fichiers
préalloués par un démon, cela n'est pas plus long (sauf au moment de
l'allocation d'un nouveau fichier).
Ouais ben le démon il prend quand même du temps d'exécution hein :)
Mais quand t'as un swap sur le réseau tu fais comment pour accéder aux
blocs ? (Si si le swap over nfs ça existe)
Et bon dans d'autres unix les fichiers sont préalloués mais on préfère
quand même les fs spécialisés. Il doit bien y avoir une raison.
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est
normal qu'en plus ils utilisent la méthode la moins performante...
C'est pas clair, là tu critiques la gestion du swap ou de la mémoire
virtuelle ? Pour le swap je comprends bien, mais pour la mémoire virtuelle
quelles sont très critiques ?
Ben l'un est l'autre sont assez complémentaires... et je dois avouer que
sous OSX les gigas de mémoire virtuelles alloués. Heureusement qu'on n'a
pas ça sur de vrais serveurs...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Le 27/08/06 19:51, dans <1hkquua.exbv181cz3r57N%, « FiLH »
Avec une partition de swap le swap accède directement aux blocs disque.
Disons que l'on passe par le driver bloc pour les accès disque.
On peut le dire, mais est-ce vraiment une réponse compréhensible par le commun des non unixiens ?
C'est donc plus long tout bêtement.
... mais en fait le noyau accède directement aux blocs des fichiers préalloués par un démon, cela n'est pas plus long (sauf au moment de l'allocation d'un nouveau fichier).
Ouais ben le démon il prend quand même du temps d'exécution hein :)
Mais quand t'as un swap sur le réseau tu fais comment pour accéder aux blocs ? (Si si le swap over nfs ça existe)
Et bon dans d'autres unix les fichiers sont préalloués mais on préfère quand même les fs spécialisés. Il doit bien y avoir une raison.
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est normal qu'en plus ils utilisent la méthode la moins performante...
C'est pas clair, là tu critiques la gestion du swap ou de la mémoire virtuelle ? Pour le swap je comprends bien, mais pour la mémoire virtuelle quelles sont très critiques ?
Ben l'un est l'autre sont assez complémentaires... et je dois avouer que sous OSX les gigas de mémoire virtuelles alloués. Heureusement qu'on n'a pas ça sur de vrais serveurs...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Nina Popravka
On Sun, 27 Aug 2006 21:57:57 +0200, (FiLH) wrote:
Mais quand t'as un swap sur le réseau tu fais comment pour accéder aux blocs ? (Si si le swap over nfs ça existe) Quel intérêt au prix des disques de nos jours ?????????????????????
-- Nina
On Sun, 27 Aug 2006 21:57:57 +0200, filh@filh.orgie (FiLH) wrote:
Mais quand t'as un swap sur le réseau tu fais comment pour accéder aux
blocs ? (Si si le swap over nfs ça existe)
Quel intérêt au prix des disques de nos jours ?????????????????????
Mais quand t'as un swap sur le réseau tu fais comment pour accéder aux blocs ? (Si si le swap over nfs ça existe) Quel intérêt au prix des disques de nos jours ?????????????????????
-- Nina
Eric Levenez
Le 27/08/06 21:57, dans <1hkr0er.12sujde120lqxcN%, « FiLH » a écrit :
Eric Levenez wrote:
Le 27/08/06 19:51, dans <1hkquua.exbv181cz3r57N%, « FiLH »
Avec une partition de swap le swap accède directement aux blocs disque.
Disons que l'on passe par le driver bloc pour les accès disque.
On peut le dire, mais est-ce vraiment une réponse compréhensible par le commun des non unixiens ?
J'explique les choses par rapport à tes affirmations, et donc je te réponds.
C'est donc plus long tout bêtement.
... mais en fait le noyau accède directement aux blocs des fichiers préalloués par un démon, cela n'est pas plus long (sauf au moment de l'allocation d'un nouveau fichier).
Ouais ben le démon il prend quand même du temps d'exécution hein :)
Non, pourquoi ? Mon démon a utilisé 0,00 seconde de CPU depuis le boot. Le tiens est à quelle utilisation ?
Mais quand t'as un swap sur le réseau tu fais comment pour accéder aux blocs ? (Si si le swap over nfs ça existe)
Je ne pense pas que cela soit possible avec Mac OS X. Il était possible de faire un swap disque avec RFS, mais je ne vois pas l'intérêt de faire cela. Sur les stations X où l'on bootait à distance sur NFS, on ajoutait un swap local sous forme de disque dur.
Et bon dans d'autres unix les fichiers sont préalloués mais on préfère quand même les fs spécialisés. Il doit bien y avoir une raison.
Cela dépend de l'implémentation de ces fichiers. Sur Mac OS X ce ne sont pas de bêtes fichiers comme sur certains unix. Là est peut-être la raison.
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est normal qu'en plus ils utilisent la méthode la moins performante...
C'est pas clair, là tu critiques la gestion du swap ou de la mémoire virtuelle ? Pour le swap je comprends bien, mais pour la mémoire virtuelle quelles sont très critiques ?
Ben l'un est l'autre sont assez complémentaires...
Non. J'utilise couramment des systèmes (Linux y compris) avec une gestion de la mémoire virtuelle mais sans aucun swap.
et je dois avouer que sous OSX
Parles-tu de Mac OS X ?
les gigas de mémoire virtuelles alloués.
Et alors, si j'alloue 10 Go à un processus, cela prend 0 octet en RAM et sur disque. Voudrais-tu que la mémoire virtuelle réservée soit effectivement allouée en RAM et/ou sur disque ?
Heureusement qu'on n'a pas ça sur de vrais serveurs...
Toujours pas compris ta critique de la mémoire virtuelle de Mac OS X.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 27/08/06 21:57, dans <1hkr0er.12sujde120lqxcN%filh@filh.orgie>, « FiLH »
<filh@filh.orgie> a écrit :
Eric Levenez <news@levenez.com> wrote:
Le 27/08/06 19:51, dans <1hkquua.exbv181cz3r57N%filh@filh.orgie>, « FiLH »
Avec une partition de swap le swap accède directement aux blocs disque.
Disons que l'on passe par le driver bloc pour les accès disque.
On peut le dire, mais est-ce vraiment une réponse compréhensible par le
commun des non unixiens ?
J'explique les choses par rapport à tes affirmations, et donc je te réponds.
C'est donc plus long tout bêtement.
... mais en fait le noyau accède directement aux blocs des fichiers
préalloués par un démon, cela n'est pas plus long (sauf au moment de
l'allocation d'un nouveau fichier).
Ouais ben le démon il prend quand même du temps d'exécution hein :)
Non, pourquoi ? Mon démon a utilisé 0,00 seconde de CPU depuis le boot. Le
tiens est à quelle utilisation ?
Mais quand t'as un swap sur le réseau tu fais comment pour accéder aux
blocs ? (Si si le swap over nfs ça existe)
Je ne pense pas que cela soit possible avec Mac OS X. Il était possible de
faire un swap disque avec RFS, mais je ne vois pas l'intérêt de faire cela.
Sur les stations X où l'on bootait à distance sur NFS, on ajoutait un swap
local sous forme de disque dur.
Et bon dans d'autres unix les fichiers sont préalloués mais on préfère
quand même les fs spécialisés. Il doit bien y avoir une raison.
Cela dépend de l'implémentation de ces fichiers. Sur Mac OS X ce ne sont pas
de bêtes fichiers comme sur certains unix. Là est peut-être la raison.
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est
normal qu'en plus ils utilisent la méthode la moins performante...
C'est pas clair, là tu critiques la gestion du swap ou de la mémoire
virtuelle ? Pour le swap je comprends bien, mais pour la mémoire virtuelle
quelles sont très critiques ?
Ben l'un est l'autre sont assez complémentaires...
Non. J'utilise couramment des systèmes (Linux y compris) avec une gestion de
la mémoire virtuelle mais sans aucun swap.
et je dois avouer que
sous OSX
Parles-tu de Mac OS X ?
les gigas de mémoire virtuelles alloués.
Et alors, si j'alloue 10 Go à un processus, cela prend 0 octet en RAM et sur
disque. Voudrais-tu que la mémoire virtuelle réservée soit effectivement
allouée en RAM et/ou sur disque ?
Heureusement qu'on n'a
pas ça sur de vrais serveurs...
Toujours pas compris ta critique de la mémoire virtuelle de Mac OS X.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 27/08/06 21:57, dans <1hkr0er.12sujde120lqxcN%, « FiLH » a écrit :
Eric Levenez wrote:
Le 27/08/06 19:51, dans <1hkquua.exbv181cz3r57N%, « FiLH »
Avec une partition de swap le swap accède directement aux blocs disque.
Disons que l'on passe par le driver bloc pour les accès disque.
On peut le dire, mais est-ce vraiment une réponse compréhensible par le commun des non unixiens ?
J'explique les choses par rapport à tes affirmations, et donc je te réponds.
C'est donc plus long tout bêtement.
... mais en fait le noyau accède directement aux blocs des fichiers préalloués par un démon, cela n'est pas plus long (sauf au moment de l'allocation d'un nouveau fichier).
Ouais ben le démon il prend quand même du temps d'exécution hein :)
Non, pourquoi ? Mon démon a utilisé 0,00 seconde de CPU depuis le boot. Le tiens est à quelle utilisation ?
Mais quand t'as un swap sur le réseau tu fais comment pour accéder aux blocs ? (Si si le swap over nfs ça existe)
Je ne pense pas que cela soit possible avec Mac OS X. Il était possible de faire un swap disque avec RFS, mais je ne vois pas l'intérêt de faire cela. Sur les stations X où l'on bootait à distance sur NFS, on ajoutait un swap local sous forme de disque dur.
Et bon dans d'autres unix les fichiers sont préalloués mais on préfère quand même les fs spécialisés. Il doit bien y avoir une raison.
Cela dépend de l'implémentation de ces fichiers. Sur Mac OS X ce ne sont pas de bêtes fichiers comme sur certains unix. Là est peut-être la raison.
Et petit troll : vu la façon lamentable dont Mac OSX gère la VM c'est normal qu'en plus ils utilisent la méthode la moins performante...
C'est pas clair, là tu critiques la gestion du swap ou de la mémoire virtuelle ? Pour le swap je comprends bien, mais pour la mémoire virtuelle quelles sont très critiques ?
Ben l'un est l'autre sont assez complémentaires...
Non. J'utilise couramment des systèmes (Linux y compris) avec une gestion de la mémoire virtuelle mais sans aucun swap.
et je dois avouer que sous OSX
Parles-tu de Mac OS X ?
les gigas de mémoire virtuelles alloués.
Et alors, si j'alloue 10 Go à un processus, cela prend 0 octet en RAM et sur disque. Voudrais-tu que la mémoire virtuelle réservée soit effectivement allouée en RAM et/ou sur disque ?
Heureusement qu'on n'a pas ça sur de vrais serveurs...
Toujours pas compris ta critique de la mémoire virtuelle de Mac OS X.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Ben, y en a qui vient de me foutre la trouille en me disant que les Dd D-ATA de 250 Go ont une structure telle qu'on ne peut y dupliquer une unité de 80 Go.
Ouf, le G5 vient de passer le test. Y a juste une astuce, mais bon...
Ben, y en a qui vient de me foutre la trouille en me disant que les Dd
D-ATA de 250 Go ont une structure telle qu'on ne peut y dupliquer une
unité de 80 Go.
Ouf, le G5 vient de passer le test. Y a juste une astuce, mais bon...
Ben, y en a qui vient de me foutre la trouille en me disant que les Dd D-ATA de 250 Go ont une structure telle qu'on ne peut y dupliquer une unité de 80 Go.
Ouf, le G5 vient de passer le test. Y a juste une astuce, mais bon...
jc
Anne wrote:
Jean-Charles wrote:
Pomme-U ne donne rien chez moi mais je suis sous Panther. Par contre les informations données sont très intéressantes. Mais je ne comprends toujuours pas comment le système a pu avoir besoin d'autant de mémoire sur le disque dur. Aujourd'hui tout beigne et du moment que j'ai un contrôle sur l'activité ça va.
tu n'as sans doute pas une grande quantité de mémoire/barrette et donc le système utilise tout ce qu'il peut.
J'ai 512 Mo, c'est pas suffisant ? Faut dire qu'avec les logiciels « baudruche » de maintenant ... (rien que FinderCleaner, qui efface 4 fichiers invisibles, fait 552 Ko).
-- JC
Anne <anneleguennec@free.fr> wrote:
Jean-Charles <jc@qui.net> wrote:
Pomme-U ne donne rien chez moi mais je suis sous Panther. Par contre les
informations données sont très intéressantes.
Mais je ne comprends toujuours pas comment le système a pu avoir besoin
d'autant de mémoire sur le disque dur. Aujourd'hui tout beigne et du
moment que j'ai un contrôle sur l'activité ça va.
tu n'as sans doute pas une grande quantité de mémoire/barrette et donc
le système utilise tout ce qu'il peut.
J'ai 512 Mo, c'est pas suffisant ? Faut dire qu'avec les logiciels
« baudruche » de maintenant ... (rien que FinderCleaner, qui efface 4
fichiers invisibles, fait 552 Ko).
Pomme-U ne donne rien chez moi mais je suis sous Panther. Par contre les informations données sont très intéressantes. Mais je ne comprends toujuours pas comment le système a pu avoir besoin d'autant de mémoire sur le disque dur. Aujourd'hui tout beigne et du moment que j'ai un contrôle sur l'activité ça va.
tu n'as sans doute pas une grande quantité de mémoire/barrette et donc le système utilise tout ce qu'il peut.
J'ai 512 Mo, c'est pas suffisant ? Faut dire qu'avec les logiciels « baudruche » de maintenant ... (rien que FinderCleaner, qui efface 4 fichiers invisibles, fait 552 Ko).
