Can-o-Worms: Pi Shutdown vs Power Off
-
@garyd9 said in Can-o-Worms: Pi Shutdown vs Power Off:
The same goes for unplugging your raspberryPi without shutting down the filesystems cleanly. Just because it "probably" won't cause you headaches, or just because it didn't cause problems X times before, doesn't mean it's safe or a good idea.
Totally agree, and that's where the risk must be weighed. How much time will be wasted in the case of a failure? How can that time be mitigated with backups, etc?
This is where I have a hard time because I haven't yet been able to cause the failure situation in normal usage, so I'm not really sure how much pain would go into a recovery. Worst case scenario for a Pi would be maybe replacing the SD card AND the pi itself. So that's maybe 50$ financial hit, plus the time to download an up to date pi image and install it on the fresh SD card, update the system, restore any backups or do a fresh install of whatever software.
In the case of the 50 mini pcs I mentioned, the risk was deemed acceptable, because the cost and complexity of mitigation was far too high to justify. If a mini PC dies it simply gets replaced with a spare. At 200$ each it's far more than a pi, but it's so rare, and the mitigation impossible (battery backup is out of the question in this locale), that it's an accepted risk.
If anyone can show me a reliable way to KILL a pi or SD card (without actual negligence/malfeasance) I'd love to see it.
-
Not sure what kind of writes your doing in your test, but perhaps try something a bit more annoying to filesystems: zip. (might need to "apt install zip")
The reason is that the headers in a zip archive have to be updated after compressed data is written to the file, so there's a chance that the archive header is out of date with respect to the data in the archive, rendering the entire archive corrupted (even if the filesystem isn't corrupted.)
Just run "zip test.zip /usr/bin/*" and on OS startup, test the zip for integrity.
-
@Phaedrux said in Can-o-Worms: Pi Shutdown vs Power Off:
Totally agree, and that's where the risk must be weighed. How much time will be wasted in the case of a failure? How can that time be mitigated with backups, etc?
I'm not familiar with what DSF/DSC is doing behind the scenes, but a question is what it might be writing to the filesystem. Anything in /var/log can be redirected to a tempfs (it'd be lost on power failure.) If that's all the fs writing that that the duet stuff does (other than writing gcode files in direct response to user interaction), then it should be reasonably safe. I'd probably turn off write caching on the file system as well (with nearly zero penalty if logs are all going to ramdisk.)
-
@Danal said in Can-o-Worms: Pi Shutdown vs Power Off:
....................Seriously, you'd be amazed at how nasty some people have been that I might be misleading noobys or something. This forum is pretty respectful, many are not.
Ohh, I'm not amazed - I have my own blog and YouTube Channel so I know how true that is.
And mostly, I'm just lazy.
Thanks for your honesty. I'm even more lazy - maybe that's why I'm sticking to stand alone "RPi-less" operation. If I don't start it up, I don't have to worry about shutting it down
-
I'm updating a SQLLITE3 database. Fairly simple structure... but... to your point, the DB engine is writing all over a file that the file systems just sees as a bunch of blocks. And those relationships can break.
Just checked. DB Healthy.
-
@Phaedrux said in Can-o-Worms: Pi Shutdown vs Power Off:
Totally agree, and that's where the risk must be weighed. How much time will be wasted in the case of a failure? How can that time be mitigated with backups, etc?
I'm not gonna name names, but I think most of us can think of a good handful that would struggle for weeks with such a scenario; which beggs the question why advocate something that is probably safe instead of implementing something that is safe? And accepting that the recommendation while we wait for a safe solution should be to safely shut down the system - anyone can ignore it at their own risk.
-
@bearer said in Can-o-Worms: Pi Shutdown vs Power Off:
And accepting that the recommendation while we wait for a safe solution should be to safely shut down the system - anyone can ignore it at their own risk.
Yes I totally get your point. A clean shutdown is the safest bet and best practice. But it's also good to know that if power is lost unexpectedly that it's not guaranteed catastrophe.
-
@bearer If you are going to use a read only pi filesystem for the sbc, where are you going to upload gcode files to? Do you intend to use a 2nd disk (network share?) of some sort?
-
@Danal said in Can-o-Worms: Pi Shutdown vs Power Off:
@gtj0 said in Can-o-Worms: Pi Shutdown vs Power Off:
@Danal Out of curiosity, how much time elapses between the 12v cutout and the 5v dropping below the Pi's Vin minimum?
I will see if there is a reasonable way to measure that. For example, if my dual channel scope will go slowly enough to trigger on the 12V and also draw a trace for the 5V.
If you have any thoughts on how to measure...?
Connect 12V to channel 1 and 5v to channel 2. Set the scope it to trigger on channel 1 falling edge.
-
@gloomyandy said in Can-o-Worms: Pi Shutdown vs Power Off:
@bearer If you are going to use a read only pi filesystem for the sbc, where are you going to upload gcode files to? Do you intend to use a 2nd disk (network share?) of some sort?
you get an overlay which is read/write worst case you loose your uploaded files and the os and config remain intact.
-
@gloomyandy said in Can-o-Worms: Pi Shutdown vs Power Off:
@bearer If you are going to use a read only pi filesystem for the sbc, where are you going to upload gcode files to? Do you intend to use a 2nd disk (network share?) of some sort?
You could create a partition just for gcode files that's writable and leave the rootfs read only.
-
The only time I've really seen corruption happen is when you loose power in the middle of a high I/O event. Unless your using a PI to build a NAS that you plan on hammering on, you will probably never see a corruption event.
-
@gtj0 said in Can-o-Worms: Pi Shutdown vs Power Off:
Connect 12V to channel 1 and 5v to channel 2. Set the scope it to trigger on channel 1 falling edge.
Roughly what I was thinking. What voltage do we consider, as the 5V decays, to be the limit?
Delta / Kossel printer fanatic
-
@Phaedrux said in Can-o-Worms: Pi Shutdown vs Power Off:
Worst case scenario for a Pi would be maybe replacing the SD card AND the pi itself.
Huh? What mechanism increases or decreases the odds of damage to a Pi (not the SD, the Pi) if it is powered off before or after a Raspbian shutdown command?
-
@Danal said in Can-o-Worms: Pi Shutdown vs Power Off:
Huh? What mechanism increases or decreases the odds of damage to a Pi (not the SD, the Pi) if it is powered off before or after a Raspbian shutdown command?
Exactly. But I just chose that as an absolute worst case total loss situation on one side of the balance.
-
@Phaedrux said in Can-o-Worms: Pi Shutdown vs Power Off:
Totally agree, and that's where the risk must be weighed. How much time will be wasted in the case of a failure? How can that time be mitigated with backups, etc?
Obviously varies by user and Pi. If for some reason I thought a given Pi would take more than an hour or so to rebuild its SD, I'd do something. I'd be much more likely to schedule a backup than to worry about shutdown. SDs fail. Whether shutdown or not.
-
@Danal said in Can-o-Worms: Pi Shutdown vs Power Off:
SDs fail. Whether shutdown or not.
And power loss can happen even with a UPS. (accidentally unplugging it, battery dying, etc)
-
@Phaedrux said in Can-o-Worms: Pi Shutdown vs Power Off:
@Danal said in Can-o-Worms: Pi Shutdown vs Power Off:
Huh? What mechanism increases or decreases the odds of damage to a Pi (not the SD, the Pi) if it is powered off before or after a Raspbian shutdown command?
Exactly. But I just chose that as an absolute worst case total loss situation on one side of the balance.
Huh again?
It seems we just agreed there is absolutely zero change in the odds of losing or not losing the hardware with shutdown or no shutdown. Therefore, hardware loss events do not enter into this discussion.
Yes? No?
Delta / Kossel printer fanatic
-
@Danal said in Can-o-Worms: Pi Shutdown vs Power Off:
@Phaedrux said in Can-o-Worms: Pi Shutdown vs Power Off:
@Danal said in Can-o-Worms: Pi Shutdown vs Power Off:
Huh? What mechanism increases or decreases the odds of damage to a Pi (not the SD, the Pi) if it is powered off before or after a Raspbian shutdown command?
Exactly. But I just chose that as an absolute worst case total loss situation on one side of the balance.
Huh again?
It seems we just agreed there is absolutely zero change in the odds of losing or not losing the hardware with shutdown or no shutdown. Therefore, hardware loss events do not enter into this discussion.
Yes? No?
All I was saying that even if the worst case was a total write off of your SD card and Pi it's ~50$ for the sake of argument. If something cost you 50$ and an hour of your time, how much effort would you be willing to put into mitigating it. It's just a thought experiment.
-
I guess in the context of using a Pi or similar as the SBC on a Duet3, it's pretty rare that anything is going to be written to the filesystem that's of any significance. Aside from doing a software update or uploading a gcode file, typical usage is pretty much just going to be read operations which aren't going to care about getting interrupted anyway.
The test is still really interesting to know how unlikely a failure is. I imagine that the more likely failure more will be due to SD dying due to swap spaces and temporary files being written... but that's a whole separate topic.While I'd always prefer to do a 'proper' shutdown, I've never felt the need on a Pi, and your test seems to have confirmed that. Though if there was an easy option to do so on the DWC, I'd likely use it.
