From: Mathijs Kwik <mathijs@bluescreen303.nl>
To: Kent Overstreet <kmo@daterainc.com>
Cc: linux-bcache@vger.kernel.org
Subject: Re: bcache and hibernation
Date: Sun, 30 Nov 2014 19:25:03 +0100 [thread overview]
Message-ID: <874mtg7dhc.fsf@bluescreen303.nl> (raw)
In-Reply-To: <20141113221134.GA15711@kmo-pixel> (Kent Overstreet's message of "Thu, 13 Nov 2014 14:11:34 -0800")
Kent Overstreet <kmo@daterainc.com> writes:
> On Thu, Nov 13, 2014 at 02:52:02PM +0100, Mathijs Kwik wrote:
>> The kernel documentation on suspend is VERY clear you should NOT touch
>> anything on disk between suspend and resume. So activating luks and LVM
>> is probably risky already, but it apppears both luks and LVM do not make
>> any on-disk changes when activated and any in-memory state (within the
>> resumed image) is still valid. The benefit of activating luks and LVM
>> before resume seems to be that it allows resuming from encrypted/lvm
>> volumes.
>
> Yeah, this is handled for in kernel stuff with the freezing mechanism, which
> bcache uses.
>
>>
>
> So, userspace shouldn't have to do anything to tell bcache about
> hibernation.
I understand bcache knows when the system hibernates so it can do some
bookkeeping/flushing. What I don't get, is how this will protect the
system in the short phase before resume, when my initrd activates bcache
and lvm, _before_ it checks for a resume image.
I guess bcache will just start running as usual. Maybe flushing some
dirty buckets, cache some new stuff (when lvm searches for volumes and
udev reads labels & more).
Then finally the resume mechanism loads the old hibernated system, while
the cache has changed in the mean time! Won't this cause issues?
>
> The dev branch is getting a true read only mode (still in progress), but this
> isn't relevant to hibernation.
>
> bcache kernel threads (allocator thread, gc thread) should be correct w.r.t.
> hibernation, but - maybe the workqueue usage isn't.
>
> I'm probably not going to be able to get to this in the next couple days, but
> this is a pretty serious issue. Can you ping me again every couple days until I
> get a fix out for this, and myabe file a bug somewhere? (i think
> bugzilla.kernel.org has been used for bcache bugs before...)
I will file a report once I'm sure what the exact cause for my data-loss
was. If I understand you correctly, all should be safe and well, no
matter what (initramfs) userspace does in between and the only thing
that might not be safe is the workqueue?
next prev parent reply other threads:[~2014-11-30 18:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-13 13:52 bcache and hibernation Mathijs Kwik
2014-11-13 15:52 ` Mathijs Kwik
[not found] ` <CAPBO7TZF5qUV64UZJVE+WQkKa2aCJSTjkQxh6eVktH7nA41Vqw@mail.gmail.com>
2014-11-13 16:52 ` Mathijs Kwik
[not found] ` <CAPBO7TbQA2MbFS43racKOwZ+=U2jC4OcLF413-MvvNKML5=QZQ@mail.gmail.com>
2014-11-13 17:23 ` Mathijs Kwik
2015-02-10 22:36 ` Kai Krakow
2014-11-13 22:11 ` Kent Overstreet
2014-11-30 18:25 ` Mathijs Kwik [this message]
2014-11-30 23:24 ` Kent Overstreet
2014-11-30 23:29 ` Kent Overstreet
2014-12-01 8:48 ` Mathijs Kwik
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=874mtg7dhc.fsf@bluescreen303.nl \
--to=mathijs@bluescreen303.nl \
--cc=kmo@daterainc.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).