public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.org>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Joe Thornber <joe@fib011235813.fsnet.co.uk>,
	linux-lvm@sistina.com, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@zip.com.au>
Subject: Re: [linux-lvm] LVM2 modifies the buffer_head struct?
Date: Thu, 4 Jul 2002 09:58:30 +0200	[thread overview]
Message-ID: <20020704075830.GQ21568@suse.de> (raw)
In-Reply-To: <15651.54044.557070.109158@notabene.cse.unsw.edu.au>

On Thu, Jul 04 2002, Neil Brown wrote:
> On Wednesday July 3, axboe@suse.de wrote:
> > 
> > Now we are in a grey area. The 'usual' stacked drivers work like this:
> > 
> > some fs path
> > 	submit_bh(bh_orig);
> > 
> > ...
> > 
> > stacked driver make_request_fn:
> > 	bh_new = alloc_bh
> > 	bh_new->b_private = bh_orig;
> > 	...
> > 	submit_bh(bh_new);
> > 
> > if you are just modifying b_private, how exactly is your stacking
> > working? ie what about lvm2 on lvm2?
> 
> I think this can work sanely and is something I have considered for
> raid1-read and multipath in md.
> 
> struct privatebit {
>   bio_end_io_t  *oldend;
>   void          *oldprivate;
>   ...other...stuff;
> };
> 
> make_request(struct request_queue_t *q, struct buffer_head *bh, int rw)
> {
> 
>  struct privatebit *pb = kmalloc(...);
> 
>   pb->oldend = bh->b_end_io;
>   pb->oldprivate = bh->b_private;
>   bh->b_private = pb;
>   bh->b_end_io = my_end_handler;
> 
>   ..remap b_rdev, b_rsector ...
> 
>   generic_make_request(bh, rw);
> 
> }

Yes this works fine, as long as you assert that stacking is an entity of
the b_end_io functions, ie you dont rely on the state of the buffer_head
before i/o completion. But it breaks for ext3.

I'm inclined to say that I think 2.4 mappers should go the full length
like I did in loop, which is always safe (although it does eat more
memory, of course, buffer_heads aren't exactly lite :)

int make_request(struct request_queue_t *q, struct buffer_head *bh, int rw)
{
	struct buffer_head *stack_bh = some_pool_alloc(...);

	stack_bh->b_private = bh;
	stack_bh->b_end_io = my_end_handler;

	/* setup b_rdev and b_rsector, etc */
	generic_make_request(stack_bh, rw);
	return 0;
}

> We just want ext3/jbd to make sure that it only calls bh2jh on
> an unlocked buffer... is that easy?

That's the question indeed, someone with a good grasp of jbd should make
that call. If that is the only 'violator' (depending on your point of
view), then yes lets just fix that up and say that the above is pb
private is valid.

> Ofcourse this ceases to be an issue in 2.5 because the filesys uses 
> pages or buffer_heads and the device driver uses bios.

Yep, no such problem in 2.5

-- 
Jens Axboe


  parent reply	other threads:[~2002-07-04  7:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <F19741gcljD2E2044cY00004523@hotmail.com>
2002-07-02 14:17 ` [linux-lvm] LVM2 modifies the buffer_head struct? Joe Thornber
2002-07-03 10:08   ` Jens Axboe
2002-07-03 10:28     ` Andrew Morton
2002-07-03 12:01     ` Joe Thornber
2002-07-03 12:10       ` Jens Axboe
2002-07-04  4:46         ` Neil Brown
2002-07-04  5:44           ` Andrew Morton
2002-07-04  7:45           ` Joe Thornber
2002-07-04  7:58           ` Jens Axboe [this message]
2002-07-04  8:40             ` Andrew Morton
2002-07-04  8:39               ` Jens Axboe
2002-07-04  8:57                 ` Joe Thornber
2002-07-04  9:00                   ` Jens Axboe
2002-07-04  9:44                 ` Andrew Morton
2002-07-07 20:51                   ` Joe Thornber
2002-07-05 15:23 Mark Peloquin

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=20020704075830.GQ21568@suse.de \
    --to=axboe@kernel.org \
    --cc=akpm@zip.com.au \
    --cc=joe@fib011235813.fsnet.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-lvm@sistina.com \
    --cc=neilb@cse.unsw.edu.au \
    /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