RaspberryPi Zero2W

[MarkMLl]

I recently found, using Debian Bookworm on a PasPi4 with only 2G ram that I needed to increase swap to 1G when compiling Lazarus. The same hardware a year (?) ago running Debian Bullseye based Raspi OS worked 'out of the box', so I don't know if its because Lazarus has got bigger or the OS has got bigger, both true of course.

I'm not entirely happy with the performance of "Bookworm" on an x86_64, so that would be my first suspect.

Let's blame it on systemd...

MarkMLl

[Mark20]

Thank you for all tips !
About the "SD-Card that has little-to-no wear levelling and it won't last long",
also a standard Rpi4 could have the same problem ?

[TRon]

About the "SD-Card that has little-to-no wear levelling and it won't last long",
also a standard Rpi4 could have the same problem ?

Not could, but does have the same issue.

The only difference is that a pi4 has the option to come in variations with more memory which reduces (or can reduce) the number of writes to the sd-card. If you have a pi4 with enough memory then consider compiling to a ram disk or use a (USB) attached storage device that is more robust.

[MarkMLl]

About the "SD-Card that has little-to-no wear levelling and it won't last long",
also a standard Rpi4 could have the same problem ?

Not could, but does have the same issue.

The only difference is that a pi4 has the option to come in variations with more memory which reduces (or can reduce) the number of writes to the sd-card. If you have a pi4 with enough memory then consider compiling to a ram disk or use a (USB) attached storage device that is more robust.

Plus modern SD-Cards /might/ be more robust. But apart from that: /all/ devices which write to an SD-Card have the same problem unless they're using a filesystem designed- from the ground up- to have its own wear-levelling. Swap is particularly brutal, and this has been an issue since the Pi-1.

I think it was the Pi-3 which introduced the ability to boot from USB-connected media, although it was disabled by default. But in any event it's never been difficult to boot from card but mount external media a the root device (i.e. /) although there's obviously a possibility that an version of Raspbian that wasn't expecting it might be unhappy e.g. applying updates.

In practice, I've got an RPi-3 here driving a 3D printer etc., it boots Buster from "spinning rust" and apart from font metrics issues that I think I've mentioned in another thread I've never had any problems.

MarkMLl

[TRon]

Plus modern SD-Cards /might/ be more robust. But apart from that: /all/ devices which write to an SD-Card have the same problem unless they're using a filesystem designed- from the ground up- to have its own wear-levelling.

Correct.

Swap is particularly brutal, and this has been an issue since the Pi-1.

I can confirm.

I think it was the Pi-3 which introduced the ability to boot from USB-connected media, although it was disabled by default. But in any event it's never been difficult to boot from card but mount external media a the root device (i.e. /) although there's obviously a possibility that an version of Raspbian that wasn't expecting it might be unhappy e.g. applying updates.

AFAIK every device listed here is capable of booting using USB host mode (at least it is advertised as such) and also AFAIK the pi3 allows to directly boot from a USB device (after some initial setup).

In practice, I've got an RPi-3 here driving a 3D printer etc., it boots Buster from "spinning rust" and apart from font metrics issues that I think I've mentioned in another thread I've never had any problems.

I do not have any issue with my pi's either but it seems that either there are people that have a terrible choice in selecting a proper SD card manufacturer/brand or do not fully understand that when you log data every 2 milliseconds that you are not suppose to write that log to a file on a SD-card that every 2 milliseconds. That will kill your SD-card for sure within a couple of weeks, if not days.

I have tested with running Lazarus on a pi3B+ but that is definitely too much to handle for that poor little thing as it requires swap for a rebuild and Lazarus/FPC does write a lot of data for/on each compilation. It is an eye opener when you dive deeper into that topic and also made me more aware so that I now use a ramdisk instead of ssd-storage for my builds and compiles (even though the wear leveling is in a much better position/state for SSD storage).

[MarkMLl]

I do not have any issue with my pi's either but it seems that either there are people that have a terrible choice in selecting a proper SD card manufacturer/brand

https://www.bunniestudios.com/blog/?page_id=1022 is a good read under the circumstances.

In practice, my recollection is that there were issues on the Pi-3, even after you'd told it to boot from an external medium, if you wanted to implement your root device using software RAID or with an encryption layer. I forget the detail, but allowing that the initial boot code was in 32K of internal ROM I don't think it was fixable.

MarkMLl

[dbannon]

I do not have any issue with my pi's either but it seems that either there are people that have a terrible choice in selecting a proper SD card manufacturer/brand or do not fully understand that when you log data every 2 milliseconds that you are not suppose to write that log to a file on a SD-card that every 2 milliseconds. That will kill your SD-card for sure within a couple of weeks, if not days.

Back when I was using a Pi 1, I was also having quite a lot of (external) power problems. I was surprised to note that the Pi seemed to cache writes for close to 24 hours. So, if the power goes off today, no data was saved after some time yesterday. Unless you call sync....

So, I guess that was to protect the sdcard from just what we are talking about. But that is not going to help when we get a page fault ! So, using it for swap is the real danger.

David

[Mark20]

I see some Rpi4 clones that have 32GB of eMMC flash onboard; do you know if this kind if flash solve the wear problem ?

[MarkMLl]

A few seconds Googling turns up https://forums.raspberrypi.com/viewtopic.php?t=358782

However I have no personal experience of that, and I'd suggest that "clone" behaviour might or might not be the same as the "real thing".

On reflection, I do have a very vague recollection of something which might have been an eMMC module on the back of an RPi clone badged (I think) Acer, which failed for unspecified reasons within weeks.

I'd also remind you of https://hackaday.com/2021/02/11/tesla-recalls-cars-with-emmc-failures-calls-part-a-wear-item/ as a cautionary tale.

MarkMLl

[TRon]

EMMC suffers from the same wear leveling issues, especially because the capacity of the devices for these kind of SBC is very small (in comparison). I do not have fond memories of emmc and avoid it like the plague (but perhaps things have improved over time).

I would be wary if it's soldered down on the board as that makes it nearly impossible to replace unless you have the equipment and are familiar with replacing such parts.

[dbannon]

I find that depressing. No wear leveling for eMMC "laptops" ?  These thing dominate the small laptop market. I still have little 10 year old Netbook, I have replaced the screen (I stood on it), the hard disk (with a standard SSD) and memory. Its no power house but its my 32bit test platform ! I'd buy a new version of it if available but would not touch a eMMC driven box.

I guess I'd think the same way with a RasPi clone but it is a different price point .....

EDIT: No, I think I might be a bit too critical.

NAND flash storage is not a simple read/write data medium. For reliable use, several algorithms should be implemented: NAND block management, garbage collection, error control and wear levelling. Modern NAND flash is managed, with algorithms on the storage device, not implemented in the host processor.

https://www.kingston.com/en/blog/embedded-and-industrial/emmc-lifecycle

Davo

[Mark20]

Seems a problem with no way out...  at least for solid long last solution...
May be we have to change  the way we program, bringing all possible in Ram, and commit to flash only when really necessary...

[MarkMLl]

Seems a problem with no way out...  at least for solid long last solution...
May be we have to change  the way we program, bringing all possible in Ram, and commit to flash only when really necessary...

Which doesn't really help if the RAM isn't protected by ECC bits.

However I repeat my earlier position: eMMC is supposedly protected by at least some internal "intelligence", but that didn't help the Tesla owners.

MarkMLl

[dbannon]

Seems a problem with no way out...  at least for solid long last solution...
May be we have to change  the way we program, bringing all possible in Ram, and commit to flash only when really necessary...

Mark20, if you are doing a small project that, once done will just run in the background, you will probably be alright.  Just keep in mind its better to write dribbling data to somewhere other that the sdcard, even a USB key.

If you are using the Pi as an on going development platform, then you are taking more significant risks. Its up to you to work out the impact, on you, of those risks. Note -

• Almost all risks are mitigated if you mount some external disk and use that for both swap and compiling. 
• You will probably find compiling a great deal quicker using a (reasonable) external disk for the i/o intensive stuff anyway.
• If your Pi has 4g ram, it probably will not go into swap anyway.
• If you keep good backups, SDcards are cheap, maybe you are willing to risk it ?

Davo

[Mark20]

Yes Davo,
for me it worth study a proper configuration and best practice to minimize risks.
I see room to work on this.

If I have to deal with projects where an ATmega32 is not enough, I want to switch on PiZero.
Also because  other "micro" as ESP32 are complex too; it's not easy to get a real and full control of such devices.
At least with Rpi and Lazarus I have a full software ecosystem which I can rely on.