Josep Lladonosa <jlladono@xxxxxxxxx> writes: > On 13 Nov 2014 17:52, "Mathijs Kwik" <mathijs@xxxxxxxxxxxxxxxx> wrote: >> >> 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? > > I do not know. Worked without any special setup. Well that's nice, but I would like to know for sure this is guaranteed to be safe :) > > System boots as usual, but during kernel boot it finds a hibernation in > swap area and just restores it. I understand how suspend works. My question is regarding the steps _before_ finding the hibernation image. My guess is there are situations where detecting/activating a bcache device before restoring the hibernation image can lead to disaster. So either this is not the case (I would like an explanation why), or I need a way to make sure udev does not register bcache before resuming. > >> >> >> > >> > 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
