Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Aug 95 12:15:54 MDT
From:      terry@cs.weber.edu (Terry Lambert)
To:        hsu@cs.hut.fi (Heikki Suonsivu)
Cc:        freebsd-hackers@freefall.FreeBSD.org
Subject:   Re: Making a FreeBSD NFS server
Message-ID:  <9508221815.AA00955@cs.weber.edu>
In-Reply-To: <199508220517.IAA01893@shadows.cs.hut.fi> from "Heikki Suonsivu" at Aug 22, 95 08:17:53 am

next in thread | previous in thread | raw e-mail | index | archive | help
>    Correct my previous post to say "don't enable async writes, ever, it's
>    not worth it (unless you have a UPS on your server).
> 
> It still could be fixed (-o async does not seem to do anything now).  It is
> somewhat annoying to, say, copy a news file system to another disk.  I
> couldn't care less if I would have to newfs the whole target in case of
> panic or power hick-up during the copy.

Different "async".  The "-o async" makes metadata writes occur
asynchronously instead of in compliance with POSIX semantics.  The
NFS async option, if implemented on a per FS basis, causes the
server to return "write complete" to the client so that the top
level caller's 'write(2)' call returns sooner.  Even though in
doing that, it risks data integrity.

Or more simply:

	-o async	Risk referential integrity
	NFS_ASYNC	Risk data integrity

To fix this, I think you'd need to implement VOP_SYNC in an NFS
using the NFS_ASYNC to go out to the server and ensure pending
writes have all completed.  Since it's impossible for the writes
to have *not* completed in a strictly conforming implementation,
this is a near impossibility.

That doesn't mean that it wouldn't be useful in copying large volumes
of data -- we are talking 6-7 times the write speed.  Just you'd need
to then go to the local system that's exporting the volume and do your
sync there.

The same effect can be had by writing the file using a 'team' or 'ddd'
multiple writer approach, without using async.  The point, after all,
is to interleave the I/O.  NFS_ASYNC just does the interleaving in
the NFS implementation rather than user space.

Really, a threaded libc would have exactly the same effect on ALL I/O
instead of just NFS I/O.  Spawn a thread per write request up to some
limit on thread-count, and do itc (inter thread communication) ala
team or ddd to order the writes, and voila.

One thread environment for implementing this would be the Sun LWP
environment -- which is implemented using async I/O.


					Regards,
					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508221815.AA00955>