public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Kalpak Shah <kalpak@clusterfs.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>,
	Andreas Dilger <adilger@clusterfs.com>
Subject: Re: [RFC][PATCH] Multiple mount protection
Date: Fri, 25 May 2007 10:39:57 -0400	[thread overview]
Message-ID: <20070525143957.GA12669@thunk.org> (raw)
In-Reply-To: <1179777153.3910.13.camel@garfield>

Hi Kalpak,

On Tue, May 22, 2007 at 01:22:32AM +0530, Kalpak Shah wrote:
> It will also protect against running e2fsck on a mounted filesystem
> by adding similar logic to ext2fs_open().

Your patch didn't add this logic to ext2fs_open(); it just reserved
the space in the superblock.

I don't mind reserving the space so we don't have to worry about
conflicting superblock uses, but I'm still on the fence about actually
adding this functionality (a) into e2fsprogs, and (b) into the ext4
kernel code.  I guess it depends on how complicated/icky the
implementation code is, I guess.  The question as before is whether
the complexity is worth it, given that someone who is actually going
to be subject to accidentally mounting an ext3/4 filesystem on
multiple systems needs to be using an HA system anyway.  So basically
this is just to protect against (a) a bug/failure in the HA subsystem,
and (b) the idiotic user that failed to realized he/she needed to set
up an HA subsystem in the first place.  Granted, the universe is going
to create idiots at a faster rate that we can deal with it, but that's
why I'm still not 100% convinced the complexity is worth it.

To be fair, if I was on a L3 support team having to deal with these
idiots, I'd probably feel differently.  :-)

							- Ted

  parent reply	other threads:[~2007-05-25 14:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-21 19:52 [RFC][PATCH] Multiple mount protection Kalpak Shah
2007-05-22  7:15 ` Manoj Joseph
2007-05-22  7:34   ` Kalpak Shah
2007-05-22  7:53     ` Manoj Joseph
2007-05-22  8:06       ` Kalpak Shah
2007-05-24 23:25     ` Karel Zak
2007-05-25  6:44       ` Kalpak Shah
2007-05-25 14:39 ` Theodore Tso [this message]
2007-05-25 19:31   ` Jim Garlick
2007-05-25 21:36   ` Kalpak Shah
2007-05-30 20:58     ` Kalpak Shah
2007-05-31 16:16       ` Theodore Tso
2007-05-31 21:09         ` Kalpak Shah
2007-06-01  8:46 ` Andi Kleen
2007-06-01  8:27   ` Kalpak Shah
2007-06-01  9:14   ` Andreas Dilger
2007-06-01 10:56     ` Andi Kleen
2007-06-01 11:41   ` Theodore Tso
2007-06-01 12:13     ` Andi Kleen
2007-06-01 13:52       ` Theodore Tso
2007-06-01 18:00         ` 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=20070525143957.GA12669@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@clusterfs.com \
    --cc=kalpak@clusterfs.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