[Sysadmins] стример записывает не на полную емкость ленты

[Sysadmins] стример записывает не на полную емкость ленты

[Oleg]

Доброго времени суток!

Стример на LTO2 начал записывать не на полную емкость. То есть если 
раньше стабильно писал ~190Гб, теперь начал писать на 150-160 Гигов.  До 
этого все работало отлично на протяжении где-то года. Это началось со 
сбоя scsi во время бекапа, после  чего стример завис. Перегрузка помогла.
Все тесты бакулы проходит. Записывал\восстанавливал бекап -  все 
отлично. Лампочка очистки не горит, да и времени пока мало прошло.
Гугл не помог.
Подскажите, пожалуйста, куда копать.


стример - HP Ultrium 448
контроллер - Adaptec 29160 Ultra160 SCSI adapter
материнка - Supermicro    Product Name: PDSM4+

сервер - altlinux 4.0
bacula 2.4.3

cat  /proc/scsi/aic7xxx/4
Adaptec AIC7xxx driver version: 7.0
Adaptec 29160 Ultra160 SCSI adapter
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
Allocated SCBs: 4, SG List Length: 128

В логах:
/var/log/messages
st 4:0:3:0: Attempting to queue an ABORT message
/var/log/kernel/warnings
kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
kernel: scsi4: Dumping Card State while idle, at SEQADDR 0x9
kernel: Card was paused
kernel: ACCUM = 0x4, SINDEX = 0x37, DINDEX = 0x24, ARG_2 = 0x0
kernel: HCNT = 0x0 SCBPTR = 0x0
kernel: SCSIPHASE[0x0] SCSISIGI[0x0] ERROR[0x0] SCSIBUSL[0x0]
kernel: LASTPHASE[0x1] SCSISEQ[0x12] SBLKCTL[0xa] SCSIRATE[0x0]
kernel: SEQCTL[0x10] SEQ_FLAGS[0xc0] SSTAT0[0x0] SSTAT1[0x8]
kernel: SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x8] SIMODE1[0xa4]
kernel: SXFRCTL0[0x80] DFCNTRL[0x0] DFSTATUS[0x89]
kernel: STACK: 0xe2 0xe2 0x179 0x3
kernel: SCB count = 4
kernel: Kernel NEXTQSCB = 3
kernel: Card NEXTQSCB = 3
kernel: QINFIFO entries:
kernel:  Waiting Queue entries:
kernel: Disconnected Queue entries: 0:2
kernel: QOUTFIFO entries:
kernel: Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
kernel: Sequencer SCB Info:
kernel:   0 SCB_CONTROL[0x44] SCB_SCSIID[0x37] SCB_LUN[0x1] SCB_TAG[0x2]
kernel:   1 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:   2 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:   3 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:   4 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:   5 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:   6 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:   7 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:   8 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:   9 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  10 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  11 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  12 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  13 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  14 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  15 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  16 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  17 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  18 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  19 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  20 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  21 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  22 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  23 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  24 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  25 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  26 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  27 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  28 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  29 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  30 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel:  31 SCB_CONTROL[0x0] SCB_SCSIID[0xff] SCB_LUN[0xff] SCB_TAG[0xff]
kernel: Pending list:
kernel:   2 SCB_CONTROL[0x40] SCB_SCSIID[0x37] SCB_LUN[0x1]
kernel: Kernel Free SCB list: 1 0
kernel: Untagged Q(3): 2
kernel:
kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>

Re: [Sysadmins] стример записывает не на полную емкость ленты

[Michael Shigorin]

On Wed, Apr 07, 2010 at 03:54:30PM +0400, Oleg wrote:
> Стример на LTO2 начал записывать не на полную емкость. То есть
> если раньше стабильно писал ~190Гб, теперь начал писать на
> 150-160 Гигов.  До этого все работало отлично на протяжении
> где-то года. Это началось со сбоя scsi во время бекапа, после
> чего стример завис. Перегрузка помогла.  Все тесты бакулы
> проходит. Записывал/восстанавливал бекап -  все отлично.
> Лампочка очистки не горит, да и времени пока мало прошло.
> Гугл не помог.  Подскажите, пожалуйста, куда копать.

Это на разных кассетах воспроизводится?  Могла пострадать
одна и сбоить на том участке, который писался.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] стример записывает не на полную емкость ленты

[Oleg]

On 04/08/2010 12:58 AM, Michael Shigorin wrote:
> On Wed, Apr 07, 2010 at 03:54:30PM +0400, Oleg wrote:
>    
>> Стример на LTO2 начал записывать не на полную емкость. То есть
>> если раньше стабильно писал ~190Гб, теперь начал писать на
>> 150-160 Гигов.  До этого все работало отлично на протяжении
>> где-то года. Это началось со сбоя scsi во время бекапа, после
>> чего стример завис. Перегрузка помогла.  Все тесты бакулы
>> проходит. Записывал/восстанавливал бекап -  все отлично.
>> Лампочка очистки не горит, да и времени пока мало прошло.
>> Гугл не помог.  Подскажите, пожалуйста, куда копать.
>>      
> Это на разных кассетах воспроизводится?  Могла пострадать
> одна и сбоить на том участке, который писался.
>
>    
На разных. В прошлом году была точно такая же ситуация. Стример начал 
писать все меньше и меньше. Ни чистка, ничего не помогло. Кончилось тем, 
что стример зажевал кассету, повредился внутри и мы обменяли его по 
гарантии. Работает, бэкапит, восстанавливает - все на отлично. Почему 
меньше - ни малейшей идеи. Механика? Но не 2 стримерах подряд же?! Если 
бы так, в инете нашлись бы еще "счастливчики", верней, это был бы 
известный всем баг. Кассеты тоже HP.