From: Kent Overstreet <kent.overstreet@gmail.com>
To: James Pharaoh <james@pharaoh.uk>
Cc: linux-bcache@vger.kernel.org
Subject: Re: Extra write mode to close RAID5 write hole (kind of)
Date: Fri, 28 Oct 2016 03:59:03 -0800 [thread overview]
Message-ID: <20161028115903.acsmc3cfemhxgt52@kmo-pixel> (raw)
In-Reply-To: <bd0112e0-976a-59e8-94ef-81777f240ffd@pharaoh.uk>
On Wed, Oct 26, 2016 at 04:20:38PM +0100, James Pharaoh wrote:
> Since I want my bcache device to essentially be a "journal", and to close
> the RAID5 write hole, I would prefer to disable this behaviour.
>
> I propose, therefore, a further write mode, in which data is always written
> to the cache first, and synced, before it is written to the underlying
> device. This could be called "journal" perhaps, or something similar.
>
> I am optimistic that this would be a relatively small change to the code,
> since it only requires to always choose the cache to write data to first.
> Perhaps the sync behaviour is also more complex, I am not familiar with the
> internals.
>
> So, does anyone have any idea if this is practical, if it would genuinely
> close the write hole, or any other thoughts?
It's not a crazy idea - bcache already has some stripe awareness code that could
be used as a starting point.
The main thing you'd need to do is ensure that
- all writes are writeback, not writethrough (as you noted)
- when the writeback thread is flushing dirty data, only flush entire stripes -
reading more data into the cache if necessary and marking it dirty, then
ensure that the entire stripe is marked dirty until the entire stripe is
flushed.
This would basically be using bcache to do full data journalling.
I'm not going to do the work myself - I'd rather spend my time working on adding
erasure coding to bcachefs - but I could help out if you or someone else wanted
to work on adding this to bcache.
next prev parent reply other threads:[~2016-10-28 11:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-26 15:20 Extra write mode to close RAID5 write hole (kind of) James Pharaoh
2016-10-26 22:31 ` Vojtech Pavlik
2016-10-27 21:46 ` James Pharaoh
2016-10-28 11:52 ` Kent Overstreet
2016-10-28 13:07 ` Vojtech Pavlik
2016-10-28 13:13 ` Kent Overstreet
2016-10-28 16:55 ` Vojtech Pavlik
2016-10-28 16:58 ` James Pharaoh
2016-10-28 17:07 ` James Pharaoh
2016-10-29 0:58 ` Kent Overstreet
2016-10-29 19:58 ` James Pharaoh
2016-10-28 11:59 ` Kent Overstreet [this message]
2016-10-28 17:02 ` James Pharaoh
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=20161028115903.acsmc3cfemhxgt52@kmo-pixel \
--to=kent.overstreet@gmail.com \
--cc=james@pharaoh.uk \
--cc=linux-bcache@vger.kernel.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