Jens Axboe wrote:
>
> ...
> > 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.
We really don't want to do this, please. Changing things so
that we can only run bh2jh() and, particularly, journal_add_journal_head()
on a locked buffer would involve fairly unpleasant surgery against
parts of ext3 which are already prone to exploding. Like
do_get_write_access().
If it was needed for 2.5 then hmm, maybe. But as this is only a
2.4 problem then I really don't think we should risk breaking
or slowing down the filesystem for this.
Look, it's easy: delete buffer_head.b_inode (which is only used as
a boolean), move its function to a b_state bit. Add a new
buffer_head.ext3_hack and we can use that for pointing at the journal_head.
<insert "stable kernel" mantra here ;)>
-
On Thu, Jul 04 2002, Andrew Morton wrote:
> Jens Axboe wrote:
> >
> > ...
> > > 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.
>
> We really don't want to do this, please. Changing things so
> that we can only run bh2jh() and, particularly, journal_add_journal_head()
> on a locked buffer would involve fairly unpleasant surgery against
> parts of ext3 which are already prone to exploding. Like
> do_get_write_access().
>
> If it was needed for 2.5 then hmm, maybe. But as this is only a
> 2.4 problem then I really don't think we should risk breaking
> or slowing down the filesystem for this.
>
> Look, it's easy: delete buffer_head.b_inode (which is only used as
> a boolean), move its function to a b_state bit. Add a new
> buffer_head.ext3_hack and we can use that for pointing at the journal_head.
Thank you, this is what I was looking for (if you look further up, I was
advocating this very thing). Slimming down buffer_head and just add the
ext3 hack is perfectly acceptable to me.
Which just means that device mapper needs to do the stacking properly,
EOD.
--
Jens Axboe
On Thu, Jul 04 2002, Joe Thornber wrote:
> On Thu, Jul 04, 2002 at 10:39:41AM +0200, Jens Axboe wrote:
> > Which just means that device mapper needs to do the stacking properly,
> > EOD.
>
> You don't think it does it properly ATM ?
Well as I said, it's in the grey zone. If you look at stacking from a
submission and end_io point of view, then yes it works. Anywhere in
between, no it doesn't.
See my previous mails in this thread :-)
--
Jens Axboe
On Thu, Jul 04, 2002 at 10:39:41AM +0200, Jens Axboe wrote:
> Which just means that device mapper needs to do the stacking properly,
> EOD.
You don't think it does it properly ATM ?
- Joe