Subject: [nfsv4] FW: I-D Action: draft-ietf-nfsv4-minorversion2-15.txt

From: "Noveck, David" <[email-masked]>
Date: Mon, 8 Oct 2012 13:32:08 -0400

Inadvertently dropped the nfsv4 list when cc-ing

-----Original Message-----
From: Noveck, David 
Sent: Monday, October 08, 2012 11:08 AM
To: 'J. Bruce Fields'
Subject: RE: [nfsv4] I-D Action: draft-ietf-nfsv4-minorversion2-15.txt

> By the way, I was idly thinking: "oh, I could just use the change
> attribute on the file, as long as it was bumped on label changes too."
> But obviously that would be a disater.

Well I was idly thinking that you could actually satisfy my requirement 
by always returning the *current* time as the value of this attribute.  
That would be an even bigger disaster.

Should we say anything about such possibilities in the requirement?  My 
proposed requirement was focused on correctness only, and left performance 
unmentioned.  Can we say anything in this regard that is more meaningful 
than "You SHOULD NOT create a performance disaster."?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of J. Bruce Fields
Sent: Saturday, October 06, 2012 7:13 PM
To: Myklebust, Trond
Cc: Haynes, Tom; nfsv4 list
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-minorversion2-15.txt

On Sat, Oct 06, 2012 at 09:43:29PM +0000, Myklebust, Trond wrote:
> 
> On Oct 5, 2012, at 4:42 AM, "Noveck, David" <[email-masked]> wrote:
> 
> >>> 	"Each time the sec_label is changed, the server MUST increment
> >>> 	the value of change_sec_label by one."
> > 
> >> Yes. That isn't needed for VERIFY/NVERIFY support.
> > 
> > True.  We need a statement of the requirement as opposed to a description
> > of one way to satisfy it.
> > 
> > I think the requirement should be something like,
> > 
> >      If the value of sec_label for a file is different at two different 
> >      Times then the values of change_sec_label at those times MUST be 
> >      different as well.
> > 
> > I don't see how you can meet that requirement with a simple hash of the
> > label string.  Maybe my definition of 'simple hash' is just too 
> > simple-minded.
> 
> As far as I'm concerned, false positives (i.e. client believes that the label has changed) are of relatively little consequence: it will force the current operation to be aborted, the label to be re-read, and the operation retried. Given the basic assumption that label changes are _rare_, I don't think this is unreasonable.

By the way, I was idly thinking: "oh, I could just use the change
attribute on the file, as long as it was bumped on label changes too."
But obviously that would be a disater.

So, *might* be worth saying something along the lines of:

	If the value of sec_label for a file is different at two
	different times then the values of change_sec_label at those
	times MUST be different as well.  The value of change_sec_label
	MAY change at other times as well, but this should be rare, as
	that will require the client to abort any operation in progress,
	re-read the label, and retry the operation.

> If you are worried that the hash may lead to collisions despite the
> rarity of label changes, then one way to solve that might be to use a
> time stamp instead: something that isn't stored on permanent storage
> will probably suffice, since false positives are (relatively) cheap.

False negatives might also be possible if time granularity's too course?

But I suppose given the rarity of label changes you should be able
to just block a repeated label change for a second if necessary, and
then all you need to do is use something like unix time and ensure it
never goes backwards.  OK.

If we really want to allow a hash then we'd want something bigger than a
u32.

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