From owner-freebsd-hackers  Mon Feb  7 11:38:11 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by builder.freebsd.org (Postfix) with ESMTP id 6B9A9404C
	for <hackers@FreeBSD.ORG>; Mon,  7 Feb 2000 11:38:04 -0800 (PST)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id LAA50114;
	Mon, 7 Feb 2000 11:38:43 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 7 Feb 2000 11:38:43 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200002071938.LAA50114@apollo.backplane.com>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: hackers@FreeBSD.ORG
Subject: Re: Syncing a vector of fileoffsets and lengths?
References:  <20000207114042.E25520@fw.wintelcom.net>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


: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