FlightAware Discussions

New 8GB Raspberry Pi 4

I have two Pi’s running 24/7 since 2015, with same two 8 GB microSD cards.

Whenever I upgrade the distro or piaware version, I do NOT use command line. I write latest image to microSD card.

Both these 8 GB microSD cards are healthy & survived till today.
I have purchased these for Canadian $8 each (= US $5.50 each).

I am surprised why there is so much fuss to save a microSD card. :wink:
Simply save a backup copy on your Desktop/Laptop and that is all what is needed.

1 Like

No fuss, it’s just that with plenty of memory, it’s a shame to see it idle :smiley:

1 Like

I realize we’ve steered off subject (apologies to OP). SD cards are a crap-shoot. The MTBF’s have been increasing and larger capacities assist in that, but throughout my various projects, I’ve had several SD cards give up the ghost. While data was still accessible on all of the failed cards I’ve had, none could be written to or formatted. Sometimes it’s taken awhile to realize they even went poof since there were no errors when attempting format and/or rewrite.

To that end, minimizing writes to the sd cards can’t ever be a bad idea, but it’s not worth losing sleep over. You owe me a new screen @abcd567!


Not only that, but brand name is no guaranty either. I have had very bad luck with SanDisk and Lexar. Kingston is middle of the road. The best of the brand names has been the Samsung EVO.

I recently purchased a bunch of ADATA brand, a tip from @abcd567, and they have been great so far.

I was way ‘late to the party’. I found out only two weeks ago that making a backup image of a microSD card using Win32DiskImager is the way to go. Experimenting with Pi software is fun again. :wink:

I wonder how much of a factor environmental conditions have on the card’s longevity. I believe yours are inside the home, controlled temperatures. Mine are in the garage. Conditions can be brutal there.

you should see me… sitting on the sofa… idle…

to the topic:
I’ve seen postings in different discussions saying it would be a good idea to move swapfiles to such a ramdisk… :flushed:

Woop back on topic! Can never have too much PIE! :slight_smile:

ADATA brand are the ones I am using for last 5 years 24/7 in two Pi’s, and these did not fail yet. These are pretty cheap and durable too.

Is it an issue with Piaware? I can see value in applications where swapping files is a frequent thing, but as it happens sometimes, it may be a solution in search of a problem.

I am using Armbian OS on my OrangePiPC for many years. Initially it used log2ram, but it gave rise to so many issues (including failure of lighttpd and pfclient), that the OS developer finally stopped using it about 3 years ago.

Similarly upto about 3 years ago Flightradar24’s Pi24 image used ram for logs, but they also stopped this practice.

Pi24 image 2017
As the logs were on ram, on reboot these log files were deleted, and both lighttpd & planefinder client were unable to recreate log files and failed.

cat /etc/fstab 
proc /proc proc defaults 0 0 
/dev/mmcblk0p1 /boot vfat defaults 0 2 
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1 

tmpfs /var/log tmpfs defaults,noatime,nosuid,mode=0755,size=100m  

I thought Armbian used zram by default?
cd /etc/cron.daily
df -h

May be armbian has changed recently. What I mentioned was situation 3 years ago. I have not checked their latest configuration.



Shouldn’t this be under responsibility of the operating system? As long as there is enough memory, swapping should never be used. If an application requires this it seem to be bad programming.

It’s correct that swapping starts before all RAM is used (at approx. 70%) but with 4GB or even 8GB this would mean that your system uses already 2.5-3GB of it’s available RAM

Just switched over Raspberry OS to 64 bit version


So far everything is working.

Prometheus and Grafana are offering both an arm64 version of their application.

  • Prometheus and Exporters: working
  • Grafana: not working, getting error “file not found”. Could be a problem in front of the screen

I don’t know enough to comment at the OS/programming level. I’m just a user trying to ‘protect’ myself. This is why I wrote it can be a case of a solution searching for a problem. :wink:

1 Like

I think what @foxhunter was originally referring to was that putting a swapfile in RAM memory uses up memory that could instead be used by applications and causes swapping to happen even sooner. It also makes it easier to run out of disk space to swap to. But it is a fast swapfile. :grin:

And he’s right. Generally better to let the OS control swapping but users can easily adjust “swappiness” to guide the OS how hard to work to keep from swapping. Might be better with slow SD card disks to ask the OS to work harder to not swap to disk and use more RAM when it can. I’m not certain but bet the tradeoff is more but shorter pausing for disk access as RAM fills up as opposed to longer but more infrequent pauses if the OS freely uses swap.

Putting swapfiles in memory has made sense before, though. Early on, OS’s couldn’t access and use all the memory you could load onto a motherboard so there were even drivers supplied that turned extra RAM into swap disks and definitely improved performance.

A swapfile in RAM is effectively what zram is, except it makes use of compression. You can therefore get more usable ram space out of your hardware. There is a performance penalty from the compression, but it is still faster than actually writing out to a swapfile on disk. On memory constrained systems it can be quite a big benefit.

if it uses compression, yes. Otherwise it will be useless to take away 2 GB of RAM and giving exactly these 2 GB back as swap.
That’s what i was referring to :slight_smile: