Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Nov 1999 15:40:51 -0500
From:      Greg Lehey <grog@lemis.com>
To:        Randell Jesup <rjesup@wgate.com>, freebsd-fs@FreeBSD.ORG
Subject:   Re: journaling UFS and LFS
Message-ID:  <19991102154051.35226@mojave.sitaranetworks.com>
In-Reply-To: <ybuogdehqkc.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>; from Randell Jesup on Mon, Nov 01, 1999 at 02:51:47AM %2B0000
References:  <Pine.BSF.4.05.9910301936530.44134-100000@calis.blacksun.org> <ybuogdehqkc.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday,  1 November 1999 at  2:51:47 +0000, Randell Jesup wrote:
> Don <don@calis.blacksun.org> writes:
>>> Most corporate IT managers wouldn't know a filesystem if they were
>>> bitten by one.
>> That is absolutely the case. That is why I can not suggest that
>> softupdates is as good as a journaled file system. The people I deal with
>> at least know the buzzword and they want to make sure that whatever
>> solution they go with will have it.
>
> 	Question: is the fsck time for softupdates the same as for
> plain UFS (when it needs to fsck, which should be (much) less often,
> if I remember correctly).

My understanding is that the fsck is identical.  The only advantage
that soft updates brings is that the danger of damage is much less.

> Even the occasional long-fsck-time can be a problem for a
> high-availability production environment.

Agreed.  This is the biggest advantage of a log-based fs.

> 	Side question: why is it that there are certain errors (inode out
> of range, for example) that fsck barfs on and exits?

Because it's broken.  We should be able to recognize and fix all these
problems.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


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




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