Messages in this thread | | | Date | Sun, 29 Aug 1999 17:22:51 +0200 (CEST) | From | Daniel Kobras <> | Subject | Re: Re: scsi-idle (fwd) |
| |
On Sat, 28 Aug 1999, paulr wrote:
> Here are 2 files, scsi-idle-225.patch.gz --- and --- > scsi-idle-2.1.62.tgz > > The first patch file is against 2.2.5, and (in essence) > adds extra ioctls for scsi disk drive motor control.
The ioctls are in essence the unimportant part of the patch. The SCSI_IOCTL_START_STOP is unneeded since 2.1.100, where SCSI_IOCTL_{START,STOP}_UNIT have been added. (Actually, they are defined right above of where you yanked in the START_STOP ioctl.) The SD_IOCTL_IDLE is deprecated because you can easily work around it in userspace[*]. For IDE disks this is already done by polling /proc/stat.
The only really important part of the patch are the changes to rw_intr(): Unlike IDE, current implementation of SCSI disks takes it as a fatal error if a mounted disk is spun down. It's basically
Kernel: "How do you do?" Disk: "NOT_READY." Kernel: "Oh really? But, how do you do?" Disk: "NOT_READY." and so on...
which the patch changes into
Kernel: "How do you do?" Disk: "NOT_READY." Kernel: "Well, try to spin up then. How do you feel now?"
However, looking at the locking hassles the spinup code in sd_init_onedisk() must endure, I get a feeling that the patch isn't waterproof on SMP, maybe neither on UP. It's on my list of "things to look at", but being busy... Anyway, unlike the ioctls the spinup logic seems to me like a valueable addition that should make it into the kernel. Then it would be possible to extend the logic that's used in bdflush-1.6.2 for IDE disks to SCSI as well.
Daniel.
[*] That's not entirely true. Due to limitations in the accounting used in /proc/stat, currently you lose with either more than 4 disks or a mixed setup of IDE and SCSI disks. I have a working solution for that, yet still have to write a sensible user space application. The difference being that it's a generic approach, not one limited to SCSI.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |