Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Welches Dateiensystem für viele kleine Dateien + kompression
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
SarahS93
Apprentice
Apprentice


Joined: 21 Nov 2013
Posts: 261

PostPosted: Sun Aug 10, 2014 8:59 pm    Post subject: Welches Dateiensystem für viele kleine Dateien + kompression Reply with quote

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?
Back to top
View user's profile Send private message
oliver2104
Apprentice
Apprentice


Joined: 27 Jul 2004
Posts: 155
Location: Wien

PostPosted: Mon Aug 11, 2014 11:15 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
l3u
Advocate
Advocate


Joined: 26 Jan 2005
Posts: 2128
Location: Konradsreuth (Germany)

PostPosted: Mon Aug 11, 2014 11:54 am    Post subject: Reply with quote

ReiserFS ist veraltet. Ich würd einfach ext4 nehmen.
Back to top
View user's profile Send private message
Child_of_Sun_24
Guru
Guru


Joined: 28 Jul 2004
Posts: 358

PostPosted: Mon Aug 11, 2014 12:26 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2824
Location: de

PostPosted: Mon Aug 11, 2014 12:27 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Yamakuzure
Veteran
Veteran


Joined: 21 Jun 2006
Posts: 1684
Location: Bardowick, Germany

PostPosted: Mon Aug 11, 2014 3:04 pm    Post subject: Reply with quote

ZFS. Gut mit vielen kleinen Dateien, variable LZ4-Kompression, sehr robust gegen plötzliches Abschalten.
_________________
systemd - The biggest fallacies
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5921
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Mon Aug 11, 2014 4:36 pm    Post subject: Reply with quote

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
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.5.2

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
SarahS93
Apprentice
Apprentice


Joined: 21 Nov 2013
Posts: 261

PostPosted: Tue Aug 12, 2014 6:18 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
l3u
Advocate
Advocate


Joined: 26 Jan 2005
Posts: 2128
Location: Konradsreuth (Germany)

PostPosted: Tue Aug 12, 2014 11:18 pm    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
bell
Guru
Guru


Joined: 27 Nov 2007
Posts: 452

PostPosted: Wed Aug 13, 2014 8:51 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2824
Location: de

PostPosted: Thu Aug 14, 2014 6:20 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
SarahS93
Apprentice
Apprentice


Joined: 21 Nov 2013
Posts: 261

PostPosted: Thu Aug 14, 2014 8:00 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
musv
Advocate
Advocate


Joined: 01 Dec 2002
Posts: 2824
Location: de

PostPosted: Thu Aug 14, 2014 6:44 pm    Post subject: Reply with quote

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:
Code:
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.
Back to top
View user's profile Send private message
Hilefoks
l33t
l33t


Joined: 29 Jan 2003
Posts: 833
Location: Emden / Deutschland

PostPosted: Fri Aug 15, 2014 2:10 pm    Post subject: Reply with quote

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.
_________________
- Der Computer rechnet vor allem damit, dass der Mensch denkt. -
Back to top
View user's profile Send private message
Christian99
Veteran
Veteran


Joined: 28 May 2009
Posts: 1063

PostPosted: Fri Aug 15, 2014 3:56 pm    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4890

PostPosted: Sat Aug 16, 2014 3:59 pm    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum