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

[jbaumann]

Hi,

[warning: this is a bit longer, sorry for that]

I‘m new to Moode and would like to experiment with it. But one important factor is that write operations to the SD card are minimized (read-only in the best case).

Why? I have connected the RPi to the switch that turns the amp on and off and this means that power loss can be sudden and without warning to the RPi.

One answer given quite often is that good-quality SD cards have no problem with sudden power loss. First of all, this is not entirely true. In seldom cases a power loss during write at the exact right moment lets the controller fry parts of the storage or even the whole card. [Off-topic: I once turned off and on an SSD on an RPi every 30 seconds for a week, turned it on again, the RPi started to boot and to write to the SSD. The SSD died after this, even though it was a quality drive (SANDisk)].

Second, even if the hardware survives this, then the last write might be compromised. On a hard disk this is no problem with a modern file system because only the last few blocks are lost, and they most probably will be some log entries. So no big loss, right? Wrong, since the internal organization of an SD card is different from the one presented th the RPi, meaning that depending on the SD card a substantially larger block of memory, e.g., 32K might be lost, that has nothing to do with the last block written, simply because it is in the same internal part. This can be alleviated to some extent by using an SD card that is substantially larger than the space needed for the OS.

Both points make power loss for an SD card or SSD much more problematic than power loss for an HDD.

There are two simple approaches to minimize the probability for this under Raspbian. The first approach (done by PiCorePlayer) is to use a read-only file system. If you want to change something then you have to first remount the file system read-write, change whatever want, and then switch back to read-only mode.

The other approach is to use an Overlay FS. This simply stores changes in RAM and overlays them transparently over the original data. When power is lost the changes are lost as well. But the changes can also be made permanent by writing them to the underlying file system (this naturally should only be done when power can be guaranteed).

[I‘m ignoring some other approaches like writing the overlay to a second SD card…]

Tim Curtis has already pointed out that Moode does not support a „read-only“ mode. But can Moode use an Overlay FS? This would be a good alternative.

Cheers, Joe

[TheOldPresbyope]

Hi, Joe.

The thing about the FOSS world is a user is free to ask for anything and a developer is free to say no if it doesn't fit in their plan.

It seems to me you have several options, many of them just variations on a theme

• use moOde and your system as it is and wait until you actually corrupt a uSD card before trying a different option
  
• use moOde and remember to first use the Power Shutdown button in the webUI to bring down moOde and the O/S and put the Pi into a quiescent state; then hit your power switch
  
• use moOde as above and let it use a GPIO line to trigger a time-delayed power shutdown of the entire system. I was doing this with time-delay relays in my amateur radio gear half a century ago 
  
• use moOde with your existing power switch along one of the many DIY shutdown solutions for the Pi involving super capacitors, battery packs, or the like, and a GPIO signal to trigger moOde's soft power shutdown
  
• alternatively, use moOde and your amplifier with a sequencing power strip. We use commercial one in the A/V system I occasionally babysit to prevent the amps from powering up until the mixer board and wireless mic receivers are running and v.v. but DIY is fine too. Again, use a GPIO signal to the Pi to start its soft power-down sequence
  
• fork the moOde distro, modify it to use an overlayFS or some other approach, and compose a pull request...don't forget to thoroughly test first...and also don't be surprised if it doesn't turn out to the answer to a maiden's prayer
  
• try to sweet talk someone else into doing the same
  
• don't use moOde.
  

I've been using the first option since I got interested in Pi-based audio and discovered moOde many years ago. Sometimes I remember to do a soft power shutdown first but mostly I'm in a hurry and just shutoff the power supply or even just pull the USB plug from the Pi.

Just my 2-cents worth.

Regards,
Kent

(not a dev though I occasionally contribute snippets; mostly I test to find bugs or unexpected consequences)

[jbaumann]

Hi Kent,

Thank you for the thorough answer. [Off-topic: I know about both FOSS and about UPS solutions for the RPi, see e.g., https://github.com/jbaumann/attiny_daemon]

My first step, before coming to a decision, is to determine what the current options are. I understand that a read-only mode is not supported, but does Moode support an Overlay FS already?

And for what it is worth: I didn‘t want to criticize any of the decisions made with Moode, to me it looks like a very nice player that could maybe replace my Picoreplayer.

Cheers, Joe

[Always_In_The_Moode]

A Raspberry Pi is so power efficient, why not connect it to a 24/7 power strip like I have? Everything else is on a switched power strip. I have checked out the CPU utilisation on the Raspberry Pi and it's not being hammered at all, so it's no where near the ~7w maximum power draw when run at full pelt.

I have left mine on 24/7 for almost a year with no issues what so ever. Is there any reason why you may not consider leaving it on 24/7?

[jbaumann]

I had something comparable to this (with multiple RPi‘s, each with their own little UPS, to control home automation, a media center, and a communications hub). But I have tried to reduce energy consumption as much as possible, and thus I changed the architecture to one N5105 (due to the RPi shortages) running multiple containers and VMs using Proxmox.

If I would follow your approach I still would want a UPS for that because I have experienced first-hand that power losses can wreak havoc with your storage. This would change the average power draw to around 8-10W, which would add a substantial amount to my overall power consumption.

So, even while it might sound theoretical, does Moode support Overlay FS already in any way (apart from the kernel providing the functionality)?

Cheers, Joe

[Nutul]

I had something comparable to this (with multiple RPi‘s, each with their own little UPS, to control home automation, a media center, and a communications hub). But I have tried to reduce energy consumption as much as possible, and thus I changed the architecture to one N5105 (due to the RPi shortages) running multiple containers and VMs using Proxmox.

If I would follow your approach I still would want a UPS for that because I have experienced first-hand that  power losses can wreak havoc with your storage. This would change the average power draw to around 8-10W, which would add a substantial amount to my overall power consumption.

So, even while it might sound theoretical, does Moode support Overlay FS already in any way (apart from the kernel providing the functionality)?

Cheers, Joe

If Overlay OS is supported transparently by Linux, then moOde (or more correctly, Raspbian OS, for that matter...) should support it.
I don't know how it works, but as you mentioned something like: "commit to disc when necessary", sounds to me that you would probably provide a way for the OS to know "when" to do such commit...

If your dedication to power-saving is so high, I would possibly go to a relayed power-off solution using GPIO signals: you switch the Pi off, and it will help power-off all the remaining hardware in your chain...

[TheOldPresbyope]

@jbaumann 

The answer was implicit in my previous reply, but, no, moOde does not use an overlay filesystem.

The acid test---start moOde and then query the O/S for any mounted overlays

Code:

pi@moode:~ $ mount | grep -i overlay
pi@moode:~ $

Had there been any overlay mounts, we would have seen a response like

Code:

pi@moode:~ $ mount | grep -i overlay
xxxx on /yyyy type overlay ...
pi@moode:~ $

Regards,
Kent

[jbaumann]

Hi Kent,

thank you for the answer. Next question: Are there any processes/programs that regularly write a state to disk that has to be kept between reboots? I don‘t mean explicit changes like updates to the media library that are triggered by the user, but writes that happen without user interaction. Background: If there are no such changes, then using the Overlay FS (and losing all temporary changes after a reboot) should introduce no problems at all. Otherwise it could become interesting…

Cheers, Joe

[Sehnsucht]

Hi Kent,

thank you for the answer. Next question: Are there any processes/programs that regularly write a state to disk that has to be kept between reboots? I don‘t mean explicit changes like updates to the media library that are triggered by the user, but writes that happen without user interaction. Background: If there are no such changes, then using the Overlay FS (and losing all temporary changes after a reboot) should introduce no problems at all. Otherwise it could become interesting…

Cheers, Joe

SD cards are cheap, and I've never corrupted mine in years of pulling the power. You hear people mentioning this as a potential problem but I think it's something of an urban myth at this point.  Additionally, you're unlikely to physically damage an SD card with the removal of power - how would that work?   You could make create a working image, then copy it, and use it a for a while, then do a diff with the pristine image and see what's been written - it might provide a clue as to what changes you'd need to make to prevent this state being written.  Another option, supposing you weren't really worried about somehow physically damaging your SD card but just wanting to minimize possible file-system corruption, would be to create a background task which performed a sync every few minutes/seconds, to flush any changes out to disk. I suppose if it really is trivial to enable an overlay FS then once you've figured out how to do it I'd be happy to test it, as I'm sure others would.

[TheOldPresbyope]

My opinion on this is that there’s no point in developing a baroque tmpfs / ramfs / ramdisk / overlayFS (these aren’t the same, by the way) solution to what is in essence a (potential) hardware problem. There’s plenty of documentation including tutorials available on the InterWeb™ if you want to go the software route anyway. 

Regards,
Kent