linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bernd Schubert <bernd.schubert@fastmail.fm>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Johann Lombardi <johann@whamcloud.com>,
	linux-ext4@vger.kernel.org,
	Andreas Dilger <adilger@whamcloud.com>
Subject: Re: [PATCH] ext4: add support for multiple mount protection
Date: Tue, 12 Apr 2011 23:41:25 +0200	[thread overview]
Message-ID: <4DA4C705.9060502@fastmail.fm> (raw)
In-Reply-To: <4DA4B885.6020004@redhat.com>

On 04/12/2011 10:39 PM, Eric Sandeen wrote:
> On 4/12/11 1:04 PM, Johann Lombardi wrote:
>> Prevent an ext4 filesystem from being mounted multiple times. A
>> sequence number is stored on disk and is periodically updated
>> (every 5 seconds by default) by a mounted filesystem. At mount
>> time, we now wait for s_mmp_update_interval seconds to make sure 
>> that the MMP sequence does not change. In case of failure, the
>> nodename, bdevname and the time at which the MMP block was last
>> updated is displayed.
>> 
>> Signed-off-by: Andreas Dilger <adilger@whamcloud.com> 
>> Signed-off-by: Johann Lombardi <johann@whamcloud.com> --- 
>> fs/ext4/ext4.h  |   56 ++++++++- fs/ext4/super.c |  363
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 2 files
>> changed, 416 insertions(+), 3 deletions(-)
>> 
> 
> There was a lot of skepticism about this last time, and I imagine
> there still is...
> 
> 400 new lines of kernel code for this, and if the other machine is
> hung up for 5 seconds and doesn't update, it can still be
> multiply-mounted anyway, right?
> 
> BUG: soft lockup - CPU#0 stuck for 10s! anyone?  :(

Please see my other comment about the two different intervals. Yes,
there is a minimal chance of a race. But firstly, 5s are too small,
already for performance reasons (setting the update-interval to 5s will
increase the min check-interval to 25s). Secondly, the mount-wait time is

+	wait_time = min(mmp_check_interval * 2 + 1,
+			mmp_check_interval + 60);

So even with Johanns patch it is at least 12s.

Thirdly, the check-interval is automatically increased, if updating the
mmp block takes too long. This value will also be saved in the
mmp-block. Of course, it has a disadvantage - the mount time increases.

> 
> I don't see the value in it for upstream ext4, but then hey, ext4
> rarely meets a feature it doesn't like ;)

Is ext4 is only used on desktop systems? IMHO, every HA solution that
does not use scsi reservations or another way to check if a device is
already in use, needs a solution like this. I have seen so many problems
with heartbeat/pacemaker to not properly detect an already mounted
devices (*) and this MMP patch already protected so many HA Lustre
installations from data corruption due to double mounts....
So why shouldn't other HA solutions benefit from such a nice feature?

Usually, the heartbeat/pacemaker issues to detect if a device is mounted
or not are due to unreliable information if a device is mounted or not.
/etc/mtab is entirely unreliable and /proc/mounts does not always show
if a device is mounted or not.
However, even if that would work somehow perfectly, without the MMP
patch there is still zero protection from user-errors. It can easily
happen an admin forgets about a mounted device and runs e2fsck or
manually mounts the device on another machine again.

So please, let this patch go in.

Thanks,
Bernd

  parent reply	other threads:[~2011-04-12 21:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-12 18:04 [PATCH] ext4: add support for multiple mount protection Johann Lombardi
2011-04-12 19:20 ` Bernd Schubert
2011-05-02 13:43   ` Johann Lombardi
2011-04-12 20:39 ` Eric Sandeen
2011-04-12 21:08   ` Andreas Dilger
2011-04-12 21:11   ` Johann Lombardi
2011-04-12 21:41   ` Bernd Schubert [this message]
2011-04-12 21:44     ` Eric Sandeen
  -- strict thread matches above, loose matches on Subject: below --
2011-05-02  8:11 MMP update Johann Lombardi
2011-05-02  9:36 ` [PATCH] ext4: add support for multiple mount protection Johann Lombardi
2011-05-23  2:19   ` Ted Ts'o
2011-05-14  0:38 Johann Lombardi
2011-05-24 21:47 ` Ted Ts'o

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=4DA4C705.9060502@fastmail.fm \
    --to=bernd.schubert@fastmail.fm \
    --cc=adilger@whamcloud.com \
    --cc=johann@whamcloud.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@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;
as well as URLs for NNTP newsgroup(s).