On-the-fly-Komprimierung unter Linux ?

On-the-fly-Komprimierung unter Linux ? (31 Beiträge, 417 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Gibts unter Linux auch sowas ?
Ich hab zwar schon danach gestöbert, aber nichts wirklich Brauchbares gefunden. chattr ist zwar recht lustig, hilft aber nicht wirklich wenn damit nichts passiert.

Interessant wären Erfahrungsberichte aus der Praxis, bitte keine "Ich hab mal von wem gehört, der sowas glaub ich schon mal gesehen hat..."

Nachtrag: Keine Bastel-, Alpha- ud sonstirgendwie instabile Lösungen, und auch für aktuellen Kernel (RHEL4)

15.01.2007, 14:37 Uhr - Editiert von Rikki, alte Version: hier

http://e2compr.sourceforge.net/

20.01.2007, 09:59 Uhr - Editiert von HITCHER, alte Version: hier

hast zu wenig platz auf deinem router?

das könnt besser geeignet sein.. is im aktuellen kernel tree:
http://sources.redhat.com/jffs2/

viele grüße

Gottfried

Leider kein Router. Es geht um einen Server mit inzwischen mehr als 1,7TB, wobei aber nicht alle Verzeichnisse ständig verwendet werden.
Ein gewisser Performanceverlust wär nicht weiter tragisch. Archivieren mit den Standardmitteln fällt aber aus, da die Datenbanken jederzeit im Zugriff sein müssen.

wie bekommt man 1.7T an daten zusammen..?

btw: ogg-vorbis, mp3, mpeg, divx, avi, jpeg, rar, zip usw... files lassen sich nicht mehr nennenswert weiter komprimieren.

da hast einen riesen rechenaufwand und max 1% kompression, wenns viele kleine files sind.

da ist es schon sinnvoller neue platten dazu zu stecken.. kosten eh einen schmarren heut zu tage.
viele grüße

Gottfried

mal überlegen, wenn von jeder Person in der EU Namen, Adresse, SV-Nummer, Tel-Nummer, Geburtsdatum, Beschäftigung, Familienverhältnisse, Kontodaten, usw. speicherst, (von allen 500 Millionen Einwohnern) dann kommt auf eine Person nur 3,6 kB an Daten. Evtl. geht sich noch ein kleines Passbild aus.

ogg-vorbis, mp3, mpeg, divx, avi, jpeg, rar, zip

Einen Server hast wohl noch nie gesehen oder ?

kosten eh einen schmarren

15k-SCSI-Platten und Storage-Rack kosten also nicht viel, aha...

Einen Server hast wohl noch nie gesehen oder ?

falsche annahme.

15k-SCSI-Platten und Storage-Rack kosten also nicht viel, aha...

bist selber schuld, wennst nicht gleich hinschreibst was sache ist.

nach deinen texten nahm ich erst an, daß du einen schwerstens gemoddeten wrt54g (oder wie auch immer das linksyskastl heißt) stehen hast und dir der platz für feature xy ausgeht.
und bei den >1TB dachte ich du hast eine warez/mp3/whatever kiste irgendwo einem provider untergeschoben und dir geht der platz aus.

auch wennst server hinschreibst... ich kenn dich ja nicht.. soviel ich wußte könntest du auch einer sein, ders grade geschafft hat einen warftpd (gibts den noch?) auf seinem 'betriebssystem' zu installieren und den mediamarkt-kasten jetzt server schimpft

wenn du sagt, daß die performance egal ist, dann wundere ich mich was da 15k rpm platten drinnen suchen, die 10k kosten pro gig ca. die hälfte. mean: wenn geld auch eine gewisse schlüsselrolle spielt.
aber sehe schon, daß es kaum möglich ist dort einen haufen handelsüblicher satas dazu zu stecken.

das mit den transparenten komprimierungen hat sich halt aus dem mainstream vertschüßt seit dems ende der 90er die gmr köpfe eingesetzt haben und die speicherdichte (im heimbereich) expodiert ist.

bei den serverreien.. -> großfirmen -> kauf ma halt was dazu

also wozu da noch zeit reinstecken.

PS: warum tust du das?
ich mein, ich wollt dir helfen und habe annahme getroffen. die waren falsch, das kann passieren wenn man raten muß. aber warum wirst du deswegen gleich so bissig? hmm?
ich wüßt jetzt nicht was ich verbrochen hab um so eine polemische antwort ab zu bekommen.
viele grüße

Gottfried

18.01.2007, 00:49 Uhr - Editiert von Gottfried, alte Version: hier

http://www.warftp.org/
Ist doch ein brauchbarer FTP-Server.

eh..
hab den früher selber mal verwendet.. und es ist der einzige ftp-server für windows, der mir auf die schnelle eingefallen is, deswegen steht er da.
viele grüße

Gottfried

15k-SCSI-Platten und Storage-Rack kosten also nicht viel, aha...

Ein gewisser Performanceverlust wär nicht weiter tragisch.

Ordentliches SATA-Raid mit ein paar Hotspares kostet doch nichts mehr.... und wenn eine Platte aussteigt - die 250GB bekommst inzwischen auch hinterhergeschmissen.

www.rechenkraft.net

Es gibt komprimierte Dateisysteme, nur sind die meist auf statische Daten ausgelegt (d.h. das komprimierte Archiv kann nur read-only geöffnet werden). Wenn du auf dem Server Verzeichnisse hast, aus denen nur gelesen, aber in die nicht (dauerhaft) geschrieben werden soll, kannst du das verwenden.

Es gibt Projekte, die sich an der dynamischen Komprimierung versuchen, aber ich kenne keines, das ausgereift und stabil genug wäre, um auf einem Server eingesetzt zu werden. Dem spendiert man eher ein neues SCSI/SATA-Disk-Array und ein gescheites Backup-System.

Das ist auch mein Wissensstand, was die transparente Komprimierung angeht ist Windoes dummerweise um Längen voraus.
Zusätzliche Raid-Arrays sind allerdings auch eine Kostenfrage...

(Gute) Server sind nun mal teuer. Und die transparente Komprimierung höchstens eine Notlösung (egal wie gut sie implementiert ist). Zumindest hatte ich bei Windows eher den Eindruck, daß das mehr für Heimanwender gedacht ist als für Server. Du weisst im Allgemeinen nie, wie gut komprimiert werden kann und wieviel Platz dir so tatsächlich zur Verfügung steht.

Wenn du im professionellen Umfeld eine Anwendung hast, die gigabyteweise Daten produziert, die sich gut komprimieren lassen, dann bringt man normalerweise der Anwendung bei, genau das zu tun (volle Kontrolle).

Wenn du es transparent machst, hast du beim Backup auf einmal wieder das Problem, daß die eigentlich bereits komprimierten Daten zum System hin ja nicht komprimiert erscheinen, und du sie unnötigerweise wieder komprimieren musst (es sei denn du hast so wahnsinnig viel Platz auf deinen Backup-Bändern, daß sich das nicht lohnt).

Nach dem was ich bisher so bei den transparent komprimierenden Projekten so mitbekommen hab, ist das zwar in der Theorie eine nette Idee, aber in der Praxis scheint das kaum jemand wirklich ernsthaft zu brauchen (sonst gäbs da mittlerweile wohl auch schon was richtig gutes für).

Ganz anders siehts mit den statisch komprimierten read-only Dateisystemen aus, die auf praktisch jedem Embedded-Linux zum Einsatz kommen, weil die entsprechenden Geräte heute immer noch sehr knapp mit Platz bemessen sind. Das wird mit den immer größer werdenen Flash-Speichern aber auch weiter in den Hintergrund rücken, jedenfalls wenn die CPU-Last kritischer wird als der Speicherverbrauch.

Dass es nur eine suboptimale Lösung ist ist natürlich klar.
Eine besondere Kompressionsrate an sich wäre nicht vorrangig, der Reiz dabei wäre neben dem Platzgewinn auch der geringe Aufwand.

Sonst bin ich kein grosser Windows-Fan. Aber z.B. bei Oracle lässt sich mit einem komprimierten Verzeichnis ohne grössere Tricks eine Reduzierung auf die Hälfte erreichen, oft sogar noch mehr.
Und das mit null Aufwand gegenüber Resize oder Reorganisation der Tablespaces, zudem bleibt trotz Komprimierung alles zugriffsbereit.

Backup ist wieder ein anderes Thema, das ist bestens abgedeckt. Reizvoll wäre es für Bereiche gewesen, die nicht ständig volle Performance benötigen. Und ein paar TB zum temporären Jonglieren zu haben ist auch praktisch.

Aus Performancesicht ist on-the-fly-Komprimieren natürlich Unfug, deshalb gibts im echten Unix-Umfeld wohl nichts vergleichbares.
Dass man sich bei Linux und ext aber zumindest Gedanken darüber gemacht hat beweisen die ext-Attribute. Warum es aber bisher nicht auch vom Kernel unterstützt wird hab ich nicht herausfinden können...

http://zlibc.linux.lu/download.html

Ich tät des aber trotzdem ned für Oracle oder ähnliches einsetzen

Remember what the dormouse said: Feed your head!

das würde imho. ohnehin nicht funktionieren, weil das nicht on-the-fly komprimiert, sondern nur on-the-fly dekomprimiert.

Naja cLoop wollt ich ihm ned antun, hab aber selbst überlesen das das nur decomprimiert.

Also cLoop würd ihm noch bleiben, k.a. aber wie effizient das ist.

Remember what the dormouse said: Feed your head!

Wer ist mit "ihm" gemeint ?
Kann es sein, dass hier ein Vorurteil herrscht ?

Wer ist mit "ihm" gemeint ?

Du eigentlich ?

Kann es sein, dass hier ein Vorurteil herrscht ?

Ähh ja, scheint so

Zu meiner Verteidigung muß ich aber sagen.. 90% GH User sind Männlein

Remember what the dormouse said: Feed your head!

90% GH User sind Männlein

Bleiben zum Glück noch immer 10% übrig

Bleiben zum Glück noch immer 10% übrig

und ich muß da wieder ins Fettnäpfchen treten

Remember what the dormouse said: Feed your head!

Mach dir nichts draus, hast eben deine 90%ige Chance genutzt.

Das e2compr ist keine Option? (Siehe HITCHER's Post)

man müsste halt RH mal dazu bringen ihren Kernel zu patchen ...

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung