From: Juan Gomez (juang@us.ibm.com)
Date: 06/02/02-01:14:50 PM Z
Subject: Re: NFSv4 Replication and Migration: design team conference call/Draft
Message-ID: <OF9AEE3387.0F107FF5-ON88256BCD.0061A369@boulder.ibm.com>
From: "Juan Gomez" <juang@us.ibm.com>
Date: Sun, 2 Jun 2002 11:14:50 -0700
Rob,
I think I was looking at the paper more from the point of view of
compression: recognizing similar blocks in a filesystem may help us a lot
in compressing what we have to send during a migration, I do not have
numbers but I think we may expect reasonable block replication on a given
filesytem, enough to be worth exploring.
Also in replication, I think we should have some protocol capable of
shipping only new blocks (i.e. updates) and not the old ones already
present in the other servers. I am not sure if we want to consider the
complications associated with this as it requires persistent storage of
replication-related metadata.
Juan
Robert Thurlow
<Robert.Thurlow@e To: Juan Gomez/Almaden/IBM@IBMUS
ng.sun.com> cc: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: NFSv4 Replication and Migration: design team
06/03/02 08:47 AM conference call/Draft
Please respond to
Robert Thurlow
> 1.-Do we want to provide for failure recovery in the
migration/replication
> protocol? I know that in most cases we should be sending differential
> changes to the filesystems but I keep thinking of the case were we have a
> full (intial) migration/replication of a file system and one side
involved
> in the process fails; do we want to have some type of migration
> checkpointing?
Yes; I believe that restartability in this case is a requirement.
> 2.-I think striving for a efficient bandwith utilization is a great idea
so
> I wanted to make the group aware of recent work in this area that may
> relevant to the design of a a bandwith efficient migration replication
> protocol:
>
> http://www.cs.ucsd.edu/sosp01/papers/mazieres.pdf
>
> I think the bandwith-saving ideas presented in this paper may work great
in
> migration/replication. What do you guys think?
This is an interesting paper I had not known about, but I believe
it is really only applicable with conventional filesystems traffic.
With replication/migration, you have a largely unidirectional flow
of data, and you can't benefit from caching and block recognition
as the paper describes. The main thing would seem to be to keep
the pipe full; a streaming protocol which minimizes the risk of a
stall waiting for back-traffic from destination to source would
seem to cover us here. Compression of data could be a benefit;
are there other ideas in the paper you believe would apply?
Rob T
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:48 AM Z CST