From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathijs Kwik Subject: Re: bcache and hibernation Date: Thu, 13 Nov 2014 17:52:01 +0100 Message-ID: <874mu3xcum.fsf@bluescreen303.nl> References: <87h9y3xl6l.fsf@bluescreen303.nl> <878ujfxflg.fsf@bluescreen303.nl> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from mail-wg0-f45.google.com ([74.125.82.45]:56567 "EHLO mail-wg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933352AbaKMQwF (ORCPT ); Thu, 13 Nov 2014 11:52:05 -0500 Received: by mail-wg0-f45.google.com with SMTP id x12so17607629wgg.18 for ; Thu, 13 Nov 2014 08:52:03 -0800 (PST) In-Reply-To: (Josep Lladonosa's message of "Thu, 13 Nov 2014 17:26:38 +0100") Sender: linux-bcache-owner@vger.kernel.org List-Id: linux-bcache@vger.kernel.org To: Josep Lladonosa Cc: "linux-bcache@vger.kernel.org" Josep Lladonosa writes: > On 13 November 2014 16:52, Mathijs Kwik 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 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 >>