All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andreas Dilger <adilger@turbolinux.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
	linux-lvm@sistina.com, jweber@valinux.com,
	"Heinz J. Mauelshagen" <mauelshagen@sistina.com>
Subject: Re: [linux-lvm] LVM 0.9 snapshot and ext3
Date: Fri, 1 Dec 2000 15:06:31 +0000	[thread overview]
Message-ID: <20001201150631.O4978@redhat.com> (raw)
In-Reply-To: <200011301948.eAUJm6k01893@webber.adilger.net>; from adilger@turbolinux.com on Thu, Nov 30, 2000 at 12:48:06PM -0700

Hi,

On Thu, Nov 30, 2000 at 12:48:06PM -0700, Andreas Dilger wrote:
> Stephen writes:
> > So, is somebody else doing a read?  It could be ext3, conceivably, if
> > we had had an IO error previously on the buffer and the BH_uptodate
> > flag had been cleared: a subsequent access to the buffer by another
> > process would try to reread the buffer off disk, locking it
> > temporarily.
> 
> Considering that there was the "Bad lvm_map in ll_rw_block" message just
> before the oops, this would lead to the situation you are talking about.
> In ll_rw_block the error path at "sorry:" clears BH_Dirty and BH_Uptodate,
> and calls b_end_io() but does not necessarily unlock the buffer?

The end-io should do the unlock no matter the value of uptodate.  I
should go and check what ext3 is doing on synchronous IO failures,
though.

> *** Stephen, in case of ANY error inside lvm_map() should it unlock the buffer?

ll_rw_block needs to unlock the buffer after the IO is complete, no
matter what the error.  The LVM people will know better than I whether
the lvm_map() function is the right place to do that.

Cheers,
 Stephen

      parent reply	other threads:[~2000-12-01 15:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-29  6:09 [linux-lvm] LVM 0.9 snapshot and ext3 Jay Weber
2000-11-29  6:21 ` Jay Weber
2000-11-29  6:24 ` Jay Weber
2000-11-29  7:01   ` Andreas Dilger
2000-11-29 10:18     ` Andreas Dilger
2000-11-30  9:46       ` Stephen C. Tweedie
2000-11-30 19:48         ` Andreas Dilger
2000-11-30 20:16           ` Andreas Dilger
2000-11-30 22:04           ` Jay Weber
2000-12-01 15:06           ` Stephen C. Tweedie [this message]

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=20001201150631.O4978@redhat.com \
    --to=sct@redhat.com \
    --cc=adilger@turbolinux.com \
    --cc=jweber@valinux.com \
    --cc=linux-lvm@sistina.com \
    --cc=mauelshagen@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.