pNFS client structure and function rename suggestions

pNFS client structure and function rename suggestions

[Andy Adamson]

[-- Attachment #1: Type: text/html, Size: 490 bytes --]

[-- Attachment #2: pnfs-client-rename.txt --]
[-- Type: text/plain, Size: 2639 bytes --]

*********
include/linux/nfs_fs.h

struct pnfs_layout_type => pnfs_layout
fields:
    refcount => lo_refcount
    segs => lo_segs
    roc_iomode => lo_roc_iomode
    seqlock => lo_seqlock
    stateid => lo_stateid
    pnfs_layout_state => lo_state
    pnfs_write_begin_pos => lo_write_begin
    pnfs_write_end_pos => lo_write_end

*********
include/linux/pnfs_xdr.h

NOTE: consider removing and adding to include/linux/nfs_xdr.h where the other
nfsv4.1 xdr structs are declared.

struct nfs4_pnfs_layout => remove, inline in nfs4_layoutget_args.

struct nfs4_pnfs_layout_segment => pnfs_layout_range

struct nfs4_pnfs_layoutget_arg => nfs4_layoutget_args
fields:
    lseg => range
    layout: remove. inline with:
	add: layout_len
        add: layout_buf

struct nfs4_pnfs_layoutget_res => nfs4_layoutget_res
fields:
    lseg => range

struct nfs4_pnfs_layoutget => nfs4_layoutget

struct pnfs_layoutcommit_arg => nfs4_layoutcommit_args
fields:
    lseg => range

struct pnfs_layoutcommit_res => nfs4_layoutcommit_res

struct pnfs_layoutcommit_data => nfs4_layoutcommit_data

struct nfs4_pnfs_layoutreturn_arg => nfs4_layoutreturn_args
fields:
    lseg => range

struct nfs4_pnfs_layoutreturn_res => nfs4_layoutreturn_res

struct nfs4_pnfs_layoutreturn => nfs4_layoutreturn

struct nfs4_pnfs_getdeviceinfo_arg => nfs4_getdeviceinfo_args

struct nfs4_pnfs_getdeviceinfo_res => nfs4_getdeviceinfo_res

*********
include/linux/nfs4.h

NFSPROC4_CLNT_PNFS_LAYOUTGET => NFSPROC4_CLNT_LAYOUTGET
NFSPROC4_CLNT_PNFS_LAYOUTCOMMIT => NFSPROC4_CLNT_LAYOUTCOMMIT
NFSPROC4_CLNT_PNFS_LAYOUTRETURN => NFSPROC4_CLNT_LAYOUTRETURN
NFSPROC4_CLNT_PNFS_GETDEVICEINFO => NFSPROC4_CLNT_GETDEVICEINFO

*********

fs/nfs/nfs4proc.c

nfs4_pnfs_layoutget_prepare => nfs4_layoutget_prepare
nfs4_pnfs_layoutget_done => nfs4_layoutget_done
nfs4_pnfs_layoutget_release => nfs4_layoutget_release

_pnfs4_proc_layoutget => _nfs4_proc_layoutget
pnfs4_proc_layoutget => nfs4_proc_layoutget


pnfs_layoutcommit_prepare => nfs4_layoutcommit_prepare
pnfs_layoutcommit_done => nfs4_layoutcommit_done
pnfs_layoutcommit_release => nfs4_layoutcommit_release

_pnfs4_proc_layoutcommit => _nfs4_proc_layoutcommit
pnfs4_proc_layoutcommit => nfs4_proc_layoutcommit

nfs4_pnfs_layoutreturn_prepare => nfs4_layoutreturn_prepare
nfs4_pnfs_layoutreturn_done => nfs4_layoutreturn_done
nfs4_pnfs_layoutreturn_release => nfs4_layoutreturn_release

_pnfs4_proc_layoutreturn => _nfs4_proc_layoutreturn
pnfs4_proc_layoutreturn => nfs4_proc_layoutreturn

nfs4_pnfs_getdeviceinfo => nfs4_proc_getdeviceinfo

Re: pNFS client structure and function rename suggestions

[Boaz Harrosh]

On 07/27/2010 06:37 PM, Andy Adamson wrote:
> *********
> include/linux/nfs_fs.h
> 
> struct pnfs_layout_type => pnfs_layout

I must disagree. Sorry.

The layout4 type in the standard is defined as:
struct layout4 {
           offset4                 lo_offset;
           length4                 lo_length;
           layoutiomode4           lo_iomode;
           layout_content4         lo_content;
};

Which is what we use as layout_segment. All the "LAYOUT" operations
operate on an embedded concept of the above layout (seg) and or
the LAYOUTGET actually returns a layout4.

Calling something else pnfs_layout, will totally confuse. (And it seems
it has already confused the best of us ;-) )

The above, former struct pnfs_layout_type, is a collection of "layout"s
and governing state, plus general LD based IO management stuff.

For me it is just the "nfs inode extension for pnfs", embedded inside the
"LD inode extension"

Call it what you like. But the concept of "layout" was invented by the
rfc5661. Please don't overload it to mean something else.

> fields:
>     refcount => lo_refcount
>     segs => lo_segs
>     roc_iomode => lo_roc_iomode
>     seqlock => lo_seqlock
>     stateid => lo_stateid
>     pnfs_layout_state => lo_state
>     pnfs_write_begin_pos => lo_write_begin
>     pnfs_write_end_pos => lo_write_end
> 

Maybe just call it:
struct nfs_inode {
	...
	struct pnfs_info *pnfs;

If the "layout" name is dropped then by naming convention the "lo_" is not
appropriate as well.

> *********
> include/linux/pnfs_xdr.h
> 
> NOTE: consider removing and adding to include/linux/nfs_xdr.h where the other
> nfsv4.1 xdr structs are declared.
> 
> struct nfs4_pnfs_layout => remove, inline in nfs4_layoutget_args.
> 
> struct nfs4_pnfs_layout_segment => pnfs_layout_range

Isn't this a struct layout4 above?
(And what an ugly reorder from the STD's fields, with these double
miss alignment inside the nfs4_pnfs_layoutget_arg)

I don't see why we have to invent new names (and structures) that translate
to yet other names and concepts in the standard. (And a dictionary that
translates one to the other). Why can't we just use the STDs names and structures
directly? Is there not to many already?

> 
> struct nfs4_pnfs_layoutget_arg => nfs4_layoutget_args
> fields:
>     lseg => range
>     layout: remove. inline with:
> 	add: layout_len
>         add: layout_buf
> 
> struct nfs4_pnfs_layoutget_res => nfs4_layoutget_res
> fields:
>     lseg => range
> 

All these lsegs above and below are layouts

> struct nfs4_pnfs_layoutget => nfs4_layoutget
> 

OMG, yes!

Boaz

> struct pnfs_layoutcommit_arg => nfs4_layoutcommit_args
> fields:
>     lseg => range
> 
> struct pnfs_layoutcommit_res => nfs4_layoutcommit_res
> 
> struct pnfs_layoutcommit_data => nfs4_layoutcommit_data
> 
> struct nfs4_pnfs_layoutreturn_arg => nfs4_layoutreturn_args
> fields:
>     lseg => range
> 
> struct nfs4_pnfs_layoutreturn_res => nfs4_layoutreturn_res
> 
> struct nfs4_pnfs_layoutreturn => nfs4_layoutreturn
> 
> struct nfs4_pnfs_getdeviceinfo_arg => nfs4_getdeviceinfo_args
> 
> struct nfs4_pnfs_getdeviceinfo_res => nfs4_getdeviceinfo_res
> 
> *********
> include/linux/nfs4.h
> 
> NFSPROC4_CLNT_PNFS_LAYOUTGET => NFSPROC4_CLNT_LAYOUTGET
> NFSPROC4_CLNT_PNFS_LAYOUTCOMMIT => NFSPROC4_CLNT_LAYOUTCOMMIT
> NFSPROC4_CLNT_PNFS_LAYOUTRETURN => NFSPROC4_CLNT_LAYOUTRETURN
> NFSPROC4_CLNT_PNFS_GETDEVICEINFO => NFSPROC4_CLNT_GETDEVICEINFO
> 
> *********
> 
> fs/nfs/nfs4proc.c
> 
> nfs4_pnfs_layoutget_prepare => nfs4_layoutget_prepare
> nfs4_pnfs_layoutget_done => nfs4_layoutget_done
> nfs4_pnfs_layoutget_release => nfs4_layoutget_release
> 
> _pnfs4_proc_layoutget => _nfs4_proc_layoutget
> pnfs4_proc_layoutget => nfs4_proc_layoutget
> 
> 
> pnfs_layoutcommit_prepare => nfs4_layoutcommit_prepare
> pnfs_layoutcommit_done => nfs4_layoutcommit_done
> pnfs_layoutcommit_release => nfs4_layoutcommit_release
> 
> _pnfs4_proc_layoutcommit => _nfs4_proc_layoutcommit
> pnfs4_proc_layoutcommit => nfs4_proc_layoutcommit
> 
> nfs4_pnfs_layoutreturn_prepare => nfs4_layoutreturn_prepare
> nfs4_pnfs_layoutreturn_done => nfs4_layoutreturn_done
> nfs4_pnfs_layoutreturn_release => nfs4_layoutreturn_release
> 
> _pnfs4_proc_layoutreturn => _nfs4_proc_layoutreturn
> pnfs4_proc_layoutreturn => nfs4_proc_layoutreturn
> 
> nfs4_pnfs_getdeviceinfo => nfs4_proc_getdeviceinfo
> 

Re: pNFS client structure and function rename suggestions

[Fred Isaman]

On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <bharrosh@panasas.com> wr=
ote:
> On 07/27/2010 06:37 PM, Andy Adamson wrote:
>> *********
>> include/linux/nfs_fs.h
>>
>> struct pnfs_layout_type =3D> pnfs_layout
>
> I must disagree. Sorry.
>
> The layout4 type in the standard is defined as:
> struct layout4 {
> =A0 =A0 =A0 =A0 =A0 offset4 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lo_offset=
;
> =A0 =A0 =A0 =A0 =A0 length4 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lo_length=
;
> =A0 =A0 =A0 =A0 =A0 layoutiomode4 =A0 =A0 =A0 =A0 =A0 lo_iomode;
> =A0 =A0 =A0 =A0 =A0 layout_content4 =A0 =A0 =A0 =A0 lo_content;
> };
>
> Which is what we use as layout_segment. All the "LAYOUT" operations
> operate on an embedded concept of the above layout (seg) and or
> the LAYOUTGET actually returns a layout4.
>
> Calling something else pnfs_layout, will totally confuse. (And it see=
ms
> it has already confused the best of us ;-) )
>
> The above, former struct pnfs_layout_type, is a collection of "layout=
"s
> and governing state, plus general LD based IO management stuff.
>
> For me it is just the "nfs inode extension for pnfs", embedded inside=
 the
> "LD inode extension"
>
> Call it what you like. But the concept of "layout" was invented by th=
e
> rfc5661. Please don't overload it to mean something else.
>
>> fields:
>> =A0 =A0 refcount =3D> lo_refcount
>> =A0 =A0 segs =3D> lo_segs
>> =A0 =A0 roc_iomode =3D> lo_roc_iomode
>> =A0 =A0 seqlock =3D> lo_seqlock
>> =A0 =A0 stateid =3D> lo_stateid
>> =A0 =A0 pnfs_layout_state =3D> lo_state
>> =A0 =A0 pnfs_write_begin_pos =3D> lo_write_begin
>> =A0 =A0 pnfs_write_end_pos =3D> lo_write_end
>>
>
> Maybe just call it:
> struct nfs_inode {
> =A0 =A0 =A0 =A0...
> =A0 =A0 =A0 =A0struct pnfs_info *pnfs;
>
> If the "layout" name is dropped then by naming convention the "lo_" i=
s not
> appropriate as well.
>
>> *********
>> include/linux/pnfs_xdr.h
>>
>> NOTE: consider removing and adding to include/linux/nfs_xdr.h where =
the other
>> nfsv4.1 xdr structs are declared.
>>
>> struct nfs4_pnfs_layout =3D> remove, inline in nfs4_layoutget_args.
>>
>> struct nfs4_pnfs_layout_segment =3D> pnfs_layout_range
>
> Isn't this a struct layout4 above?

No, this is probably the most confusingly named structure of them all,
and one I would strongly urge be changed along the line of Andy's
suggestion.

=46red

> (And what an ugly reorder from the STD's fields, with these double
> miss alignment inside the nfs4_pnfs_layoutget_arg)
>
> I don't see why we have to invent new names (and structures) that tra=
nslate
> to yet other names and concepts in the standard. (And a dictionary th=
at
> translates one to the other). Why can't we just use the STDs names an=
d structures
> directly? Is there not to many already?
>
>>
>> struct nfs4_pnfs_layoutget_arg =3D> nfs4_layoutget_args
>> fields:
>> =A0 =A0 lseg =3D> range
>> =A0 =A0 layout: remove. inline with:
>> =A0 =A0 =A0 add: layout_len
>> =A0 =A0 =A0 =A0 add: layout_buf
>>
>> struct nfs4_pnfs_layoutget_res =3D> nfs4_layoutget_res
>> fields:
>> =A0 =A0 lseg =3D> range
>>
>
> All these lsegs above and below are layouts
>
>> struct nfs4_pnfs_layoutget =3D> nfs4_layoutget
>>
>
> OMG, yes!
>
> Boaz
>
>> struct pnfs_layoutcommit_arg =3D> nfs4_layoutcommit_args
>> fields:
>> =A0 =A0 lseg =3D> range
>>
>> struct pnfs_layoutcommit_res =3D> nfs4_layoutcommit_res
>>
>> struct pnfs_layoutcommit_data =3D> nfs4_layoutcommit_data
>>
>> struct nfs4_pnfs_layoutreturn_arg =3D> nfs4_layoutreturn_args
>> fields:
>> =A0 =A0 lseg =3D> range
>>
>> struct nfs4_pnfs_layoutreturn_res =3D> nfs4_layoutreturn_res
>>
>> struct nfs4_pnfs_layoutreturn =3D> nfs4_layoutreturn
>>
>> struct nfs4_pnfs_getdeviceinfo_arg =3D> nfs4_getdeviceinfo_args
>>
>> struct nfs4_pnfs_getdeviceinfo_res =3D> nfs4_getdeviceinfo_res
>>
>> *********
>> include/linux/nfs4.h
>>
>> NFSPROC4_CLNT_PNFS_LAYOUTGET =3D> NFSPROC4_CLNT_LAYOUTGET
>> NFSPROC4_CLNT_PNFS_LAYOUTCOMMIT =3D> NFSPROC4_CLNT_LAYOUTCOMMIT
>> NFSPROC4_CLNT_PNFS_LAYOUTRETURN =3D> NFSPROC4_CLNT_LAYOUTRETURN
>> NFSPROC4_CLNT_PNFS_GETDEVICEINFO =3D> NFSPROC4_CLNT_GETDEVICEINFO
>>
>> *********
>>
>> fs/nfs/nfs4proc.c
>>
>> nfs4_pnfs_layoutget_prepare =3D> nfs4_layoutget_prepare
>> nfs4_pnfs_layoutget_done =3D> nfs4_layoutget_done
>> nfs4_pnfs_layoutget_release =3D> nfs4_layoutget_release
>>
>> _pnfs4_proc_layoutget =3D> _nfs4_proc_layoutget
>> pnfs4_proc_layoutget =3D> nfs4_proc_layoutget
>>
>>
>> pnfs_layoutcommit_prepare =3D> nfs4_layoutcommit_prepare
>> pnfs_layoutcommit_done =3D> nfs4_layoutcommit_done
>> pnfs_layoutcommit_release =3D> nfs4_layoutcommit_release
>>
>> _pnfs4_proc_layoutcommit =3D> _nfs4_proc_layoutcommit
>> pnfs4_proc_layoutcommit =3D> nfs4_proc_layoutcommit
>>
>> nfs4_pnfs_layoutreturn_prepare =3D> nfs4_layoutreturn_prepare
>> nfs4_pnfs_layoutreturn_done =3D> nfs4_layoutreturn_done
>> nfs4_pnfs_layoutreturn_release =3D> nfs4_layoutreturn_release
>>
>> _pnfs4_proc_layoutreturn =3D> _nfs4_proc_layoutreturn
>> pnfs4_proc_layoutreturn =3D> nfs4_proc_layoutreturn
>>
>> nfs4_pnfs_getdeviceinfo =3D> nfs4_proc_getdeviceinfo
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>

Re: pNFS client structure and function rename suggestions

[Boaz Harrosh]

On 07/28/2010 04:48 PM, Fred Isaman wrote:
> On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>>> struct nfs4_pnfs_layout_segment => pnfs_layout_range
>>
>> Isn't this a struct layout4 above?
> 
> No, this is probably the most confusingly named structure of them all,
> and one I would strongly urge be changed along the line of Andy's
> suggestion.
> 
> Fred
> 

We are like a married couple on a freezing night. Each pulling the blanket
to his/her side.

I'm trying to pull the blanket to the side. where all these are converted
to exactly the names and structures as stated by the standard.
That the Linux-pnfs-workgroup tried to invent their own STD is a misfortune
which I missed, getting so late into the game.

What side of the Bed are you pulling to?
I wish you elaborate more, and explain, instead of just saying "NO"

struct layout_content {
           layouttype4 loc_type;
           void      *loc_body;
};

struct layout {
           offset4                 lo_offset;
           length4                 lo_length;
           layoutiomode4           lo_iomode;
           layout_content4         lo_content;
};

struct layoutget_args {
           /* CURRENT_FH: file */
           bool                    loga_signal_layout_avail;
           layouttype4             loga_layout_type;
           layoutiomode4           loga_iomode;
           offset4                 loga_offset;
           length4                 loga_length;
           length4                 loga_minlength;
           stateid4                loga_stateid;
           count4                  loga_maxcount;
};

struct layoutget_res {
           bool               logr_return_on_close;
           stateid4           logr_stateid;
           layout             logr_layout;
};

How is the above less useful then the mess we have now?

Boaz

Re: pNFS client structure and function rename suggestions

[Fred Isaman]

On Wed, Jul 28, 2010 at 10:12 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
> On 07/28/2010 04:48 PM, Fred Isaman wrote:
>> On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>>>> struct nfs4_pnfs_layout_segment => pnfs_layout_range
>>>
>>> Isn't this a struct layout4 above?
>>
>> No, this is probably the most confusingly named structure of them all,
>> and one I would strongly urge be changed along the line of Andy's
>> suggestion.
>>
>> Fred
>>
>
> We are like a married couple on a freezing night. Each pulling the blanket
> to his/her side.
>
> I'm trying to pull the blanket to the side. where all these are converted
> to exactly the names and structures as stated by the standard.
> That the Linux-pnfs-workgroup tried to invent their own STD is a misfortune
> which I missed, getting so late into the game.
>
> What side of the Bed are you pulling to?
> I wish you elaborate more, and explain, instead of just saying "NO"
>

All I meant that "no, this is not the struct layout4 above."

There currently exists:

struct nfs4_pnfs_layout_segment {
	u32 iomode;
	u64 offset;
	u64 length;
};

which is used to hold range information, but which is easy to confuse
with struct pnfs_layout_segment.

I REALLY want the name nfs4_pnfs_layout_segment changed.

When possible, I'm all for changing names to coincide with those used
in the spec.  But note that those structures are most useful for XDR
encoding/decoding, and don't always correspond to the information we
need to pass around internally.

Fred


> struct layout_content {
>           layouttype4 loc_type;
>           void      *loc_body;
> };
>
> struct layout {
>           offset4                 lo_offset;
>           length4                 lo_length;
>           layoutiomode4           lo_iomode;
>           layout_content4         lo_content;
> };
>
> struct layoutget_args {
>           /* CURRENT_FH: file */
>           bool                    loga_signal_layout_avail;
>           layouttype4             loga_layout_type;
>           layoutiomode4           loga_iomode;
>           offset4                 loga_offset;
>           length4                 loga_length;
>           length4                 loga_minlength;
>           stateid4                loga_stateid;
>           count4                  loga_maxcount;
> };
>
> struct layoutget_res {
>           bool               logr_return_on_close;
>           stateid4           logr_stateid;
>           layout             logr_layout;
> };
>
> How is the above less useful then the mess we have now?
>
> Boaz
>

Re: pNFS client structure and function rename suggestions

[Boaz Harrosh]

On 07/28/2010 05:29 PM, Fred Isaman wrote:
> On Wed, Jul 28, 2010 at 10:12 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>> On 07/28/2010 04:48 PM, Fred Isaman wrote:
>>> On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>>>>> struct nfs4_pnfs_layout_segment => pnfs_layout_range
>>>>
>>>> Isn't this a struct layout4 above?
>>>
>>> No, this is probably the most confusingly named structure of them all,
>>> and one I would strongly urge be changed along the line of Andy's
>>> suggestion.
>>>
>>> Fred
>>>
>>
>> We are like a married couple on a freezing night. Each pulling the blanket
>> to his/her side.
>>
>> I'm trying to pull the blanket to the side. where all these are converted
>> to exactly the names and structures as stated by the standard.
>> That the Linux-pnfs-workgroup tried to invent their own STD is a misfortune
>> which I missed, getting so late into the game.
>>
>> What side of the Bed are you pulling to?
>> I wish you elaborate more, and explain, instead of just saying "NO"
>>
> 
> All I meant that "no, this is not the struct layout4 above."
> 
> There currently exists:
> 
> struct nfs4_pnfs_layout_segment {
> 	u32 iomode;
> 	u64 offset;
> 	u64 length;
> };
> 
> which is used to hold range information, but which is easy to confuse
> with struct pnfs_layout_segment.
> 

OK, perhaps the STD failed to define that RANGE structure that got open coded
in lots of operations. Adding that should be a refinement (use the new type
where it is open coded). Not the complete re-ordering and invention of
new structures that carry the same information but different.

> I REALLY want the name nfs4_pnfs_layout_segment changed.
> 

OK Agreed *pnfs_layout_range* is a good name. Because anything nfs4_ is expected
to derive from the STD, and the above is our own invention. Some comments to
that effect could be nice.

> When possible, I'm all for changing names to coincide with those used
> in the spec.  But note that those structures are most useful for XDR
> encoding/decoding, and don't always correspond to the information we
> need to pass around internally.
> 

I wish we could, other then such refinements like the new pnfs_layout_range,
stick closer to the STD. Including an nfs4_layout structure which corresponds
to the layout4 from RFC.

> Fred
> 

(I know, words are cheep, I wish I had the time, busy with raid5/6. Just my
 $0.017)

Boaz

Re: pNFS client structure and function rename suggestions

[Benny Halevy]

On Jul. 28, 2010, 18:10 +0300, Boaz Harrosh <bharrosh@panasas.com> wrote:
> On 07/28/2010 05:29 PM, Fred Isaman wrote:
>> On Wed, Jul 28, 2010 at 10:12 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>>> On 07/28/2010 04:48 PM, Fred Isaman wrote:
>>>> On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>>>>>> struct nfs4_pnfs_layout_segment => pnfs_layout_range
>>>>>
>>>>> Isn't this a struct layout4 above?
>>>>
>>>> No, this is probably the most confusingly named structure of them all,
>>>> and one I would strongly urge be changed along the line of Andy's
>>>> suggestion.
>>>>
>>>> Fred
>>>>
>>>
>>> We are like a married couple on a freezing night. Each pulling the blanket
>>> to his/her side.
>>>
>>> I'm trying to pull the blanket to the side. where all these are converted
>>> to exactly the names and structures as stated by the standard.
>>> That the Linux-pnfs-workgroup tried to invent their own STD is a misfortune
>>> which I missed, getting so late into the game.
>>>
>>> What side of the Bed are you pulling to?
>>> I wish you elaborate more, and explain, instead of just saying "NO"
>>>
>>
>> All I meant that "no, this is not the struct layout4 above."
>>
>> There currently exists:
>>
>> struct nfs4_pnfs_layout_segment {
>> 	u32 iomode;
>> 	u64 offset;
>> 	u64 length;
>> };
>>
>> which is used to hold range information, but which is easy to confuse
>> with struct pnfs_layout_segment.
>>
> 
> OK, perhaps the STD failed to define that RANGE structure that got open coded
> in lots of operations. Adding that should be a refinement (use the new type
> where it is open coded). Not the complete re-ordering and invention of
> new structures that carry the same information but different.
> 
>> I REALLY want the name nfs4_pnfs_layout_segment changed.
>>
> 
> OK Agreed *pnfs_layout_range* is a good name. Because anything nfs4_ is expected
> to derive from the STD, and the above is our own invention. Some comments to
> that effect could be nice.
> 

I'm ok with _range, though it is a bit more than a range since it also has an iomode

I propose pnfs_layout_hdr to replace pnfs_layout_type.

Benny

>> When possible, I'm all for changing names to coincide with those used
>> in the spec.  But note that those structures are most useful for XDR
>> encoding/decoding, and don't always correspond to the information we
>> need to pass around internally.
>>
> 
> I wish we could, other then such refinements like the new pnfs_layout_range,
> stick closer to the STD. Including an nfs4_layout structure which corresponds
> to the layout4 from RFC.
> 
>> Fred
>>
> 
> (I know, words are cheep, I wish I had the time, busy with raid5/6. Just my
>  $0.017)
> 
> Boaz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pNFS client structure and function rename suggestions

[Andy Adamson]

On Aug 2, 2010, at 10:39 AM, Benny Halevy wrote:

> On Jul. 28, 2010, 18:10 +0300, Boaz Harrosh <bharrosh@panasas.com> wrote:
>> On 07/28/2010 05:29 PM, Fred Isaman wrote:
>>> On Wed, Jul 28, 2010 at 10:12 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>>>> On 07/28/2010 04:48 PM, Fred Isaman wrote:
>>>>> On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>>>>>>> struct nfs4_pnfs_layout_segment => pnfs_layout_range
>>>>>> 
>>>>>> Isn't this a struct layout4 above?
>>>>> 
>>>>> No, this is probably the most confusingly named structure of them all,
>>>>> and one I would strongly urge be changed along the line of Andy's
>>>>> suggestion.
>>>>> 
>>>>> Fred
>>>>> 
>>>> 
>>>> We are like a married couple on a freezing night. Each pulling the blanket
>>>> to his/her side.
>>>> 
>>>> I'm trying to pull the blanket to the side. where all these are converted
>>>> to exactly the names and structures as stated by the standard.
>>>> That the Linux-pnfs-workgroup tried to invent their own STD is a misfortune
>>>> which I missed, getting so late into the game.
>>>> 
>>>> What side of the Bed are you pulling to?
>>>> I wish you elaborate more, and explain, instead of just saying "NO"
>>>> 
>>> 
>>> All I meant that "no, this is not the struct layout4 above."
>>> 
>>> There currently exists:
>>> 
>>> struct nfs4_pnfs_layout_segment {
>>> 	u32 iomode;
>>> 	u64 offset;
>>> 	u64 length;
>>> };
>>> 
>>> which is used to hold range information, but which is easy to confuse
>>> with struct pnfs_layout_segment.
>>> 
>> 
>> OK, perhaps the STD failed to define that RANGE structure that got open coded
>> in lots of operations. Adding that should be a refinement (use the new type
>> where it is open coded). Not the complete re-ordering and invention of
>> new structures that carry the same information but different.
>> 
>>> I REALLY want the name nfs4_pnfs_layout_segment changed.
>>> 
>> 
>> OK Agreed *pnfs_layout_range* is a good name. Because anything nfs4_ is expected
>> to derive from the STD, and the above is our own invention. Some comments to
>> that effect could be nice.
>> 
> 
> I'm ok with _range, though it is a bit more than a range since it also has an iomode
> 
> I propose pnfs_layout_hdr to replace pnfs_layout_type.

I like pnfs_layout_hdr.

-->Andy

> 
> Benny
> 
>>> When possible, I'm all for changing names to coincide with those used
>>> in the spec.  But note that those structures are most useful for XDR
>>> encoding/decoding, and don't always correspond to the information we
>>> need to pass around internally.
>>> 
>> 
>> I wish we could, other then such refinements like the new pnfs_layout_range,
>> stick closer to the STD. Including an nfs4_layout structure which corresponds
>> to the layout4 from RFC.
>> 
>>> Fred
>>> 
>> 
>> (I know, words are cheep, I wish I had the time, busy with raid5/6. Just my
>> $0.017)
>> 
>> Boaz
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html