Linux: Gibt es automatisch komprimierende Verzeichnisse?

https://wiki.archlinux.org/index.php/Btrfs#Compression

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.

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/

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...

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.