thank you for the response
I just applied the latest st patch from sun last week, so I have coverage up to
Gen 3
but I still see error messages
these are the error messages I am seeing
10/12/05 21:02:27 nsrd: media notice: Volume "000922" on device "rd=pcf-lgtosnux
:/dev/rmt/9cbn": Block size is 32768 bytes not 65536 bytes. Verify the device co
nfiguration. Tape positioning by record is disabled. This is from the networker
daemon log, the message is also seen in /var/adm/messages.
Oct 9 20:12:07 pcf-lgtoux scsi: [ID 107833 kern.notice] Requested Block:
0 Error Block: 0
Oct 9 20:12:07 pcf-lgtoux scsi: [ID 107833 kern.notice] Vendor: IBM
Serial Number:
Oct 9 20:12:07 pcf-lgtoux scsi: [ID 107833 kern.notice] Sense Key: Unit
Attention
Oct 9 20:12:07 pcf-lgtoux scsi: [ID 107833 kern.notice] ASC: 0x29 (power
on, reset, or bus reset occurred), ASCQ: 0x0, FRU: 0x30 This is from
/var/adm/messages
Oct 12 20:16:01 pcf-lgtoux scsi: [ID 107833 kern.warning] WARNING: /[EMAIL
PROTECTED],600000
/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 (st114):
Oct 12 20:16:01 pcf-lgtoux Error for Command: space Error
Level: Fatal.
Oct 12 20:16:01 pcf-lgtoux scsi: [ID 107833 kern.notice] Requested Block:
1 Error Block: 1
Oct 12 20:16:01 pcf-lgtoux scsi: [ID 107833 kern.notice] Vendor: IBM
Serial Number:
Oct 12 20:16:01 pcf-lgtoux scsi: [ID 107833 kern.notice] Sense Key: Media
Error
Oct 12 20:16:01 pcf-lgtoux scsi: [ID 107833 kern.notice] ASC: 0x14 (recor
ded entity not found), ASCQ: 0x0, FRU: 0x36
Oct 12 20:16:01 pcf-lgtoux root: [ID 702911 daemon.notice] NetWorker media: (war
ning) /dev/rmt/9cbn moving: fsf 34: I/O error This is from /var/adm/messages
The behavior I've noticed is that Legato sees an unexpected block size and
disables positioning by record, which causes it not to be able to read to an
EOF and append to a volume. Or at least that's what the support guy from
storage tek told me. Networker automatically sets LTO2 drives to 64KB blocks,
but it appears as though the OS is writing 32K blocks, and I don't know how to
adjust this or perhaps I don't fully understand how the relationship between
the OS, the tape drive, and the backup software functions. Here is what I
received from sun/storagetek about this:
"I suggest you comment out the device-specific entries in your st.conf and make
sure you have the latest st patch. These drives are supported natively and
Sun's recommendation is do allow that native support. I'm seeing a lot of I/O
errors on fsf operations on just about all of your drives, this could be caused
by several things, including media, st.conf settings, Networker settings and
even dirty drives.
We need to get the cleaning tapes into the SL8500 and get ACSLS set up to
handle the cleaning.
Just in case, here's how to determine what level your st patch is at and the
latest levels.
The command to get the info is below:
showrev -p | grep XXXXXX
(Note: XXXXXX is the 6-digit patch number that is being
searched for)
The patch number will depend on what level Solaris is :
* Solaris 2.6 105847
* Solaris 7 107460
* Solaris 8 108725
* Solaris 9 113324
I think that the fsf errors after the following occurs:
Volume "000386" on device "/dev/rmt/4cbn": Block size is 32768 bytes not 65536
bytes. Verify the device configuration. Tape positioning by record is disabled.
I've seen this caused in Netbackup by incorrect st.conf parameters, same block
sizes and very similar message. I'm sure the same thing would have similar
results in Networker. Once tape positioning by record is disabled fsf will
likely not work, as that is what fsf does....skip forward by the number of
records(files). I'm seeing this on most if not all drives."
Jeff Ekstrom
Solutions Engineer
SANZ, Inc.
Vienna, VA
(571) 643-8402 Cell
[EMAIL PROTECTED]
________________________________
From: [EMAIL PROTECTED] on behalf of Darren Dunham
Sent: Thu 10/13/2005 4:25 PM
To: [email protected]
Subject: Re: [Solaris-Users] st.conf entry question
> I am trying to configure IBM LTO2 drives to work with Solaris 5.9 and Emulex
> LP9802 HBAs.
>
> My backup software keeps marking tapes full prematurely, with as little as a
> few MB written to the tape. All of my research and support cases point to a
> misconfigured st.conf entry for LTO2.
What makes you say that? The st.conf does control some things, but
premature tape full indicationss or spurious errors are not something I
would expect.
Can you get the exact SCSI message that is returned to the application?
Is there anything in /var/adm/messages when it happens?
> Does anyone know how this should be configured?
First of all, with up-to-date patches, you shouldn't need to add any
configuration. The LTO2 type is already in the driver. You can confirm
that with 'strings'.
$ strings /kernel/drv/sparcv9/st | grep LTO
HP Ultrium LTO 2
HP Ultrium LTO
Seagate Ultrium LTO
IBM Ultrium Gen 2 LTO
IBM Ultrium Gen 2 LTO
IBM Ultrium LTO
IBM Ultrium LTO
If you don't have them, patch up.
> And just as importantly, can anyone explain what each field in the
> initiation strings stand for? Understanding what is going on will help
> me almost as much as knowing what specific entry I need.
It's specified in the 'st' man page. There's quite a bit of detail, so
I won't go into it here, but feel free to ask again if you have some
specific questions about it. Most of it is a bit string for various
options, then some vendor specific "density" settings.
--
Darren Dunham [EMAIL PROTECTED]
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
_______________________________________________
Solaris-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/solaris-users
_______________________________________________
Solaris-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/solaris-users
