Hi and happy new year!
I would like to report a problem that I am encountering with the sdcard storage.
I have a laptop/convertible where /home is on an sd-card (because the internal disk is too small). The card is luks encrypted and has a btrfs filesystem on it.
When the laptop sleeps and then resumes, there is a race. The sdcard gets accessed for read/write but is not yet ready, so there are I/O errors. BTRFS is not happy with them and tends to remount RO.
This issue is well known to purism developers (e.g. see https://source.puri.sm/Librem5/linux/-/issues/484 and https://forums.puri.sm/t/sdcard-becomes-read-only-after-waking-up-from-suspe...).
My kernel logs are identical to those in https://source.puri.sm/Librem5/linux/-/issues/484 (first comment), apart from the fact that I get the errors from BTRFS, while the reporter there gets the errors from EXT4. This indicates that the race is not specific to BTRFS.
The errors in the kernel logs come right after the PM: suspend exit message.
From what I understand:
1. The error is more frequent with the SD-LUKS-FILESYSTEM stratification, but not specific to it
2. A phone/tablet set up such as those that purism developers address will generally use sdcard for storage and require suspend, being a good trigger for the problem. However, the problem is in no means specific to phones, ARM devices, etc. I am getting it on an X86-64 laptop.
3. It is unclear to me if there is a real risk of data loss. Possibly with BTRFS that has a more complex data management this can be the case.
4.Even without data loss, the issue requires a reboot to get the filesystem back to RW, so it is annoying.
5. Purism developers have a kernel patch for it at https://source.puri.sm/Librem5/linux/-/merge_requests/788, but I believe it is not in linux mainline or stable. Would it make sense to consider that patch?
6. For stable kernels, there is a mitigation consisting in a systemd sleep-resume hook as in
#!/bin/sh /usr/bin/systemd-cat -p5 /usr/bin/echo ${1} ${2}
case "${1}" in post) sleep 1.5 systemd-cat -p4 /usr/bin/echo "hack, wait for sdcard" ;; esac
see https://source.puri.sm/Librem5/linux/-/issues/484#note_277648
This appears to reduce the occurrence of the problem, but not to eliminate it completely.
Thanks for the attention
Sergio