Deux tmpfs différents lors d'un df

Support Debian
#1

Yop,

J’ai un petit truc qui me gêne sur mon système.
Pourquoi quand je fais un df je vois apparaître deux tmpfs différents ?

10:16 cartman@serveur ~% df Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/hda2 897M 183M 667M 22% / tmpfs 505M 12K 505M 1% /dev/shm /dev/hda1 89M 14M 71M 17% /boot /dev/hda10 35G 29G 4,1G 88% /home /dev/hda9 9,2G 257M 8,5G 3% /opt /dev/hda7 1,8G 8,1M 1,7G 1% /tmp /dev/hda8 9,2G 2,2G 6,6G 26% /usr /dev/hda5 19G 3,0G 15G 17% /var /dev/sda1 151G 34G 110G 24% /media/160go /dev/sdb 276G 255G 6,7G 98% /media/300go tmpfs 10M 188K 9,9M 2% /dev
Merci d’avance.

#2

ah ben pareil ici :slight_smile:

[quote]/dev/hda9 on / type ext3 (rw,noatime,errors=remount-ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda5 on /boot type ext3 (rw)
/dev/hda6 on /home type ext3 (rw,noatime,data=writeback)
/dev/hda11 on /var type reiserfs (rw)
/dev/hda8 on /root type xfs (rw,noatime,nodiratime,logbufs=8)
/dev/hda7 on /xfs type xfs (rw,noatime,nodiratime,logbufs=8)
/dev/hda1 on /mnt/hda1 type ntfs (ro,umask=000,nls=utf8)
/dev/hda10 on /mnt/hda10 type vfat (rw,noexec,nosuid,nodev,umask=000)
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)
[/quote]

C’est peut-être normal…

#3

Après une mise à jour du noyau p’tête !!

#4

Ah oui hier j’ai installé le 2.6.17. C’est ptet lié…
J’ai la flemme de redemarrer en 2.6.16.

D’ailleurs le 2.6.17 marche vraimment bien, je le conseille!

#5

[quote=“BorisTheButcher”]Ah oui hier j’ai installé le 2.6.17. C’est ptet lié…
J’ai la flemme de redemarrer en 2.6.16.

D’ailleurs le 2.6.17 marche vraimment bien, je le conseille![/quote]
De même pour moi.

#6

C’est p’tête une raison mais c’est p’tête pas la raison.
Je dis ça car j’ai le prob une fois aussi.

#7

Pour vous éviter une erreur :

[quote]ginkgobiloba@debian:~$ df
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/hdc3 8364932 3754528 4185488 48% /
tmpfs 518412 0 518412 0% /dev/shm
/dev/hdc5 185057520 4522364 171134724 3% /home
/dev/hda5 39678816 11751360 27927456 30% /mnt/donnees
/dev/sda5 4807056 2452652 2110220 54% /mnt/sarge-268
/dev/sda7 4870252 1077124 3545732 24% /mnt/sarge-home
/dev/sda1 149231456 46774432 102457024 32% /mnt/video
/dev/hda1 18924536 3959040 14965496 21% /mnt/w_2000
tmpfs 518412 140 518272 1% /dev
ginkgobiloba@debian:~$ uname -r
2.6.15-1-k7[/quote] 2 tmpfs et noyau 2.6.15
le 2.6.17 n’est donc pas à mettre en cause pour cela (ou alors cela traîne depuis un petit moment !)

#8

Avec le 2.16.9 je n’avais pas ça.

#9

je vais faire une supposition mais vu mon niveau vous êtes en droit de l’ignorer : j’ai 2 partitions swap et y a-t-il 1 tmpfs pour 1 swap ?

#10

Ben ta théorie tombe à l’eau vu que pour ma part je n’ai qu’une seule partition swap. :wink:

#11

Non, les gars, vous n’y êtes pas, tout est normal:
le premier tmpfs est là depuis longtemps, et est un bête ramdisk utilisé d’aprés ce que je vois pour stocker des données volatiles liées au réseau.
Le deuxiême est le ramdisk créé par udev, et qui est bien évidement monté sur /dev
Ceux qui n’ont pas udev (ou devfs, ou un ramdisk perso, d’ailleurs) n’ont que le Ramdisk d’usage général /dev/shm.
Ne vous inquiètez pas: “Tout va trés bien, Madame la Marquise…”

PS/Edit: quel interet ce /dev/shm ? Ce qui est dans un ramdisk est plus rapide d’accés que ce qui est sur le disque. Si on y met des données de config consultées souvent (genre les données de resolvconf, pour ceux qui connaissent) le processus qui a besoin de ces données tourne d’autant plus vite.
Mais ça n’est interressant que pour des données qui peuvent disparaitre en cas de coupure de jus (contrairement par exemple à la base de registre windows qui est à la fois en mêmoire et sur disque, ce qui ralentit l’accés mêmoire et bouffe des cycles, car il faut en permanence synchroniser la RAM et le HD, ce qui rend l’accés à la base de registre mêmoire encore plus lente que si elle n’etait que sur disque, et qui en plus pose des problême en cas de coupure brutale lors de la synchro des deux bases de registre - là encore windows a tout faux).

#12

merci pour les infos : j’ai bien cherché et trouvé qque chose d’approchant mais c’était moins clair …

#13

Merci. :slightly_smiling: