All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: xiubli@redhat.com, idryomov@gmail.com, zyan@redhat.com
Cc: sage@redhat.com, pdonnell@redhat.com, hch@infradead.org,
	ceph-devel@vger.kernel.org
Subject: Re: [RFC PATCH v2] ceph: do not execute direct write in parallel if O_APPEND is specified
Date: Tue, 04 Feb 2020 09:35:21 -0500	[thread overview]
Message-ID: <fd6b6bf9247cbdc1be03637196d54feacce0d72c.camel@kernel.org> (raw)
In-Reply-To: <20200204022825.26538-1-xiubli@redhat.com>

On Mon, 2020-02-03 at 21:28 -0500, xiubli@redhat.com wrote:
> From: Xiubo Li <xiubli@redhat.com>
> 
> In O_APPEND & O_DIRECT mode, the data from different writers will
> be possiblly overlapping each other with shared lock.
> 
> For example, both Writer1 and Writer2 are in O_APPEND and O_DIRECT
> mode:
> 
>           Writer1                         Writer2
> 
>      shared_lock()                   shared_lock()
>      getattr(CAP_SIZE)               getattr(CAP_SIZE)
>      iocb->ki_pos = EOF              iocb->ki_pos = EOF
>      write(data1)
>                                      write(data2)
>      shared_unlock()                 shared_unlock()
> 
> The data2 will overlap the data1 from the same file offset, the
> old EOF.
> 
> Switch to exclusive lock instead when O_APPEND is specified.
> 
> Signed-off-by: Xiubo Li <xiubli@redhat.com>
> ---
> 
> Changed in V2:
> - fix the commit comment
> - add more detail in the commit comment
> - s/direct_lock/shared_lock/g
> 
>  fs/ceph/file.c | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> index ac7fe8b8081c..e3e67ef215dd 100644
> --- a/fs/ceph/file.c
> +++ b/fs/ceph/file.c
> @@ -1475,6 +1475,7 @@ static ssize_t ceph_write_iter(struct kiocb *iocb, struct iov_iter *from)
>  	struct ceph_cap_flush *prealloc_cf;
>  	ssize_t count, written = 0;
>  	int err, want, got;
> +	bool shared_lock = false;
>  	loff_t pos;
>  	loff_t limit = max(i_size_read(inode), fsc->max_file_size);
>  
> @@ -1485,8 +1486,11 @@ static ssize_t ceph_write_iter(struct kiocb *iocb, struct iov_iter *from)
>  	if (!prealloc_cf)
>  		return -ENOMEM;
>  
> +	if ((iocb->ki_flags & (IOCB_DIRECT | IOCB_APPEND)) == IOCB_DIRECT)
> +		shared_lock = true;
> +
>  retry_snap:
> -	if (iocb->ki_flags & IOCB_DIRECT)
> +	if (shared_lock)
>  		ceph_start_io_direct(inode);
>  	else
>  		ceph_start_io_write(inode);
> @@ -1576,14 +1580,15 @@ static ssize_t ceph_write_iter(struct kiocb *iocb, struct iov_iter *from)
>  
>  		/* we might need to revert back to that point */
>  		data = *from;
> -		if (iocb->ki_flags & IOCB_DIRECT) {
> +		if (iocb->ki_flags & IOCB_DIRECT)
>  			written = ceph_direct_read_write(iocb, &data, snapc,
>  							 &prealloc_cf);
> -			ceph_end_io_direct(inode);
> -		} else {
> +		else
>  			written = ceph_sync_write(iocb, &data, pos, snapc);
> +		if (shared_lock)
> +			ceph_end_io_direct(inode);
> +		else
>  			ceph_end_io_write(inode);
> -		}
>  		if (written > 0)
>  			iov_iter_advance(from, written);
>  		ceph_put_snap_context(snapc);
> @@ -1634,7 +1639,7 @@ static ssize_t ceph_write_iter(struct kiocb *iocb, struct iov_iter *from)
>  
>  	goto out_unlocked;
>  out:
> -	if (iocb->ki_flags & IOCB_DIRECT)
> +	if (shared_lock)
>  		ceph_end_io_direct(inode);
>  	else
>  		ceph_end_io_write(inode);

Ok, I think this looks reasonable, but I actually preferred the
"direct_lock" name you had before. I'm going to do some testing today
and will probably merge this (with s/shared_lock/direct_lock/) if it
tests out ok.

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2020-02-04 14:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04  2:28 [RFC PATCH v2] ceph: do not execute direct write in parallel if O_APPEND is specified xiubli
2020-02-04 14:35 ` Jeff Layton [this message]
2020-02-04 14:44   ` Xiubo Li

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=fd6b6bf9247cbdc1be03637196d54feacce0d72c.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=idryomov@gmail.com \
    --cc=pdonnell@redhat.com \
    --cc=sage@redhat.com \
    --cc=xiubli@redhat.com \
    --cc=zyan@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.