Subject: RE: [nfsv4] (no subject)

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 25 Aug 2005 12:17:42 -0400

Benny Halevy:
> Maybe this is obvious but I think that this should be 
> restricted to the semantics specified by NFSv4.  

I'm not sure what you mean here.  The server should not 
behave differently because of a change of impid.  If the
two behaviors are different, even if both of them conform
to the spec in every other respect, if they are different,
then you are violating the spec.  That is the meaning of
Mike's text and my more alarmist text.

> For 
> example, there's nothing wrong with a server that will 
> implement a different read-ahead algorithm based on the 
> impid, right?

I do think there is something wrong in that, yes.  Suppose
I open a 1 GB file and proceed to read randomly.  If you, based
on my impid know that if the file name ends in ".dnoveck",
I will almost certainly eventually read every block in the
file, and read the whole thing sequentially into memory, 
then my performance will be *noticeably* better with that
impid than with no impid or a different impid and I think
it is clear we don't want to go there.  If you want the 
client to define such a hint, then the proper way to do
so is to specify the form of that hint in the protocol. 

> This should be unnoticeable to a test program 
> that tests NFSv4 semantics.  It might notice different 
> performance characteristics though - which should be allowed.

If the performance implications of some different behavior
are so small that are below the performance noise level then
your transgression will indeed go unnoticed, but if the
benefit is so small it is unnoticeable, why do it?  On the
other hand, you are supposing that "It might notice different
performance characteristics" so in that case it would not be
unnoticeable, after all.  If a test program is simply testing
for conformance to the spec in both cases, it will see no 
violation in either case.  If it is testing for a difference 
in behavior, then it is free to look for performance differences
although only gross ones are going to reliably indicate an issue.

When you are looking for behavior differences, whether due to
performance or otherwise, you need to verify that it is the impid
that is provoking the change.  I may because of resource constraints
give out a delegation when you open a file and the next time with 
a different impid not give out the delegation.  If that is just random
behavior, there isn't a problem.  If you repeat the test and find 
out that the impid is the controlling factor then that certainly 
is a problem. 

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]] 
Sent: Wednesday, August 24, 2005 5:45 PM
To: [email-masked]
Cc: Noveck, Dave; [email-masked]
Subject: Re: [nfsv4] (no subject)

comment below...

Benny

Mike Eisler wrote:
> 
> --- "Noveck, Dave" <[email-masked]> wrote:
> 
> 
>>    The server and client MUST NOT, UNDER ANY CIRCUMSTACES WHATSOEVER,
>>    behave differently as a result of the reciept of a particular
impid
>>    or the absence of an impid.
> 
> 
> I've got less alarmist text that is semantically the same, but I will
> add that in.

Maybe this is obvious but I think that this should be 
restricted to the semantics specified by NFSv4.  For 
example, there's nothing wrong with a server that will 
implement a different read-ahead algorithm based on the 
impid, right?  This should be unnoticeable to a test program 
that tests NFSv4 semantics.  It might notice different 
performance characteristics though - which should be allowed.

> 
> 
>>    To guard against the possibility of servers or clients behaving 
>>    differently based on the impid of their partner, interoperabuility

>>    testing should generally be done with sending of impid's disabled.

>>    When impid's are sent during testing, the result should be
verified 
>>    with the sending of impid's disabled.  Any difference in behavior
>>    should be noted as indicating the party (client or server)
receiving
>>    such impid and behaving differently needs to be fixed.   
> 
> 
> I like that idea too. 
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Benny Halevy <[email-masked]>
Date: Thu, 25 Aug 2005 19:55:40 +0300

Ok. I'm convinced.  Explicit hints are better than using 
impid for application specific optimizations.  Now 
practically, what hints can and should nfsv4 provide?

Benny

Noveck, Dave wrote:
> violation in either case.  

That's what I meant in "unnoticeable to a test program
that tests NFSv4 semantics."

> If it is testing for a difference