Life of SDcard

[docbroke]

SD cards have fairly limited read/ write cycles compared to ssd/hdd drives. How can we prolong the life of SD card in pyra ?

I was reading about this and found two things, to reduce read/write

1. Use noatime as mounting parameter in /etc/fstab
2. Do not create "swap" partition on SD card.
3. ? avoid journaling file systems like ext3/4 and use ext2 instead ( I am not sure if this is advisable )
EDIT: ext3 can be created without journal,

mke2fs -t ext3 -O ^has_journal /dev/whatever

source https://unix.stackexchange.com/questions/259211/write-once-archive-ext2-vs-ext4has-journal-vs
EDIT2:
4. Large number of read/writes comes from log files and temporary files. Less essential logs can be cutdown, while temporary files can be kept in rem (tmpfs). Arch does that, I don't know about debian.
EDIT3:
5. Use large capacity cards, they last longer. ( I forgot where I read this, but basically larger capacity means less overwriting in same areas, which prolongs the life )

 

[levi]

I've been running my OS from SD card on a couple of machines now for a good few years. I do keep fairly regular backups, but so far (touch wood) I've not had one fail on me.

I understand you can disable journalling on ext3/4 although I'm less clear on exactly what the benefit of using them remains in that case. I guess I could read up on it easily enough, but meh. I've never disabled it on any of my SD cards where I do tend to use ext4 these days, and I don't mount them noatime either.

 

[docbroke]

You are lucky. I have 2 SD cards that failed in android phone.

 

[Letalis Sonus]

https://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/

 

[Linux-SWAT]

You can also disable journal on ext4.

 

[elvissteinjr]

Been using a fairly cheap Transcent SD card in my Pandora since 2011 and it's still working fine. FAT32 formatted, though.
May not be the norm, but the cards probably won't die as fast as you think.

With the OS running from internal memory there will probably also a bit less writes going towards the SD card than worth worrying about.

 

[elw3]

Those tips you where refering to where published at the beginning of the ssd era. They are ancient.
Todays OS is smart enough to keep flush cycles at minimum and quality cards have a good wear leveling.

It does reduce shit, true, but its equivalent to copying over one movie file per year. In other words if the series you watch has 15 or 16 episodes per season will have a greater impact than those saving methods.

In other news your browser is constandly writing to disk while you browse the inteweb. They say its harmless and yet this is more than timestamps and journal produces.

SD cards have fairly limited read/ write cycles compared to ssd/hdd drives.

This is wrong, booth are build the same. They should in theory have the same life time. In practice ppl buy the cheapest cards possible but thats another story.

Ive had so far 5 cards failing. 4 of them are μSD and have a broken controller. Thats not even connected to write cycles at all.
Another is a 64gb no name SD in my pandora that regulary looses data. The os can handle that, but its annoying.

2. Do not create "swap" partition on SD card.

FFS dont use swap at all! I am sick of tutorials speaking about swaps when 99% of users only waste storage without the slightlest benefit of it.
[doublepost=1552923586,1552922833][/doublepost]

4. Large number of read/writes comes from log files and temporary files. Less essential logs can be cutdown, while temporary files can be kept in rem (tmpfs). Arch does that, I don't know about debian.

Example of /etc/fstab:

tmpfs    /home/USER/.thumbnails   tmpfs    defaults    0 0

You should put browser caches and logs in there. Its not bad, but not that usefull either.
More important is placing download folders or temporary archives into ramdisks. Say jdownloader for example, part downloading and unzipping may cause the flie to get written 3 times. Do that in a ramdisk.
On every linux there is /dev/shm preconfigured as such, just point your download folder to there.

 

[Linux-SWAT]

If you don't use swap on a low ram device, processes will be slaughtered by the oom killer.

 

[Letalis Sonus]

and quality cards have a good wear leveling.

Even good cards' wear leveling is still shit compared to first gen SSDs. You only have very limited ressources to work with, you can't just slap a fully fledged Cortex-M4 on steroids into them like with SSDs. That's why Samsung created F2FS - which, on the other hand, only provides its full potential when it is being fine-tuned to the flash media's characteristics, which are rarely public information.

Even today there still are cards out there whose FTL will go rampage if you do not use a FAT-based filesystem because the manufacturer used some seriously dirty tricks to optimize their wear leveling. That's why we already have an own SD card compatibility list.

 

[elw3]

If you don't use swap on a low ram device, processes will be slaughtered by the oom killer.

Thats the 1%.
The tutorial should go "if you programs get killed due to not enough ram you may need a swap" and not "you need a swap, i dont know what for but you need it".

Even good cards' wear leveling is still shit compared to first gen SSDs. You only have very limited ressources to work with,

There are cards with extreme good wear leveling, notably a few from mushkin, but yea their chip is limited and having a good wear leveling means slower data transfer.

 

[Linux-SWAT]

Believe me or not, you really doesn't want your applications crashing out randomly

 

[elw3]

There is no sane usecase where that ever happens.

 

[WizardStan]

Believe me or not, you really doesn't want your applications crashing out randomly

I have never, in almost 20 years of using Linux, had a random application close because of OOM. Always, without fail, when RAM fills up, my system just locks up. If I'm lucky, a few hours later it may start to stutter to life enough that I can ssh into it and kill something (usually chromium).
I've used several flavours of Ubuntu, Fedora/Redhat, CentOs, and Arch, and not a single one has ever behaved differently.
My current office computer with Ubuntu 18.04 has 16GB RAM and 16GB swap: the swap is near useless, even with swappiness 100 it never uses more than 5%, and eventually physical RAM fills up and that's it, only chance of recovery is to reboot.
Believe me, I would love to have the OOM killer reap a few random apps: it may be vexing to lose my work in something, but when the alternative is a required reboot anyway I'd happily take it. Unfortunately I'm not convinced it exists, or at least that it works the way it's described.

 

[elw3]

Affirmative, but I was under the impression that this is a side effect of zram. But thats not that old...
Chromium actually closes tabs on its own when i run out of ram.

 

[harlequin]

You are lucky. I have 2 SD cards that failed in android phone.

Aaaand here I am.

Back when I bought my GHz Pandora, I put 2 SD cards in the same order from Dragon Box, 32 GB and 64 GB ("Transcend", I think, I may have to verify as I may still have them).

Well, the 64 GB died first, after less than one year, and the 32 GB one 6 months later. ext2 (Super Zaxxon rootfs) on the smallest one, ext4 on the other one.

No heavy writing at all, no swap, just put data on them when I received the precious Pandora, and then, all of a sudden...
Written files that disappear, constantly corrupted filesystem, impossible to fix.
Same behaviour in both cases.

I was so sad

I had already sent my Pandora to EvilDragon during the first months in order to have minor issues fixed under warranty (thank you very much ED, you're great ), so I didn't want to send yet one more small package to Germany...

Ended up just buying a Sandisk 128 GB as they got cheaper with time...
But I'm still scared of losing my SD card to "gremlins".

For a while I thought that, maybe it was the Pandora, with its battery compartment that doesn't constantly make perfect contact, that gave off random spikes to the card (leading to random writes?) when transported in my backpack, or that "burnt" the card's controller/memory/let out the magic smoke.
Then I accused the cards' controllers for "optimizing" (== taking shortcuts... quite like Intel and their "performance advantage" built on "security shortcuts", that are heavily showing, as of late) for specific filesystems (mainly FAT and lately exFAT too).
Guess I'll never know.

May your backups always be up to date.

 

[elw3]

Well the pandoras SD reader works different than any other device i have. Not better or worse, just different. On the one hand i loose a lot of data too, on the other it can access/use/format/repair cards which no other device can use.

 

[Kuro]

I have never, in almost 20 years of using Linux, had a random application close because of OOM. Always, without fail, when RAM fills up, my system just locks up. If I'm lucky, a few hours later it may start to stutter to life enough that I can ssh into it and kill something (usually chromium).
I've used several flavours of Ubuntu, Fedora/Redhat, CentOs, and Arch, and not a single one has ever behaved differently.
My current office computer with Ubuntu 18.04 has 16GB RAM and 16GB swap: the swap is near useless, even with swappiness 100 it never uses more than 5%, and eventually physical RAM fills up and that's it, only chance of recovery is to reboot.
Believe me, I would love to have the OOM killer reap a few random apps: it may be vexing to lose my work in something, but when the alternative is a required reboot anyway I'd happily take it. Unfortunately I'm not convinced it exists, or at least that it works the way it's described.

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. It's really useful when everything locks up due to swapping.

The other option is to disable swap altogether and the system will call the OOM kill when it needs to. This means however that you can't for example do hibernation (suspend to disk), and that the system might at some time kill an important process which would otherwise just cause some background processes to be swapped out.

 

[docbroke]

You can always use Alt+SysRq+f

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

 

[Kuro]

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.

 

[second exodous]

I've had pretty good luck with SD cards. I have been trying out a lot of pi images and have killed a few 64GB cards and a few 32 GB cards in the last year. My high-qulaity cards, like those bought directly from Samsung, are going strong though. 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.

Depending on who made the image I find that some enable journaling and some not, I don't think most people know what that is, even those making images. On my Pandora I've used the same 32GB card to run the OS and I have a few full size SD cards I have just formatted to EXT4 without turning journaling off and they haven't died yet.

From now on for any card over $50 I'm going to spend an extra 10% or so more by bying directly from the manufacturer, like Samsung, Kingston, or Lexmark. No more bargains from online sites.