why not use something like heartbeat when Server A goes away either planned or unplanned outage Server B mounts the filesystem. then Server A comes back Server B unmounts it and Server A mounts it
I think it would be allot cleaner and only one server has it mounted at a time IMHO a better way William 'Doug' Carroll Mainframe Systems Eng Sr I Global Technology Infrastructure -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Ted Rodriguez-Bell Sent: Friday, June 05, 2009 7:47 PM To: [email protected] Subject: Mounting a filesystem *really* read-only 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 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. ---------------------------------------------------------------------- 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
