On Sun, Nov 30, 2014 at 07:25:03PM +0100, Mathijs Kwik wrote: > Kent Overstreet <kmo@xxxxxxxxxxxxx> writes: > > > On Thu, Nov 13, 2014 at 02:52:02PM +0100, Mathijs Kwik wrote: > >> 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. > > > > Yeah, this is handled for in kernel stuff with the freezing mechanism, which > > bcache uses. > > > >> > > > > So, userspace shouldn't have to do anything to tell bcache about > > hibernation. > > I understand bcache knows when the system hibernates so it can do some > bookkeeping/flushing. What I don't get, is how this will protect the > system in the short phase before resume, when my initrd activates bcache > and lvm, _before_ it checks for a resume image. Wait what? Ohh... you must be talking about hibernate, not suspend... > I guess bcache will just start running as usual. Maybe flushing some > dirty buckets, cache some new stuff (when lvm searches for volumes and > udev reads labels & more). > > Then finally the resume mechanism loads the old hibernated system, while > the cache has changed in the mean time! Won't this cause issues? I have no idea how hibernate works, but yeah, quite possibly... > > The dev branch is getting a true read only mode (still in progress), but this > > isn't relevant to hibernation. > > > > bcache kernel threads (allocator thread, gc thread) should be correct w.r.t. > > hibernation, but - maybe the workqueue usage isn't. > > > > I'm probably not going to be able to get to this in the next couple days, but > > this is a pretty serious issue. Can you ping me again every couple days until I > > get a fix out for this, and myabe file a bug somewhere? (i think > > bugzilla.kernel.org has been used for bcache bugs before...) > > I will file a report once I'm sure what the exact cause for my data-loss > was. If I understand you correctly, all should be safe and well, no > matter what (initramfs) userspace does in between and the only thing > that might not be safe is the workqueue? I was thinking suspend to ram, not hibernate. gonna have to look into how hibernate works now. -- 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
