Merkwürdigkeiten bei Speicherkapazitäten von DDS-Bändern...

[future_former]

ich sichere meinen datenbestand mit DDS-bändern. dabei verwende ich DDS3/4/5 mit einem DAT72 (DDS5)-laufwerk.

ich habe ein seltsames verhalten beim sichern von mp3-dateien bemerkt: die medienkapazität liegt weit unterhalb der nativen kapazität eines bandes. so passen auf ein DDS5-band normalerweise bis zu 36 GB (36.000.000.00 bytes) unkomprimierter daten (nativ).
ich habe die maximal verfügbare kapazität bereits mit verschiedenen datentypen (office-dokumente, virtual machines, bilder, etc.) verifiziert und komme auf durchschnittlich ca. 31 bis 33 GB pro band.
beim sichern von mp3-dateien fällt dieser wert jedoch auf ungefähr nur 20 GB datenvolumen pro band zurück.

hat jemand einen tipp für mich, woran das liegen könnte ?


future_former

 

[MarkTheRipper]

was für ein dateisystem haben diese bänder?
weil es könnte doch sein, dass wegen der vielen kleine dateien ein größerer verwaltungsaufwand benötigt wird.

mfg

 

[future_former]

was für ein dateisystem haben diese bänder?
weil es könnte doch sein, dass wegen der vielen kleine dateien ein größerer verwaltungsaufwand benötigt wird.

DDS- bzw. backupbänder verwenden kein dateisystem wie NTFS oder FAT im herkömmlichen sinne. die daten werden proprietär von der jeweiligen sicherungssoftware auf das band geschrieben.
ich verwende ausschliesslich das bei windows beiliegende "NTBACKUP 5.1".

wenn ich bunt gemischte daten wie zips, rar, jpeg, office etc. sichere kommen da weitaus mehr einzeldateien zusammen als bei den mp3s, trotzdem sichert das laufwerk in diesem fall klaglos bis zu 32 GB weg.

ist halt seltsam, weil's fast ausschliesslich mp3s betrifft...


future_former

 

[jni]

Hat der Streamer immer die Kompression an ? Dann ist der Kompressionsalgorithmus vielleicht so schlecht, daß er bei schlecht kompriimerbaren Daten (wie z. B. mp3's) deutlich mehr Platz braucht, als unkomprimiert ?

Mach doch mal einen anderen Test: erzeuge mal ein paar sehr große Zip- oder Rar-Files und sichere die mal ! Ich denke das Verhalten ist dann noch schlechter als bei den mp3's.

 

[future_former]

Hat der Streamer immer die Kompression an ? Dann ist der Kompressionsalgorithmus vielleicht so schlecht, daß er bei schlecht kompriimerbaren Daten (wie z. B. mp3's) deutlich mehr Platz braucht, als unkomprimiert ?

Mach doch mal einen anderen Test: erzeuge mal ein paar sehr große Zip- oder Rar-Files und sichere die mal ! Ich denke das Verhalten ist dann noch schlechter als bei den mp3's.

ja, die hardware-kompression ist ständig eingeschaltet. das abschalten der hard- bzw. software-kompression erbrachte bisher allerdings kein ergebnis, immer das gleiche: band nach 2/3 voll. den test mit *.rar bzw. *.zip-files werde ich noch nachholen.
bei divx/xvid-videofiles ist es das gleiche wie bei mp3s - die nennkapazität des bandes wird nur zu 2/3 ausgenutzt... scheint auf den ersten blick tatsächlich am algorithmus zu liegen, so etwas habe ich mir auch schon gedacht.

wäre natürlich gut, wenn man das irgendwie beeinflussen könnte, weil schade um den verlorenen speicherplatz...

grüsse,


future_former

 

[jni]

Wenn das mit DivX das selbe ist, kannst du dir den Test mit den Zip-Files sparen. Da kommt mit Sicherheit das gleiche raus.

Ich würde mal vermuten, daß sich die Kompression gar nicht abschalten läßt - was natürlich Mist ist. Das wäre aber glatt mal ne Frage an den Herstellersupport.

Da die Verwaltungsinformationen so viel auch nicht sind, müßte man unkomprimiert schon immer 35,x GByte drauf bekommen, sofern die Dateizahl nicht in die Millionen geht.

 

[future_former]

Da die Verwaltungsinformationen so viel auch nicht sind, müßte man unkomprimiert schon immer 35,x GByte drauf bekommen, sofern die Dateizahl nicht in die Millionen geht.

tja, schön wär's... bei gemischten daten komme ich wenigstens auf ca. 85 bis 90 % der nennkapazität, multimedia verschwendet dagegen nur bänder...

ich werde mal beim support anfragen und die ergenisse dann hier posten.

besten dank für den gedankenaustausch ,


future_former

 

[passat3233]

Man muß beim Backup aufpassen:
Man kann die Kompression im Backup-Programm einschalten, da komprimiert dann das Backup-Programm die Daten, bevor es die aufs Band schiebt.
Oder man kann die Hardwarekompression einschalten. Das geht i.d.R. über einen Jumper am Bandlaufwerk. Da werden die Daten unkomprimiert zum Band geschoben und dann von einem Chip in der Laufwerkselektronik komprimiert und erst dann aufs Band geschoben.
Hat man die Hardwarekompression eingeschaltet, sollte man tunlichst die Softwarekompression des Backup-Programms ausschalten.
Und bei komprimierten Dateien kann eine Kompression auch den gegenteiligen Effekt haben. Es kann nämlich je nach Inhalt einer komprimierten Datei passieren, das die bei nochmaligem Kompressionsversuch größer wird!

Beispiel ZIP:
Es werden nicht nur die Dateien komprimiert, sondern in der ZIP-Datei stehen auch noch Informationen über die komprimierten Dateien mit drin, wie z.B. CRC-Prüfsumme, Dateiname, Pfadinformationen etc.

Da geschieht folgendes:

Inhalt ZIP-Datei 1:
Komprimierte Datei 1, Datei 2, Datei 3, etc. dazu werden Informationen über Datei 1-x in der ZIP-Datei gespeichert.

Wenn man nun eine ZIP-Datei noch einmal zippen will, passiert folgendes:
Inhalt ZIP-Datei 2:
Komprimierte ZIP-Datei 1, dazu Informationen über die ZIP-Datei 1.
Lässt sich ZIP-Datei 1 nicht weiter komprimieren, so ist Zip-Datei 2 größer als ZIP-Datei 1, da ja die Informationen über die Zip-Datei 1 zusätzlich hinzu gekommen sind.

Ich habe übrigens mit DDS etwas andere Erfahrungen:
Ich habe da mit eingeschalteter Hardwarekompression immer ca. 40-50% mehr als die native Kapazität auf ein Band bekommen.
Bei DDS3 mit 12 GB also ca. 16-18 GB.

Dabei waren aber selten komprimierte Dateiformate.
Neben den Formaten diverser Packer wie ZIP, RAR etc. sind auch fast alle Multimedia-Dateien komprimiert und auch PDFs speichern ihre Inhalte in einem komprimierten Format und lassen sich entsprechend sehr schlecht weiter komprimieren.
Auch viele Bildformate wie JPG, GIF, PNG speichern komprimiert.

 

[future_former]

Man muß beim Backup aufpassen:
Man kann die Kompression im Backup-Programm einschalten, da komprimiert dann das Backup-Programm die Daten, bevor es die aufs Band schiebt.
Oder man kann die Hardwarekompression einschalten. Das geht i.d.R. über einen Jumper am Bandlaufwerk. Da werden die Daten unkomprimiert zum Band geschoben und dann von einem Chip in der Laufwerkselektronik komprimiert und erst dann aufs Band geschoben.
Hat man die Hardwarekompression eingeschaltet, sollte man tunlichst die Softwarekompression des Backup-Programms ausschalten.
...
Ich habe übrigens mit DDS etwas andere Erfahrungen:
Ich habe da mit eingeschalteter Hardwarekompression immer ca. 40-50% mehr als die native Kapazität auf ein Band bekommen.
Bei DDS3 mit 12 GB also ca. 16-18 GB.

ich habe das beschriebene verhalten sowohl bei aktivierter als auch bei deaktivierter hard- bzw. softwarekompression festgestellt. was noch aussteht ist der versuch sämtliche kompression abzuschalten.

16-18 GB mit DDS3 ? das klappt vielleicht bei datenbanken oder unkomprimierten CAD-grafiken...

beste grüsse,


future_former

 

[passat3233]

16-18 GB mit DDS3 ? das klappt vielleicht bei datenbanken oder unkomprimierten CAD-grafiken...

Die Daten sind tatsächlich i.d.R. unkomprimierte CAD-Zeichnungen (aber fast keine DXF/DWG) und Office-Dateien wie .doc, .xls, etc.

Grüsse
Roman

 

[future_former]

Hat der Streamer immer die Kompression an ? Dann ist der Kompressionsalgorithmus vielleicht so schlecht, daß er bei schlecht kompriimerbaren Daten (wie z. B. mp3's) deutlich mehr Platz braucht, als unkomprimiert ?

ich habe jetzt folgendes ergebnis mit DDS4-bändern gemacht:

eingeschaltet: hardware-kompression (HP DAT72)
ausgeschaltet: software-kompression (durch NTBackup)

wenn die software-kompression abgeschaltet wird erreicht der streamer die unkomprimierte nennkapazität eines bandes (20 GB), mit eingeschalteter komprimierung nur 12 GB... beim DDS3 das gleiche spiel: 8 GB bei eingescalteter komprimierung, 12 GB bei abgeschalteter kompression.
offenbar arbeitet die software-kompression von NTBackup so schlecht, dass mehr als 1/3 des speicherplatzes verschwendet werden...


future_former

 

[Acid73]

Mhhhhhhhhh,,,komisch,,,,arbeite zwar jeden Tag mit diesen Baendern,,,aber von so einem Problem habe Ich jetzt auch noch nie was gehoert. Aber Ich denke auch das es am KA liegt. Hab meine Daten auch eine Zeit lanh so gesichert, aber mit LTO Baendern.