Re: [RFC] ext3 multi-mount protection

On Sun, Jul 16, 2006 at 03:05:13AM -0600, Andreas Dilger wrote:
> The reason the INCOMPAT flag is used in order to prevent some other
> node which knows nothing about the heartbeat block from trying to
> mount the filesystem.  This needs to be INCOMPAT because even an r/o
> mount on a second node will still replay the journal and corrupt the
> filesystem.

If the goal is to solve the problem of cooperating nodes in a
cluster/fallback setup, we can assume they are running the correct
software to check for the hearbeat block without needing to enforce it
with an INCOMPAT flag.

I wonder how useful is it to protect against the newbie case:

> Yeah, I also thought about reading the block back, and this might be
> desirable at some point in the future.  The current goal is just to
> prevent another node from trying to mount the filesystem.  This can
> also happen in non-HA scenarios where an FC SAN has disks that are
> visible on nodes they shouldn't be.  Some clueless newbie thinks
> "Wow, there's 2TB of disk space on this node that isn't even mounted,
> I'm going to store my pr0n collection there...".

.... since said newbie is just as likely to decide to use reiserfs4,
since it's so l33t (or reuse the space as part of LVM RAID setup, or
as an Oracle raw tablespace, etc.) and then you're screwed.

If we make sure the heartbeat block is near the beginning of the
filesystem, and we do implement the constant readback of heartbeat
block, it becomes more likely that we catch that case, although it's
still not fool proof.

> IMHO, having this done in userspace is just asking for trouble.  You
> first have to handle the INCOMPAT flag, then this has to be checked
> after the filesystem is mounted but before journal replay (doing a
> "pre check" is still racy with some other node mounting), then start
> a daemon after the fs is mounted, and that daemon might never start or
> die for any number of reasons.

As long as both sides do the pre-check using the same pre-check
algorithm, it's no more or less racy as doing it in the kernel.  There
will always be a gap between when you do the passive observation of
the heartbeat block, to when you try to claim it by writing a bootid
and/or a random 32-bit sequence number (I would strongly recommend
using the bootid --- it's safer), and when you start to run the
journal.

And if you are doing the periodic read checking in the kernel, then I
think it's safe to move the keepalive daemon into userspace.  On the
other hand, it's not that much code, so maybe it is better to keep it
in the kernel.

						- Ted


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642