linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Drokin, Oleg" <oleg.drokin@intel.com>
Cc: "<linux-fsdevel@vger.kernel.org>" <linux-fsdevel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <david@fromorbit.com>, Theodore Ts'o <tytso@mit.edu>,
	Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: [RFC] write(2) semantics wrt return values and current position
Date: Mon, 6 Apr 2015 21:09:22 +0100	[thread overview]
Message-ID: <20150406200922.GP889@ZenIV.linux.org.uk> (raw)
In-Reply-To: <9FE2E968-DF4D-43F7-858C-81A13F2C0A75@intel.com>

On Mon, Apr 06, 2015 at 08:04:01PM +0000, Drokin, Oleg wrote:
> Hello!
> 
> On Apr 6, 2015, at 12:02 PM, Al Viro wrote:
> > 	2) should we ever update the current position when write() returns 0?
> > IOW, what effect should zero-length write() on O_APPEND file have upon its
> > current position?  POSIX seems to imply that it should do nothing, and
> > generally that's what happens, but e.g. ext4 *does* update position to
> > the EOF, whether we will write anything or not.  So does FUSE when server
> > requests to bypass the page cache.  AFAICS, lustre is the same way,
> > but I might be missing something; everything else definitely does not
> 
> Lustre is not the same way.
> drivers/staging/lustre/lustre/llite/file.c::ll_file_io_generic() has this
>         if (io-> ci_nob > 0) {
>                 result = io->ci_nob;
>                 *ppos = io->u.ci_wr.wr.crw_pos;
>         }
> 
> and ppos is passed in as &iocb->ki_pos. ci_nob is number of bytes that we managed to read/write,
> and if it was 0 (either due to 0 bytes io request or due to error from the get go)
> we won't update it.

Eh? vvp_io_write_start():
                result = generic_file_write_iter(cio->cui_iocb, cio->cui_iter);

  reply	other threads:[~2015-04-06 20:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-06 16:02 [RFC] write(2) semantics wrt return values and current position Al Viro
2015-04-06 18:13 ` Linus Torvalds
2015-04-06 19:29   ` Al Viro
2015-04-06 19:50     ` Al Viro
2015-04-06 20:04 ` Drokin, Oleg
2015-04-06 20:09   ` Al Viro [this message]
2015-04-06 20:39     ` Drokin, Oleg
2015-04-07 15:25 ` Christoph Hellwig
2015-04-08 19:24 ` Al Viro
2015-04-08 20:57   ` Al Viro
2015-04-08 21:20     ` Al Viro
2015-04-09  4:48       ` Junxiao Bi
2015-04-09 11:23         ` Al Viro
2015-04-09 11:42           ` Al Viro
2015-04-10 14:31             ` Junxiao Bi

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=20150406200922.GP889@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=oleg.drokin@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=trond.myklebust@primarydata.com \
    --cc=tytso@mit.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).