Hi All
I am looking at the fs/nfsd/vfs.c:nfsd_create_v3 function.
In there, a comment says:
"furthermore, if the size is nonzero, we should ignore it
according to spec!"
Could someone please point out the section in RFC1813 where this
particular point is specified?
Thanks
Shehjar
J. Bruce Fields wrote:
> On Fri, Jun 26, 2009 at 02:40:12PM +0530, Shehjar Tikoo wrote:
>> Hi All
>>
>> I am looking at the fs/nfsd/vfs.c:nfsd_create_v3 function. In
>> there, a comment says: "furthermore, if the size is nonzero, we
>> should ignore it according to spec!"
>>
>> Could someone please point out the section in RFC1813 where this
>> particular point is specified?
>
> It's referring to the third paragraph of the DESCRIPTION section of
> the OPEN operation (14.2.16) in rfc 3530.
>
> --b.
Ok.
For NFSv3, is there a specified way to handle create or mkdir ops where
the size is non-zero? The reason this came up is that I was testing
unfs3 with SpecSFS2k8 and an MKDIR op failed in unfs3 because SFS sent
the mkdir call with non-zero size in the attributes. I just wanted to
see how Linux nfsd handled it.
Thanks
-Shehjar
Shehjar Tikoo wrote:
> J. Bruce Fields wrote:
>> On Fri, Jun 26, 2009 at 02:40:12PM +0530, Shehjar Tikoo wrote:
>>> Hi All
>>>
>>> I am looking at the fs/nfsd/vfs.c:nfsd_create_v3 function. In
>>> there, a comment says: "furthermore, if the size is nonzero, we
>>> should ignore it according to spec!"
>>>
>>> Could someone please point out the section in RFC1813 where this
>>> particular point is specified?
>>
>> It's referring to the third paragraph of the DESCRIPTION section of
>> the OPEN operation (14.2.16) in rfc 3530.
>>
>> --b.
> Ok.
>
> For NFSv3, is there a specified way to handle create or mkdir ops where
> the size is non-zero? The reason this came up is that I was testing
> unfs3 with SpecSFS2k8 and an MKDIR op failed in unfs3 because SFS sent
> the mkdir call with non-zero size in the attributes. I just wanted to
> see how Linux nfsd handled it.
>
Most servers in the market just ignore the size field for
MKDIR requests. They also ignore the size field, unless it is
0, for CREATE requests.
Setting the size on a directory does not make sense and the
usual decision point for file creation is whether to truncate
the file to empty or not.
ps
On Wed, Aug 26, 2009 at 09:38:46AM -0400, Peter Staubach wrote:
> Shehjar Tikoo wrote:
> > J. Bruce Fields wrote:
> >> On Fri, Jun 26, 2009 at 02:40:12PM +0530, Shehjar Tikoo wrote:
> >>> Hi All
> >>>
> >>> I am looking at the fs/nfsd/vfs.c:nfsd_create_v3 function. In
> >>> there, a comment says: "furthermore, if the size is nonzero, we
> >>> should ignore it according to spec!"
> >>>
> >>> Could someone please point out the section in RFC1813 where this
> >>> particular point is specified?
> >>
> >> It's referring to the third paragraph of the DESCRIPTION section of
> >> the OPEN operation (14.2.16) in rfc 3530.
> >>
> >> --b.
> > Ok.
> >
> > For NFSv3, is there a specified way to handle create or mkdir ops where
> > the size is non-zero? The reason this came up is that I was testing
> > unfs3 with SpecSFS2k8 and an MKDIR op failed in unfs3 because SFS sent
> > the mkdir call with non-zero size in the attributes. I just wanted to
> > see how Linux nfsd handled it.
But you've only seen the problem against unfs3, not against the kernel
nfsd?
>
> Most servers in the market just ignore the size field for
> MKDIR requests. They also ignore the size field, unless it is
> 0, for CREATE requests.
So it's probably a bug on both sides. (SpecSFS shouldn't be sending a
non-zero size either.)
--b.
>
> Setting the size on a directory does not make sense and the
> usual decision point for file creation is whether to truncate
> the file to empty or not.
>
> ps
> --
> 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
J. Bruce Fields wrote:
> On Wed, Aug 26, 2009 at 09:38:46AM -0400, Peter Staubach wrote:
>> Shehjar Tikoo wrote:
>>> J. Bruce Fields wrote:
>>>> On Fri, Jun 26, 2009 at 02:40:12PM +0530, Shehjar Tikoo wrote:
>>>>> Hi All
>>>>>
>>>>> I am looking at the fs/nfsd/vfs.c:nfsd_create_v3 function. In
>>>>> there, a comment says: "furthermore, if the size is nonzero, we
>>>>> should ignore it according to spec!"
>>>>>
>>>>> Could someone please point out the section in RFC1813 where this
>>>>> particular point is specified?
>>>> It's referring to the third paragraph of the DESCRIPTION section of
>>>> the OPEN operation (14.2.16) in rfc 3530.
>>>>
>>>> --b.
>>> Ok.
>>>
>>> For NFSv3, is there a specified way to handle create or mkdir ops where
>>> the size is non-zero? The reason this came up is that I was testing
>>> unfs3 with SpecSFS2k8 and an MKDIR op failed in unfs3 because SFS sent
>>> the mkdir call with non-zero size in the attributes. I just wanted to
>>> see how Linux nfsd handled it.
>
> But you've only seen the problem against unfs3, not against the kernel
> nfsd?
>
I didnt test SFS against the kernel nfsd so cant comment on it.
>> Most servers in the market just ignore the size field for
>> MKDIR requests. They also ignore the size field, unless it is
>> 0, for CREATE requests.
>
> So it's probably a bug on both sides. (SpecSFS shouldn't be sending a
> non-zero size either.)
>
Yes, I fixed the problem in unfs3 by making it ignore the size in
the MKDIR request. SpecSFS might need further investigation.
Thanks
-Shehjar
> --b.
>
>> Setting the size on a directory does not make sense and the
>> usual decision point for file creation is whether to truncate
>> the file to empty or not.
>>
>> ps
>> --
>> 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 Fri, Jun 26, 2009 at 02:40:12PM +0530, Shehjar Tikoo wrote:
> Hi All
>
> I am looking at the fs/nfsd/vfs.c:nfsd_create_v3 function.
> In there, a comment says:
> "furthermore, if the size is nonzero, we should ignore it
> according to spec!"
>
> Could someone please point out the section in RFC1813 where this
> particular point is specified?
It's referring to the third paragraph of the DESCRIPTION section of the
OPEN operation (14.2.16) in rfc 3530.
--b.