From: Andrea Arcangeli <andrea@suse.de>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-lvm@msede.com, marcelo@conectiva.com.br
Subject: [linux-lvm] Re: LVM 2.2 snapshot bug
Date: Tue, 7 Nov 2000 14:21:52 +0100 [thread overview]
Message-ID: <20001107142152.G1276@inspiron.random> (raw)
In-Reply-To: <Pine.LNX.4.05.10011071151180.21541-100000@humbolt.nl.linux.org>; from riel@conectiva.com.br on Tue, Nov 07, 2000 at 11:55:42AM +0100
On Tue, Nov 07, 2000 at 11:55:42AM +0100, Rik van Riel wrote:
> On snapshot creation, the snapshot block device (/dev/vg0/snap1)
> is NOT made a read-only device, so ext3 tries to do journal
It is made read only.
> (leading to all kinds of nasty oopses)
Could you show me the Oopses?
> It should be easy enough to do an set_device_ro() on the LVM
> snapshot, shouldn't it?
That shouldn't be necessary. The way LVM handle this looks correct
to me, but maybe it's never been tested in the ll_rw_block layer because the
open(O_RDWR) check always handled it with ext2. Maybe ext3 forces writes via
ll_rw_block also when the device is mounted read only (probably when doing log
reply?) and maybe it hits the ll_rw_block check for the first time.
Currently we choose if a device is readable or not using the
VM_WRITE bitflag in the lv->lv_access field. If the bitflag is set
the device is writeable. You'll find that the snapshots has that bitflag
unset (please verify via /proc that they don't have the W capability set).
If the snapshot is not writeable as expected, the lvm hook in ll_rw_block
should return -1 and ll_rw_block should goto sorry just like if we would be
using the ro_bits via set_device_ro. So it should not be necessary
to use the set_device_ro.
Or maybe the bug is in ext3 that doesn't handle real read only blockdevices?
> That would fix the oopses I've been seeing and would make
Hopefully the Oopses will tell us more about this ext3/snapshot collision.
Also please ensure you can reproduce with 2.2.18pre17aa1 or 2.4.0-test10 to
make sure we're looking at the same sources.
Andrea
next prev parent reply other threads:[~2000-11-07 13:21 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 ` Andrea Arcangeli [this message]
2000-11-07 14:56 ` [linux-lvm] " 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
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=20001107142152.G1276@inspiron.random \
--to=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.