Doing the research reveals the true case about wear on flash memory
style devices and that is that substantially reads do *not* damage the
cells at all, at least no more than reading, say, DRAM. It is block
erases and writes that do and so, paradoxically, when used as a PROM, probably wear levelling is entirely unnecessary. And if done
gratuitously may actually reduce lifetime. By 'gratuitously;, I mean
that it is done when there is no write operation in progress.
I cannot see any reason why one would shuffle blocks around *except* as
a result of a write operation, however.
There appears to be one aspect of read operations that *does* disturb
the data (read distrurbance), and that is that read operations can
minutely affect the state of physically adjacent but unread cells.
However this is generally at least an order of magnitude below write
damage, and is normally dealt with by error correction.
So smart SSDS with good wear levelling will *occasionally* rewrite read
only blocks, but this is in terms of hundreds of thousands of reads.
In my particular application the reads to reasonably static
configuration files will exceed 32 million per annum, or rather they
would *without disk caching*...
Now I am unaware as to how long Linux will regard a read only file that
is fully cached (my files are less than 1kBytes) as valid. I cannot
see *any* reason why re-reading file data that the operating systems
*knows* has not changed, would result in any actual 'physical' reads to
the SD card *at all*.
And in fact in my particular application one code and data is loaded,
even changing the configurations files should not result in a physical
read, as the disk cache itself used to do the writing will retain the information.
I think the summary of all of this research is significant for PI users running Linux in what may be generally classed as 'read often, write
seldom' accesses to an SD card, and that is that by far and away the
greatest protection the card has is the Linux disk buffering algorithm itself, provided that constant reads do not exceed its capacity. In a
typical 24x7 applications there is no reason why, post boot, any SD
reads should happen *at all*, once the disk cache is full. It also shows
the absolutely vital role that '-noatime' plays in protecting read only
files that are read continuously from producing unwanted writes.
As far as writes go there will (nearly) always be a 1:1 correlation eventually between writes to the linux file system and writes to the SD
card: The exception being data that us rewritten to the same disk file
cache before it gets flushed to physical storage.
So the general rule in utilising the SD card in the most effective
manner, is to reduce writes to a minimum by firstly mounting the card -noatime, and secondly using RAM disks to do any logging that you can't
turn off, and for all operations where ephemeral data are being recorded
and read, but which do not need to survive a reboot. Then, having a superfluity of RAM available for disk caching will reduce SD *reads* to essentially zero. No matter how often the file system is accessed by the application.
And in fact using iostat on my running application shows no (physical)
reads or writes *AT ALL*. As evinced by the rock steady light on the Pi
Zero.
Am 11.08.23 um 11:54 schrieb The Natural Philosopher:
Doing the research reveals the true case about wear on flash memory
style devices and that is that substantially reads do *not* damage the
cells at all, at least no more than reading, say, DRAM. It is block
erases and writes that do and so, paradoxically, when used as a PROM,
probably wear levelling is entirely unnecessary. And if done
gratuitously may actually reduce lifetime. By 'gratuitously;, I mean
that it is done when there is no write operation in progress.
I cannot see any reason why one would shuffle blocks around *except* as
a result of a write operation, however.
There appears to be one aspect of read operations that *does* disturb
the data (read distrurbance), and that is that read operations can
minutely affect the state of physically adjacent but unread cells.
However this is generally at least an order of magnitude below write
damage, and is normally dealt with by error correction.
So smart SSDS with good wear levelling will *occasionally* rewrite read
only blocks, but this is in terms of hundreds of thousands of reads.
In my particular application the reads to reasonably static
configuration files will exceed 32 million per annum, or rather they
would *without disk caching*...
Now I am unaware as to how long Linux will regard a read only file that
is fully cached (my files are less than 1kBytes) as valid. I cannot
see *any* reason why re-reading file data that the operating systems
*knows* has not changed, would result in any actual 'physical' reads to
the SD card *at all*.
And in fact in my particular application one code and data is loaded,
even changing the configurations files should not result in a physical
read, as the disk cache itself used to do the writing will retain the
information.
I think the summary of all of this research is significant for PI users
running Linux in what may be generally classed as 'read often, write
seldom' accesses to an SD card, and that is that by far and away the
greatest protection the card has is the Linux disk buffering algorithm
itself, provided that constant reads do not exceed its capacity. In a
typical 24x7 applications there is no reason why, post boot, any SD
reads should happen *at all*, once the disk cache is full. It also shows
the absolutely vital role that '-noatime' plays in protecting read only
files that are read continuously from producing unwanted writes.
As far as writes go there will (nearly) always be a 1:1 correlation
eventually between writes to the linux file system and writes to the SD
card: The exception being data that us rewritten to the same disk file
cache before it gets flushed to physical storage.
So the general rule in utilising the SD card in the most effective
manner, is to reduce writes to a minimum by firstly mounting the card
-noatime, and secondly using RAM disks to do any logging that you can't
turn off, and for all operations where ephemeral data are being recorded
and read, but which do not need to survive a reboot. Then, having a
superfluity of RAM available for disk caching will reduce SD *reads* to
essentially zero. No matter how often the file system is accessed by the
application.
And in fact using iostat on my running application shows no (physical)
reads or writes *AT ALL*. As evinced by the rock steady light on the Pi
Zero.
What exactly is your question?
On 11/08/2023 13:24, Jörg Lorenz wrote:
Am 11.08.23 um 11:54 schrieb The Natural Philosopher:My question is "Why did you think that a post has to be a question?"
Doing the research reveals the true case about wear on flash memory
style devices and that is that substantially reads do *not* damage the
cells at all, at least no more than reading, say, DRAM. It is block
erases and writes that do and so, paradoxically, when used as a PROM,
probably wear levelling is entirely unnecessary. And if done
gratuitously may actually reduce lifetime. By 'gratuitously;, I mean
that it is done when there is no write operation in progress.
I cannot see any reason why one would shuffle blocks around *except* as
a result of a write operation, however.
There appears to be one aspect of read operations that *does* disturb
the data (read distrurbance), and that is that read operations can
minutely affect the state of physically adjacent but unread cells.
However this is generally at least an order of magnitude below write
damage, and is normally dealt with by error correction.
So smart SSDS with good wear levelling will *occasionally* rewrite read
only blocks, but this is in terms of hundreds of thousands of reads.
In my particular application the reads to reasonably static
configuration files will exceed 32 million per annum, or rather they
would *without disk caching*...
Now I am unaware as to how long Linux will regard a read only file that
is fully cached (my files are less than 1kBytes) as valid. I cannot
see *any* reason why re-reading file data that the operating systems
*knows* has not changed, would result in any actual 'physical' reads to
the SD card *at all*.
And in fact in my particular application one code and data is loaded,
even changing the configurations files should not result in a physical
read, as the disk cache itself used to do the writing will retain the
information.
I think the summary of all of this research is significant for PI users
running Linux in what may be generally classed as 'read often, write
seldom' accesses to an SD card, and that is that by far and away the
greatest protection the card has is the Linux disk buffering algorithm
itself, provided that constant reads do not exceed its capacity. In a
typical 24x7 applications there is no reason why, post boot, any SD
reads should happen *at all*, once the disk cache is full. It also shows >>> the absolutely vital role that '-noatime' plays in protecting read only
files that are read continuously from producing unwanted writes.
As far as writes go there will (nearly) always be a 1:1 correlation
eventually between writes to the linux file system and writes to the SD
card: The exception being data that us rewritten to the same disk file
cache before it gets flushed to physical storage.
So the general rule in utilising the SD card in the most effective
manner, is to reduce writes to a minimum by firstly mounting the card
-noatime, and secondly using RAM disks to do any logging that you can't
turn off, and for all operations where ephemeral data are being recorded >>> and read, but which do not need to survive a reboot. Then, having a
superfluity of RAM available for disk caching will reduce SD *reads* to
essentially zero. No matter how often the file system is accessed by the >>> application.
And in fact using iostat on my running application shows no (physical)
reads or writes *AT ALL*. As evinced by the rock steady light on the Pi
Zero.
What exactly is your question?
This is information for Pi people using SD cards. Condensing a mornings research into some general practical conclusions.
If you are not interested in it, just skip it.
On 11/08/2023 13:24, Jörg Lorenz wrote:[snip long research summary]
Am 11.08.23 um 11:54 schrieb The Natural Philosopher:
My question is "Why did you think that a post has to be a question?"
And in fact using iostat on my running application shows no (physical)
reads or writes *AT ALL*. As evinced by the rock steady light on the Pi
Zero.
What exactly is your question?
This is information for Pi people using SD cards. Condensing a mornings research into some general practical conclusions.
If you are not interested in it, just skip it.
Am 11.08.23 um 17:21 schrieb The Natural Philosopher:
On 11/08/2023 13:24, Jörg Lorenz wrote:
Am 11.08.23 um 11:54 schrieb The Natural Philosopher:My question is "Why did you think that a post has to be a question?"
Doing the research reveals the true case about wear on flash memory
style devices and that is that substantially reads do *not* damage the >>>> cells at all, at least no more than reading, say, DRAM. It is block
erases and writes that do and so, paradoxically, when used as a PROM,
probably wear levelling is entirely unnecessary. And if done
gratuitously may actually reduce lifetime. By 'gratuitously;, I mean
that it is done when there is no write operation in progress.
I cannot see any reason why one would shuffle blocks around *except* as >>>> a result of a write operation, however.
There appears to be one aspect of read operations that *does* disturb
the data (read distrurbance), and that is that read operations can
minutely affect the state of physically adjacent but unread cells.
However this is generally at least an order of magnitude below write
damage, and is normally dealt with by error correction.
So smart SSDS with good wear levelling will *occasionally* rewrite read >>>> only blocks, but this is in terms of hundreds of thousands of reads.
In my particular application the reads to reasonably static
configuration files will exceed 32 million per annum, or rather they
would *without disk caching*...
Now I am unaware as to how long Linux will regard a read only file that >>>> is fully cached (my files are less than 1kBytes) as valid. I cannot
see *any* reason why re-reading file data that the operating systems
*knows* has not changed, would result in any actual 'physical' reads to >>>> the SD card *at all*.
And in fact in my particular application one code and data is loaded,
even changing the configurations files should not result in a physical >>>> read, as the disk cache itself used to do the writing will retain the
information.
I think the summary of all of this research is significant for PI users >>>> running Linux in what may be generally classed as 'read often, write
seldom' accesses to an SD card, and that is that by far and away the
greatest protection the card has is the Linux disk buffering algorithm >>>> itself, provided that constant reads do not exceed its capacity. In a
typical 24x7 applications there is no reason why, post boot, any SD
reads should happen *at all*, once the disk cache is full. It also shows >>>> the absolutely vital role that '-noatime' plays in protecting read only >>>> files that are read continuously from producing unwanted writes.
As far as writes go there will (nearly) always be a 1:1 correlation
eventually between writes to the linux file system and writes to the SD >>>> card: The exception being data that us rewritten to the same disk file >>>> cache before it gets flushed to physical storage.
So the general rule in utilising the SD card in the most effective
manner, is to reduce writes to a minimum by firstly mounting the card
-noatime, and secondly using RAM disks to do any logging that you can't >>>> turn off, and for all operations where ephemeral data are being recorded >>>> and read, but which do not need to survive a reboot. Then, having a
superfluity of RAM available for disk caching will reduce SD *reads* to >>>> essentially zero. No matter how often the file system is accessed by the >>>> application.
And in fact using iostat on my running application shows no (physical) >>>> reads or writes *AT ALL*. As evinced by the rock steady light on the Pi >>>> Zero.
What exactly is your question?
Because the posting otherwise is unsoliceted spam?
This is information for Pi people using SD cards. Condensing a mornings
research into some general practical conclusions.
If you are not interested in it, just skip it.
I'll ask when I am interested.
Am 11.08.23 um 17:21 schrieb The Natural Philosopher:
On 11/08/2023 13:24, Jörg Lorenz wrote:
Am 11.08.23 um 11:54 schrieb The Natural Philosopher:My question is "Why did you think that a post has to be a question?"
Doing the research reveals the true case about wear on flash memory
style devices and that is that substantially reads do *not* damage the >>>> cells at all, at least no more than reading, say, DRAM. It is block
erases and writes that do and so, paradoxically, when used as a PROM,
probably wear levelling is entirely unnecessary. And if done
gratuitously may actually reduce lifetime. By 'gratuitously;, I mean
that it is done when there is no write operation in progress.
I cannot see any reason why one would shuffle blocks around *except* as >>>> a result of a write operation, however.
There appears to be one aspect of read operations that *does* disturb
the data (read distrurbance), and that is that read operations can
minutely affect the state of physically adjacent but unread cells.
However this is generally at least an order of magnitude below write
damage, and is normally dealt with by error correction.
So smart SSDS with good wear levelling will *occasionally* rewrite read >>>> only blocks, but this is in terms of hundreds of thousands of reads.
In my particular application the reads to reasonably static
configuration files will exceed 32 million per annum, or rather they
would *without disk caching*...
Now I am unaware as to how long Linux will regard a read only file that >>>> is fully cached (my files are less than 1kBytes) as valid. I cannot
see *any* reason why re-reading file data that the operating systems
*knows* has not changed, would result in any actual 'physical' reads to >>>> the SD card *at all*.
And in fact in my particular application one code and data is loaded,
even changing the configurations files should not result in a physical >>>> read, as the disk cache itself used to do the writing will retain the
information.
I think the summary of all of this research is significant for PI users >>>> running Linux in what may be generally classed as 'read often, write
seldom' accesses to an SD card, and that is that by far and away the
greatest protection the card has is the Linux disk buffering algorithm >>>> itself, provided that constant reads do not exceed its capacity. In a
typical 24x7 applications there is no reason why, post boot, any SD
reads should happen *at all*, once the disk cache is full. It also shows >>>> the absolutely vital role that '-noatime' plays in protecting read only >>>> files that are read continuously from producing unwanted writes.
As far as writes go there will (nearly) always be a 1:1 correlation
eventually between writes to the linux file system and writes to the SD >>>> card: The exception being data that us rewritten to the same disk file >>>> cache before it gets flushed to physical storage.
So the general rule in utilising the SD card in the most effective
manner, is to reduce writes to a minimum by firstly mounting the card
-noatime, and secondly using RAM disks to do any logging that you can't >>>> turn off, and for all operations where ephemeral data are being recorded >>>> and read, but which do not need to survive a reboot. Then, having a
superfluity of RAM available for disk caching will reduce SD *reads* to >>>> essentially zero. No matter how often the file system is accessed by the >>>> application.
And in fact using iostat on my running application shows no (physical) >>>> reads or writes *AT ALL*. As evinced by the rock steady light on the Pi >>>> Zero.
What exactly is your question?
Because the posting otherwise is unsoliceted spam?
This is information for Pi people using SD cards. Condensing a mornings
research into some general practical conclusions.
If you are not interested in it, just skip it.
I'll ask when I am interested.
Oh? You think that unsolicited information about Linux and rasberry Pis
is spam, in linux and raspberry Pi newsgroups?
What on earth do you think that spam acrually IS?
Am 11.08.23 um 23:07 schrieb The Natural Philosopher:
Oh? You think that unsolicited information about Linux and rasberry Pis
is spam, in linux and raspberry Pi newsgroups?
What on earth do you think that spam acrually IS?
Postings from anonymous Trolls with fake identities.
On 2023-08-11 17:48, Jörg Lorenz wrote:
Am 11.08.23 um 17:21 schrieb The Natural Philosopher:
Because the posting otherwise is unsoliceted spam?What exactly is your question?My question is "Why did you think that a post has to be a question?"
Not correct.
As we are in a Linux group, you might remember that Linus posted his
first kernel here (on comp.os.minix) and it was not a question.
Doing the research reveals the true case about wear on flash memory
style devices and that is that substantially reads do *not* damage the
cells at all, at least no more than reading, say, DRAM. It is block
erases and writes that do and so, paradoxically, when used as a PROM, probably wear levelling is entirely unnecessary. And if done
gratuitously may actually reduce lifetime. By 'gratuitously;, I mean
that it is done when there is no write operation in progress.
I cannot see any reason why one would shuffle blocks around *except* as
a result of a write operation, however.
There appears to be one aspect of read operations that *does* disturb
the data (read distrurbance), and that is that read operations can
minutely affect the state of physically adjacent but unread cells.
However this is generally at least an order of magnitude below write
damage, and is normally dealt with by error correction.
So smart SSDS with good wear levelling will *occasionally* rewrite read
only blocks, but this is in terms of hundreds of thousands of reads.
In my particular application the reads to reasonably static
configuration files will exceed 32 million per annum, or rather they
would *without disk caching*...
Now I am unaware as to how long Linux will regard a read only file that
is fully cached (my files are less than 1kBytes) as valid. I cannot
see *any* reason why re-reading file data that the operating systems
*knows* has not changed, would result in any actual 'physical' reads to
the SD card *at all*.
And in fact in my particular application one code and data is loaded,
even changing the configurations files should not result in a physical
read, as the disk cache itself used to do the writing will retain the information.
I think the summary of all of this research is significant for PI users running Linux in what may be generally classed as 'read often, write
seldom' accesses to an SD card, and that is that by far and away the
greatest protection the card has is the Linux disk buffering algorithm itself, provided that constant reads do not exceed its capacity. In a
typical 24x7 applications there is no reason why, post boot, any SD
reads should happen *at all*, once the disk cache is full. It also shows
the absolutely vital role that '-noatime' plays in protecting read only
files that are read continuously from producing unwanted writes.
As far as writes go there will (nearly) always be a 1:1 correlation eventually between writes to the linux file system and writes to the SD
card: The exception being data that us rewritten to the same disk file cache before it gets flushed to physical storage.
So the general rule in utilising the SD card in the most effective
manner, is to reduce writes to a minimum by firstly mounting the card -noatime, and secondly using RAM disks to do any logging that you can't
turn off, and for all operations where ephemeral data are being recorded
and read, but which do not need to survive a reboot. Then, having a superfluity of RAM available for disk caching will reduce SD *reads* to essentially zero. No matter how often the file system is accessed by the application.
And in fact using iostat on my running application shows no (physical)
reads or writes *AT ALL*. As evinced by the rock steady light on the Pi
Zero.
Am 11.08.23 um 23:07 schrieb The Natural Philosopher:
Oh? You think that unsolicited information about Linux and rasberry Pis
is spam, in linux and raspberry Pi newsgroups?
What on earth do you think that spam acrually IS?
Postings from anonymous Trolls with fake identities.
On 8/11/23 22:33, Jörg Lorenz wrote:
Am 11.08.23 um 23:07 schrieb The Natural Philosopher:
Oh? You think that unsolicited information about Linux and rasberryPostings from anonymous Trolls with fake identities.
Pis is spam, in linux and raspberry Pi newsgroups? What on earth do
you think that spam acrually IS?
When is an identity real, and when is it fake?
Surely it is only fake if it is pretending to be someone, or
something, it is not.
On 8/11/23 22:33, Jörg Lorenz wrote:
Am 11.08.23 um 23:07 schrieb The Natural Philosopher:When is an identity real, and when is it fake?
Oh? You think that unsolicited information about Linux and rasberry Pis
is spam, in linux and raspberry Pi newsgroups?
What on earth do you think that spam acrually IS?
Postings from anonymous Trolls with fake identities.
Surely it is only fake if it is pretending to be someone, or something,
it is not.
Pancho <Pancho.Jones@Proton.Me> writes:
On 8/11/23 22:33, Jörg Lorenz wrote:
Am 11.08.23 um 23:07 schrieb The Natural Philosopher:
Oh? You think that unsolicited information about Linux and rasberryPostings from anonymous Trolls with fake identities.
Pis is spam, in linux and raspberry Pi newsgroups? What on earth do
you think that spam acrually IS?
When is an identity real, and when is it fake?
Surely it is only fake if it is pretending to be someone, or
something, it is not.
TNP’s been consistently posting under the same identity since, hmm, the 1990s I think? I think I’d call it a nom de plume.
At any rate, chatter about the longevity characteristics of storage
devices seems on topic here to me.
Pancho <Pancho.Jones@Proton.Me> writes:
On 8/11/23 22:33, Jörg Lorenz wrote:
Am 11.08.23 um 23:07 schrieb The Natural Philosopher:
Oh? You think that unsolicited information about Linux and rasberryPostings from anonymous Trolls with fake identities.
Pis is spam, in linux and raspberry Pi newsgroups? What on earth do
you think that spam acrually IS?
When is an identity real, and when is it fake?
Surely it is only fake if it is pretending to be someone, or
something, it is not.
TNP’s been consistently posting under the same identity since, hmm, the 1990s I think? I think I’d call it a nom de plume.
At any rate, chatter about the longevity characteristics of storage
devices seems on topic here to me.
This is a general hardware question and not of any relevance to Linux in particular.
Am 12.08.23 um 09:43 schrieb Richard Kettlewell:
At any rate, chatter about the longevity characteristics of storage
devices seems on topic here to me.
This is a general hardware question and not of any relevance to Linux in particular.
On Sat, 12 Aug 2023 11:10:50 +0200
Jörg Lorenz <hugybear@gmx.ch> wrote:
This is a general hardware question and not of any relevance to Linux in
particular.
This group is about the Raspberry Pi range of SBCs almost all of
which use SD cards for primary storage and far from all of which run Linux.
On 12/08/2023 10:10, Jörg Lorenz wrote:
Am 12.08.23 um 09:43 schrieb Richard Kettlewell:
If you look at the headers, assuming you can read, you will see that its cross posted to comp.sys.raspberry-pi,At any rate, chatter about the longevity characteristics of storage
devices seems on topic here to me.
This is a general hardware question and not of any relevance to Linux in
particular.
Looking at previous postings, it seems about average "on topic" for comp.os.linux.misc, it is 100% on topic for comp.sys.raspberry-pi.
I'm interested.
If you want to criticise, there is loads of other shit that we discuss
that isn't on topic.
Am 12.08.23 um 12:41 schrieb Jörg Lorenz:
Am 12.08.23 um 12:26 schrieb Pancho:
Looking at previous postings, it seems about average "on topic" for
comp.os.linux.misc, it is 100% on topic for comp.sys.raspberry-pi.
I'm interested.
If you want to criticise, there is loads of other shit that we discuss
that isn't on topic.
Discussions with fake identities are futile.
The Natural Philosopher <tnp@invalid.invalid>
Before and after Covid I have no intention to talk to masked and
anonymous people.
Am 12.08.23 um 12:26 schrieb Pancho:
Looking at previous postings, it seems about average "on topic" for
comp.os.linux.misc, it is 100% on topic for comp.sys.raspberry-pi.
I'm interested.
If you want to criticise, there is loads of other shit that we discuss
that isn't on topic.
Discussions with fake identities are futile.
The Natural Philosopher <tnp@invalid.invalid>
Am 12.08.23 um 11:55 schrieb The Natural Philosopher:
On 12/08/2023 10:10, Jörg Lorenz wrote:
Am 12.08.23 um 09:43 schrieb Richard Kettlewell:If you look at the headers, assuming you can read, you will see that its
At any rate, chatter about the longevity characteristics of storage
devices seems on topic here to me.
This is a general hardware question and not of any relevance to Linux in >>> particular.
cross posted to comp.sys.raspberry-pi,
comp.os.linux.misc
Stop this X-posting! Get it?
Am 12.08.23 um 12:41 schrieb Jörg Lorenz:
Am 12.08.23 um 12:26 schrieb Pancho:
Looking at previous postings, it seems about average "on topic" for
comp.os.linux.misc, it is 100% on topic for comp.sys.raspberry-pi.
I'm interested.
If you want to criticise, there is loads of other shit that we discuss
that isn't on topic.
Discussions with fake identities are futile.
The Natural Philosopher <tnp@invalid.invalid>
Before and after Covid I have no intention to talk to masked and
anonymous people.
Am 12.08.23 um 11:55 schrieb The Natural Philosopher:
On 12/08/2023 10:10, Jörg Lorenz wrote:
Am 12.08.23 um 09:43 schrieb Richard Kettlewell:If you look at the headers, assuming you can read, you will see that its
At any rate, chatter about the longevity characteristics of storage
devices seems on topic here to me.
This is a general hardware question and not of any relevance to Linux in >>> particular.
cross posted to comp.sys.raspberry-pi,
comp.os.linux.misc
Stop this X-posting! Get it?
On 12/08/2023 11:46, Jörg Lorenz wrote:
Am 12.08.23 um 12:41 schrieb Jörg Lorenz:
Am 12.08.23 um 12:26 schrieb Pancho:
Looking at previous postings, it seems about average "on topic" for
comp.os.linux.misc, it is 100% on topic for comp.sys.raspberry-pi.
I'm interested.
If you want to criticise, there is loads of other shit that we discuss >>>> that isn't on topic.
Discussions with fake identities are futile.
The Natural Philosopher <tnp@invalid.invalid>
Before and after Covid I have no intention to talk to masked and
anonymous people.
Why are you talking to me?
On 12/08/2023 11:46, Jörg Lorenz wrote:
Am 12.08.23 um 12:41 schrieb Jörg Lorenz:
Am 12.08.23 um 12:26 schrieb Pancho:
Looking at previous postings, it seems about average "on topic" for
comp.os.linux.misc, it is 100% on topic for comp.sys.raspberry-pi.
I'm interested.
If you want to criticise, there is loads of other shit that we discuss >>>> that isn't on topic.
Discussions with fake identities are futile.
The Natural Philosopher <tnp@invalid.invalid>
Before and after Covid I have no intention to talk to masked and
anonymous people.
Well why don't you STFU then?
You have no way of knowing who here is using their real name, or even if
they have a real name. Many people have more than one name they commonly
use.
As for publishing a real email address, you must be bonkers. I have
enough spam as it is.
On 12/08/2023 10:10, Jörg Lorenz wrote:
Am 12.08.23 um 09:43 schrieb Richard Kettlewell:
If you look at the headers, assuming you can read, you will see that its cross posted to comp.sys.raspberry-pi, and since all PIs other than theAt any rate, chatter about the longevity characteristics of storage
devices seems on topic here to me.
This is a general hardware question and not of any relevance to Linux in
particular.
Pico run off primarily an SD card, and primarily run Linux, it is of
extreme relevance to them.
It also touches on aspects of the Linux operating system - its logging,
and its file system behaviour, and its file cacheing, that are of considerable interest to people who may not appreciate how deeply these affect its performance.
Of course if you simply want to gaze at a glass terminal and pretend you
are back in the days of a PDP11, it's of no interest to you at all.
But don't judge everyone else by your own standards
Am 12.08.23 um 12:48 schrieb Pancho:
On 12/08/2023 11:46, Jörg Lorenz wrote:
Am 12.08.23 um 12:41 schrieb Jörg Lorenz:
Am 12.08.23 um 12:26 schrieb Pancho:
Looking at previous postings, it seems about average "on topic" for
comp.os.linux.misc, it is 100% on topic for comp.sys.raspberry-pi.
I'm interested.
If you want to criticise, there is loads of other shit that we discuss >>>>> that isn't on topic.
Discussions with fake identities are futile.
The Natural Philosopher <tnp@invalid.invalid>
Before and after Covid I have no intention to talk to masked and
anonymous people.
Why are you talking to me?
Try to find out yourself.
On 11/08/2023 22:33, Jörg Lorenz wrote:
Am 11.08.23 um 23:07 schrieb The Natural Philosopher:No-one could possibly be called Jörg Lorenz.
Oh? You think that unsolicited information about Linux and
rasberry Pis is spam, in linux and raspberry Pi newsgroups? What
on earth do you think that spam acrually IS?
Postings from anonymous Trolls with fake identities.
Trying to police a newsgroup that is not moderated will not work.
If you don't like the discussion filter it out of your feed, either by poster, or by thread. Complaining will not stop it and just adds to the noise, or gets your articles filtered out by others.
That's how usenet works.
What I observe since I participate in the usenet Anglosaxons often weigh
free speech higher than a minimum standard of decency and politeness
that helps to increase their credibility.
In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
On 11/08/2023 22:33, Jörg Lorenz wrote:
Am 11.08.23 um 23:07 schrieb The Natural Philosopher:No-one could possibly be called Jörg Lorenz.
Oh? You think that unsolicited information about Linux and
rasberry Pis is spam, in linux and raspberry Pi newsgroups? What
on earth do you think that spam acrually IS?
Postings from anonymous Trolls with fake identities.
Jörg earned a permanent position in my kill file by being a complete arsehole. This entire meta discussion indicates that the mentally
disturbed individual behind the nym remains just as much an arsehole
now as then.
Best to just killfile it and more along.
In any case, SDs are "smart" devices, they have a
controller to manage various needs. They are not
just "stupid" memory space even though they try
to *appear* as such to the user.
A few of my applications involve like a DECADE
of reliability. As such the hidden tricks of SDs
becomes relevant (as do memory leaks).
At the point where you _need_ something to work for a decade, it's
probably worth looking at industrial SD cards rather than
off-the-shelf ones. These are commonly characterised by using SLC
flash, which trades storage capacity for more write cycles.
NAND flash types: https://www.kingston.com/en/blog/pc-performance/difference-between-slc-mlc-tlc-3d-nand
The datasheet for this SLC SD card describes the controller's
reliability features (including wear levelling): https://docs.rs-online.com/29d1/0900766b815d5fe1.pdf
(pages 11 & 12)
Here's sales info from another industrial SD card manufacturer, who
elsewhere also advertise SD cards with an "advanced wear levelling algorithm": https://www.atpinc.com/blog/industrial-sd-cards-factors-requirements-to-consider
I'm not sure whether the industrial SD card controllers really do
much more for increasing longevity in a read-only application
though.
Doing the research reveals the true case about wear on flash memory
style devices and that is that substantially reads do *not* damage the
cells at all, at least no more than reading, say, DRAM. It is block
erases and writes that do a
In comp.os.linux.misc 23k.304 <23k304@bfxw9.net> wrote:
In any case, SDs are "smart" devices, they have a
controller to manage various needs. They are not
just "stupid" memory space even though they try
to *appear* as such to the user.
A few of my applications involve like a DECADE
of reliability. As such the hidden tricks of SDs
becomes relevant (as do memory leaks).
At the point where you _need_ something to work for a decade, it's
probably worth looking at industrial SD cards rather than
off-the-shelf ones. These are commonly characterised by using SLC
flash, which trades storage capacity for more write cycles.
NAND flash types: https://www.kingston.com/en/blog/pc-performance/difference-between-slc-mlc-tlc-3d-nand
The datasheet for this SLC SD card describes the controller's
reliability features (including wear levelling): https://docs.rs-online.com/29d1/0900766b815d5fe1.pdf
(pages 11 & 12)
Here's sales info from another industrial SD card manufacturer, who
elsewhere also advertise SD cards with an "advanced wear levelling algorithm": https://www.atpinc.com/blog/industrial-sd-cards-factors-requirements-to-consider
I'm not sure whether the industrial SD card controllers really do
much more for increasing longevity in a read-only application
though.
On 13/08/2023 01:40, Computer Nerd Kev wrote:
At the point where you _need_ something to work for a decade, it's
probably worth looking at industrial SD cards rather than
off-the-shelf ones. These are commonly characterised by using SLC
flash, which trades storage capacity for more write cycles.
NAND flash types:
https://www.kingston.com/en/blog/pc-performance/difference-between-slc-mlc-tlc-3d-nand
The datasheet for this SLC SD card describes the controller's
reliability features (including wear levelling):
https://docs.rs-online.com/29d1/0900766b815d5fe1.pdf
(pages 11 & 12)
Here's sales info from another industrial SD card manufacturer, who
elsewhere also advertise SD cards with an "advanced wear levelling
algorithm":
https://www.atpinc.com/blog/industrial-sd-cards-factors-requirements-to-consider
I'm not sure whether the industrial SD card controllers really do
much more for increasing longevity in a read-only application
though.
Indeed. It does seem that with the price of computing power falling so massively, there is little reason *not* to add wear levelling to SD
cards. Which ultimately renders them as reliable as any other NAND based flash device.
My interest is, as always, to understand just enough to get the job
done, which in this case means I want about 10-15 years of reliable
operation on a 24x7 basis.
Having noted that in normal operation as far as I have built it, the
unit is not accessing its SD card AT ALL apart from a daily write to
some logs, I think that there I will stop.
There happens to be a sufficiency of RAM to regard the SD card
essentially as EAROM.
That will do nicely.
Am 12.08.23 um 11:55 schrieb The Natural Philosopher:
On 12/08/2023 10:10, Jörg Lorenz wrote:
Am 12.08.23 um 09:43 schrieb Richard Kettlewell:If you look at the headers, assuming you can read, you will see that its
At any rate, chatter about the longevity characteristics of storage
devices seems on topic here to me.
This is a general hardware question and not of any relevance to Linux in >>> particular.
cross posted to comp.sys.raspberry-pi,
comp.os.linux.misc
Stop this X-posting! Get it?
Am 12.08.23 um 12:26 schrieb Pancho:
Looking at previous postings, it seems about average "on topic" for
comp.os.linux.misc, it is 100% on topic for comp.sys.raspberry-pi.
I'm interested.
If you want to criticise, there is loads of other shit that we discuss
that isn't on topic.
Discussions with fake identities are futile.
The Natural Philosopher <tnp@invalid.invalid>
| Sysop: | Coz |
|---|---|
| Location: | Anoka, MN |
| Users: | 2 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 140:08:51 |
| Calls: | 166 |
| Files: | 5,389 |
| Messages: | 223,236 |