Subject: RE: NFS Vendor's Conference / Interest in replication and migrati on

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 10 Dec 2001 10:48:15 -0800

Rob Thurlow wrote:
[ > Erez Zadok wrote]: 
> > Smart or not, users will _want_ to migrate b/t heterogeneous servers.  They
> > will complain (correctly or not) "why can't you migrate nfsv4 to
> > heterogeneous servers but nfsv4 works b/t heterogeneous clients and
> > servers."
> 
> People will do this, but I don't think we need to do heroics to
> protect them as much as advise them of consequences.  You should
> never lose data by surprise, but a lot of the time you may not
> really care whether you do or not, or know your dataset doesn't
> depend on something like named attributes.  You should always be
> informed of issues like this when setting up a migration or
> replication, and given the chance to bail or make another choice.

I think it's critical that you never lose data by susprise.  If
you know you may lose data and don't care, then presumably tools
will have -JustDoTheBestYouCan flag and your logs can fill with
warnings.  But if you think that your data is such that you won't
lose information and that turns out, for whatever reason, not to
be true, the administrator had better explicitly assent to that.
 
> BTW, you postulated an A->B and a B->A migration because host A
> might be down for extended repairs.  Surely in this scenario, you
> would create a replica and promote it to read-write, and then
> synchronize with the original data when it was back online?  That
> way, you would lose the extra stuff only temporarily.

This will be so if we are careful with the protocol and when
you synchronize, a distinction is made between having no named 
attributes and not supporting named attributes.  If a file is
changed and has no named attributes then the obvious thing is
to do when synching with the original data is to delete them,
whcih we don't want to do.  So we have to be careful and have
the filesystems explicitly provide information about what they
support to do the sync correctly.

Another related situation involves migrating temporarily in
the reverse direction.  Suppose you have a filesystem which
doesn't support named attributes and you temporarily migrate
it to one where there is such support.  If the new system is
a temporary home, it wouldn't be desirable if named atributes
were created on the temporary home, only to be lost when 
resyncing.  I don't think that file systems should be required
to provide this functionality but a migration protocol should
allow this information to be propagated so that a filesystem
could choose to present this filesystem to its v4 clients
as one which does not support named attributees, allowing it
to be sync'ed back or migrated back without additional problems.

---

From: Brent Callaghan <[email-masked]>
Date: Mon, 10 Dec 2001 16:02:37 -0800

Noveck, Dave wrote:

> warnings. 

An interesting challeng for mig/repl, and one that we've run into
already in implementing NFSv4, is that we're short on interfaces
that let us query the capabilities of a filesystem.  For instance,
UNIX OS's support a pathconf() function that let you query maximum
name length and a couple of other features, but it's really hard
to tell whether a filesystem supports ACLs, or what type of ACL
is supported.

I don't see any easy answer to this problem in the short term.
Over time, it would be nice to see a generic API develop (POSIX?)
that we can implement filesystem by filesystem.  Until then, it'll
probably be a heuristic matter: probing and poking with various
API's to see what works and what doesn't.

	Brent