On Tue, Jan 21, 2020 at 4:00 AM Robbie Smith <zoqaeski@xxxxxxxxx> wrote: > > I think I have a hunch as to why this issue has occurred. I've had two > btrfs partition failures, and both times it was upon resuming from > hibernation. The key file for the encrypted swap was stored in > /root/key-file, and the openswap hook unlocks the encrypted root, > mounts it, reads the keyfile for the swap partition, and then unmounts > it again. For sure if it's a rw mount it's a problem. I'm pretty sure even ro mount isn't guaranteed to be ro, it's only ro for user space but kernel space could still write. I think the only sure way is use blockdev --setro before mounting the volume. > The very first line of swsusp[1] has a big fat warning about touching > data on the disk between suspend and resume, and in hindsight I > imagine this action may count. Totally counts. The hibernation image has its own view of the file system which is restored when resuming from that image. I don't know enough about the work implied by not merely syncing the file system at hibernation time, but forcing an unmount after the hibernation image is written; and therefore requiring it be (freshly) mounted upon resuming from hibernation. That would prevent this problem, but then also makes hibernation entry and resume more complicated. -- Chris Murphy
