public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dominik Kubla <kubla@sciobyte.de>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Cc: "Alexis S. L. Carvalho" <alexis@cecm.usp.br>,
	linux-kernel@vger.kernel.org
Subject: Re: implementing soft-updates
Date: Wed, 10 Apr 2002 11:28:07 +0200	[thread overview]
Message-ID: <20020410092807.GA4015@duron.intern.kubla.de> (raw)
In-Reply-To: <20020409184605.A13621@cecm.usp.br> <200204100041.g3A0fSj00928@saturn.cs.uml.edu>

On Tue, Apr 09, 2002 at 08:41:28PM -0400, Albert D. Cahalan wrote:
...
> While ext2 fsck doesn't guarantee anything, in practice it is far
> more reliable than ufs fsck. If you change the algorithms to be
> like those used by BSD, then you may lose some of the ability to
> recover. Remember, fsck isn't just for power failures. It tries
> to piece together a filesystem that has suffered disk corruption
> caused by attackers, kernel bugs, fdisk screwups, MS-DOS writing
> past the end of a partition, Windows NT Disk Manager, viruses,
> disk head crashes, and every other cause you can imagine. If you
> change fsck to make BSD-style assumptions about write ordering,
> you weaken the ability to deal with disasters.

I disagree. In fact the current  BSD softupdate code guarantees that all
that ever  happens is that  freed blocks are  not entered into  the free
block list. Something  fsck can fix in background on  a life system. See
M. Kirk McKusicks BSDcon 02 paper 'Running fsck in background.'

Your argument  that faulty hardware  may create havoc with  your on-disk
data structures  is something every  file system  is prone to  unless it
uses  a  raw-read-after-write  for checking  purposes.  Something  which
definitely kills disk performance.

The background  fsck capability, just  like journalling or  logging, are
typically only in needed in 24/7 systems (sure, they are nice to have in
your home  system, but do  you _REALLY_ need  them? i don't!)  and those
system  typically are  run on  proven  hardware which  is operated  well
within the specs. So please don't construct these kinds of arguments.

The fact that the BSD FFS in it's currently released version (which does
not include snapshot and background fsck capability) is considered to be
one of the more reliable file  systems around, even when softupdates are
enabled, speaks  for itself.  So please  just as  you don't  want horror
stories about Linux ext2 spread: don't do it yourself.

Alexis, if you're looking for a rewarding Linux project, don't focus too
much  on softupdates,  the majority  of linux  users/developers couldn't
care less.  I wonder  sometimes if  this is perhaps  because BSD  did it
first?

Read  M. Kirk  McKusick's  paper  on fsck  and  snapshots  (it's in  the
proceedings  of this  years BSDcon,  available from Usenix)  and try  to
implement the snapshot capability for  ext2/ext3. Everyone of us who has
to do live backups of production systems  will thank you if you get that
development started. I  found that Mr. McKusick is somebody  who is very
helpful towards people  trying to understand his work, so  you might get
help  from  him  if you  get  stuck.  OTOH  if  you avoid  the  buzzword
'softupdates' many Linux file system  hackers will be much more inclined
to help you out with the Linux part.

Yours,
  Dominik Kubla
-- 
"Those who would give up essential Liberty to purchase a little
temporary Safety deserve neither Liberty nor Safety." (Benjamin Franklin)

  parent reply	other threads:[~2002-04-10  9:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-09 21:46 implementing soft-updates Alexis S. L. Carvalho
2002-04-09 22:17 ` Mike Fedyk
2002-04-09 22:23   ` Dominik Kubla
2002-04-09 23:36     ` Mike Fedyk
2002-04-10  0:41 ` Albert D. Cahalan
2002-04-10  1:58   ` Alexis S. L. Carvalho
2002-04-10  3:46     ` Andreas Dilger
2002-04-10  2:55   ` Andreas Dilger
2002-04-10 11:48     ` Peter Wächtler
2002-04-11 12:45     ` Bill Davidsen
2002-04-10  9:28   ` Dominik Kubla [this message]
2002-04-10 18:07     ` Albert D. Cahalan
2002-04-08 20:34       ` Pavel Machek
2002-04-10 18:13     ` Andreas Dilger
     [not found] <20020409184605.A13621@cecm.usp.br.suse.lists.linux.kernel>
     [not found] ` <200204100041.g3A0fSj00928@saturn.cs.uml.edu.suse.lists.linux.kernel>
     [not found]   ` <20020410092807.GA4015@duron.intern.kubla.de.suse.lists.linux.kernel>
2002-04-10 19:24     ` Andi Kleen
2002-04-08 20:35       ` Pavel Machek
2002-04-15 20:25         ` Andi Kleen
2002-04-15 20:47         ` Andreas Dilger
2002-04-16 10:45         ` Wichert Akkerman
2002-04-16 18:55           ` Mike Fedyk
  -- strict thread matches above, loose matches on Subject: below --
2002-04-11 16:35 James Bottomley

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=20020410092807.GA4015@duron.intern.kubla.de \
    --to=kubla@sciobyte.de \
    --cc=acahalan@cs.uml.edu \
    --cc=alexis@cecm.usp.br \
    --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