From: Kalpak Shah <kalpak@clusterfs.com>
To: Manoj Joseph <manoj@clusterfs.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>,
Andreas Dilger <adilger@clusterfs.com>
Subject: Re: [RFC][PATCH] Multiple mount protection
Date: Tue, 22 May 2007 13:04:42 +0530 [thread overview]
Message-ID: <1179819282.4797.9.camel@garfield> (raw)
In-Reply-To: <4652987D.70209@clusterfs.com>
On Tue, 2007-05-22 at 12:45 +0530, Manoj Joseph wrote:
> Kalpak Shah wrote:
> > Hi,
> >
> > There have been reported instances of a filesystem having been
> > mounted at 2 places at the same time causing a lot of damage to the
> > filesystem. This patch reserves superblock fields and an INCOMPAT
> > flag for adding multiple mount protection(MMP) support within the
> > ext4 filesystem itself. The superblock will have a block number
> > (s_mmp_block) which will hold a MMP structure which has a sequence
> > number which will be periodically updated every 5 seconds by a
> > mounted filesystem. Whenever a filesystem will be mounted it will
> > wait for s_mmp_interval seconds to make sure that the MMP sequence
> > does not change. To further make sure, we write a random sequence
> > number into the MMP block and wait for another s_mmp_interval secs.
> > If the sequence no. doesn't change then the mount will succeed. In
> > case of failure, the nodename, bdevname and the time at which the MMP
> > block was last updated will be displayed. tune2fs can be used to set
> > s_mmp_interval as desired.
>
> What would the default value of s_mmp_interval be? 5 seconds? more?
I have set the default value to 6 seconds. Depending on specific
conditions (hardware, etc.) it can be increased using tunefs.
>
> If I am not reading this wrong a mount will take more than
> 's_mmp_interval' seconds to complete. Wouldn't this be too much of a
> penalty during boot up if the system has many 'mount at boot' filesystems?
Yes it may take a maximum of s_mmp_interval*2 seconds to mount a
filesystem which has INCOMPAT_MMP feature set. Its up to the user to use
this feature, if he finds the penalty is too large, he can do away with
this feature. This feature will mostly be used for filesystems used in
failover scenarios.
>
> Also, I am curious about this. Is there a test case for mounting the
> same filesystem multiple times? Does this use different paths to reach
> the device? Or is there a race? Or does it happen on a device shared by
> multiple hosts?
>
If you are using some HA software, there is the possibility of a race.
Yes it can happen on a device shared by multiple hosts.
A simple test case for this will be:
$ dd if=/dev/zero of=img0 bs=1M count=256
$ mke2fs -F -j img0
$ ln img0 img1
$ losetup /dev/loop0 img0
$ losetup /dev/loop1 img1
$ mount /dev/loop0 /mnt/loop0
$ mount /dev/loop1 /mnt/loop1
This succeeds currently causing a multiple mount.
Thanks,
Kalpak.
> -Manoj
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2007-05-22 7:31 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 [this message]
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
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=1179819282.4797.9.camel@garfield \
--to=kalpak@clusterfs.com \
--cc=adilger@clusterfs.com \
--cc=linux-ext4@vger.kernel.org \
--cc=manoj@clusterfs.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