public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stefan Traby <stefan@hello-penguin.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Stefan Traby <stefan@hello-penguin.com>,
	Daniel Phillips <phillips@innominate.de>,
	Rik van Riel <riel@conectiva.com.br>,
	linux-kernel@vger.kernel.org
Subject: Re: Journaling: Surviving or allowing unclean shutdown?
Date: Fri, 5 Jan 2001 02:01:37 +0100	[thread overview]
Message-ID: <20010105020137.A1396@stefan.sime.com> (raw)
In-Reply-To: <Pine.LNX.4.30.0101031253130.6567-100000@springhead.px.uk.com> <Pine.LNX.4.21.0101031325270.1403-100000@duckman.distro.conectiva> <3A5352ED.A263672D@innominate.de> <20010104192104.C2034@redhat.com> <20010104220821.B775@stefan.sime.com> <20010104224946.C1290@redhat.com>
In-Reply-To: <20010104224946.C1290@redhat.com>; from sct@redhat.com on Thu, Jan 04, 2001 at 10:49:46PM +0000

On Thu, Jan 04, 2001 at 10:49:46PM +0000, Stephen C. Tweedie wrote:
> > I think any other action (only replaying on rw mount and presenting
> > a broken filesystem on ro) is quite fatal, at least if I think of
> > a replay on -remount,rw :)
> 
> Correct.
> 
> > Also, an unconditional hidden replay even if "ro" is specified is not nice.
> 
> > This is especially critical on root filesystem
> 
> In what way?  A root fs readonly mount is usually designed to prevent
> fsck can run without the filesystem being volatile.  That's the only

There are people out that say that readonly mount was
initially designed to behave as physically read only.
fsck was a wanted side-effect...
And trust me, most people think so before dialing
with a journaled filesystem. This was discussed
to death on the reiserFS list.

Clearly the definition of "ro" is weak, does it mean media or
filesystem view ? It's even weak on lower levels: There are
also disks out there that write even if physical write-protection
is enabled (for example auto-remapping after an ECC-recovery read).

Anyway, it is "especially" critical on the root filesystem because the
authors of filesystems can't support two ro states on boot.

Reiserfs allowed  -oro,noreplay.

Please tell me how to specify "noreplay" for the initial "/" mount
:)

Yes, I think that the journal is an integral part of the filesystem.
But this has nothing to do with forcing a write on "ro" mounts, which
I interpret as design bug. (ro,noreplay is also a kind of design bug,
everything except a virtual replay under physical ro conditions looks
like a design bug to me because it breaks user expectations either
by writing on "ro" or by giving an invalid view by "noreplay")

-- 

  ciao - 
    Stefan

"     ( cd /lib ; ln -s libBrokenLocale-2.2.so libNiedersachsen.so )     "
    
Stefan Traby                Linux/ia32               fax:  +43-3133-6107-9
Mitterlasznitzstr. 13       Linux/alpha            phone:  +43-3133-6107-2
8302 Nestelbach             Linux/sparc       http://www.hello-penguin.com
Austria                                    mailto://st.traby@opengroup.org
Europe                                   mailto://stefan@hello-penguin.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2001-01-05  1:03 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-03 12:55 Journaling: Surviving or allowing unclean shutdown? Dr. David Gilbert
2001-01-03 15:26 ` Rik van Riel
2001-01-03 15:38   ` Michael Rothwell
2001-01-03 16:18   ` Andi Kleen
2001-01-03 16:27   ` Daniel Phillips
2001-01-03 16:42     ` Alex Belits
2001-01-04  8:00       ` Daniel Phillips
2001-01-04 17:39         ` Alex Belits
2001-01-03 18:52     ` Dr. David Gilbert
2001-01-04  9:57       ` Helge Hafting
2001-01-04 10:14         ` Daniel Phillips
2001-01-04 10:25           ` David Woodhouse
2001-01-04 17:43           ` David Lang
2001-01-04 17:52             ` David Woodhouse
2001-01-04 18:00               ` David Lang
2001-01-04 18:11                 ` Alan Cox
2001-01-05  4:12                   ` Chipzz
2001-01-05  4:18                     ` Alan Cox
2001-01-05 16:55                   ` Mike Touloumtzis
2001-01-05 16:57                   ` David Woodhouse
2001-01-05 22:09                 ` Pavel Machek
2001-01-04 17:59             ` Alan Cox
2001-01-04 18:10               ` Chris Wedgwood
2001-01-04 18:15                 ` Mo McKinlay
2001-01-04 18:19                   ` David Lang
2001-01-04 18:20                     ` Mo McKinlay
2001-01-04 19:42                       ` Richard B. Johnson
2001-01-04 20:31                         ` egger
2001-01-04 20:59                           ` Richard B. Johnson
2001-01-04 21:05                             ` egger
2001-01-04 22:45                             ` Erik Mouw
2001-01-04 18:23                   ` Chris Wedgwood
2001-01-05 12:04                   ` David Woodhouse
2001-01-04 18:21               ` Dr. David Gilbert
2001-01-04 18:11             ` Mo McKinlay
2001-01-04 21:00         ` Brett G. Person
2001-01-05 22:05         ` Pavel Machek
2001-01-04 19:21     ` Stephen C. Tweedie
2001-01-04 21:08       ` Stefan Traby
2001-01-04 22:49         ` Stephen C. Tweedie
2001-01-05  1:01           ` Stefan Traby [this message]
2001-01-05  8:10             ` Andreas Dilger
2001-01-05 11:05             ` Stephen C. Tweedie
2001-01-05 11:58         ` David Woodhouse
2001-01-06 19:57           ` Marc Lehmann
2001-01-06 20:09             ` Stefan Traby
2001-01-06 20:35               ` Chris Mason
2001-01-06 21:49                 ` Marc Lehmann
2001-01-08 12:02             ` Stephen C. Tweedie
2001-01-09  9:34               ` Roger Gammans
2001-01-05  0:31       ` Daniel Phillips
2001-01-05  8:00         ` Andreas Dilger
2001-01-05 12:46           ` Alan Cox
2001-01-05 12:59             ` Chris Wedgwood
2001-01-05 13:22             ` Stephen C. Tweedie
2001-01-05 10:31         ` Stephen C. Tweedie
     [not found] <fa.e3022cv.v2ucim@ifi.uio.no>
     [not found] ` <fa.naq8vev.74ai08@ifi.uio.no>
2001-01-04 22:38   ` Dan Maas
  -- strict thread matches above, loose matches on Subject: below --
2001-01-08 23:19 Bernd Eckenfels

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010105020137.A1396@stefan.sime.com \
    --to=stefan@hello-penguin.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@innominate.de \
    --cc=riel@conectiva.com.br \
    --cc=sct@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox