Date: Mon, 21 Sep 1998 09:37:38 +0200 From: Mats Lofkvist <mal@algonet.se> To: tlambert@primenet.com Cc: freebsd-current@FreeBSD.ORG Subject: Re: pthreads and sync writes Message-ID: <199809210737.JAA07641@kairos> In-Reply-To: <199809202009.NAA28679@usr04.primenet.com> (message from Terry Lambert on Sun, 20 Sep 1998 20:09:26 %2B0000 (GMT)) References: <199809202009.NAA28679@usr04.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809210737.JAA07641>