All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH] vfs: pass struct file to do_truncate on O_TRUNC opens
Date: Mon, 15 Mar 2010 18:31:28 -0400	[thread overview]
Message-ID: <1268692288.3040.2.camel@localhost.localdomain> (raw)
In-Reply-To: <1268689152-19168-1-git-send-email-jlayton@redhat.com>

On Mon, 2010-03-15 at 17:39 -0400, Jeff Layton wrote: 
> When a file is opened with O_TRUNC, the truncate processing is handled
> by handle_truncate(). This function however doesn't receive any info
> about the newly instantiated filp, and therefore can't pass that info
> along so that the setattr can use it.
> 
> This makes NFSv4 misbehave. The client does an open and gets a valid
> stateid, and then doesn't use that stateid on the subsequent truncate.
> It uses the zero-stateid instead. Most servers ignore this fact and
> just do the truncate anyway, but some don't like it (notably, RHEL4).
> 
> It seems more correct that since we have a fully instantiated file at
> the time that handle_truncate is called, that we pass that along so
> that the truncate operation can properly use it.

At least in the O_CREAT|O_TRUNC case, we really should modify
nfs4_opendata_alloc() to set the attrs.ia_size to zero, so that the
server does an atomic open(O_CREAT|O_TRUNC) for us (see the DESCRIPTION
paragraph in RFC3530 section 14.2.16). There shouldn't be any need for
an extra truncate RPC call.

Plain open(O_TRUNC) probably does need something along the lines of what
you propose, however.

Cheers
  Trond 


WARNING: multiple messages have this Message-ID (diff)
From: Trond Myklebust <trond.myklebust-41N18TsMXrtuMpJDpNschA@public.gmane.org>
To: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] vfs: pass struct file to do_truncate on O_TRUNC opens
Date: Mon, 15 Mar 2010 18:31:28 -0400	[thread overview]
Message-ID: <1268692288.3040.2.camel@localhost.localdomain> (raw)
In-Reply-To: <1268689152-19168-1-git-send-email-jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Mon, 2010-03-15 at 17:39 -0400, Jeff Layton wrote: 
> When a file is opened with O_TRUNC, the truncate processing is handled
> by handle_truncate(). This function however doesn't receive any info
> about the newly instantiated filp, and therefore can't pass that info
> along so that the setattr can use it.
> 
> This makes NFSv4 misbehave. The client does an open and gets a valid
> stateid, and then doesn't use that stateid on the subsequent truncate.
> It uses the zero-stateid instead. Most servers ignore this fact and
> just do the truncate anyway, but some don't like it (notably, RHEL4).
> 
> It seems more correct that since we have a fully instantiated file at
> the time that handle_truncate is called, that we pass that along so
> that the truncate operation can properly use it.

At least in the O_CREAT|O_TRUNC case, we really should modify
nfs4_opendata_alloc() to set the attrs.ia_size to zero, so that the
server does an atomic open(O_CREAT|O_TRUNC) for us (see the DESCRIPTION
paragraph in RFC3530 section 14.2.16). There shouldn't be any need for
an extra truncate RPC call.

Plain open(O_TRUNC) probably does need something along the lines of what
you propose, however.

Cheers
  Trond 

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-03-15 22:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-15 21:39 [PATCH] vfs: pass struct file to do_truncate on O_TRUNC opens Jeff Layton
2010-03-15 21:39 ` Jeff Layton
2010-03-15 22:31 ` Trond Myklebust [this message]
2010-03-15 22:31   ` Trond Myklebust
2010-03-15 22:47   ` Jeff Layton
2010-03-15 22:50     ` Al Viro
2010-03-15 23:03       ` Jeff Layton
2010-03-15 23:03         ` Jeff Layton
2010-03-16 17:47       ` Valerie Aurora

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=1268692288.3040.2.camel@localhost.localdomain \
    --to=trond.myklebust@fys.uio.no \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.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.