geohei Geschrieben 15. Februar 2009 Teilen Geschrieben 15. Februar 2009 Hallo. Ich habe einen HP DAT72 C7438A Streamer an einem Adaptec ASC-19160 über den LVD Bus angeschlossen. Wenn ich in ein Backup machen, bekommen ich nur 2 MB/s. Backups über Stunden bestätigen dieser Ergebnis. Der Rechner ist schnell genug. Es hängen keine anderen SCSI Geräte an diesem Bus. Hardware und Software Kompression sind abgeschaltet. Die HP C7438A Datenblätter sagen 3 MB/s sind möglich. wenn ich den Streamer an den SE Bus hänge, gibt es nur 1.5 MB/s. Weiß jemand warum der Streamer langsamer speichert als technisch möglich? Gruß, Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
DocInfra Geschrieben 15. Februar 2009 Teilen Geschrieben 15. Februar 2009 Ein Streamer kommt nur auf Touren wenn die Daten auch "passend" sind. Viele kleine Dateien sind nicht gut für die Performance. Große Blockdateien sind klasse, da kann der Streamer richtig gut ziehen. Ich tippe auf viele kleine Dateien. Die im Datenblatt angegebenen Datenraten schaffst du nur unter optimalen Bedingungen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
geohei Geschrieben 15. Februar 2009 Autor Teilen Geschrieben 15. Februar 2009 Das hatte ich vergessen zu erwähnen ... es sind GB große Files (Image Files). Von daher dürfte es also keine Probleme geben. Weiterhin fiel mir auf ... dass wenn ich die Hardware Kompression des Streamers einschalte, der Datendurchsatz sich nicht ändert. Es sind immer noch etwa 120 MB/s, was nur 2/3 der native (ohne Kompression) capacity ist. Natürlich habe ich für diesen Test sehr stark komprimierbare Files benutzt (selbst erstellt große Files von jeweils 1 GB mit lauter "00" Bytes). BTW ... betreibst du einen Streamer? Wenn ja, welchen? Gruß, Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
volker81 Geschrieben 16. Februar 2009 Teilen Geschrieben 16. Februar 2009 Wenn ich in ein Backup machen, bekommen ich nur 2 MB/s. Backups über Stunden bestätigen dieser Ergebnis. dass wenn ich die Hardware Kompression des Streamers einschalte, der Datendurchsatz sich nicht ändert. Es sind immer noch etwa 120 MB/s, Was denn nun? 2MB/s oder 120MB/s ? Mit was für einer Software sicherst du denn? Was sagen die Logs vom Streamer aus? Woher nimmst du die Werte für Geschwindigkeit und Zeit? Was macht der Server in der Zeit noch? Paar mehr Angaben bitte! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
FfFCMAD Geschrieben 19. Februar 2009 Teilen Geschrieben 19. Februar 2009 1. Images sind Binaerdaten und lassen sich meist nicht gut komprimieren. Zumindest nicht wenn die Datenkompression nicht darauf ausgelegt ist. Ausserdem ist bei Images oft Muell dabei, da hier ja ein Abbild vom Datentraeger genommen wird. Die ganzen Bits die durch geleoschte Dateien zwar noch gesetzt sind, aber natuerlicherweise nicht verwendet werden werden beim Image auch einbezogen. Intelligente Datensicherungsprogramme nehmen nur die Nutzdaten und das Dateisystem mit. Ungenutze Bloecke werden ausgeblendet und beim Wiederherstellen einfach mit Nullen gefuellt. 2. Die 3Mbyte pro Sekunde sind das Maximum. Ob das in der Praxis erreicht wird ist eine andere Frage. Wenn der Streamer Parity unterstuetzt schalte das mal testweise ab. Zudem "SCSI Disconnect" einschalten. Andere Geraete machen uebrigens keine Probleme, wenn der Streamer die hoechste Prioritaet hat. 3. Ich glaube nicht das du ansonsten viel tun kannst. Vielleicht kann ein anderer Controller abhelfen. Hat schonmal jemand versucht ein Streamer-RAID0 zu erstellen? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
DocInfra Geschrieben 19. Februar 2009 Teilen Geschrieben 19. Februar 2009 Also wenn das Ding 2 MB/s, also 120 MB/Minute bringt, aber 3 MB/s bringen sollte, dann kann man nicht mehr viel machen. Imagedateien lassen sich i.d.R. nicht gut komprimieren. Ich würde mir da keine weiteren Gedanken zu machen. Ich meine wir reden hier von DAT... Ich betreibe zwar selber keinen Streamer, habe aber diverse Tapes bei Kunden verteilt. Da ist vom DAT bis zur 1000 Slot Bandlibrary alles dabei. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
geohei Geschrieben 22. Februar 2009 Autor Teilen Geschrieben 22. Februar 2009 Gleich eins vorweg ... das Problem ist gelöst. Es waren die Treiber von WinXP. ganz banal, aber ich habe sie erst vor einigen Monaten installiert und da lief alles. Da ich in der Zwischenzeit an der SCSI rumgemacht habe, dachte ich zuerst an ein Hardware Problem. Siehe hier: Message-ID: <1232950254_417@vo.lu> @volker81 Software: Retrospect 7.5.251 Die Logs bestätigen die Speed, zeigen keine Fehler! Den Durchsatz lese ich ab und bestätige per Zeitmessung. Server ist quasi idle. 2MB/s wären dann 120 MB/min? Ein Typo meinerseits. Sorry! @bla!zilla Nach dem Einspielen der Adaptec Treiber funktioniert alles tadellos. 3 MB/s sind ja nichts für SCSI und PCI bus. Von daher muss 3 MB/s ja schon erreicht werden. Danke für die Hilfe! Gruß, Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Thombo Geschrieben 26. Februar 2009 Teilen Geschrieben 26. Februar 2009 Generell nochmal eine kleine Info dazu: (evtl. findet jemand den Thread nochmal per SuFu und hat n ähnliches Problem) Es sollte nie ein SCSI-Controller zum Einsatz kommen der RAID-Funktionen hat. Bei einem Bandlaufwerk mit U-160 SCSI soll auch ein u-160 Controller zum Einsatz kommen (und kein 320) 1.) SCSI Bus richtig terminieren 2.) IDs passend einstellen 3.) SCSI-Treiber des Herstellers verwenden (Achtung, Adaptec hat für die "kleinen" Adapter z.Bsp. keine 64bit Treiber, wenn ein 64bit OS eingesetzt wird, an sowas vorher denken) 4.) Backup-Software installieren 5.) Backup-Software aktualisieren 6.) Als Treiber für das Bandlaufwerk den Treiber der Backup-Software (falls mitgeliefert) verwenden. Generell ist es eine gute Idee, vorher beim Hersteller des Bandlaufwerkes zu prüfen welche SCSI-Adapter empfohlen werden. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
DocInfra Geschrieben 26. Februar 2009 Teilen Geschrieben 26. Februar 2009 Es sollte nie ein SCSI-Controller zum Einsatz kommen der RAID-Funktionen hat. Das ist pauschal erstmal Quatsch. Manche SCSI RAID Controller können mit Tape-Drives nichts anfangen, korrekt. Bei der Empfehlung geht es aber viel mehr darum, wo die Platten angeschlossen sind. Um den SCSI Controller, bzw. den Bus nicht zu überfordern, sollte man Tape und Platten trennen. Daher nicht an einen Controller. Bei einem Bandlaufwerk mit U-160 SCSI soll auch ein u-160 Controller zum Einsatz kommen (und kein 320) Ist auch Quatsch und hat in meinen Augen auch keinen sinnvollen Hintergrund. Das ein U320 Streamer an einem U160 Controller unglücklich ist, ist klar. Aber an einen U320 kann ich durchaus zwei U160 Streamer hängen (z.B. zwei LTO-1 oder 2 an einen U320, aber nur ein LTO-3 oder LTO-4 an einen U320). Ein LTO-2 macht, bei einer 1:2 Kompression, ca. 60 MB/s. Mit zwei Laufwerken ist selbst ein U160 nicht mal ausgelastet. Bie LTO-3 und LTO-4 sieht das anders aus. 1.) SCSI Bus richtig terminieren ACK! 2.) IDs passend einstellen NACK. Passiert ja wohl mehr oder weniger automatisch, oder? Controller ist i.d.R. 7, also kann man sich für seine Laufwerke irgendwas zwischen 0 bis 6, und 8 bis 15 aussuchen. Die meisten Laufwerke stehen vom Werk aus auf 2 oder 3. 3.) SCSI-Treiber des Herstellers verwenden (Achtung, Adaptec hat für die "kleinen" Adapter z.Bsp. keine 64bit Treiber, wenn ein 64bit OS eingesetzt wird, an sowas vorher denken) ACK! Generell ist es eine gute Idee, vorher beim Hersteller des Bandlaufwerkes zu prüfen welche SCSI-Adapter empfohlen werden. Im Prinzip alle aktuellen die es auf dem Markt gibt. Bei den meisten handelt es sich eh um OEM Produkte von LSI oder Adaptec. btw: SCSI ist mehr oder weniger tot. Die neuen Laufwerke kommen meist nur noch aus Kompabilitätsgründen mit einem SCSI Interface auf den Markt. SAS setzt sich gerade mehr und mehr bei den lokalen internen und externen Laufwerken durch. Wenn wir uns in Richtung SAN bewegen, dann ist da Fibre-Channel gesetzt. Und bei SAS entfallen die ganzen dämlichen Dinge wie IDs, Terminierung und Busse. Jedes Laufwerk hat die volle Performance an seinem Bus. Da zählt nur noch die Bandbreite des Controllers und das, was die Platten hergeben. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Thombo Geschrieben 26. Februar 2009 Teilen Geschrieben 26. Februar 2009 Das ist pauschal erstmal Quatsch. Manche SCSI RAID Controller können mit Tape-Drives nichts anfangen, korrekt. Bei der Empfehlung geht es aber viel mehr darum, wo die Platten angeschlossen sind. Um den SCSI Controller, bzw. den Bus nicht zu überfordern, sollte man Tape und Platten trennen. Daher nicht an einen Controller. Das sind die Aussagen wie ich sie immer wieder von den Herstellern höre. In der täglichen Praxis kann ich das bestätigen. Selbst wenn an dem SCSI-Controller nur ein Gerät (das Band-LW) hängt, kann es mit RAID-fähigen Controllern Probleme geben. Ist auch Quatsch und hat in meinen Augen auch keinen sinnvollen Hintergrund. Das ein U320 Streamer an einem U160 Controller unglücklich ist, ist klar. Aber an einen U320 kann ich durchaus zwei U160 Streamer hängen (z.B. zwei LTO-1 oder 2 an einen U320, aber nur ein LTO-3 oder LTO-4 an einen U320). Ein LTO-2 macht, bei einer 1:2 Kompression, ca. 60 MB/s. Mit zwei Laufwerken ist selbst ein U160 nicht mal ausgelastet. Bie LTO-3 und LTO-4 sieht das anders aus. Wenn Laufwerk = 160 dann Controller auch 160, sonst siehe oben NACK. Passiert ja wohl mehr oder weniger automatisch, oder? Controller ist i.d.R. 7, also kann man sich für seine Laufwerke irgendwas zwischen 0 bis 6, und 8 bis 15 aussuchen. Die meisten Laufwerke stehen vom Werk aus auf 2 oder 3. Auch hier: Auf jeden Fall prüfen. Ich habs auch schon gesehen gesehen dass Tape-Libary und Laufwerk dieselbe ID hatten und deswegen die Sicherung auch nur sporadisch lief, beide IDs waren ab Werk so eingestellt. Im Prinzip alle aktuellen die es auf dem Markt gibt. Bei den meisten handelt es sich eh um OEM Produkte von LSI oder Adaptec. jepp, hier aber auch mit der Einschränkung: Es gibt für die günstigen SCSI-Controller in der Regel keine 64bit Treiber vom Hersteller, sondern meistens nur die generischen vom OS, deswegen hier vorher prüfen. btw: SCSI ist mehr oder weniger tot. Die neuen Laufwerke kommen meist nur noch aus Kompabilitätsgründen mit einem SCSI Interface auf den Markt. SAS setzt sich gerade mehr und mehr bei den lokalen internen und externen Laufwerken durch. Wenn wir uns in Richtung SAN bewegen, dann ist da Fibre-Channel gesetzt. Und bei SAS entfallen die ganzen dämlichen Dinge wie IDs, Terminierung und Busse. Jedes Laufwerk hat die volle Performance an seinem Bus. Da zählt nur noch die Bandbreite des Controllers und das, was die Platten hergeben. ACK SAS ist einfach toll Leider wird es wohl doch noch ne Weile dauern bis keine SCSI-Laufwerke mehr verkauft werden Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Thanks-and-Goodbye Geschrieben 26. Februar 2009 Teilen Geschrieben 26. Februar 2009 In der täglichen Praxis kann ich das bestätigen. Selbst wenn an dem SCSI-Controller nur ein Gerät (das Band-LW) hängt, kann es mit RAID-fähigen Controllern Probleme geben. Jupps... bestätigt aus der freien Wildbahn. Wir haben das auch mal vor ein paar Jahren ausprobiert. Ein Streamer am Raidcontroller (selbst wenn es ein Mehrkanalcontroller ist und der Streamer alleine am zweiten Kanal hing) funktionierte die Datensicherung wie ein guter Autoblinker. Übrigens: von FSC ist das für die Primergy Server zum Teil (ich habe seit zwei Jahren keine Primergy mehr installiert) generell nicht freigegeben: keine Garantie für Streamer am Raidcontroller. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
DocInfra Geschrieben 26. Februar 2009 Teilen Geschrieben 26. Februar 2009 HP Supported es bei Smart Array Controllern auch nicht, außer dem 6i. Da geht es aber dann auch problemlos. Zudem geht es bei einigen ICP-Vortex und Mylex. Also so pauschal kann man die Aussage nicht ziehen lassen. Bezüglich IDs: Das man die vorher kontrollieren sollte ist schon klar. Aber es bringt nichts daran rumzufummeln, wenn keine ID doppelt vergeben ist. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.