[2.6.0-test4] blocking access to mounted scsi devices

[2.6.0-test4] blocking access to mounted scsi devices

[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.

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

Re: [2.6.0-test4] blocking access to mounted scsi devices

[Christoph Hellwig]

On Mon, Aug 25, 2003 at 05:04:53PM +1000, Douglas Gilbert wrote:
> 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

> 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.

> 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.

Re: [2.6.0-test4] blocking access to mounted scsi devices

[Douglas Gilbert]

Christoph Hellwig wrote:
> On Mon, Aug 25, 2003 at 05:04:53PM +1000, Douglas Gilbert wrote:
> 
>>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

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

Re: [2.6.0-test4] blocking access to mounted scsi devices

[James Bottomley]

On Tue, 2003-08-26 at 05:20, Douglas Gilbert wrote:
> Christoph Hellwig wrote:
> > 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.

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

Re: [2.6.0-test4] blocking access to mounted scsi devices

[Christoph Hellwig]

On Tue, Aug 26, 2003 at 09:08:54AM -0500, James Bottomley wrote:
> 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.

Re: [2.6.0-test4] blocking access to mounted scsi devices

[James Bottomley]

On Tue, 2003-08-26 at 09:32, Christoph Hellwig wrote:
> Linus accepted a patch from Neil Brown in -test4 that changes this.

OK, I'll see if I can do anything about this.

James

Re: [2.6.0-test4] blocking access to mounted scsi devices

[Bruce Allen]

On 26 Aug 2003, James Bottomley wrote:
> On Tue, 2003-08-26 at 05:20, Douglas Gilbert wrote:
> > Christoph Hellwig wrote:
> > > 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.
> 
> 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