From: Bill Davidsen <davidsen@tmr.com>
To: Neil Brown <neilb@suse.de>
Cc: liu yang <liudows2@gmail.com>, linux-raid@vger.kernel.org
Subject: Re: to understand the logic of raid0_make_request
Date: Tue, 13 Jun 2006 14:45:39 -0400 [thread overview]
Message-ID: <448F07D3.50605@tmr.com> (raw)
In-Reply-To: <17550.2944.728044.154492@cse.unsw.edu.au>
Neil Brown wrote:
>On Tuesday June 13, liudows2@gmail.com wrote:
>
>
>>hello,everyone.
>>I am studying the code of raid0.But I find that the logic of
>>raid0_make_request is a little difficult to understand.
>>Who can tell me what the function of raid0_make_request will do eventually?
>>
>>
>
>One of two possibilities.
>
>Most often it will update bio->bi_dev and bio->bi_sector to refer to
>the correct location on the correct underlying devices, and then
>will return '1'.
>The fact that it returns '1' is noticed by generic_make_request in
>block/ll_rw_block.c and generic_make_request will loop around and
>retry the request on the new device at the new offset.
>
>However in the unusual case that the request cross a chunk boundary
>and so needs to be sent to two different devices, raidi_make_request
>will split the bio into to (using bio_split) will submit each of the
>two bios directly down to the appropriate devices - and will then
>return '0', so that generic make request doesn't loop around.
>
>I hope that helps.
>
Helps me, anyway, thanks! Wish the comments on stuff like that in
general were clear, you can see what the code *does*, but you have to
hope that it's what the coder *intended*. And if you're looking for a
bug it may not be, so this is not an idle complaint.
Some of the kernel coders think "if it was hard to write it should be
hard to understand."
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2006-06-13 18:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-13 0:37 to understand the logic of raid0_make_request liu yang
2006-06-13 0:49 ` Neil Brown
2006-06-13 1:18 ` RAID tuning? Adam Talbot
2006-06-13 10:19 ` Gordon Henderson
2006-06-13 10:21 ` Justin Piszcz
2006-06-13 10:23 ` Justin Piszcz
2006-06-13 10:32 ` Gordon Henderson
2006-06-13 17:57 ` Adam Talbot
2006-06-13 21:38 ` Gordon Henderson
2006-06-14 15:11 ` Nix
2006-06-14 15:35 ` Molle Bestefich
2006-06-14 20:38 ` Disks keep failing durning testing Adam Talbot
2006-06-14 21:45 ` PFC
2006-06-14 23:23 ` Adam Talbot
2006-06-15 12:12 ` Leo Kliger
2006-06-13 18:45 ` Bill Davidsen [this message]
2006-06-16 2:53 ` to understand the logic of raid0_make_request liu yang
2006-06-16 4:32 ` Neil Brown
2006-06-16 5:14 ` RAID on the root partition / Adam Talbot
2006-06-16 6:13 ` Neil Brown
2006-06-16 6:55 ` Gordon Henderson
2006-06-16 13:41 ` to understand the logic of raid0_make_request liu yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=448F07D3.50605@tmr.com \
--to=davidsen@tmr.com \
--cc=linux-raid@vger.kernel.org \
--cc=liudows2@gmail.com \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).