generic_make_request fucntion for scsi_disk

generic_make_request fucntion for scsi_disk

[Ravish Tayal]

Hello,

I am debugging Filesystem code for USB mass storage devices.  I need
help to figure out after generic_make_request how the request is
placed to scsi disk (sd) requeset queue and than how sd qeueuecommand
to usb_storeage thread.  (in which context, is it system call context)


inside generic_make_request

1.   q = bdev_get_queue(bio->bi_bdev);  [is sd.c register queue this
queue or any other scsi file?]
2.     ret = q->make_request_fn(q, bio);  [which file contain this
make_request_fn for scsi disk driver (generic)]

As per my unsderanding flow is like
Fat_writepage ->_block_write_full_page --> blkdev_writepage-->
block_write_full_page-->submit_bh-->generic_make_request ???  (sd ??)
----> queuecommand

Please suggest any sorce file, link or document.

with thanks
Ravish

Re: generic_make_request fucntion for scsi_disk

[James Bottomley]

On Sat, 2009-06-20 at 19:35 +0530, Ravish Tayal wrote:
> I am debugging Filesystem code for USB mass storage devices.  I need
> help to figure out after generic_make_request how the request is
> placed to scsi disk (sd) requeset queue and than how sd qeueuecommand
> to usb_storeage thread.  (in which context, is it system call context)

requests out of the lower end of block come from the elevators.  The
elevators can operate in a variety of contexts: user, kernel thread or
softirq depending on state.

The mechanism for queueing to the USB thread is in
scsiglue.c:queuecommand() it's basically a simple single command
consumer model: fill in slot and wake thread.

James

Re: generic_make_request fucntion for scsi_disk

[Alan Stern]

On Sat, 20 Jun 2009, Ravish Tayal wrote:

> Hello,
> 
> I am debugging Filesystem code for USB mass storage devices.

What part of the filesystem code are you debugging?

Your questions talk about four separate layers: the filesystem, the
block layer, the SCSI layer, and the usb-storage driver.  Normally
people work on only one layer at a time.

Why are you concerned with more than one layer?

>  I need
> help to figure out after generic_make_request how the request is
> placed to scsi disk (sd) requeset queue and than how sd qeueuecommand
> to usb_storeage thread.  (in which context, is it system call context)
> 
> 
> inside generic_make_request
> 
> 1.   q = bdev_get_queue(bio->bi_bdev);  [is sd.c register queue this
> queue or any other scsi file?]

See scsi_alloc_sdev() in scsi_scan.c.  That's where the queue is 
allocated.

> 2.     ret = q->make_request_fn(q, bio);  [which file contain this
> make_request_fn for scsi disk driver (generic)]

scsi_request_fn() is in scsi_lib.c.  You could have found this out by 
yourself very easily with grep.  sd_prep_fn() is in sd.c.

> As per my unsderanding flow is like
> Fat_writepage ->_block_write_full_page --> blkdev_writepage-->
> block_write_full_page-->submit_bh-->generic_make_request ???  (sd ??)
> ----> queuecommand
> 
> Please suggest any sorce file, link or document.

The most relevant source files are scsi_lib.c and scsi.c.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: generic_make_request fucntion for scsi_disk

[James Bottomley]

Please don't drop the cc list ... part of the point of this is to create
an archive record for people with similar questions to find.

On Sat, 2009-06-20 at 20:11 +0530, Ravish Tayal wrote:
> Thanks James. 
>  
> For simple case when I echo few lines to usb mounted disk (fat file
> system).
>  
> mkdir /var/disk1
> mount /dev/sda /var/disk1
> echo "TESTing " >/var/disk1/test.txt
>  
> in this case will it be echo commands context it will be queue the
> commands to scsiglue.c or in between scsi layer would hold the
> commands.

That echo will end up in the page cache as a dirty page.
 
> I have noticed on usb analyser the write scsi commands happens for max
> sector size (64K) ... does in this case scsi command would be happen 
> for few bytes ?

Block commands all have to happen at a granularity of the device block
size (512b usually).  The elevators try to build up to larger sizes.

> or in other words is pdflush invokation indirectly control the WRITE
> scsi command length if file is of few MB or scsi layer itself does
> ot ?

The elevators control final request size depending on what inputs they
have and what parameters they were given.  In all cases, the request
will be a multiple of the filesystem block size (which will be the same
or bigger than the device block size).

> I still not able to find where sd register its request queue to file
> system.

It doesn't.  The Filesystem registers with block via sys_mount and SCSI
with block in scsi_lib.c:scsi_alloc_queue().

James

Re: generic_make_request fucntion for scsi_disk

[Alan Stern]

You should use Reply-To-All so that other people reading the mailing 
list will be able to follow and contribute to the thread.

On Sat, 20 Jun 2009, Ravish Tayal wrote:

> Thanks Alan,
> 
> I am actually trying to profile the time taken by each layer to complete the
> disk write opertaion as sys_write to queue_command invokation veries alot.

Of course it varies.  The kernel buffers disk writes, shuffles them 
around, and then carries them out when it wants to.  As James has 
pointed out, your write(2) system calls don't directly cause any I/O to 
take place.

Alan Stern

Re: generic_make_request fucntion for scsi_disk

[Ravish Tayal]

Sorry My mistake.
I will take care of it now onwards
regards
Ravish


On Sat, Jun 20, 2009 at 8:26 PM, Alan Stern<stern@rowland.harvard.edu> wrote:
> You should use Reply-To-All so that other people reading the mailing
> list will be able to follow and contribute to the thread.
>
> On Sat, 20 Jun 2009, Ravish Tayal wrote:
>
>> Thanks Alan,
>>
>> I am actually trying to profile the time taken by each layer to complete the
>> disk write opertaion as sys_write to queue_command invokation veries alot.
>
> Of course it varies.  The kernel buffers disk writes, shuffles them
> around, and then carries them out when it wants to.  As James has
> pointed out, your write(2) system calls don't directly cause any I/O to
> take place.
>
> Alan Stern
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html