Doubts on IO requests in USB subsystem

Doubts on IO requests in USB subsystem

[Morales, Alejandra]

Dear all,

For my master thesis I am developing a user space power management tool. For that purpose
I am implementing a kernel module and one task this module does is to intercept calls to the
request_fn function for every scsi device in order to check when they are actually being requested
an IO operation.

I am testing with a regular SATA hard drive and with an external USB hard drive. Both are just
mounted and there is no application using them at the moment, so that I was expecting that none
of them receive file system requests. Indeed the SATA HD does not receive any requests unless I
mount or unmount it, but the USB HD receives a large number of file system requests and it seems
that it never enters into an idle state. Since any application is using it I think these requests may
come from the USB subsystem. Am I right? If so, how could I determine whether a request comes
from the USB subsystem or it is a file system request that actually moves blocks?

Thanks in advance.
Regards,
Alejandra

Re: Doubts on IO requests in USB subsystem

[Oliver Neukum]

On Mon, 2013-09-09 at 08:20 +0000, Morales, Alejandra wrote:
> mounted and there is no application using them at the moment, so that
> I was expecting that none
> of them receive file system requests. Indeed the SATA HD does not
> receive any requests unless I
> mount or unmount it, but the USB HD receives a large number of file
> system requests and it seems
> that it never enters into an idle state. Since any application is
> using it I think these requests may
> come from the USB subsystem. Am I right? If so, how could I determine
> whether a request comes
> from the USB subsystem or it is a file system request that actually
> moves blocks?

Your prime suspect is the detection of medium change which was
moved into the kernel in 3.2 or so. It can be disabled by sysfs.
Generally the notion that a certain task originates a read or write
on a block device is iffy. Read-ahead and shared data structures
make it impossible to accurately tell.

USB storage devices are notorious for setting the removable bit
even if they have no removable medium.

	Regards
		Oliver

RE: Doubts on IO requests in USB subsystem

[Morales, Alejandra]

2013/9/9 Oliver Neukum <oliver@neukum.org>
>
> Your prime suspect is the detection of medium change which was
> moved into the kernel in 3.2 or so. It can be disabled by sysfs.
> Generally the notion that a certain task originates a read or write
> on a block device is iffy. Read-ahead and shared data structures
> make it impossible to accurately tell.
>
> USB storage devices are notorious for setting the removable bit
> even if they have no removable medium.
>

Thanks for the answer Oliver. Unfortunately it doesn't seem to be the
medium change detection what is causing these requests, since the
removable bit is disabled and the polling period is set to -1:

morales@nonzerodesk:~$ udevadm info --query all --path /sys/block/sdc/ --attribute-walk

looking at device '/devices/pci0000:00/0000:00:1a.7/usb1/1-3/1-3:1.0/host11/target11:0:0/11:0:0:0/block/sdc':
    KERNEL=="sdc"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{range}=="16"
    ATTR{ext_range}=="256"
    ATTR{removable}=="0"
    ATTR{ro}=="0"
    ATTR{size}=="1953525168"
    ATTR{alignment_offset}=="0"
    ATTR{discard_alignment}=="0"
    ATTR{capability}=="50"
    ATTR{stat}=="   12805     1970   102691    23528   747334     2557  5999128  3340096        0  1963084  3362880"
    ATTR{inflight}=="       0        0"
    ATTR{events}==""
    ATTR{events_async}==""
    ATTR{events_poll_msecs}=="-1"


Regards
- Alejandra

Re: Doubts on IO requests in USB subsystem

[Oliver Neukum]

On Mon, 2013-09-16 at 10:33 +0000, Morales, Alejandra wrote:
> 2013/9/9 Oliver Neukum <oliver@neukum.org>
> >
> > Your prime suspect is the detection of medium change which was
> > moved into the kernel in 3.2 or so. It can be disabled by sysfs.
> > Generally the notion that a certain task originates a read or write
> > on a block device is iffy. Read-ahead and shared data structures
> > make it impossible to accurately tell.
> >
> > USB storage devices are notorious for setting the removable bit
> > even if they have no removable medium.
> >
> 
> Thanks for the answer Oliver. Unfortunately it doesn't seem to be the
> medium change detection what is causing these requests, since the
> removable bit is disabled and the polling period is set to -1:

Interesting. Then you have no choice. Make a usbmon trace and look
at the SCSI commands going to the device.

	HTH
		Oliver

RE: Doubts on IO requests in USB subsystem

[Morales, Alejandra]

2013/9/16 Oliver Neukum <oliver@neukum.org>
> On Mon, 2013-09-16 at 10:33 +0000, Morales, Alejandra wrote:
> > 2013/9/9 Oliver Neukum <oliver@neukum.org>
> > >
> > > Your prime suspect is the detection of medium change which was
> > > moved into the kernel in 3.2 or so. It can be disabled by sysfs.
> > > Generally the notion that a certain task originates a read or write
> > > on a block device is iffy. Read-ahead and shared data structures
> > > make it impossible to accurately tell.
> > >
> > > USB storage devices are notorious for setting the removable bit
> > > even if they have no removable medium.
> > >
> >
> > Thanks for the answer Oliver. Unfortunately it doesn't seem to be the
> > medium change detection what is causing these requests, since the
> > removable bit is disabled and the polling period is set to -1:

> Interesting. Then you have no choice. Make a usbmon trace and look
> at the SCSI commands going to the device.

I made the usbmon and I could see a lot of scsi write commands, but no
clue about where they were coming from.

I did some testing on different computers and Linux distributions and
it turned out that those requests were issued only on a desktop running
Ubuntu. I followed this example:

http://ubuntuforums.org/showthread.php?t=833301

and I could figure out that the requests were coming from a daemon
called spindownd. After stopping it, they disappeared.

Thanks for you help, Oliver.

Regards,
Alejandra