Re: [RFC] ext3 multi-mount protection

Like Stephen, I'm pretty nervous about trying to effectively add a
heartbeat/keepalive mechanism into the filesystem, and effectively
utilizing a disk block as a the communication path.  It's adding a
fair amount of complexity into the filesystem, and it's not even a
complete solution; without STONITH, we can easily end up with a
situation where the FC cable gets temporarily disconnected, the backup
takes over, and then when the FC cable gets reconnected, the master
thinks it can still write to the disk, and.... oops!

But if we are going to do this, we can do it without adding an
INCOMPAT_PO flag.  What we do is we define a new superblock field
which defines the block that should be used as the "poor-man's
heartbeat block", and then reserve the block in the bad block inode.
Simple, no muss, no fuss, no dirty dishes.

It is actually possible to do a STONITH like thing, but it's
**really** gross.  It requires that the kalived thread to every five
seconds, to try reading from the heartbeat block, and if the read does
not succeed within 3 seconds, the kernel must abort all filesystem I/O
operations and revoke all file descriptors.  If the read succeeds, one
of the things stored in the heartbeat block, in addition to the
sequence counter, is the bootid UUID of the system with the mounted
filesystem.  If the bootid UUID ever changes from what is expected,
the system must again immediately stop writing to the filesystem and
revoke(2) all file descriptors on the filesystem.

When a system tries to grab the filesystem, it must first check the
heartbeat block, wait 10 seconds, and check the heartbeat block again.
If the sequence number has changed, then it must refuse the mount.
Once it believes the system is dead, it must write its bootid UUID
into the heartblock, and wait another 10 seconds, and recheck the
heartbeat block.  If the bootid UUID changes, then something has gone
wrong and the acquiring system must refuse the mount.  Only after the
second 20 second wait should the backup system assume that it can
safely assume that the other system is dead (or will refuse to touch
the filesystem, in any case), and at that point, it can run the
journal and mount the filesystem.

The question though is how much of this should be done in the kernel,
and how much should just be deferred to a userspace helper utility
program.

						 - 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