linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Akira Hayakawa <ruby.wktk@gmail.com>
To: ejt@redhat.com
Cc: Greg KH <gregkh@linuxfoundation.org>,
	snitzer@redhat.com, dm-devel@redhat.com,
	driverdev-devel@linuxdriverproject.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] staging: writeboost: Add dm-writeboost
Date: Sat, 21 Feb 2015 10:36:53 +0900	[thread overview]
Message-ID: <54E7E135.3060507@gmail.com> (raw)
In-Reply-To: <20150220161759.GC4740@debian>

To be clear, bio's semantics doesn't require a io is written on
persistent medium before any ack. The border line is that ios that's acked
are persitent before ack to REQ_FLUSH request.
So, writing on the volatile buffer (log chunk in this case) and then ack
is safe if the data gets persistent before some future REQ_FLUSH
request is acked. That's dm-writeboost does.
And in general, ack should be quick as possible otherwise may incur
some problems such as upper layer may suspend any other requests.

The bio_vecs solution works only for a tiny prototype.
If I apply the solution there will appear the following problems

1. The write to the cache device isn't one single write.
    This causes atomicity problem. And may cause performance
    degradation.
2. We need to compute checksum of the entire log chunk before write.
    Without this, the user isn't safe from partial write problem.
    Like the 1 above, atomicity is to be cared.
    (btw, I don't think dm-cache that has separete data device and
     metadata device can guarantee this level of safetiness)
3. Don't ack any bios until the full buffer is written is harmful.
    We should ack as quick as possible as explained above.
4. Read caching becomes infeasible. It needs copying of the read data.

My conclusion is write buffer in practice should be a single buffer and
copying is inevitable.

>From a engineering point of view, memory copy can't be the bottleneck
(before that, SSD's throughput hits) so we shouldn't hack for the little
improvement.

- Akira

On 2015/02/21 1:17, Joe Thornber wrote:
> On Sat, Feb 21, 2015 at 01:06:08AM +0900, Akira Hayakawa wrote:
>> The size is configurable but typically 512KB (that's the default).
>>
>> Refer to bio payload sounds really dangerous but it may be possible
>> in some tricky way. but at the moment I am not sure how the
>> implementation would be.
>>
>> Is there some fancy function that is like memcpy but actually "move"
>> the ownership?
> When building up your log chunk bio copy the bio_vecs (not the data)
> from the original bios.  You can't complete the original bios until
> your log chunk has been written.
>
> - Joe


      reply	other threads:[~2015-02-21  1:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-01  8:44 [PATCH v3] staging: writeboost: Add dm-writeboost Akira Hayakawa
2015-01-18  0:09 ` Greg KH
2015-02-20  8:44   ` Akira Hayakawa
2015-02-20 15:06     ` Joe Thornber
     [not found]       ` <54E75201.9030202@gmail.com>
2015-02-20 15:50         ` Joe Thornber
2015-02-20 16:06           ` Akira Hayakawa
2015-02-20 16:17             ` Joe Thornber
2015-02-21  1:36               ` Akira Hayakawa [this message]

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=54E7E135.3060507@gmail.com \
    --to=ruby.wktk@gmail.com \
    --cc=dm-devel@redhat.com \
    --cc=driverdev-devel@linuxdriverproject.org \
    --cc=ejt@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=snitzer@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).