From: Kent Overstreet <kmo@daterainc.com>
To: Mathijs Kwik <mathijs@bluescreen303.nl>
Cc: linux-bcache@vger.kernel.org
Subject: Re: bcache and hibernation
Date: Sun, 30 Nov 2014 15:29:59 -0800 [thread overview]
Message-ID: <20141130232959.GA8123@kmo-pixel> (raw)
In-Reply-To: <874mtg7dhc.fsf@bluescreen303.nl>
On Sun, Nov 30, 2014 at 07:25:03PM +0100, Mathijs Kwik wrote:
> 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?
BTW - it sounds like you're ahead of me on how this is put together - could you
point me at the userspace side of hibernate that you're using (those initramfs
scripts, and in particular whatever device mapper does)? that'll help a lot.
next prev parent reply other threads:[~2014-11-30 23:27 UTC|newest]
Thread overview: 13+ 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
2014-11-30 23:24 ` Kent Overstreet
2014-11-30 23:29 ` Kent Overstreet [this message]
2014-12-01 8:48 ` Mathijs Kwik
-- strict thread matches above, loose matches on Subject: below --
2018-04-03 19:01 bcache: bad block header Nikolaus Rath
2018-04-03 22:38 ` Jens Axboe
2018-04-05 8:51 ` bcache and hibernation (was: bcache: bad block header) Nikolaus Rath
2018-04-05 18:13 ` bcache and hibernation Michael Lyle
2018-04-05 19:51 ` Nikolaus Rath
2018-04-06 0:21 ` Michael Lyle
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=20141130232959.GA8123@kmo-pixel \
--to=kmo@daterainc.com \
--cc=linux-bcache@vger.kernel.org \
--cc=mathijs@bluescreen303.nl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.