Linux LVM users
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
	linux-lvm@msede.com, marcelo@conectiva.com.br
Subject: [linux-lvm] Re: LVM 2.2 snapshot bug
Date: Tue, 7 Nov 2000 20:51:37 +0100	[thread overview]
Message-ID: <20001107205137.A7093@inspiron.suse.de> (raw)
In-Reply-To: <20001107170420.D12477@redhat.com>; from sct@redhat.com on Tue, Nov 07, 2000 at 05:04:20PM +0000

On Tue, Nov 07, 2000 at 05:04:20PM +0000, Stephen C. Tweedie wrote:
> 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.

I don't have the Oops (I asked for it too) but Rik should have 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.

Stephen, the floppy device is doing exactly the same thing of LVM.
I don't think it's a major bug. The _only_ downside of the bug is that
it will generate I/O errors when you try to write to the device via
ll_rw_block (no oopses, no corruption), and those I/O errors will happen
anyways in real world too with real harddisk so we must able to cope with them
regardless.

The bug that hurted Rik is ext3 that is not able to deal with I/O error
properly during recovery and if you fix that, then LVM snapshot not setting
ro_bits will be a minor problem IMHO.

Infact I'm not even sure if it worth to have LVM snapshot to set ro_bits
given it will soon become a writeable snapshot (so that we can do recovery
on it too :).

Andrea

  reply	other threads:[~2000-11-07 19:51 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
2000-11-07 19:51         ` Andrea Arcangeli [this message]
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=20001107205137.A7093@inspiron.suse.de \
    --to=andrea@suse.de \
    --cc=linux-lvm@msede.com \
    --cc=marcelo@conectiva.com.br \
    --cc=riel@conectiva.com.br \
    --cc=sct@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox