From: Li Wang <liwang@ubuntukylin.com>
To: "Yan, Zheng" <ukernel@gmail.com>
Cc: ceph-devel <ceph-devel@vger.kernel.org>,
Sage Weil <sage@inktank.com>,
Yunchuan Wen <yunchuanwen@ubuntukylin.com>
Subject: Re: [PATCH 17/18] client: Write inline data path
Date: Mon, 02 Dec 2013 16:03:58 +0800 [thread overview]
Message-ID: <529C3EEE.3080604@ubuntukylin.com> (raw)
In-Reply-To: <CAAM7YAnwL4xdY0wysN46yVgb2=MciNA5DGV4Ac=nYgQi4vcfPw@mail.gmail.com>
Hi Zheng,
Thanks for your comments.
Regarding the configuration option, it is in our original plan, and
we will make it appear soon in the incoming next version :)
For the write optimization, it does remind us to do an optimization,
that is, if the inline data length is zero, we won't bother to do the
migration. This will capture the situation that application has a write
buffer larger than the inline threshold, the sequential write will not
incur migration. And another situation that client performs some inline
read/write, then truncate it to zero, then start write after the inline
threshold.
Cheers,
Li Wang
On 11/28/2013 11:02 AM, Yan, Zheng wrote:
> On Wed, Nov 27, 2013 at 9:40 PM, Li Wang <liwang@ubuntukylin.com> wrote:
>> Signed-off-by: Yunchuan Wen <yunchuanwen@ubuntukylin.com>
>> Signed-off-by: Li Wang <liwang@ubuntukylin.com>
>> ---
>> src/client/Client.cc | 55 +++++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 54 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/client/Client.cc b/src/client/Client.cc
>> index 6b08155..c913e35 100644
>> --- a/src/client/Client.cc
>> +++ b/src/client/Client.cc
>> @@ -6215,6 +6215,41 @@ int Client::_write(Fh *f, int64_t offset, uint64_t size, const char *buf)
>>
>> ldout(cct, 10) << " snaprealm " << *in->snaprealm << dendl;
>>
>> + Mutex uninline_flock("Clinet::_write_uninline_data flock");
>> + Cond uninline_cond;
>> + bool uninline_done = false;
>> + int uninline_ret = 0;
>> + Context *onuninline = NULL;
>> +
>> + if (in->inline_version < CEPH_INLINE_NONE) {
>> + if (endoff > CEPH_INLINE_SIZE || !(have & CEPH_CAP_FILE_BUFFER)) {
>> + onuninline = new C_SafeCond(&uninline_flock,
>> + &uninline_cond,
>> + &uninline_done,
>> + &uninline_ret);
>> + uninline_data(in, onuninline);
>
> If client does 4k sequence write, the second write always trigger the
> "uninline" procedure, this is suboptimal. It's better to just copy the
> inline data to the object cacher.
>
> Besides, this feature should be disabled by default because it's not
> compatible with old clients and it imposes overhead on the mds. we
> need to use a config option or directory attribute to enable it.
>
> Regards
> Yan, Zheng
>
>
>> + } else {
>> + get_cap_ref(in, CEPH_CAP_FILE_BUFFER);
>> +
>> + uint32_t len = in->inline_data.length();
>> +
>> + if (endoff < len)
>> + in->inline_data.copy(endoff, len - endoff, bl);
>> +
>> + if (offset < len)
>> + in->inline_data.splice(offset, len - offset);
>> + else if (offset > len)
>> + in->inline_data.append_zero(offset - len);
>> +
>> + in->inline_data.append(bl);
>> + in->inline_version++;
>> +
>> + put_cap_ref(in, CEPH_CAP_FILE_BUFFER);
>> +
>> + goto success;
>> + }
>> + }
>> +
>> if (cct->_conf->client_oc && (have & CEPH_CAP_FILE_BUFFER)) {
>> // do buffered write
>> if (!in->oset.dirty_or_tx)
>> @@ -6265,7 +6300,7 @@ int Client::_write(Fh *f, int64_t offset, uint64_t size, const char *buf)
>> }
>>
>> // if we get here, write was successful, update client metadata
>> -
>> +success:
>> // time
>> lat = ceph_clock_now(cct);
>> lat -= start;
>> @@ -6293,6 +6328,24 @@ int Client::_write(Fh *f, int64_t offset, uint64_t size, const char *buf)
>> mark_caps_dirty(in, CEPH_CAP_FILE_WR);
>>
>> done:
>> +
>> + if (onuninline) {
>> + client_lock.Unlock();
>> + uninline_flock.Lock();
>> + while (!uninline_done)
>> + uninline_cond.Wait(uninline_flock);
>> + uninline_flock.Unlock();
>> + client_lock.Lock();
>> +
>> + if (uninline_ret >= 0 || uninline_ret == -ECANCELED) {
>> + in->inline_data.clear();
>> + in->inline_version = CEPH_INLINE_NONE;
>> + mark_caps_dirty(in, CEPH_CAP_FILE_WR);
>> + check_caps(in, false);
>> + } else
>> + r = uninline_ret;
>> + }
>> +
>> put_cap_ref(in, CEPH_CAP_FILE_WR);
>> return r;
>> }
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2013-12-02 8:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-27 13:40 [PATCH v3 00/18] ceph: Inline data support Li Wang
2013-11-27 13:40 ` [PATCH 01/18] ceph: Add inline data feature Li Wang
2013-11-27 13:40 ` [PATCH 02/18] ceph: Add inline state definition Li Wang
2013-11-27 13:40 ` [PATCH 03/18] mds: Add inline fields to inode_t Li Wang
2013-11-27 13:40 ` [PATCH 04/18] mds: Add inline encode/decode " Li Wang
2013-11-27 13:40 ` [PATCH 05/18] ceph: Add inline fields to MClientCaps Li Wang
2013-11-27 13:40 ` [PATCH 06/18] osdc: Add write method with truncate parameters Li Wang
2013-11-27 13:40 ` [PATCH 07/18] mds: Add inline fields to Capability Li Wang
2013-11-27 13:40 ` [PATCH 08/18] mds: Push inline data to client in cap message Li Wang
2013-11-27 13:40 ` [PATCH 09/18] ceph: Add inline fields to InodeStat Li Wang
2013-11-27 13:40 ` [PATCH 10/18] mds: Push inline data to client in inodestat Li Wang
2013-11-27 13:40 ` [PATCH 11/18] mds: Receive updated inline data from client Li Wang
2013-11-27 13:40 ` [PATCH 12/18] client: Add inline fields to Inode Li Wang
2013-11-27 13:40 ` [PATCH 13/18] client: Receive inline data pushed from mds Li Wang
2013-11-27 13:40 ` [PATCH 14/18] client: Push inline data to mds by send cap Li Wang
2013-11-27 13:40 ` [PATCH 15/18] client: Add inline data migration helper Li Wang
2013-11-27 13:40 ` [PATCH 16/18] client: Read inline data path Li Wang
2013-11-27 13:40 ` [PATCH 17/18] client: Write " Li Wang
2013-11-28 3:02 ` Yan, Zheng
2013-11-29 17:01 ` Matt W. Benjamin
2013-12-02 8:20 ` Li Wang
2013-12-02 8:03 ` Li Wang [this message]
2013-11-27 13:40 ` [PATCH 18/18] client: Fallocate " Li Wang
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=529C3EEE.3080604@ubuntukylin.com \
--to=liwang@ubuntukylin.com \
--cc=ceph-devel@vger.kernel.org \
--cc=sage@inktank.com \
--cc=ukernel@gmail.com \
--cc=yunchuanwen@ubuntukylin.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.