Subject: RE: Migration/Replication & renames

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 10 Jan 2002 13:52:14 -0800

Brent Callaghan wrote:
> "Noveck, Dave" wrote:
> > 
> > Unless I'm missing something, it seems your approach would
> > deal with renames that happened after the migration event,
> > but be exposed to the effects of renames of open files
> > that happened before the migration event.
> > 
> > Suppose I open A.  Get back handle X and stateid S.
> > 
> > Another client renames A to be B and renames C to be
> > A.
> > 
> > Migration.  Client references A using handle X and gets
> > NFS4ERR_MOVED.  He then gets the new location of the fs.
> 
> How about a grace period that freezes name changes
> before the migration event ?

How long does such a period last?  It would have to
be long enough such that no open which started before it
began could still be present since any such open would have
been pending during a period before the grace period started,
and during that period of time renames including renames of
the particular open file would have been allowed.

Even if you could bound the time a file was open (and I
doubt you could do that), the limit woudl be so large
that there would be no way you hold off renames for that
period of time, and it woudl mean that you couldn't actually
effect the migration for a considerable time after deciding to 
do it. 

> > I think some sort of grace period is essential to make this
> > problem tractable, but I believe that you need some sort
> > of mapping facility that allows the client to convert 
> > old handles to new ones, without depending on name lookup,
> > which may do the wrong thing, from the client's point of
> > view.
> 
> I'd prefer we find a way to avoid mapping tables.  A mapping
> table has the potential to be huge, expensive to create, 
> and it has to be kept somwhere.  It could turn into another
> .nfsxxx problem.

The mapping tables could be limited in size by only including
open files.  If you don't find something in the mapping table,
you can remap by name. It has to be kept somewhere but 
you have a file system in which you can keep things 
(and if the fs is read-only you aren't going to be
renaming things and won't need the table).  The problem 
has to be solved somehow and I don't think it can be
solved depending only on mapping by file name, as long
as you allow, as UNIX systems do, renaming an open file.

> Still hoping we can come up with a migration/replication
> protocol that's popular independently of NFSv4.

Migration is a generally useful thing, but it is particularly
useful when combined with transparent access to the migrated
data.  That's the nice thing that NFSv4 gives you and any
migration protocol should not interfere with that.