# Welche Dateisystemzweige legt man auf eine Extra Partition

## Tinitus

Hallo,

da Gentoo ja gerade ein Problem mit Udev und separater /usr Partition hat überlege ich mein System mal neu aufzusetzen.

Welche Teile des Filesystem legt man am Besten auf eine extra Partition?

Ich denke auf jeden Fall:

/boot      wegen des Zugriffs auf den Kernel

/tmp       wegen des Überlaufens im Falle eines Programmfehlers

/var/tmp wie oben

/             sowieso  :Wink: 

/home     wie oben

Wie groß sind eure Partitionen in Zeiten von 2GB aufwärts?

Danke für jeden Tipp.

----------

## Max Steel

Hallo Tinitus,

/boot ist hier 100-150MB groß.

/ beschränke ich auf etwa 10GB

/usr/portage muss mit 5-10GB reichen (falls distfiles getrennt davon ist etwa 3-8GB weniger)

/tmp ist bei mir eine tmpfs mit etwa 3-5GB

/var/tmp habe ich (wegen /var/tmp/portage) 10GB groß gemacht.

/home braucht bei mir gute 15-25GB

Wie gesagt, das ist in etwa meine Festplatten aufteilung, alles in einer LVM auf einer LUKS-partition.

Eine extra Datenfestplatte habe ich auch noch um User und vor allem Betriebssystem übergreifende Daten zu speichern.

----------

## Jean-Paul

Hi,

/boot ist bei mir 200MB groß

/ hat 12GB

/home so viel du willst

/tmp und /var/tmp liegen im RAM

Sonst verwende ich keine separaten Filesysteme.

Mein System ist aber auch extrem minimalistisch (/ belegt gerade mal 4GB)

Jean-Paul

----------

## cryptosteve

Moin,

/boot ist bei mir deutlich größer, weil ich ein via lvm/cryptsetup vollverschlüsseltes System habe und /boot bei mir immer auch eine LiveCD beinhaltet, von der ich bei Bedarf fromiso booten kann. Es kommt zwar fast nie zu Problemen, aber wenn, dann habe ich gerade keinen externen Datenträger zur Hand.  :Smile:  /boot ist also zwischen einem und zwei GB groß

/tmp liegt bei mir ebenfalls im tmpfs, genauso wie /run (/var/run) und /var/lock. Ich kompiliere auch gerne im RAM (/var/tmp, bzw. entsprechende Einstellung in make.conf verweisen dann auf /dev/shm), aber hier musste ich schockiert feststellen, dass 8GB dazu heute nicht mehr ausreichen, vor allem, wenn firefox/thunderbird im Spiel ist. 

/ hat bei mir eine Größe von 15GB, beinhaltet aber auch die distfiles

/home bekommt den Rest

----------

## bell

Bei mir:

/boot: 500 MB. Das sollte für mehrere Kernel reichen

/  Auf dem Desktop 50 GB, da dort viele Spiele installiert sind. Auf dem Laptop 30 GB, wobei nur die Hälfte belegt ist.

/tmp und /var/tmp als tmpfs im RAM, mit "size=100%". Also so groß wie der Arbeitsspeicher.

/home : der Rest der Platte

Ach ja, Swap habe ich dann auch, falls tmpfs doch stärker beansprucht wird. 4 GB

----------

## cryptosteve

 *bell wrote:*   

> /tmp und /var/tmp als tmpfs im RAM, mit "size=100%". Also so groß wie der Arbeitsspeicher.

 

Darf ich fragen, wieviel Hauptspeicher Du hast?

----------

## Yamakuzure

Hier einmal meine Konfiguration, und warum:

```
 ~ $ df -h | egrep "(sda|auf)"

Dateisystem             Größe Benutzt Verf. Verw% Eingehängt auf

/dev/sda2                 21G     18G  2,0G   90% /

/dev/sda1                102M     22M   76M   23% /boot

/dev/sda5                992M    3,1M  938M    1% /tmp

/dev/sda6                3,9G    3,2G  527M   87% /var

/dev/sda7                4,0G    3,3G  541M   86% /opt

/dev/sda8                2,0G    1,3G  635M   67% /var/tmp

/dev/sda11               228G    192G   25G   89% /home

/dev/sda9                4,9G    3,9G  781M   84% /home/.ccache

/dev/sda10                25G     22G  2,3G   91% /usr/lib64/debug

aufs                     3,9G    3,2G  527M   87% /var/db

aufs                     3,9G    3,2G  527M   87% /var/lib/layman

aufs                      21G     18G  2,0G   90% /usr/portage

aufs                      21G     18G  2,0G   90% /usr/share/texmf-dist
```

aufs

Dieses sind squash_dir Verzeichnisse (Siehe Thread, die Sofware kommt aus Martin Väths overlay 'mv' (via layman).)Großes root, da ich keine separate /usr partition habe. Mir war das a) zu fumelig mit aktuellem udev und ohne initramfs, und b) gibt es für mich keinen vernünftigen Grund für eine separate /usr partition./tmp und /var/tmp sind eigene Partitionen, um dort ein ext2 zu benutzen. gleiches gilt für /home/.ccache, ebenfalls ext2./usr/lib64/debug ist eine eigene Partition, da ich als Entwickler global CFLAGS="-ggdb" und FEATURES="splitdebug" in meiner make.conf gesetzt habe./opt hat eine eigene Partition, da dort auch gerne mal experimentelles Zeug rein kommt./var hat eine eigene Partition, da sich hier /var/db/pkg befindet, ohne das das System schlicht hinüber ist. (oder so gut wie.)Und hier die Einträge aus der fstab. (Anmerkung: Ich benutze data=ordered, da das hier ein Laptop ist. Ja, "writeback" ist schneller, dafür gibt es aber auch gar kein journaling mehr. (Siehe Kernel Dokumentation Ext4)

```
 ~ $ grep sda /etc/fstab

/dev/sda1  /boot            ext2 defaults,relatime,user_xattr              1 2

/dev/sda2  /                ext4 defaults,relatime,data=ordered,user_xattr 0 1

/dev/sda3  none             swap sw                                        0 2

/dev/sda5  /tmp             ext2 defaults,relatime,user_xattr              0 2

/dev/sda6  /var             ext4 defaults,relatime,data=ordered,user_xattr 0 2

/dev/sda7  /opt             ext4 defaults,relatime,data=ordered,user_xattr 0 2

/dev/sda8  /var/tmp         ext2 defaults,relatime,user_xattr              0 2

/dev/sda11 /home            ext4 defaults,relatime,data=ordered,user_xattr 0 2

/dev/sda9  /home/.ccache    ext2 defaults,relatime,user_xattr              0 2

/dev/sda10 /usr/lib64/debug ext4 defaults,relatime,data=ordered,user_xattr 0 2
```

Ich habe auch schon überlegt die Root-Partition auf "data=journal" umzustellen, aber bislang keine Zeit zum Testen gehabt. In /home ist es mir wurscht, da ich die wichtigen Sachen in 4 TrueCrypt Containern habe.

----------

## cryptosteve

Moin Yamakuzure,

sehr interessant.

Dazu zwei Fragen:

a) Warum ext2 für .ccache? Ist das spürbar schneller als ext3/ext4?

b) Was genau bringt data=ordered? Ist die Option weniger brisant, wenn die Gefahr von Stromausfall minimiert ist? Zudem ist die Option nach meinem Verständnis (lt. man-page von mount) ohnehin default.

----------

## bell

 *cryptosteve wrote:*   

>  *bell wrote:*   /tmp und /var/tmp als tmpfs im RAM, mit "size=100%". Also so groß wie der Arbeitsspeicher. 
> 
> Darf ich fragen, wieviel Hauptspeicher Du hast?

 

Am PC 4 GB und am Laptop 8 GB. 

Auf dem Laptop kann ich also sogar LibreOffice (innerhalb von 1 Stunde) im RAM bauen. Aber da darf dann parallel keine VM oder sonstiges speicherintensives laufen, sonst fängt er an zu swappen.

Am PC unmounte ich manuell /var/tmp, wenn LibreOffice, Firefox oder Thunderbird gebaut werden soll.

----------

## cryptosteve

Hmm ... ich hab am Notebook (aeh, ich hab nur ein Notebook) auch 8gb und hier knallts mit "no space left", wenn ich im /dev/shm baue. 

Darf ich fragen, wie genau Deine Zeile in /etc/fstab für /var/tmp aussieht?

----------

## forrestfunk81

Ich hab mich in letzter Zeit immer für einfache Setups entschlossen. Früher hatte ich auch /usr, /var, /opt, Musik und Filme auf separaten Partitionen. Aber wenn mal was voll läuft ist mir das zuviel unnötiger Stress für zu geringe Vorteile.

/boot: 200 MB

/ 60GB (Rest der SSD)

/home: 1,5 TB (so groß ist die HD)

/var/tmp/portage: 4 GB (tmpfs)

/tmp: 1,5 GB (tmpfs)

Und ne extra 2 TB Backup Platte.

Auf dem Laptop teilen sich home und root die gesamte Partition bis auf 200 MB /boot. Auf dem Server kein tmpfs dafür 1,5 GB für eine ext2 /tmp Partition. Ach... und bei allen Systemen eine Swap Partition in Größe des Arbeitsspeichers. Was sind schon 2-8 GB bei den heutigen Plattengrößen.

Man kann Portage auch so konfigurieren, dass für spezielle Pakete (Libreoffice, Firefox, Icedtea etc) trotz tmpfs ein normales on disc Verzeichnis zum Kompilieren benutzt wird (wiki).

----------

## bell

 *cryptosteve wrote:*   

> Hmm ... ich hab am Notebook (aeh, ich hab nur ein Notebook) auch 8gb und hier knallts mit "no space left", wenn ich im /dev/shm baue. 
> 
> Darf ich fragen, wie genau Deine Zeile in /etc/fstab für /var/tmp aussieht?

 Aber klar doch.

```
none         /tmp      tmpfs      size=100%   0 0

none         /var/tmp   tmpfs      size=100%   0 0
```

```
$ df -h /tmp/

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf

none            7,7G     68K  7,7G    1% /tmp

$ df -h /var/tmp/

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf

none            7,7G       0  7,7G    0% /var/tmp
```

Standardmäßig wird nur 50% genommen.

----------

## schmidicom

```
Modell: ATA OCZ-VERTEX2 (scsi)

Festplatte  /dev/sda:  115GB

Sektorgröße (logisch/physisch): 512B/512B

Partitionstabelle: gpt

Disk Flags: 

Nummer  Anfang  Ende   Größe  Dateisystem  Name              Flags

 1      1049kB  211MB  210MB  fat32                          boot

 2      211MB   115GB  115GB  ext4         gentoo
```

Das erste ist die EFI-Systempartition ( /boot ) wo einerseits der Kernel und eine EFI-Shell liegt und das zweite ist das Betriebssystem ( / ).

Das ganze aufzuteilen ist mir inzwischen einfach zu aufwändig vor allem wenn man plötzlich feststellt das irgendwo zu wenig Speicher zugeteilt wurde.

----------

## Josef.95

@bell cryptosteve

Hm, mit dem kompletten /var/tmp in den Ram zu mounten wäre ich ein wenig vorsichtig. Es ist eigentlich nicht vorgesehen das /var/tmp bei jedem reboot gelöscht wird.

Einige Programme speichern dort auch temporäre Dateien die nicht ständig entfernt werden sollten. KDE speichert hier zb den Cache, und wenn der automatisch beim reboot mit geleert wird ist nicht unbedingt sichergestellt, das eine kurz zuvor geänderte Konfiguration im KDE tatsächlich beibehalten wird.

----------

## trismo

Auf Desktop pc mit SSD 

100MIB EFI

1 GIB boot für iso´s 

90'% btrfs @vol root home 

10% Reserve 

tmp´s in ram 

Ab kernel 3.7 ist die Performance klasse

Große Dinge per package.env laufen auf SSD tmp

Auf Servern bevorzuge ich mehr Partitionen je nach einsetzt kommt es immer mal vor 

das etwas "Daten Spam" verursacht und wenn sowas auftritt das System stabiler bleibt.

tmp´s in ram max 50%

----------

## cryptosteve

 *Josef.95 wrote:*   

> @bell cryptosteve
> 
> Hm, mit dem kompletten /var/tmp in den Ram zu mounten wäre ich ein wenig vorsichtig. Es ist eigentlich nicht vorgesehen das /var/tmp bei jedem reboot gelöscht wird.

 

Ja, darum habe ich das bei mir bislang durch folgende Einträge in make.conf anders gelöst:

```
PORTAGE_TMPFS="/dev/shm"

PORTAGE_TMPDIR="/dev/shm"

BUILD_PREFIX="/dev/shm"
```

Trotzdem läuft mir das shm da ab und an voll. Von daher nehme ich hier gerne den Tip zur Konfiguration über package.env mit. Das kannte ich so nicht und es erfüllt genau das, was ich brauche, nämlich einige wenige (maximal drei) schwere Brocken aus dem shm heraus zu halten.

----------

## bell

/dev/shm ist nicht dazu gedacht als /tmp missbraucht zu werden. Damit könntest Du unvorhersehbare Probleme verursachen. Lege lieber eigenes Verzeichnis dazu und mounte diesen mit tmpfs.

----------

## cryptosteve

Welche Probleme könnten das sein?

----------

## bell

Konkrete Probleme kann ich nicht nennen. Aber es ist halt dazu gedacht dass Prozesse unter einander darüber kommunizieren und Daten austauschen können. Und nach dem guten alten Unix-Prinzip sollte man es auch nur dafür nutzen.

----------

## cryptosteve

Hmm .. wenn dem so ist, dann ist mir das neu. Nach meinem Verständnis ist beides von der Technik her ein identisches tmpfs. Ich gestehe, dass ich sogar meinen Browsercache dort liegen habe.  :Smile: 

Aber ich gehe gerne mal googlen, vielleicht finde ich ja was zum Thema. Daher kann es hier gerne zurück zum eigentlichen Topic kommen.

----------

## mv

Auf /dev/shm greift die glibc in m.W. nicht genau dokumentierter Weise zur Implementierung der shm*-Funktionen zu. Sie wird vermutlich keine aufwändigen Test auf Filenamenkollisionen o.ä. veranstalten. Wenn es also bisher bei Dir ging, dann war das nur "Zufall". (Wobei natürlich die Wahrscheinlichkeit für eine zufällige Filenamenkollision vermutlich sehr gering ist).

----------

## musv

```

# System - virtuelle Laufwerke

proc            /proc               proc    nosuid,noexec,nodev 0 0 

sysfs           /sys                sysfs   nosuid,noexec,nodev 0 0 

devpts          /dev/pts            devpts  rw,gid=5,mode=620   0 0 

tmpfs           /run                tmpfs   defaults            0 0 

devtmpfs        /dev                devtmpfs mode=0755,nosuid   0 0                                                                 

tmpfs           /dev/shm            tmpfs   nodev,nosuid,noexec 0 0 

tmpfs           /tmp                tmpfs   mode=0777,nodev,nosuid  0 0 

tmpfs           /var/tmp/portage    tmpfs   size=13g  0 0 

# Partitionen

LABEL=BOOT      /boot             btrfs   noatime,nodiratime,ssd,discard,noacl,compress-force=lzo  1 2

LABEL=ROOT      /                 btrfs   noatime,nodiratime,ssd,discard,noacl,compress-force=lzo  1 0

LABEL=DATEN     /mnt/daten     xfs    rw,noatime,logbufs=8,nobarrier  0 0

# Userverzeichnisse + Swap

/mnt/daten/sm      /home/sm/Daten         none   bind,users   0 0

/mnt/daten/fabiana                 /home/fabiana/Daten      none   bind,users   0 0

/mnt/daten/swapfile   none         swap   sw         0 0
```

Erklärung: Die Datenplatte ist, wie der Name schon sagt, für die Userdaten zuständig. Die Systemplatte ist 'ne SSD. Die Homeverzeichnisse sind auf der SSD, weil ich mir einbilde, dass die ganzen Programmkonfigurationen von der SSD mit weniger Latenz geladen werden. 

Eine Swap-Partition hab ich nicht angelegt. Halte ich bei 24GB Ram für wenig sinnvoll.

----------

## Yamakuzure

 *cryptosteve wrote:*   

> a) Warum ext2 für .ccache? Ist das spürbar schneller als ext3/ext4?

 ext2 hat wirklich gar kein (auch nicht optional wie ext3) journaling, und damit in der Richtung keinerlei Overhead. Ferner betrachte ich den ccache als "flüchtig", es kratzt mich nicht das Ding zu schrubben. (War aber bislang noch nie nötig.) *cryptosteve wrote:*   

> b) Was genau bringt data=ordered? Ist die Option weniger brisant, wenn die Gefahr von Stromausfall minimiert ist? Zudem ist die Option nach meinem Verständnis (lt. man-page von mount) ohnehin default.

 Ja, "ordered" ist momentan default. Sollte sich das (warum auch immer) ändern, erlebe ich keine Überraschungen und muss nichts ändern.

Zu den Modi habe ich hier einen interessanten Buchausschnitt gefunden, den ich ob der Länge nicht abtippen werde: http://books.google.de/books?id=dYESFmtciKgC&pg=PA152

----------

## mv

 *Yamakuzure wrote:*   

>  *cryptosteve wrote:*   a) Warum ext2 für .ccache? Ist das spürbar schneller als ext3/ext4? ext2 hat wirklich gar kein (auch nicht optional wie ext3) journaling, und damit in der Richtung keinerlei Overhead.

 

Falcshe Logik. ext4 mit ausgeschaltetem Journaling hat auch kein Journaling, ist aber normalerweise sowieso schneller und effizienter, gerade bei so vielen Files in wenigen Verzeichnisse wie bei ccache. Es würde mich sehr wundern, wenn ext2 bei ccache tatsächlich schneller wäre, wobei zuverlässiges Benchmarking gerade bei ccache aber sehr schwer ist.

----------

## Yamakuzure

 *mv wrote:*   

>  *Yamakuzure wrote:*    *cryptosteve wrote:*   a) Warum ext2 für .ccache? Ist das spürbar schneller als ext3/ext4? ext2 hat wirklich gar kein (auch nicht optional wie ext3) journaling, und damit in der Richtung keinerlei Overhead. 
> 
> Falcshe Logik. ext4 mit ausgeschaltetem Journaling hat auch kein Journaling, ist aber normalerweise sowieso schneller und effizienter, gerade bei so vielen Files in wenigen Verzeichnisse wie bei ccache. Es würde mich sehr wundern, wenn ext2 bei ccache tatsächlich schneller wäre, wobei zuverlässiges Benchmarking gerade bei ccache aber sehr schwer ist.

 Naja, "hat wirklich gar kein Journaling" sollte besser heißen: "hat wirklich keinerlei Code für optionales Journaling, und damit auch keinerlei Code-Verzweigungen.".  :Wink: 

Aber Spaß beiseite, vielleicht sollte ich ext4 wirklich mal testen, denn ext2 hat, gerade bei sowas wie ccache, ein extremes Fragmentierungsproblem

```
67200 Inodes sind in Benutzung (5.13%)

   36342 nicht zusammenhängende Dateien (54.1%)

     257 nicht zusammenhängende Verzeichnisse (0.4%)

         # von Inodes mit ind/dind/tind Blöcken: 29559/2531/0

 4194221 Blöcke werden benutzt (80.00%)

0 ungültige Blöcke

       0 große Dateien

   66916 reguläre Dateien

     275 Verzeichnisse
```

Schon stramm...

----------

## bell

Naja, ob man ext2, ext3 oder ext4 nimmt ist inzwischen egal, wenn man die Kernel-Option CONFIG_EXT4_USE_FOR_EXT23 (Use ext4 for ext2/ext3 file systems) nutzt.

----------

## Yamakuzure

 *bell wrote:*   

> Naja, ob man ext2, ext3 oder ext4 nimmt ist inzwischen egal, wenn man die Kernel-Option CONFIG_EXT4_USE_FOR_EXT23 (Use ext4 for ext2/ext3 file systems) nutzt.

 

```
sed-notebook /usr/src/linux # grep EXT4_USE .config

sed-notebook /usr/src/linux # 
```

Tue ich wohl nicht... Na sowas, da ist mir wohl etwas entgangen. Aber die Option (habe gerade nachgeschaut) erscheint _nur_, wenn entweder ext3 oder ext2 /nicht/ ausgewählt sind.

Hmm... ich habe mal ein wenig Google befragt, und diese Option hat ja für reichlich Ärger gesorgt. Ich probier das mal aus, mal sehen was das an weniger Kernel-Größe bringt.

Edith sah gerade: Also der LZO-gepackte Kernel ist mit dieser Option und ohne ext2/ext3 mal eben 110KB kleiner.

----------

## mv

 *Yamakuzure wrote:*   

> hat wirklich keinerlei Code für optionales Journaling, und damit auch keinerlei Code-Verzweigungen."

 

Ist mir schon klar, dass Du das gemeint hast, aber:  Bin ich gar nicht sicher, ob das richtig ist. Ich glaube, ext2/3 teilen sich mehr gemeinsamen Code als ext4 mit ext2/3 (müsste ich aber untersuchen, wofür mir ehrlich gesagt, die Zeit zu schade ist).  Je nach Kernel-Optionen wird sogar ohnehin nur der ext4 code auch für ext2/3 genommen.  Selbst wenn: Dann sind das ein paar bedingte Sprünge. Wahrscheinlich sparst Du Dir sogar mehr bedingte Sprünge, wenn Du nur ext4 benutzt und damit die ext2/3-Verzweigung vermeidest.  Selbst auf langsamen Systemen dürfte die Prozessorzeit nicht der entscheidende Punkt in der Geschwindigkeit des Filesystems sein.

----------

## slick

 *cryptosteve wrote:*   

> Darf ich fragen, wie genau Deine Zeile in /etc/fstab für /var/tmp aussieht?

 

Wichtig finde ich die Anzahl der inodes, die normalerweise abhängig von der Größe des Dateisystem ist. Bedeutet aber: kleine Ramdisk -> wenig Inodes -> sehr schnell voll 

Besser ist da die Anzahl der Inodes beim Mounten explizit zu erhöhen, Beispiel:

```
mount none -t tmpfs /tmp -o size=75%,nr_inodes=2M
```

----------

## cryptosteve

Klingt interessant. Auf wieviel Gesamtspeicher bezieht sich Deine inode-Anzahl bei einer size von 75%?

----------

## slick

 *cryptosteve wrote:*   

> Klingt interessant. Auf wieviel Gesamtspeicher bezieht sich Deine inode-Anzahl bei einer size von 75%?

 

Das war nur ein Beispielwert ohne tieferen Sinn.

 * http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt  wrote:*   

> 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
> 
>            machine with highmem) the number of lowmem RAM pages,
> ...

 

----------

## Yamakuzure

 *mv wrote:*   

>  *Yamakuzure wrote:*   hat wirklich keinerlei Code für optionales Journaling, und damit auch keinerlei Code-Verzweigungen." 
> 
> Ist mir schon klar, dass Du das gemeint hast, aber:

 *meh* Warum ignorierst du den "Spaß beiseite" Abschnitt? Aber der Vollständigkeit halber: 1: ziemlich sicher sogar, 2: Hatte ich nicht, habe ich jetzt, 3: Nein und 4: Jein.

Ansonsten:

```
 # grep portage /etc/fstab

none       /var/tmp/portage tmpfs defaults,relatime,size=8g,uid=250,gid=250,mode=775 0 0
```

hat immer gut funktioniert, bis das ganze WebKit-Gedöns losging. Die sind unmöglich mit 4GB RAM in einem tmpfs zu bauen. Sobald da Horden an Dateien gelinkt werden fängt mein Laptop gerne mal an zu swappen. Während auf der Platte gebaut wird, wohlgemerkt.

Fazit: Ich will 16GB RAM!   :Twisted Evil: 

----------

## musv

 *Yamakuzure wrote:*   

> Ansonsten:
> 
> ```
>  # grep portage /etc/fstab
> 
> ...

 

Libreoffice hätte auch gern mehr als 4GB. Und KDELibs bauen auch nicht mit 4GB tmpfs. Da meine Kiste Triple-Channel unterstützt, musste ich zwangsläufig auf 24GB aufrüsten. Ich glaub, bis auf 21 GB Speicherbelegung hatte ich's mal gebracht.

Bei Webkit-gtk nervt mich am meisten, dass der Müll nur mit MAKEOPTS="-j1" baut. Damit dauert das Compilieren wesentlich länger als Libreoffice, GCC oder KDElibs.

----------

