headers
Garth Goodson | 1 Aug 2006 01:01
Picon

pnfs issue 102: new layout type definition requirements

I've come up with the following proposal on the requirements for 
defining new layout types.  It is currently a little rough.  It 
resembles the method used in DHCP to define new options, found in 
RFC2132, section 10.

Defining new layout types

    New layout type numbers will be requested from IANA.  IANA will
    only provide layout type numbers for Standards Track RFCs approved
    by the IESG, in accordance with Standards Action policy defined in
    RFC2434.

    The author of a new pNFS layout specification must follow these
    steps to obtain acceptance of the layout type as a standard:

    1. The author devises the new layout specification.

    2. The new layout type specification MUST, at a minimum:
       * Define the following data types: the device address, the
         layout, the layouthint, and the layoutupdate structure
       * Describe or define the storage access protocol used to access
         the data servers
       * Include a security considerations section

    3. The author documents the new layout specification as an Internet
       Draft.

    4. The author submits the Internet Draft for review through the
       IETF standards process as defined in "Internet Official Protocol
       Standards" (STD 1).  The new layout specification will be
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andreas Gruenbacher | 1 Aug 2006 12:36
Picon

Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

On Friday 28 July 2006 08:32, Lisa Week wrote:
> >[...] We don't care about permissions that are not
> >granted, so we *could* only look at ALLOW ACEs, but this distinction is
> > not at all relevant.
>
> What?  I don't understand how you can say that "we don't care about
> permissions that are not granted".  We definitely care about permissions
> that are explicitly not granted.

What I mean is that when looking at which permissions go beyond additional 
file access control mechanisms, we don't need to consider DENY ACEs: DENY 
ACEs can only further restrict access, and so they are never alternate file 
access control mechanisms.

> Also, I believe it is relevant to make a distinction between ALLOW and
> DENY ACEs.  Here's why:
>
> The reasoning behind classifying those DENY ACEs as additional access
> control mechanisms are 1.) because they further restrict the permissions
> of users and groups (which is what additional does by definition) and
> 2.) we don't want them to have to be disabled upon chmod.  Try to think
> about it in a way that you have just set an explicit entry to deny
> certain permissions to a supplemental user or group.  It is important
> that those users or groups don't have their permissions elevated after
> chmod.

Yes.

> For example, if you have an ACL such as this:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benny Halevy | 1 Aug 2006 14:34
Favicon

Re: pnfs issue 102: new layout type definition requirements

Looks good.
Benny

Garth Goodson wrote:
> I've come up with the following proposal on the requirements for 
> defining new layout types.  It is currently a little rough.  It 
> resembles the method used in DHCP to define new options, found in 
> RFC2132, section 10.
>
>
>
> Defining new layout types
>
>    New layout type numbers will be requested from IANA.  IANA will
>    only provide layout type numbers for Standards Track RFCs approved
>    by the IESG, in accordance with Standards Action policy defined in
>    RFC2434.
>
>    The author of a new pNFS layout specification must follow these
>    steps to obtain acceptance of the layout type as a standard:
>
>    1. The author devises the new layout specification.
>
>    2. The new layout type specification MUST, at a minimum:
>       * Define the following data types: the device address, the
>         layout, the layouthint, and the layoutupdate structure
>       * Describe or define the storage access protocol used to access
>         the data servers
>       * Include a security considerations section
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Hildebrand | 1 Aug 2006 22:30
Picon
Favicon

Re: pnfs: read/write through MDS hint (Issue 55)


>  For either
> threshold type, a value of 0 indicates no read or write should be
> issued to the metadata server, while a value of ~0 indicates all reads
> or writes should be issued to the metadata server.
Do you mean all 1s, or do I not understand a common term (~0)?
>
> Due to dynamic system changes, the client
> should not assume that the attribute will remain constant for any
> specific time period, thus it should be periodically refreshed.
Should we specify some minimum amount of time that it is valid (such as 
while a file is open) ?
Dean
>
>
> Structures:
> -----------
>
> struct pnfs_mdsthreshold_item {
>   pnfs_layouttype4  layout_type;
>   bitmap4           hintset;
>   opaque            hintlist<>;
> };
>
> struct pnfs_mdsthreshold {
>   pnfs_mdsthreshold_item hints<>;
> };
>
> The pnfs_mdsthreshold structure holds an array of hints that can help
> the client determine when it should issue I/O directly through the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Garth Goodson | 2 Aug 2006 01:09
Picon

Re: pnfs: read/write through MDS hint (Issue 55)


Dean Hildebrand wrote:
> 
>>  For either
>> threshold type, a value of 0 indicates no read or write should be
>> issued to the metadata server, while a value of ~0 indicates all reads
>> or writes should be issued to the metadata server.
> Do you mean all 1s, or do I not understand a common term (~0)?

Yes, all ones.

>>
>> Due to dynamic system changes, the client
>> should not assume that the attribute will remain constant for any
>> specific time period, thus it should be periodically refreshed.
> Should we specify some minimum amount of time that it is valid (such as 
> while a file is open) ?

This is tricky.  I don't think we can impose a minimum on an 
implementation.  Some apps may keep files open for a very long period of 
time, and it would be unreasonable to restrict the server from 
optimizing itself to adhere to this restriction.  We talked a bit about 
this in Montreal and there is no good solution at this time.  Some 
prefer the client to poll, while others prefer some type of callback.

-Garth

> Dean
>>
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Garth Goodson | 2 Aug 2006 01:17
Picon

pnfs issue 57: private layout range

I've created a paragraph on private vs standardized layout ranges.  I 
added it to the layouttype4 description, but am not sure if this is the 
best place.  It should reference the section describing the method for 
adding new layout types (issue 102).

-Garth

1.2.17.  layouttype4

    enum layouttype4 {
        LAYOUT_NFSV4_FILES  = 1,
        LAYOUT_OSD2_OBJECTS = 2,
        LAYOUT_BLOCK_VOLUME = 3
    };

    A layout type specifies the layout being used.  The implication is
    that clients have "layout drivers" that support one or more layout
    types.  The file server advertises the layout types it supports
    through the LAYOUT_TYPES file system attribute.  A client asks for
    layouts of a particular type in LAYOUTGET, and passes those layouts
    to its layout driver.

+  The layouttype4 structure is 32 bits in length.  The range
+  represented by the layout type is split into two parts.  Types
+  within the range 0x00000000-0x7FFFFFFF are globally unique and are
+  assigned according to the description in Section ??; they are
+  maintained by IANA.  Types within the range 0x8000000-0xFFFFFFFF are
+  site specific and for "private use" only [RFC2434].

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Garth Goodson | 2 Aug 2006 02:17
Picon

Re: proposal to remove CB_SIZECHANGED

There doesn't seem to be any disagreement to this proposal, so I think 
we have reached consensus on the issue -- last chance to disagree ;-).

Should we continue to use issue 21 to track this?

This change affects the following sections:

16.4.2.  LAYOUTCOMMIT and size

- Last paragraph should be removed

- Could insert a paragraph explaining what the client can do 
(combination of polling using GETATTR, and short-read detection using 
cached attrs), as described in Benny's original email.

- Include some text describing possibility of recalling layout in some 
corner cases.

17.5.  Storage Device Component File Size

- Needs to be re-written, I can do this

20.3.  Callback operations and their valid errors

- Remove reference

20.4.  Errors and the operations that use them

- Remove reference
(Continue reading)

Permalink | Reply | 627 comments |
headers
Benny Halevy | 2 Aug 2006 08:45
Favicon

Re: proposal to remove CB_SIZECHANGED

Garth Goodson wrote:
> There doesn't seem to be any disagreement to this proposal, so I think 
> we have reached consensus on the issue -- last chance to disagree ;-).
>
> Should we continue to use issue 21 to track this?
I think that the scope of the change justifies filing a new issue.

Benny
>
>
> This change affects the following sections:
>
> 16.4.2.  LAYOUTCOMMIT and size
>
> - Last paragraph should be removed
>
> - Could insert a paragraph explaining what the client can do 
> (combination of polling using GETATTR, and short-read detection using 
> cached attrs), as described in Benny's original email.
>
> - Include some text describing possibility of recalling layout in some 
> corner cases.
>
> 17.5.  Storage Device Component File Size
>
> - Needs to be re-written, I can do this
>
> 20.3.  Callback operations and their valid errors
>
> - Remove reference
(Continue reading)

Permalink | Reply | 1 comment |
headers
Spencer Shepler | 2 Aug 2006 11:44
Picon

Re: Preview of new locking chapter

On Sun, Noveck, Dave wrote:
> Here is the new revised-for-sessions locking chapter, including the
> changes for SEQUENCE-based notifications and a re-organized treatment of
> lock revocations, that have been proposed previously.  Although the
> reaction to these was generally positive, there wasn't enough discussion
> to really declare a consensus and so I promised everybody a chance to
> look at the new locking chapter, before it went into an official draft.

After reviewing this chapter I have a few comments.

Overall, I believe that the contents of the chapter need to be split
into three areas of discussion.  The first would be the protocol's
state and how it is instantiated, manipulated, and destroyed/released.
This would be in normal operation.  I would like to refer to this
as "state" instead of locks specifically to avoid any mis-interpretations
of locks and byte-range locks.

Following this would be a discussion of the failure/recovery mechanisms
and their impact on the state (much of what is there in the chapter
already.

Finally, a discussion of shares and byte-range locks.

The reason for this is that these three areas are intermixed because
of the structure we had in rfc3530 and was never cleaned up.

A couple of comments that are not directly related to the specifics
of the locking chapter but were things I thought the WG had agreed to
and we need to confirm that and then find a home for them.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Peter Somogyi | 2 Aug 2006 14:18
Picon

FYI: win<-->NFS4 ACL mapping on samba-tech

Hi,

I'd like to inform you there's a design and coding-level acceptance discussion 
on samba-technical <at> lists.samba.org about a new samba module patch which maps 
between windows and NFS4 ACLs.
(subject is very long: svn commit: samba r17353 - in branches/SAMBA_3_0: 
examples examples/gpfs source source/modules source/smbd)

Anybody reading or joining the thread are welcome.

Peter Somogyi

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |

Gmane