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-
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
2013/9/9 Oliver Neukum <[email protected]>
>
> 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-
On Mon, 2013-09-16 at 10:33 +0000, Morales, Alejandra wrote:
> 2013/9/9 Oliver Neukum <[email protected]>
> >
> > 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