# [solved] Shared Memory freigeben

## Jean-Paul

Hallo,

ich habe qemu / kqemu installiert, was super läuft.

Dazu habe ich in der fstab folgendes angelegt  *Quote:*   

> shm       		/dev/shm  		tmpfs   	defaults,size=640M	0      0

 

```

[jean ~]$ df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda6             7,6G  1,7G  5,5G  24% /

/dev/sda1              46M  4,2M   40M  10% /boot

/dev/sda7              95G   19G   71G  21% /home

/dev/sdb1             230G   70G  148G  33% /save

/tmp                  3,0G  4,0K  3,0G   1% /tmp

shm                   640M     0  640M   0% /dev/shm

```

```

[jean ~]$ free -m

             total       used       free     shared    buffers     cached

Mem:          6083        391       5691          0        150        117

-/+ buffers/cache:        124       5959

Swap:          494          0        494

```

Wenn ich jetzt z.B. Archlinux in qemu aufrufe, etwas damit arbeite und wieder schließe, sieht es folgendermaßen aus:

```

[jean ~]$ df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda6             7,6G  1,7G  5,5G  24% /

/dev/sda1              46M  4,2M   40M  10% /boot

/dev/sda7              95G   19G   71G  21% /home

/dev/sdb1             230G   70G  148G  33% /save

/tmp                  3,0G  4,0K  3,0G   1% /tmp

shm                   640M  182M  459M  29% /dev/shm

```

Die /dev/shm ist definitiv leer.

Ein erneuter qemu-Aufruf ergibt dann

```

You do not have enough space in '/dev/shm' for the 512 MB of QEMU virtual RAM.

To have more space available provided you have enough RAM and swap, do as root:

mount -o remount,size=528m /dev/shm

Or disable the accelerator module with -no-kqemu

```

Ich habe 6 GB RAM, das sollte also kein Problem sein.

Das bedeutet, dass Linux /dev/shm als nicht leer deklariert, obwohl /dev/shm leer ist  *Quote:*   

> [jean ~]$ du /dev/shm
> 
> 0	/dev/shm

 

Gibt es eine Möglichkeit dieses shared memory freizugeben ?

Bis jetzt ist es so, dass ich mein System neu booten muss, will ich 2x in Folge qemu starten.

Jean-PaulLast edited by Jean-Paul on Thu Nov 05, 2009 8:21 pm; edited 1 time in total

----------

## ChrisJumper

Ich war mir nicht sicher ob ich dich richtig verstanden hab. Aber es schaut so aus als möchtest du einfach /dev/shm wieder Freigeben.

Probier mal ein:

```
# umount /dev/shm
```

Möchtest du es wieder einbinden einfach mit mount /dev/shm

----------

## Tinitus

Hallo,

bringt das shm Device wirlich so viel Geschwindigkeit?

G. R.

----------

## firefly

 *Tinitus wrote:*   

> Hallo,
> 
> bringt das shm Device wirlich so viel Geschwindigkeit?
> 
> G. R.

 

in diesem falle hat es nichts mit Geschwindigkeit zu tun. Sondern qemu verwendet /dev/shm für den virtuellen Arbeitsspeicher für die VMs.

----------

## Jean-Paul

Hi, danke für die Antworten.

Ja, ein umount wäre schön einfach gewesen.

```

[jean ~]$ df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda6             7,6G  1,7G  5,5G  24% /

/dev/sda1              46M  4,2M   40M  10% /boot

/dev/sda7              95G   19G   71G  22% /home

/dev/sdb1             230G   70G  148G  33% /save

/tmp                  3,0G  4,0K  3,0G   1% /tmp

shm                   640M  117M  524M  19% /dev/shm

[jean ~]$ su

Password: 

[root /home/jean]# umount /dev/shm

umount: /dev/shm: device is busy.

        (In some cases useful info about processes that use

         the device is found by lsof(8) or fuser(1))

[root /home/jean]# du /dev/shm

0   /dev/shm

[root /home/jean]# lsof /dev/shm

[root /home/jean]# fuser -m /dev/shm

```

Wie man sieht, läßt sich /dev/shm nicht umounten und weder lsof noch fuser zeigen an, dass ein anderer Prozess das Device blockiert.

Ich hab mal versuchsweise /dev/shm aus der fstab rausgenommen. kqemu geht dann nach /tmp, wenn kein anderer Pfad definiert wurde.

/tmp habe ich aber auch im RAM und dort ist es das Selbe. /tmp wächst langsam zu (df -h), obwohl es leer ist, nur habe ich die Möglichkeit qemu öffter zu starten, weil /tmp 3GB groß ist.

Ich werde mir wohl doch nach einem Patch für kvm-88 schauen müssen, damit es sich mit Kernel-2.6.31 bauen läßt, denn da hatte ich diese Probleme nicht.

@Tinitus,

ja, mit /dev/shm, weil es im RAM liegt, und der Option "qemu -kernel-kqemu ..."  bringst du qemu richtig auf Touren - praktisch kein Unterschied mehr zu VMware. Oder du nimmst kvm.

Jean-Paul

----------

## musv

 *Jean-Paul wrote:*   

> Wie man sieht, läßt sich /dev/shm nicht umounten und weder lsof noch fuser zeigen an, dass ein anderer Prozess das Device blockiert.

 

Probier mal:

```
umount -l /dev/shm
```

Das hilft bei mir, wenn irgendwelche nfs-Laufwerke noch denken, dass sie von jemandem benutzt werden.

----------

## Jean-Paul

Das war's, Danke.

shm läßt sich umounten und nach einem erneuten mount ist alles wieder auf Null.

Jean-Paul

----------

