From: Daniel Phillips <phillips@innominate.de>
To: Alex Belits <abelits@phobos.illtel.denver.co.us>,
linux-kernel@vger.kernel.org
Subject: Re: Journaling: Surviving or allowing unclean shutdown?
Date: Thu, 04 Jan 2001 09:00:06 +0100 [thread overview]
Message-ID: <3A542D86.BADE2D36@innominate.de> (raw)
In-Reply-To: <3A5352ED.A263672D@innominate.de> <Pine.LNX.4.20.0101030838350.13243-100000@phobos.illtel.denver.co.us>
Alex Belits wrote:
>
> On Wed, 3 Jan 2001, Daniel Phillips wrote:
>
> > I don't doubt that if the 'power switch' method of shutdown becomes
> > popular we will discover some applications that have windows where they
> > can be hurt by sudden shutdown, even will full filesystem data state
> > being preserved. Such applications are arguably broken because they
> > will behave badly in the event of accidental shutdown anyway, and we
> > should fix them. Well-designed applications are explicitly 'serially
> > reuseable', in other words, you can interrupt at any point and start
> > again from the beginning with valid and expected results.
>
> I strongly disagree. All valid ways to shut down the system involve
> sending SIGTERM to running applications -- only broken ones would
> live long enough after that to be killed by subsequent SIGKILL.
>
> A lot of applications always rely on their file i/o being done in some
> manner that has atomic (from the application's point of view) operations
> other than system calls -- heck, even make(1) does that.
Nobody is forcing you to hit the power switch in the middle of a build.
But now that you mention it, you've provided a good example of a broken
application. Make with its reliance on timestamps for determining build
status is both painfully slow and unreliable. What happens if you
adjust your system clock? That said, Tux2 can preserve the per-write
atomicity quite easily, or better, make could take advantage of the new
journal-oriented transaction api that's being cooked up and specify its
requirement for atomicity in a precise way.
Do you have any other examples of programs that would be hurt by sudden
termination? Certainly we'd consider a desktop gui broken if it failed
to come up again just because you bailed out with the power switch
instead of logging out nicely.
--
Daniel
-
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/
next prev parent reply other threads:[~2001-01-04 8: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 [this message]
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
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=3A542D86.BADE2D36@innominate.de \
--to=phillips@innominate.de \
--cc=abelits@phobos.illtel.denver.co.us \
--cc=linux-kernel@vger.kernel.org \
/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