Date: Thu, 26 Sep 2002 10:36:27 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: freebsd-current@FreeBSD.ORG Subject: Re: Journaled filesystem in CURRENT Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Claus Assmann wrote: > > > > Does CURRENT support journaled filesystem ? > > > > > > There are not journaling file systems in current at this time. > > > Efforts to port both xfs and jfs are underway. > > > > We have something better than those. SoftUpdates. Much faster than jfs > > in metadata intensive operations. > > But much slower in some other applications. > > When we tested several filesystems for mailservers (to store the > mail queue), JFS and ext3 (in journal mode) beat UFS with softupdates > by about a factor of 2. Hi Claus! Nice to hear from someone who actually tests things! I think that what you were probably testing was directory entry layout and O(N) (linear) vs. O(log2(N)+1) search times for both non-existant entries on creates, and for any entry on lookup ( / 2 on lookup) . The best answer for inbound mail is to go to per domain mail queues, and the best for outbound is to go to hashed outbound domains (as we discussed at the 2000 Sendmail MOTM gathering). Per domain mail queues inbound give you a 100% hit rate on a directory traversal for a queue flush; using hashed outbound directories isn't a 100% hit rate, but you can keep it above 85% with the right hashing structure, which makes the miss rate have only 1-2% impact on processing. 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 be treated differently for the purposes of recovery. The soft updates background recover can not do this; the foregound recovery can, but only if it's not the abbreviated version. A 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. -- Terry 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?3D93459B.E4405568>