mount r/w and r/o

[Jeff Dinisco]

I have an ext3 filesystem mounted r/w on 1 host and r/o on multiple
hosts.  Dangerous but cost effective.  I recently implemented some
protection through a fc switch that restricts some hosts to r/o access
to the data luns.  So if someone types mount -o rw or something, all is
not lost.

The issue occurs when it's mounted r/w on 1 host and another host
attempts to mount it r/o.  The mount command takes about a minute to
complete, it successfully mounts, and several error messages are
reported...

Nov  3 12:52:26 lax kernel: EXT3-fs: INFO: recovery required on readonly
filesystem.
Nov  3 12:52:26 lax kernel: EXT3-fs: write access will be enabled during
recovery.
Nov  3 12:52:27 lax kernel: cfq: depth 4 reached, tagging now on

...reports this for about 260 different sectors (makes sense, fc switch
is preventing write access)...

Nov  3 12:52:27 lax kernel: SCSI error : <494 0 0 1> return code =
0x8000002
Nov  3 12:52:27 lax kernel: sdl: Current: sense key: Data Protect
Nov  3 12:52:27 lax kernel:     Additional sense: Logical unit software
write protected
Nov  3 12:52:27 lax kernel: end_request: I/O error, dev sdl, sector 496
Nov  3 12:52:27 lax kernel: Buffer I/O error on device sdl, logical
block 62
Nov  3 12:52:27 lax kernel: lost page write due to I/O error on sdl

then completes...

Nov  3 12:52:44 laxl kernel: EXT3-fs: recovery complete. (how???)
Nov  3 12:52:44 laxl kernel: EXT3-fs: mounted filesystem with ordered
data mode.

This also happens on other filesystems and other devices under the same
circumstances.

When the filesystem is umounted from the r/w host, it mounts w/ out
error on r/o host.  It's interesting to note that after that's done, you
can remount the filesystem on the r/w host, and then mount it on the r/o
w/ just a few errors and w/ in seconds.

My questions are...
Should I be concerned by this?
Is there a way to automatically skip the recovery attempt, and if so,
should I use it?
Am I going about this all wrong, is there a better way to do this (other
than GFS)?

Thanks.

 - Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20051103/9d2c42ce/attachment.htm>