# Wie und wohin /tmp/ am besten verschieben/auslagern?

## SarahS93

Mein System läuft auf einem SSD Laufwerk, und /tmp/ liegt da noch immer drauf.

Ich würde /tmp/ gerne auf /mnt/festplatte_sdb1/tmp/ haben, wie mache ich das? (sdb1 ist eine Festplatte, kein SSD Laufwerk)

Ist es möglich /tmp/ in einer VM per Netzwerk (cifs Dateifreigabe) auszulagern?

----------

## py-ro

/tmp kannst am besten in ein tmpfs auslagern, wird spätestens mit systemd eh Standard.

/var/tmp lohnt sich eher, in deinem fall entweder per bind mount, wie bei der installation, oder per symlink.

/tmp in das Netz auszulagern ginge zwar, macht aber keinen Sinn und bremst das System unter Umständen doch merklich.

Bye

Py

----------

## SarahS93

Wie mache ich das mit dem auslagern von /tmp in ein "tmpfs"? Was ist ein systemd?

Also einfach ein mount --bind /var/tmp/ /mnt/festplatte_sdb1/var_tmp/?

Um das dauerhaft so zu machen entsprechend in fstab eintragen oder wie gehe ich am besten vor?

Was ist mit den ganzen Dateien die akutel in /var/tmp/ sich befinden? Sind diese wichtig oder kann ich die löschen?

Macht es Sinn die /var/tmp/ Geschichte in einer VM auf eine Netzwerkfreigabe auszulagern?

----------

## kernelOfTruth

Beispiel von /etc/fstab:

```
tmpfs         /tmp         tmpfs      noatime,nodiratime,nosuid,noexec,nodev,size=4096M,mode=1777   0 0
```

die Dateien in /var/tmp können dort verbleiben, wenn /var/tmp un-mounted wird, ist dort wieder auf die Dateien zugreifbar

Beispiel für /var/tmp über zram (mit ziemlich aktuellem Kernel, der den parallelen Zugriff, discard- und lz4-Kompression unterstützt)

 */etc/local.d/zram.start wrote:*   

> 
> 
> #!/bin/sh
> 
> modprobe zram num_devices=2
> ...

 

jfs lief am problemlosesten, Btrfs hat ziemlich häufig zu Latency-spikes geführt, ext4 - naja, das hat in den letzten Kerneln auch irgendwie Probleme und Instabilitäten bei mir verursacht (hauptsächlich beim Kompilien größerer Programme)

 */etc/local.d/zram.stop wrote:*   

> #!/bin/bash
> 
> swapoff /dev/zram0
> 
> echo 1 > /sys/block/zram0/reset
> ...

 

----------

## musv

Mal 'ne dumme Frage: 

Wozu soll der Aufwand mit zram gut sein? 

Die Kompression ist ja schön und gut, aber /var/tmp/portage läuft bei mir seit Jahren brauchbar als tmpfs, ohne dass ich da erst ein Dateisystem angelegt hab.

----------

## py-ro

Vor allem warum auch noch Swap, das passt nicht zur Fragestellung und wir den/die Threadstarterin (nichts für ungut) nur verwirren.

Bye

Py

----------

## kernelOfTruth

gar keine dumme Frage   :Wink: 

das ist einfach das volle Skript, in dem auch /var/tmp bei mir abgelegt ist (quasi als Referenz-Skript),

der Aufwand deswegen, weil hiermit dann der Durchsatz für die Kompiliererei (z.B. firefox, chromium, libreoffice, etc.) hierdurch höher ist

ich kann aber auch gerne nur /var/tmp hier gepostet lassen und swap entfernen, wenn dies gewünscht ist

----------

## toralf

 *musv wrote:*   

> Mal 'ne dumme Frage: 
> 
> Wozu soll der Aufwand mit zram gut sein? 
> 
> Die Kompression ist ja schön und gut, aber /var/tmp/portage läuft bei mir seit Jahren brauchbar als tmpfs, ohne dass ich da erst ein Dateisystem angelegt hab.

 Bie mir auch, aber firefox mit debug info braucht 8 GB beim Kompilieren - die muß man auch erst mal immer frei haben.

----------

## Child_of_Sun_24

In der fstab:

```
/mnt/festplatte_sdb1/tmp/         /tmp         auto      bind                    0 0
```

Als Mount Befehl:

```
mount -o bind /mnt/festplatte_sdb1/tmp /tmp
```

Nur als BEispiel falls du das in Zukunft mal brauchen solltest.

----------

## musv

Um mal bissel die Arroganz raushängen zu lassen:

 *toralf wrote:*   

> aber firefox mit debug info braucht 8 GB beim Kompilieren - die muß man auch erst mal immer frei haben.

 

 :Question: 

Ich hab 24 GB in der Kiste drinstecken.

----------

## wuesti

 *musv wrote:*   

> Um mal bissel die Arroganz raushängen zu lassen:
> 
>  *toralf wrote:*   aber firefox mit debug info braucht 8 GB beim Kompilieren - die muß man auch erst mal immer frei haben. 
> 
>  :?:
> ...

 

Ich bin bin beeindruckt ;.)

Den Aufwand kann ich nicht ganz nachvollziehen. Warum überlässt du das nicht dem Cache. Bei 24gb wird er wohl kaum volllaufen. Ich lasse gerade hier firefox bauen. Der schreibt alle 3-4 Sekunden mal 1 MB auf die Platte, mit write behind dürfte das die Geschwindigkeit nicht sehr beeinflussen. Ok, mein Rechner ist nur ein Quad-Core mit 2,3MHz und 4 GB Ram, 

Hast du einen zeitlichen Vergleich ohne zram und mit zram?

----------

## toralf

 *wuesti wrote:*   

> Warum überlässt du das nicht dem Cache. Bei 24gb wird er wohl kaum volllaufen.

 aber durch den ca. aller 5 sec angestoßenen sync wird das System dann  doch ausgebremst, siehe /proc/sys/dirty_writeback_centisecs

----------

## wuesti

Da habe ich doch mal lyx wiederholt gebaut.

Mit mount -t tmpfs -o bind /var/tmp/portage /tmp/portage habe ich zwischendurch das tmpfs aktiviert. 

zram einzurichten ist mir jetzt zu aufwendig.Ob es wirklich was bringt (höhere Prozessorlast gegen weniger Speicherdurchsatz) mag ich nicht beurteilen.

Meine Ergebnisse: 

ohne tmpfs: 4:11 min +-1sec

mit tmpfs: 4:10 min +-1sec

Das sind immerhin 0,4% Geschwindigkeitszuwachs.

Firefox & Co. brauchen bei mir zwischen ein und zwei Stunden, da könnte ich pro Programm 10-20 Sekunden sparen. ;-)

----------

## musv

Mal meine "Bauliste":

```
 * www-client/firefox-19.0

   Emerged at: Sa Mär  9 11:48:37 2013

   Build time: 19 minutes, and 56 seconds

 * www-client/firefox-20.0.1

   Emerged at: So Apr 28 15:24:15 2013

   Build time: 17 minutes, and 28 seconds

 * www-client/firefox-23.0

   Emerged at: Mi Sep 18 14:03:04 2013

   Build time: 47 minutes, and 9 seconds

 * www-client/firefox-24.0-r1

   Emerged at: Di Okt 15 21:22:56 2013

   Build time: 36 minutes, and 58 seconds

 * www-client/firefox-26.0

   Emerged at: Di Jan 14 18:06:24 2014

   Build time: 25 minutes, and 57 seconds

 * www-client/firefox-27.0.1

   Emerged at: So Mär 16 17:47:00 2014

   Build time: 38 minutes

 * www-client/firefox-29.0.1

   Emerged at: Sa Mai 17 06:47:35 2014

   Build time: 33 minutes, and 20 seconds

 * www-client/firefox-30.0

   Emerged at: Do Jun 26 16:36:13 2014

   Build time: 21 minutes, and 17 seconds
```

Die unterschiedlichen Zeiten kommen einfach zustande, weil ich oft 3 oder 4 Sachen gleichzeitig mergen lass. 

An zram hab ich vorher ehrlich gesagt nie groß gedacht. Aber der Aufwand ist schon ganz nett verglichen mit einem einfachen tmpfs. 

Mittlerweile dürfte es bei SSDs zwar auch keine große Rolle mehr spielen. Aber ich bin damals vollständig auf tmpfs umgestiegen, um einfach die Festplattenzugriffe beim Bauen zu reduzieren. Früher (4 GB Ram) musste ich dazu das tmpfs bei den kdelibs, gcc, Firefox, Seamonkey und webkit-gtk deaktivieren. Aber beim Rest klappte es ebenfalls ganz gut.

----------

## ChrisJumper

Bezüglich der SSD und das es ja nicht mehr nötig ist weil eigentlich die Firmware der SSD sich darum kümmert das die Alterung gleichmässig ist. Bisher ist mir da noch keine SSD kaputt gegangen nach 4 Jahren Laufzeit bisher. Logfiles habe ich aber ohnehin auf normale Festplatten ausgelagert.

Doch was ist mit Datenbanken? Kennt ihr euch da aus bezüglich postgre, mysql, mariadb und Mnesia? Natürlich hängt das auch mit der Einschätzung zusammen wie viele Abfragen an die Datenbanken gerichtet werden. Wenn ihr da zufällig was wisst oder euch im Stande seht eine Einschätzung zu machen lasst es mich wissen. Bisher versuch ich halt immer die Einstellungen bei der Installation einer Datenbank so zu legen das die Daten von einer Rotationskopf-Platte kommen.

----------

## musv

Wie du schon selbst erwähnt hast, ist die Alterung der SSD mittlerweile mit der einer normalen HDD vergleichbar bzw. sogar besser. 

Gerade Datenbanken legen ich vor allem auf die SSD, da dort die Geschwindigkeitsvorteile besser zur Geltung kommen.

----------

