• A bit more on SD and SSD...wear characteristics.

    From The Natural Philosopher@3:770/3 to All on Fri Aug 11 10:54:30 2023
    XPost: comp.os.linux.misc

    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.



    --
    "If you don’t read the news paper, you are un-informed. If you read the
    news paper, you are mis-informed."

    Mark Twain

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?J=c3=b6rg_Lorenz?=@3:770/3 to All on Fri Aug 11 14:24:44 2023
    XPost: comp.os.linux.misc

    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?

    --
    Manus manum lavat

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Fri Aug 11 16:21:10 2023
    XPost: comp.os.linux.misc

    On 11/08/2023 13:24, Jörg Lorenz wrote:
    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?

    My question is "Why did you think that a post has to be a 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.


    --
    There’s a mighty big difference between good, sound reasons and reasons
    that sound good.

    Burton Hillis (William Vaughn, American columnist)

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?J=c3=b6rg_Lorenz?=@3:770/3 to All on Fri Aug 11 17:48:38 2023
    XPost: comp.os.linux.misc

    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:
    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?

    My question is "Why did you think that a post has to be a 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.

    --
    Alea iacta est

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Rich@3:770/3 to The Natural Philosopher on Fri Aug 11 18:13:12 2023
    XPost: comp.os.linux.misc

    In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
    On 11/08/2023 13:24, Jörg Lorenz wrote:
    Am 11.08.23 um 11:54 schrieb The Natural Philosopher:
    [snip long research summary]

    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?

    My question is "Why did you think that a post has to be a question?"

    Well, you were responded to by Jörg -- it has a mental defect where it
    can't help but be a prime asshole. That mental defect earned it a
    permanant position in my killfile. I only saw it's response because of
    your response.

    This is information for Pi people using SD cards. Condensing a mornings research into some general practical conclusions.

    And condensing a few hundred scattered individual articles in the two
    groups into a single place for future reference. It was a useful
    summary post, even if Jörg had an issue.

    If you are not interested in it, just skip it.

    Indeed, some can't seem to 'get' that simple bit of logic into their
    thick heads.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Carlos E.R.@3:770/3 to All on Fri Aug 11 20:11:42 2023
    XPost: comp.os.linux.misc

    On 2023-08-11 17:48, Jörg Lorenz wrote:
    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:
    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?

    My question is "Why did you think that a post has to be a question?"

    Because the posting otherwise is unsoliceted spam?

    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.


    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.


    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Fri Aug 11 22:07:34 2023
    XPost: comp.os.linux.misc

    On 11/08/2023 16:48, Jörg Lorenz wrote:
    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:
    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?

    My question is "Why did you think that a post has to be a question?"

    Because the posting otherwise is unsoliceted spam?

    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?

    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.

    Well, next time why not shut the fuck up when you are not.

    You don't get to decide policy.

    All you have is a keyboard and a killfile. It's very democratic. You can
    only create your own safe space, you cant dictate it for anyone else


    --
    A lie can travel halfway around the world while the truth is putting on
    its shoes.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?J=c3=b6rg_Lorenz?=@3:770/3 to All on Fri Aug 11 23:33:40 2023
    XPost: comp.os.linux.misc

    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.

    --
    Alea iacta est

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to All on Fri Aug 11 23:03:06 2023
    XPost: comp.os.linux.misc

    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 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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andreas Kohlbach@3:770/3 to Carlos E.R. on Fri Aug 11 20:10:30 2023
    XPost: comp.os.linux.misc

    On Fri, 11 Aug 2023 20:11:43 +0200, Carlos E.R. wrote:

    On 2023-08-11 17:48, Jörg Lorenz wrote:
    Am 11.08.23 um 17:21 schrieb The Natural Philosopher:

    You all forgot how to trim postings? :-/

    What exactly is your question?

    My question is "Why did you think that a post has to be a question?"
    Because the posting otherwise is unsoliceted spam?

    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.

    Part was.

    | [...] PS. Could someone please try to finger me from overseas, as I've
    | installed a "changing .plan" (made by your's truly), and I'm not certain
    | it works from outside? It should report a new .plan every time.

    <https://www.cs.cmu.edu/~awb/linux.history.html>

    But I agree, announcements may be okay, if they are on topic.

    F'up2 colm.
    --
    Andreas

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 23k.304@3:770/3 to The Natural Philosopher on Sat Aug 12 01:22:44 2023
    XPost: comp.os.linux.misc

    On 8/11/23 5:54 AM, The Natural Philosopher wrote:
    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.


    This is substantially correct. Reading from an SD/SSD *can*
    result in re-writes, thus shortening the life of the medium.
    How MUCH/OFTEN ... well, it depends.

    The BEST IDEA is to shift EVERY relevant file that
    might possibly try to be read/writ to/from an SD off
    into RAM as quickly as possible. Depending on your
    distro you might be able to shift the entire OS to
    RAM. Some "live" distros are kinda like this already.
    A Pi with 4+ gb of RAM may be adequate enough for
    this approach.

    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).


    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.




    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Sat Aug 12 09:09:54 2023
    XPost: comp.os.linux.misc

    On 11/08/2023 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 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.

    No-one could possibly be called Jörg Lorenz.


    --
    To ban Christmas, simply give turkeys the vote.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Kettlewell@3:770/3 to Pancho on Sat Aug 12 08:43:16 2023
    XPost: comp.os.linux.misc

    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 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.

    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.

    --
    https://www.greenend.org.uk/rjk/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Pancho on Sat Aug 12 09:14:28 2023
    XPost: comp.os.linux.misc

    On 11/08/2023 23:03, Pancho wrote:
    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 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.

    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.

    I have been using nyms since before the usenet was in the internet. Why? Because I realised back in the 1980s that employers can peer into your
    private discussions, and I didn't like it. I lost a job through not
    being religious enough once.
    What I have to say is what I have to say, regardless of whether it can
    be connected to who I am as far as the electoral register, the bank and
    the taxman are concerned.
    There are some deeply weird and disturbed people on the internet as well
    as elsewhere. I don't want my house set on fire or my tyres slashed any
    more than already.
    If you don't like it, just kill file me and STFU.


    --
    To ban Christmas, simply give turkeys the vote.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Richard Kettlewell on Sat Aug 12 09:19:50 2023
    XPost: comp.os.linux.misc

    On 12/08/2023 08:43, Richard Kettlewell wrote:
    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 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.

    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.

    It was earlier than that actually Richard. Before we met. It was pretty
    much my 'social media' identity from the word go.

    Curiously my experiences with Usenet absolutely put me off any
    involvement with twitter or facebook.


    At any rate, chatter about the longevity characteristics of storage
    devices seems on topic here to me.

    I think so, It was something I didn't know the full answer to, and
    judging by the responses, the same was true of others. Everyone had a
    bit of the picture, but the whole practical issue with respect to using
    PIs was not available. I tried to summarise what everyone had
    contributed into the salient issues.

    --
    "Women actually are capable of being far more than the feminists will
    let them."

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?J=c3=b6rg_Lorenz?=@3:770/3 to All on Sat Aug 12 11:10:50 2023
    XPost: comp.os.linux.misc

    Am 12.08.23 um 09:43 schrieb Richard Kettlewell:
    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 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.

    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.

    --
    Alea iacta est

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to hugybear@gmx.ch on Sat Aug 12 10:48:26 2023
    XPost: comp.os.linux.misc

    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.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    Host: Beautiful Theory meet Inconvenient Fact
    Obit: Beautiful Theory died today of factual inconsistency

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Sat Aug 12 10:55:10 2023
    XPost: comp.os.linux.misc

    On 12/08/2023 10:10, Jörg Lorenz wrote:
    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.

    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 the
    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

    --
    Labour - a bunch of rich people convincing poor people to vote for rich
    people by telling poor people that "other" rich people are the reason
    they are poor.

    Peter Thompson

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?J=c3=b6rg_Lorenz?=@3:770/3 to All on Sat Aug 12 12:09:22 2023
    XPost: comp.os.linux.misc

    Am 12.08.23 um 11:48 schrieb Ahem A Rivet's Shot:
    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.

    comp.os.linux.misc

    Stop this X-posting! Get it?

    --
    Alea iacta est

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?J=c3=b6rg_Lorenz?=@3:770/3 to All on Sat Aug 12 12:11:10 2023
    XPost: comp.os.linux.misc

    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:

    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.

    If you look at the headers, assuming you can read, you will see that its cross posted to comp.sys.raspberry-pi,

    comp.os.linux.misc

    Stop this X-posting! Get it?


    --
    Alea iacta est

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?J=c3=b6rg_Lorenz?=@3:770/3 to All on Sat Aug 12 12:41:30 2023
    XPost: comp.os.linux.misc

    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>

    --
    Alea iacta est

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to All on Sat Aug 12 11:48:24 2023
    XPost: comp.os.linux.misc

    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?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?J=c3=b6rg_Lorenz?=@3:770/3 to All on Sat Aug 12 12:46:36 2023
    XPost: comp.os.linux.misc

    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.

    --
    Alea iacta est

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to All on Sat Aug 12 11:26:12 2023
    XPost: comp.os.linux.misc

    On 12/08/2023 11:11, Jörg Lorenz wrote:
    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:

    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.

    If you look at the headers, assuming you can read, you will see that its
    cross posted to comp.sys.raspberry-pi,

    comp.os.linux.misc

    Stop this X-posting! Get it?



    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Sat Aug 12 12:01:36 2023
    XPost: comp.os.linux.misc

    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.

    --
    There is nothing a fleet of dispatchable nuclear power plants cannot do
    that cannot be done worse and more expensively and with higher carbon
    emissions and more adverse environmental impact by adding intermittent renewable energy.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From David W. Hodgins@3:770/3 to hugybear@gmx.ch on Sat Aug 12 07:23:36 2023
    XPost: comp.os.linux.misc

    On Sat, 12 Aug 2023 06:11:10 -0400, Jörg Lorenz <hugybear@gmx.ch> wrote:

    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:

    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.

    If you look at the headers, assuming you can read, you will see that its
    cross posted to comp.sys.raspberry-pi,

    comp.os.linux.misc

    Stop this X-posting! Get it?

    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.

    Regards, Dave Hodgins

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?J=c3=b6rg_Lorenz?=@3:770/3 to All on Sat Aug 12 13:22:56 2023
    XPost: comp.os.linux.misc

    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.

    --
    Alea iacta est

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Schram@3:770/3 to The Natural Philosopher on Sat Aug 12 11:34:40 2023
    XPost: comp.os.linux.misc

    On 2023-08-12, The Natural Philosopher <tnp@invalid.invalid> wrote:
    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.

    Just to add a data point to this more and more ridiculous off-topic meta discussion, for Usenet purpose only, email address in my From: header,
    as well as in my .signature, is quite real and working. I cannot
    remember the last time, if ever at all, I received spam email at that
    address. Lucky? Maybe.

    --
    chrispam1@me.com is a filtered spam magnet. Email replies may be lost.
    You're better off replying to this newsgroup.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Carlos E.R.@3:770/3 to The Natural Philosopher on Sat Aug 12 14:59:48 2023
    XPost: comp.os.linux.misc

    On 2023-08-12 11:55, The Natural Philosopher wrote:
    On 12/08/2023 10:10, Jörg Lorenz wrote:
    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.

    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 the
    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.

    Absolutely.


    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


    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Sat Aug 12 14:49:40 2023
    XPost: comp.os.linux.misc

    On 12/08/2023 12:22, Jörg Lorenz wrote:
    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.

    I don't feel it would be worth ones while.
    --
    It is the folly of too many to mistake the echo of a London coffee-house
    for the voice of the kingdom.

    Jonathan Swift

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Rich@3:770/3 to The Natural Philosopher on Sat Aug 12 15:08:52 2023
    XPost: comp.os.linux.misc

    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:
    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.

    No-one could possibly be called Jörg Lorenz.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From =?UTF-8?Q?J=c3=b6rg_Lorenz?=@3:770/3 to All on Sat Aug 12 16:29:08 2023
    XPost: comp.os.linux.misc

    Am 12.08.23 um 13:23 schrieb David W. Hodgins:
    Trying to police a newsgroup that is not moderated will not work.

    Sure. I made my point clear in the first answer to the OP.
    But so many users thought they had to add something meaningful.

    Case is closed for me now and the OP is (again) in my killfile. I will
    always react to anonymous and impolite wisenheimers the way they deserve
    in my opinion.

    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.

    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.

    That's how usenet works.

    Believe me, after 22 years in the global usenet I know how it works. Unmoderated Usenet is much more beneficial to all of us if the regulars
    are very disciplined.

    --
    Alea iacta est

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Sat Aug 12 16:45:14 2023
    XPost: comp.os.linux.misc

    On 12/08/2023 15:29, Jörg Lorenz wrote:
    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.

    What a pompous prick.

    --
    "A point of view can be a dangerous luxury when substituted for insight
    and understanding".

    Marshall McLuhan

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Rich on Sat Aug 12 16:46:04 2023
    XPost: comp.os.linux.misc

    On 12/08/2023 16:08, Rich wrote:
    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:
    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.

    No-one could possibly be called Jörg Lorenz.

    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.

    One investigates to see if there is any sanity behind the mask. Then
    moves on. There is none.

    --
    "A point of view can be a dangerous luxury when substituted for insight
    and understanding".

    Marshall McLuhan

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From MarioCCCP@3:770/3 to All on Sun Aug 13 02:33:18 2023
    XPost: comp.os.linux.misc

    T24gMTIvMDgvMjMgMTE6MTAsIErDtnJnIExvcmVueiB3cm90ZToNCj4gQW0gMTIuMDguMjMg dW0gMDk6NDMgc2NocmllYiBSaWNoYXJkIEtldHRsZXdlbGw6DQo+PiBQYW5jaG8gPFBhbmNo by5Kb25lc0BQcm90b24uTWU+IHdyaXRlczoNCj4+PiBPbiA4LzExLzIzIDIyOjMzLCBKw7Zy ZyBMb3Jlbnogd3JvdGU6DQo+Pj4+IEFtIDExLjA4LjIzIHVtIDIzOjA3IHNjaHJpZWIgVGhl IE5hdHVyYWwgUGhpbG9zb3BoZXI6DQo+Pj4+PiBPaD8gWW91IHRoaW5rIHRoYXQgdW5zb2xp Y2l0ZWQgaW5mb3JtYXRpb24gYWJvdXQgTGludXggYW5kIHJhc2JlcnJ5DQo+Pj4+PiBQaXMg aXMgc3BhbSwgaW4gbGludXggYW5kIHJhc3BiZXJyeSBQaSBuZXdzZ3JvdXBzPyAgV2hhdCBv biBlYXJ0aCBkbw0KPj4+Pj4geW91IHRoaW5rIHRoYXQgc3BhbSBhY3J1YWxseSBJUz8NCj4+ Pj4gUG9zdGluZ3MgZnJvbSBhbm9ueW1vdXMgVHJvbGxzIHdpdGggZmFrZSBpZGVudGl0aWVz Lg0KPj4+DQo+Pj4gV2hlbiBpcyBhbiBpZGVudGl0eSByZWFsLCBhbmQgd2hlbiBpcyBpdCBm YWtlPw0KPj4+DQo+Pj4gU3VyZWx5IGl0IGlzIG9ubHkgZmFrZSBpZiBpdCBpcyBwcmV0ZW5k aW5nIHRvIGJlIHNvbWVvbmUsIG9yDQo+Pj4gc29tZXRoaW5nLCBpdCBpcyBub3QuDQo+Pg0K Pj4gVE5Q4oCZcyBiZWVuIGNvbnNpc3RlbnRseSBwb3N0aW5nIHVuZGVyIHRoZSBzYW1lIGlk ZW50aXR5IHNpbmNlLCBobW0sIHRoZQ0KPj4gMTk5MHMgSSB0aGluaz8gSSB0aGluayBJ4oCZ ZCBjYWxsIGl0IGEgbm9tIGRlIHBsdW1lLg0KPj4NCj4+IEF0IGFueSByYXRlLCBjaGF0dGVy IGFib3V0IHRoZSBsb25nZXZpdHkgY2hhcmFjdGVyaXN0aWNzIG9mIHN0b3JhZ2UNCj4+IGRl dmljZXMgc2VlbXMgb24gdG9waWMgaGVyZSB0byBtZS4NCj4gDQo+IFRoaXMgaXMgYSBnZW5l cmFsIGhhcmR3YXJlIHF1ZXN0aW9uIGFuZCBub3Qgb2YgYW55IHJlbGV2YW5jZSB0byBMaW51 eCBpbg0KPiBwYXJ0aWN1bGFyLg0KDQpJIGNvbXBsZXRlbHkgZGlzYWdyZWUsIHNpbmNlIGhl LCBhZnRlciBhIHRlY2huaWNhbCANCmRpc2N1c3Npb24gKHRvIHByb3ZlIHRoZSBjb25jbHVz aW9ucyksIHdlbnQgb24gdG8gZ2l2ZSANCnVzZWZ1bCBhZHZpY2VzIHNwZWNpZmljIHRvIExp bnV4LCBpLmcuIHRoZSBvbmUgYWJvdXQgDQoibm9hdGltZSIgbW91bnQgb3B0aW9uLCBhbmQg dGhlIHN0dWZmIGFib3V0IGxvZ2dpbmcgb24gYSByYW0gDQpkaXNrLg0KWW91IHNlZW0gdG8g YmUgcG9sZW1pc2luZyBmb3IgbWlzdGVyaW91cyByZWFzb25zDQoNCg0KPiANCg0KLS0gDQox KSBSZXNpc3RlcmUsIHJlc2lzdGVyZSwgcmVzaXN0ZXJlLg0KMikgU2UgdHV0dGkgcGFnYW5v IGxlIHRhc3NlLCBsZSB0YXNzZSBsZSBwYWdhbm8gdHV0dGkNCk1hcmlvQ0NDUA0KDQo=

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to 23k304@bfxw9.net on Sun Aug 13 10:40:20 2023
    XPost: comp.os.linux.misc

    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.

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Computer Nerd Kev on Sun Aug 13 08:33:46 2023
    XPost: comp.os.linux.misc

    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.

    --
    Climate Change: Socialism wearing a lab coat.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to The Natural Philosopher on Mon Aug 14 08:15:44 2023
    XPost: comp.os.linux.misc

    The Natural Philosopher wrote:

    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

    Hence the primary metric for SSD longevity is TBW (terabytes written).

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 24k.305@3:770/3 to Computer Nerd Kev on Tue Aug 15 00:58:52 2023
    XPost: comp.os.linux.misc

    On 8/12/23 8:40 PM, Computer Nerd Kev wrote:
    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.


    Those are pretty good. However within a certain range
    I still rec FRAM. It's REALLY good and you can get I2C
    or SPI interface. Capacity, alas, is a bit limited. But,
    if your app requires keeping track of peak figures,
    current state and such ... things that ARE going to change
    a fair bit but MUST be remembered between reboots .......
    if you want a decade you don't use SD or on-chip flash.


    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.

    Well, as mentioned, there may be "sneak" writes of
    various kinds. Those who make distros for PIs and
    such TRY to shift everything off into RAM but they
    can MISS stuff, or discount "lesser" stresses on
    SD. The focus of such distros is still aimed more
    at "hobbyists" than "industrial" and they make
    judgements accordingly.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From 24k.305@3:770/3 to The Natural Philosopher on Tue Aug 15 01:22:48 2023
    XPost: comp.os.linux.misc

    On 8/13/23 3:33 AM, The Natural Philosopher wrote:
    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.


    I wrote a multi-channel environmental monitor for "field"
    use a few years ago. It took 12 samples per hour. Does not
    sound like much, but it adds up. The device also HAD to
    store a lot of high/low and random params which could
    change every sample.

    For that I chose I2C FRAM. No wait states, effectively
    unlimited re-writes. Better than SD or on-chip EEPROM.

    This is NOT a solution for jamming an entire OS into
    unless it's DOS 2.x but you (and hopefully the distro
    writers) do your best to shift all the OS stuff into
    RAM and kinda hope for the best. The params in the FRAM
    take care of reboots, save "the state".

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From scott@alfter.diespammersdie.us@3:770/3 to hugybear@gmx.ch on Wed Aug 16 16:31:26 2023
    XPost: comp.os.linux.misc

    In comp.sys.raspberry-pi Jörg Lorenz <hugybear@gmx.ch> wrote:
    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:

    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.

    If you look at the headers, assuming you can read, you will see that its
    cross posted to comp.sys.raspberry-pi,

    comp.os.linux.misc

    Stop this X-posting! Get it?

    The horse is dead. Quit beating it. If you find a topic annoying, killfile it. (You do know how to use your newsreader's killfile facility, right?)

    FWIW, I find you more annoying than this topic, so...

    ** PLONK ***

    --
    _/_
    / v \ Scott Alfter (remove the obvious to send mail)
    (IIGS( https://alfter.us/ Top-posting!
    \_^_/ >What's the most annoying thing on Usenet?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim H@3:770/3 to Lorenz on Fri Aug 25 18:02:40 2023
    On Sat, 12 Aug 2023 12:41:31 +0200, in <ub7nkr$bgb$1@solani.org>, Jörg
    Lorenz <hugybear@gmx.ch> wrote:

    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>

    After many years I've discovered that those complaining about a non de
    plume vs a real name, and esp a working email address, are only trolls
    looking for info to allow harassing the poster via other means.
    --
    Jim H

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)