From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Rik van Riel <riel@conectiva.com.br>,
linux-lvm@msede.com, marcelo@conectiva.com.br,
"Stephen C. Tweedie" <sct@redhat.com>
Subject: [linux-lvm] Re: LVM 2.2 snapshot bug
Date: Tue, 7 Nov 2000 17:04:20 +0000 [thread overview]
Message-ID: <20001107170420.D12477@redhat.com> (raw)
In-Reply-To: <20001107174504.A5834@inspiron.suse.de>; from andrea@suse.de on Tue, Nov 07, 2000 at 05:45:04PM +0100
Hi,
On Tue, Nov 07, 2000 at 05:45:04PM +0100, Andrea Arcangeli wrote:
> On Tue, Nov 07, 2000 at 03:56:59PM +0100, Rik van Riel wrote:
> > That's a bit much to type in by hand ... and it's basically
> > kjournald being confused by all its writes failing on a RW
> > block device.
>
> So ext3 will crash also if I/O errors happen during the log reply. The Oopses
> seems due an _ext3_ bug (not due the missing ro_bits in the LVM snapshot)
> as far I can tell.
The current ext3 includes debugging code to trap invariants which the
filesystem expects to be guaranteed, and it's entirely possible that
their over-cautious checking is trapping on such failed writes. Send
me an oops and I can deal with it.
> > Indeed this is the case. When the block device is read-write
> > (the is_read_only(blk_dev) is non-true) it tries to replay
> > the log, even for a read-only mounted FS.
>
> Ok, I agree it's a minor LVM bug, but again I can't see how that minor bug can
> cause oopses and I think setting ro_bits won't fix the real bug but it will
> only hide it.
It's a major bug as far as ext3 is concerned, because filesystem
recovery is a critical prerequisite for mounting a filesystem, and
that requires write access. ext3 has to be able to trust the ro bits
in order to know whether it is safe to perform recovery writes for a
mount, or whether the mount must be rejected because recovery cannot
take place.
Cheers,
Stephen
next prev parent reply other threads:[~2000-11-07 17:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-07 10:55 [linux-lvm] LVM 2.2 snapshot bug Rik van Riel
2000-11-07 12:16 ` Heinz J. Mauelshagen
2000-11-07 14:42 ` Rik van Riel
2000-11-07 13:21 ` [linux-lvm] " Andrea Arcangeli
2000-11-07 14:56 ` Rik van Riel
2000-11-07 16:45 ` Andrea Arcangeli
2000-11-07 17:04 ` Stephen C. Tweedie [this message]
2000-11-07 19:51 ` Andrea Arcangeli
2000-11-07 20:36 ` Andreas Dilger
2000-11-08 11:11 ` Stephen C. Tweedie
2000-11-08 16:16 ` Andrea Arcangeli
2000-11-08 19:08 ` Andreas Dilger
2000-11-08 11:10 ` Stephen C. Tweedie
2000-11-08 16:53 ` Andrea Arcangeli
2000-11-07 23:04 ` Rik van Riel
2000-11-08 7:55 ` Heinz Mauelshagen
2000-11-08 13:44 ` Rik van Riel
2000-11-08 16:31 ` Andrea Arcangeli
[not found] ` <898720000.973701988@coffee>
2000-11-08 17:04 ` Andrea Arcangeli
2000-11-08 19:11 ` Andreas Dilger
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=20001107170420.D12477@redhat.com \
--to=sct@redhat.com \
--cc=andrea@suse.de \
--cc=linux-lvm@msede.com \
--cc=marcelo@conectiva.com.br \
--cc=riel@conectiva.com.br \
/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.