Moode and power loss (aka writes to the sd card)

[jbaumann]

@Sehnsucht , since I have destroyed multiple SD cards and one SSD through power loss, I don‘t see it as myth. Regarding how this can happen: I haven‘t researched it, but two immediate possibilities would be that in the controller we get conflicting potentials during the power loss that fry part of the control logic (remember, the internal voltage is much lower than the external voltage) the other could be that single cells or banks could be lost in the same way. But I would have to look into it…
The second question is whether with the low cost of an SD card and the comparably low risk thinking about it is worth the time.
Otoh, thinking about it is fun and a challenge (and a learning opportunity). The simplest way to introduce a read-only mode is to simply use raspi-config and turn on the overlayfs. This turns everything to read-only, and adds a „ram disk“ that contains all the changes. Turning the RPi off means throwing away every change. [this would be the simplest approach, without syncing back, as could be done with zram-config]
For my use case this would be absolutely ok, since I want to use the player as a frontend to my LMS. My question remains: Is there any Moode process that relies on changes being kept over reboots? And are there any processes that produce a large number of changes (the size of the overlay, kept in RAM, is limited)?
If not, then I think I will put this experiment on my list…
Cheers, Joe

[Nutul]

(...) My question remains: Is there any Moode process that relies on changes being kept over reboots? And are there any processes that produce a large number of changes (the size of the overlay, kept in RAM, is limited)?

Straight out of logic: the library itself (the directory tree is read and a database is generated/update on every library generation/update), together with the album-art thumbnails (same update principle applies), any configuration/preferences changes and, eventually, the current play-queue.
Big-data... I think it's not the case with moOde.

There might be other things under the hood, but these are those that count, IMO.

[jbaumann]

I did a number of tests on an RPi3 with 1GB of RAM. Since the Overlay FS stores all changes (including log entries) and is limited by the available RAM it slowly runs full. On the test system I got 9-12 hours before I reached 8-9% remaining storage. On a RPi4 with its larger RAM we get even longer.
(I think the memory usage could be reduced considerably but it simply is not necessary…)

This means that for all practical purposes Moode can be used with the OverlayFS without problems.

I have written a few small scripts to allow the simple switch from and to the Overlay FS and I think I will write up what has to be done to use it. Where should I put the tutorial? On this site?

[TheOldPresbyope]

@jbaumann

The FAQ and Guides subforum here would seem as good a place as any. Lots of devs also use their own GitHub repos for this purpose.

My personal experience with moOde and uSD cards is so counter to what you describe that I don’t feel the need to use Overlay FS. OTOH, I can’t resist testing/playing with code related to moOde that others post.

Regards,
Kent

[Tim Curtis]

I did a number of tests on an RPi3 with 1GB of RAM. Since the Overlay FS stores all changes (including log entries) and is limited by the available RAM it slowly runs full. On the test system I got 9-12 hours before I reached 8-9% remaining storage. On a RPi4 with its larger RAM we get even longer.
(I think the memory usage could be reduced considerably but it simply is not necessary…)

This means that for all practical purposes Moode can be used with the OverlayFS without problems.

I have written a few small scripts to allow the simple switch from and to the Overlay FS and I think I will write up what has to be done to use it. Where should I put the tutorial? On this site?

Are you sure? "This means that for all practical purposes Moode can be used with the OverlayFS without problems."

How are changes to config, prefs, state etc written to underlying file system?

[jbaumann]

Maybe I wasn‘t precise enough. Everything that is changed while the OverlayFS is active is lost on reboot (on purpose).

For my use cases this is perfect, because I change the system only infrequently (the only exception being playlists which I hope can be stored on network storage…)

This means that as soon as you want to change anything permanently (this includes playlists, configuration entries, updates etc.) you first have to disable the OverlayFS, reboot, do the changes, enable the OverlayFS again and reboot again.

Sadly, there is no way to enable and disable the OverlayFS on the fly, and I haven‘t found anything reliable that allows to write the changes back to the underlying FS yet.

[Tim Curtis]

Maybe I wasn‘t precise enough. Everything that is changed while the OverlayFS is active is lost on reboot (on purpose).

For my use cases this is perfect, because I change the system only infrequently (the only exception being playlists which I hope can be stored on network storage…)

This means that as soon as you want to change anything permanently (this includes playlists, configuration entries, updates etc.) you first have to disable the OverlayFS, reboot, do the changes, enable the OverlayFS again and reboot again.

Sadly, there is no way to enable and disable the OverlayFS on the fly, and I haven‘t found anything reliable that allows to write the changes back to the underlying FS yet.

Also lost would be various state files, settings etc that are programmatically updated but as you state this is not an issue for your usage scenario.

For playlists you can prolly replace the local directory /var/lib/mpd/playlists/ with a symlink that points to your NAS.

[jbaumann]

I replaced the local playlist directory as suggested and it worked fine.

But in some cases I turn my stereo on when the NAS is still turned off. In these cases the player wouldn‘t have a valid directory, and I assume would not play anything (haven‘t tried it though). So that solution probably does not work in my situation.

[Nutul]

I replaced the local playlist directory as suggested and it worked fine.

But in some cases I turn my stereo on when the NAS is still turned off. In these cases the player wouldn‘t have a valid directory, and I assume would not play anything (haven‘t tried it though). So that solution probably does not work in my situation.

Of course it won't. but I cannot see any solution that allows a situation like this... ;-)

BTW, why are you switching the NAS off... aren't those things supposed to be on 24/7?

[jbaumann]

If MPD would allow multiple playlist directories then it could work, or if it would allow subdirectories then too.
There seems to be a possibility of adding playlists from music directories with a plugin, but I do not yet understand how that is used. And even if that is the case, this would only allow me to use playlists on the NAS, but not actively store them without having to copy them by hand…

Regarding the NAS: It depends on who you are asking. The classical approach is to let the NAS run 24/7, but turning it off once a day isn‘t going to change the longevity of the drives in any relevant way, and thus I automatically turn off the NAS at 2300 and turn it on in the morning when I start to work.
This way I‘m in no way restricted in my use of the NAS while at the same time conserving a lot of power the NAS would need while idling through the night…

Cheers, Joe