On 05/03/2024 15:59, Patryk wrote: > wt., 5 mar 2024 o 16:33 Christian Loehle <christian.loehle@xxxxxxx> napisał(a): >> Immune to what exactly? >> - (User) data loss of data that is still in the cache of the sd card? >> (That would be saved by a timely cache flush) >> - (User) data loss of data that should've been written to flash already? >> - SD cards breaking? >> - Explosions? > > Data loss of data that is still in the cache of the sd card Then my (very biased) opinion is: Anything >1s window between being notified and power-loss a userspace umount/fsync might be an improvement enough for your case. Anything <1s window is then so storage-module-implementation specific that it's hard to draft a solution that actually provides a measurable improvement. Of course, turning off the SD cache completely is always an option (with drawbacks like reduced performance and endurance). > >> (Anything but the first IMO should be fixed by procurement and not by the >> kernel, but I'm not sure if that's consensus). >> >>> Assuming that I have the information about upcoming power loss >>> (provided by e.g. external interrupt, PSU voltage monitoring etc) how >>> should I pass this information to the Kernel so that it will try to >>> clean up resources - in particular MMC subsystem? > >> There was a discussion, currently there aren't really, but it depends >> on the scenario you're afraid of. Just issuing a cache flush might be fine. >> https://www.phoronix.com/news/Linux-Priority-Based-Shutdown >> https://lore.kernel.org/lkml/2023112403-laxative-lustiness-6a7f@gregkh/T/ > > Thanks, I didn't know about this, I will check it. Forgot to CC Oleksij before, did it now. Kind Regards, Christian > >> One of the fundamental questions IMO remains: How much time do we actually >> have between being notified? > > I haven't done any measurements yet, sorry. > > Best regards > Patryk
