Subject: RE: [nfsv4] SET_PRIORITY: new op proposal

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 26 Feb 2007 14:01:18 -0500

> If I thught the OpenGroup copyrights allowed me to, I'd lift its
> language almost verbatim. :-) Instead, I'd note the inspiration for
> model,and make an informative reference.

It's short enough it might pass muster under Fair Use, but I'm not
a lawyer and I don't play one on television.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 1:44 PM
To: [email-masked]
Subject: Re: [nfsv4] SET_PRIORITY: new op proposal

--- "Talpey, Thomas" <[email-masked]> wrote:

> But, what does the server actually do with the priority? Normally,
> any
> operation is eligible once received at the server, does this mean the
> server is required to implement strict queuing within the session,
> and
> if so does it mean that it will need to delay the processing of
> requests
> which are otherwise ready? If not, then what does it actually do?
> Benny's
> text documents the field, but doesn't describe the server's
> requirements.

I believe Chuck Lever called this a UNIX-like "nice" priority system.

The man page,
  http://www.opengroup.org/onlinepubs/007908799/xcu/renice.html
for re-nice is very interesting in that it doesn't say anything
about how the operating system is supposed to implement it.
Nothing for example about whether processes with a higher
priority are always ahead of the processes with a lower
priority.
http://www.opengroup.org/onlinepubs/007908799/xbd/glossary.html
under system scheduling priority has more weasel words, ending
with:

  Because of the use of "implementation-dependent" in 
  nice and renice, a wide range of implementation 
  strategies is possible. 

If I thught the OpenGroup copyrights allowed me to, I'd lift its
language almost verbatim. :-) Instead, I'd note the inspiration for
model,and make an informative reference.

But the point is that there is an existance proof of an underspecified
priority system having achieved success.

_______________________________________________
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: "Noveck, Dave" <[email-masked]>
Date: Tue, 27 Feb 2007 09:31:08 -0500

Just to clarify here, when I said,

> I think there would have to be a strong case made to justify inclusion

> of such a feature at this stage in the development of v4.1. 

I was referring back to "anything that imposes strict requirements".
For something that is loose on implementation requirements, as I 
think we agree this is, the justification threshold would be much
lower.  I believe that including this functionality in v4.1, in the
form that Mike proposed is quite reasonable.

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]] 
Sent: Tuesday, February 27, 2007 3:51 AM
To: Noveck, Dave
Cc: Talpey, Thomas; [email-masked]; Robert Gordon;
[email-masked]; Welch, Brent; [email-masked]
Subject: Re: [nfsv4] SET_PRIORITY: new op proposal

Noveck, Dave wrote:
> As I understand the proposal, there are no requirements per se.
> This is a case of the client proposes and the server disposes.
> While there may be valid objections to leaving things so loose, 
> anything that imposes strict requirements seems like it will add to 
> implementation complexity and complicate the specification process.

agreed.

> I think there would have to be a strong case made to justify inclusion

> of such a feature at this stage in the development of v4.1.

I can't speak for application vendors but I can provide several possible
use cases:

* namespace related:
  - per volume: /production vs. /home
  - per subtree: /home/sales/* vs. /home/dev/*
  - per file type: *.tbl (standing for a database table) vs. *.mp3

* operation type:
  - better response time for GETATTRs and READDIRs vs. READ/WRITE (and
    from a workstation vs. from an application server).
  - lower priority for client readahead READs.
  - higher priority for WRITEs and COMMITs when client is under low
memory
    pressure.

* deployment:
  - clients with different priorities: app servers in the data center
    vs. user workstations.
  - hosting farm SLAs (over shared storage ;-).
  - job scheduling in a cluster of clients (compute farm)
  - just translating the process nice priority into NFS I/O priority.

Benny

> From: Talpey, Thomas
> Sent: Monday, February 26, 2007 12:39 PM
> To: [email-masked]; Halevy, Benny; Robert Gordon
> Cc: [email-masked]; Welch, Brent; [email-masked]
> But, what does the server actually do with the priority? Normally, any

> server is required to implement strict queuing within the session, and

> requests which are otherwise ready? If not, then what does it actually
do?
> Call me confused, perhaps...
> 
> Tom.
> 
> At 12:21 PM 2/26/2007, Robert Gordon wrote:
>> exactly what i was thinking..
>>
>> Robert.
>> On Feb 26, 2007, at 7:35 AM, Mike Eisler wrote:
>>
>>> If we were talking about NFSv4.2, SET_PRIORITY would be a natural 
>>> way to add this operation.
>>>
>>> Since we are still working on NFSv4.1, we have an opportunity to add

>>> this to "existing" NFSv4.1 core infrastructure.
>>>
>>> My counter proposal is:
>>>
>>> - add a priority field to CREATE_SESSION arguments (which the server

>>> can
>>>   confirm as it does various other session values). The priority is
>>>   relative to other sessions, and represents the priority the server
>>>   and client will take when servicing the fore and back channels of
>>>   the session. For completeness, there can be separate fore and back
>>>   channel priorities.
>>>
>>> - add a priority field to SEQUENCE and CB_SEQUENCE arguments
>>>   and results. The priority represents priority of the
>>>   COMPOUND/CB_COMPOUND relative to other COMPOUNDs/CB_COMPOUNDs
>>>   executed on the session.
>>>
>>> - There is no way to update the session's priority once the session
> is
>>>   created. Just as there is no way to update the maximum request
> size.
>>>   Maybe, someday, we'll need such capabilities, but a general
purpose
>>>   operation to updated session and channel attributes should be
> added.
>>>   Thus far, I haven't seen a clamor for that. In the mean time, just
>>>   create another session, and gracefully destroy the old session
once
>>>   replies for all outstanding COMPOUNDs have been received.
>>>