Subject: Re: Persistent Filehandle: contradiction in spec and possible implementation

From: Som <[email-masked]>
Date: Tue, 26 Jun 2001 22:26:30 -0700 (PDT)

--- Spencer Shepler <[email-masked]> wrote:
> On Fri, Som wrote:
> > Thanks Spencer!
> > 
> > I must admit that your email was more clear than
> the
> > spec :-) ( probably calls for inclusion in spec ).
> > 
> > I have some more doubts:
> > 
> > 1) Can a NFS client assume that a persistent
> > filehandle is never allocated ( after its deleted
> ) as
> > a volatile filehandle? 
> > [ In section 4.2.4 of the spec it tries to define
> the
> > format of volatile filehandle...but, was it part
> of
> > spec or just an example? so looks to me, a
> persitent
> > filehandle can never be equal to a volatile
> filehandle
> > ..is that true? ]
> 
> Generally, the only time a client is going to get
> into
> trouble is when it is caching the filehandle.  If it
> is caching the
> filehandle, the client needs to be very careful to
> check the
> file type, modification/change time, etc. before
> using the
> cached information because of this and other issues.
> 
> In the years of NFSv2/v3 implementations, the reuse
> of a
> previous persistent filehandle has not been a
> problem.  
> Implementors have ensured that the filehandles have
> not
> been reused.  With the upcoming revisions to the
> RFC, I will
> make sure to pay attention to this particular issue
> and
> ensure that the language is clear about reuse.
> 
> > 2) Can a NFS server steal few bits of persistent
> > filehandle to denote as "reincarnation
> bits"?...the
> > purpose of this is to inform client that a
> "deleted
> > persistent filehandle" [ DPF ] being re-used ( so
> > don't trust this handle anymore...a new error
> status
> > is needed in that case ).
> > 
> > If we don't do 2), then a NFS client may misuse a
> DPF
> > handle thus corrupting a file.
> > [ however, reincarnation bits don't fix the
> problem
> > 100%, but its better than no information at all ]
> 
> If the server has enough knowledge to notify the
> client that the
> filehandle is being reused, can't it just create a
> filehandle that
> doesn't collide with the previous value?  This is
> the purpose of the
> generation number in the classic Unix
> implementation.  Having a
> generation number of 32bits usually ensures that a
> problem does not
> exist.
> 
> > 3) NFS clients need not know anything about those
> > special bits in persistent filehandle, but the new
> > error status will be needed.
> 
> This is not clear to me and I don't believe that any
> modification
> needs to be made to the current RFC with respect to
> this.
> 
> BTW: Did you mean to post this to the WG?
> 
> Spencer

Yes, I wanted to post this to the WG..and my reply was
in earlier email ( reply to Dave's email ).

thanks, som.

=====
"Chess holds its master in its own bonds,
shackling the mind and brain so that the 
inner freedom of the very strongest must 
suffer"-Albert Einstein

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/