From: Robert Thurlow (Robert.Thurlow@eng.sun.com)
Date: 08/16/01-12:24:45 PM Z
Date: Thu, 16 Aug 2001 11:24:45 -0600 (MDT)
From: Robert Thurlow <Robert.Thurlow@eng.sun.com>
Subject: Replication and migration requirements
Message-ID: <Roam.SIMC.2.0.6.997982685.24335.thurlow@jurassic.eng>
In his minutes from the NFSv4 WG at IETF 51, Brent Callaghan wrote:
> Brian summarized the aims of the replication and migration work:
> Transparent, client failover for read-only replicas, good
> performance across low bandwidth links, and security as good as v4.
I'd like to spark some discussion about the requirements for
replication and migration. Here are the requirements Brian
Pawlowski presented at IETF 49, lifted from:
http://playground.sun.com/pub/nfsv4/presentations/ietf49/beepy2.pdf
They're a fairly large set, and I'd like to find out who cares
about which parts. For that matter, I'd like to find out who
cares about replication and migration; this topic has not drawn
a lot of comments on the alias in quite a long time. I'll also
include Brian's listing of issues.
Requirements
o Transparent client failover
o For read-only replicas and migrated writable volumes
o Performance
o Bandwidth conservative
o Differences propagated
o Restartable
o Client lockout time minimized
o Security
o As good as V4
o Scalable
o Huge file systems
o Small file s ystems
o Capability negotiation between "peers"(?)
o I believe this referred to things like attribute differences
o Efficient multi-way replication (propagation)
o Correctness
o "Atomic" propagation of file system from client view
o Failover to a correct replica version
o TCP/ IP based
o No legacy UDP requirement
Issues
o Replica versioning non-existent
o Failing over to "correct" version of replica impossible?
o Base V4 protocol change?
o Proposal: Investigate versioning requirement
o Single vs. multi-master
o Multi-master entails conflict resolution
o Proposal: Single master copy sufficient - objections?
o Disconnected operation irrelevant
o Corollary to above
o Proposal: Disconnected operation for clients not required - objections?
o File oriented
o Fits with NFS model, and heterogeneous
o Efficiency concerns
o Block-oriented not heterogeneous
o Proposal: Draft proposal for comments.
o Replicating "opaque" (to NFS) local file system attributes
o Proposal: NFS Version 4 named attributes propagated - unsupported
attributes not
o Migration/replication only for V4
o Not a general (rdist) mechanism
o Lock and delegation propagation
o Certainly a requirement, but ouch!
o Proposal: Locking and delegation state propagated, acceptable
that it resembles a server reboot.
o We pushed need for reliable name/location service from clients to
servers
o Proposal: Investigate how far to tie back end protocol to name
sevice
Rob T
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:00 AM Z CST