Brak Dostępu Do Streamer-a Po Wykonaniu Backup-u

[phm]

Serwer: DELL PowerEdge (model 430SC),

System: Red Hat Enterprise Linux ES,

 

Opis problemu: Archiwizuję pewne pliki z wykorzystaniem streamer-a na taśmy za pomocą poleceń (skrypt):

1) # mt -f /dev/st0 status

2) # tar cvf /dev/nst0 / {ścieżka dostępu}

3) # mt -f /dev/st0 rewoffl

 

Wszystko wygląda dobrze, słychać, że pliki są przegrywane na taśmę, po czym taśma zostaje wysunięta. Problem polega na tym. nie można wykonać takiej operacji ponownie, także na inną taśmę, ani za kilka godzin ani za kilka dni. Po restarcie serwera znów jest wszystko dobrze i można wykonać (ale tylko raz) backup.

Proszę o pomoc. Ostrzegam, że jestem laikiem, jeśli chodzi o (_linuxa_ → Linuksa) ORT, więc proszę o wyrozumiałość i "łopatologiczne" porady krok po kroku co mogę sprawdzić, zrobić.

[Arabski]

Dziwne... Mam streamer i takiej hecy jeszcze nie widziałem. Jaki interfejs?

 

Próbowałeś zamienić

 

2) # tar cvf /dev/nst0 / {ścieżka dostępu}

 

/dev/nst0 na /dev/st0?

[phm]

Dziwne... Mam streamer i takiej hecy jeszcze nie widziałem. Jaki interfejs?

 

Próbowałeś zamienić

 

2) # tar cvf /dev/nst0 / {ścieżka dostępu}

 

/dev/nst0 na /dev/st0?

 

Dzięki za odzew!

Dostęp do tego komputera będę miał dopiero w poniedziałek, to sprawdzę, ale wcześniej będę musiał oczywiście zrestartować komputer.

Gdybym teraz bez restartu wydał polecenie np:

1) # mt -f /dev/st0 status

to otrzymałbym komunikat:

"no such device or address"

albo podobny (cytuję z pamięci)

Nie zdejmowałem obudowy, bo jest jeszcze na gwarancji, więc nie wiem, jaki interfejs - nie wiem jak sprawdzić w systemie.

[Arabski]

Aaa to urządzenie wewnętrzne... Może być SCSI, ale może być też USB. Choć nie wiem, czy robi się taki sztuki, jak wewnętrzne podłączenie przez USB.

 

nie wiem jak sprawdzić w systemie.

 

Np. tak:

 

bartek@dream32:~$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: SEAGATE  Model: ST336754LC       Rev: D403
  Type:   Direct-Access                    ANSI  SCSI revision: 03
Host: scsi0 Channel: 00 Id: 04 Lun: 00
  Vendor: COMPAQ   Model: AD009335C9       Rev: A017
  Type:   Direct-Access                    ANSI  SCSI revision: 02
Host: scsi0 Channel: 00 Id: 05 Lun: 00
  Vendor: IBM      Model: DNES-309170W     Rev: SA50
  Type:   Direct-Access                    ANSI  SCSI revision: 03
Host: scsi0 Channel: 00 Id: 06 Lun: 00
  Vendor: HP       Model: 9.10GB A 68-SA40 Rev: SA40
  Type:   Direct-Access                    ANSI  SCSI revision: 02

 

[phm]

Aaa to urządzenie wewnętrzne... Może być SCSI, ale może być też USB. Choć nie wiem, czy robi się taki sztuki, jak wewnętrzne podłączenie przez USB.

 

 

 

Np. tak:

 

bartek@dream32:~$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: SEAGATE  Model: ST336754LC       Rev: D403
  Type:   Direct-Access                    ANSI  SCSI revision: 03
Host: scsi0 Channel: 00 Id: 04 Lun: 00
  Vendor: COMPAQ   Model: AD009335C9       Rev: A017
  Type:   Direct-Access                    ANSI  SCSI revision: 02
Host: scsi0 Channel: 00 Id: 05 Lun: 00
  Vendor: IBM      Model: DNES-309170W     Rev: SA50
  Type:   Direct-Access                    ANSI  SCSI revision: 03
Host: scsi0 Channel: 00 Id: 06 Lun: 00
  Vendor: HP       Model: 9.10GB A 68-SA40 Rev: SA40
  Type:   Direct-Access                    ANSI  SCSI revision: 02

Więc pewnie będzie SCSI, ale to dopiero w poniedziałek będę mógł sprawdzić...

 

[phm]

Aaa to urządzenie wewnętrzne... Może być SCSI, ale może być też USB. Choć nie wiem, czy robi się taki sztuki, jak wewnętrzne podłączenie przez USB.

Sprawdziłem - to SCSI.

Nie mogę zmienić w:

2) # tar cvf /dev/nst0 / {ścieżka dostępu}

/dev/nst0 na /dev/st0

ponieważ o ile wiem, to zastosowanie st0 powoduje przewinięcie taśmy na początek, a w moim skrypcie kopiowane są pliki z 3 różnych lokalizacji (3 razy występuje polecenie # tar cvf /dev/nst0 /{ścieżka dostępu})

[@WalDo]

ponieważ o ile wiem, to zastosowanie st0 powoduje przewinięcie taśmy na początek

Dokładnie tak. Pliki /dev/st0 i /dev/nst0 wskazują fizycznie na to samo urządzenie i tylko ich obsługa jest nieco inna ("n" jak "no rewind").

Założę się, że polecenie ls -l /dev/*st0 pokaże ten sam major number (nie wiem jak to się na polski tłumaczy) w obu przypadkach.

 

[phm]

cat /proc/scsi/scsi

wynik(taki sam przed i po wykonaniu backup-u):

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
 Vendor: ATA      Model: Maxtor 6L080M0   Rev: BACE
 Type:   Direct-Access                    ANSI SCSI revision: 05
Host: scsi0 Channel: 00 Id: 01 Lun: 00
 Vendor: ATA      Model: Maxtor 6L080M0   Rev: BACE
 Type:   Direct-Access                    ANSI SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
 Vendor: Seagate  Model: STT3401A         Rev: 310C
 Type:   Sequential-Access                ANSI SCSI revision: 02

 

[Arabski]

To może jeszcze inaczej:

 

3) # mt -f /dev/st0 rewoffl

 

Spróbuj wywalić tą linijkę. i ręcznie wysunąć taśmę. Weź następną i zobacz czy to cokolwiek zmienia w kwestii dostępności steamera.

 

Nie zdejmowałem obudowy, bo jest jeszcze na gwarancji

 

Jeżeli gwarancja obejmuje komputer + system to bym się ani chwili nie zastanawiał. Nie działa jak powinno i już.

 

p.s.

 

Pliki /dev/st0 i /dev/nst0 wskazują fizycznie na to samo urządzenie i tylko ich obsługa jest nieco inna

 

Wszystko się zgadza, ale przy tak małym polu manewru co innego można poradzić? Tylko kombinacje z tym co jest.

[phm]

Problem rozwiązany.

Po wielu różnych testach i próbach okazało się, że streamer nie może pracować wspólnie z napędem CD na jednej taśmie. Powodowało to przerwanie nagrywania danych na taśmę streamera po pewnym dłuższym czasie. Po odłączeniu napędu CD wykonuje się kopia do końca, nic nie przerywa.