move /var/log to a RAMDISK

Restarts are not a problem really. the whole central heating system dies when the power goes out anyway.

If I wanted to run through that I'd UPS the whole damned thing.

no argument there. Was there even at the time of MSDOS. I once traced through the code that ran when you hit a key on the keyboard. Thousands of instructions

Neat stuff

OK, I remember looking at this back in December and coming to the conclusion it was hopeless. Micro SD cards (probably) don't do active wear levelling + I wasn't clear what IO actually killed them. I seem to remember, someone suggesting it was the EXT4 journal file that was the problem rather than logs.

That's old hat for anyone who's had to work with M$ products.

-- /~\ Charlie Gibbs | You can't save the earth \ / snipped-for-privacy@kltpzyxm.invalid | unless you're willing to X I'm really at ac.dekanfrus | make other people sacrifice. / \ if you read it the right way. | -- Dogbert the green consultant

For many years scientists have tried to perfect fault tolerant systems. Meanwhile, Microsoft profits by exploiting fault tolerant customers.

I've seen that as a programming design philosophy. The idea is that it should be possible to kill the program at any time without depending on it going through some cleanup/finish code it can just stop without losing anything. The startup code always goes through the crash recovery and everything necessary to recover must be flushed to disc before acknowledging an input.

That is a slightly terrifying thought...does anyone have any more information? Mm. It would seem that while journalling multiplies the number of writes, it wont impact what amounts to a read-only or 'write very rarely' filesystem. Phew. Obviously of you are wring huge amounts of data over and over again you would probably attach an SSD via USB anyway..

Well that's why we eliminated M$ - and installed Linux, innit?

The problem with the ext4 journal and a SD card /without wear leveling/ is the journal is in a fixed location on the disk, so any write anywhere that is journaled also becomes a write onto the journal area of the disk. So the flash cells underlying the area of the journal see far more writes than the rest of the cells, and wear out sooner.

Now, *with wear leveling* those journal writes that are logically to the same blocks on the disk get spread all over the flash cells via the wear leveling controller, mitigating the issue of a lot of writes happening to the same blocks on the disk. The write amplification issue is still present in any case.

But agreed, as you've reduced the number of writes to a bare minimum, you likely won't need to worry about whether your sd card has, or does not have, a wear leveling controller. Few to zero writes means little to no wear.

I'm using 11 GB of a 32 GB sd card using ext4 on an rpi 4b. A little slow to boot but otherwise performance pretty good. It's running kde plasma, with no workarounds to avoid extra writes, just disabling things I don't like in plasma like desktop effects and most background services.

# free -m total used free shared buff/cache available Mem: 3831 1289 1141 49 1400 2305 Swap: 6696 0 6696

It's currently running konversation and guvcview for a camera, but I've used firefox on it too. Firefox is slow, but not unusable.

I use it mainly for konversation so I can do things on my main desktop system while discussing things in irc.

I have some spare sd cards just in case and keep regular backups on my main system. I've been running it with the same sd card since Feb. 2021.

The sd cards are in packages labeled Lexar high-performance 633x microSDHC UHS-I.

I have no idea if that does wear leveling.

The rpi 4b has much better performance than I expected given that it's using an sd card. I was going to try xfce4 with it, but after seeing it's performance decided to try kde plasma.

Using something like f2fs would probably be better, but ext4 is working fine for me. Knock on wood. :-)

Regards, Dave Hodgins

I guessed that the worry was that the journal was a smallish single file, used as a circular buffer (maybe 128MB). So, without wear levelling, the same few blocks would be getting hit all the time. Meaning the SD card dies well below any quoted TB Written endurance stat.

But.., I appear to have been wrong, some micro SD cards do, indeed, do wear levelling, the Kingston Industrial for example. But it is pricey £24 quid for £64 GB (32 GB even more expensive).

Due to this high cost of the industrial SD, for my rPi, I still arrive at the same conclusion, yearly replacement of a cheap SD.

Remember write amplification - flash storage uses very large blocks

Mmm. But that goes for directory entries which get time stamped, as well I think any card with NO wear levelling - that is no mapping from logical to physical sectors - is not going to work as a card at all, because the OS will be dealing in much smaller sectors than the SD card, and the card has to erase large blocks.

So there must be some processor s*it going on to map logical to physical blocks and it is then no cost saving to have s*it software. Unfortunately that means you need to have somewhere to store that mapping, and THAT area will get a lot of writes. Dunno how they manage that.

I suspect the cheaper chips have substandard NVRAM

Yes. When I thought about what was happening in the application, the user makes occasional config changes, but apart from that, nothing needs to change. If it goes wrong, unless it's me, logs are pointless. And I am keeping RAM logs, which are worth it for live debugging.

I dunno how fast an SSD with a USB interface would be compared with a SATA, but if I was using a pi for user level stuff, I'd want some kind of SSD in there with the SD card only there to boot the thing.

My impressions is that a Pi is about as fast as a 486 used to be. or maybe a bit more. Many people say the latest Pi is pentium 4 level or thereabouts.

Indeed.

Oddly enough my SSD drives seem to be lasting better than the spinning rust they replaced. The wear levelling in THOSE really works. So my tentative feeling at this point in time is that while /boot might be on the SD card, if I were to use a pi for serious R/W everything else would be an SSD mounted somehow at boot. I believe with later PIs you can boot the whole thing from USB/SSD or rust.

For me that leads to a sort of tentative conclusions - if I want a busy server, or user desktop, I'd pick a late model Pi and USB boot it. If I want an embedded device, I'd pick an SD card and tune the OS not to use it, if possible.

And for serious storage, the later OS supports SATA hats...

sd cards are a lot cheaper. :-)

This is an rpi 4b, which is a quad core (1 thread per core) and 4GB ram.

lscpu shows 108.0 BogoMIPS, while my desktop system with an AMD FX(tm)-4170 Quad-Core Processor from 2012 shows 8428.66 BoboMIPS. Despite the low number of BogoMIPS, I'm still impressed by it overall.

It's fine for running the few applications I use it for.

Regards, Dave Hodgins

I remember the "battery hat" - still sold :

However I don't think the most stress to SD cards is on boot - but during regular USE ... the usual data churning and loading system apps from the card. If "ping" is used, well, where does it COME from on a PI ? The SD card. Each application has to be examined to see what routines are used and put them into a RAMdisk or whatever. Remember, even reading an SD card involves re-writing the thing, that's how the tech works.

Hey, I *remember* those days ! Bill Gates kinda rose to fame because there used to be contests over how to write basic functions in the very least number of bytes/cycles. Consider how TINY his BASIC was at the start, yet could DO so much. These days - ten or more times the pork for barely more function and if it doesn't have a giant slick GUI nobody wants to use it.

Yea, Bill became a total asshole, but at the beginning ...

I've always liked micro-controllers. Very little RAM/ROM or even speed. The goal is to use every trick to squeeze as much function from every single byte as possible. That is an entirely different philosophy from what we commonly see today.

Used to do ASM on micro-controllers, but over the past decade the better 'C' compilers are actually smarter, can do the same in even fewer bytes/cycles than most human-writ code. Not by a HUGE margin, but, on tiny devices, maybe enough.

Yep, and FAMILIAR too. This was the kind of stuff "developers" had to deal with back in the day, right down to making the hardware. No "standard drivers" or off-the-shelf plug-in cards back then worth s*it. If it was worth doing you had to do it ALL yourself from the crappy chips on up.

Such INTERESTING days ! :-)

I'd say maybe 1830-1900 were equally interesting for the old MECHANICAL developers. Ah to be on Edison's team (even though he was an asshole) !!! :-)

Some new "interesting days", or "day", may be yet to come - but it's in "AI" development. After that there's nothing left (for humans). It'll be robotopia, or the "Savage Reservation" ....

That seems right to me too.

Heh, heh ... ALWAYS a lot more complicated than it SEEMS :-)

On the old IBM-PCs there were a bunch, a whole bunch, of BIOS routines. These were pretty well optimized code due to size limits of the time. Using ASM you could exploit them nicely - get KB input, do X-Y output to the monitor, like all the stuff you'd need for a smart WYSIWYG text editor, all from these built-in routines.

Still have the old IBM Technical Reference Manual. All that stuff was meticulously documented.