View previous topic :: View next topic |
Author |
Message |
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Sun Aug 10, 2014 8:59 pm Post subject: Welches Dateiensystem für viele kleine Dateien + kompression |
|
|
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 |
|
|
oliver2104 Apprentice
Joined: 27 Jul 2004 Posts: 214 Location: Wien
|
Posted: Mon Aug 11, 2014 11:15 am Post subject: |
|
|
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 |
|
|
l3u Advocate
Joined: 26 Jan 2005 Posts: 2545 Location: Konradsreuth (Germany)
|
Posted: Mon Aug 11, 2014 11:54 am Post subject: |
|
|
ReiserFS ist veraltet. Ich würd einfach ext4 nehmen. |
|
Back to top |
|
|
Child_of_Sun_24 Guru
Joined: 28 Jul 2004 Posts: 578
|
Posted: Mon Aug 11, 2014 12:26 pm Post subject: |
|
|
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 |
|
|
musv Advocate
Joined: 01 Dec 2002 Posts: 3337 Location: de
|
Posted: Mon Aug 11, 2014 12:27 pm Post subject: |
|
|
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 |
|
|
Yamakuzure Advocate
Joined: 21 Jun 2006 Posts: 2284 Location: Adendorf, Germany
|
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
Posted: Mon Aug 11, 2014 4:36 pm Post subject: |
|
|
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.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
Back to top |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Tue Aug 12, 2014 6:18 pm Post subject: |
|
|
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 |
|
|
l3u Advocate
Joined: 26 Jan 2005 Posts: 2545 Location: Konradsreuth (Germany)
|
Posted: Tue Aug 12, 2014 11:18 pm Post subject: |
|
|
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 |
|
|
bell Guru
Joined: 27 Nov 2007 Posts: 510
|
Posted: Wed Aug 13, 2014 8:51 pm Post subject: |
|
|
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 |
|
|
musv Advocate
Joined: 01 Dec 2002 Posts: 3337 Location: de
|
Posted: Thu Aug 14, 2014 6:20 am Post subject: |
|
|
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 |
|
|
SarahS93 l33t
Joined: 21 Nov 2013 Posts: 693
|
Posted: Thu Aug 14, 2014 8:00 am Post subject: |
|
|
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 |
|
|
musv Advocate
Joined: 01 Dec 2002 Posts: 3337 Location: de
|
Posted: Thu Aug 14, 2014 6:44 pm Post subject: |
|
|
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 |
|
|
Hilefoks l33t
Joined: 29 Jan 2003 Posts: 849 Location: Emden / Deutschland
|
Posted: Fri Aug 15, 2014 2:10 pm Post subject: |
|
|
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 |
|
|
Christian99 Veteran
Joined: 28 May 2009 Posts: 1668
|
Posted: Fri Aug 15, 2014 3:56 pm Post subject: |
|
|
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 |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Sat Aug 16, 2014 3:59 pm Post subject: |
|
|
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 |
|
|
|