# Dateisysteme - wie verteilen?

## Shagrath

Nun gut, wir mussten uns ja schon alle mal mit dieser Frage auseinandersetzen.

/boot ist ja für gewöhnlich immer ext2, das wird es bei mir auch bleiben.

Jetzt stellt sich die Frage nach dem Rest. Ich könnte / unter reiserfs stellen und /home unter XFS, da ich hier auch meine oggs und Videos lager. Oder sogar der ganze root? Wie groß sind in etwa durchschnittlich die Binarys? Besonders die von KDE und Konsorten? ReiserFS soll ja besonders bei kleinen Dateien gut skalieren. Bis zu welcher Größe hin gilt in diesem Fall für ReiserFS eine Datei als klein? Und kommt mir nicht mit Reiser4, das nutze ich schon aus psychologischen Gründen nicht (:. Dazu ist es mir noch zu neu.

----------

## Deever

So ein Unterschied besteht zwischen den Journaling Dateisystemen auch wieder nicht. Erst bei Hochlast wird es imho bemerkbar, welches man einsetzt. Ich würd eher zu XFS tendieren, da man über ReiserFS nicht nur Gutes hört...

Gruß,

/dev

----------

## c07

 *Shagrath wrote:*   

> /boot ist ja für gewöhnlich immer ext2, das wird es bei mir auch bleiben.

 

Wenn man schon eine eigene Partition für /boot hat (wofür es normalerweise keinen vernünftigen Grund gibt), kommt auch Minix in Frage. Und warum ausgerechnet bei /boot ein Journal entbehrlich sein soll und sonst nicht, leuchtet mir auch nicht ein.

 *Shagrath wrote:*   

> Wie groß sind in etwa durchschnittlich die Binarys?

 

Der Durchschnitt ist belanglos; entscheidend ist die Verteilung. Z.B. kann man mit 

```
find /usr/bin -size +0 -size -9 | wc -l
```

 die Zahl der Dateien in /usr/bin ermitteln, die exakt einen 4-KB-Block benötigen.

 *Shagrath wrote:*   

> ReiserFS soll ja besonders bei kleinen Dateien gut skalieren.

 

Was soll in diesem Zusammenhang "skalieren" bedeuten? Es geht halt bei kleinen Dateien sehr sparsam mit dem Platz um, ohne deswegen langsam zu werden.

 *Shagrath wrote:*   

> Bis zu welcher Größe hin gilt in diesem Fall für ReiserFS eine Datei als klein?

 

Entweder 1 Block (Standard) oder 4 Blöcke (mit mount -o tails=on ).

Generell sollte man sich auch mit den möglichen Optionen beschäftigen, wenn man sich überhaupt tiefere Gedanken über das ideale Dateisystem macht.

----------

## Shagrath

@c07 Danke! (wirklich)

 *Quote:*   

> die Zahl der Dateien in /usr/bin ermitteln, die exakt einen 4-KB-Block benötigen. 

 244.

 *Quote:*   

> Was soll in diesem Zusammenhang "skalieren" bedeuten? Es geht halt bei kleinen Dateien sehr sparsam mit dem Platz um, ohne deswegen langsam zu werden.

  Bisher dachte ich (wahrscheinlich weil ich keine passenden INformationsquellen kenn), dass das soviel wie 'hui superschnell' heißen soll.

 *Quote:*   

> Entweder 1 Block (Standard) oder 4 Blöcke (mit mount -o tails=on ). 

 Ist dies bei der oben ermittelten Zahl (244) ein verhältnismäßig guter Wert, dass es sich lohnen würde?

----------

## tam

 *Shagrath wrote:*   

> Jetzt stellt sich die Frage nach dem Rest. 

 

Ich mach immer alles in eine Partition mit ReiserFS. Bisher hatte ich damit noch nie ein Problem.

----------

## c07

 *Shagrath wrote:*   

>  *Quote:*   die Zahl der Dateien in /usr/bin ermitteln, die exakt einen 4-KB-Block benötigen.  244.

 

Die Zahl ist belanglos; es war nur ein Beispiel, wie man prinzipiell eine Größenverteilung ermitteln kann. Erstens kommt es auf die Relation zur Gesamtzahl an (kriegt man z.B. ohne die "-size"-Parameter) und zweitens besteht die Partition sicher nicht nur aus Binarys. Die sind in der Regel eher relativ groß, aber speziell in /usr/share gibts oft sehr viele Krümeldateien.

Spätestens wenn die Hälfte der Dateien deutlich kleiner als die Blockgröße ist und das Dateisystem die nicht speziell behandelt, läuft man Gefahr, durch die Platzverschwendung auch Performance zu verlieren (zumindest bei gut gefüllten Partitionen). Ganz kleine Dateien (die direkt in den Inode passen) werden aber auch von XFS und JFS nicht in einen eigenen Block gesetzt. Und meistens kann man auch die Blockgröße reduzieren.

 *Shagrath wrote:*   

>  *Quote:*   Was soll in diesem Zusammenhang "skalieren" bedeuten?  Bisher dachte ich (wahrscheinlich weil ich keine passenden INformationsquellen kenn), dass das soviel wie 'hui superschnell' heißen soll.

 

Es kann unter Normalbedingungen eher heißen, dass es langsamer ist, aber dafür in Extremsituationen bzw. im großen Maßstab auch noch vernünftig funktioniert. Wobei die Extremsituationen im Lauf der Zeit oft zum Normalfall mutieren und auch bei bestimmten Anwendungen (z.B. Server) völlig normal sein können.

----------

## Fauli

 *c07 wrote:*   

> Und warum ausgerechnet bei /boot ein Journal entbehrlich sein soll und sonst nicht, leuchtet mir auch nicht ein.

 

Die boot-Partition ist i. d. R. < 100 MB und dann ist die Dauer eines möglichen Filesystem-Checks vernachlässigbar. Ein Journal (also z. B. mit ext3) schadet aber auch nicht.

----------

## c07

 *Fauli wrote:*   

> Die boot-Partition ist i. d. R. < 100 MB und dann ist die Dauer eines möglichen Filesystem-Checks vernachlässigbar.

 

Dafür ist dann aber auch der Resourcenbedarf vom Journal vernachlässigbar. Wobei zugegebenermaßen zumindest der Platzbedarf nicht proportional zur Partitionsgröße steigt.

----------

## amne

Hihi, als bei /boot verkommt das wirklich zur Grundsatzdiskussion, in der Praxis ist das doch wirklich egal, oder?

PS: Meine /boot ist natürlich ext2, alles andere ist völlig inakzeptabel und Ressourcenverschwendung!  :Very Happy: 

----------

## c07

 *amne wrote:*   

> Hihi, als bei /boot verkommt das wirklich zur Grundsatzdiskussion, in der Praxis ist das doch wirklich egal, oder?

 

Eben (Ausgangspunkt war ja, dass ext2 quasi fix wär). Vor allem deshalb, weil diese Partition eh unnütz ist.

----------

## mrsteven

 *Fauli wrote:*   

> Die boot-Partition ist i. d. R. < 100 MB und dann ist die Dauer eines möglichen Filesystem-Checks vernachlässigbar. Ein Journal (also z. B. mit ext3) schadet aber auch nicht.

 

Außerdem, wann ist die Bootpartition überhaupt mal gemounted? Eigentlich wird sie doch beim Start nicht gemountet, und wenn man einen neuen Kernel hat, wird sie eingehängt und gleich wieder ausgehängt:

```
cd /usr/src/linux

mount /boot

make install

umount /boot

```

Wenn der Rechner während make install abschmiert, muss das schon ein großer Zufall sein.  :Shocked: 

----------

## c07

 *mrsteven wrote:*   

> Wenn der Rechner während make install abschmiert, muss das schon ein großer Zufall sein. 

 

Ja, aber dafür hast du auch praktisch keine Nachteile durch das Journal.

Wenn man nach der normalen Anleitung vorgeht, kopiert man übrigens Kernel, System.map und .config per Hand mit der Version im Namen und muss dann auch noch die grub.conf editieren und eventuell alte Kernel löschen (wobei die Frage ist, wieviel Prozent der /boot-Partitions-Besitzer dann noch an das umount denken).

----------

