Subject: RE: Section 6.4. Filehandle recovery for Migration or Replicatio n

From: Salit Gazit <[email-masked]>
Date: Wed, 5 Jan 2000 17:30:47 -0800 (PST)

>> Right now the spec says that FH4_VOLATILE_MIGRATION says the 
>> filehandle "may expire during file system migration".  If the 
>> intent is that it "will expire", then we should say that.
>> 
>> For FH4_VOLATILE_ANY, we may want to add something about
>> always expiring at migration or simply allow FH4_VOL_MIGRATION
>> to be set even if FH4_VOLATILE_ANY is set.

Why is there this restriction in the first place? Having FH4_VOLALTILE_ANY
set does not contradict having FH4_VOL_MIGRATION or, for that matter,
FH4_VOL_RENAME set. On the other hand, shouldn't there be a
restriction in the protocol from having FH4_PERSISTENT bit set when
any of the other bits (except the migration bit) are set?

Salit

---

From: Mike Eisler <[email-masked]>
Date: Thu, 6 Jan 2000 07:29:35 -0800 (PST)

> FH4_VOL_RENAME set. On the other hand, shouldn't there be a

What is the purpose is allowing the server to convey redundant information? 

> any of the other bits (except the migration bit) are set?

There is a restriction. FH4_PERSISTENT is a pseudo bit:

   /*
    * Values for fattr4_fh_expire_type
    */
   const   FH4_PERSISTENT          = 0x00000000;
   const   FH4_NOEXPIRE_WITH_OPEN  = 0x00000001;
   const   FH4_VOLATILE_ANY        = 0x00000002;
   const   FH4_VOL_MIGRATION       = 0x00000004;
   const   FH4_VOL_RENAME          = 0x00000008;

i.e. if fattr4_fh_expire_type is non-zero, FH4_PERSISTENT is not "set".

	-mre

---

From: "Salit.Levy" <[email-masked]>
Date: Wed, 5 Jan 2000 16:20:06 -0800 (PST)

> What is the purpose is allowing the server to convey redundant information?

For implementation purposes. If it is known that a filehandle will expire
because of a rename or migration, the client can proactively structure the
request accordingly, for instance by adding a lookup after rename. If
the additional bits are not specified, there is no need for the proactive
code, even if the filehandle may still expire for other reasons.
 
> i.e. if fattr4_fh_expire_type is non-zero, FH4_PERSISTENT is not "set".

Yes, I figured it out after I sent the previous message. But the above is
defined in nfs4_prot.x, not in the protocol draft, and it's not obvious from
the text.

Salit

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 06 Jan 2000 11:36:23 -0600

> defined in nfs4_prot.x, not in the protocol draft, and it's not obvious from

The I-D will be changed to add the clarification.

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Thu, 6 Jan 2000 09:48:20 -0800 (PST)

> > > Why is there this restriction in the first place? Having
> FH4_VOLALTILE_ANY > > set does not contradict having FH4_VOL_MIGRATION or,
> for that matter, > > FH4_VOL_RENAME set. On the other hand, shouldn't there
> be a > 

If FH4_VOLATILE_ANY is set, then the client had better add a lookup after
rename if it is caching file handles. If FH4_VOLATLE_ANY is set, the
client is better off not caching file handles.

> defined in nfs4_prot.x, not in the protocol draft, and it's not obvious from

I cut and paste the above from the i-d on www.ietf.org.

	-mre