blocking access to mounted scsi devices
A recent test of smartmontools on lk 2.6.0-test4 failed miserably on my main SCSI disk. It would seem that attempts to use either the:
SCSI_IOCTL_SEND_COMMAND
SG_IO
ioctls on a mounted SCSI "block" device fail with EBUSY. These ioctls work fine on devices that don't have mounted file systems on then. If this is a new policy then it needs to be reconsidered. smartmontools still works ok on ATA disks in lk 2.6.0-test4.
Both the ioctls in question still work via the corresponding scsi generic device. Will scsi generic devices make a re-appearance in sysfs (as indicated by Christoph when the relevant code in sg was removed)?
Doug Gilbert
Quoted 10 lines · Douglas Gilbert
A recent test of smartmontools on lk 2.6.0-test4 failed miserably on my main SCSI disk. It would seem that attempts to use either the:
SCSI_IOCTL_SEND_COMMAND
SG_IO
ioctls on a mounted SCSI "block" device fail with EBUSY. These ioctls work fine on devices that don't have mounted file systems on then. If this is a new policy then it needs to be reconsidered. smartmontools still works ok on ATA disks in lk 2.6.0-test4.
That's because both mount (or e.g. volume managers) claims devices for exclusive use, as does drivers/block/scsi_ioctl.c
Quoted 2 lines
Both the ioctls in question still work via the corresponding scsi generic device.
Well, we either want both to work or not work. The current situation is inconsistant.
Quoted 3 lines
Will scsi generic devices make a
re-appearance in sysfs (as indicated by Christoph when the relevant code in sg was removed)?
Yeah, I still need to come up with a way for class_interfaces like sg to have sysfs entries. the TODO list is growing but I'll take a look at this, promised.
Quoted 14 lines · Christoph Hellwig
Quoted 10 lines · Douglas Gilbert
A recent test of smartmontools on lk 2.6.0-test4 failed miserably on my main SCSI disk. It would seem that attempts to use either the:
SCSI_IOCTL_SEND_COMMAND
SG_IO
ioctls on a mounted SCSI "block" device fail with EBUSY. These ioctls work fine on devices that don't have mounted file systems on then. If this is a new policy then it needs to be reconsidered. smartmontools still works ok on ATA disks in lk 2.6.0-test4.
Quoted 2 lines
That's because both mount (or e.g. volume managers) claims devices for exclusive use, as does
drivers/block/scsi_ioctl.c
Well it is reasonable that mount should exclude other attempts to mount. However the device holding the root file system may be an ATA or SCSI disk and the ide-disk and sd drivers do not support SMART probing directly.
Tools like smartmontools periodically (or on demand) probe disks to find their SMART status. According to an IBM white paper a significant percentage of disk failures can be predicted by increased error rates and drive temperature. It doesn't seem practical to unmount the root file system (and any other mounted partitions) to allow such a probe then remount.
If this policy is to remain in lk 2.6 (for SCSI disks but not ATA disks yet) then perhaps the sd and sr drivers need to be changed to treat READ and WRITE commands differently from other commands. Other commands should not be subject block level policy.
Doug Gilbert
Quoted 8 lines · Douglas Gilbert
Quoted 2 lines · Christoph Hellwig
That's because both mount (or e.g. volume managers) claims devices for exclusive use, as does
drivers/block/scsi_ioctl.cWell it is reasonable that mount should exclude other attempts to mount. However the device holding the root file system may be an ATA or SCSI disk and the ide-disk and sd drivers do not support SMART probing directly.
Hang on, that's not the way it's supposed to work.
Mount should be on partition devices (like /dev/sda1) whereas the tools should be on whole disc devices (like /dev/sda). I thought we'd agreed that even opening a partition exclusively wouldn't affect the ability to open the whole disc device (but opening the whole disc device exclusively would block access to all partitions).
Therefore, the only issue we should have is with volume managers that need to open whole disc devices exclusively, and possibly with the device mapper.
James
Quoted 7 lines · James Bottomley
Hang on, that's not the way it's supposed to work.
Mount should be on partition devices (like
/dev/sda1) whereas the tools should be on whole disc devices (like/dev/sda). I thought we'd agreed that even opening a partition exclusively wouldn't affect the ability to open the whole disc device (but opening the whole disc device exclusively would block access to all partitions).
Linus accepted a patch from Neil Brown in -test4 that changes this.
Quoted 1 line · Christoph Hellwig
Linus accepted a patch from Neil Brown in -test4 that changes this.
OK, I'll see if I can do anything about this.
James
Quoted 10 lines · James Bottomley
Quoted 8 lines · Douglas Gilbert
Quoted 2 lines · Christoph Hellwig
That's because both mount (or e.g. volume managers) claims devices for exclusive use, as does
drivers/block/scsi_ioctl.cWell it is reasonable that mount should exclude other attempts to mount. However the device holding the root file system may be an ATA or SCSI disk and the ide-disk and sd drivers do not support SMART probing directly.
Quoted 7 lines
Hang on, that's not the way it's supposed to work.
Mount should be on partition devices (like
/dev/sda1) whereas the tools should be on whole disc devices (like/dev/sda). I thought we'd agreed that even opening a partition exclusively wouldn't affect the ability to open the whole disc device (but opening the whole disc device exclusively would block access to all partitions).
This sounds exactly right -- tools like smartmontools address the whole device, not a partition.
Cheers,
Bruce