Backing device unattaches from caching device when hibernating into a swap file

[tankmissile]

This behavior is very inconsistent. I'm using btrfs, which only recently received swap file support as of linux kernel version 5.0. I followed the directions to get a swap file working on btrfs, including using resume=swap_device and resume_offset=swap_file_offset. The physical offset was retrieved using this script: https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c. I then divided the physical offset by the page size to get the resume offset. At best, hibernating into a swap file only works the first time after creation. Every subsequent hibernation leads my system to boot as if it were not resuming. In a worse case, hibernating caused the backing device to unattach from the caching device, leading to an unbootable system. I then had to forcefully recreate the cache in order to fix it. At worst, at one point I think my filesystem became corrupted since there were quite a lot of missing files, including commands, that made my system unusable. I then had to reinstall the whole system.

[Paride Legovini (paride)]

Hi and thanks for taking the time to report this bug.

There isn't really enough information here for a developer to confirm this issue is a bug, or to begin working on it, so I am marking this bug Incomplete for now.

Given that the setup you are trying to achieve is rather non-standard, I'm prone to think there is a problem in the setup itself, rather than a bug in Ubuntu. You can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community.

If you believe that this is really a bug, then you may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem, explain why you believe this is a bug in Ubuntu rather than a problem specific to your system, and then change the bug status back to New.

[tankmissile (tankmissile)]

In that case, I've reported this bug to the wrong place. This is a bcache specific issue and not a distro specific issue. I'm not exactly sure where to report it now. I apologize for this mistake.

[Christian Ehrhardt  (paelzer)]

No need to apologize, it can be complex at times.
We can be glad you reported it at all instead of just being grumpy about it :-)

Bcache is "at home" at https://bcache.evilpiepirate.org/
It seems it uses ther kernel style for bugs which means:
tracker: https://bugzilla.kernel.org/show_bug.cgi?id=203573
and discussions on the mailing list: <email address hidden>

I hope that helps to report, if you have a bug link or mail there report it here please so it can be tracked.

[alecfeldman (alecfeldman-linux-kernel-bugs)]

I followed the directions to get a swap file working on btrfs, including using resume=swap_device and resume_offset=swap_file_offset. The physical offset was retrieved using this script: https://github.com/osandov/osandov-linux/blob/master/scripts/btrfs_map_physical.c. I then divided the physical offset by the page size to get the resume offset. Hibernating into a swap file only works the first time after creation. Every subsequent hibernation leads my system to boot as if it were not resuming. Hibernating can also cause the backing device to unattach from the caching device, leading to an unbootable system. I then have to forcefully recreate the cache in order to fix it. Eventually, the above happens, but the filesystem also becomes corrupted as I can no longer reattatch the cache. This can be reproduced on any setup with bcache, btrfs on the cache, and a swap file on the btrfs system. I am not sure if this affects other filesystems.

[tankmissile (tankmissile)]

https://bugzilla.kernel.org/show_bug.cgi?id=207809

[tankmissile (tankmissile)]

From looking deeper into this issue and reading the FAQ on the bcache site, this appears to be a catch 22 issue. During resume, you are not allowed to make any changes to the disk. However, with bcache, this can be tricky: any read you make from a bcache device could result in a write to update the caching device. Currently bcache has no good ways of solving this. This means resume must finish before bcache starts. However, if the resume image is on the bcache backing device, the image must be accessed first. Using resume_offset to use the swap file on the backing device must be updating the caching device, and subsequently causing data loss. If I have reached the correct conclusion from the data loss that occured on my system and the limitation listed on the bcache FAQ, then that means swap files are not supported on bcache period. With that in mind, bcache should not allow hibernation to occur using swap files.

[tankmissile (tankmissile)]

Actually, a proposed solution that could work is disabling the caching device on bcache before hibernating. See here for more details: https://bcache.evilpiepirate.org/FAQ/

[alecfeldman (alecfeldman-linux-kernel-bugs)]

From looking deeper into this issue and reading the FAQ on the bcache site, this appears to be a catch 22 issue. During resume, you are not allowed to make any changes to the disk. However, with bcache, this can be tricky: any read you make from a bcache device could result in a write to update the caching device. Currently bcache has no good ways of solving this. This means resume must finish before bcache starts. However, if the resume image is on the bcache backing device, the image must be accessed first. Using resume_offset to use the swap file on the backing device must be updating the caching device, and subsequently causing data loss. If I have reached the correct conclusion from the data loss that occured on my system and the limitation listed on the bcache FAQ, then that means resuming from a swap file on a backing device, at least with the cache enabled, is not possible. Disabling the cache during resume may prevent data loss from occuring.