As a followup question: Is there a safe way to use hiberation in the presence of bcache? 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
