From owner-freebsd-hackers Tue Feb 6 12:20:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 5C24E37B491 for ; Tue, 6 Feb 2001 12:20:40 -0800 (PST) Received: (qmail 13512 invoked from network); 6 Feb 2001 20:17:28 -0000 Received: from unknown (HELO monzoon.net) ([195.134.133.140]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 6 Feb 2001 20:17:28 -0000 Message-ID: <3A805C4B.A200EA28@monzoon.net> Date: Tue, 06 Feb 2001 21:19:23 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: Mike Silbersack , Rik van Riel , Poul-Henning Kamp , Charles Randall , Dan Phoenix , Alfred Perlstein , Jos Backus , freebsd-hackers@FreeBSD.ORG Subject: Re: soft updates and qmail (RE: qmail IO problems) References: <200102061759.f16Hxv662437@earth.backplane.com> <3A805137.230E0A0D@monzoon.net> <200102061956.f16JuCb65538@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > : > :This information is in fact correct. Have a look at the FreeBSD link(2) > :man page: > : > :LINK(2) FreeBSD System Calls Manual > :LINK(2) > > Andre, I think there *might* be a dozen people in the world that > understand UFS/FFS better then I do, but none of them have posted to > this thread. > > Believe me when I say that there is no metadata ordering guarentee > in the case of a crash. Yes a standard UFS/FFS will do synchronous > metadata updates for certain operations. No, this does not guarentee > metadata ordering. OK, then I believe you. But please answer me one question: Is the link() call atomically in FFS/UFS w or w/o softupdates? Meaning when the call returns the meta- data is written to stable storage like with fsync()? Only this answer is needed for qmail operation. -- Andre > There has been talk of providing system calls to allow user programs > to request ordering semantics for certain operations, but nobody has > actually implemented anything. Most of the discussion has been centered > on having calls to guarentee file write ordering between a set of > open descriptors for databases. > > As I said, a journaled filesystem can theoretically make metadata > ordering guarentees, but actually doing so creates massive performance > and scaleability issues that aren't apparent until you really start > pounding the filesystem. It *CAN* be done efficiently, but only if > you have a significant amount of non-volatile memory store to hold > the journal. ReiserFS might do it right now, as a side effect, but if > it does it faces serious scaleability issues. > > Softupdates can also theoretically order [meta]data, using dependancies. > It is a very difficult problem to solve and it doesn't do it now. All > softupdates does is guarentee filesystem consistency in the case of a > crash and certain guarentees for what will be crash-recoverable when you > do an fsync(). > > -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message