there are a number of possibilities we have 2 HBAs that connect to Brocade switches, which form 2 seperate fabrics with a san at our remote site via a DWDM link
so 1 HBA per fabric, which goes to a brocade, then over dwdm, with a brocade on the other side each HBA is zoned in with 9 lto2 drives each zone has only one initiator we are using an sl8500 silo, and acsls to control the silo all the drives show up, but I'm not sure if that many drives per hba is supported so perhaps I should extend this discussion to storage area network discussions with other users -----Original Message----- From: [EMAIL PROTECTED] on behalf of Darren Dunham Sent: Thu 10/13/2005 5:29 PM To: [email protected] Subject: Re: [Solaris-Users] st.conf entry question > 10/12/05 21:02:27 nsrd: media notice: Volume "000922" on device = > "rd=3Dpcf-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. Okay, now that *is* often caused by a bad st.conf, but it's not usually responsible for premature 'full' tapes. It just means that recovery will be a bit slower. I think you'll continue to see that when you do recoveries on tapes written with the "wrong" st.conf. As they expire and you reuse them, the errors should go away. > 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 That's completely separate. That suggests that you have some issues with the drive itself. Are these direct scsi or are you using some sort of fiber bridge? Can other devices be causing a reset? Is the bridge acting up (I've seen that before)... > 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: > =20 > "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. I think you may have two separate issues here. I agree with those recommendations. Go for the unadorned, patched st.conf. Check other things associated with the drives (cleaning, cables, fiber, bridges, other host connections, etc...). -- 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
