From owner-freebsd-hackers Tue Feb 6 12:31:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B5E4337B503 for ; Tue, 6 Feb 2001 12:30:53 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f16KRot23065; Tue, 6 Feb 2001 12:27:50 -0800 (PST) Date: Tue, 6 Feb 2001 12:27:50 -0800 From: Alfred Perlstein To: Matt Dillon Cc: Andre Oppermann , Rik van Riel , Mike Silbersack , Poul-Henning Kamp , Charles Randall , Dan Phoenix , Jos Backus , freebsd-hackers@FreeBSD.ORG Subject: Re: soft updates and qmail (RE: qmail IO problems) Message-ID: <20010206122750.T26076@fw.wintelcom.net> References: <3A805035.C71AAD5E@monzoon.net> <200102061943.f16Jhp365113@earth.backplane.com> <3A805938.96ED890D@monzoon.net> <200102062018.f16KIdx66146@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102062018.f16KIdx66146@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Feb 06, 2001 at 12:18:39PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matt Dillon [010206 12:19] wrote: > :> banging on unrelated areas of the filesystem in parallel, and an > :> fsync() of one descriptor would have to wait for the entire filesystem > :> to reach a synchronization point to guarentee metadata update ordering. > :> This creates a serious scaleability issue within a filesystem! > : > :Yes, my understanding of the meaning of "ordered meta-date update" as > :I have grasped it from Terry's rants in the past years is not that all > :meta-data updates on a filesystem have to be done one-after-the-other > :but ordered in respect to each other; That a link() happens before a > :unlink() on the same file. Does this make sense? > > If you link() in directory A and unlink() in directory B, you are not > guarenteed that the link in A will sync to the disk before the unlink > in B with regards to a crash occuring. I dont' think the "link() in directory A" syscall will return until it is sync'd (noasync UFS/FFS)! Therefore the unlink() can't happen unless it's being done by another process. Yes, other activity in the same dir can cause corruption, but meta data updates are done via sync writes that won't return until they are complete. Except for corruption, they are ordered. Since you can't IPC during a syscall reliably (you can't signal before because then you have a race, and you can't signal during because the kernel has a grip on your context) they are ordered when related. -- -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