I have a SATA mobile tray and a new 750GB SATA drive that I will be using for full system backups. The idea is that weekly I manually insert the drive, run a script to perform my full backup, and then remove and safely store the drive "off site." Conceptually I have already tested the idea but unfortunately, I have to manually configure everything.

This past weekend I recompiled my kernel to include CONFIG_SCSI_MULTI_LUN=y. According to other threads in this forum I needed to do that to avoid using /etc/rc.d/rc.scanluns. Yet I have had no success in seeing my drive get automatically recognized by the kernel. I realize I must manually mount to a mount point, but the drive is not automatically recognized as happens when I insert a USB stick.

If I run rc.scanluns (or rescan-scsi-bus), the drive is then recognized. Yes, my backup script could perform the same thing, but I thought the kernel was supposed to recognize the new device automatically. Please correct me if I'm wrong. If I am correct, then what else must I do to get the kernel to automatically assign a device name?

Second, I have no idea how to enforce device name assignments. From what little I've read so far, I think the correct term is persistent naming? I realize udev is old stuff to many of you, but until I bought my new box recently, I never had reason to use udev with my old boxes that did not support hot plugging. So right now udev is terribly foreign to me. I would like the device name sdb to always be reserved for my SATA drive, which is not always connected. I would like USB devices to get assigned device names to sdc or higher. Is this possible? If not, how in my backup script do I programmatically determine the device name my SATA drive is assigned?

Third, I am using gkrellm to monitor my hardware. Even after I manually rescan the SCSI bus to find my SATA drive, I must manually restart hddtemp, smartctl, and gkrellm to recognize the drive. I would think this would be automatic too. How do I configure those applets and daemons to auto-recognize the new drive?

Is any of this possible or am I stuck writing a quick script to rescan the bus, and restart the daemons?

Thanks again.

USB/Firewire naturally supports hot swapping but it does not work the same for SATA. The SATA controller must support hot swapping (not all do) and support must be compiled into the kernel. AFAIK you will have to manually tell the OS you are disconnecting/reconnecting the device to the system in addition to mounting/unmounting.

If you use UUID or filesystem labels for the fstab entries then the actual device ID i.e. /dev/sdx does not matter.

Okay, that makes sense based upon my observations. My motherboard is an Asus M2NPV-VM with an Nvidia nForce 430/MPC51 controller. Any idea whether this chip supports true hot swapping?

I have the following kernel options set:
CONFIG_SATA_AHCI=y
CONFIG_SATA_NV=y

Perhaps the noauto option might suffice too.

As mentioned in my original post, I'm using a SATA hard drive for external backups, connected through a SATA hard drive bay.

Based upon what michaelk wrote above, I wrote a script to manually scan the SCSI bus (rescan-scsi-bus -l), which adds the device to the SCSI list. The script then mounts the drive and performs the backup. All well and good.

However, after manually unmounting the device, I am not figuring out how to inform the kernel that I have powered down (through a key switch on the drive bay) and removed the drive. Performing rescan-scsi-bus -r does not remove the device from the list and lsscsi confirms the device is still listed on the bus. I don't want to perform rescan-scsi-bus --forceremove because I have an internal SATA drive that I don't want removed or unmounted.

Searching the web has left me empty, but I could simply not be using the correct key words.

What is the correct (programmatic) way to remove the drive from the SCSI bus?

I'm not looking for a way to update /proc/scsi/scsi per se --- I'm looking for a way that will automate that updating. Basically why does rescan-scsi-bus -r fail?

Thanks again.

I might have solved the problem, or at least found a few more pieces of the puzzle. I finally noticed when running the rescan-scsi-bus script with the -r option I received an error message at line 262. This line is in a subroutine named getluns. That line makes a call to /usr/bin/sg_luns. No such command was on my box.

A quick check of the web revealed that the sg3_utils package was available at slacky.eu. I downloaded, compiled, and installed the package. No more error messages.

However, I'm uncertain of the correct syntax when using the -r option. Seems I have to pass the full SCSI address (host, channel, ID, lun), which first requires manually listing all the devices. I could programmatically extract those four elements from the lsscsi command if I correctly identify the device. I think if only one device is on a particular host that I need only pass that first element. I'm still trying to learn more.

If I do not pass parameters with the -r option, then my internal SATA drive is removed from the scsi list too. Not good --- so some restrictive parameters seem to be necessary to remove only one device.

Perhaps this makes sense, but my thinking was that I could power down the device and then run rescan-scsi-bus to update my scsi list. However a "mere" rescan does not remove devices from the list. I also presumed that the -r option was programmatically intelligent to notice the device is gone and remove from the list. Apparently this is not so as I need to be more explicit when using the -r option. Someone correct me if I'm off on a tangent and missing the big picture! I would be happy to learn the problem is a syntax misunderstanding by me.

This all seems far to manual and clunky, but then again, SATA does not operate the same as USB and DVDs/CDs. From an electronics perspective SATA is hot pluggable, but that seems about all that is accomplished with the Linux kernel. A script would automate the disconnection process, of course.

I'm wondering whether PV knows that the rescan-scsi-bus script cannot remove devices because the sg3_utils package is not included in the stock Slackware. The rescan-scsi-bus script is included in the a/sysvinit-scripts package, but that is all.

I appreciate any further thoughts.