Ted Rodriguez-Bell wrote:
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.


Hrmm...

Wait a minute !

Are you saying side A is using the filesystem R/W and you are attempting
to mount the filesystem on side B R/O ?

And *THEN* you are trying to see any modifications made on side A from
side B ?

....

That's very *VERY* unreliable !

First, as you noted, ext3 is a journaled filesystem.. So this means that
any changes made by side A only have meaning if you can replay the log.

Second (as Mark noted) - you may think you can mount the FS R/O and
prevent the log from being replayed by specifying you want a
non-journaled FS (aka EXT2) - which may (and will) lead to the FS being
marked dirty (as Shane noted) - requiring a 'fsck' to be performed -
requiring WRITE access (bad.. very bad !)

Third..

If you mount the fs R/O and read data off of it - there is NO GUARANTEE
- that the FS manager will reread that very same block if it is already
cached.. So your view of the FS is likely going to be skewed.. Or you
could be reading something completely different and unrelated... Which
in the event you are trying to read an hyperblock, alloc map or other
forms of meta data, could lead to a system panic if the system believes
the FS has gone completely insane (which it could since it cannot relate
the changes made by side A).
...
ext2 and/or ext3 is (as I see it) never been designed to be used with
concurrent access in mind.

Personally, I would *NOT* tread in those waters (whatever the
architecture !)

I would strongly suggest you use a filesystem that is designed to be
accessed concurrently by multiple systems (OCFS2 maybe ?)

--Ivan

----------------------------------------------------------------------
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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to