Gentle managers:

We have a need to mount a filesystem without reading it at all.

The situation is that we have a user who can't take downtime when his
LPAR is IPLed.  Our workaround is to give him two servers on different
LPARs, but share the same physical disks between them.  Server A on
LPAR AA is the primary; then A goes down then server B is directed to
mount the disks and carry on.

The first thing we tried was just to have B mount the disks read-only
and check for a flag file; if that file (we'll call it IN_USE) exists,
don't do anything.  If it doesn't, then A has shut down nicely and
it's safe to grab the filesystem read-only.

The problem is that Ext3 will happily write to a filesystem *EVEN*
when you mount the FS read-only, if it thinks the journal needs
replaying.  Obviously playing the journal on server B while server A
is writing to it could be Very Bad.  This is a known property of ext3;
there was a long discussion
(http://lkml.indiana.edu/hypermail/linux/kernel/0704.1/0098.html)
about changing this on the kernel developers' list that petered out.
The concern was that the kernel could get confused if the mount -ro
proceeded and the filesystem was incorrect.

Now I think we could work around this by changing the device to
read-only before mounting, so you'd do something like this:
  blockdev --setro /dev/dasdXX     # Lock the device
  if mount /dev/dasdXX /mount/point ; then
     if [[ ! -f /mount/point/IN_USE ]]; then
         SAFE_TO_MOUNT=yes
     else
         SAFE_TO_MOUNT='no, lock file exists'
     fi
  else
         SAFE_TO_MOUNT='no, could not mount filesystem'
  fi
  blockdev --setrw /dev/dasdXX
I've tested "blockdev --setro" and it *is* local; changing it on one
machine doesn't change the filesystem on the other.

But is there some other reason to think this might be unsafe?  Would
Novell support be a better forum than this one?

(And we don't want to mess with a clustered filesystem if we don't
have to; they'd work but for this it would be overkill.)

Gratefully yours,

Ted Rodriguez-Bell
[email protected]

--
Company policy requires:  This message may contain confidential and/or 
privileged information.  If you are not the addressee or authorized to receive 
this for the addressee, you must not use, copy, disclose, or take any action 
based on this message or any information herein.  If you have received this 
message in error, please advise the sender immediately by reply e-mail and 
delete this message.  Thank you for your cooperation.

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to