From owner-freebsd-current Mon Sep 21 00:56:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA22187 for freebsd-current-outgoing; Mon, 21 Sep 1998 00:56:29 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp.algonet.se (angel.algonet.se [194.213.74.112]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA22174 for ; Mon, 21 Sep 1998 00:56:25 -0700 (PDT) (envelope-from mal@algonet.se) Received: (qmail 15948 invoked from network); 21 Sep 1998 07:37:38 -0000 Received: from kairos.algonet.se (HELO kairos) (194.213.74.18) by angel.algonet.se with SMTP; 21 Sep 1998 07:37:38 -0000 Received: (mal@localhost) by kairos (SMI-8.6/8.6.12) id JAA07641; Mon, 21 Sep 1998 09:37:38 +0200 Date: Mon, 21 Sep 1998 09:37:38 +0200 Message-Id: <199809210737.JAA07641@kairos> From: Mats Lofkvist To: tlambert@primenet.com CC: freebsd-current@FreeBSD.ORG In-reply-to: <199809202009.NAA28679@usr04.primenet.com> (message from Terry Lambert on Sun, 20 Sep 1998 20:09:26 +0000 (GMT)) Subject: Re: pthreads and sync writes References: <199809202009.NAA28679@usr04.primenet.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Is it possible to do a sync write from a thread without blocking > the process completely? I have tried with open(O_FSYNC) and by > calling fsync() after writev(), but neither seem to make any other > thread runnable. The point of the system call is to block the caller until the caller is guaranteed that the cached contents of the file are the same as those on on disk (i.e., it flushes the write-through cache). Yes, but is there a way doing it without blocking the other threads in the process? E.g. doing something similiar to sync() for a single file (starting the flush) and then polling for the completion? This is a place where an async call gate would be useful. Sounds like major work :-) > Fsync()ing also seems to be sligtly faster, is this an illusion or > is there a difference in the semantics? When you write to a file with O_FSYNC, the write does not return until the data has been committed. When you write to a file without O_FSYNC and subsequently call fsync(2) on the descriptors, all dirty buffers are written to disk. As a result, the second case will give better performance if your application is such that you can do multiple writes before calling fsync(2) without sacrificing data integrity in the process. What happens is, effectively, write-gathering. I made the program call fsync after _every_ write (writev really) as an alternative to open(O_FSYNC), so there should be no difference in the amount of data written. Could there be a difference in the amount of meta-data (access times, file length, ...) written or the order they are written in (disk seeks are limiting the speed) ? Compare O_SYNC vs O_DSYNC in Solaris: I'm not sure I understand them but it looks like the former guarantees more meta-data updates being flushed ("synchronized _file_ integrity completion" vs "synchronized _data_ integrity completion"). _ Mats Lofkvist mal@algonet.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message