On 07/28/2010 04:48 PM, Fred Isaman wrote:
> On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <[email protected]> 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
On Wed, Jul 28, 2010 at 10:12 AM, Boaz Harrosh <[email protected]> wrote:
> On 07/28/2010 04:48 PM, Fred Isaman wrote:
>> On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <[email protected]> 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
>
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
>
On 07/28/2010 05:29 PM, Fred Isaman wrote:
> On Wed, Jul 28, 2010 at 10:12 AM, Boaz Harrosh <[email protected]> wrote:
>> On 07/28/2010 04:48 PM, Fred Isaman wrote:
>>> On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <[email protected]> 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
On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <[email protected]> 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 [email protected]
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
On Aug 2, 2010, at 10:39 AM, Benny Halevy wrote:
> On Jul. 28, 2010, 18:10 +0300, Boaz Harrosh <[email protected]> wrote:
>> On 07/28/2010 05:29 PM, Fred Isaman wrote:
>>> On Wed, Jul 28, 2010 at 10:12 AM, Boaz Harrosh <[email protected]> wrote:
>>>> On 07/28/2010 04:48 PM, Fred Isaman wrote:
>>>>> On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <[email protected]> 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 [email protected]
>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Jul. 28, 2010, 18:10 +0300, Boaz Harrosh <[email protected]> wrote:
> On 07/28/2010 05:29 PM, Fred Isaman wrote:
>> On Wed, Jul 28, 2010 at 10:12 AM, Boaz Harrosh <[email protected]> wrote:
>>> On 07/28/2010 04:48 PM, Fred Isaman wrote:
>>>> On Wed, Jul 28, 2010 at 7:09 AM, Boaz Harrosh <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html