Re: Re: GFS, what's remaining

[Greg Freemyer <greg.freemyer@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2377 bytes --]

On 9/5/05, Stephen C. Tweedie <sct@redhat.com> wrote:
> 
> Hi,
> 
> On Sun, 2005-09-04 at 21:33, Pavel Machek wrote:
> 
> > > - read-only mount
> > > - "specatator" mount (like ro but no journal allocated for the mount,
> > > no fencing needed for failed node that was mounted as specatator)
> >
> > I'd call it "real-read-only", and yes, that's very usefull
> > mount. Could we get it for ext3, too?
> 
> I don't want to pollute the ext3 paths with extra checks for the case
> when there's no journal struct at all. But a dummy journal struct that
> isn't associated with an on-disk journal and that can never, ever go
> writable would certainly be pretty easy to do.
> 
> But mount -o readonly gives you most of what you want already. An
> always-readonly option would be different in some key ways --- for a
> start, it would be impossible to perform journal recovery if that's
> needed, as that still needs journal and superblock write access. That's
> not necessarily a good thing.
> 
> And you *still* wouldn't get something that could act as a spectator to
> a filesystem mounted writable elsewhere on a SAN, because updates on the
> other node wouldn't invalidate cached data on the readonly node. So is
> this really a useful combination?
> 
> About the only combination I can think of that really makes sense in
> this context is if you have a busted filesystem that somehow can't be
> recovered --- either the journal is broken or the underlying device is
> truly readonly --- and you want to mount without recovery in order to
> attempt to see what you can find. That's asking for data corruption,
> but that may be better than getting no data at all.
> 
> But that is something that could be done with a "-o skip-recovery" mount
> option, which would necessarily imply always-readonly behaviour.
> 
> --Stephen


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.

I'm not sure how ext3 supports those environments (I use XFS when I need 
snapshot capability).

The above -skip-recovery option might be required?

Greg
-- 
Greg Freemyer
The Norcross Group
Forensics for the 21st Century

[-- Attachment #1.2: Type: text/html, Size: 2847 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]