Date: Tue, 6 Feb 2001 12:01:48 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Matt Dillon <dillon@earth.backplane.com> Cc: Andre Oppermann <oppermann@monzoon.net>, Mike Silbersack <silby@silby.com>, Rik van Riel <riel@conectiva.com.br>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Charles Randall <crandall@matchlogic.com>, Dan Phoenix <dphoenix@bravenet.com>, Jos Backus <josb@cncdsl.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: soft updates and qmail (RE: qmail IO problems) Message-ID: <20010206120148.R26076@fw.wintelcom.net> In-Reply-To: <200102061956.f16JuCb65538@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Feb 06, 2001 at 11:56:12AM -0800 References: <Pine.BSF.4.31.0102061149180.14899-100000@achilles.silby.com> <200102061759.f16Hxv662437@earth.backplane.com> <3A805137.230E0A0D@monzoon.net> <200102061956.f16JuCb65538@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Since I'm still being cc'd on this... :) * Matt Dillon <dillon@earth.backplane.com> [010206 11:56] 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. It does if it's a single threaded process doing the updates, or the IPC doesn't allow one process to proceed until the first initiated call is complete. > 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. Sort of like process groups, a process can join in an IO-group and have all journal entries tagged as belonging to the group, when an fsync is done (or maybe fsync_ioid()) all those tagged entries can be flushed. It's not that hard, it just takes some time. You also have to deal with overlap, by either forcing a sync op, or allowing IO-groups to be mixed creating dependancies where if IO-group 1 calls fsync, it can't return until IO-group 2 is done. You then generate a new generation count for each IO-group involved in the fsync. well maybe. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010206120148.R26076>