Josep Lladonosa <jlladono@xxxxxxxxx> writes: > On 13 November 2014 16:52, Mathijs Kwik <mathijs@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
