Is Gentoo bad for a microSD

[thegrind]

I have a microSD on a Rpi5. I am looking to compile a kernel and headless chromium. Will all this emerging and compiling really chew up my card? I bought a better performing but I'd like to move it over after I'm done with some heavy compiling/emerging. Thoughts?

[Zucca]

I'd maybe use an USB stick to store Portage temporary files (PORTAGE_TMPDIR).
_________________
..: Zucca :..

[Banana]

They have improved over the years, but I would suggest either: Build on different PC, use binhost or use an extranl drive on your Pi.
_________________
Forum Guidelines

PFL - Portage file list - find which package a file or command belongs to.
My delta-labs.org snippets do expire

[pa4wdh]

I have been running a Raspberry Pi 2 based NTP server since 2016 running Gentoo from a microSD card. It's biggest compile job is gcc (running the job from disk and using lots of swap because it only has 1GB of memory). So far i've replaced the SD card twice, but never because it failed. I usually get low on space for the rootfs and wait for nice discounts on cards.
Now it has a 128GB Samsung card i bought for about 20 euros using f2fs as a filesystem. As far as i know sdcards don't have smart-like functions so i can't tell how much has been read/written on the card.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[Naib]

Things have improved but the old trope still exists (but is still something to be mindful of)... >100,000writes means you are likely to face physical failure before bit failure.
Gentoo and linux does increase the number of writes but there are some things you can do to prolong it

1. disable atime
2. disable logging - or selectively
3. use a non-journaled FS (or use FSFS)
4. use gentoo binhost
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;

[flysideways]

With the Pi 5 comes the option of using an nvme adapter.

This is from an sd card in a Pi 5

[NeddySeagoon]

Personally, if you must use an SD card, choose a good quality card, not a noname one and over provision it.
Many SD cards do wear levelling now, so F2FS will fight the inbuilt wear levelling, if you have it.

Does fstrim -av trim your card, or is trim not supported for you?
That's a good thing to do once a month to keep free space erased to keep write speeds up.
if trim is supported, you probabably have wear levelling too but there is no way to be sure.

I use a 512Gb Sandisk card with a desktop install. It want's to build Chromium every week.
Its a ~arm64 install except Chromium, which is stable.

The only reason I don't use NVMe is that Pi5 has to be silent, so passively cooled.
Maybe I could do some metalwork to use a bottom NVMe but that's for the future.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[pingtoo]

I use RPI5 for my daily drive. It is gentoo based on SD card. However I seldom compile on it. I use other nodes on my network that provide NBD then I pool those NBD with LVM and mount the lv as /var/tmp. Just give you some idea for possible workaround the SD card write concern.

[Goverp]

[pingtoo]

Goverp,

Thank you for sharing your f2fs experience. I think I will try it for my next stage4 build for rpi5. However I have one concern. I remember from somewhere it suggest f2fs are tie to kernel. i.e change kernel version may cause the file system on disk not usable. Is this true? or it was but changed so now it no longer is the case?

[Ralphred]

[eccerr0r]

most SD cards are probably using TLC or QLC flash memory and probably will only get 800-1000 erase cycles before becoming unreliable. Wear leveling will increase apparent erase cycle life. It appears there are "industrial" microsd cards that have SLC in them... these probably can do the 100K cycles.

I'm not sure if SD cards have become "fully associative" like most nvme/sata versus "set associative" wear leveling - at least this was a thing in the past. I also highly doubt it has inactive pool recycling like properly designed nvme/sata SSDs as it would really kill interactive performance that's slow enough as it is...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[lars_the_bear]

I don't care how many writes my Raspberry Pi SD cards can tolerate. SD cards large enough for a Pi root filesystem are cheap, and I regard them as disposable. When I'm actively working on a Pi project, every so often I pull the SD card and copy it. This takes a few minutes, but I don't have to sit and watch it. Then, if an SD fails, I just copy the back-up image to an new SD and I'm good to go. In practice, I've never had an SD card fail, if it looked like it was in good order when I bought it. The ones that have failed are the ones I bought in bulk at too-good-to-be-true prices, and seemed dodgy right from the start.

BR, Lars.

[Goverp]

[pingtoo]

[eccerr0r]

[gentoo_ram]

You have options.

1. I run an RPi5 with the NVME HAT+ option. It's running a real NVME drive direct over a PCI-E link. Increases performance and deals with the MMC wear issue.
2. I boot an RPI4 with a USB3-to-NVME adapter with an NVME drive inside. From what I can tell that's higher throughput than the SDCard and deals with the wear issue.
3. I put my /var/tmp/portage on a ZRAM device so it's all compiled in compressed RAM. Installs would happen over SDCard and/or NVME as appropriate. Would also reduce SDCard write wear.

[eccerr0r]

I have a RPi2 ...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?