move /var/log to a RAMDISK

Ah, obfuscation ....

Is that in the FSB handbook ? Surely !

Piss off.

I tend to separate "CPU"s from "u-Controllers". They are really different "concepts", aimed at different universes.

u-Controllers offer VERY fine-grained control ... but not much "performance" in the conventional sense. They are for interacting with the often-messy Real World.

In THIS context, you CAN basically turn OFF a u-Controller chip - no power used except waiting for a signal on an interrupt pin. You can run the clockspeed down to almost nothing (actually nothing on some). You can't do that with "CPU"s. Different worlds. Different apps.

Epson did, I think still, sells 4-bit u-Controllers. They're mostly meant for coin-cell devices like remote controls and thermostats and such and you have to order like 100,000 at a time. However, if you read the docs, they are just FANTASTICALLY versatile - endless tricks you can use to cope with Real World needs. 4-bits really CAN be more than enough.

Look it up. I don't have time to do all your research.

YOU don't do the re-write, the logic for that it is built into the flash device, hidden in the background. Reading kinda blanks what's there, and then it has to be re-writ.

Well, have fun with the bollocks ...

I was there long before any of this tech was invented, learned the good AND bad. A lot of the bad has been *disappeared* of late ...

IF your needs are small enough, under 256kb or so, with u-controller apps, then look into FRAM rather than "flash". Oh, it's a lot FASTER too, no waiting cycles for R/W.

"Flash" is not just some dumb memory chip despite how it tries to present itself to the user, it has a CONTROLLER. One function is "wear-leveling" but another underlying function is the "re-write on read" aspect.

I am well aware of how DRAM works ... I was in the biz BEFORE DRAM. Ah, SRAM ... so much nicer to deal with. They couldn't scale it up alas.

"Flash" is a "smart device". It has a controller. One function is "wear-leveling", but another is "rewrite on read". YOU never see this stuff.

Nope - but it's not quite as it sounds for details see this patent:

Yes, that is what I found, also. Essentially a read is between ten and a thousand times less destructive than a write.

But in the context of a PI running Raspios or other Linux, with adequate RAM, 99.99% of reads will be from cache, not the card, anyway. So you can safely ignore this theoretical issue

Obviously if you are building a busy NAS device, where such conditions do not apply, you would not be using an SD card anyway.

You pretty much have to ignore it anyway it's all internal to the device where you have no access to change anything.

More utter bollocks from the nymshifting troll.

DRAM's rewrite on reads - flash does not.

That's the DRAM read cycle, not the flash read cycle.

And so far, across about 20 different nymshifts, you've spouted by far more incorrect bullshit than correct information (that and significant irrelivant Abe Simpson like 'asides').

Flash does not rewrite on read -- DRAM does, but not flash.

This patent is describing what TNP posted in his other thread about "disturbing" adjacent cells:

Quoting from early in the description:

The read disturb error is such a phenomenon that, when data on a certain page of a certain physical block are read out frequently, data being stored in a cell on other pages of the data read block are changed.

And a little further on they detail the number of reads necessary to trigger the refreshing rewrite:

For example, among currently available products, the single-level cell (SLC) type has the limit of the number of data read of 100,000 to 1,000,000 times and the multi-level cell (MLC) type has the limit of the number of data read of 10,000 to 100,000 times (generally, these limits tend to be lowered as the data reading frequency is increased).

However the nymshift troll is presenting its false argument as "all reads cause a rewrite".

Well not exactly, the argument was about minimising reads as well as writes to minimise wear.

My point was to get back from armchair theorising to practicalities. In practice the disk cache reduces regular reads issues to the card, to zero.

That sounds about right to me.

Yeah that was silly.

For what you've described as your use cases for the PI's, yes, the Linux disk cache should minimize the number of reads that hit the SD card. That is once it has booted and reached its normal operational steady state.

You should end up seeing very close to zero reads and writes to the PI sd cards given what you've described to us. Certianly a low enough rate that even a less than stellar card should last for quite a long time.

First off, NO state will be leaving the USA - it's actually illegal, they can and will send in the army. Bet on it.

As for "differences" ... that was part of the whole idea of a United STATES. Not every environment, every local culture, every local need, is the same. Truly "national" govts like to forget that - and it causes BIG problems. Can even cause bloody revolutions where everyone suffers horribly.

As for "empires" - there's a FALLACY to "empire" in the usual meaning. They only survive by engulfing more and more - and every bit they obtain soon becomes a management EXPENSE. It's doomed. From Sumer and Akkadia all the way to Rome and the Mongols and Ottomans, this has been the horrible horrible truth of "empires". They are about EGO, not fiscal reality.

But then this was SUPPOSED to be about what to do with /var/log :-)

The latest bookworm release (32 bit lite) October 10th 2023 does not seem to have the directory

/etc/rsyslog.d

and so I created it and copied drop.systemd.conf into it. Is that the right thing to do ?

Bob.