From owner-freebsd-hackers Tue Feb 6 10:54:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from brutus.conectiva.com.br (brutus.conectiva.com.br [200.250.58.146]) by hub.freebsd.org (Postfix) with ESMTP id 549B737B491 for ; Tue, 6 Feb 2001 10:54:05 -0800 (PST) Received: from localhost (riel@localhost) by brutus.conectiva.com.br (8.11.2/8.11.2) with ESMTP id f16IqJD27140; Tue, 6 Feb 2001 16:52:19 -0200 X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs Date: Tue, 6 Feb 2001 16:52:19 -0200 (BRDT) From: Rik van Riel X-Sender: riel@duckman.distro.conectiva To: Matt Dillon Cc: 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) In-Reply-To: <200102061839.f16Id0P63433@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 6 Feb 2001, Matt Dillon wrote: > :Reiserfs and ext3 have write-ahead logs and, AFAIK, fsync() > :will not return until there is a commit point in the log. > : > :This means that fsync() will guarantee that the transactions > :won't be unwound (unless I've overlooked some weird special > :case situations where it is needed after all...). > > Yes, I believe you are correct. I was operating under the impression > that ReiserFS had only one log, though. I have not researched EXT3 > so I can't comment on it. So if you fsync() a file under Reiser, aren't > you fsync()ing the entire filesystem? It would only need to do 2 things: 1. put a sync point in the journal, after writing all the needed data to the journal (cheap, no disk seeks involved) 2. write out the file data to the filesystem For ext3, you can either go the same way as reiserfs or you can do full data journalling. With full data journalling you will end up writing the data twice, but you can return from fsync() after having synced the data to the journal only... This decrease in latency means that for some workloads doing full data journalling could give better performance than metadata-only journalling. And then, of course, there's the option of moving the journal to a separate device. In this situation doing data journalling will almost certainly improve performance if your workload has lots of fsyncs sincy you both cut down on the seek times needed for an fsync and the "real filesystem" has more freedom to reorder the writes it does ... the data has everything needed for the last few seconds, so why worry. regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message