LTO-Laufwerke unter Linux

[Sebastian Suchanek]

Hallo NGs!

Aktuell bin ich gerade dabei, eine LTO-Library an meinem Linux-
Server in Betrieb zu nehmen. Konkret handelt es sich dabei um
eine Overland NEO2000, die mit je einem LTO1- und einem LTO3-
Laufwerk bestückt ist. Alle drei Geräte (die Library selbst und
die beiden Laufwerke) hängen am selben externen Port eines
Adaptec 29320ALP. Bei beiden Laufwerken ist nach Auskunft sowohl
der Library als auch tapeinfo unter Linux die
Hardwarekompression aktiv.
Als Software soll Bacula v5.2 auf Debian Jessie zum Einsatz
kommen.
Im Moment bin ich noch dabei, diverse Tests zu fahren, um sicher
zu stellen, dass die Hardware auch reibungslos funktioniert.
Dazu verwende ich - gemäß des Bacula-Handbuchs - das Tool
"btape" aus dem Bacula-Lieferumfang mit der "fill"-Option,
welche laut Anleitung das eingelegte Band testweise komplett
vollschreibt.

Bei diesen Tests ist mir die eher maue Datenrate beim Schreiben
aufgefallen: Das LTO1-Laufwerk kommt laut btape auf knapp
15,5MB/s, das LTO3-Laufwerk auf ca. 27,2MB/s. Zur Erinnerung:
Laut Spezifikation soll LTO1 20/40MB/s und LTO3 80/160MB/s
schaffen (jeweils unkomprimiert/komprimiert).
Außerdem ist mir aufgefallen, dass beim Test des LTO1-Laufwerks
nur um die 100MB geschrieben wurden - wobei ich nicht weiß, ob
die Testdaten, die btape schreibt, gut oder schlecht
komprimierbar sind. (Der LTO3-Test läuft gerade noch.)
Die CPU, ein Xeon E3-1225, langweilt sich bei diesen Tests
übrigens mit ca. 10-15% Last für den btape-Thread.

Soweit die Symptome.
Was mich nun gerne wissen würde: Sind diese niedrigen Datenraten
ansatzweise normal? Insbesondere beim LTO3-Laufwerk kann ich mir
das nicht so recht vorstellen...
Falls nicht: Wo und wie kann ich am besten ansetzen, um den
Flaschenhals zu ermitteln? (Und ihn anschließend beheben?)
Und zur geschriebenen Daten-Gesamtmenge: weiß jemand zufällig,
welche Art von Daten (gut oder schlecht komprimierbar) btape
schreibt? Bzw. wie kann ich herausfinden, ob die
Hardwarekompression der Laufwerke *wirklich* funktioniert?


TIA,

Sebastian

PS: Da ich nicht weiß, ob es sich um ein Hardware- oder
Software-Problem handelt, XP nach dchlm & dcoulm - f'up beim
Antworten bitte passend setzen.

[Dietz Pröpper]

Sebastian Suchanek wrote:

> Aktuell bin ich gerade dabei, eine LTO-Library an meinem Linux-
> Server in Betrieb zu nehmen. Konkret handelt es sich dabei um
> eine Overland NEO2000, die mit je einem LTO1- und einem LTO3-
> Laufwerk bestückt ist.

Ich habe im Keller fast die gleiche Library stehen. 2xLTO3, über Glasfaser
angeschlossen. Deine sind via Ultra320 angeschlossen, oder?

> Alle drei Geräte (die Library selbst und
> die beiden Laufwerke) hängen am selben externen Port eines
> Adaptec 29320ALP. Bei beiden Laufwerken ist nach Auskunft sowohl
> der Library als auch tapeinfo unter Linux die
> Hardwarekompression aktiv.
> Als Software soll Bacula v5.2 auf Debian Jessie zum Einsatz
> kommen.

Hier 7.4.

> Im Moment bin ich noch dabei, diverse Tests zu fahren, um sicher
> zu stellen, dass die Hardware auch reibungslos funktioniert.
> Dazu verwende ich - gemäß des Bacula-Handbuchs - das Tool
> "btape" aus dem Bacula-Lieferumfang mit der "fill"-Option,
> welche laut Anleitung das eingelegte Band testweise komplett
> vollschreibt.

Exakt. Und erst weiter machen, wenn der fill-Test ohne Befund läuft.

> Bei diesen Tests ist mir die eher maue Datenrate beim Schreiben
> aufgefallen: Das LTO1-Laufwerk kommt laut btape auf knapp
> 15,5MB/s, das LTO3-Laufwerk auf ca. 27,2MB/s.

Bekanntes Problem ;-). Füge in Deiner sd-config jeweils ein Maximum Block Size
= 1290240 (bzw. einen anderen möglichst großen Wert) hinzu. Und tune wenn Du
fertig bist auch noch ein wenig an der Maximum Network Buffer Size.

> Zur Erinnerung:
> Laut Spezifikation soll LTO1 20/40MB/s und LTO3 80/160MB/s
> schaffen (jeweils unkomprimiert/komprimiert).
> Außerdem ist mir aufgefallen, dass beim Test des LTO1-Laufwerks
> nur um die 100MB geschrieben wurden - wobei ich nicht weiß, ob
> die Testdaten, die btape schreibt, gut oder schlecht
> komprimierbar sind. (Der LTO3-Test läuft gerade noch.)
> Die CPU, ein Xeon E3-1225, langweilt sich bei diesen Tests
> übrigens mit ca. 10-15% Last für den btape-Thread.

An Deiner Stelle würde ich für die Tests zunächst auf jeden Fall unkomprimiert
schreiben. Da siehst Du einfacher, welche realen Transferraten etc. heraus
kommen.

> Und zur geschriebenen Daten-Gesamtmenge: weiß jemand zufällig,
> welche Art von Daten (gut oder schlecht komprimierbar) btape
> schreibt? Bzw. wie kann ich herausfinden, ob die
> Hardwarekompression der Laufwerke *wirklich* funktioniert?

Schreib' mit dd Nullen (bei großer Blocksize). Wenn Du dabei eine Schreibrate
von 40-50MB/s (am LTO3) erzielst, dann ist die Komprimierung aus. Mit
Komprimierung solltest Du an die Rate des SCSI-Controllers hin kommen.

Falls die Controller-Karte in Deiner Library schlau genug ist, Ethernet
anstöpseln und die diversen Logs der Library durchzuschauen schadet auch
nicht.

[Marcel Mueller]

On 06.09.16 22.04, Sebastian Suchanek wrote:
> Aktuell bin ich gerade dabei, eine LTO-Library an meinem Linux-
> Server in Betrieb zu nehmen. Konkret handelt es sich dabei um
> eine Overland NEO2000, die mit je einem LTO1- und einem LTO3-
> Laufwerk bestückt ist. Alle drei Geräte (die Library selbst und
> die beiden Laufwerke) hängen am selben externen Port eines
> Adaptec 29320ALP. Bei beiden Laufwerken ist nach Auskunft sowohl
> der Library als auch tapeinfo unter Linux die
> Hardwarekompression aktiv.

[...]

> Bei diesen Tests ist mir die eher maue Datenrate beim Schreiben
> aufgefallen: Das LTO1-Laufwerk kommt laut btape auf knapp
> 15,5MB/s, das LTO3-Laufwerk auf ca. 27,2MB/s.

Hmm, da würde ich auch mal suchen, was Sache ist. Mein IBM LTO3 (Dell
PowerVault T124) macht gut 70MB/s und auch das nur, weil ich meinen
einzigen U160-Controller mit zwei Bussen für etwas besseres brauche als
für den Server. Da ist nur U2W drin und das geht bei knapp 80MB/s in
Sättigung.

> Zur Erinnerung:
> Laut Spezifikation soll LTO1 20/40MB/s und LTO3 80/160MB/s
> schaffen (jeweils unkomprimiert/komprimiert).

Die komprimierten Werte sind Marketinggeblubber. Die angenommene
Kompressionsrate von 2:1 erreicht man selten bei großen Haus- und
Hofdaten, weil die meisten großen Dateien bereits komprimierte
Multimedia-Dateien sind. Lediglich VM-Images lassen sich ganz gut
eindampfen.
Aber mehr als 27MB/s sollten da schon kommen.

> Außerdem ist mir aufgefallen, dass beim Test des LTO1-Laufwerks
> nur um die 100MB geschrieben wurden - wobei ich nicht weiß, ob
> die Testdaten, die btape schreibt, gut oder schlecht
> komprimierbar sind.

Keinen Plan. Verwende ich nicht.

> (Der LTO3-Test läuft gerade noch.)
> Die CPU, ein Xeon E3-1225, langweilt sich bei diesen Tests
> übrigens mit ca. 10-15% Last für den btape-Thread.

Wenig überraschend - eher sogar viel, aber wäre zu klären bei welcher
Taktfrequenz.

> Soweit die Symptome.
> Was mich nun gerne wissen würde: Sind diese niedrigen Datenraten
> ansatzweise normal? Insbesondere beim LTO3-Laufwerk kann ich mir
> das nicht so recht vorstellen...

Nein, definitiv nicht.

> Falls nicht: Wo und wie kann ich am besten ansetzen, um den
> Flaschenhals zu ermitteln? (Und ihn anschließend beheben?)

Probiere erst mal ob die Software sich blöd anstellt.
Also Laufwerkskompression ausschalten (sollte mit mt-st gehen), dann per
dd von /dev/zero nach /dev/st? kopieren und die Statistik-Option
aktivieren bzw. das entsprechende Signal schicken (AFAIR SIGUSR). Nach 5
Minuten, hast Du das Ergebnis.

Wenn es da auch lahm ist, wäre im Dunstkreis Treiber/Hardware zu suchen,
andernfalls die Software.

Bei Hardware könnten auch matschige Bänder dafür verantwortlich
zeichnen, denn dann wird alles doppelt und dreifach geschrieben.
Ansonsten eventuell Probleme bei der SCSI-Verkabelung mit vielen Retries?

Bei Software sollte man checken, ob der Bursche evtl. von /dev/random
liest. Das rückt nicht so viele Bits raus, weil ihm sonst die Entropie
aus geht.

> Und zur geschriebenen Daten-Gesamtmenge: weiß jemand zufällig,
> welche Art von Daten (gut oder schlecht komprimierbar) btape
> schreibt? Bzw. wie kann ich herausfinden, ob die
> Hardwarekompression der Laufwerke *wirklich* funktioniert?

Die Angaben sind im allgemeinen verlässlich. Wenn Du signifikant mehr
als die Nennkapazität an Daten drauf bekommst, weißt Du dass es geht.

> PS: Da ich nicht weiß, ob es sich um ein Hardware- oder
> Software-Problem handelt, XP nach dchlm & dcoulm - f'up beim
> Antworten bitte passend setzen.

Wäre noch zu klären.


Marcel

[Sebastian Suchanek]

Am 07.09.2016 um 18:53 schrieb Marcel Mueller:
> On 06.09.16 22.04, Sebastian Suchanek wrote:

Erstmal Danke für Deine Antwort - auch an Dietz.

> [...]

>> Falls nicht: Wo und wie kann ich am besten ansetzen, um den
>> Flaschenhals zu ermitteln? (Und ihn anschließend beheben?)
>
> Probiere erst mal ob die Software sich blöd anstellt.
> Also Laufwerkskompression ausschalten (sollte mit mt-st gehen), dann per
> dd von /dev/zero nach /dev/st? kopieren und die Statistik-Option
> aktivieren bzw. das entsprechende Signal schicken (AFAIR SIGUSR). Nach 5
> Minuten, hast Du das Ergebnis.

> [...]

Das habe ich heute mal mit dem LTO3-Laufwerk versucht und bin mit dd
zumindest auf /etwas/ höhere Datenraten gekommen:

| # dd if=/dev/zero of=/dev/st1 bs=4M count=10000
| 10000+0 records in
| 10000+0 records out
| 41943040000 bytes (42 GB) copied, 1139.12 s, 36.8 MB/s
| #

Dabei bin ich allerdings auch auf ein anderes Problem gestoßen: Obwohl
tapeinfo für das Laufwerk "MaxBlock: 16777215" meldet, kann ich bei dd
keine Blockgrößen >4MB verwenden - diese führen zu unterschiedlichen
Fehlermeldungen:

| # dd if=/dev/zero of=/dev/st1 bs=5M count=10
| dd: error writing ‘/dev/st1’: Device or resource busy
| 1+0 records in
| 0+0 records out
| 0 bytes (0 B) copied, 10.6233 s, 0.0 kB/s
| #

bzw.:

| # dd if=/dev/zero of=/dev/st1 bs=16M count=10
| dd: error writing ‘/dev/st1’: Invalid argument
| 1+0 records in
| 0+0 records out
| 0 bytes (0 B) copied, 0.0275072 s, 0.0 kB/s
| #

Irgendwelche Ideen dazu?

> Bei Hardware könnten auch matschige Bänder dafür verantwortlich
> zeichnen, denn dann wird alles doppelt und dreifach geschrieben.
> Ansonsten eventuell Probleme bei der SCSI-Verkabelung mit vielen Retries?

> [...]

Neue Bänder eines anderen Herstellers sind im Zulauf, das kann ich erst
in gut einer Woche testen. Wie könnte ich am besten der SCSI-Verkabelung
auf den Zahn fühlen?


Tschüs,

Sebastian

[Marcel Mueller]

On 08.09.16 20.05, Sebastian Suchanek wrote:
> Das habe ich heute mal mit dem LTO3-Laufwerk versucht und bin mit dd
> zumindest auf /etwas/ höhere Datenraten gekommen:
>
> | # dd if=/dev/zero of=/dev/st1 bs=4M count=10000
> | 10000+0 records in
> | 10000+0 records out
> | 41943040000 bytes (42 GB) copied, 1139.12 s, 36.8 MB/s
> | #

Dolle ist das nicht.

> Dabei bin ich allerdings auch auf ein anderes Problem gestoßen: Obwohl
> tapeinfo für das Laufwerk "MaxBlock: 16777215" meldet, kann ich bei dd
> keine Blockgrößen >4MB verwenden - diese führen zu unterschiedlichen
> Fehlermeldungen:

Das kann schon sein. Die Laufwerke selber akzeptieren nicht beliebig
große Blöcke, weil sie sich ihren Pufferspeicher nicht mit einem Block
zuschießen wollen. Sonst würde das Band dauernd stehen bleiben, weil
keine Pipeline mehr möglich ist (SCSI-Transfer, Compression & forward
error correction etc., Write).

Ich verwende, einer Empfehlung folgend 2M.

Ich habe gerade nochmal das letzte Backup gecheckt. 421 GB in nahezu
exakt 2 Stunden, macht so knapp 60MB/s. Kompression war es aus, da
Videos. Da ist aber jetzt auch alles dabei, also auch die
Richtungswechsel beim Band und so und natürlich nur U2W. Bei einem
anderen Band waren es knapp 200 GB in 50 Minuten.

> Neue Bänder eines anderen Herstellers sind im Zulauf, das kann ich erst
> in gut einer Woche testen. Wie könnte ich am besten der SCSI-Verkabelung
> auf den Zahn fühlen?

Eigentlich sollte das in irgendeinem Log landen. Kann aber sein, dass
man dazu erst den Trace-Level der SCSI-Controller-Treibers hoch setzen muss.


Marcel

[Michael Bäuerle]

Marcel Mueller wrote:
> On 08.09.16 20.05, Sebastian Suchanek wrote:
> >

> > [...]

> > Neue Bänder eines anderen Herstellers sind im Zulauf, das kann ich erst
> > in gut einer Woche testen. Wie könnte ich am besten der SCSI-Verkabelung
> > auf den Zahn fühlen?
>
> Eigentlich sollte das in irgendeinem Log landen. Kann aber sein, dass
> man dazu erst den Trace-Level der SCSI-Controller-Treibers hoch setzen
> muss.

Mal nach "Domain validation" suchen. Neuere SCSI Hostadapter machen das
vor oder nach der Verhandlungsphase um zu sehen, ob die Fähigkeiten von
HA und Laufwerken auf dem Bus tatsächlich nutzbar sind.

[Marcel Mueller]

On 08.09.16 23.09, Michael Bäuerle wrote:
> Mal nach "Domain validation" suchen. Neuere SCSI Hostadapter machen das
> vor oder nach der Verhandlungsphase um zu sehen, ob die Fähigkeiten von
> HA und Laufwerken auf dem Bus tatsächlich nutzbar sind.

Gutes Stichwort!

Könnte es sein, dass irgendein Device, und sei es ein oller
SCSI-Terminator, den Bus auf Single Ended runter zieht? Dann wäre bei UW
mit 40 MB/s Schluss, was ganz gut zu den Symptomen passen könnte.

Jetzt sind wir aber wirklich bei der Hardware => f'up.


Marcel

[Michael Bäuerle]

Marcel Mueller wrote:
> On 08.09.16 23.09, Michael Bäuerle wrote:
> >
> > Mal nach "Domain validation" suchen. Neuere SCSI Hostadapter machen das
> > vor oder nach der Verhandlungsphase um zu sehen, ob die Fähigkeiten von
> > HA und Laufwerken auf dem Bus tatsächlich nutzbar sind.
>
> Gutes Stichwort!
>
> Könnte es sein, dass irgendein Device, und sei es ein oller
> SCSI-Terminator, den Bus auf Single Ended runter zieht? Dann wäre bei
> UW mit 40 MB/s Schluss, was ganz gut zu den Symptomen passen könnte.

Welchen Transfermodus sie ausgehandelt haben schreiben zumindest die
Adaptec-Treiber üblicherweise ins Logfile.

Früher konnte man auch aus dem "proc" FS Daten auslesen, ich weiß nicht
ob das in der neuen Welt noch funktioniert. Beispiel eines HP LTO-2 an
einem Adaptec AIC7890 mit Kernel 2.6:
|
| # cat /proc/scsi
| [...]
| Host: scsi2 Channel: 00 Id: 03 Lun: 00
| Vendor: HP Model: Ultrium 2-SCSI Rev: S63D
| Type: Sequential-Access ANSI SCSI revision: 03
| [...]
| # cat /proc/scsi/aic7xxx/2
| [...]
| Target 3 Negotiation Settings
| User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit)
| Goal: 80.000MB/s transfers (40.000MHz, offset 64, 16bit)
| Curr: 3.300MB/s transfers
| Channel A Target 3 Lun 0 Settings
| Commands Queued 429642318
| Commands Active 0
| Command Openings 1
| Max Tagged Openings 0
| Device Queue Frozen Count 0
| [...]

Dass es hier auf Async zurückgefallen ist liegt daran, dass das Netzteil
gestorben ist (Lüfter ausgefallen und danach die Elkos aufgeplatzt).
Zuerst gab es Schreibfehler, die das Laufwerk aber als "Medium error"
deklariert hat (deswegen bin ich nicht rechtzeitig hellhörig geworden).
Es gibt zwar eine LED "Fan/Power fail", aber die befindet sich leider
auf der Rückseite, wo ich nicht hinsehen kann wenn das Laufwerk im 19"
Schrank steht.
Ich werde jetzt neue Elkos bestellen und hoffe, das Laufwerk lebt noch.

[Sebastian Suchanek]

Am 09.09.2016 um 06:54 schrieb Marcel Mueller:
> On 08.09.16 23.09, Michael Bäuerle wrote:
>> Mal nach "Domain validation" suchen. Neuere SCSI Hostadapter machen das
>> vor oder nach der Verhandlungsphase um zu sehen, ob die Fähigkeiten von
>> HA und Laufwerken auf dem Bus tatsächlich nutzbar sind.
>
> Gutes Stichwort!
>
> Könnte es sein, dass irgendein Device, und sei es ein oller
> SCSI-Terminator, den Bus auf Single Ended runter zieht? Dann wäre bei UW
> mit 40 MB/s Schluss, was ganz gut zu den Symptomen passen könnte.

(Leider) Treffer, versenkt. :-\
Hier der Auszug aus /var/log/messages, als der Adaptec sich den Bus
zurechtsortiert hat (des Umfangs wegen als Link):

http://suchanek.de/temp/auszug_messages.txt (60kB)

Zum besseren Verständnis, die SCSI-IDs sind wie folgt vergeben:
- 10: LTO1-Laufwerk
- 11: Library-Controller
- 12: LTO3-Laufwerk

So wie ich das interpretiere, könnte das LTO3-Laufwerk eigentlich U160,
der Bus fällt aber auf 40MB/s zurück.
Was mir dabei aber noch nicht klar ist: Der Library-Controller kann,
soweit ich die Meldungen verstehe, sogar nur 20MB/s. Von daher hätte ich
erwartet, dass der SCSI-Bus bis auf 20MB/s zurückschaltet. Wie ergeben
sich dann die tatsächlich ausgehandelten - und anscheinend auch
verfügbar/möglichen - 40MB/s? Glücklicher Zufall oder kann ein
LVD-SCSI-Bus eigentlich schon unterschiedliche Geschwindigkeiten für
unterschiedliche Geräte fahren und die langsame Geschwindigkeit rührt
von einem anderen Problem her?

> Jetzt sind wir aber wirklich bei der Hardware => f'up.

ACK. :-)


Tschüs,

Sebastian

[Marcel Mueller]

On 09.09.16 19.06, Sebastian Suchanek wrote:
>> Könnte es sein, dass irgendein Device, und sei es ein oller
>> SCSI-Terminator, den Bus auf Single Ended runter zieht? Dann wäre bei UW
>> mit 40 MB/s Schluss, was ganz gut zu den Symptomen passen könnte.
>
> (Leider) Treffer, versenkt. :-\

> So wie ich das interpretiere, könnte das LTO3-Laufwerk eigentlich U160,
> der Bus fällt aber auf 40MB/s zurück.
> Was mir dabei aber noch nicht klar ist: Der Library-Controller kann,
> soweit ich die Meldungen verstehe, sogar nur 20MB/s. Von daher hätte ich
> erwartet, dass der SCSI-Bus bis auf 20MB/s zurückschaltet.

Nein, so tickt das nicht. SCSI steuert normalerweise jedes Gerät mit
seiner eigenen Geschwindigkeit an. Es gibt aber 3 kabeltechnisch
inkompatible Versionen. HDV, SE und LVD. HVD ist uralt und tot. Wenn man
HVD und das billigere SE verwechselt hat, ist üblicherweise etwas
gestorben. Bei LVD hat man sich schlauer angestellt. Wenn sie einen
Kurzschluss auf -TERMPWR entdecken, schalten sie automatisch auf SE
runter. Und das passiert genau in dem Moment, wo man eine nicht
LVD-kompatible Komponente an den Bus ansteckt. Da SE-Geräte die ganzen
positiv aktiven LVD-Datenleitungen kurzschließen ist ein koexistenter
Betrieb mit LVD nicht möglich.
Bei SE ist bei 40 MB/s Schluss, also bei 16 Bit alias wide, bei 8 Bit
die Hälfte. Das ist der einzige Fall, wo bei SCSI nicht alle am Bus
hängenden Devices mit für sie maximaler Taktfrequenz übertragen.

> Wie ergeben
> sich dann die tatsächlich ausgehandelten - und anscheinend auch
> verfügbar/möglichen - 40MB/s? Glücklicher Zufall oder kann ein
> LVD-SCSI-Bus eigentlich schon unterschiedliche Geschwindigkeiten für
> unterschiedliche Geräte fahren und die langsame Geschwindigkeit rührt
> von einem anderen Problem her?

Er schaltet auf SE zurück und gibt alles was SE kann.

Checke mal, ob auf allen Komponenten (auch Kabel und Terminatoren)
LVD/SE steht. Gerade bei Terminatoren wird gerne mal daneben gegriffen.


Marcel

[Sebastian Suchanek]

Am 09.09.2016 um 20:50 schrieb Marcel Mueller:

> [...]

> Checke mal, ob auf allen Komponenten (auch Kabel und Terminatoren)
> LVD/SE steht.

Kann ich leider erst in einer Woche machen, aber ich werde weiter berichten.

> Gerade bei Terminatoren wird gerne mal daneben gegriffen.

Zumindest bin ich mir sicher, dass der verwendete Terminator eine LED
hat, die im Betrieb leuchtet. Also wird es zumindest ein aktiver sein...


Tschüs,

Sebastian

[Goetz Hoffart]

Sebastian Suchanek <sebastian...@gmx.de> wrote:

> > Gerade bei Terminatoren wird gerne mal daneben gegriffen.
>
> Zumindest bin ich mir sicher, dass der verwendete Terminator eine LED
> hat, die im Betrieb leuchtet. Also wird es zumindest ein aktiver sein...

Das gibt es auch für 8-Bit SCSI mit 5 MB/s ... muss deswegen also kein
LVD sein.

Grüße
Götz
--
http://www.3rz.org

[Sebastian Suchanek]

Naja, SCSI-1 auf VHDCI-Steckern habe ich noch nicht gesehen. ;-)
Aber wie gesagt: Nächstes Wochenende beiße ich mal in den sauren Apfel
und werde ein paar Tauschversuche mit der Verkabelung machen.


Tschüs,

Sebastian

[Marcel Mueller]

On 09.09.16 23.04, Sebastian Suchanek wrote:
> Am 09.09.2016 um 22:42 schrieb Goetz Hoffart:
>> Sebastian Suchanek <sebastian...@gmx.de> wrote:
>>
>>> Zumindest bin ich mir sicher, dass der verwendete Terminator eine LED
>>> hat, die im Betrieb leuchtet. Also wird es zumindest ein aktiver sein...
>>
>> Das gibt es auch für 8-Bit SCSI mit 5 MB/s ... muss deswegen also kein
>> LVD sein.
>
> Naja, SCSI-1 auf VHDCI-Steckern habe ich noch nicht gesehen. ;-)

Und ich habe noch keinen LVD-Terminator mit LED gesehen.


Marcel

[Sebastian Suchanek]

Schau mal hier:

http://www.ebay.de/itm/191665865254

Ungefähr so sieht meiner übrigens auch aus. Ich kann kommendes
Wochenende auch gerne noch ein Foto nachreichen.


Tschüs,

Sebastian

[Marcel Mueller]

On 10.09.16 08.51, Sebastian Suchanek wrote:
>> Und ich habe noch keinen LVD-Terminator mit LED gesehen.
>
> Schau mal hier:
>
> http://www.ebay.de/itm/191665865254
>
> Ungefähr so sieht meiner übrigens auch aus. Ich kann kommendes
> Wochenende auch gerne noch ein Foto nachreichen.

Keine Panik, das glaube ich schon. Nur meine haben allesamt keine Laterne.


Marcel

[Michael Bäuerle]

Marcel Mueller wrote:
> On 10.09.16 08.51, Sebastian Suchanek wrote:

> > Marcel Mueller wrote:
> > >
> > > Und ich habe noch keinen LVD-Terminator mit LED gesehen.
> >
> > Schau mal hier:
> >
> > http://www.ebay.de/itm/191665865254
> >
> > Ungefähr so sieht meiner übrigens auch aus. Ich kann kommendes
> > Wochenende auch gerne noch ein Foto nachreichen.
>
> Keine Panik, das glaube ich schon. Nur meine haben allesamt keine Laterne.

Nehmt die LED nicht so wichtig. Normalerweise hängt die einfach nur an
Termpower (und zeigt an ob das anliegt). Sie hat sonst nichts mit dem
eigentlichen Terminator zu tun, sagt also nicht über dessen Aufbau und
dessen Fähigkeiten aus.

Was der Terminator kann, muss draufstehen. Für SE/HVD/LVD sollte es ein
entsprechendes Symbol geben.
Für den maximal nutzbaren Transfermodus steht übicherweise sowas wie
"U320" drauf, wenn der Terminator für 80MHz geeignet ist. Da einige
Transfermodi die gleichen Frequenzen verwenden, sind sie für den
Terminator vergleichbar anspruchsvoll.
Gängige synchrone Transfermodi:

Transfermodus Frequenz DT¹ Transferrate Datenrate (Wide16-Bus)
--------------------------------------------------------------------
Fast5 5 MHz 5 MT/s 10 MByte/s
Fast10 "Fast" 10 MHz 10 MT/s 20 MByte/s
Fast20 "Ultra" 20 MHz 20 MT/s 40 MByte/s
--------------------------------------------------------------------
Fast40 "Ultra2" 40 MHz 40 MT/s 80 MByte/s
Fast80 "U160" 40 MHz X 80 MT/s 160 MByte/s
Fast160 "U320" 80 MHz X 160 MT/s 320 MByte/s

Die Modi unterhalb der Linie in der Mitte sind nicht für SE-Busse
geeignet. Fast40 geht noch mit HVD, der Rest war für LVD gedacht.


__________________
¹) Dual Transition (Transfers auf beiden Taktflanken)

[Sebastian Suchanek]

Am 09.09.2016 um 10:29 schrieb Michael Bäuerle:

Diesen Teil f'uppe ich mal wieder zurück nach dcoulm...

> [SCSI unter Linux]

> Welchen Transfermodus sie ausgehandelt haben schreiben zumindest die
> Adaptec-Treiber üblicherweise ins Logfile.
>
> Früher konnte man auch aus dem "proc" FS Daten auslesen, ich weiß nicht
> ob das in der neuen Welt noch funktioniert. Beispiel eines HP LTO-2 an
> einem Adaptec AIC7890 mit Kernel 2.6:
> |
> | # cat /proc/scsi
> | [...]
> | Host: scsi2 Channel: 00 Id: 03 Lun: 00
> | Vendor: HP Model: Ultrium 2-SCSI Rev: S63D
> | Type: Sequential-Access ANSI SCSI revision: 03
> | [...]
> | # cat /proc/scsi/aic7xxx/2
> | [...]
> | Target 3 Negotiation Settings
> | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit)
> | Goal: 80.000MB/s transfers (40.000MHz, offset 64, 16bit)
> | Curr: 3.300MB/s transfers
> | Channel A Target 3 Lun 0 Settings
> | Commands Queued 429642318
> | Commands Active 0
> | Command Openings 1
> | Max Tagged Openings 0
> | Device Queue Frozen Count 0
> | [...]

> [...]

Hier[tm], das heißt Debian Jessie mit 4.6er Kernel aus den Backports,
gibt's das so leider nicht mehr:

| # cd /proc/s
| self/ sys/ sysvipc/
| # cd /proc/s

Gibt's auch unteren neueren Linuxen irgendwie die Möglichkeit,
/übersichtlich/ herauszufinden, was auf dem/den SCSI-Bus(sen) im System
so los ist? Die Informationen über die Initalisierungs-Meldungen in
/var/log/messages oder /var/log/kern.log zusammenzusuchen ist
einigermaßen mühselig und auch nicht besonders praktikabel, falls man
(Teil)-Informationen mal in Skripten bräuchte.
"hwinfo --scsi" gibt auch längst nicht alles aus: In meinem konkreten
Fall z.B. nur Informationen zu den beiden Bandlaufwerken, aber nicht zum
Library-Controller. Angaben zur Bus-Geschwindigkeit fehlen gänzlich.


Tschüs,

Sebastian

PS: XP dchlm & dcoulm, f'up2 dcoulm

[Michael Bäuerle]

Update:
Elkos gewechselt, Netzteil läuft wieder, Laufwerk hat überlebt.
Danach sah es wieder so aus:

|
| [...]
| Target 3 Negotiation Settings
| User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit)
| Goal: 80.000MB/s transfers (40.000MHz, offset 64, 16bit)

| Curr: 80.000MB/s transfers (40.000MHz, offset 64, 16bit)

| Channel A Target 3 Lun 0 Settings

| Commands Queued 432043053

| Commands Active 0
| Command Openings 1
| Max Tagged Openings 0
| Device Queue Frozen Count 0
| [...]

Aus dem Logfile:
|
| scsi2 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
| <Adaptec aic7890/91 Ultra2 SCSI adapter>
| aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs

|
| Vendor: HP Model: Ultrium 2-SCSI Rev: S63D
| Type: Sequential-Access ANSI SCSI revision: 03

| target2:0:3: Beginning Domain Validation
| target2:0:3: wide asynchronous
| target2:0:3: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 64)
| target2:0:3: Domain Validation skipping write tests
| target2:0:3: Ending Domain Validation

Hier hat die Domain Validation wohl nur auf !SE und Wide16 geprüft.

[Sebastian Suchanek]

Thus spoke Sebastian Suchanek:

> Am 09.09.2016 um 20:50 schrieb Marcel Mueller:
>
>> [...]
>> Checke mal, ob auf allen Komponenten (auch Kabel und
>> Terminatoren) LVD/SE steht.
>
> Kann ich leider erst in einer Woche machen, aber ich werde
> weiter berichten.

> [...]

JFTR:
Heute habe ich eine große Bastelaktion gestartet und den SCSI-
Bus in allen möglichen Varianten durchprobiert. Die Laufwerke
einzeln, mit und ohne Library-Controller, andere Reihenfolge,
anderes Kabel zwischen SCSI-Controller und den Testobjekten usw.

Ergebnis: Im Prinzip keine Veränderungen. Das LTO1-Laufwerk
fällt am Bus nach wie vor auf 66MB/s zurück, das LTO3-Laufwerk
teilweise bis auf 10MB/s(!).
Damit bleiben aus meiner Sicht folgende Fehlerquellen übrig:
- SCSI-Controller defekt
- Laufwerke defekt
(IMHO unwahrscheinlich, dass gleich zwei Streamer ähnliche
Macken haben.)
- Terminator defekt
(Ich hatte mir zwar einen neuen Terminator bestellt, aber der
ist leider noch nicht da. :-( )

Auf den Kabeln steht zu den tauglichen SCSI-Standards leider gar
nichts (zumindest habe ich nichts gefunden), auf dem Terminator
steht "U320".


Tschüs,

Sebastian

[Marcel Mueller]

On 17.09.16 19.13, Sebastian Suchanek wrote:
> Ergebnis: Im Prinzip keine Veränderungen. Das LTO1-Laufwerk
> fällt am Bus nach wie vor auf 66MB/s zurück, das LTO3-Laufwerk
> teilweise bis auf 10MB/s(!).
> Damit bleiben aus meiner Sicht folgende Fehlerquellen übrig:
> - SCSI-Controller defekt
> - Laufwerke defekt
> (IMHO unwahrscheinlich, dass gleich zwei Streamer ähnliche
> Macken haben.)
> - Terminator defekt
> (Ich hatte mir zwar einen neuen Terminator bestellt, aber der
> ist leider noch nicht da. :-( )

- Kabel defekt oder ungeeignet.

> Auf den Kabeln steht zu den tauglichen SCSI-Standards leider gar
> nichts (zumindest habe ich nichts gefunden),

Kein gutes Zeichen. Zufällig ein Rundkabel? Dann kannst Du es vmtl. in
die Tonne treten. Die Dinger machen eigentlich immer nur Probleme. Die
können nur gut aussehen.

> auf dem Terminator steht "U320".

Das passt ja.


Marcel

[Sebastian Suchanek]

Thus spoke Marcel Mueller:

> On 17.09.16 19.13, Sebastian Suchanek wrote:
>

>> [...]

>> Auf den Kabeln steht zu den tauglichen SCSI-Standards
>> leider gar nichts (zumindest habe ich nichts gefunden),
>
> Kein gutes Zeichen. Zufällig ein Rundkabel? Dann kannst Du
> es vmtl. in die Tonne treten. Die Dinger machen eigentlich
> immer nur Probleme. Die können nur gut aussehen.

> [...]

Ja, es sind alles Rundkabel - aber ich auch noch nie *externe*
Parallel-SCSI-Kabel als Flachbandkabel gesehen.
Für das 3,8-m-Kabel zwischen HA und erstem Gerät in der Library
habe ich gerade nochmal nachgesehen: Das ist beschriftet als
Compaq, Teilenummer "332616-002" bzw. "313374-002". Davon habe
ich zwei Exemplare, die ich beide ausprobiert habe. Die kurzen
Kabel (~20cm) zwischen den Geräten sind IIRC von Hewlett Packard
und Overland.


Tschüs,

Sebastian

[Michael Bäuerle]

Sebastian Suchanek wrote:
> Thus spoke Marcel Mueller:
> > On 17.09.16 19.13, Sebastian Suchanek wrote:
> > >
> > > [...]
> > > Auf den Kabeln steht zu den tauglichen SCSI-Standards
> > > leider gar nichts (zumindest habe ich nichts gefunden),
> >
> > Kein gutes Zeichen. Zufällig ein Rundkabel? Dann kannst Du
> > es vmtl. in die Tonne treten. Die Dinger machen eigentlich
> > immer nur Probleme. Die können nur gut aussehen.
> > [...]
>
> Ja, es sind alles Rundkabel - aber ich auch noch nie *externe*
> Parallel-SCSI-Kabel als Flachbandkabel gesehen.

Ja, extern sind nur Rundkabel üblich.

> Für das 3,8-m-Kabel zwischen HA und erstem Gerät in der Library
> habe ich gerade nochmal nachgesehen: Das ist beschriftet als
> Compaq, Teilenummer "332616-002" bzw. "313374-002". Davon habe
> ich zwei Exemplare, die ich beide ausprobiert habe. Die kurzen
> Kabel (~20cm) zwischen den Geräten sind IIRC von Hewlett Packard
> und Overland.

Für SE jenseits von 5 MHz wäre so ein Bus natürlich auch zu lang,
das kommt als Fallback daher nicht in Frage. Für LVD darf das aber kein
Problem darstellen, vielleicht taugt wirklich das 3.8m Kabel nichts.

Ich weiß nicht wie gut du an den HA und die Laufwerke rankommst:
Falls sich ein Laufwerk provisorisch so neben dem Host platzieren
lässt, dass man es mit einem internen Flachbandkabel verbinden kann,
dann wäre das eine gute und billige Option um zu testen, dass HA bzw.
Laufwerk nicht selbst eine Macke haben und es wirklich am Bus liegt.

[Sebastian Suchanek]

Thus spoke Michael Bäuerle:

> [...]

> Ich weiß nicht wie gut du an den HA und die Laufwerke
> rankommst: Falls sich ein Laufwerk provisorisch so neben
> dem Host platzieren lässt, dass man es mit einem internen
> Flachbandkabel verbinden kann, dann wäre das eine gute und
> billige Option um zu testen, dass HA bzw. Laufwerk nicht
> selbst eine Macke haben und es wirklich am Bus liegt.

Das scheidet leider de facto aus. Die Library ist eine
Overland NEO 2000 älteren Datums. Da sind die Laufwerke auf
Einschüben montiert, die Buchsen für die externe
SCSI-Verkabelung sitzen auf dem eigentlichen "Chassis" der
Library und werden von dort durch eine Steckverbindung an die
Laufwerke weitergeleitet. über diese interne proprietäre
Steckverbindung läuft auch die Stromversorgung und
wahrscheinlich auch irgendwelche Status-Leitungen zur
Kommunikation mit dem Library-Controller. So sieht das von
außen aus:

http://www.itinstock.com/ekmps/shops/itinstock/images/overland-storage-neo-series-2000-tape-library-2x-ultrium-lto3-10300073-002-[2]-39547-p.jpg

Und hier sieht man im Hintergrund ansatzweise den internen Verbinder:

http://www.ebay.de/itm/331803806389

IOW: Um die Laufwerke "direkt" zu testen, müsste ich sie aus
dem Einschubgehäuse herausfummeln und mir dann auch noch
Gedanken über eine (temporäre) Stromversorgung machen.

Bis kommendes Wochenende ist hoffentlich der zweite
Terminator da, mit dem teste ich dann nochmal. Falls das es
damit immer noch nicht funktioniert, werde ich mich wohl
besser nach gänzlich anderen Lösungen umschauen.


Tschüs,

Sebastian

[Marcel Mueller]

On 17.09.16 21.39, Sebastian Suchanek wrote:
> Ja, es sind alles Rundkabel - aber ich auch noch nie *externe*
> Parallel-SCSI-Kabel als Flachbandkabel gesehen.

Ja, dunkles Kapitel.
Sagen wir mal, je dicker, desto besser.


Ich würde einfach testhalber mal ein internes Kabel für die externe
Verbindung nehmen. Die passen auch auf die HD-Stecker.


Btw.: ich hoffe doch dass die SCSI-Terminierung auf beiden Seiten sauber
ist, und nicht etwa der Hostadapter zusätzlich zum Terminator an dem
inneren Kabel terminiert. Das würde die Symptome auch erklären.


Marcel

[Michael Bäuerle]

Marcel Mueller wrote:
>
> Ich würde einfach testhalber mal ein internes Kabel für die externe
> Verbindung nehmen. Die passen auch auf die HD-Stecker.

Sebastian hat aber doch VHDCI-Steckverbinder im Einsatz.

[Sebastian Suchanek]

Am 18.09.2016 um 18:22 schrieb Marcel Mueller:
> On 17.09.16 21.39, Sebastian Suchanek wrote:
>> Ja, es sind alles Rundkabel - aber ich auch noch nie *externe*
>> Parallel-SCSI-Kabel als Flachbandkabel gesehen.
>
> Ja, dunkles Kapitel.
> Sagen wir mal, je dicker, desto besser.

Müsste ich erst messen... ;-)

> Ich würde einfach testhalber mal ein internes Kabel für die externe
> Verbindung nehmen. Die passen auch auf die HD-Stecker.

Leider kommen bei meiner Hardware ausschließlich VHDCI-Buchsen vor.

> Btw.: ich hoffe doch dass die SCSI-Terminierung auf beiden Seiten sauber
> ist, und nicht etwa der Hostadapter zusätzlich zum Terminator an dem
> inneren Kabel terminiert. Das würde die Symptome auch erklären.

Es gibt in meinem Setup keine internen Kabel:


[SCSI-HA] Adaptec 29320LPE
|
| externes Kabel ~3,8m
|
[LTO3] LTO3-Laufwerk (IIRC HP)
|
| externes Kabel ~20cm
|
[LTO1] LTO1-Laufwerk (IIRC Seagate Viper 200)
|
| externes Kabel ~20cm
|
[Library] Controller der Library, Overland NEO 2000
|
[Terminator] externer Terminator, beschriftet mit "U320"


Der Adaptec steht zumindest im BIOS auf automatischer Terminierung, nach
dem Jumper zur "harten" Terminierung habe ich bei der letzten
Bastelaktion nicht geschaut.

Eine potentielle Fehlerquelle ist mir allerdings inzwischen noch
eingefallen: Wie ich in <nrm54e...@msgid.suchanek.de> beschrieben
hatte, sitzen die Laufwerke in separaten Einschüben, die ihrerseits
zusammen mit dem Chassis der Library kurze Kabel und eigene
Steckverbinder mitbringen. Da könnte natürlich auch noch ein Fehler
liegen. Ich werde am kommenden Wochenende wohl versuchsweise auch die
Laufwerkseinschübe mal gegeneinander tauschen...


Tschüs,

Sebastian

[Juergen P. Meier]

Sebastian Suchanek <sebastian...@gmx.de>:

> Es gibt in meinem Setup keine internen Kabel:
>

Hier gehoeren entweder Terminatoren auf den Internen Anschluss
gesteckt, oder evtl. vorhandene Terminatoren *auf der internen SEite*
des Adaptec's per Firmware aktiviert.

> [SCSI-HA] Adaptec 29320LPE
> |
> | externes Kabel ~3,8m
> |
> [LTO3] LTO3-Laufwerk (IIRC HP)

Hier darf nix terminiert werden, solange beide Kabel gleichen
SCSI-typs sind.
Evtl. vorhandene Interne Teminatoren sind auf jeden Fall zu
deaktivieren!
Welchen SCSI-Dialekt spricht das Laufwerk denn?

> |
> | externes Kabel ~20cm
> |
> [LTO1] LTO1-Laufwerk (IIRC Seagate Viper 200)

Das ist laut Internet *entweder ein UW-LVD *oder* ein UW-HVD Device.
Bei letzterem funktionert das natuerlich nicht mit LVD-Devices am
selben Bus (kann aber evtl. Fallback auf Fast Wide SCSI-2, 10 bzw. 20
MByte/s Transferrate).

> |
> | externes Kabel ~20cm
> |
> [Library] Controller der Library, Overland NEO 2000

Die Library selbst hat kein SCSI on Board. Das wird ueber
PCI-Einschubkarten nachgeruestet. Was ist denn bei dir eingebaut?

> |
> [Terminator] externer Terminator, beschriftet mit "U320"

Ultra-320 ist Wide (implizit). Der Teminator terminiert also alle 16
Datenleitungen und ist auf LVD ausgelegt.

Wenn an dem Bus ein HVD Device haengt, funktionert der ganze Schlodder
nicht.

> Der Adaptec steht zumindest im BIOS auf automatischer Terminierung, nach
> dem Jumper zur "harten" Terminierung habe ich bei der letzten
> Bastelaktion nicht geschaut.

Eventuell terminiert er damit die Externe Seite des Busses. Diese
billigen Controller waren AFAIK nie fuer den Betrieb nur mit Extern gedacht.

> Eine potentielle Fehlerquelle ist mir allerdings inzwischen noch
> eingefallen: Wie ich in <nrm54e...@msgid.suchanek.de> beschrieben
> hatte, sitzen die Laufwerke in separaten Einschüben, die ihrerseits
> zusammen mit dem Chassis der Library kurze Kabel und eigene
> Steckverbinder mitbringen. Da könnte natürlich auch noch ein Fehler
> liegen. Ich werde am kommenden Wochenende wohl versuchsweise auch die
> Laufwerkseinschübe mal gegeneinander tauschen...

Je nach dem wie die Libaray das intern macht, ob mit eigenem HBA der
zum Adaptec hin ein virtuelles SCSI-Device mit mehren LUNs hin
emuliert (ueblich), die Laufwerke innen aber selbst mit einem eigenen
SCSI-Bus anspricht, oder ob sie den Bus nur verlaengert, das muesstest
du aus dem Datenblatt/Manual der SCSI-Karte in der Library ablesen.

Und Pruefe auch ob du auf dem gesamten Strang durchgehend Wide-SCSI hast.
Man haengt NArrow-SCSI devices deswegen auch immer ans andere Ende vom
HBA, weil man beim ersten UEbergang von Wide auf NArrow schon den
Wide-Teil terminieren muss (und ab da kein Wide mehr hat).

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Juergen P. Meier]

Sebastian Suchanek <sebastian...@gmx.de>:

> Es gibt in meinem Setup keine internen Kabel:
>
>
> [SCSI-HA] Adaptec 29320LPE
> |
> | externes Kabel ~3,8m
> |
> [LTO3] LTO3-Laufwerk (IIRC HP)
> |
> | externes Kabel ~20cm
> |
> [LTO1] LTO1-Laufwerk (IIRC Seagate Viper 200)
> |
> | externes Kabel ~20cm
> |
> [Library] Controller der Library, Overland NEO 2000
> |
> [Terminator] externer Terminator, beschriftet mit "U320"

PS: Wie verhaelt es sich denn mit der Geschwindigkeit der ersten
beiden LTO-LAufwerke (gleichzeitig testen!) wenn du die Libarary ganz
absteckst und den Terminator direkt auf das LTO1 LAufwerk steckst?

[Sebastian Suchanek]

Am 19.09.2016 um 07:02 schrieb Juergen P. Meier:
> Sebastian Suchanek <sebastian...@gmx.de>:
>> Es gibt in meinem Setup keine internen Kabel:
>>
>
> Hier gehoeren entweder Terminatoren auf den Internen Anschluss
> gesteckt, oder evtl. vorhandene Terminatoren *auf der internen SEite*
> des Adaptec's per Firmware aktiviert.

Ich könnte schwören, dass das SCSI-BIOS am Wochenende nur die Optionen
"Automatic" und "Disabled" gezeigt hat, ein im WWW verfügbares
Handbuch[1] nennt aber auch "Enabled". (Plus den bereits erwähnten
Hardware-Jumper.) Aktuell steht die Karte sicher auf "Automatic" - ich
werde am kommenden Wochenende aber nochmal danach schauen.

>> [SCSI-HA] Adaptec 29320LPE
>> |
>> | externes Kabel ~3,8m
>> |
>> [LTO3] LTO3-Laufwerk (IIRC HP)
>
> Hier darf nix terminiert werden, solange beide Kabel gleichen
> SCSI-typs sind.
> Evtl. vorhandene Interne Teminatoren sind auf jeden Fall zu
> deaktivieren!

Sollten sie eigentlich sein. Ansonsten wüsste ich auch nicht, wie die
nachgeschalteten SCSI-Geräte noch nennenswerte Geschwindigkeiten
aushandeln könnten.

> Welchen SCSI-Dialekt spricht das Laufwerk denn?

U160.

>> |
>> | externes Kabel ~20cm
>> |
>> [LTO1] LTO1-Laufwerk (IIRC Seagate Viper 200)
>
> Das ist laut Internet *entweder ein UW-LVD *oder* ein UW-HVD Device.
> Bei letzterem funktionert das natuerlich nicht mit LVD-Devices am
> selben Bus (kann aber evtl. Fallback auf Fast Wide SCSI-2, 10 bzw. 20
> MByte/s Transferrate).

AFAIK funktionieren LVD- und HVD-Geräte am gleichzeitig am Bus überhaupt
nicht, bzw. könnten IIRC sogar zu Hardwareschäden führen.

>> |
>> | externes Kabel ~20cm
>> |
>> [Library] Controller der Library, Overland NEO 2000
>
> Die Library selbst hat kein SCSI on Board. Das wird ueber
> PCI-Einschubkarten nachgeruestet. Was ist denn bei dir eingebaut?

Diejenige Karte, die standardmäßig bei der Library dabei ist -
"108288-002" ist wohl die Teilenummer dazu. Die Doku von Overland hat
IMHO noch gewisse Verbesserungspotentiale... ;-)

> [...]

>> Der Adaptec steht zumindest im BIOS auf automatischer Terminierung, nach
>> dem Jumper zur "harten" Terminierung habe ich bei der letzten
>> Bastelaktion nicht geschaut.
>
> Eventuell terminiert er damit die Externe Seite des Busses. Diese
> billigen Controller waren AFAIK nie fuer den Betrieb nur mit Extern gedacht.

Das Handbuch[1] zeigt explizit eine Konfiguration mit ausschließlich
externen Geräten.

>> Eine potentielle Fehlerquelle ist mir allerdings inzwischen noch
>> eingefallen: Wie ich in <nrm54e...@msgid.suchanek.de> beschrieben
>> hatte, sitzen die Laufwerke in separaten Einschüben, die ihrerseits
>> zusammen mit dem Chassis der Library kurze Kabel und eigene
>> Steckverbinder mitbringen. Da könnte natürlich auch noch ein Fehler
>> liegen. Ich werde am kommenden Wochenende wohl versuchsweise auch die
>> Laufwerkseinschübe mal gegeneinander tauschen...
>
> Je nach dem wie die Libaray das intern macht, ob mit eigenem HBA der
> zum Adaptec hin ein virtuelles SCSI-Device mit mehren LUNs hin
> emuliert (ueblich), die Laufwerke innen aber selbst mit einem eigenen
> SCSI-Bus anspricht, oder ob sie den Bus nur verlaengert, das muesstest
> du aus dem Datenblatt/Manual der SCSI-Karte in der Library ablesen.

Der Library-Controller meldet sich als ein separates SCSI-Gerät ohne
LUNs am SCSI-Bus an. Die Laufwerke melden sich ebenfalls als
eigenständige Geräte an. Über das Userinterface der Library lassen sich
die Laufwerke allerdings bezüglich SCSI-ID usw. konfigurieren. Siehe
auch das Handbuch[2].

> Und Pruefe auch ob du auf dem gesamten Strang durchgehend Wide-SCSI hast.

> [...]

Laut /var/log/messages wird für jedes Gerät immer "Wide" ausgehandelt.


Tschüs,

Sebastian

_____
[1]
http://download.adaptec.com/pdfs/installation_guides/scsi_installation_and_user_guide_02_07.pdf
[2]
https://strobe.uwaterloo.ca/~twiki/pub/ISTCSS/BackupSystem/10400171-101.pdf

[Sebastian Suchanek]

Beide Laufwerke gleichzeitig ohne Library getestet habe ich nicht, wohl
aber jedes Laufwerk völlig alleine:

3,80m
[HA]---------[LTO1]-[Term]

bzw.

3,80m
[HA]---------[LTO3]-[Term]

Ergebnis: Das LTO3-Laufwerk fällt reproduzierbar von 160MB/s auf
inzwischen 10MB/s(!) zurück, das LTO1-Laufwerk von 80MB/s auf 66MB/s.

Je länger ich selbst darüber nachdenke, desto mehr spricht das IMO für
einen Fehler irgendwo im Laufwerkseinschub des LTO3-Laufwerks...


Tschüs,

Sebastian

[Sebastian Suchanek]

Sebastian Suchanek macht die Ingrid:

> [...]

Inzwischen ist der zweite Terminator eingetroffen, sodass ich
heute eine zweite Bastelaktion gestartet habe:
- Terminator getauscht -> keine Änderung
- Die beiden Laufwerkseinschübe gegeneinander getauscht -> keine
Änderung

Dann habe ich den Laufwerkseinschub mit dem LTO3-Laufwerk mal
aufgemacht: Von der proprietären Steckverbindung[1] geht nur ein
einzelnes kurzes Flachbandkabel als "Stich" zum eingebauten
Laufwerk. Das war etwas "wüst" ins Einschubgehäuse geknüllt -
ich habe es etwas anders verlegt und auch den gesteckten
"TermPower"-Jumper entfernt. Damit (und alles andere wieder in
der ursprünglichen Originalkonfiguration) fällt das Laufwerk
zumindest nur noch auf 40MB/s (statt wie zuletzt 10 oder gar 5
MB/s) zurück. Das ist zwar etwas besser, aber immer noch zu
langsam, um ein LTO3-Laufwerk selbst ohne Kompression
auszureizen.
Daraus schließe ich für mich, dass doch entweder das Laufwerk
selbst oder der Laufwerkseinschub nebst Verkabelung einen "Hau"
haben. Damit beende ich für mich dieses Experiment an dieser
Stelle und schaue mich nach Alternativen um.


Tschüs,

Sebastian

_____
[1] Das könnte BTW ein ERNI ERmet sein.