[Lustre-devel] Commit on share

[Andreas Dilger]

On Jun 02, 2008  12:42 +0400, Alex Zhuravlev wrote:
> there was an idea to control recovery postponing replies.
> can we use this idea for COS? instead of immediate sync
> we execute request, but put reply on a special queue. then
> reply is sent from the queue when all previous transno
> are committed (for COS w/o VBR). if there is no requests to
> be handled, but reply queue isn't empty server does sync.

Yes, this was proposed for the DMU OST, so that it can export
synchronous IO semantics to clients that do not know how to do
bulk IO recovery (i.e. all of them right now) without forcing
the DMU to limit the transaction group size too much.

My proposal was that the OST service threads would perform the IO
in the normal manner until they were ready with the reply, but
instead of waiting in the thread context for the commit the RPC
request (with attached reply) would be put as private data into
a commit callback.  Once the commit callbacks are run (whether
because of transaction size, age, or explicit sync operation)
the RPC requests are put into a queue and sent by one or more
threads to the waiting clients.

This ties in fairly nicely with the network request scheduler, as
it can batch requests from the same or multiple clients in different
ways, and then "unplug" the device (sync the transaction).

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.