Subject: RE: Replication and migration requirements

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 20 Aug 2001 13:23:18 -0700

Brent wrote: 
> Uresh Vahalia wrote:
> > 
> > Brent wrote:
> > > Realistically, we won't ever have correct replication/migration
> > > unless it's across homogeneous filesystems.  I think we'll be
> > 
> > Absolutely.  But if it is merely something that kind of sort of works
> > most of the time, customers would doubtless seek safe haven in a
> > homogenous solution.
> 
> ... for which block-level solutions already exist. No problem with that.
> 
> I'm guessing that most apps make fairly minimal demands on filesystem
> features so that they have maximal portability.

People who are interested in portability, often test whether certain
functionality is present and do different things so that they can 
workaround the case in which the functionality is not present.

If the results of that test can be invalidated at any instant as a
result of migration, then such apps would have a problem.

Apart from the apps, lots of client implementations may have problems
if features that were present one instant are not available the next.
Consider all the optional attributes and how tough it might be
to deal with migration to a file-system that supported a smaller set,
while keeping all the client code from losing its mind.

I think one of the goals here should be to define the conditions for
reasonably safe migration, so that you can say "I can't do that",
rather than trying and causing chaos.
 
> So I hope it's reasonable to assume that a protocol that works across
> heterogeneous filesystems, albeit with less than 100% support of features,
> will be useful and popular.  Isn't that the premise behind NFS ?

As far as the protocol goes, yes.  But the user who uses NFS generally
has some contraints on what is on the server side.  I think it would be
very hard to find a significant application that that would work with
any possible server implementation.  This is the other side of the
decision that NFS doesn't dictate fs semantics.  To the degree that 
you depend on fs semantics, you are depending not on NFS but on the 
semantics exported by the server fs.  

NFS-v4, because it embraces so many optional features, (attributes,
types of handles, named attributes, etc.) makes this issue larger
than it was in v2 and v3.  Also, the very attempt to be less
UNIX-centric creates more opportunities for multiple types of
clients to have a larger range of expectations regarding server
behavior, such that these could be invalidated by an inappropriate
migration.