From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Freemyer Subject: Re: Re: GFS, what's remaining Date: Mon, 5 Sep 2005 12:41:03 -0400 Message-ID: <87f94c3705090509411af94019@mail.gmail.com> References: <20050901104620.GA22482@redhat.com> <20050901035939.435768f3.akpm@osdl.org> <1125586158.15768.42.camel@localhost.localdomain> <20050901132104.2d643ccd.akpm@osdl.org> <20050903051841.GA13211@redhat.com> <20050904203344.GA1987@elf.ucw.cz> <1125917048.1910.9.camel@sisko.sctweedie.blueyonder.co.uk> Reply-To: linux clustering Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0497222381==" Cc: Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel , Alan Cox Return-path: To: linux clustering In-Reply-To: <1125917048.1910.9.camel@sisko.sctweedie.blueyonder.co.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-cluster-bounces@redhat.com Errors-To: linux-cluster-bounces@redhat.com List-Id: linux-fsdevel.vger.kernel.org --===============0497222381== Content-Type: multipart/alternative; boundary="----=_Part_3948_25644443.1125938463587" ------=_Part_3948_25644443.1125938463587 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 9/5/05, Stephen C. Tweedie wrote: >=20 > Hi, >=20 > On Sun, 2005-09-04 at 21:33, Pavel Machek wrote: >=20 > > > - 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? >=20 > 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. >=20 > 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. >=20 > 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? >=20 > 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. >=20 > But that is something that could be done with a "-o skip-recovery" mount > option, which would necessarily imply always-readonly behaviour. >=20 > --Stephen This is getting way off-thread, but xfs does not do journal replay on=20 read-only mount. This was required due to filesystem snapshots which are=20 often truly read-only. i.e. All LVM1 snapshots are truly read-only. Also=20 many FC arrays support read-only snapshots as well. I'm not sure how ext3 supports those environments (I use XFS when I need=20 snapshot capability). The above -skip-recovery option might be required? Greg --=20 Greg Freemyer The Norcross Group Forensics for the 21st Century ------=_Part_3948_25644443.1125938463587 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 bu= t no journal allocated for the mount,
> >   no fencing n= eeded for failed node that was mounted as specatator)
>
> I'd call it "real-read-only", and yes, that's ve= ry usefull
> mount. Could we get it for ext3, too?

I don't wan= t 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 gowritable would certainly be pretty easy to do.

But mount -o readonl= y 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 ge= t something that could act as a spectator to
a filesystem mounted writable elsewhere on a SAN, because updates on th= e
other node wouldn't invalidate cached data on the readonly node. =  So is
this really a useful combination?

About the only comb= ination I can think of that really makes sense in
this context is if you have a busted filesystem that somehow can't berecovered --- either the journal is broken or the underlying device istruly readonly --- and you want to mount without recovery in order to
attempt to see what you can find.  That's asking for data corrupt= ion,
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<= br>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 n= eed snapshot capability).

The above -skip-recovery option might be required?

Greg
--
Greg Freemyer
The Norcross Group
Forensics for= the 21st Century ------=_Part_3948_25644443.1125938463587-- --===============0497222381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0497222381==--