Sd card race on resume with filesystem errors (possible data loss?)

[Sergio Callegari <sergio.callegari@gmail.com>]

Hi and happy new year!

I would like to report a problem that I am encountering with the sdcard 
storage.

I have received the suggestion to write to the dedicated ml from the 
linux-stable one.

In my setup /home is on an sd-card (because system is a 
laptop/convertible where 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-suspend/20767/2).

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 if data loss can be excluded, 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. From my 
understandig, this 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