linux-2.5.2-pre11/drivers/loop.c bio question

linux-2.5.2-pre11/drivers/loop.c bio question

[Adam J. Richter]

	Has anyone out there tried to use linux-2.5.2-pre11/drivers/loop.c?
In my hacked version of loop.c, do_bio_blockbacked is often
called with a bio that has bio->bi_idx set to 1 rather than 0
(and with bi->bi_vcnt == 1), so it thinks it has no transfers to do.
When I add the kludge of doing "bio->bi_idx = 0;" at the beginning
of the routine, then it works fine.


	It is possible that my problem is self-inflicted because I
am using a version that I have adopted the "initial value" patch to,
and I also added a temporary hack to force the requests to be processed
one sector at a time, like so:

        blk_queue_max_segment_size(BLK_DEFAULT_QUEUE(MAJOR_NR), 512);

	However, I think my changes are probably not the cause.  Anyhow,
I thought I should mention this now to see if anyone else can
confirm or refute having similar problems.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

Re: linux-2.5.2-pre11/drivers/loop.c bio question

[Jens Axboe]

On Sat, Jan 12 2002, Adam J. Richter wrote:
> 	Has anyone out there tried to use linux-2.5.2-pre11/drivers/loop.c?
> In my hacked version of loop.c, do_bio_blockbacked is often
> called with a bio that has bio->bi_idx set to 1 rather than 0
> (and with bi->bi_vcnt == 1), so it thinks it has no transfers to do.
> When I add the kludge of doing "bio->bi_idx = 0;" at the beginning
> of the routine, then it works fine.

Must be some of your changes, end_that_request_last is the one that
increments the index and that is not called for loop requests.

> 	It is possible that my problem is self-inflicted because I
> am using a version that I have adopted the "initial value" patch to,
> and I also added a temporary hack to force the requests to be processed
> one sector at a time, like so:
> 
>         blk_queue_max_segment_size(BLK_DEFAULT_QUEUE(MAJOR_NR), 512);

Well that change has absolutely zero impact on loop, so you cannot
possibly see any changes from that. Besides, _if_ it would have an
effect you did not limit the segment size to 512 bytes -- there is no
splitting going on, so you would still receive up to 4k of data at the
time per segment.

-- 
Jens Axboe