All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Nelson <mnelson@redhat.com>
To: Sage Weil <sage@newdream.net>, "Chen, Xiaoxi" <xiaoxi.chen@intel.com>
Cc: Haomai Wang <haomaiwang@gmail.com>,
	Somnath Roy <Somnath.Roy@sandisk.com>,
	"Duan, Jiangang" <jiangang.duan@intel.com>,
	"Zhang, Jian" <jian.zhang@intel.com>,
	ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: 回复: Re: 回复: Re: 回复: Re: NewStore performance analysis
Date: Tue, 21 Apr 2015 18:59:08 -0500	[thread overview]
Message-ID: <5536E44C.20302@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1504211654560.18547@cobra.newdream.net>

On 04/21/2015 06:57 PM, Sage Weil wrote:
> On Tue, 21 Apr 2015, Chen, Xiaoxi wrote:
>> ---- Sage Weil?? ----
>>
>>> On Tue, 21 Apr 2015, Chen, Xiaoxi wrote:
>>>> Haomai is right in theory, but I am not sure whether all
>>>> user(mon,filestore,kvstore) of submit_transaction API clearly holding
>>>> the expectation that their data is not persistent and may lost in
>>>> failure.  So in rocksdb now the sync is default to true even in
>>>> submit_transaction(and this option make the two api exactly the same).
>>>> Maybe we need to rename the api to
>>>> submit_transaction_persistent/nonpersistent to better discribe the
>>>> behavior?
>>>
>>> Let's audit them, then.. I think they are right, but we may as well
>>> confirm!
>>>
>>> Again, FileStore is the odd one out here because it is relying on the
>>> syncfs(2) at commit time for everything.
>>>
>>
>> Yes, so maybe we dont need to expose the option to user, we can decide
>> whether to.sync in code logic.
>
> Yeah, I think it'll reduce confusion too.  I suggest we do a pull request
> against master that does this... let me know if you want to do it,
> otherwise I will!
>
>> I remember some folks in out team tried to move KVDB to a partition on
>> SSD while leave other filestore data on HDD, in my memory it benifit
>> performance.  This deployment is problematic with kv_sync=false.  gWill
>> check the data first and then we can evaluate whethe we want to support
>> this kind of deployment.
>
> We could detect this by doing a stat(2) on the current/omap/ vs current/
> dirs and checking if it's a different file system.  If so, we can do the
> syncfs(2) on both dirs.  The btrfs case would probably not be practical,
> but we can error out in that case.  But yeah not sure how important it
> would be to support this since filestore doesn't use leveldb that
> heavily... and I'd prefer to limit our investment of time there if we can
> instead make newstore (or something else) better.

FWIW, the last time I tried putting leveldb on SSD didn't really help at 
all.  It's been a while so maybe that's changed, but newstore definitely 
seems like the way forward to me.

Mark

  parent reply	other threads:[~2015-04-21 23:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-20 14:59 NewStore performance analysis Chen, Xiaoxi
2015-04-20 15:39 ` Sage Weil
2015-04-20 15:55   ` Mark Nelson
2015-04-20 16:11   ` 回复: " Chen, Xiaoxi
     [not found]     ` <alpine.DEB.2.00.1504200945000.18547@cobra.newdream.net>
2015-04-21  6:43       ` Chen, Xiaoxi
2015-04-21  8:51         ` Haomai Wang
     [not found]           ` <alpine.DEB.2.00.1504211246450.18547@cobra.ne <alpine.DEB.2.00.1504211627110.18547@cobra.newdream.net>
     [not found]             ` <alpine.DEB.2.00.1504211627110.18547@cobra.newdream.net>
2015-04-21 23:47               ` 回复: Re: 回复: " Chen, Xiaoxi
     [not found]                 ` <alpine.DEB.2.00.1504211654560.18547@cobra.newdream.net>
2015-04-21 23:59                   ` Mark Nelson [this message]
2015-04-22  3:34                     ` Chen, Xiaoxi

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=5536E44C.20302@redhat.com \
    --to=mnelson@redhat.com \
    --cc=Somnath.Roy@sandisk.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=haomaiwang@gmail.com \
    --cc=jian.zhang@intel.com \
    --cc=jiangang.duan@intel.com \
    --cc=sage@newdream.net \
    --cc=xiaoxi.chen@intel.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.