Re: SYNCHRONIZE CACHE command from sd on close

[Douglas Gilbert <dgilbert@interlog.com>]

Christoph Hellwig wrote:
> On Fri, Feb 19, 2010 at 01:20:25AM +0100, Douglas Gilbert wrote:
>> So send a START_STOP_UNIT(stop) through the SG_IO
>> ioctl on a sd device opened RW and as a bonus get
>> three INQUIRYs (one standard, two VPD pages) and 5 READ
>> commands!
>>
>> If the device is SCSI (as the scsi_debug driver is
>> simulating) then those READs fail because the drive
>> is stopped. However if that is an ATA disk behind a
>> SAT layer, then the disk will be spun up. That defeats
>> the purpose of the pass-though, especially when it
>> is being used to spin down the disk.
>>
>> My guess, reviewing the bug reports flowing into me is
>> that this nonsense started around lk 2.6.29 .
> 
> We should never send INQUIRY or READ commands from the kernel
> in response to opening a device.  But the combination sounds
> like something udev might be doing for it's stable device
> indentifier and manual partition scan because I don't trust
> the kernel thing.  Can you check if these commands come from
> udev or one of the realted tools (hal, device-kit-blah, udisks
> whatever it is called today)

Adding some sleep()s to sg_start it seems that all nasty
stuff gets sent to the device synchronized with the close()
of the /dev/sd* file descriptor (not the open() ).

The sg_start sequence is:
    a)  fd = open("/dev/sdb", O_RDWR | O_NOBLOCK)
    b)  ioctl(fd, SG_IO, <START_STOP_UNIT(stop) command>)
    c)  close(fd)

a) sends no SCSI commands to the device
b) sends the START_STOP_UNIT(stop) only
c) sends 3 INQUIRYs and 5 READs !?