From: Shehjar Tikoo <shehjart-+FkPdpiNhgJBDgjK7y7TUQ@public.gmane.org>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Peter Staubach <staubach@redhat.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Reference to file size in nfsd_create_v3
Date: Thu, 27 Aug 2009 11:49:36 +0530 [thread overview]
Message-ID: <4A962578.5000509@gluster.com> (raw)
In-Reply-To: <20090826160444.GC18070@fieldses.org>
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 majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2009-08-27 6:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-26 9:10 Reference to file size in nfsd_create_v3 Shehjar Tikoo
[not found] ` <4A449074.6060600-+FkPdpiNhgJBDgjK7y7TUQ@public.gmane.org>
2009-08-25 16:18 ` J. Bruce Fields
2009-08-26 7:10 ` Shehjar Tikoo
[not found] ` <4A94DFDA.4040508-+FkPdpiNhgJBDgjK7y7TUQ@public.gmane.org>
2009-08-26 13:38 ` Peter Staubach
2009-08-26 16:04 ` J. Bruce Fields
2009-08-27 6:19 ` Shehjar Tikoo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A962578.5000509@gluster.com \
--to=shehjart-+fkpdpinhgjbdgjk7y7tuq@public.gmane.org \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=staubach@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.