Re: Question regarding informing MMC subsystem about upcoming power loss.

[Christian Loehle <christian.loehle@arm.com>]

On 05/03/2024 15:59, Patryk wrote:
> wt., 5 mar 2024 o 16:33 Christian Loehle <christian.loehle@arm.com> 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