From: Kai Krakow <hurikhan77@gmail.com>
To: linux-bcache@vger.kernel.org
Subject: Re: bcache fails after reboot if discard is enabled
Date: Mon, 09 Feb 2015 20:46:05 +0100 [thread overview]
Message-ID: <tcfnqb-u59.ln1@hurikhan77.spdns.de> (raw)
In-Reply-To: loom.20150105T010336-763@post.gmane.org
Michael Goertz <goertzm@gmail.com> schrieb:
> Stefan Priebe <s.priebe <at> profihost.ag> writes:
>
>>
>> Hi Rolf,
>> Am 03.01.2015 um 17:32 schrieb Rolf Fokkens:
>> > I've been using discard for a while, but I ran a few times in serious
>> > FS corruptions. After disabling discard bcache was stable again.
>> >
>> > So far I tributed the corruptions to a low-cost SSD which probably
>> > didn't handle discard very well. But this was only an assumptions.
>> >
>> > I didn't experience specific reboot problems like you describe.
>>
>> Reboot just triggers it faster and even fs crashes can occur the errors
>> are just examples.
>>
>> I've now disabled discards in my kernel code.
>>
>> Kent may you have a look at the 3.18 kernel code regading discards?
>>
>> Greets,
>> Stefan
>>
>
> I just started using bcache and run into this same issue after a reboot.
> I was running in writeback mode at the time and run into some FS loss as a
> result. I don't have back traces since my machine wouldn't boot. I
> recovered by removing the cache device and forcing the backing device to
> run without it.
>
> I am running Ubuntu 14.04 with the Utopic kernel. I can provide more
> details of my setup and hardware if that's helpful.
It works perfectly fine here with latest 3.18. My setup is backing a btrfs
filesystem in write-back mode. I can reboot cleanly, hard-reset upon
freezes, I had no issues yet and no data loss. Even after hard-reset the
kernel logs of both bcache and btrfs were clean, the filesystem was clean,
just the usual btrfs recovery messages after an unclean shutdown.
I wonder if the SSD and/or the block layer in use may be part of the
problem:
* if putting bcache on LVM, discards may not be handled well
* if putting bcache or the backing fs on LVM, barriers may not be handled
well (bcache relies on perfectly working barriers)
* does the SSD support powerloss protection? (IOW, use capacitors)
* latest firmware applied? read the changelogs of it?
I'd try to first figure out these differences before looking further into
debugging. I guess that most consumer-grade drives at least lack a few of
the important features to use write-back mode, or use bcache at all.
So, to start the list: My SSD is a Crucial MX100 128GB with discards enabled
(for both bcache and btrfs), using plain raw devices (no LVM or MD
involved). It supports TRIM (as my chipset does), and it supports powerloss-
protection and maybe even some internal RAID-like data protection layer
(whatever that is, it's in the papers).
I'm not sure what a hard-reset technically means to the SSD but I guess it
is handled as some sort of short powerloss. Reading through different SSD
firmware update descriptions, I also see a lot words around power-off and
reset problems being fixed that could lead to data-loss otherwise. That
could be pretty fatal to bcache as it considers it storage as always unclean
(probably even in write-through mode). Having damaged data blocks out of
expected write order (barriers!) could be pretty bad when bcache recovers
from last shutdown and replays logs.
--
Replies to list only preferred.
next prev parent reply other threads:[~2015-02-09 19:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-02 9:47 bcache fails after reboot if discard is enabled Stefan Priebe - Profihost AG
2015-01-02 10:00 ` Stefan Priebe - Profihost AG
2015-01-03 16:32 ` Rolf Fokkens
2015-01-03 19:32 ` Stefan Priebe
2015-01-05 0:06 ` Michael Goertz
2015-02-09 19:46 ` Kai Krakow [this message]
2015-04-08 0:06 ` Dan Merillat
2015-04-08 18:17 ` Eric Wheeler
2015-04-08 18:27 ` Stefan Priebe
2015-04-08 19:31 ` Eric Wheeler
2015-04-08 19:54 ` Kai Krakow
2015-04-08 22:02 ` Dan Merillat
2015-04-10 23:00 ` Kai Krakow
2015-04-11 0:14 ` Kai Krakow
2015-04-11 6:31 ` Dan Merillat
2015-04-11 6:54 ` Dan Merillat
2015-04-11 7:52 ` Kai Krakow
2015-04-11 18:53 ` Dan Merillat
[not found] ` <CAPL5yKfpk8+6Vw cUVcwJ9QxAZJQmqaa98spCyT7+LekkRvkeAw@mail.gmail.com>
2015-04-11 20:09 ` Kai Krakow
2015-04-12 5:56 ` Dan Merillat
2015-04-29 17:48 ` Dan Merillat
2015-04-29 18:00 ` Ming Lin
2015-04-29 19:57 ` Kai Krakow
2015-04-08 18:46 ` Kai Krakow
2015-06-05 5:11 ` Kai Krakow
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=tcfnqb-u59.ln1@hurikhan77.spdns.de \
--to=hurikhan77@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).