Re: bcache and hibernation

[Mathijs Kwik <mathijs@bluescreen303.nl>]

Josep Lladonosa <jlladono@gmail.com> writes:

> On 13 November 2014 16:52, Mathijs Kwik <mathijs@bluescreen303.nl> wrote:
>
>> As a followup question:
>>
>> Is there a safe way to use hiberation in the presence of bcache?
>>
>
> Hello,
>
> I am using (just now) a laptop with root filesystem on a bcache partition,
> a separate boot partition (non bcache, small) and a swap partition used for
> hibernation and it works perfectly.

I'm glad to hear that. So how does your system boot/resume?
Does the initrd postpone registering/activating bcache until after the
resume-check? Or are my assumptions just wrong?


>
> Josep
>
>
>>
>> Assuming a (initrd) boot procedure should at least wait for the
>> hard-disk to settle, this will mean some udev rules will fire...
>> With the bcache udev rules in place, this means activating/attaching a
>> cache+backing device. Am I assuming correctly that this might
>> immediately lead to on-disk changes (writeback dirty pages for example)?
>>
>> So what's the way to go?
>> Make sure the bcache module doesn't get loaded when resuming from
>> hibernation? Tell udev not to activate the device automatically until we
>> check for a resume-image?
>>
>>
>>
>>
>>
>> Mathijs Kwik <mathijs@bluescreen303.nl> writes:
>>
>> > Hi all,
>> >
>> > Today, I lost most my data (don't worry, got backups) after the cache
>> > got corrupted somehow. I suspected a recent suspend-to-disk to be the
>> > cause. I checked how my distribution (NixOS) handles suspend/resume and
>> > I have some concerns about how bcache fits into this.
>> >
>> > Normally, the kernel and initrd get loaded. The initrd loads required
>> > kernel modules, waits for udev to settle, activates luks&lvm, then
>> > finally asks the kernel to resume from the resume device.
>> >
>> > 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.
>> >
>> > Now, with bcache added, things probably get a bit hairy. NixOS supports
>> > bcache inside the initrd and uses udev rules to activate/attach. I
>> > suspect this is probably unsafe. Probably bcache starts to see if any
>> > dirty pages exist, to write them to the backing store. Even without
>> > writeback caching, the activation of lvm will read some sectors, which
>> > might trigger the cache to update. Then after resuming the image, the
>> > in-memory state is corrupted and further damage occurs.
>> >
>> > - Does this sound plausible?
>> > - Is there any way to tell bcache to make absolutely no changes to
>> >   either the backing device or the cache?
>> >   Basically like a readaround+writearound which can be triggered on
>> >   hibernate and switched off on resume.
>> >
>> > Thanks,
>> > Mathijs
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>