On 9/5/05, <b class="gmail_sendername">Stephen C. Tweedie</b> <<a href="mailto:sct@redhat.com">sct@redhat.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>On Sun, 2005-09-04 at 21:33, Pavel Machek wrote:<br><br>> > - read-only mount<br>> > - "specatator" mount (like ro but no journal allocated for the mount,<br>> >   no fencing needed for failed node that was mounted as specatator)
<br>><br>> I'd call it "real-read-only", and yes, that's very usefull<br>> mount. Could we get it for ext3, too?<br><br>I don't want to pollute the ext3 paths with extra checks for the case<br>when there's no journal struct at all.  But a dummy journal struct that
<br>isn't associated with an on-disk journal and that can never, ever go<br>writable would certainly be pretty easy to do.<br><br>But mount -o readonly gives you most of what you want already.  An<br>always-readonly option would be different in some key ways --- for a
<br>start, it would be impossible to perform journal recovery if that's<br>needed, as that still needs journal and superblock write access.  That's<br>not necessarily a good thing.<br><br>And you *still* wouldn't get something that could act as a spectator to
<br>a filesystem mounted writable elsewhere on a SAN, because updates on the<br>other node wouldn't invalidate cached data on the readonly node.  So is<br>this really a useful combination?<br><br>About the only combination I can think of that really makes sense in
<br>this context is if you have a busted filesystem that somehow can't be<br>recovered --- either the journal is broken or the underlying device is<br>truly readonly --- and you want to mount without recovery in order to<br>
attempt to see what you can find.  That's asking for data corruption,<br>but that may be better than getting no data at all.<br><br>But that is something that could be done with a "-o skip-recovery" mount<br>option, which would necessarily imply always-readonly behaviour.
<br><br>--Stephen</blockquote><div><br>
 </div>This
is getting way off-thread, but xfs does not do journal replay on
read-only mount.  This was required due to filesystem snapshots
which
are often truly read-only.  i.e. All LVM1 snapshots are truly
read-only.  Also many FC arrays support read-only snapshots as
well.<br>
<br>
I'm not sure how ext3 supports those environments  (I use XFS when I need snapshot capability).<br>
<div><br>
The above -skip-recovery option might be required?<br>
<br>
Greg</div></div>-- <br>Greg Freemyer<br>The Norcross Group<br>Forensics for the 21st Century