Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Sep 2002 21:09:47 +0200
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: Journaled filesystem in CURRENT
Message-ID:  <20020926210947.5d5fdd45.Alexander@Leidinger.net>
In-Reply-To: <3D93459B.E4405568@mindspring.com>
References:  <200209251319.g8PDJYoD047918@ib.com.ua> <20020925111232.B3686@Odin.AC.HMC.Edu> <20020926111949.5c0da160.Alexander@Leidinger.net> <20020926090325.A24614@zardoc.esmtp.org> <3D93459B.E4405568@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 26 Sep 2002 10:36:27 -0700 Terry Lambert
<tlambert2@mindspring.com> wrote:

> That said, journalling and Soft Updates are totally orthogonal
> technologies, just as btree and linear directory structures are
> two orthogonal things.
> 
> Journalling has advantages that a non-journalling FS with soft
> updates does not -- can not -- have, particularly since it is
> not possible to distinguish a power failure from a hardware
> failure from (some) software failures, and those cases need to

Power failure:
   No problem for both.
Hardware failure (I assume you think about a HDD failure):
   Read failure: doesn't matter here
   Write failure: either the sector gets remapped (no problem
                  for both), or the disk is in self destruct
                  mode (both can't cope with this)
Software failure:
   Are you talking about bugs in the FS code? Or about a nasty
   person which writes some bad data into the FS structures?

> be treated differently for the purposes of recovery.  The soft

Sorry, I don't get it. Can you please be more verbose?

> updates background recover can not do this; the foregound
> recovery can, but only if it's not the abbreviated version.  A

What are you talking about? Did you managed to get an unexpected
softupdates inconsistency after the last bugfix?

I don't see a difference in the power or hardware failure cases for a
journaled fs and SO. The only reason for a fg-fsck instead of a bg-fsck
(in the "there's no bug in the bg-fsck code path" case) is if someone
damages the fs-structures on disk (I assume there are no bugs in SO
anymore which result in an unexpected SO inconsistency).

Note: I don't think the actual code path for bg-fsck is bugfree at the
moment (read: I don't trust it at the moment).

> JFS that journals both data and metadata can recover from all
> three, to a consistant state, and one that journals only
> metadata can recover from two of them.

SO writes the data directly to free sectors in the target filesystem. I
don't see where journaled data is an improvement in fs-consistency here.

Bye,
Alexander.

-- 
                   It's not a bug, it's tradition!

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020926210947.5d5fdd45.Alexander>