mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
To: jens.axboe@oracle.com
Cc: agk@redhat.com, mchristi@redhat.com,
	linux-kernel@vger.kernel.org, dm-devel@redhat.com,
	j-nomura@ce.jp.nec.com, k-ueda@ct.jp.nec.com
Subject: Re: [RFC PATCH 2/8] rqbased-dm: add block layer hook
Date: Thu, 21 Dec 2006 17:22:46 -0500 (EST)	[thread overview]
Message-ID: <20061221.172246.21934588.k-ueda@ct.jp.nec.com> (raw)
In-Reply-To: <20061221074947.GC17199@kernel.dk>

Hi Jens,

On Thu, 21 Dec 2006 08:49:47 +0100, Jens Axboe <jens.axboe@oracle.com> wrote:
> > The new hook is needed for error handling in dm.
> > For example, when an error occurred on a request, dm-multipath
> > wants to try another path before returning EIO to application.
> > Without the new hook, at the point of end_that_request_last(),
> > the bios are already finished with error and can't be retried.
> 
> Ok, I see what you are getting at. The current ->end_io() is called when
> the request has fully completed, you want notification for each chunk
> potentially completed.
> 
> I think a better design here would be to use ->end_io() as the full
> completion handler, similar to how bio->bi_end_io() works. A request
> originating from __make_request() would set something ala:
> 
> int fs_end_io(struct request *rq, int error, unsigned int nr_bytes)
> {
>         if (!__end_that_request_first(rq, err, nr_bytes)) {
>                 end_that_request_last(rq, error);
>                 return 0;
>         }
> 
>         return 1;
> }
> 
> and normal io completion from a driver would use a helper:
> 
> int blk_complete_io(struct request *rq, int error, unsigned int nr_bytes)
> {
>         return rq->end_io(rq, error, nr_bytes);
> }
> 
> instead of calling the functions manually. That would allow you to get
> notification right at the beginning and do what you need, without adding
> a special hook for this.

I'm not confident about what you mean.
Something like this?
  - __make_request() sets fs_end_io() to req->end_io()
  - The driver calls blk_complete_io()
       * if it succeeds, the request is done
       * if it fails, the request is not completed
         and the driver needs retry or something
  - Current users of req->end_io() have to update/rewrite thier end_io.
  - Features like mine will set its own end_io.
    It checks error and decides whether calling fs_end_io() or not.

Depending on drivers, there are some functions called between
__end_that_request_first() and end_that_request_last().
For example:
  - add_disk_randomness()
  - blk_queue_end_tag()
  - floppy_off()
So they might prevent such generalization.


In addition to the suggested approach, what do you think about
adding a new flag to req->cmd_flags which lets the end_io() handler
not to return bio to upper layer?
It will be useful for multipathing and can be done even within
the current __end_that_request_first().
For example,

static int __end_that_request_first()
{
	.....
	error = 0;
	if (end_io_error(uptodate))
		error = !uptodate ? -EIO : uptodate;
	.....
	if (error && (req->cmd_flags & "NEW_FLAG"))
		return 0; /* Tell the driver to call end_that_request_last() */

	total_types = bio_nbytes = 0;
	while ((bio = req->bio) != NULL) {
		..... /* process of finishing bios */
	}
	.....
}

Thanks,
Kiyoshi Ueda


  reply	other threads:[~2006-12-21 22:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-19 22:11 Kiyoshi Ueda
2006-12-20 13:49 ` Jens Axboe
2006-12-20 21:52   ` Kiyoshi Ueda
2006-12-21  7:49     ` Jens Axboe
2006-12-21 22:22       ` Kiyoshi Ueda [this message]
2006-12-21 22:56         ` business1
2006-12-22  7:18         ` [dm-devel] " Mike Christie
2006-12-22 19:55           ` Kiyoshi Ueda
2006-12-21 23:00     ` business1
2006-12-21 22:56   ` business1
2006-12-21 22:53 ` business1

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=20061221.172246.21934588.k-ueda@ct.jp.nec.com \
    --to=k-ueda@ct.jp.nec.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchristi@redhat.com \
    /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

all inboxes | Powered by JetHome®