Life of SDcard

[docbroke]

Are you sure you are pressing SysRq? As it is usually bellow PrintScreen you need to do Shift+PrintScreen to activate it, so the full key combo becomes Alt+Shift+PrintScreen+f, this varies with keyboards though.

The other possibility is the SysRq combos being disabled in your system, this link should help with that for Arch and maybe other distros as well.

Yes I was pressing SysRq. I think it is disabled by default in arch, as per archwiki link you posted, I have to enable kernel shortcuts at boot to use that. I think I will try that in evening.

In fact, pretty much all the cheap 32 or 64 GB cards I originally had for my pi SBCs have died and I'm using my 128GB cards on them now.

This reminded me that large capacity cards last longer ( I don't remember where I read that), added this point to the first post.

 

[second exodous]

In fact, pretty much all the cheap 32 or 64 GB cards I originally had for my pi SBCs have died and I'm using my 128GB cards on them now.

This reminded me that large capacity cards last longer ( I don't remember where I read that), added this point to the first post.

Well, I still have both 32GB and 64GB cards that have been formatted and new images burned on them over and over again that are fine butI know those are genuine Kingston or Lexmark. If they are high quality when you buy them they're more likely to last longer. I mainly used the cheap ones until they died because I'm constantly trying new images and if the cheap ones wear out eh, I don't care. I have a VPN server on one of my pi computers and that one I run a 32 GB card I know is a genuine kingston because I don't want that dying. I think life of an SD card has more to do with quality than size. Size can be a factor when data needs to be constantly deleted to make space though. My 128 GB cards I use with my gopro for example I let fill completely up before reformatting so they get wiped a lot less frequently than smaller cards.

 

[levi]

The other possibility is the SysRq combos being disabled in your system, this link should help with that for Arch and maybe other distros as well.

There's still no f in reisub. I've not tried it, but that doc suggests that alt+sysreq (shift+alt+del on my eeepc keyboard fwiw), f shouldn't do anything on arch anyway.

 

[Kuro]

There's still no f in reisub. I've not tried it, but that doc suggests that alt+sysreq (shift+alt+del on my eeepc keyboard fwiw), f shouldn't do anything on arch anyway.

reisub is just a subset of the commands available with SysRq, they are the more commonly known as they are usually the best course of action when something goes wrong.

R - to prevent X to catch some keyboard inputs, which is useful for debugging,
E- to send the equivalent of a Ctrl+c to every runnig process to give them a chance terminate by themselves,
I - to forcefully terminate every running process,
S - to do the equivalent of a sync and prevent cached data from being lost,
U - to remount every drive as read-only to prevent corruption,
B - to finally force a reboot.

But there are a lot more SysRq commands to debug and recover from crashes and hangs, there's this wikipedia page listing all of them. All these commands should be available in every distro as they are a kernel feature, although they are sometimes disabled by default as they are deemed as debugging tools.

 

[Letalis Sonus]

On which OS. It does nothing on my arch setup.

On some systems all or part of the SysRq commands are disabled by default.

 

[WizardStan]

You can always use Alt+SysRq+f (yeah that key usually paired with print screen that no one knows what it's for) to call the OOM kill function.

Nope. I mean, I can, when my system is not out of RAM and is responding normally I totally can force the OOM to run and system logs acknowledge that it was run and some process (usually a Chromium tab) has been killed, but when RAM is full? Nothing.
SysRq+b DOES trigger a reboot, so whatever subsystem is listening for key presses is still there, but the OOM killer has never, under any circumstance that I'm aware of, actually killed an app for me to recover my system.

The other option is to disable swap altogether and the system will call the OOM kill when it needs to.

Tried that, too, back when I had less RAM.
My "solution" was to install 32GB of RAM. I have yet to hit that in months of usage. Chromium sure as hell tries but I usually need to actually reboot due to a system update before it happens.

 

[Linux-SWAT]

It's because the root processes have a RAM priority so the system can keep afloat.
The user processes get killed first.
Some reading:
https://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html

 

[spud42]

This reminded me that large capacity cards last longer ( I don't remember where I read that), added this point to the first post.

i have a 128Mb SD card that i have been using for 10 years and it was used by the previous technician before i got it. it has been formatted, firmware files written to it and removed from it and up dated firmware for 10 years and it is still going strong. its not a "brand" card either. its labled DSE which was an Australian electronics chain Dick Smith Electronics.... so cards aint cards..lol

 

[Kuro]

Nope. I mean, I can, when my system is not out of RAM and is responding normally I totally can force the OOM to run and system logs acknowledge that it was run and some process (usually a Chromium tab) has been killed, but when RAM is full? Nothing.
SysRq+b DOES trigger a reboot, so whatever subsystem is listening for key presses is still there, but the OOM killer has never, under any circumstance that I'm aware of, actually killed an app for me to recover my system.

It can take some time for the system to become responsive again when it's using a lot of swap, but the OOM killer call does work. Had to wait up to 5-10 minutes once, but I was able to recover some important work that i would lose otherwise. The time it takes to recover depends on the amount of swap in use at the moment you take action and the speed of the drive your swap is in.

 

[elw3]

Never got syscalls to work either, assumed its a unicorn.

This reminded me that large capacity cards last longe

Yes, for obvious reasons, more space means more places to put wear level on.

 

[netlinker]

I have a Sandisk Extreme 64 GB in my Raspberry for a while now. I'm using it for TV-Recording. So far I have about 3 to 4 TB written without any complains. I fill it up and empty it usually three times a week. I'm curious though how long it will last. It's some kind of endurance experiment.
I had a lot of other Cards failing as well. Namely the Sandisk ultra series. The first one was gone after 3 weeks in my Raspberry and the other one was loosing data in my phone after 6 months or so while at the same time enabling write protection. I didn't even write a lot, just photos, mp3 and email.
Since then I only buy cards of the upper price segment with no complains so far.
I replaced the first one with a Panasonic gold, which is still running for several years now.
It's the only one I found where the manufacturer states that it has MLC storage as well as advanced wear leveling, whatever THAT(advanced) means.