Once upon a time, Bill Perry wlperry@williamperry.com said:

Then I decided to upgrade. I swapped out the motherboard and got a 64 bit cpu and upgraded the OS (complete new install). I now have Fedora 15 running on the box.

IIRC the "st" module may not be loaded automatically on newer systems. Try a "lsmod | grep st" and "modprobe st" (if it isn't listed). If that fixes it, there are several ways to get the module loaded (try that and post back the results).

It almost looks like the device changed from /dev/st4 to /dev/st0. Is that possible?

Yeah, I don't know why it would ever have been st4; the SCSI tape devices have always been numbered starting with 0 in my experience (I think I first used a SCSI tape device on Linux in 1996).

An alternate way to always access a specific tape drive by a fixed path is via /dev/tape/by-id.

On Fri, 2011-10-14 at 14:24 -0700, Bill Perry wrote:

Thank-you.

It appears that the st module is loaded. #lsmod |grep st

<stuff> st 32080 0

Next, I tried the command write to the tape as /dev/st0. I put a writeable tape in the drive. I have a couple of files in /root called yum_list...

tar cvf /dev/st0 /root/yum* tar: /dev/st0: Cannot open: Input/output error tar: Error is not recoverable: exiting now

The /dev/tape/by-id/... is a link pointing to /dev/st0 tar cvf /dev/tape/by-id/scsi-1HP_C7438_xxxxx /root/yum* tar: /dev/tape/by-id/scsi-1HP_C7438A_xxxxx: Cannot open: Input/output error tar: Error is not recoverable: exiting now

Running rescan-scsi-bus.sh does not help.

Running mt -f /dev/st0 offline does not do anything. mt -f /dev/st0 status SCSI 2 tape drive: File number=-1, block number=-1, partition=0. Tape block size 0 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (10000): IM_REP_EN

The tape drive still appears in lsscsi

---- st refers to an automatic tape drive and nst refers to a manually controlled drive and most backup software prefers the usage of nst as it wants to get control over the drive and tape positioning anyway.

You might want to try...

mt -f /dev/nst0 rewind mt -f /dev/nst0 status

Craig

On Friday, October 14, 2011 09:59:38 PM Rick Stevens wrote:

On 10/14/2011 11:51 AM, Chris Adams wrote:

...

Once upon a time, Bill Perry wlperry@williamperry.com said:

...

It almost looks like the device changed from /dev/st4 to /dev/st0. Is that possible?

Yeah, I don't know why it would ever have been st4; the SCSI tape devices have always been numbered starting with 0 in my experience (I think I first used a SCSI tape device on Linux in 1996).

Back in the day, the SCSI controller was assigned ID 7 and typically tape drives were given ID 4. Hard drives were usually 0, 1, 2, and 3. IDs 5 and 6 were left for the user. Don't ask me why...I suppose they figured no one would ever need more than four hard drives. Then again, Gates said we'd never need more than 640K of RAM.

That actually has quite a logical explanation. Assuming a narrow scsi bus, you have 8 data lines. If the bus is idle and a device wants to send data, it simply puts a signal on the line that corresponds to its ID. Then the device will wait for a short period of time and then the one with the highest ID will be allowed to procede. That's why the HBA is ID 7 - it always wins if there are other devices that try to send at the same time. The tape device carried a high penalty for running out of data to write: You had to stop the tape, rewind, start again, find the exact spot and then continue writing. So you'd give it a high ID. The actual ID wasn't always 4 though. HP DAT drives shipped set to ID 3, quantum and its OEMs shipped ID6, so did storagetek LTO drives.

Older Linux kernels carried along the SCSI ID as the device name, hence the naming of /dev/st4 on older systems.

How old do we talk here? I started using Linux when the version number still had a beautiful 0 at the beginning :-) Seriously though - st4 because of scsi id 4 makes little sense - what if you have two HBAs? For the fun of it I pulled the 1.0 kernel source and even there the kernel enumerates sg devices, then assigns the st device when an sg is of the appropriate type. st4 can only happen if you have 5 devices that identify themselves as tape or you accidentally set the tape device to the same id as the controller.

Newer kernels typically query the device as to what it is and start assigning hard drives starting at /dev/sda, tapes at /dev/st0 and CD/DVD drives at /dev/cdrom0 (the "/dev/sd<letter>" bit because drives can be partitioned).

BTW, as an aside, Sun always assigned their first hard drive to ID 1. I guess because IBM was stupid enough to assign their first floppy to ID 1 instead of 0 on the IBM PC (aka IBM 5150) and put that bloody twist in the floppy cable to hide that rather obvious cockup.

SS10 or 20? :) coming from an IPC where the drive was ID3, that took me a day to figure out...

BTW, I was on one of the first ANSI SCSI committees (the conversion from SASI to SCSI) and was a design engineer for (gasp! is he really that old?) Micropolis in the mid 70s.

Don't feel bad - nobody here is getting any younger :)

Peter.

On 14Oct2011 23:31, Chris Adams cmadams@hiwaay.net wrote: | > Older Linux kernels carried along the SCSI ID as the device name, | | No, Linux always assigned SCSI devices in order from the start (e.g. | sda, sg0, sr0, st0). Assigning with the ID was always something | controversial, because on one hand, it would have given fixed device | names (when that was desired for the more "enterprise-level" SCSI, when | IDE always used hda for primary master, hdb for primary slave, etc.), | while on the other, there weren't enough device major/minor numbers (and | that assignment style never handled multiple buses or HBAs) to actually | do that. | | Other OSes did it different, but not Linux, and certainly not any Fedora | version (as the OP said). I'm pretty sure the only way Fedora would | have had st4 without st[0-3] would have been if there was a udev rule to | rename it.

Yes, and this has _long_ been a major annoyance to me. Add a drive? Other drives get renamed! Add a bus (eg new PCI SCSI card)? Other drives get renamed!

I've got a machine at home whose / drive gets renamed depending on whether the PCI SCSI RAID stuff is broken or not. Hmm, shall root be on sdb or sdc today? Maddening when trying to rescue.

I'm all ok with providing sda/hda as discovered, _provided_ one also has nice bus/id type names as well. Solaris' bus/id/partition drive names looked long and complicated but they were reliable - you could look at the device ids and know what the OS would call them.

Cheers,

Once upon a time, Cameron Simpson cs@zip.com.au said:

I'm all ok with providing sda/hda as discovered, _provided_ one also has nice bus/id type names as well. Solaris' bus/id/partition drive names looked long and complicated but they were reliable - you could look at the device ids and know what the OS would call them.

See /dev/disk/by-{id,path,uuid}. This is also an advantage of LVM; it knows how to find the physical volumes, and you generally don't have to care (/dev/vg_foo is always /dev/vg_foo). Even Solaris' bus number wasn't stable in the face of card changes IIRC.

The problem with enumerating devices by HBA/bus/ID/LUN is that today's storage is more dynamic. USB ports are "SCSI" (protocol); how do you number those? IIRC USB ports on a hub are not deterministically ordered, so a flash card reader on a hub may come before a thumb drive on one boot and after on the next.

On 16Oct2011 18:09, Joe Zeff joe@zeff.us wrote: | On 10/16/2011 05:47 PM, Cameron Simpson wrote: | > I've got a machine at home whose / drive gets renamed depending on | > whether the PCI SCSI RAID stuff is broken or not. Hmm, shall root be on | > sdb or sdc today? Maddening when trying to rescue. | | Make sure that every partition has a label and use them in fstab. (If | the partition's already mounted by UUID, add a comment to the file | giving the label.) Then, when rescuing, you can unmount your drives and | remount them by using mount -a to get them where you want them.

Which is no good for the root= kernel command line option. And the root=LABEL= syntax is apparently a nonstandard kernel patch.

I mount stuff in /etc/fstab with labels - more readable; I tak your point about using a UUID and a label in the comment.

When I say "rescue", here I'm not meaning "boot off a CDROM and fsck etc my OS". I mean "my system doesn't boot because it can't find the root partition". It is "hunt the /dev/sdX" device, with many minutes of delay between retries. More annoying that my words can describe.

Cheers,

On Sun, 2011-10-16 at 20:15 -0500, Chris Adams wrote:

The problem with enumerating devices by HBA/bus/ID/LUN is that today's storage is more dynamic. USB ports are "SCSI" (protocol); how do you number those? IIRC USB ports on a hub are not deterministically ordered, so a flash card reader on a hub may come before a thumb drive on one boot and after on the next.

I would have gone down the route of calling USB devices with a usb device name. So a USB device doesn't become sda and shuffle device names around for *other* devices.

And I would have left IDE style devices as hd, SCSI as sd, SATA as sa, and so on, and so forth...

That way when I have a computer with an internal IDE drive, an external USB, and an external SATA, I could tell them instantly apart from each other as they would be /dev/hda, /dev/usb1, /dev/sa1. Rather than /dev/sda, /dev/sdb, and /dev/sdc, where I could guess that the internal drive was *probably* /dev/sda, but could never guess what either of the other two were.