From: Andrew Morton <akpm@zip.com.au>
To: Jens Axboe <axboe@suse.de>
Cc: Joe Thornber <joe@fib011235813.fsnet.co.uk>,
linux-lvm@sistina.com, linux-kernel@vger.kernel.org
Subject: Re: [linux-lvm] LVM2 modifies the buffer_head struct?
Date: Wed Jul 3 05:23:01 2002 [thread overview]
Message-ID: <3D22D1CE.1C0A4906@zip.com.au> (raw)
In-Reply-To: 20020703100838.GH14097@suse.de
Jens Axboe wrote:
>
> On Tue, Jul 02 2002, Joe Thornber wrote:
> > Tom,
> >
> > On Tue, Jul 02, 2002 at 09:40:56AM -0400, Tom Walcott wrote:
> > > Hello,
> > >
> > > Browsing the patch submitted for 2.4 inclusion, I noticed that LVM2
> > > modifies the buffer_head struct. Why does LVM2 require the addition of it's
> > > own private field in the buffer_head? It seems that it should be able to
> > > use the existing b_private field.
> >
> > This is a horrible hack to get around the fact that ext3 uses the
> > b_private field for its own purposes after the buffer_head has been
> > handed to the block layer (it doesn't just use b_private when in the
> > b_end_io function). Is this acceptable behaviour ? Other filesystems
> > do not have similar problems as far as I know.
> >
> > device-mapper uses the b_private field to 'hook' the buffer_heads so
> > it can keep track of in flight ios (essential for implementing
> > suspend/resume correctly). See dm.c:dec_pending()
>
> Your driver is required to properly stack b_private uses, however if
> ext3 (well jbd really) over writes b_private after bh i/o submission I
> would say that it is broken. That breaks more than just device mapper,
> that will break any stacked driver (such as loop, for instance).
It requires that b_private be stable across the lifetime of the buffer.
hmm.
-
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@zip.com.au>
To: Jens Axboe <axboe@suse.de>
Cc: Joe Thornber <joe@fib011235813.fsnet.co.uk>,
linux-lvm@sistina.com, linux-kernel@vger.kernel.org
Subject: Re: [linux-lvm] LVM2 modifies the buffer_head struct?
Date: Wed, 03 Jul 2002 03:28:30 -0700 [thread overview]
Message-ID: <3D22D1CE.1C0A4906@zip.com.au> (raw)
In-Reply-To: 20020703100838.GH14097@suse.de
Jens Axboe wrote:
>
> On Tue, Jul 02 2002, Joe Thornber wrote:
> > Tom,
> >
> > On Tue, Jul 02, 2002 at 09:40:56AM -0400, Tom Walcott wrote:
> > > Hello,
> > >
> > > Browsing the patch submitted for 2.4 inclusion, I noticed that LVM2
> > > modifies the buffer_head struct. Why does LVM2 require the addition of it's
> > > own private field in the buffer_head? It seems that it should be able to
> > > use the existing b_private field.
> >
> > This is a horrible hack to get around the fact that ext3 uses the
> > b_private field for its own purposes after the buffer_head has been
> > handed to the block layer (it doesn't just use b_private when in the
> > b_end_io function). Is this acceptable behaviour ? Other filesystems
> > do not have similar problems as far as I know.
> >
> > device-mapper uses the b_private field to 'hook' the buffer_heads so
> > it can keep track of in flight ios (essential for implementing
> > suspend/resume correctly). See dm.c:dec_pending()
>
> Your driver is required to properly stack b_private uses, however if
> ext3 (well jbd really) over writes b_private after bh i/o submission I
> would say that it is broken. That breaks more than just device mapper,
> that will break any stacked driver (such as loop, for instance).
It requires that b_private be stable across the lifetime of the buffer.
hmm.
-
next prev parent reply other threads:[~2002-07-03 5:23 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-02 8:41 [linux-lvm] LVM2 modifies the buffer_head struct? Tom Walcott
2002-07-02 9:17 ` Joe Thornber
2002-07-02 14:17 ` Joe Thornber
2002-07-03 5:09 ` Jens Axboe
2002-07-03 10:08 ` Jens Axboe
2002-07-03 5:23 ` Andrew Morton [this message]
2002-07-03 10:28 ` Andrew Morton
2002-07-03 7:01 ` Joe Thornber
2002-07-03 12:01 ` Joe Thornber
2002-07-03 7:10 ` Jens Axboe
2002-07-03 12:10 ` Jens Axboe
2002-07-03 23:44 ` Neil Brown
2002-07-04 4:46 ` Neil Brown
2002-07-04 0:39 ` Andrew Morton
2002-07-04 5:44 ` Andrew Morton
2002-07-04 2:46 ` Joe Thornber
2002-07-04 7:45 ` Joe Thornber
2002-07-04 2:58 ` Jens Axboe
2002-07-04 7:58 ` Jens Axboe
2002-07-04 3:34 ` Andrew Morton
2002-07-04 8:40 ` Andrew Morton
2002-07-04 3:40 ` Jens Axboe
2002-07-04 8:39 ` Jens Axboe
2002-07-04 3:58 ` Joe Thornber
2002-07-04 8:57 ` Joe Thornber
2002-07-04 4:00 ` Jens Axboe
2002-07-04 9:00 ` Jens Axboe
2002-07-04 4:38 ` Andrew Morton
2002-07-04 9:44 ` Andrew Morton
2002-07-07 14:52 ` Joe Thornber
2002-07-07 20:51 ` Joe Thornber
-- strict thread matches above, loose matches on Subject: below --
2002-07-05 0:21 Mark Peloquin
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=3D22D1CE.1C0A4906@zip.com.au \
--to=akpm@zip.com.au \
--cc=axboe@suse.de \
--cc=joe@fib011235813.fsnet.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-lvm@sistina.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.