From: Harris, James R <james.r.harris at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] Handling of physical disk removals
Date: Fri, 01 Jun 2018 16:54:03 +0000 [thread overview]
Message-ID: <A07631C3-3DBD-4F7F-B557-28CD62A5B6DB@intel.com> (raw)
In-Reply-To: CAKye4QbhELsBk2tdaAy1pW75P6Qq5Tcbt2ds97oujp1==s=Gvg@mail.gmail.com
[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]
From: SPDK <spdk-bounces(a)lists.01.org> on behalf of Baruch Even <baruch(a)weka.io>
Reply-To: Storage Performance Development Kit <spdk(a)lists.01.org>
Date: Friday, June 1, 2018 at 1:25 AM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: Re: [SPDK] Handling of physical disk removals
[…]
In regards to your concerns on I/O splitting - I think step one is making sure the driver has APIs to expose any device-specific characteristics such as sectors per stripe. Step two is measuring the overhead of the splitting logic when splitting is not required. Based on those measurements, we can consider optimizations and/or evaluate a bypass mode. The bypass mode seems important to Weka.io – would you like to submit an RFC for what this bypass mode might look like in more detail?
What is needed for the RFC?
It doesn’t need to be especially formal. Basically, what your new API would look like and how it would impact the existing code at a reasonable level of detail. Also, what tests you would plan to add to automate testing of the new API. An RFC typically comes with an assumption that the author plans to carry the work forward if and when a consensus has been reached. If that assumption is not correct, it is best to clarify that up front.
Any kind of empirical performance data is critical. I’m really interested in seeing it. The existing driver can get >4M IO/s on a single Xeon core, so the extra complexity and maintenance burden of the new API has to show demonstrable improvements. Hopefully there would be no changes to the existing API, but if there are, that’s another data point that would need to be considered.
Baruch
--
[https://docs.google.com/uc?export=download&id=1w6mlhCJZRlvqVOKRoulFtalU3TMY41VY&revid=0Bw_6cJeSSMVJR2JMQzdxV3VqVi9IWFNDM1FVcnFoRlc2NkJzPQ]
Baruch Even, Software Developer
E baruch(a)weka.io<mailto:liran(a)weka.io>
www.weka.io<http://www.weka.io>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 6267 bytes --]
next reply other threads:[~2018-06-01 16:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-01 16:54 Harris, James R [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-06-03 8:35 [SPDK] Handling of physical disk removals Baruch Even
2018-06-01 8:27 Baruch Even
2018-06-01 8:25 Baruch Even
2018-05-31 19:01 Andrey Kuzmin
2018-05-31 16:33 Verkamp, Daniel
2018-05-31 16:24 Harris, James R
2018-05-31 7:54 Andrey Kuzmin
2018-05-31 7:37 Baruch Even
2018-05-31 7:24 Baruch Even
2018-05-30 21:27 Walker, Benjamin
2018-05-30 17:49 Andrey Kuzmin
2018-05-30 11:46 Baruch Even
2018-05-24 16:44 Walker, Benjamin
2018-05-24 8:16 Baruch Even
2018-05-23 17:18 Harris, James R
2018-05-23 8:44 Baruch Even
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=A07631C3-3DBD-4F7F-B557-28CD62A5B6DB@intel.com \
--to=spdk@lists.01.org \
/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