j'aimerai passer mon '/tmp' et mon '/var/tmp' en tmpfs. Je me suis donc
créé une partition de swap de 2Go et j'ai lu le fichier tmpfs.txt de la
documentation du noyau (je sais j'aurais mieux fait de commencer par ça
mais bon...) .
Je pensais donc qu'il suffisait de remplacer la ligne
tmpfs /dev/shm tmpfs defaults 0 0
de mon '/etc/fstab' par celle-ci
tmpfs /tmp tmpfs defaults 0 0
puis de changer le répertoire '/var/tmp' en lien vers '/tmp'.
Première question : Pensez-vous que cette façon de faire soit correcte ?
En lisant la doc je suis aussi tombé sur ces lignes :
######
tmpfs has three mount options for sizing:
size: The limit of allocated bytes for this tmpfs instance. The
default is half of your physical RAM without swap. If you
oversize your tmpfs instances the machine will deadlock
since the OOM handler will not be able to free that memory.
nr_blocks: The same as size, but in blocks of PAGE_CACHE_SIZE.
nr_inodes: The maximum number of inodes for this instance. The default
is half of the number of your physical RAM pages, or (on a
a machine with highmem) the number of lowmem RAM pages,
whichever is the lower.
######
Si je comprends bien l'auteur déconseille de surdimensionner une
instance tmpfs sous peine de planter la machine. Alors avant de faire
une boulette j'aimerais savoir ce que vous en pensez.
Précision : je suis sur une Debian 3.1 (sarge), j'ai 392Mo de RAM et je
pensais consacrer une partion de 2Go au swap et au tmpfs.
Il parait que la glibc en dépend. Je ne sais pas pour quoi faire...
/dev/shm sert à la glibc pour implémenter les fonctions de mémoire partagée POSIX (pas SysV), qui utilisent le filesystem comme point de rendez-vous. Mais justement, je ne connais aucun programme utilisant les fonctions de mémoire partagée POSIX (à part peut-être qemu, comme dit ailleurs, je n'ai pas vérifié).
l'indien wrote in message <pan.2005.08.17.21.42.06.67803@magic.fr>:
Il parait que la glibc en dépend. Je ne sais pas pour quoi faire...
/dev/shm sert à la glibc pour implémenter les fonctions de mémoire partagée
POSIX (pas SysV), qui utilisent le filesystem comme point de rendez-vous.
Mais justement, je ne connais aucun programme utilisant les fonctions de
mémoire partagée POSIX (à part peut-être qemu, comme dit ailleurs, je n'ai
pas vérifié).
Il parait que la glibc en dépend. Je ne sais pas pour quoi faire...
/dev/shm sert à la glibc pour implémenter les fonctions de mémoire partagée POSIX (pas SysV), qui utilisent le filesystem comme point de rendez-vous. Mais justement, je ne connais aucun programme utilisant les fonctions de mémoire partagée POSIX (à part peut-être qemu, comme dit ailleurs, je n'ai pas vérifié).
l'indien
On Thu, 18 Aug 2005 01:03:59 +0000, Nicolas George wrote:
l'indien wrote in message :
Il parait que la glibc en dépend. Je ne sais pas pour quoi faire...
/dev/shm sert à la glibc pour implémenter les fonctions de mémoire partagée POSIX (pas SysV), qui utilisent le filesystem comme point de rendez-vous. Mais justement, je ne connais aucun programme utilisant les fonctions de mémoire partagée POSIX (à part peut-être qemu, comme dit ailleurs, je n'ai pas vérifié).
Pour qemu, je viens de vérifier. Il se sert de /dev/shm pour allouer de la mémoire quand il utilise le module kqemu. C'est donc uniquement en cas de virtualisation x86, pas dans le cas d'une émulation "brute".
On Thu, 18 Aug 2005 01:03:59 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2005.08.17.21.42.06.67803@magic.fr>:
Il parait que la glibc en dépend. Je ne sais pas pour quoi faire...
/dev/shm sert à la glibc pour implémenter les fonctions de mémoire partagée
POSIX (pas SysV), qui utilisent le filesystem comme point de rendez-vous.
Mais justement, je ne connais aucun programme utilisant les fonctions de
mémoire partagée POSIX (à part peut-être qemu, comme dit ailleurs, je n'ai
pas vérifié).
Pour qemu, je viens de vérifier.
Il se sert de /dev/shm pour allouer de la mémoire quand il utilise le
module kqemu. C'est donc uniquement en cas de virtualisation x86, pas dans
le cas d'une émulation "brute".
On Thu, 18 Aug 2005 01:03:59 +0000, Nicolas George wrote:
l'indien wrote in message :
Il parait que la glibc en dépend. Je ne sais pas pour quoi faire...
/dev/shm sert à la glibc pour implémenter les fonctions de mémoire partagée POSIX (pas SysV), qui utilisent le filesystem comme point de rendez-vous. Mais justement, je ne connais aucun programme utilisant les fonctions de mémoire partagée POSIX (à part peut-être qemu, comme dit ailleurs, je n'ai pas vérifié).
Pour qemu, je viens de vérifier. Il se sert de /dev/shm pour allouer de la mémoire quand il utilise le module kqemu. C'est donc uniquement en cas de virtualisation x86, pas dans le cas d'une émulation "brute".
