Date: Mon, 7 Feb 2000 11:38:43 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: hackers@FreeBSD.ORG Subject: Re: Syncing a vector of fileoffsets and lengths? Message-ID: <200002071938.LAA50114@apollo.backplane.com> References: <20000207114042.E25520@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:Is it possible to submit several offsets of a file to be synced
:rather than calling fsync or mmap'ing over the file and calling
:msync()?
:
:The only way I can think of doing this is queuing write requests
:backed by a O_FSYNC fd to an aiod.
:
:Even then the desired result isn't really achived as instead of
:all the buffers being simultaniously queued for immediate IO
:the aiod will stall on each buffer.
:
:Is there a better way to submit multiple buffers for immediate
:sync without syncing the entire file?
There is no way to do this currently.
:It seems that msync with MS_ASYNC would work (a bit kludgy), but
:it's not implemented according to the manpage.
:
:thanks,
:--
:-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
The man page is wrong. It is implemented, but it doesn't guarentee
that metadata will be written nor does it guarentee the timing of
the data writes.
I have long considered this problem. NFSv3 needs to be able to do
ranged fsyncs to handle the commit RPC. It used to just fysnc the
whole file (bad). Now it has a kludge to scan the buffers and
write out the appropriate ones, which is better. However, it has
the same problem that msync() has when doing a ranged sync - the
metadata is not guarenteed. (When you do a normal fsync() the
meta-data is guarenteed, even in the softupdates case).
Only minor adjustments are required to brute-force the metadata, and
a couple more adjustments to make it work properly with softupdates.
Once I do this we can break the code out into its own system call.
fsync2(fd, options, offset, size) ???
degenerate case would sync to the EOF if size == 0.
synchronously fsyncs by default, FSYNC_ASYNC would run it
asynchronously.
You could async fsync it, then fsync it normally later on to
make sure it has all gone out.
We would also have to make a new VOP to do it, VOP_FSYNC2(), which
would default to calling VOP_FSYNC() with a 0 offset and 0 size.
I've been wanting to do this for a while. There are a huge number
of uses for this sort of system call, including database apps and
two of my own projects. I'm waiting till after the release before
starting work on it.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200002071938.LAA50114>