From: Eric Sandeen <sandeen@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
Fengguang Wu <fengguang.wu@gmail.com>
Subject: Re: Fw: [BUG -mm] ext3_orphan_add() accessing corrupted list on a corrupted ext3fs
Date: Thu, 01 Feb 2007 10:58:08 -0600 [thread overview]
Message-ID: <45C21C20.7080807@redhat.com> (raw)
In-Reply-To: <20070201010836.31a63ef2.akpm@osdl.org>
Andrew Morton wrote:
>
> Begin forwarded message:
>
> Date: Thu, 1 Feb 2007 16:44:39 +0800
> From: Fengguang Wu <fengguang.wu@gmail.com>
> To: LKML <linux-kernel@vger.kernel.org>
> Subject: [BUG -mm] ext3_orphan_add() accessing corrupted list on a corrupted ext3fs
>
>
> I accidentally ran two qemu instances on the same ext3 fs, after that bad
> things happened. After exiting the two qemus and running a new one, I got the
> following oops:
Is this equivalent to mounting the same SAN block device on 2 different
machines? And if so how much can the filesystem really be expected to
cope with this?
(remembering to read the rest of his inbox...)
Andreas Dilger wrote:
> I don't have a comment on the actual bug here, but this is another case
> where it would be nice to have multi-mount protection built into ext3...
> When I last proposed this it was refused on the grounds that an external
> HA manager should be doing this job but I don't think that is realistic.
I'm with Andreas on this one, in the era of SANs, iscsi, virtual
machines, and suspended images, it would be nice to prevent multiple
mounts at the fs (or vfs?) level....
-Eric
next prev parent reply other threads:[~2007-02-01 16:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-01 9:08 Fw: [BUG -mm] ext3_orphan_add() accessing corrupted list on a corrupted ext3fs Andrew Morton
2007-02-01 10:25 ` Andreas Dilger
2007-02-01 17:28 ` Alex Tomas
2007-02-02 1:19 ` Andreas Dilger
2007-02-01 16:58 ` Eric Sandeen [this message]
2007-02-01 20:56 ` ext3_forget() and ext3_free_blocks() Mingming Cao
2007-02-02 10:30 ` Andreas Gruenbacher
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=45C21C20.7080807@redhat.com \
--to=sandeen@redhat.com \
--cc=akpm@osdl.org \
--cc=fengguang.wu@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).