Unter Windows kann man Verzeichnisse so einstellen, daß Dateien, die man hineinschiebt, transparent komprimiert werden. Gibts sowas auch unter Linux?
avfs scheint auch eine (eingeschränkte) Lösung zu sein: es mountet Archivdateien ins Dateisystem und erlaubt so beliebigen Applikationen Lesezugriff auf die Daten. Leider ist es unter Ubuntu 12.04 defekt.
brtfs kann wohl bei Bedarf auch nur einzelne Verzeichnisse komprimieren http://radudi.com/index.php/2011/08/31/using-btrfs-per-file-and-per-directory-compression/
Komprimierende Verzeichnisse sind ein Furz. Man tauscht Geschwindigkeit gegen mehr [Platten-]Speicher. Da der eh nichts kostet, sollte man das sein lassen. Ein weiteres Problem, das auftaucht, ist bei einem Plattencrash. Da ist nichts mehr lesbar...
Zac Hobson schrieb: > Komprimierende Verzeichnisse sind ein Furz. Man tauscht Geschwindigkeit > gegen mehr [Platten-]Speicher. Da der eh nichts kostet, sollte man das > sein lassen. CPU leistung ist heute ausreichend vorhanden, andere verschlüsseln sogar die ganze festplatte und merken auch kein unterschied. > Ein weiteres Problem, das auftaucht, ist bei einem Plattencrash. Da ist > nichts mehr lesbar... ob die datei gepackt ist oder nicht ändert daran aber nichts. Entweder ist die datei lesbar oder nicht.
Zac Hobson schrieb: > Komprimierende Verzeichnisse sind ein Furz. Man tauscht Geschwindigkeit > gegen mehr [Platten-]Speicher. Hängt davon ab was schneller ist, Platte oder CPU. So pauschal kann man das nicht sagen.
A. K. schrieb: > https://wiki.archlinux.org/index.php/Btrfs#Compression Ist BTRFS ist im Kernel nicht immer noch als 'experimental' markiert?
CPUs hat man heute beim Heim-PC oft genug im Überfluss. Das Problem ist eher, dass dort die grössten Datenmengen durch Material anfallen, das nicht komprimierbar ist (Bilder/Video). Was für Material gibt es denn auf solchen PCs, das in relevanten Mengen anfällt und gut komprimierbar ist? Im Business sieht das etwas anders aus. Da kann hochverfügbarer Plattenplatz sehr viel teuer sein und dort finden sich auch genug komprimierbare Daten.
Zac Hobson schrieb: > Komprimierende Verzeichnisse sind ein Furz. So. > Man tauscht Geschwindigkeit > gegen mehr [Platten-]Speicher. Da der eh nichts kostet, sollte man das > sein lassen. Ich würde sagen, es kommt auf den Platz an, den man zu Verfügung hat und auf die Art von Daten, die man speichern will. NMEA-Tracks und daraus erzeugte html-Dateien sind so redundant, daß sich Kompression auch bei geringem Preis für Plattenplatz lohnt. > Ein weiteres Problem, das auftaucht, ist bei einem Plattencrash. Da ist > nichts mehr lesbar... Als wären unkomprimierte Daten nach einem Crash besser lesbar, als komprimierte... kelle schrieb: > Ist BTRFS ist im Kernel nicht immer noch als 'experimental' markiert? So weit ich weiß, ja. Und bei bestehendem ext4-Dateisystem zur Kompression irgendwelche File-Container mit BTRFS drin zu basteln, ist vielleicht doch etwas überzogen... Ich hoffe einfach mal darauf, das die Canoniker das avfs bald reparieren - auf Debian funktionierts jedenfalls.
Uhu Uhuhu schrieb: > Als wären unkomprimierte Daten nach einem Crash > besser lesbar, als komprimierte... Im Prinzip ja... da die Daten redundanzen enthalten ist es prinzipiell möglich diese aufgrund der Redundanz bei teilweisem Verlust zu rekonstruieren. Uhu Uhuhu schrieb: > NMEA-Tracks und daraus erzeugte html-Dateien sind so redundant Was spricht dagegen die Daten in einem ZIP Archiv zu speichern und das HTML nur bei Bedarf zu generieren? Alternativ eine MySQL Datenbank mit Archive Storage typ, da wird autoamtisch komprimiert... Alternativ wäre da noch fuse-zip wenn du es nun partou wie ein Verzeichnis ansprechen willst: http://code.google.com/p/fuse-zip/
Peter II schrieb: > CPU leistung ist heute ausreichend vorhanden, andere verschlüsseln sogar > die ganze festplatte und merken auch kein unterschied. doch, merkt man schon. seit schäuble verschlüssle ich alle datenträger und es ist ein unterschied bei den zugriffszeiten spürbar. gemessen hab ichs jedoch nicht weil sich erstens trotzdem damit arbeiten lässt und ich die verschüsselung haben will. kompression sollte man also auch merken, aber wen juckts wenn einem transparente kompression wichtiger ist als die letzten paar ms herauszuholen.
> Peter II schrieb: > > CPU leistung ist heute ausreichend vorhanden, andere verschlüsseln sogar > die ganze festplatte und merken auch kein unterschied. > c. m. (camikusch) schrieb: > doch, merkt man schon. Beide haben ein wenig Recht. WENN man als Verschlüsselungsalgorithmus AES einsetzt UND die CPU HardwareAES unterstützt UND das Betriebssystem dafür Module/Treiber bereitstellt, DANN geht's ab wie Schmidt's Katze. zB. VIA PadLock AES, Intel AES-NI
Läubi .. schrieb: > Was spricht dagegen die Daten in einem ZIP Archiv zu speichern und das > HTML nur bei Bedarf zu generieren? Daß regelmäßig Tracks dazu kommen, die HTMLs dann generiert werden und beides ohne Klimmzüge zugreifbar sein soll, ohne 5 mal so viel Speicher zu belegen, wie notwendig. > Alternativ eine MySQL Datenbank mit Archive Storage typ, da wird > autoamtisch komprimiert... Dann müssen alle Anwendungen, die auf den Daten arbeiten, mit der Datenbank kommunizieren können - das muß nicht sein. > Alternativ wäre da noch fuse-zip wenn du es nun partou wie ein > Verzeichnis ansprechen willst: > http://code.google.com/p/fuse-zip/ Aha, guter Tipp, das werde ich ausprobieren. Dürfte ein Ersatz für das kaputte avfs sein.
Läubi .. schrieb: > Alternativ wäre da noch fuse-zip wenn du es nun partou wie ein > Verzeichnis ansprechen willst: > http://code.google.com/p/fuse-zip/ Das ist sogar als fertiges Paket im Ubuntu-Repositorium. Merkwürdigerweise werden beim Anklicken einer Datei immer Execute Permissions zurückgegeben und man muß dann die passende Operation auswählen. Die Aktion hat aus 1 GB Daten 140 MB gemacht...
A. K. schrieb: > Das Problem ist eher, dass dort die grössten Datenmengen durch Material > anfallen, das nicht komprimierbar ist (Bilder/Video). Ich würd's etwas anders formulieren: Durch Material, das bereits (stark) komprimiert ist. Uhu Uhuhu schrieb: > Ich würde sagen, es kommt auf den Platz an, den man zu Verfügung hat und > auf die Art von Daten, die man speichern will. NMEA-Tracks und daraus > erzeugte html-Dateien sind so redundant, daß sich Kompression auch bei > geringem Preis für Plattenplatz lohnt. Hast du denn soviele Gigabytes an NMEA-Daten? Bei den aktuellen Festplattenpreisen kostet ein Gigabyte Platz so ca. 5-10 cent, je nach Plattengröße und ob 3,5" oder 2,5". >> Ein weiteres Problem, das auftaucht, ist bei einem Plattencrash. Da ist >> nichts mehr lesbar... > > Als wären unkomprimierte Daten nach einem Crash besser lesbar, als > komprimierte... Gerade bei NMEA und HTML, also textbasierten Files läßt sich da noch am meisten retten, wenn's nicht komprimiert ist. Wenn da ein paar Bytes nicht mehr lesbar sind, sind halt genau diese Bytes kaputt, und der Rest geht noch. Bei komprimierten Daten kann durch sowas dann gleich das komplette File komplett unbrauchbar werden. Wenn das File dann gar ein Container/Archiv ist, kann das schon größere Ausmaße annehmen.
Rolf Magnus schrieb: > Hast du denn soviele Gigabytes an NMEA-Daten? Bei den aktuellen > Festplattenpreisen kostet ein Gigabyte Platz so ca. 5-10 cent, je nach > Plattengröße und ob 3,5" oder 2,5". Das scheint ja wirklich furchtbar schwer zu verstehen zu sein: Mein Rechner ist konfiguriert und die Platte hat leider kein Loch, in das man Blumendünger kippen kann, damit sie wächst. Also ist es durchaus eine Überlegung wert, Daten mit viel Redundanz, die immer mal wieder, aber nicht andauernd zugegriffen werden, möglichst platzsparend unterzubringen. Das machen ja fast alle Audio-, Foto- und Videoformate auch - nur NMEA machts nicht und 1000 Stunden NMEA-Mitschrieb von einer GPS-Maus sind 1 GB. Was ein GB kostet, wenn man es heute kauft, ist ungefähr so interessamt, wie die Frage, ein Quadratmeter Blech kostet, wenn man den Kotflügel an seinem Atuto geschrottet hat. > Wenn das File dann gar ein Container/Archiv ist, kann das schon größere > Ausmaße annehmen. Es geht nicht darum, ein ordentliches Backup einzusparen.
ich habs nicht nachgemessen (weil ich nur noch SSDs habe), vermute aber, daß man redundante Daten sogar schneller zugreifen kann wenn sie komprimiert sind, da die datenrate der Festplatte der Bottleneck ist.
Uhu Uhuhu schrieb: > Daß regelmäßig Tracks dazu kommen, die HTMLs dann generiert werden und > beides ohne Klimmzüge zugreifbar sein soll, ohne 5 mal so viel Speicher > zu belegen, wie notwendig. Speicher die Tracks einfach einzeln ge-gzip-t (track.nmea.gz). Zum Verarbeiten kannst du die direkt mit zcat unkomprimiert ausgeben ohne sie erst "von Hand" dekomprimieren zu müssen. Mit Ruby, Python usw. können auch direkt beim Lesen gzip-dekomprimieren. Die HTML-Dateien würde ich genauso speichern, ich weiß zwar nicht ob ein Browser sie automatisch erkennt, aber ein kleiner Webserver der .html.gz-Dateien mit Content-type: html und Content-encoding: gzip ausliefert tut's auch (Beispiel s. Anhang).
Andreas Schwarz schrieb: > ob ein Browser sie automatisch erkennt Der FF hier öffnet wahlweise den Archive Manager, oder speichert die Datei ab. Man braucht also wirklich einen kleinen Server, damit der Mime Type beim Browser richtg ankommt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.