# Welches Dateiensystem für viele kleine Dateien + kompression

## SarahS93

Welche Dateiensysteme eignen sich für viele kleien Dateien, bieten optionen für Kompression und verkraften es auch wenn das System ausgeschaltet anstatt runtergefahren wird?

----------

## oliver2104

Das ReiserFS wäre vielleicht dafür geignet. Verwende ich auch.

Ist ideal für viele kleine Dateien, verkraftet auch zb. einen plötzlichen Stromausfall.

Habe aber keine Erfahrung betreffend Kompressionsoptionen.

Dieses Problem hatte ich, aufgrund der heutzutage üblichen

Festplatten-Kapazitäten noch nicht.

----------

## l3u

ReiserFS ist veraltet. Ich würd einfach ext4 nehmen.

----------

## Child_of_Sun_24

So gut wie alle Dateisysteme "verkraften" ein plötzliches ausschalten, die Frage ist nur ob die zuletzt getätigten Transaktionen verworfen werden (Womit es schonmal vorkommen kann das Dateiänderungen beim nächsten Neustart wieder den vorherigen Inhalt haben).

Ext2 wäre hier am besten da es kein Journal benutzt und Änderungen sofort gespeichert werden (Könntest du natürlich auch bei ext3 und ext4 so einstellen).

Wenn es um Kompression geht fallen mir nur reiser4 und btrfs ein (Allerdings würde ich beide nicht für die Speicherung von wichtigen Dateien benutzen, zudem nehmen sie dir plötzliches ausschalten mitunter sehr übel).

Aus dem Bauch raus würde ich sagen das für dein Anwendungsgebiet kein Dateisystem mit Kompression zur Verfügung steht.

----------

## musv

ReiserFS hatte zudem das Problem der starken Fragmentierung. Auch wenn das offiziell nicht gegeben haben soll, konnte ich damals feststellen, wie die Platte immer langsamer wurde mit der Zeit. 

Reiser4 war da schon besser und auch erstaunlich stabil in Sachen Stromausfall. Auch mit der Kompression konnte das Dateisystem punkten. Reiser4 wurde aber auch mit der Zeit langsamer und ist im Endeffekt mit Kernel-2.6.38 (endgültig?) gestorben. 

Aktuell soll wohl BTRFS in Sachen kleine Dateien und Kompression eine ganz gute Wahl sein. Bei der Stabilität vertrau ich BTRFS aber noch nicht 100%-ig. Hab es jetzt schon ein paar Jahre im Einsatz. 1x hatte ich das Dateisystem abgeschossen. Weiß nicht mehr, mit welchem Befehl ich es dann repariert hatte.

----------

## Yamakuzure

ZFS. Gut mit vielen kleinen Dateien, variable LZ4-Kompression, sehr robust gegen plötzliches Abschalten.

----------

## kernelOfTruth

 *Yamakuzure wrote:*   

> ZFS. Gut mit vielen kleinen Dateien, variable LZ4-Kompression, sehr robust gegen plötzliches Abschalten.

 

kann dem nur zustimmen:

https://forums.gentoo.org/viewtopic-p-7591700.html#7591700

das Dateisystem (ZFS) hat hier schon dutzende Hardlocks, Resets, etc. überlebt ohne dass es zu Datenverlust, Inkonsistenzen, etc. gekommen ist

wenn das System immer läuft und stets auf viele kleine Dateien zugegriffen wird wäre es evtl. hilfreich eine SSD als L2ARC einzuhängen (einen Reboot überlebt der L2ARC ohne Patch noch nicht und es dauert dementsprechend

eine Weile, bis dieser wieder "warm" ist),

aus Daten-Sicherheitsgründen sollte noch eine zweite Platte ("Raid1", Mirror-Mode) eingehängt werden

und natürlich externe Backups

Btrfs läuft hier mittlerweile standardmäßig auf der Systemplatte, wobei es bis vor kurzem bei Testläufen auf zusätzlichen Backup-Platten zu Problemen mit Hängern (http://marc.info/?l=linux-btrfs&m=140742753821490&w=2) und auch mal ENOSPC (http://marc.info/?t=140702264100001&r=1&w=2) gekommen ist

bis vor einige Kernel-Versionen wirkte Btrfs auf Systemplatten noch recht fragil und Datenkorruption, Unfähigkeit zu Mounten, etc. sind aufgetreten - das sollte großteils behoben sein (es tauchen auf der Mailing-Liste immer wieder noch Bugfixes für damit in Verbindung stehende Meldungen auf)

wie es mit Raid, Volumes, Snapshots, Sends, etc. ausschaut, weiß ich aus persönlicher Erfahrung nicht - nach Posts auf der Mailing-Liste gibt es aber immer noch (un)regelmäßig Probleme

als wirklich stabil ist es Btrfs also nicht zu bezeichnen.

ZFS ist natürlich auch nicht ohne Fehler und/oder Probleme (https://github.com/zfsonlinux/zfs/issues ), hat sich aber schon in der Vergangenheit bewährt bzw. ist aber schon in kritischen Projekten im Einsatz (LHC, ...), wo es auf Datenintegrität wirklich ankommt

Für beide Dateisysteme gilt: je mehr Arbeitsspeicher, desto besser und: 64bit ist Pflicht

----------

## SarahS93

Mit 64 Bit läuft mein System.

Mir fällt es mal wieder schwer auszudrücken und zu beschreiben was ich eigentlich vorhabe.

Ich will um die 10 VM mit qemu laufen lassen. Das ganze muss neben meinem System was derzeit um die 12GB belegt auf die 240GB große SSD passen.

Anfangs dachte ich immer ich halte die VM klein, so um die 2 bis 5 GB je nach dem was das System darin braucht (gui oder keine gui, kde oder xfce usw...)

Weiter dachte ich ok ich lagere alles per smb/nfs auf eine hdd aus (portage, /temp, /usr/src/<kernel>.

Aber das wird alles zu umständlich und dann sind die VM so sehr mit meinem Haupt system durch die Netzwerkfreigaben und UserIDs der Freigaben verknüpft das mir das alles schon nicht mehr gefällt.

Daher will ich glaube ich eher den Weg ansteuern 32GB für jede VM und alles bleibt in der VM. Alles bleibt beisammen.

Nur weiss ich einfach nicht welches Dateiensystem ich den VM geben soll.

Wie halte ich die 10 32GB VM komprimiert so klein das sie auf meine Ca. 200GB freie SSD passen?

Kann Qemu eine VM-ImageDatei komprimieren, lässt diese sich dann aber noch per losetup einfach so einhängen?

Meine CPU ist starkt, daher denke ich schon das diese kompressionssache die beste lösung sein könnte, nur wie sollte ich das angehen?

----------

## l3u

 *SarahS93 wrote:*   

> Wie halte ich die 10 32GB VM komprimiert so klein das sie auf meine Ca. 200GB freie SSD passen?

 

Gar nicht. Nimm eine 320-GB-HD und erstelle Raw-Images mit 32 GB Größe drauf. Vielleicht ein bischen kleiner. Mit Kompression wird das nichts IMHO.

Abgesehen davon hat das mit kleinen Dateien (vgl. 1. Post?!) nichts zu tun, weil die virtuelle Festplatte jeder VM das ganze Gegenteil einer kleinen Datei ist (es sei denn, du findest, dass 32 GB große Dateien klein sind).

----------

## bell

Im Zusammenhang mit mehreren (ähnlichen) VM's hatte ich mal von "Data Deduplication" bei einem Vortrag gehört. Ich denke Du suchst (ua.) nach so etwas. Die selbe Datei in mehreren VM's belegt am Ende nur 1x den Speicherplatz im Host-Dateisystem. Die VM's sind jedoch komplett unabhängig von einander. Nach einer kurzen Suche fand ich dass ZFS es kann, mit Patches brtfs (oder offline-deduplication) und auch ein "lessfs" welches ich nicht kenne, es kann. Damit also die 320GB Host-HDD formatieren und die technologie benutzen. Welches Dateisystem die VM's selbst haben ist glaube ich egal. Es sollte gleich sein damit gleiche Dateien auch gleich gespeichert werden um als doppelt erkannt zu werden. Das Data Deduplication erfordert jedoch viel RAM, wie ich es lese. Erkundige Dich, ich habe damit auch bisher noch keine praktische Erfahrung, fand aber die Theorie interessant.

----------

## musv

 *SarahS93 wrote:*   

> Kann Qemu eine VM-ImageDatei komprimieren,...

 

Wenn du eine virtuelle Platte in Qemu neu anlegst, kannst du die als QCow2-Image anlegen. Ich hab das noch so in Erinnerung, dass die grob nur soviel Platz braucht, wie du innerhalb der VM brauchst.

----------

## SarahS93

Das mit dem QCow gefällt mir nicht. Wenn die VM zu gross wird, und ich darain dann Dinge deinstalliere/lösche .. wird sie bestimmt nicht von selbst wieder kleiner?

Die VM Datei soll eine feste Größe haben.

Wie stelle ich mir das mit btrfs, zfs, xfs, und der Datenkompression vor? Ich lege eine z.B, 16GB grosse VM Image-Datei im Host an, in dieser läuft die VM und das Dateiensystem dort ist mit z.B. btrfs formatiert und kompression der Daten. Sieht das System in der VM dann das da 16GB Speicherplatz ist, und es wird je nach kompressionsrate nur langsammer voll beim beschreiben? Habe ich eine übersicht wie gut sich welche Datei/Verzeichniss kompremieren lassen?

Ist brtfs für meine vorhaben das richtige Dateiensystem?

----------

## musv

 *SarahS93 wrote:*   

> Das mit dem QCow gefällt mir nicht. Wenn die VM zu gross wird, und ich darain dann Dinge deinstalliere/lösche .. wird sie bestimmt nicht von selbst wieder kleiner?  Die VM Datei soll eine feste Größe haben.

 

Hab ich nicht ausprobiert. Aber da im Image normalerweise auch ein Dateisystem verwendet wird, wo beim Löschen normalerweise nur die Blöcke als ungültig markiert werden, könnte man davon ausgehen, dass das Image nicht schrumpfen wird. 

Andererseits bist du mit QCow und dynamischer Allocation des Festplattenspeichers definitiv maximal so groß wie bei einem Image mit fester Größe.

Und als nächstes gibt's bei Qemu mit libvirt noch als Gast-Dateisystem VirtIO. Mit diesem Treiber "weiß" im Endeffekt das System, dass es sich in einer VM befindet und spart sich den Overhead (und vermutlich die Optimierungen) für ein eigenes Dateisystem und überlässt die Dateisystemoperationen dem Host. Damit könnte es u.U. sogar möglich sein, dass das QCow-Image wieder schrumpft, wenn du im Gast eine Datei löschst. 

 *SarahS93 wrote:*   

> Wie stelle ich mir das mit btrfs, zfs, xfs, und der Datenkompression vor? 

 

XFS hat überhaupt keine Kompression. Wie der Stand von ZFS bei Linux ist, weiß ich nicht. Es ist für Solaris konzipiert und für ca. 10 Festplatten oder mehr optimiert und braucht einige GB RAM um vernünftig zu funktionieren. 

Bei BTRFS kannst du in den Mountoptionen einstellen, wie die zu schreibenden Inhalte komprimiert werden sollen. In meiner fstab sieht das z.B. so aus:

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

Damit jagt das BTRFS sämtliche zu schreibende Inhalte erst durch den LZO-Kompressor, bevor es auf der Platte landet. Bereits komprimierte Inhalte (Bilder, Videos) werden weniger erfolgreich komprimiert, bei Textdatei sieht's entsprechend besser aus. Ob's irgendwo eine dynamische Statistik dafür gibt, bezweifel ich mal.

----------

## Hilefoks

 *SarahS93 wrote:*   

> [...]Anfangs dachte ich immer ich halte die VM klein, so um die 2 bis 5 GB je nach dem was das System darin braucht (gui oder keine gui, kde oder xfce usw...)[...]

 

Zurück zum Anfang... was willst du mit deinen VMs erreichen und welche Anforderungen hast du eigentlich? Klingt für mich so, als wenn du hauptsächlich Linux laufen lassen möchtest. In dem Fall gibt es vielleicht bessere Alternativen. Sowohl was die Performance, wie auch was Speicherverbrauch angeht.

----------

## Christian99

auch wäre es möglich, die root partition per nfs einzubinden. da hast du dann auch keine image dateien mit vorher festgelegter größe. und du könntest updates auch mit der hostOS machen was, performanter sein sollte als in der VM (wenn du als guest Gentoo nimmst, bei binären distributionen ist es wohl egal)

----------

## mv

Zunächst Grundsätzliches: Kein Dateisystem kann Dir garantieren, dass es bei plötzlichem Ausschalten keinen Datenverlust gibt.

Nicht zuletzt kann es nämlich passieren, dass beim Zusammenbrechen von z.B. der Prozessorfunktionalität noch zufällige Daten an zufällige Orte der Festplatte (bevorzugt auf Track 0) geschrieben werden. Ist mir schon etliche Male passiert, bis ich mir jetzt endlich eine USV geleistet habe...

Und weil es noch nicht angesprochen wurde: squashmount (also squashfs zusammen mit aufs/overlayfs/unionfs-fuse/unionfs/funionfs zum Schreiben).

----------

