All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Peng Tao <bergwolf@gmail.com>
Cc: <linux-nfs@vger.kernel.org>, Peng Tao <tao.peng@emc.com>
Subject: Re: [PATCH RFC 2/3] NFS41: send real write size in layoutget
Date: Sun, 12 Aug 2012 21:40:09 +0300	[thread overview]
Message-ID: <5027F889.6090700@panasas.com> (raw)
In-Reply-To: <5027F63F.8070107@panasas.com>

On 08/12/2012 09:30 PM, Boaz Harrosh wrote:

> So for objects the wasting factor is the actual i_size extending as a cause
> of layout_get, and not the number of pages served. So for us the gain is if
> client, that has a much newer information about i_size, sends it on first
> layout_get. Though extending file size only once on first layout_get and
> not on every layout_get.
> 


I want to clarify here. The i_size does not and must not grow as part of
a layout_get. Only a layout_commit might extend i_size.

the "file-size" I meant above is the current maximum size that can be
described by the inode's layout device-map. The device map does grow on
layout_get both for objects, as well as for example  a CEPH cluster. If we
send i_size from client then we only need extend device-map once during the
complete writeout. (If need extending)

Thanks
Boaz

  reply	other threads:[~2012-08-12 18:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-08  2:03 [PATCH RFC 0/3] NFS41: optimize layoutget Peng Tao
2012-08-08  2:03 ` [PATCH RFC 1/3] NFS: track direct IO left bytes Peng Tao
2012-08-08  2:03 ` [PATCH RFC 2/3] NFS41: send real write size in layoutget Peng Tao
2012-08-08 18:50   ` Myklebust, Trond
2012-08-09  2:24     ` Peng Tao
2012-08-12 18:30   ` Boaz Harrosh
2012-08-12 18:40     ` Boaz Harrosh [this message]
2012-08-13  6:15     ` Peng Tao
2012-08-13  9:44     ` Peng Tao
2012-08-13 20:13       ` Boaz Harrosh
2012-08-13 20:21         ` Myklebust, Trond
2012-08-08  2:03 ` [PATCH RFC 3/3] NFS41: send real read size in layoutget for DIO Peng Tao
2012-08-08 18:57   ` Myklebust, Trond
2012-08-09  2:30     ` Peng Tao
2012-08-12 17:39       ` Boaz Harrosh

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=5027F889.6090700@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=bergwolf@gmail.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=tao.peng@emc.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.