Date: Fri, 27 Sep 2002 02:21:27 -0700 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Dan Nelson <dnelson@allantgroup.com>, brooks@one-eyed-alien.net, toha@ib.com.ua, freebsd-current@FreeBSD.ORG Subject: Re: Journaled filesystem in CURRENT Message-ID: <20020927092127.GA1340@HAL9000.homeunix.com> In-Reply-To: <20020926182319.68907194.Alexander@Leidinger.net> References: <200209251319.g8PDJYoD047918@ib.com.ua> <20020925111232.B3686@Odin.AC.HMC.Edu> <20020926111949.5c0da160.Alexander@Leidinger.net> <20020926155218.GA67579@dan.emsphone.com> <20020926182319.68907194.Alexander@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Alexander Leidinger <Alexander@Leidinger.net>:
> On Thu, 26 Sep 2002 10:52:18 -0500 Dan Nelson <dnelson@allantgroup.com>
> wrote:
>
> > > We have something better than those. SoftUpdates. Much faster than
> > > jfs in metadata intensive operations.
> >
> > If you can stand the 20 minutes of severly degraded performance while
> > the background fsck runs after a crash, and the loss of any files
>
> Sometimes it's better to have 20 minutes (or how long it takes to do the
> bg-fsck on your FS) degraded performance, than no performance at all
> (you can have this too, just configure the system to make an fg-fsck
> instead of a bg-fsck)... (how long does it take to check the journal and
> to do some appropriate actions depending on the journal?)
A journalling FS is slightly slower in day-to-day ``everything
works'' operation because all metadata is written twice. However,
it can recover from a crash with less work, because all it needs
to do is commit the operations in the log following the last
checkpoint. It doesn't have to look at every cylinder group to
figure out exactly where it might have been interrupted.
The speed at which background fsck operates should be tunable. If
you're willing to allow it to take a really long time, you can
make its impact on the system minimal. I think Kirk's paper on
the topic discusses a way of moderating its speed automatically,
but I forget the details.
> > created up to 30 seconds (by default) before the crash.
>
> There's no guarantee with a journaled fs, that the data before the crash
> is on the disk. A journaled fs is in the same boat with SO here.
Any service that really cares about its data being committed to
stable storage should use fsync(2). Mail servers do this, for
example[1]. If the filesystem implements fsync correctly, then
there is no additional risk. If you don't use fsync, you can lose
data in a crash with journalling or softupdates, but the metadata
will make it to disk sooner with journalling.
[1] I'm not so sure about qm***. DJB seems to think that anything
but sync mounts are unreliable for mail, so maybe he expects
that fsync(2) is broken on these filesystems and therefore doesn't
use it.
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?20020927092127.GA1340>