All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Shehjar Tikoo <shehjart-+FkPdpiNhgJBDgjK7y7TUQ@public.gmane.org>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Reference to file size in nfsd_create_v3
Date: Wed, 26 Aug 2009 09:38:46 -0400	[thread overview]
Message-ID: <4A953AE6.1030800@redhat.com> (raw)
In-Reply-To: <4A94DFDA.4040508-+FkPdpiNhgJBDgjK7y7TUQ@public.gmane.org>

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

  parent reply	other threads:[~2009-08-26 13:38 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 [this message]
2009-08-26 16:04           ` J. Bruce Fields
2009-08-27  6:19             ` Shehjar Tikoo

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=4A953AE6.1030800@redhat.com \
    --to=staubach@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=shehjart-+FkPdpiNhgJBDgjK7y7TUQ@public.gmane.org \
    /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.