Subject: Replication and Migration - summary so far

From: Robert Thurlow <[email-masked]>
Date: Mon, 24 Sep 2001 21:46:57 -0600 (MDT)

Below is an attempt to summarize the discussion so far regarding
the next phase of work for NFSv4 replication and migration.  We
have a few decisions to make about what direction we want to take
with this work, and I hope people will take some time to give
feedback on these areas.

First, to clarify what I think we are doing:

We want to create a new protocol which servers can use to transfer
and maintain replicas of NFSv4 filesystems, or to migrate NFSv4
filesystems from one server to another.  The protocol should likely
have most of the following attributes: heterogeneous, correct, fast,
secure, and bandwidth efficient.

Question to the WG: how many people out there are interested
in this area of effort?  To the vendors who have homogeneous
features in this area, does this seem like a good thing?

As we have discussed this, some issues and disagreements have
popped up.  Here's what I have seen:

Delegation and lock state
Migration of a read-write filesystem needs either to transfer
state for current delegations and locks or ensure that such
state does not exist when the transfer starts.  This is seen
as difficult to do, so some want to ignore this for now and
focus on what we need to make read-only replication work well.
Compromises might be to leave a place holder in the protocol
for this unique metadata and define how it is to be handled
later, or to make this a SHOULD in the protocol.

Question to the WG: how important does it seem to you to
solve this problem?  Does either compromise work for you?

NFSv4-specific vs. generic
Brian's original work had some language that this would not
be a general purpose replication protocol for use with older
versions of NFS and with CIFS, but others want exactly that
sort of capability.  It does seem that without knowing some
intimate things about NFSv4 metadata, the protocol cannot
truly transfer filesystems with the degree of correctness
desired.

Spencer Shepler suggested what I think is an excellent way
to handle this: that rather than putting core knowledge of
NFSv4 into the replication/migration protocol, we define a
series of protocol-specific "attachments" which contain the
details of how metadata looks, and make the first attachment
for NFSv4, able to use NFSv4 definitions.

Question to the WG: does this kind of layering make sense?

Capability negotiation
Brian's original talks had a negotiation phase between the
peers of a filesystem transfer so that the sender can know
any impairments before starting an initial transfer and
warn an admin or bail out.   Some weren't sure this was
necessary.  But Dave Noveck wrote a good argument for this,
stating that portable programs often try to learn their
environments before doing serious work, and that losing
an extended attribute after a migration event would be a
very bad thing.

Question to the WG: do we need capability negotiation?

We also have some things that seem to be accepted based on
the amount of attention paid to them so far.  I think the
following are not in much dispute; please argue with me if
you disagree:

- it is OK for the replication/migration protocol to not be
  based on RPC
- it is OK for the replication/migration protocol to be able
  to rely on transport-level security (e.g. IPSEC)
- it is likely interesting to use the "rsync" algorithm to
  transfer replicas in some cases, though there will be
  cases where we have, and should use, better information
  from the filesystem
- resource discovery (how the client finds the filesystems
  to use) is impacted by replication and migration, but is
  not part of this solution space
- multiple writable copies and disconnected operation are
  not in scope

Comments?

Rob T