🚀 go-pugleaf

lehners@uniol.UUCP (Joerg Lehners) writes:

->Moin !

->Wo's mir 'mal grad wieder auffaellt:
->Ein 'kleiner' Bug in der Streamer-Software.

->Wenn man einen nicht zureuckgespulten Streamer einlegt, und waehrend
->des Zurueckspulens auf den Streamer zugreift, dann gibts KuddelMuddel.
->Einfaches Bespiel:
->nicht zurueckgespulten Streamer einlegen,
->waehrend des Zurueckspulens eintippen:
->< /dev/ris0     # eigentlich sollte hier bis zum Ende des Zurueckspulen
->		# gewartet werden, tut's aber nicht.
->< /dev/ris0     # erst beim zweiten mal wird auf das Zureckspulen
->		# gewartet.

das wundert mich, denn Streamer einlegen und "</dev/ris0" tippen ist
fuer mich automatisch; spaetestens wenn mein Prompt wieder da ist,
weiss ich, dass der Streamer zurueckgespult ist (was Du ja wohl auch
bezwecken willst).

->Wenn man waehrend des Zurueckspulens auf den Streamer schreibt, dann
->ist mit ziemlichen Datenverlust zu rechnen.
->Wenn man waehrend des Zurueckspulens vom Streamer liest bekommt man
->nur Unsinn.

Ich muss zugeben, dass ich sowas noch nie probiert habe (welchen Sinn
soll das denn haben ?-), aber ich kann es ja mal ausprobieren!

->Unsere Kisten laufen unter Munix V.3-3.1.
->Ist der Fehler bekannt, und eventuell in V.3-3.2 behoben ?

erster Teil: bisher nicht, wir machen das allgemein so (s.o.)
zweiter Teil: muss ich mal probieren.

Ich melde mich wieder

Gruss
--
Mike Schroeder		PCS-Mail: msc
DOMAIN:  msc@cochise.pcs.de (EUR) or  msc@cochise.pcs.com  (US)
BANG:    ..unido!pcsbst!msc (EUR) or  ..pyramid!pcsbst!msc (US)

In article <2334@uniol.UUCP> lehners@uniol.UUCP (Joerg Lehners) writes:
()nicht zurueckgespulten Streamer einlegen,
()waehrend des Zurueckspulens eintippen:
()< /dev/ris0     # eigentlich sollte hier bis zum Ende des Zurueckspulen
()		  # gewartet werden, tut's aber nicht.

Komisch. Ich habe auch V.3-3.1 und bei mir blockiert </dev/ris0,
bis der Streamer zurueckgespult ist (CTS2a mit icckernel 6.0). Das
gilt auch fuer andere Kommandos wie isctrl -i und isctrl -S etc.

>Wenn man waehrend des Zurueckspulens auf den Streamer schreibt, dann
>ist mit ziemlichen Datenverlust zu rechnen.

Schon fast jokeverdaechtig, der Spruch!
Uebrigens:  Wenn man waehrend des Schreibens auf den Streamer zurueckspult,
dann ist auch mit ziemlichen Datenverlust zu rechnen. ;-)

-- 
Stefan Stapelberg, <stefan@systemware.de>
Endlich: Schalck-Golodkowski zwangsvereinigt mit Schabowski! -- Kowalski

Moin !

stefan@shiva.systemware.de (Stefan Stapelberg) writes:
>In article <2334@uniol.UUCP> lehners@uniol.UUCP (Joerg Lehners) writes:
>()[...]
>Komisch. Ich habe auch V.3-3.1 und bei mir blockiert </dev/ris0,
>bis der Streamer zurueckgespult ist (CTS2a mit icckernel 6.0). Das
>gilt auch fuer andere Kommandos wie isctrl -i und isctrl -S etc.

Icckernel 6.0 haben wir auch hier laufen, aber das Laufwerk ist ein
CTS1. Ist's moeglicherweise ein Hardware-Problem ?

>>Wenn man waehrend des Zurueckspulens auf den Streamer schreibt, dann
>>ist mit ziemlichen Datenverlust zu rechnen.
>Schon fast jokeverdaechtig, der Spruch!
>Uebrigens:  Wenn man waehrend des Schreibens auf den Streamer zurueckspult,
>dann ist auch mit ziemlichen Datenverlust zu rechnen. ;-)

Joke hin, Joke her .. das Problem ist jedenfalls, das ein Backup,
das man *vor* Ende des Rueckspulens anfaengt (wenn der Streamer just
firsch eingelegt ist) den Bach 'runter geht. Ab und an kloetern bei uns
die Rechner so sehr, dass man eben nicht hoert, ob der Streamer zuende
gespult hat oder nicht.

  Bis denn
	Joerg
--
/ UUCP:    lehners@uniol              | Joerg Lehners                  \
|       ...!uunet!unido!uniol!lehners | Fachbereich 10 Informatik ARBI |
| BITNET:  066065 AT DOLUNI1          | Universitaet Oldenburg         |
\ Inhouse: aragorn!joerg              | D-2900 Oldenburg               /

Moin !

mike@cochise.pcs.com (Mike Schroeder) writes:
>lehners@uniol.UUCP (Joerg Lehners) writes:
>->Wo's mir 'mal grad wieder auffaellt:
>->Ein 'kleiner' Bug in der Streamer-Software.
>->[...]
>das wundert mich, denn Streamer einlegen und "</dev/ris0" tippen ist
>fuer mich automatisch; spaetestens wenn mein Prompt wieder da ist,
>weiss ich, dass der Streamer zurueckgespult ist (was Du ja wohl auch
>bezwecken willst).

Eben dies macht der Streamer bei uns nicht. Alle betroffenen Kisten sind
32 Bitter mit dem CTS1(a) Laufwerk und Munix V.3-3.1.
Das 'Warten auf Zurueckspulen' wird eben erst beim zweiten Kommando
der Art gemacht.
Wie Stefan Stabelberg ja schon geschrieben hat, scheint der Fehler
nicht mit dem CTS2(a) Laufwerk aufzutreten.

>->Wenn man waehrend des Zurueckspulens auf den Streamer schreibt, dann
>->ist mit ziemlichen Datenverlust zu rechnen.
>->Wenn man waehrend des Zurueckspulens vom Streamer liest bekommt man
>->nur Unsinn.
>Ich muss zugeben, dass ich sowas noch nie probiert habe (welchen Sinn
>soll das denn haben ?-), aber ich kann es ja mal ausprobieren!

Ganz einfach: ein alltaeglicher Vorgang:
Streamer in die Luke und Luke schliessen;
sofort wird danach 'find blafasel -print | cpio -ovS > /dev/nris0'
eingegeben.
Weil der Streamer aber meist nach dem Einlegen noch am Rueckspulen
oder positionieren ist, gibt's nur Muell auf dem Band.

Ich hab's just grad noch 'mal ausprobiert: das Kommando oben macht
zwar den *Eindruck* als wuerde es auf den Streamer warten (bis der
zurueckgespult ist) und schreibt erst dann auf das Tape. Tatsaechlich
ist aber der erste Block (60 BK bei der 'S' Option) futsch.
Je nach Groesse der Dateien printet das cpio Kommando ein paar
Dateinamen aus und wartet dann, wenn der Streamer fertig ist, gehts
weiter.

>->Unsere Kisten laufen unter Munix V.3-3.1.
>->Ist der Fehler bekannt, und eventuell in V.3-3.2 behoben ?
>erster Teil: bisher nicht, wir machen das allgemein so (s.o.)
>zweiter Teil: muss ich mal probieren.
>Ich melde mich wieder

Es waer echt nett, wenn dieses 'Odditity' bald der Vergangenheit angehoert.
Ich hab' mir zwar bisher erst einmal dadurch ein paar Dateien zerschossen,
aber es kann schnell wieder vorkommen, wenn man zu schnell ist ...

  Bis denn
	Joerg
--
/ UUCP:    lehners@uniol              | Joerg Lehners                  \
|       ...!uunet!unido!uniol!lehners | Fachbereich 10 Informatik ARBI |
| BITNET:  066065 AT DOLUNI1          | Universitaet Oldenburg         |
\ Inhouse: aragorn!joerg              | D-2900 Oldenburg               /

lehners@uniol.UUCP (Joerg Lehners) writes:

->Moin !

->stefan@shiva.systemware.de (Stefan Stapelberg) writes:
->>In article <2334@uniol.UUCP> lehners@uniol.UUCP (Joerg Lehners) writes:
->>()[...]
->>Komisch. Ich habe auch V.3-3.1 und bei mir blockiert </dev/ris0,
->>bis der Streamer zurueckgespult ist (CTS2a mit icckernel 6.0). Das
->>gilt auch fuer andere Kommandos wie isctrl -i und isctrl -S etc.

->Icckernel 6.0 haben wir auch hier laufen, aber das Laufwerk ist ein
->CTS1. Ist's moeglicherweise ein Hardware-Problem ?

glaub ich nicht (ausser Euer Streamer ist defekt), denn (siehe meinen
ersten Artikel hierzu) bei uns tritt das Problem auch nicht auf (d.h.
es verhaelt sich genau wie bei Stefan) und wir haben CTS1, CTS1a und
CTS2 (und demnaechst wohl CTS3). Tritt das bei Euch auf
einem/mehreren/allen Streamern auf??

Aber wieso eigentlich icckernel 6.0?? Leute, mittlerweile gibt's (seit
5 Monaten oder so) V.3.2 mit icckernel 7.2! Und vielen anderen feinen
Sachen (Bezerkeley FFS, NFS, _echte_ sockets, bsd Kompatibilitaet usw.).

->>>Wenn man waehrend des Zurueckspulens auf den Streamer schreibt, dann
->>>ist mit ziemlichen Datenverlust zu rechnen.
->>Schon fast jokeverdaechtig, der Spruch!
->>Uebrigens:  Wenn man waehrend des Schreibens auf den Streamer zurueckspult,
->>dann ist auch mit ziemlichen Datenverlust zu rechnen. ;-)

->Joke hin, Joke her .. das Problem ist jedenfalls, das ein Backup,
->das man *vor* Ende des Rueckspulens anfaengt (wenn der Streamer just
->firsch eingelegt ist) den Bach 'runter geht. Ab und an kloetern bei uns
->die Rechner so sehr, dass man eben nicht hoert, ob der Streamer zuende
->gespult hat oder nicht.

tja, aber nur wenn (was ich wie gesagt noch nie erlebt habe) der
entsprechende cpio oder tar oder was-weiss-ich nicht blockt, bis der
Streamer fertig ist! Und das haben wir hier wirklich noch nicht
reproduzieren koennen.

->  Bis denn

Servus
--
Mike Schroeder		PCS-Mail: msc
DOMAIN:  msc@cochise.pcs.de (EUR) or  msc@cochise.pcs.com  (US)
BANG:    ..unido!pcsbst!msc (EUR) or  ..pyramid!pcsbst!msc (US)
-- 
Mike Schroeder		PCS-Mail: msc
DOMAIN:  msc@cochise.pcs.de (EUR) or  msc@cochise.pcs.com  (US)
BANG:    ..unido!pcsbst!msc (EUR) or  ..pyramid!pcsbst!msc (US)