From: J. Bruce Fields (bfields@fieldses.org)
Date: 05/31/02-11:25:11 AM Z
Date: Fri, 31 May 2002 12:25:11 -0400
Subject: Re: Replication/Migration conference call minutes, 5/29
Message-ID: <20020531162511.GA17121@fieldses.org>
From: "J. Bruce Fields" <bfields@fieldses.org>
On Thu, May 30, 2002 at 10:16:41AM -0600, Robert Thurlow wrote:
>
> - Some discussion about encoding of attributes led to a
> consensus that we should try to re-use as much from NFSv4
> as we could; for example, there was no reason to invent a
> new way to express directories when the XDR encoding for
> READDIR was available. Some asked how much different the
> repl-mig protocol had to be than "one long compound op";
> we agreed that there were differences, and that in some
> cases e.g. read-only attributes, we would have to do some
> things that could not be done with NFSv4 ops.
If you're moving something from a source to a target, then wouldn't it
make more sense for the target to do reads and gettattrs and such, instead
of the source doing writes and setattrs?
What's wrong with the following as a migration protocol: Given a source
machine with a directory tree that we want to move to a target machine:
1. The target machine mounts the directory tree from
the source.
2. The target machine then exports this same tree. At
this point, the target is just another client to
the source machine, but can also serve the same
tree to other clients.
3. The target machine tells the source that it wants
to take over.
4. The source machine then starts sending
NFS4ERR_MOVED in response to any further requests,
except for requests coming from the target, which
the source continues to process normally.
So now the clients of the source have all become clients of the target,
and the target is a client of the source. The target could just do the
equivalent of a "cp -a" at this point to move the data from the source,
probably dropping requests from the clients in the meantime, or it could
choose to only make the requests to the source that it needs to make in
order to service incoming client requests. If it was smart, it would
probably do some combination of the two.
No additional protocol is required here, except maybe a single extra RPC
at step 3. This doesn't solve the problem of transferring state, but
no-one knows how to solve that problem anyway right now. As a first
attempt, we've said we're content with migrations that look to clients
like server reboots.
Maybe there are obvious problems with this. But if someone could point
out those problems, maybe that would help me understand better why we
need an entirely separate protocol to do migration, and what features
such a protocol must have if we do need one.
--Bruce Fields (@citi.umich.edu)
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:47 AM Z CST