From: Nix <nix@esperi.org.uk>
To: Pavel Goran <via-bcache@pvgoran.name>
Cc: Coly Li <colyli@suse.de>,
linux-bcache@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH v3 00/13] bcache: device failure handling improvement
Date: Thu, 25 Jan 2018 18:57:25 +0000 [thread overview]
Message-ID: <874ln9hilm.fsf@esperi.org.uk> (raw)
In-Reply-To: <1664591662.20180125063516@pvgoran.name> (Pavel Goran's message of "Thu, 25 Jan 2018 06:35:16 +0300")
On 25 Jan 2018, Pavel Goran told this:
> Hello Nix,
>
> Thursday, January 25, 2018, 1:23:19 AM, you wrote:
>
>> This feels wrong to me. If a cache device is writethrough, the cache is
>> a pure optimization: having such a device fail should not lead to I/O
>> failures of any sort, but should only flip the cache device to 'none' so
>> that writes to the backing store simply don't get cached any more.
>
>> Anything else leads to a reliability reduction, since in the end cache
>> devices *will* fail.
>
> It's one of those choices: "if something can't work as intended, should it be
> allowed to work at all?"
Given that the only difference between a bcache with a writearound cache
and a bcache with no cache is performance... is it really ever going to
beneficial to users to have a working system suddenly start throwing
write errors and probably become instantly nonfunctional because a
cache device has worn out, when it is perfectly possible to just
automatically dissociate the failed cache and slow down a bit?
I would suggest that no user would ever want the former behaviour, since
it amounts to behaviour that worsens a slight slowdown into a complete
cessation of service (in effect, an infinite "slowdown"). Is it better
to have a system working correctly but more slowly than before, or one
that without warning stops working entirely? Is this really even in
question?!
> Of course, this only applies to "writethrough" and "writearound" modes with
> zero dirty data; "writeback" bcache devices (or devices switched from
> writeback and still having some dirty data) should probably be disabled if the
> cache device fails.
Oh yes, definitely. That's simple correctness. The filesystem is no
longer valid if you make the cache device disappear in this case: at the
very least it needs a thorough fscking, i.e. sysadmin attention.
--
NULL && (void)
next prev parent reply other threads:[~2018-01-25 18:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-14 14:42 [PATCH v3 00/13] bcache: device failure handling improvement Coly Li
2018-01-14 14:42 ` [PATCH v3 01/13] bcache: set writeback_rate_update_seconds in range [1, 60] seconds Coly Li
2018-01-16 9:03 ` Hannes Reinecke
2018-01-14 14:42 ` [PATCH v3 02/13] bcache: properly set task state in bch_writeback_thread() Coly Li
2018-01-16 9:02 ` Hannes Reinecke
2018-01-14 14:42 ` [PATCH v3 03/13] bcache: set task properly in allocator_wait() Coly Li
2018-01-16 9:05 ` Hannes Reinecke
2018-01-16 9:29 ` Coly Li
2018-01-14 14:42 ` [PATCH v3 04/13] bcache: fix cached_dev->count usage for bch_cache_set_error() Coly Li
2018-01-14 14:42 ` [PATCH v3 05/13] bcache: quit dc->writeback_thread when BCACHE_DEV_DETACHING is set Coly Li
2018-01-16 9:11 ` Hannes Reinecke
2018-01-26 6:21 ` Coly Li
2018-01-14 14:42 ` [PATCH v3 06/13] bcache: stop dc->writeback_rate_update properly Coly Li
2018-01-14 14:42 ` [PATCH v3 07/13] bcache: set error_limit correctly Coly Li
2018-01-14 14:42 ` [PATCH v3 08/13] bcache: add CACHE_SET_IO_DISABLE to struct cache_set flags Coly Li
2018-01-14 14:42 ` [PATCH v3 09/13] bcache: stop all attached bcache devices for a retired cache set Coly Li
2018-01-14 14:42 ` [PATCH v3 10/13] bcache: fix inaccurate io state for detached bcache devices Coly Li
2018-01-16 9:27 ` Hannes Reinecke
2018-01-14 14:42 ` [PATCH v3 11/13] bcache: add backing_request_endio() for bi_end_io of attached backing device I/O Coly Li
2018-01-16 9:28 ` Hannes Reinecke
2018-01-14 14:42 ` [PATCH v3 12/13] bcache: add io_disable to struct cached_dev Coly Li
2018-01-16 9:32 ` Hannes Reinecke
2018-01-14 14:42 ` [PATCH v3 13/13] bcache: stop bcache device when backing device is offline Coly Li
2018-01-16 9:33 ` Hannes Reinecke
2018-01-24 22:23 ` [PATCH v3 00/13] bcache: device failure handling improvement Nix
2018-01-25 3:35 ` Re[2]: " Pavel Goran
2018-01-25 18:57 ` Nix [this message]
2018-01-26 4:15 ` Pavel Goran
2018-01-26 4:56 ` Coly Li
2018-01-26 5:51 ` Michael Lyle
2018-01-26 6:23 ` Coly Li
2018-02-16 12:11 ` Nix
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=874ln9hilm.fsf@esperi.org.uk \
--to=nix@esperi.org.uk \
--cc=colyli@suse.de \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=via-bcache@pvgoran.name \
/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