Hardware bit loss on a file copy

[James Harris]

Well, here's a strange one. After I copied a file from one drive to
another I compared them and found them to be different! :-(

If your first thought is that I must have done something wrong you are
not alone. That's what I thought. But as far as I can tell it has turned
out to be a genuine error in either the hardware or in system software.

The reason for posting is partly that you might find this interesting
and partly because if it was a hardware error I wonder if there's
anything an operating system can do to detect or prevent such errors.

Here are the details.

---

The original file was very large, a 500GB disk image. The error happened
in a copy job I left to run overnight along the lines of (on Unix)

at 2am
cp -i /mnt/backups0/disk.img /mnt/backups1/work.img

Only one bit changed. A byte about 1.3% into the file was originally
0x70 but in the copy it became 0x71.

After the copy both diff and cmp reported a mismatch.

To see what the mismatch looked like in context I wrote a short C
program to extract a part of the file using fseek. (I found 'cut' to be
unsuitable as it read the file from the beginning until it got to the
requested offset; fseek was a better approach.)

I am confident that that was the only mismatch because after I used a
program called hexedit to correct the copy both diff and cmp found no
mismatch.

---

That's the situation. What do you think?

The only places I can think of where the bit could have been changed
from 0 to 1 are the following four.

* Between source drive and host system.
* In the host system's CPU or RAM. (It's plain RAM, not ECC.)
* Between host system and target drive.
* Within the host drive when it transferred its RAM to the disk surface.

Any others?

Given the above, if you are interested where do you think such an error
could have occurred and what could an OS do about it?

[Rod Pemberton]

On Sat, 13 Feb 2021 10:52:01 +0000

Post by James Harris
Well, here's a strange one. After I copied a file from one drive to
another I compared them and found them to be different! :-(

Ok.

(Somehow, it seems that I always get to your posts first, almost like
I'm "jumping" on them or at them. I hope that's not stopping others
from responding.)

Post by James Harris
If your first thought is that I must have done something wrong you
are not alone. That's what I thought.

No, that wasn't my first thought. My first thought was that this was a
Windows machine, and you were writing a file system image to a
disk/media. Windows is known to update some data structures on disk.
I.e., a copy of the file system on the newly written disk/media into
another file/image will produce a second image that is different from
the first, because Windows modified what was on the disk/media.

My second thought was the problems I had with booting DOS from a USB
stick, where the file system was corrupt. I'm still not sure if this
was an issue with BIOS boot emulation of USB images or some limitation
in DOS disk reads etc, and don't recall my prior conclusions ATM.

My third thought was of the track zero errors of floppy disks.

My fourth thought was of my recent over-heating hard disk.

My fifth thought was of a CD-ROM with numerous read errors.

My sixth thought was of my attempts to boot a DOS hard-disk image from
USB, and data being corrupted only during BIOS emulation.

...

Post by James Harris
But as far as I can tell it has turned out to be a genuine error in
either the hardware or in system software.

Ok.

Post by James Harris
The reason for posting is partly that you might find this interesting
and partly because if it was a hardware error I wonder if there's
anything an operating system can do to detect or prevent such errors.

Read, write, re-read, compare, retry if bad or not if good ...

Post by James Harris
Here are the details.
---
The original file was very large, a 500GB disk image. The error
happened in a copy job I left to run overnight along the lines of (on
Unix)

Overnight? Could this be a clue? ...

For example, maybe the machine goes to sleep/hibernate/suspend mode
causing a memory glitch?

Or, a screen saver kicks in causing a memory glitch?

Or, a drive being written to had many sector write errors causing
corruption?

Or, a drive being read from had many sector read errors causing
corruption?

Or, since this was Linux(?), the OS dumped itself to the swap partition
causing a glitch?

Post by James Harris
The original file was very large, a 500GB disk image. The error
happened in a copy job I left to run overnight along the lines of (on
Unix)
at 2am
cp -i /mnt/backups0/disk.img /mnt/backups1/work.img
Only one bit changed. A byte about 1.3% into the file was originally
0x70 but in the copy it became 0x71.

You have /mnt in the directory path. Were these files/images unmounted
while being copied? If these files/images were actually mounted during
the copy, perhaps as loop-back file systems, it's possible OS wrote to
them because the file system in the image was active during the copy.
e.g., the OS may have updated directory info, or file size info, or
partition size correction, or a change to the boot flag, etc.

Post by James Harris
I am confident that that was the only mismatch because after I used a
program called hexedit to correct the copy both diff and cmp found no
mismatch.

See the man page for the 'xxd' command for Linux. I.e., you can use
'hexdump -C' or 'xxd' to produce a hex dump, 'vi' or 'emacs' to edit,
and 'xxd -r' to convert the hex dump back into a binary.

I'm not sure yet what command is available on Linux to cut binary files
into pieces.

I wrote two C programs for DOS to cut files into pieces and merge them
back together. I also wrote two C programs for DOS to hex dump and
un-hex dump. I've not ported these to Linux as Linux seems to have
commands for everything, so far ... which is rather boring.

Post by James Harris
The only places I can think of where the bit could have been changed
from 0 to 1 are the following four.
* Between source drive and host system.
* In the host system's CPU or RAM. (It's plain RAM, not ECC.)
* Between host system and target drive.
* Within the host drive when it transferred its RAM to the disk surface.
Any others?

My primary guesses would be, in order,

a) the written image was also mounted, so the file system on it was
active, and some file system info was updated by the OS,

b) memory glitch from bad memory, e.g., bad bit or stuck bit

c) error in the disk media, e.g., bad bit or bad sector, or
perhaps the disk was not formatted, e.g., format on write ...

d) processor sleep/hibernation, causing memory corruption

e) processor speed/power throttling or overheating, causing memory bus
errors

f) over-heating device e.g., failing hard disk

g) error-prone device e.g., cd-rom reads from bad disk


Also, see earlier comments above for others.

Because this was only a single bit, option a), which is similar to what
Windows does to floppy images written to floppy disks, is my primary
suspicion. In other words, I suspect the image was not just being
copied, but was also mounted as an active file system, during the
copy, and Linux(?) wrote to it to update some file system info.

Of course, this can rather easily be disproved if untrue, depending on
what data is located at that location. If there is no file system
related info there, then Linux wouldn't have written anything there.
Hence, some other issue.

Post by James Harris
Given the above, if you are interested where do you think such an
error could have occurred and what could an OS do about it?

a) (unmount or lock image files), read, write, flush/sync/clear disk
errors, re-read, compare data, retry if bad.

b) (unmount or lock image files), read, compute first check sum, write,
flush/sync/clear disk errors, re-read, compute second check sum,
compare check sums, retry if bad.

...

--

[Rod Pemberton]

On Sat, 13 Feb 2021 10:52:01 +0000

Post by James Harris
The original file was very large, a 500GB disk image. The error
happened in a copy job I left to run overnight along the lines of (on
Unix)
at 2am
cp -i /mnt/backups0/disk.img /mnt/backups1/work.img
Only one bit changed. A byte about 1.3% into the file was originally
0x70 but in the copy it became 0x71.
After the copy both diff and cmp reported a mismatch.

Did you use 'cmp' or 'diff' to first identify this issue? Or, did
check sum commands like 'md5sum' or 'sha256sum' to first identify the
issue? Are the check sum commands faster?

--

[James Harris]

Post by Rod Pemberton
On Sat, 13 Feb 2021 10:52:01 +0000

Post by James Harris
The original file was very large, a 500GB disk image. The error
happened in a copy job I left to run overnight along the lines of (on
Unix)
at 2am
cp -i /mnt/backups0/disk.img /mnt/backups1/work.img
Only one bit changed. A byte about 1.3% into the file was originally
0x70 but in the copy it became 0x71.
After the copy both diff and cmp reported a mismatch.

Did you use 'cmp' or 'diff' to first identify this issue?

Yes, diff, I think.

I had used ddrescue to create an image (the disk.img, above) of a
damaged 500GB hard drive. ddrescue did a great job and got back more
than 99.99% of it!

I decided to put a "BAD SECTOR"-type string in the image in place of the
sectors ddrescue could not get back. The idea would then be to use grep
to find files, if any, which had been corrupted. The procedure is set out at

https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Fill-mode

Rather than changing any of the precious 500GB disk.img I made a working
copy so that I could go back to the original in case something I did
messed it up. It was only when using diff to compare the copy with the
original, as a precaution, that I came across the mismatch which led to
this discussion.

Post by Rod Pemberton
Or, did
check sum commands like 'md5sum' or 'sha256sum' to first identify the
issue? Are the check sum commands faster?

FWIW, in tests on this machine:

* md5sum took 75% of a CPU and read a disk at 190Mbytes/s
* sha256sum maxed out a CPU and read at 100Mbytes/s

By contrast, cmp took about 37% of a CPU and read two disks at a time at
a little over 130Mbytes/s.

That said, the big io factor is that files nearer the outside of a disk
can be read quite a bit faster than those near the spindle. The same cmp
could drop down to something like 75Mbytes/s, IIRC, for files near the
spindle.

[wolfgang kern]

On 13.02.2021 11:52, James Harris wrote:
...

Post by James Harris
Only one bit changed. A byte about 1.3% into the file was originally
0x70 but in the copy it became 0x71.

...

Post by James Harris
That's the situation. What do you think?
The only places I can think of where the bit could have been changed
from 0 to 1 are the following four.
* Between source drive and host system.
* In the host system's CPU or RAM. (It's plain RAM, not ECC.)
* Between host system and target drive.
* Within the host drive when it transferred its RAM to the disk surface.
Any others?
Given the above, if you are interested where do you think such an error
could have occurred and what could an OS do about it?

I can confirm that such errors happen quite often from power glitches
with cheap or broken PSU.
it could also be a RAM problem, but then the machine would crash often.

lazy/bad interrupt handling (esp RTCL) may cause short BUS-locks.

the only solution for an OS is to split large junks and verify/retry.
__
wolfgang

[James Harris]

Post by wolfgang kern
...

Post by James Harris
Only one bit changed. A byte about 1.3% into the file was originally
0x70 but in the copy it became 0x71.

...

Post by James Harris
That's the situation. What do you think?
The only places I can think of where the bit could have been changed
from 0 to 1 are the following four.
* Between source drive and host system.
* In the host system's CPU or RAM. (It's plain RAM, not ECC.)
* Between host system and target drive.
* Within the host drive when it transferred its RAM to the disk surface.
Any others?
Given the above, if you are interested where do you think such an
error could have occurred and what could an OS do about it?

I can confirm that such errors happen quite often from power glitches
with cheap or broken PSU.
it could also be a RAM problem, but then the machine would crash often.

That's what I thought. In the event, as I set out in other replies
earlier today, it did turn out to be a RAM problem but the apparent
reason the machine didn't crash often was that the fault would only show
when certain values were written to that part of memory - or only if
certain values (possibly a sequence of just two) were written to that
part of memory. In the meantime it could have been corrupting my
backups. Nasty!

Post by wolfgang kern
lazy/bad interrupt handling (esp RTCL) may cause short BUS-locks.
the only solution for an OS is to split large junks and verify/retry.

IMO an OS should detect bad memory.

[Scott Lurndal]

Post by James Harris

Post by wolfgang kern
lazy/bad interrupt handling (esp RTCL) may cause short BUS-locks.
the only solution for an OS is to split large junks and verify/retry.

IMO an OS should detect bad memory.

Most consumer grade hardware doesn't have ECC protected memory.

The operating system can't detect bad memory without hardware that
detects that something has gone awry.

[James Harris]

Post by Scott Lurndal

Post by James Harris

Post by wolfgang kern
lazy/bad interrupt handling (esp RTCL) may cause short BUS-locks.
the only solution for an OS is to split large junks and verify/retry.

IMO an OS should detect bad memory.

Most consumer grade hardware doesn't have ECC protected memory.
The operating system can't detect bad memory without hardware that
detects that something has gone awry.

Are you sure...?

How do you think memtest programs work?!

[Scott Lurndal]

Post by James Harris

Post by Scott Lurndal

Post by James Harris

Post by wolfgang kern
lazy/bad interrupt handling (esp RTCL) may cause short BUS-locks.
the only solution for an OS is to split large junks and verify/retry.

IMO an OS should detect bad memory.

Most consumer grade hardware doesn't have ECC protected memory.
The operating system can't detect bad memory without hardware that
detects that something has gone awry.

Are you sure...?
How do you think memtest programs work?!

Somewhat effective standalone. Quite poorly as an attempt to provide
similar capabilities to ECC.

[Rod Pemberton]

On Sun, 21 Feb 2021 19:54:49 GMT

Post by Scott Lurndal

Post by James Harris

Post by Scott Lurndal

Post by James Harris

Post by wolfgang kern
lazy/bad interrupt handling (esp RTCL) may cause short BUS-locks.
the only solution for an OS is to split large junks and
verify/retry.

IMO an OS should detect bad memory.

Most consumer grade hardware doesn't have ECC protected memory.
The operating system can't detect bad memory without hardware that
detects that something has gone awry.

Are you sure...?
How do you think memtest programs work?!

Somewhat effective standalone. Quite poorly as an attempt to provide
similar capabilities to ECC.

Well, I think an OS could detect bad memory, but I don't think an OS
really should detect bad memory. I really view that as being the job of
the hardware.

If a computer user suspects a memory issue or when a customer
buys/builds a new computer, they can always test memory via a program.
If you want ECC hardware, then spend the money to buy it.

Many of these OS issues which we've been discussing can be implemented
in hardware rather easily nowadays. So, I see no reason why the
software should be burdened with them anymore. IMO, the more
abstraction or excision of the hardware specific functionality from the
OS which occurs can cause the OS design to become more streamlined.
This is just like the purpose of the original BIOS, except to be done
in hardware instead of software.

Since the topic is an OS detecting bad memory and/or file corruption:

a) If the OS check summed files in the file system, the OS could verify
the file's check sum upon being copied.

b) The OS could check sum each critical memory block at various stages
of loading, moving, and saving. If the check sum is incorrect, then
something happened. Depending on what check sum and/or error
correction algorithm you used, you may or may not be able to recover
errors.

Now, I said _critical_ as computing check sums on individual memory
blocks, instead of upon an entire file in memory, would definitely
create some overhead and bloat, which would only be necessary for the
protection of the OS, in most instances. I.e., your file data may
become corrupt because it wouldn't be protected, but the the OS code
wouldn't become corrupt or become hackable because it would be
protected.

E.g., the OS could allocate an input/output buffer of some size, say 4KB
up to 64KB, then everything loaded into memory from the drives could be
moved through this buffer. This is typical of how many C libraries
work already for file read/write functions. Many file based C
programs are coded this way too. Of course, the OS buffer could be
tested first for any errors. Next, any data to be moved from the OS
buffer to a memory block, could be check summed before being copied,
moved, and/or written. I.e., the OS memory allocator would need to
store this check sum info. Finally, prior to execution of any code, or
prior writing data to a file, the check sums for the memory blocks in
use could be verified, and provide a warning or recovery/discard options
if there is an issue.

--

[James Harris]

Post by Rod Pemberton
On Sun, 21 Feb 2021 19:54:49 GMT

Post by Scott Lurndal

Post by James Harris

Post by Scott Lurndal

Post by James Harris

Post by wolfgang kern
lazy/bad interrupt handling (esp RTCL) may cause short BUS-locks.
the only solution for an OS is to split large junks and
verify/retry.

IMO an OS should detect bad memory.

Most consumer grade hardware doesn't have ECC protected memory.
The operating system can't detect bad memory without hardware that
detects that something has gone awry.

Are you sure...?
How do you think memtest programs work?!

Somewhat effective standalone. Quite poorly as an attempt to provide
similar capabilities to ECC.

Well, I think an OS could detect bad memory, but I don't think an OS
really should detect bad memory. I really view that as being the job of
the hardware.

That would be good but what if the hardware is unable to detect such
errors? As I wrote in another reply, a machine which has a RAM fault as
obscure as the one I wrote about could have been silently corrupting
data for years. As is true of many machines it had no ECC RAM so had no
way for the hardware to do such detection.

Post by Rod Pemberton
If a computer user suspects a memory issue or when a customer
buys/builds a new computer, they can always test memory via a program.
If you want ECC hardware, then spend the money to buy it.

To be clear, I'm not suggesting error correction but only that an OS
should check memory before handing it out. If Linux had detected the RAM
fault it could have reported it and avoided handing that page out to
apps. Then my data (potentially including backups) would not have been
corrupted and I would have been able to buy RAM to replace the failing
DIMM.

Post by Rod Pemberton
Many of these OS issues which we've been discussing can be implemented
in hardware rather easily nowadays. So, I see no reason why the
software should be burdened with them anymore.

When you say "anymore" I don't think I know of any OS which does check
memory at present.

Post by Rod Pemberton
IMO, the more
abstraction or excision of the hardware specific functionality from the
OS which occurs can cause the OS design to become more streamlined.
This is just like the purpose of the original BIOS, except to be done
in hardware instead of software.

Noted. It seems strange to me that a number of people who have commented
on this don't think an OS should check memory before handing it out.
Other people's mileages evidently vary!

Post by Rod Pemberton
a) If the OS check summed files in the file system, the OS could verify
the file's check sum upon being copied.

True but what if a program changes one byte in a long file? Just reading
the 500GB file takes over an hour! Or did you mean checksums of
individual blocks?

Post by Rod Pemberton
b) The OS could check sum each critical memory block at various stages
of loading, moving, and saving. If the check sum is incorrect, then
something happened. Depending on what check sum and/or error
correction algorithm you used, you may or may not be able to recover
errors.
Now, I said _critical_ as computing check sums on individual memory
blocks, instead of upon an entire file in memory, would definitely
create some overhead and bloat, which would only be necessary for the
protection of the OS, in most instances. I.e., your file data may
become corrupt because it wouldn't be protected, but the the OS code
wouldn't become corrupt or become hackable because it would be
protected.

You might find the first 10 minutes of this interesting

The presenter talks about ZFS storing filesystem block checksums in
parent nodes rather than with the data so that it can more reliably
detect damage to data stored on disk. It sounds as though you have
something similar in mind for critical parts of the OS in memory.

While we are on the topic there's also this rather impressive video
explaining exactly how Hamming codes can identify the location of a
single-bit error in a block by adding a surprisingly small number of
check bits. As the presenter says, it seems like magic when you first
see it but becomes obvious once you see the trick.

Post by Rod Pemberton
E.g., the OS could allocate an input/output buffer of some size, say 4KB
up to 64KB, then everything loaded into memory from the drives could be
moved through this buffer. This is typical of how many C libraries
work already for file read/write functions. Many file based C
programs are coded this way too. Of course, the OS buffer could be
tested first for any errors. Next, any data to be moved from the OS
buffer to a memory block, could be check summed before being copied,
moved, and/or written. I.e., the OS memory allocator would need to
store this check sum info. Finally, prior to execution of any code, or
prior writing data to a file, the check sums for the memory blocks in
use could be verified, and provide a warning or recovery/discard options
if there is an issue.

It's an interesting idea but what's the advantage of it compared with
the OS checking all memory before handing it out to apps? (I don't mean
the OS checking all memory in one go before starting to do anything
useful but the OS, on startup, keeping track of which memory it has
checked and which it has yet to check.)

[Rod Pemberton]

On Mon, 22 Feb 2021 10:45:57 +0000

Post by James Harris

Post by Rod Pemberton
On Sun, 21 Feb 2021 19:54:49 GMT

Post by Scott Lurndal

Post by James Harris

Post by Scott Lurndal

Post by James Harris

Post by wolfgang kern
lazy/bad interrupt handling (esp RTCL) may cause short
BUS-locks.
the only solution for an OS is to split large junks and
verify/retry.

IMO an OS should detect bad memory.

Most consumer grade hardware doesn't have ECC protected memory.
The operating system can't detect bad memory without hardware
that detects that something has gone awry.

Are you sure...?
How do you think memtest programs work?!

Somewhat effective standalone. Quite poorly as an attempt to
provide similar capabilities to ECC.

Well, I think an OS could detect bad memory, but I don't think an OS
really should detect bad memory. I really view that as being the
job of the hardware.

That would be good but what if the hardware is unable to detect such
errors?

$%!^ out-of-luck?

Post by James Harris
As I wrote in another reply, a machine which has a RAM fault
as obscure as the one I wrote about could have been silently
corrupting data for years. As is true of many machines it had no ECC
RAM so had no way for the hardware to do such detection.

You can test your machine for memory errors with a program as
frequently as you want, e.g., every time you do backups. I.e., if it's
not the hardware's problem, and it's not the OS' problem, shouldn't it
be the user's problem?

Post by James Harris

Post by Rod Pemberton
If a computer user suspects a memory issue or when a customer
buys/builds a new computer, they can always test memory via a
program. If you want ECC hardware, then spend the money to buy it.

To be clear, I'm not suggesting error correction but only that an OS
should check memory before handing it out.

Bloat. Complexity.

Post by James Harris
If Linux had detected the
RAM fault it could have reported it and avoided handing that page out
to apps. Then my data (potentially including backups) would not have
been corrupted and I would have been able to buy RAM to replace the
failing DIMM.

If God had detected the RAM fault he could have reported it ...

Obviously, the OS could do it, but should it? I already stated my
position of "No" on that.

Now, let's play, "Who or what failed to detect my bad RAM?"

a) God
b) hardware
c) OS
d) James

Please, don't call me an asshole for that, even if it was rather
uncouth of me. I just found it rather amusing (ROFL) that it now seems
like you're whining a bit about *nix not detecting the problem for you
...

Post by James Harris

Post by Rod Pemberton
Many of these OS issues which we've been discussing can be
implemented in hardware rather easily nowadays. So, I see no
reason why the software should be burdened with them anymore.

When you say "anymore" I don't think I know of any OS which does
check memory at present.

Sorry, "them" prior to "anymore" referred to "Many of these OS issues
which we've been discussing ...", none of which were identified by me
or checked as to whether or not they once had been actually
implemented. The point being the hardware could take care of these
more advanced things nowadays if sod designed, so why shouldn't it?
(general observation)

Post by James Harris

Post by Rod Pemberton
IMO, the more
abstraction or excision of the hardware specific functionality from
the OS which occurs can cause the OS design to become more
streamlined. This is just like the purpose of the original BIOS,
except to be done in hardware instead of software.

Noted. It seems strange to me that a number of people who have
commented on this don't think an OS should check memory before
handing it out. Other people's mileages evidently vary!

AISI, it's more of a practical or common sense matter. How much work
do you intend to put into your OS code? And, where is your time best
spent? If your hardware works correctly, as it should, how much time
and code do you spend on verifying it's correctness? There is plenty
of work to do without having to verify the hardware works.
Corporations face the same decision, not because of time spent, but
because of money spent on salaries.

Post by James Harris

Post by Rod Pemberton
Since the topic is an OS detecting bad memory and/or file
a) If the OS check summed files in the file system, the OS could
verify the file's check sum upon being copied.

True but what if a program changes one byte in a long file? Just
reading the 500GB file takes over an hour!

I meant that a check sum would be computed when the file was saved
initially. Then, another would be computed when the file was copied.
In both instances, the file is being written in it's entirety, so the
user has to wait an hour both times. Of course, the "file" being
copied could be a raw device under *nix as "Everything is a file." In
that case, two check sums for read and write would need to be computed
at the same time.

Post by James Harris
Or did you mean checksums
of individual blocks?

I didn't mean that, but that's a more fine grained option, perhaps
allowing more precise error detection. Unfortunately, numerous check
sums would have to be computed for a file copy, and each one checked,
instead of just computing and checking one (against an earlier sum).

Post by James Harris

Post by Rod Pemberton
b) The OS could check sum each critical memory block at various
stages of loading, moving, and saving. If the check sum is
incorrect, then something happened. Depending on what check sum
and/or error correction algorithm you used, you may or may not be
able to recover errors.
Now, I said _critical_ as computing check sums on individual memory
blocks, instead of upon an entire file in memory, would definitely
create some overhead and bloat, which would only be necessary for
the protection of the OS, in most instances. I.e., your file data
may become corrupt because it wouldn't be protected, but the the OS
code wouldn't become corrupt or become hackable because it would be
protected.

You might find the first 10 minutes of this interesting
http://youtu.be/Hjpqa_kjCOI
The presenter talks about ZFS storing filesystem block checksums in
parent nodes rather than with the data so that it can more reliably
detect damage to data stored on disk. It sounds as though you have
something similar in mind for critical parts of the OS in memory.

I just meant that an OS designer, if attempting to protect the OS from
memory corruption, would likely only protect the OS, and not make any
attempt to protect user data due to extra time, cost, bloat, and
complexity.

Post by James Harris
While we are on the topic there's also this rather impressive video
explaining exactly how Hamming codes can identify the location of a
single-bit error in a block by adding a surprisingly small number of
check bits. As the presenter says, it seems like magic when you first
see it but becomes obvious once you see the trick.
http://youtu.be/X8jsijhllIA

I've never used them, but was exposed to Hamming and other error
correction codes as a part of my electrical engineering classes decades
ago. The last thing I remember about them was that one of them could
correct up to 2 bits. Maybe, they're more advanced now. IIRC, I
discussed them some years back too with someone, perhaps you.

Post by James Harris

Post by Rod Pemberton
E.g., the OS could allocate an input/output buffer of some size,
say 4KB up to 64KB, then everything loaded into memory from the
drives could be moved through this buffer. This is typical of how
many C libraries work already for file read/write functions. Many
file based C programs are coded this way too. Of course, the OS
buffer could be tested first for any errors. Next, any data to be
moved from the OS buffer to a memory block, could be check summed
before being copied, moved, and/or written. I.e., the OS memory
allocator would need to store this check sum info. Finally, prior
to execution of any code, or prior writing data to a file, the
check sums for the memory blocks in use could be verified, and
provide a warning or recovery/discard options if there is an issue.

It's an interesting idea but what's the advantage of it compared with
the OS checking all memory before handing it out to apps?

Check all memory as it's allocated? Takes time. Also, this doesn't
detect changes in the data after it has been written into allocated
memory. The check sums in my example would be computed when the data
was in two different memory regions, and so could detect memory that
immediately shows an issue, such as a stuck bit, as well as memory which
very slowly shows an issue, such as a bit that slowly decays to the
opposite state, if the original check sum was saved.

Obviously, my example wouldn't attempt to test for the more complicated
situations a memory tester program would try to detect. I'm assuming
your method(s) wouldn't do so either. So, is there really any point to
implementing such simple memory tests as part of the OS proper? You
stated that a more thorough and/or complicated memory test was needed
to identify the issue with your memory chip.

--

[James Harris]

Post by Scott Lurndal

Post by James Harris

Post by Scott Lurndal

Post by James Harris

Post by wolfgang kern
lazy/bad interrupt handling (esp RTCL) may cause short BUS-locks.
the only solution for an OS is to split large junks and verify/retry.

IMO an OS should detect bad memory.

Most consumer grade hardware doesn't have ECC protected memory.
The operating system can't detect bad memory without hardware that
detects that something has gone awry.

Are you sure...?
How do you think memtest programs work?!

Somewhat effective standalone. Quite poorly as an attempt to provide
similar capabilities to ECC.

Error /correction/ is somewhat out of scope! What I was suggesting was
that an OS should check that memory is good before handing it out to apps.

When you think about it, the problem I mentioned at the start of this
thread and its diagnosis means that the PC in question has for some time
been silently corrupting roughly 1 bit in a trillion. How long has that
been happening? There's no way to tell. What damage has it done to my
files? Again, that's unknown.

Furthermore, the problem was not detected when the machine booted. It
wasn't even detected by most of the intensive memtest algorithms. But it
was there and it was damaging data.

As you know, a 1-bit error in a jpg wouldn't matter but a 1-bit error in
a program could cause catastrophic behaviour.

Worse still, if it went on long enough then even backups will have been
corrupted.

Surely it is the responsibility of an OS to detect such failures. It's
certainly not up to apps, and a user isn't going to realise there's a
problem unless he copies and then compares 500GB files - which doesn't
happen often!

[Scott Lurndal]

Post by James Harris

Post by Scott Lurndal

Post by James Harris

Post by Scott Lurndal

Post by James Harris

Post by wolfgang kern
lazy/bad interrupt handling (esp RTCL) may cause short BUS-locks.
the only solution for an OS is to split large junks and verify/retry.

IMO an OS should detect bad memory.

Most consumer grade hardware doesn't have ECC protected memory.
The operating system can't detect bad memory without hardware that
detects that something has gone awry.

Are you sure...?
How do you think memtest programs work?!

Somewhat effective standalone. Quite poorly as an attempt to provide
similar capabilities to ECC.

Error /correction/ is somewhat out of scope! What I was suggesting was
that an OS should check that memory is good before handing it out to apps.

I think the performance cost of doing so will not be worth any
potential benefit.

[James Harris]

Post by James Harris

Post by Scott Lurndal

Post by James Harris

Post by wolfgang kern
lazy/bad interrupt handling (esp RTCL) may cause short BUS-locks.
the only solution for an OS is to split large junks and verify/retry.

IMO an OS should detect bad memory.

Most consumer grade hardware doesn't have ECC protected memory.
The operating system can't detect bad memory without hardware that
detects that something has gone awry.

Are you sure...?
How do you think memtest programs work?!

memtest may only check random locations within some blocks...
a true walking-bit test on 16GB would take one year or more :)

The memtest I ran apparently tried a number of walking-bit tests on 4GB
and did so fairly quickly. But, interestingly, they didn't spot the
problem. It was only in what it called the random-number test that it
found the fault.

FWIW, I've only once before seen a memory error on a PC. That, too, was
detected by the random-number test rather than the program's walking-bit
test.

There must be some practical set of tests which an OS could use to check
memory before handing it out. (Most or all of such tests could be
avoided where the OS can detect ECC RAM.)

[Rod Pemberton]

On Mon, 22 Feb 2021 09:54:38 +0000

Post by James Harris

Post by James Harris

Post by Scott Lurndal

Post by James Harris

Post by wolfgang kern
lazy/bad interrupt handling (esp RTCL) may cause short
BUS-locks.
the only solution for an OS is to split large junks and
verify/retry.

IMO an OS should detect bad memory.

Most consumer grade hardware doesn't have ECC protected memory.
The operating system can't detect bad memory without hardware that
detects that something has gone awry.

Are you sure...?
How do you think memtest programs work?!

memtest may only check random locations within some blocks...
a true walking-bit test on 16GB would take one year or more :)

The memtest I ran apparently tried a number of walking-bit tests on
4GB and did so fairly quickly. But, interestingly, they didn't spot
the problem. It was only in what it called the random-number test
that it found the fault.
FWIW, I've only once before seen a memory error on a PC. That, too,
was detected by the random-number test rather than the program's
walking-bit test.
There must be some practical set of tests which an OS could use to
check memory before handing it out. (Most or all of such tests could
be avoided where the OS can detect ECC RAM.)

I think most of those tests really only test for a bit being stuck,
although they attempt to test for other things.

Testing for a bit the decays or fades to the opposite state would be
harder to test. You'd have to keep testing the memory for a long time.

The fact that your computer's error was apparently found with random
values, would seem to imply there were multiple bits involved. I.e.,
if it was just a stuck bit etc, then the simpler tests should have
found it, or so I'd suspect.

--

[James Harris]

Post by James Harris
Well, here's a strange one. After I copied a file from one drive to
another I compared them and found them to be different! :-(

...

Post by James Harris
    cp -i /mnt/backups0/disk.img /mnt/backups1/work.img
Only one bit changed. A byte about 1.3% into the file was originally
0x70 but in the copy it became 0x71.

...

Thanks for the replies so far. I've read them but I haven't replied yet
as I am not sure what to say! What I have done is run the copy a few
more times and, to my astonishment, the first error was not a simple
glitch: each run has ended up with mismatches!

If, for simplicity, I call the source file S here are the results of
running cmp on each of the new copies.


Second copy:

# cmp -bl S cp2
55953317123 72 : 73 ;
136265755907 104 D 105 E

The above shows that copy 2 had two mismatches, one per line at the
stated file positions. Since cmp writes byte values in octal what it's
saying is that one byte of octal 72 in the original became octal 73 in
the copy, and similar with 104 becoming 105.



Third copy:

# cmp -bl S cp3
232018550019 220 M-^P 221 M-^Q
362797145347 16 ^N 17 ^O

That third copy job (using the Unix cp command) also shows two mismatches.


In case it was a problem with cp I tried copying the file using rsync
but that also had a problem as follows.


Fourth copy (this time using rsync instead of cp):

# cmp -bl S rsync1
338194283779 124 T 125 U


In other words all show mismatches. In every case (including the
original cp copy) one or more bits was found to have been changed from
zero to one. Maybe that gives a clue as to what's causing the problem?

The limited number of tests is because each copy-and-compare takes two
to three hours but that's four tests run now, all with similar issues.

There's only something like one bit in a trillion getting changed but
this shouldn't be happening, should it...?

IIRC disk drives can be rated as 1 error in N bits. Maybe we shouldn't
expect any better? :-((

Post by James Harris
The only places I can think of where the bit could have been changed
from 0 to 1 are the following four.
* Between source drive and host system.
* In the host system's CPU or RAM. (It's plain RAM, not ECC.)
* Between host system and target drive.
* Within the host drive when it transferred its RAM to the disk surface.

I'm still trying to work out where this is happening. I'll run some more
tests to see if I can narrow it down a little.

[wolfgang kern]

On 16.02.2021 15:52, James Harris wrote:
...

Post by James Harris
Thanks for the replies so far. I've read them but I haven't replied yet
as I am not sure what to say! What I have done is run the copy a few
more times and, to my astonishment, the first error was not a simple
glitch: each run has ended up with mismatches!

[..] seems you got a hardware problem then, either RAM,PSU,RTCL or HD.
I'd first disable IRQ_8 (RTCL) and then check for HD error with sector
by sector write/verify sequence, even it may take a week or more ...
__
wolfgang

[Scott Lurndal]

Post by wolfgang kern
...

Post by James Harris
Thanks for the replies so far. I've read them but I haven't replied yet
as I am not sure what to say! What I have done is run the copy a few
more times and, to my astonishment, the first error was not a simple
glitch: each run has ended up with mismatches!

[..] seems you got a hardware problem then, either RAM,PSU,RTCL or HD.
I'd first disable IRQ_8 (RTCL) and then check for HD error with sector
by sector write/verify sequence, even it may take a week or more ...

It appeared to be the low-order bit in all cases that were described,
which is indicative of a hardware problem.

[Rod Pemberton]

On Wed, 17 Feb 2021 14:55:53 GMT

Post by Scott Lurndal

Post by wolfgang kern

Post by James Harris
Thanks for the replies so far. I've read them but I haven't
replied yet as I am not sure what to say! What I have done is run
the copy a few more times and, to my astonishment, the first error
was not a simple glitch: each run has ended up with mismatches!

[..] seems you got a hardware problem then, either RAM,PSU,RTCL or
HD. I'd first disable IRQ_8 (RTCL) and then check for HD error with
sector by sector write/verify sequence, even it may take a week or
more ...

It appeared to be the low-order bit in all cases that were described,
which is indicative of a hardware problem.

Anyone else beginning to think that this may be an old 386 or 486
original IBM computer with DIP memory chips, MRM hard disk or early IDE
hard disk, with a high current draw Cyrix processor or perhaps NEC V20,
being connected to a modern computer via null-modem serial cable? ...

I.e., James has been exceptionally vague on details about this computer.

--

[Rod Pemberton]

On Thu, 18 Feb 2021 03:34:09 -0500

Post by Rod Pemberton
On Wed, 17 Feb 2021 14:55:53 GMT

Post by Scott Lurndal

Post by wolfgang kern

Post by James Harris
Thanks for the replies so far. I've read them but I haven't
replied yet as I am not sure what to say! What I have done is run
the copy a few more times and, to my astonishment, the first
error was not a simple glitch: each run has ended up with
mismatches!

[..] seems you got a hardware problem then, either RAM,PSU,RTCL or
HD. I'd first disable IRQ_8 (RTCL) and then check for HD error with
sector by sector write/verify sequence, even it may take a week or
more ...

It appeared to be the low-order bit in all cases that were
described, which is indicative of a hardware problem.

Anyone else beginning to think that this may be an old 386 or 486
original IBM computer with DIP memory chips, MRM hard disk or early
IDE hard disk, with a high current draw Cyrix processor or perhaps
NEC V20, being connected to a modern computer via null-modem serial
cable? ...
I.e., James has been exceptionally vague on details about this
computer.

E.g., if this is an old P.O.S., then maybe it has a broken/failing
IDE/MFM/Floppy cable, need to re-seat DIP memory chips or processor,
need to apply new heat sink grease to processor, bad connector for
RS-232C or disk cable, corroded/tarnished contacts on card slot, need
to re-solder cold through-hole solder joints, ...

Also, older computers would sometimes twist an inserted card if you
screwed them to the slot on the case, i.e., case slot and motherboard
connector weren't aligned. This could be pulling an IDE card out of the
motherboard.

Well, I've shotgunned your problem enough. Let me know if one of them
actually hit! ;-)

--

[James Harris]

Post by Rod Pemberton
On Wed, 17 Feb 2021 14:55:53 GMT

Post by Scott Lurndal

Post by wolfgang kern

Post by James Harris
Thanks for the replies so far. I've read them but I haven't
replied yet as I am not sure what to say! What I have done is run
the copy a few more times and, to my astonishment, the first error
was not a simple glitch: each run has ended up with mismatches!

[..] seems you got a hardware problem then, either RAM,PSU,RTCL or
HD. I'd first disable IRQ_8 (RTCL) and then check for HD error with
sector by sector write/verify sequence, even it may take a week or
more ...

It appeared to be the low-order bit in all cases that were described,
which is indicative of a hardware problem.

Anyone else beginning to think that this may be an old 386 or 486
original IBM computer with DIP memory chips, MRM hard disk or early IDE
hard disk, with a high current draw Cyrix processor or perhaps NEC V20,
being connected to a modern computer via null-modem serial cable? ...
I.e., James has been exceptionally vague on details about this computer.

:-) Not deliberately.

The spec:
ASUS mobo with AMD Athlon(tm) X2 Dual Core BE-2400
4GB DDR2 RAM
120GB SSD system disk
2x8TB Seagate SMR data drives

It is an old machine which I put to use recently as a backup server, by
which I mean it is configured to take copies of various parts of other
machines each night.

[Rod Pemberton]

On Fri, 19 Feb 2021 14:07:46 +0000

Post by James Harris
2x8TB Seagate SMR data drives

I haven't kept up with hard disk technology in decades. Was this SMR
technology the reason you were asking about differences in the read and
write head widths a while back? When I searched for SMR, a short
article on PMR versus SMR came up. PMR was what I learned about
decades ago for floppies and hard disks. SMR is novel, but obviously,
you can't rewrite a track easily, as it will overwrite data on the
adjacent track. I'm still not sure why they don't or can't figure out
how to make the write head as narrow as the read head.

--

[James Harris]

Post by Rod Pemberton
On Fri, 19 Feb 2021 14:07:46 +0000

Post by James Harris
2x8TB Seagate SMR data drives

I haven't kept up with hard disk technology in decades. Was this SMR
technology the reason you were asking about differences in the read and
write head widths a while back?

I doubt it. I didn't know the heads were different sizes! I did ask
about SMR but more about the logistics of having to rewrite large
chunks, IIRC. If an OS could be made aware of shingle sizes it could
significantly improve the performance of certain writes. Such knowledge
would also allow an OS to get better performance out of and less wear of
SSDs.

Unfortunately, the storage industry has long been obsessed with
providing the illusion of a perfect array of sectors even though that
hurts performance.

Post by Rod Pemberton
When I searched for SMR, a short
article on PMR versus SMR came up. PMR was what I learned about
decades ago for floppies and hard disks. SMR is novel, but obviously,
you can't rewrite a track easily, as it will overwrite data on the
adjacent track. I'm still not sure why they don't or can't figure out
how to make the write head as narrow as the read head.

When I got the drives I found that the ext4 formatting process became
inordinately slow when the format program spread copies of its metadata
across the disk. The drive was evidently having to rewrite entire
shingled zones for each such block of metadata.

The fix was to use packed_meta_blocks as in

mkfs.ext4 -E packed_meta_blocks=1 /dev/sdd2 -b 4096

See

https://man7.org/linux/man-pages/man8/mke2fs.8.html

for info about the option.

[Bernhard Schornak]

Post by Rod Pemberton
On Fri, 19 Feb 2021 14:07:46 +0000

    2x8TB Seagate SMR data drives

I haven't kept up with hard disk technology in decades.  Was this SMR
technology the reason you were asking about differences in the read and
write head widths a while back?

I doubt it. I didn't know the heads were different sizes! I did ask about SMR but more about the
logistics of having to rewrite large chunks, IIRC. If an OS could be made aware of shingle sizes it
could significantly improve the performance of certain writes. Such knowledge would also allow an OS
to get better performance out of and less wear of SSDs.
Unfortunately, the storage industry has long been obsessed with providing the illusion of a perfect
array of sectors even though that hurts performance.

SMR is perfect for write once, read on demand, while CMR is
perfect for random read/write sequences. The problem is not
the physical architecture, but the width of the write head,
which overwrites data on the cylinders - not sectors - next
to the current cylinder. The altered data must be restored,
which consumes time, and therefore slows down writing. This
has nothing to do with organisation in sectors (segments of
a cylinder). Lower sector counts towards the centers of the
platters was introduced long time ago. Only *very* old HDDs
have equal sector counts for all cylinders.


Enjoy the weekend!

Bernhard Schornak

[James Harris]

Post by Bernhard Schornak

Post by James Harris

Post by Rod Pemberton
On Fri, 19 Feb 2021 14:07:46 +0000

    2x8TB Seagate SMR data drives

I haven't kept up with hard disk technology in decades.  Was this SMR
technology the reason you were asking about differences in the read and
write head widths a while back?

I doubt it. I didn't know the heads were different sizes! I did ask
about SMR but more about the logistics of having to rewrite large
chunks, IIRC. If an OS could be made aware of shingle sizes it could
significantly improve the performance of certain writes. Such
knowledge would also allow an OS to get better performance out of and
less wear of SSDs.
Unfortunately, the storage industry has long been obsessed with
providing the illusion of a perfect array of sectors even though that
hurts performance.

SMR is perfect for write once, read on demand, while CMR is
perfect for random read/write sequences.

Well, surely CMR is also good for write once, read on demand.

If SMR is good at anything it's saving money! It's a cheap way of using
disk surface. But the downside is it's really poor at random writes. CMR
is good at both random and sequential reads and writes.

In my case the two 8TB drives are to store backups, especially of large
TV recordings, so writes are mainly sequential and SMR is fine.

Post by Bernhard Schornak
The problem is not
the physical architecture, but the width of the write head,
which overwrites data on the cylinders - not sectors - next
to the current cylinder. The altered data must be restored,
which consumes time, and therefore slows down writing. This
has nothing to do with organisation in sectors (segments of
a cylinder).

That's not the performance problem I was thinking of. Rather:

1. Most HDDs hide bad sectors from the OS. For one thing they waste
space by setting aside spare sectors and cylinders. Worse from a
performance perspective, they remap bad sectors to the spares. That
hurts performance because it adds both rotational delay and head
movements that the OS is kept in the dark about.

A drive's internal caches help a lot but it would be better to have both
the caches /and/ for the OS to know where the bad sectors were.

If the OS were able to handle bad sectors it could, instead, allow the
much smaller delays of simple rotation past bad sectors. No need to wait
for rotation to where the spare sectors are and no need for any head
movement at all.

2. Since, IIRC, ATA2 an OS doesn't even get to read a disk without
retries. That option was removed.

Post by Bernhard Schornak
Lower sector counts towards the centers of the
platters was introduced long time ago. Only *very* old HDDs
have equal sector counts for all cylinders.

Indeed. Where the resulting zones begin and end is, IMO, something else
an OS should be made aware of.

[Bernhard Schornak]

Post by James Harris

Post by Bernhard Schornak

Post by Rod Pemberton
On Fri, 19 Feb 2021 14:07:46 +0000

    2x8TB Seagate SMR data drives

I haven't kept up with hard disk technology in decades.  Was this SMR
technology the reason you were asking about differences in the read and
write head widths a while back?

I doubt it. I didn't know the heads were different sizes! I did ask about SMR but more about the
logistics of having to rewrite large chunks, IIRC. If an OS could be made aware of shingle sizes
it could significantly improve the performance of certain writes. Such knowledge would also allow
an OS to get better performance out of and less wear of SSDs.
Unfortunately, the storage industry has long been obsessed with providing the illusion of a
perfect array of sectors even though that hurts performance.

SMR is perfect for write once, read on demand, while CMR is
perfect for random read/write sequences.

Well, surely CMR is also good for write once, read on demand.
If SMR is good at anything it's saving money! It's a cheap way of using disk surface. But the
downside is it's really poor at random writes. CMR is good at both random and sequential reads and
writes.
In my case the two 8TB drives are to store backups, especially of large TV recordings, so writes are
mainly sequential and SMR is fine.

I replaced my former array of 2 * 2 TB and 2 * 4 TB with two
10 GB drives (HGST HUH721010ALE600). They work fine, and are
faster than any of the previously installed drives.

Post by James Harris

Post by Bernhard Schornak
The problem is not
the physical architecture, but the width of the write head,
which overwrites data on the cylinders - not sectors - next
to the current cylinder. The altered data must be restored,
which consumes time, and therefore slows down writing. This
has nothing to do with organisation in sectors (segments of
a cylinder).

1. Most HDDs hide bad sectors from the OS. For one thing they waste space by setting aside spare
sectors and cylinders. Worse from a performance perspective, they remap bad sectors to the spares.
That hurts performance because it adds both rotational delay and head movements that the OS is kept
in the dark about.
A drive's internal caches help a lot but it would be better to have both the caches /and/ for the OS
to know where the bad sectors were.
If the OS were able to handle bad sectors it could, instead, allow the much smaller delays of simple
rotation past bad sectors. No need to wait for rotation to where the spare sectors are and no need
for any head movement at all.
2. Since, IIRC, ATA2 an OS doesn't even get to read a disk without retries. That option was removed.

Assignment of sectors is - and always was - a hardware task.
There is no OS keeping track of sectors and such. All modern
OS'es access drives via LBAs, where the physical position of
each sector is transparent to the OS. It would slow down any
data transfer, if a OS interfered with the drive controller,
telling the drive where to write which data. Modern transfer
is done via memory. The OS just tells the drive where to get
how much data from (writes), or where to store how much data
to (reads).

Post by James Harris

Post by Bernhard Schornak
Lower sector counts towards the centers of the
platters was introduced long time ago. Only *very* old HDDs
have equal sector counts for all cylinders.

Indeed. Where the resulting zones begin and end is, IMO, something else an OS should be made aware of.

Why? No OS can perform such tasks better or even faster than
the specialised hardware on the drive itself. It's a part of
any HDD development, to optimise access on hardware level.


Enjoy the weekend!

Bernhard Schornak

[James Harris]

...

Post by Bernhard Schornak

Post by James Harris
If the OS were able to handle bad sectors it could, instead, allow the
much smaller delays of simple rotation past bad sectors. No need to
wait for rotation to where the spare sectors are and no need for any
head movement at all.
2. Since, IIRC, ATA2 an OS doesn't even get to read a disk without
retries. That option was removed.

Assignment of sectors is - and always was - a hardware task.
There is no OS keeping track of sectors and such. All modern
OS'es access drives via LBAs, where the physical position of
each sector is transparent to the OS. It would slow down any
data transfer, if a OS interfered with the drive controller,
telling the drive where to write which data. Modern transfer
is done via memory. The OS just tells the drive where to get
how much data from (writes), or where to store how much data
to (reads).

I'm sorry, Bernhard, but I completely disagree with you on this. What
you say is essentially true of SSDs where there is neither rotational
nor actuator delay but if we want performance on disks we still need to
think about /where/ sectors are physically located in relation to each
other.

That's one reason why modern file systems such as ext4 allocate space
for files in 'extents'. (IBM was doing this on mainframes in the 1960s.)
It is faster to read a disk cylinder by cylinder and track by track than
it is to have sectors scattered around.

Post by Bernhard Schornak

Post by James Harris

Post by Bernhard Schornak
Lower sector counts towards the centers of the
platters was introduced long time ago. Only *very* old HDDs
have equal sector counts for all cylinders.

Indeed. Where the resulting zones begin and end is, IMO, something
else an OS should be made aware of.

Why? No OS can perform such tasks better or even faster than
the specialised hardware on the drive itself. It's a part of
any HDD development, to optimise access on hardware level.

Because a hard drive does not and cannot know how the blocks it is
passed by the OS are intended to be used. An OS (or a storage manager)
will be in a position to know which block comes after another in a file
and can be told or can find out by learning how files are accessed.

Put simply, files which don't need speed could go at the slow end of the
drive near the spindle whereas files which need faster read/write times
could go nearer the edge. No disk drive can know such things.

[Scott Lurndal]

Post by James Harris
...

Post by Bernhard Schornak

Post by James Harris
If the OS were able to handle bad sectors it could, instead, allow the
much smaller delays of simple rotation past bad sectors. No need to
wait for rotation to where the spare sectors are and no need for any
head movement at all.
2. Since, IIRC, ATA2 an OS doesn't even get to read a disk without
retries. That option was removed.

Assignment of sectors is - and always was - a hardware task.
There is no OS keeping track of sectors and such. All modern
OS'es access drives via LBAs, where the physical position of
each sector is transparent to the OS. It would slow down any
data transfer, if a OS interfered with the drive controller,
telling the drive where to write which data. Modern transfer
is done via memory. The OS just tells the drive where to get
how much data from (writes), or where to store how much data
to (reads).

I'm sorry, Bernhard, but I completely disagree with you on this. What
you say is essentially true of SSDs where there is neither rotational
nor actuator delay but if we want performance on disks we still need to
think about /where/ sectors are physically located in relation to each
other.

That may have been true in 1985. It's not worth the effort with
modern spinning rust.

[James Harris]

Post by Scott Lurndal

Post by James Harris
...

Post by Bernhard Schornak

Post by James Harris
If the OS were able to handle bad sectors it could, instead, allow the
much smaller delays of simple rotation past bad sectors. No need to
wait for rotation to where the spare sectors are and no need for any
head movement at all.
2. Since, IIRC, ATA2 an OS doesn't even get to read a disk without
retries. That option was removed.

Assignment of sectors is - and always was - a hardware task.
There is no OS keeping track of sectors and such. All modern
OS'es access drives via LBAs, where the physical position of
each sector is transparent to the OS. It would slow down any
data transfer, if a OS interfered with the drive controller,
telling the drive where to write which data. Modern transfer
is done via memory. The OS just tells the drive where to get
how much data from (writes), or where to store how much data
to (reads).

I'm sorry, Bernhard, but I completely disagree with you on this. What
you say is essentially true of SSDs where there is neither rotational
nor actuator delay but if we want performance on disks we still need to
think about /where/ sectors are physically located in relation to each
other.

That may have been true in 1985. It's not worth the effort with
modern spinning rust.

Surely the effort depends on how files are intended to be used. And
rather than "spinning rust" modern hard drives are cutting edge. Solid
state has not yet come up with anything which is price comparable. Even
new typed of hard drive are hitting the market, e.g.

https://blocksandfiles.com/2021/02/18/toshiba-18tb-mg09-hdd/

[James Harris]

Post by James Harris

Post by James Harris
...

Post by Bernhard Schornak

Post by James Harris
If the OS were able to handle bad sectors it could, instead, allow the
much smaller delays of simple rotation past bad sectors. No need to
wait for rotation to where the spare sectors are and no need for any
head movement at all.
2. Since, IIRC, ATA2 an OS doesn't even get to read a disk without
retries. That option was removed.

Assignment of sectors is - and always was - a hardware task.
There is no OS keeping track of sectors and such. All modern
OS'es access drives via LBAs, where the physical position of
each sector is transparent to the OS. It would slow down any
data transfer, if a OS interfered with the drive controller,
telling the drive where to write which data. Modern transfer
is done via memory. The OS just tells the drive where to get
how much data from (writes), or where to store how much data
to (reads).

I'm sorry, Bernhard, but I completely disagree with you on this. What
you say is essentially true of SSDs where there is neither rotational
nor actuator delay but if we want performance on disks we still need to
think about /where/ sectors are physically located in relation to each
other.

That may have been true in 1985.  It's not worth the effort with
modern spinning rust.

Surely the effort depends on how files are intended to be used.

I mean whether it's /worth/ the effort or not depends on intended usage.
If users choose to use disks for cost reasons then they should be able
to do so without their access to those disks being unnecessarily slowed
down by sector remapping.

SSDs are catching up on cost but they are still more expensive.

[Scott Lurndal]

Post by James Harris

Post by Scott Lurndal
That may have been true in 1985. It's not worth the effort with
modern spinning rust.

Surely the effort depends on how files are intended to be used. And
rather than "spinning rust" modern hard drives are cutting edge.

A turn of phrase, referring to the iron oxide coating on
disk platters in the days of removable packs.

Indeed, helium-filled drives with advanced recording techniques
are available. It's been my experience that the trend is towards
dense NVME arrays rather than higher capacity HDD.

I probably should have said "may have been true when the average
seek time was 20 milliseconds and rotational latency was 8.something
milliseconds and disk drives had no on-board DRAM or SRAM caches.

[James Harris]

Post by Scott Lurndal

Post by James Harris

Post by Scott Lurndal
That may have been true in 1985. It's not worth the effort with
modern spinning rust.

Surely the effort depends on how files are intended to be used. And
rather than "spinning rust" modern hard drives are cutting edge.

A turn of phrase, referring to the iron oxide coating on
disk platters in the days of removable packs.
Indeed, helium-filled drives with advanced recording techniques
are available. It's been my experience that the trend is towards
dense NVME arrays rather than higher capacity HDD.
I probably should have said "may have been true when the average
seek time was 20 milliseconds and rotational latency was 8.something
milliseconds and disk drives had no on-board DRAM or SRAM caches.

The basic problem will exist whenever one has rotational and seek
latency. Any sectors which the drive has remapped require either
additional rotational delay or additional seek time or both.

By contrast, if the drive did not remap sectors but, instead, informed
the host where the bad sectors were then the host could account for that
when laying out data on disk, allowing IO to be significantly faster.

As for caches, they don't help when the drive is busy, say with a large
file copy, because the drive never gets idle time in which to read ahead!

[Scott Lurndal]

Post by James Harris

Post by Scott Lurndal
I probably should have said "may have been true when the average
seek time was 20 milliseconds and rotational latency was 8.something
milliseconds and disk drives had no on-board DRAM or SRAM caches.

The basic problem will exist whenever one has rotational and seek
latency. Any sectors which the drive has remapped require either
additional rotational delay or additional seek time or both.

One of our volume products is a disk drive controller (the chip
on the drive); They've advanced substantially since 1985. The
application doesn't have any need to care about where, on a drive,
a portion of a file exists. The operating system, file system driver,
host bus adapter and drive electronics are all conspiring against it.

Post by James Harris
By contrast, if the drive did not remap sectors but, instead, informed
the host where the bad sectors were then the host could account for that
when laying out data on disk, allowing IO to be significantly faster.

You'll need to back this assertion up with some actual real-world
numbers, I'm afraid.

Post by James Harris
As for caches, they don't help when the drive is busy, say with a large
file copy, because the drive never gets idle time in which to read ahead!

I think you'd be surprised at the difference in data rates from the heads
to the cache and between the cache and the host. Those tracks are pretty
dense nowadays.

[James Harris]

Post by Scott Lurndal

Post by James Harris

Post by Scott Lurndal
I probably should have said "may have been true when the average
seek time was 20 milliseconds and rotational latency was 8.something
milliseconds and disk drives had no on-board DRAM or SRAM caches.

The basic problem will exist whenever one has rotational and seek
latency. Any sectors which the drive has remapped require either
additional rotational delay or additional seek time or both.

One of our volume products is a disk drive controller (the chip
on the drive); They've advanced substantially since 1985. The
application doesn't have any need to care about where, on a drive,
a portion of a file exists. The operating system, file system driver,
host bus adapter and drive electronics are all conspiring against it.

If you are involved in making such drive controller chips perhaps you
can answer a question which has been bugging me for some time and I've
never found an answer to. Can modern drive controllers read from or
write to all heads in a cylinder at the same time - or do they have to
carry out IO for one head at a time, perhaps with some micro-seeking of
the actuator arm on each track?

Post by Scott Lurndal

Post by James Harris
By contrast, if the drive did not remap sectors but, instead, informed
the host where the bad sectors were then the host could account for that
when laying out data on disk, allowing IO to be significantly faster.

You'll need to back this assertion up with some actual real-world
numbers, I'm afraid.

Specific timings would depend on the drive model but I can reply with
some example figures to illustrate the point.

What I intend to show is that with remapped sectors there are several
sources of delay relative to what could be accomplished.

Assuming read operations as they are most common and to keep the
description simple, the fastest possible way to read a drive would be
cylinder by cylinder and, if a controller cannot read from all heads at
at once then, within that, track by track. The time to read each
cylinder of a contiguous set would be approximately

a + e(h + f + r)

where

a is the time to move the actuator to the adjacent cylinder - say 0.5ms

e is the effective number of tracks on a cylinder and would be 1 if
the controller is able to read from an entire cylinder at a time

h is the time to switch heads - say 0.001 ms

f is the time to wait for the start of a sector to appear beneath the
head - say 0.001 ms

r is the time for the spindle to rotate fully - say 8.3ms

If e is 1 then the above formula would suggest reading a set of adjacent
cylinders would take about 9ms each.



The point I am making is that if the controller remaps bad sectors then
there are two additional sources of delay:

1. Any space reserved for bad sectors or bad tracks will still cost time
(even if the medium has no bad areas). Such space will not be occupied
so will reduce the overall data rate. If n% of a drive were reserved
then the data on the disk would essentially be readable a little under
n% slower - with exact timings depending on whether sectors, tracks or
cylinders were reserved and other factors.

2. Any remapped data will require additional time to
a) find out where the bad block has been remapped to
b) seek to the right place
c) wait for the data to pass under the head
d) seek back to where we came from for the next read

Let's say that would add 7 to 20 ms for each such read depending on
where the block had been remapped to.

By contrast, if the OS knew where the bad blocks were it could simply
not use them. The cost of that would be approximately 2f (where f is as
defined above) which would be, say, 2 microseconds.



BOTTOM LINE
===========

From the above a 'bad block' should take something of the order of 2
microseconds to process but remapping could perhaps turn that into
something like 7,000 to 20,000 microseconds. Such delays are completely
unnecessary: the OS could handle the bad areas far more efficiently than
a drive controller.



Note that the above is only about bad areas. It could also help
efficiency if drives made an OS aware of (1) where the number of sectors
per track changed, (2) where SMR zones, if any, began and ended, and (3)
each failed read (rather than drives retrying accesses themselves).

Post by Scott Lurndal

Post by James Harris
As for caches, they don't help when the drive is busy, say with a large
file copy, because the drive never gets idle time in which to read ahead!

I think you'd be surprised at the difference in data rates from the heads
to the cache and between the cache and the host. Those tracks are pretty
dense nowadays.

What are drive-to-cache transfer rates these days? It used to be called
Sustained Data Transfer Rate (SDTR).

As long as the transfer rates from a drive's cache to the host are
faster (6Gbit/s for SATA, 12Gbit/s for SAS?) then a drive can still fall
behind.

[Scott Lurndal]

Post by James Harris

Post by Scott Lurndal

Post by James Harris

Post by Scott Lurndal
I probably should have said "may have been true when the average
seek time was 20 milliseconds and rotational latency was 8.something
milliseconds and disk drives had no on-board DRAM or SRAM caches.

The basic problem will exist whenever one has rotational and seek
latency. Any sectors which the drive has remapped require either
additional rotational delay or additional seek time or both.

One of our volume products is a disk drive controller (the chip
on the drive); They've advanced substantially since 1985. The
application doesn't have any need to care about where, on a drive,
a portion of a file exists. The operating system, file system driver,
host bus adapter and drive electronics are all conspiring against it.

If you are involved in making such drive controller chips perhaps you
can answer a question which has been bugging me for some time and I've
never found an answer to. Can modern drive controllers read from or
write to all heads in a cylinder at the same time - or do they have to
carry out IO for one head at a time, perhaps with some micro-seeking of
the actuator arm on each track?

I cannot answer in specifics, of course, as that's proprietary
information, but I will note that the controllers are highly
parallel System-on-Chip implementations.

Post by James Harris

Post by Scott Lurndal

Post by James Harris
By contrast, if the drive did not remap sectors but, instead, informed
the host where the bad sectors were then the host could account for that
when laying out data on disk, allowing IO to be significantly faster.

You'll need to back this assertion up with some actual real-world
numbers, I'm afraid.

Specific timings would depend on the drive model but I can reply with
some example figures to illustrate the point.

Your example timings seem to be 1990's timings. Progress has
intervened subsequently; features such as native command queuing
have significantly increased throughput. All without giving
the operating software visibility into the data organization
on the platter (with areal density of 625Gb/in2).

The average latency on a modern 7200rpm drive around 4ms, average seek
time is < 8.5ms. Significantly lss on a 10krpm drive.

Post by James Harris
The point I am making is that if the controller remaps bad sectors then
1. Any space reserved for bad sectors or bad tracks will still cost time
(even if the medium has no bad areas). Such space will not be occupied
so will reduce the overall data rate. If n% of a drive were reserved
then the data on the disk would essentially be readable a little under
n% slower - with exact timings depending on whether sectors, tracks or
cylinders were reserved and other factors.
2. Any remapped data will require additional time to
a) find out where the bad block has been remapped to
b) seek to the right place
c) wait for the data to pass under the head
d) seek back to where we came from for the next read
Let's say that would add 7 to 20 ms for each such read depending on
where the block had been remapped to.

Or you can just get an SSD or NVME device if you really
need such performance. I'd argue that there aren't any
applications that care about the miniscule additional latency
for a remapped spinning rust sector, especially if that the
latency is subsumed by other operations.

[Rod Pemberton]

On Tue, 2 Mar 2021 11:25:06 +0000

Post by James Harris
What I intend to show is that with remapped sectors there are several
sources of delay relative to what could be accomplished.

Um...

How do yo intend to force a drive to remap sectors so that you could
actually test this?

I.e., wouldn't this need to be a physical modification of the disk
platter(s)?

E.g., the last time I remember there being modifications made to
(removable) drive media were laser spot burns for copy protection:

https://diskpreservation.com/dp.php?pg=protection
https://en.wikipedia.org/wiki/Bit_nibbler

--

[James Harris]

Post by Rod Pemberton
On Tue, 2 Mar 2021 11:25:06 +0000

Post by James Harris
What I intend to show is that with remapped sectors there are several
sources of delay relative to what could be accomplished.

Um...
How do yo intend to force a drive to remap sectors so that you could
actually test this?

I think I meant "show by calculation" rather than by testing.

[Rod Pemberton]

On Thu, 25 Feb 2021 17:47:17 +0000

Post by James Harris

Post by Scott Lurndal
That may have been true in 1985. It's not worth the effort with
modern spinning rust.

Surely the effort depends on how files are intended to be used. And
rather than "spinning rust" modern hard drives are cutting edge.
Solid state has not yet come up with anything which is price
comparable. Even new typed of hard drive are hitting the market, e.g.

Prior to 2007, I always had a problem with having enough capacity. I
never had enough capacity to store files for daily usage and I never
had enough capacity for backups. CD-ROMs helped a lot with backups,
but didn't eliminate the issue as they weren't large enough.

Post 2007, I've had more than enough capacity, using a single small 64GB
SSD for daily usage, and an external USB hard drive for backups. I
haven't powered up the external drive in a while and don't recall it's
capacity, perhaps 1TB or 512GB, etc. Admittedly, I have had to clean
up some space on the 64GB SDD from time to time, which is why it's
replacement sitting here is a 512GB SSD.

The point being that the OS only needs so much capacity and daily use
files only need so much capacity. Therefore, I'll be selecting
smaller, faster, more modern drives, even if they're of lower capacity
and higher cost per byte, for the main boot and usage drive of any new
computer that I build. And, I'll only be using higher capacity, lower
cost per byte, older technology drives for backups. I still haven't
converted to dual RAID drives for speed, as everything is quick enough.

--

[James Harris]

Post by Rod Pemberton
On Thu, 25 Feb 2021 17:47:17 +0000

Post by James Harris

Post by Scott Lurndal
That may have been true in 1985. It's not worth the effort with
modern spinning rust.

Surely the effort depends on how files are intended to be used. And
rather than "spinning rust" modern hard drives are cutting edge.
Solid state has not yet come up with anything which is price
comparable. Even new typed of hard drive are hitting the market, e.g.

Prior to 2007, I always had a problem with having enough capacity. I
never had enough capacity to store files for daily usage and I never
had enough capacity for backups. CD-ROMs helped a lot with backups,
but didn't eliminate the issue as they weren't large enough.
Post 2007, I've had more than enough capacity, using a single small 64GB
SSD for daily usage, and an external USB hard drive for backups. I
haven't powered up the external drive in a while and don't recall it's
capacity, perhaps 1TB or 512GB, etc. Admittedly, I have had to clean
up some space on the 64GB SDD from time to time, which is why it's
replacement sitting here is a 512GB SSD.

It's interesting to compare storage requirements. I think I have
something like, in gigabytes

0.1 websites
0.3 project files
1.8 documents
10 photos
100 videos
100 download archive
132 music
11,000 TV recordings

Post by Rod Pemberton
The point being that the OS only needs so much capacity and daily use
files only need so much capacity. Therefore, I'll be selecting
smaller, faster, more modern drives, even if they're of lower capacity
and higher cost per byte, for the main boot and usage drive of any new
computer that I build. And, I'll only be using higher capacity, lower
cost per byte, older technology drives for backups. I still haven't
converted to dual RAID drives for speed, as everything is quick enough.

It's the 11TB and growing of TV recordings which makes it too expensive
for me to use SSD for everything. Otherwise, SSDs would be enough.

[Rod Pemberton]

On Sat, 27 Feb 2021 18:20:58 +0000

Post by James Harris
It's interesting to compare storage requirements. I think I have
something like, in gigabytes
0.1 websites
0.3 project files
1.8 documents
10 photos
100 videos
100 download archive
132 music
11,000 TV recordings

Wow, that "TV recordings" size seems huge! 11TB vs zero here. A CD-RW
(or even a VHS tape) seems to suffice here. We don't even use the DVR.

I messed up the counts below on the iso and pdf slightly, so I just
rounded them up. I have pdfs *everywhere* and didn't count a bunch,
e.g., too few per directory or too nested, but I also counted some from
extracted/expanded iso's. I'm counting my mistake as a wash. The
counts include files not in my DOS or Linux systems, but just on my
external USB backup. Some of the counts probably overlap, e.g., due to
pdfs everywhere, text in code sub-directories, etc ... I listed the
Linux and DOS sizes below, because I didn't include any OS software,
compiler software, or application software in the main list. There is
minimal overlap of the two systems, probably only the music files.
(in GBs)

0.01 text files (I've written on various topics)
0.17 my programming projects (*)
0.3 photos (family)
133 videos (mainly archive of a Youtube business guru) (**)
70 archive (data archive + text programming documents)
0.3 music (I prefer CD's, or Youtube or streaming)
0 TV recordings

10 iso CD-ROM images Linux and Windows 98/SE
20 pdf files (on everything, but mostly programming docs)

0.90 code porting projects
0.17 my other projects (non-programming)

44GB entire Linux system (80% of 64GB SSD)
33GB entire backup of DOS system

(*) This includes many files in sub-directories which are not mine, but
are related to the projects, e.g., data & code, probably high by 0.070
or so ...

(**) The vast majority of stuff is programming related, except for the
pdf's, which is probably about 60% programming docs. Without the
videos of the business guru, I'd have only 12GB of videos. The text
programming documents are abut 10GB. A data archive I downloaded and
don't need but didn't delete comprises most of that 70GB.

About 27% of the 1TB external USB hard disk (NTFS) is in use, but that
includes multiple backups of the Linux and DOS systems and some other
archived data. I only have small part of my DOS system installed on a
bootable memory card, which is too small. So, I've been avoiding using
it. I still ... sigh ... haven't gotten around to upgrading my drives
although I've had the new drives sitting here for a few years.

Post by James Harris
It's the 11TB and growing of TV recordings which makes it too
expensive for me to use SSD for everything. Otherwise, SSDs would be
enough.

Are these TV recordings on your computer hard disk, an external USB hard
disk, or a DVR? If I was going to record TV shows, I'd get a large
capacity DVR and be done with it.

--

[James Harris]

Post by Rod Pemberton
On Sat, 27 Feb 2021 18:20:58 +0000

Post by James Harris
It's interesting to compare storage requirements. I think I have
something like, in gigabytes
0.1 websites
0.3 project files
1.8 documents
10 photos
100 videos
100 download archive
132 music
11,000 TV recordings

Wow, that "TV recordings" size seems huge! 11TB vs zero here. A CD-RW
(or even a VHS tape) seems to suffice here. We don't even use the DVR.

In terms of raw space it's not a lot these days when one could record
that much on a single disk but it is certainly a lot of space compared
with everything else I have.

Plus it needs to be backed up which is why I recently bought 2x8TB
drives which are in another machine.

Having that much recorded is a result of having the TV-recorder machine
running for something like 15 years. I think I put it together around 2006.

Post by Rod Pemberton
I messed up the counts below on the iso and pdf slightly, so I just
rounded them up. I have pdfs *everywhere* and didn't count a bunch,

Similarly, I probably have quite a few files which aren't in the above
figures because they are scattered around. One task I have on is to
consolidate all of them together with suitable on-site and off-site
backups.

...

Interestingly, with the exception of the TV recordings ISTM your storage
requirements (now snipped) and mine are broadly similar.

Post by Rod Pemberton

Post by James Harris
It's the 11TB and growing of TV recordings which makes it too
expensive for me to use SSD for everything. Otherwise, SSDs would be
enough.

Are these TV recordings on your computer hard disk, an external USB hard
disk, or a DVR? If I was going to record TV shows, I'd get a large
capacity DVR and be done with it.

If setting up a TV recorder today one could use the much larger hard
drives which are economic now - e.g. an initial 4TB for recordings and
an 8TB for backups - but back in the day I bought a fairly unusual
chassis in that it had eight external 5.25 slots so I could have plenty
of hard disks which were economical at the time.

I currently have in those eight 5.25 slots the following.

6 x trayless 3.5 sata bays
1 x 6-bay 2.5 sata slots
1 x optical drive

The 3.5-inch trayless bays are all occupied. They hold data drives of
various sizes. The 6-bay unit has only the 2.5-inch SSD boot/system
drive in it at present.

The machine acts as a video recorder, video player (it's connected to
the TV) and file server though after my experience with bad RAM I have
been looking to see whether there's a cost effective way to make a
machine with ECC memory to replace it. The CPU in it is very old, now,
and slow by modern standards and isn't supported by some 64-bit OSes so
it has long been due an upgrade.

[Bernhard Schornak]

Post by James Harris
...

Post by Bernhard Schornak

Post by James Harris
If the OS were able to handle bad sectors it could, instead, allow the much smaller delays of
simple rotation past bad sectors. No need to wait for rotation to where the spare sectors are and
no need for any head movement at all.
2. Since, IIRC, ATA2 an OS doesn't even get to read a disk without retries. That option was removed.

Assignment of sectors is - and always was - a hardware task.
There is no OS keeping track of sectors and such. All modern
OS'es access drives via LBAs, where the physical position of
each sector is transparent to the OS. It would slow down any
data transfer, if a OS interfered with the drive controller,
telling the drive where to write which data. Modern transfer
is done via memory. The OS just tells the drive where to get
how much data from (writes), or where to store how much data
to (reads).

I'm sorry, Bernhard, but I completely disagree with you on this.

People do have (and always did have) different opinions here and
there - that's absolutely nothing to be sorry about! ;)

Post by James Harris
What you say is essentially true of
SSDs where there is neither rotational nor actuator delay but if we want performance on disks we
still need to think about /where/ sectors are physically located in relation to each other.
That's one reason why modern file systems such as ext4 allocate space for files in 'extents'. (IBM
was doing this on mainframes in the 1960s.) It is faster to read a disk cylinder by cylinder and
track by track than it is to have sectors scattered around.

Extents have nothing to do with physical addressing - all modern
file systems use LBA addressing. The old C/H/S scheme does *not*
represent the real physical location, because there are not that
much heads on a drive than reported, anyway.

https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Extents

Post by James Harris

Post by Bernhard Schornak

Post by James Harris

Post by Bernhard Schornak
Lower sector counts towards the centers of the
platters was introduced long time ago. Only *very* old HDDs
have equal sector counts for all cylinders.

Indeed. Where the resulting zones begin and end is, IMO, something else an OS should be made
aware of.

Why? No OS can perform such tasks better or even faster than
the specialised hardware on the drive itself. It's a part of
any HDD development, to optimise access on hardware level.

Because a hard drive does not and cannot know how the blocks it is passed by the OS are intended to
be used. An OS (or a storage manager) will be in a position to know which block comes after another
in a file and can be told or can find out by learning how files are accessed.
Put simply, files which don't need speed could go at the slow end of the drive near the spindle
whereas files which need faster read/write times could go nearer the edge. No disk drive can know
such things.

That's besides the real story. The OS tells the drive which LBAs
it shall read from or write to the medium. The OS neither cares,
where addressed LBAs are located, nor how or in which order they
are written. The drive electronics will decide that (specialised
control circuits can do this much better than any OS developer).

What you have in mind ist the burst capability of modern drives,
where the FS allocates large blocks of memory for very fast data
transfer from/to the drive, which has nothing to do with CHS/LBA
addressing, either.

I bet, that no modern filesystem uses CHS, 'cause LBA addressing
is less complicated and PCIe does not provide any fast CHS-based
function for bursts and such.


Greetings from Augsburg

Bernhard Schornak

[Bernhard Schornak]

Post by James Harris
Put simply, files which don't need speed could go at the slow end of the drive near the spindle
whereas files which need faster read/write times could go nearer the edge. No disk drive can know
such things.

The LBA number gives us a faint hint where the corresponding data
reside physically - as it is crucial to read and write allocation
data (FAT or whatever you want to name it) very fast, they should
be stored within the first LBAs of the drive, which is determined
by the file system. If access speed does not really matter, those
data can be stored at the highest LBAs downwards, which should be
determined by the FS, as well.

Nevertheless, no FS should ever attempt to replace internal drive
electronics - if you did that, you had to write one FS for *each*
HDD model and version on the market, which is not very realistic.
Better trust our HDD vendors and let their drives do the job they
were designed for.


Greetings from Augsburg

Bernhard Schornak

[James Harris]

...

Post by Bernhard Schornak

Post by James Harris
Put simply, files which don't need speed could go at the slow end of
the drive near the spindle whereas files which need faster read/write
times could go nearer the edge. No disk drive can know such things.

That's besides the real story. The OS tells the drive which LBAs
it shall read from or write to the medium. The OS neither cares,
where addressed LBAs are located, nor how or in which order they
are written.

It matters for applications which need best performance. If an app
requires uncached LBAs 1000, 1001, and 1002, say, then they would be
read fastest if they were in adjacent sectors.

On the other hand, if block 1001 had been remapped by the drive to a
different cylinder then reading the three blocks would take much longer.
It really does matter where blocks are stored relative to each other.

Hence my preference for the OS to know that block 1001 was unusable.
They it could record the blocks of the file on LBAs 1000, 1002 and 1003
and get best performance. It is unfortunate that disk drives hide media
flaws.

[Scott Lurndal]

Post by James Harris
...

Post by Bernhard Schornak

Post by James Harris
Put simply, files which don't need speed could go at the slow end of
the drive near the spindle whereas files which need faster read/write
times could go nearer the edge. No disk drive can know such things.

That's besides the real story. The OS tells the drive which LBAs
it shall read from or write to the medium. The OS neither cares,
where addressed LBAs are located, nor how or in which order they
are written.

It matters for applications which need best performance. If an app
requires uncached LBAs 1000, 1001, and 1002, say, then they would be
read fastest if they were in adjacent sectors.

Not necessarily. Back in the day, the packs would have to be formatted
with interleaved sectoring to get any form of throughput on multi-sector
reads.

Today, the drive might read the whole track into on-drive DRAM cache
and serve subsequent I/O requests from there, and if it detects a sequential
access pattern, will preload the next track, or group of sectors,
into the cache (depending on cache size).

That said, the application generally doesn't have complete control of
the drive, and other applications and the operating system will be
interleaving I/O requests with the application requests. Hence, the
OS handles buffering in the file cache and some will detect sequential
access patterns and fill the OS file cache with anticipatory requests.
The OS will also order requests to limit head movement if
certain I/O schedulers (linux) are configured, but this is mostly
left over from the olden days when elevator algorithms were all in vogue.

[wolfgang kern]

Post by James Harris
...

Post by Bernhard Schornak

Post by James Harris
Put simply, files which don't need speed could go at the slow end of
the drive near the spindle whereas files which need faster read/write
times could go nearer the edge. No disk drive can know such things.

That's besides the real story. The OS tells the drive which LBAs
it shall read from or write to the medium. The OS neither cares,
where addressed LBAs are located, nor how or in which order they
are written.

It matters for applications which need best performance. If an app
requires uncached LBAs 1000, 1001, and 1002, say, then they would be
read fastest if they were in adjacent sectors.
On the other hand, if block 1001 had been remapped by the drive to a
different cylinder then reading the three blocks would take much longer.
It really does matter where blocks are stored relative to each other.
Hence my preference for the OS to know that block 1001 was unusable.
They it could record the blocks of the file on LBAs 1000, 1002 and 1003
and get best performance. It is unfortunate that disk drives hide media
flaws.

an OS can use info from SMART to find physical consecutive good blocks.
__
wolfgang

[James Harris]

Post by wolfgang kern

Post by James Harris
...

Post by Bernhard Schornak

Post by James Harris
Put simply, files which don't need speed could go at the slow end of
the drive near the spindle whereas files which need faster
read/write times could go nearer the edge. No disk drive can know
such things.

That's besides the real story. The OS tells the drive which LBAs
it shall read from or write to the medium. The OS neither cares,
where addressed LBAs are located, nor how or in which order they
are written.

It matters for applications which need best performance. If an app
requires uncached LBAs 1000, 1001, and 1002, say, then they would be
read fastest if they were in adjacent sectors.
On the other hand, if block 1001 had been remapped by the drive to a
different cylinder then reading the three blocks would take much
longer. It really does matter where blocks are stored relative to each
other.
Hence my preference for the OS to know that block 1001 was unusable.
They it could record the blocks of the file on LBAs 1000, 1002 and
1003 and get best performance. It is unfortunate that disk drives hide
media flaws.

an OS can use info from SMART to find physical consecutive good blocks.

That would be useful. How does it work?

[wolfgang kern]

Post by James Harris

Post by wolfgang kern
an OS can use info from SMART to find physical consecutive good blocks.

That would be useful. How does it work?

I lost my link collection, search for "S.M.A.R.T"
__
wolfgang

[James Harris]

Post by James Harris

Post by wolfgang kern
an OS can use info from SMART to find physical consecutive good blocks.

That would be useful. How does it work?

I lost my link collection,  search for "S.M.A.R.T"

AFAICS SMART will report the total number of bad blocks but not,
unfortunately, where they or the good blocks are physically.

[wolfgang kern]

Post by James Harris

Post by James Harris

Post by wolfgang kern
an OS can use info from SMART to find physical consecutive good blocks.

That would be useful. How does it work?

I lost my link collection,  search for "S.M.A.R.T"

AFAICS SMART will report the total number of bad blocks but not,
unfortunately, where they or the good blocks are physically.

if you know where the bad blocks are then .... :)
__
wolfgang

[Rod Pemberton]

On Mon, 22 Feb 2021 11:45:29 +0000

Post by James Harris

Post by Bernhard Schornak

Post by James Harris
If the OS were able to handle bad sectors it could, instead, allow
the much smaller delays of simple rotation past bad sectors. No
need to wait for rotation to where the spare sectors are and no
need for any head movement at all.
2. Since, IIRC, ATA2 an OS doesn't even get to read a disk without
retries. That option was removed.

Assignment of sectors is - and always was - a hardware task.
There is no OS keeping track of sectors and such. All modern
OS'es access drives via LBAs, where the physical position of
each sector is transparent to the OS. It would slow down any
data transfer, if a OS interfered with the drive controller,
telling the drive where to write which data. Modern transfer
is done via memory. The OS just tells the drive where to get
how much data from (writes), or where to store how much data
to (reads).

I'm sorry, Bernhard, but I completely disagree with you on this. What
you say is essentially true of SSDs where there is neither rotational
nor actuator delay but if we want performance on disks we still need
to think about /where/ sectors are physically located in relation to
each other.

Why can't the hardware do keep track of "/where/ sectors are physically
located in relation to each other"? I see no reason it can't.

If they installed a processor, disk operating system (DOS), and ram on
the drive, much like they did for old Commodore CBM 1541 drives, they
should be able to do that.

Post by James Harris

Post by Bernhard Schornak

Post by James Harris

Post by Bernhard Schornak
Lower sector counts towards the centers of the
platters was introduced long time ago. Only *very* old HDDs
have equal sector counts for all cylinders.

Indeed. Where the resulting zones begin and end is, IMO, something
else an OS should be made aware of.

Why? No OS can perform such tasks better or even faster than
the specialised hardware on the drive itself. It's a part of
any HDD development, to optimise access on hardware level.

Because a hard drive does not and cannot know how the blocks it is
passed by the OS are intended to be used.

Are you saying the hard disk couldn't keep track of which sectors are
loaded from it according to time since power-up and by count of times
read or written?

(Sure it could, if it was designed to do so. It's just that they
aren't designed to do so, because they're cheaper that way.)

Post by James Harris
An OS (or a storage
manager) will be in a position to know which block comes after
another in a file and can be told or can find out by learning how
files are accessed.

What do you think a DOS is and does? (disk operating system)

Of course, M$ sort of corrupted the meaning of "DOS" with their OS
called MS-DOS, which was both an OS and a DOS integrated together. The
Commodore C64 had a separate OS and DOS which ran on separate
processors/computers. The C64 computer ran the OS on a 6510. The
1541 disk drives - another computer - ran the DOS on a 6502 (IIRC).
I.e., there is no reason that a drive couldn't have an embedded 486, an
OS, specifically a DOS, or even an entire SOC x86 PC running
Linux/Windows, perhaps stripped down, or an embedded Raspberry Pi
running Linux, etc.

Post by James Harris
Put simply, files which don't need speed could go at the slow end of
the drive near the spindle whereas files which need faster read/write
times could go nearer the edge. No disk drive can know such things.

If it had an embedded computer, it could.

--

[James Harris]

Post by Rod Pemberton
On Mon, 22 Feb 2021 11:45:29 +0000

Post by James Harris

Post by Bernhard Schornak

Post by James Harris
If the OS were able to handle bad sectors it could, instead, allow
the much smaller delays of simple rotation past bad sectors. No
need to wait for rotation to where the spare sectors are and no
need for any head movement at all.
2. Since, IIRC, ATA2 an OS doesn't even get to read a disk without
retries. That option was removed.

Assignment of sectors is - and always was - a hardware task.
There is no OS keeping track of sectors and such. All modern
OS'es access drives via LBAs, where the physical position of
each sector is transparent to the OS. It would slow down any
data transfer, if a OS interfered with the drive controller,
telling the drive where to write which data. Modern transfer
is done via memory. The OS just tells the drive where to get
how much data from (writes), or where to store how much data
to (reads).

I'm sorry, Bernhard, but I completely disagree with you on this. What
you say is essentially true of SSDs where there is neither rotational
nor actuator delay but if we want performance on disks we still need
to think about /where/ sectors are physically located in relation to
each other.

Why can't the hardware do keep track of "/where/ sectors are physically
located in relation to each other"? I see no reason it can't.

If the hard drives were aware of how sectors were likely to be read in
relation to each other then I agree with you that this could be handled
by the drive.

However, skipping a few bad blocks would be fairly easy to do in OS
software so why build a complex disk drive?

Having the OS lay out the sectors of a file would also be more flexible.

Post by Rod Pemberton
If they installed a processor, disk operating system (DOS), and ram on
the drive, much like they did for old Commodore CBM 1541 drives, they
should be able to do that.

Agreed, with caveats as above.

Post by Rod Pemberton

Post by James Harris

Post by Bernhard Schornak

Post by James Harris

Post by Bernhard Schornak
Lower sector counts towards the centers of the
platters was introduced long time ago. Only *very* old HDDs
have equal sector counts for all cylinders.

Indeed. Where the resulting zones begin and end is, IMO, something
else an OS should be made aware of.

Why? No OS can perform such tasks better or even faster than
the specialised hardware on the drive itself. It's a part of
any HDD development, to optimise access on hardware level.

Because a hard drive does not and cannot know how the blocks it is
passed by the OS are intended to be used.

Are you saying the hard disk couldn't keep track of which sectors are
loaded from it according to time since power-up and by count of times
read or written?

No, it's the /sequence/ in which sectors will be read which matters.

Post by Rod Pemberton
(Sure it could, if it was designed to do so. It's just that they
aren't designed to do so, because they're cheaper that way.)

Post by James Harris
An OS (or a storage
manager) will be in a position to know which block comes after
another in a file and can be told or can find out by learning how
files are accessed.

What do you think a DOS is and does? (disk operating system)

As in my example of another reply, if part of a file is to be stored in
three blocks starting at LBA 1000 and yet the space where block 1001
would be stored is unusable it would be effecient to store the three
blocks at LBAs 1000, 1002, 1003 - assuming that they and the damaged
1001 are physically adjacent on a track; unfortunately, disk drives
usually remap 1001 to somewhere else and pretend to the OS that the
block is OK.

Post by Rod Pemberton
Of course, M$ sort of corrupted the meaning of "DOS" with their OS
called MS-DOS, which was both an OS and a DOS integrated together. The
Commodore C64 had a separate OS and DOS which ran on separate
processors/computers. The C64 computer ran the OS on a 6510. The
1541 disk drives - another computer - ran the DOS on a 6502 (IIRC).
I.e., there is no reason that a drive couldn't have an embedded 486, an
OS, specifically a DOS, or even an entire SOC x86 PC running
Linux/Windows, perhaps stripped down, or an embedded Raspberry Pi
running Linux, etc.

Post by James Harris
Put simply, files which don't need speed could go at the slow end of
the drive near the spindle whereas files which need faster read/write
times could go nearer the edge. No disk drive can know such things.

If it had an embedded computer, it could.

It would need an embedded computer ... and a way to give it lots of
knowledge about intended use cases!

[Rod Pemberton]

On Thu, 25 Feb 2021 18:08:15 +0000

Post by James Harris
As in my example of another reply, if part of a file is to be stored
in three blocks starting at LBA 1000 and yet the space where block
1001 would be stored is unusable it would be effecient to store the
three blocks at LBAs 1000, 1002, 1003

It might be efficient to do so. You don't know if the damaged block
1001 is relocated somewhere on the disk's platters such as outer/inner
tracks, or relocated to some flash memory. If one block is bad,
adjacent blocks are likely bad too. I.e., the disk controller may
relocate an entire track.

Post by James Harris
- assuming that they and the
damaged 1001 are physically adjacent on a track; unfortunately, disk
drives usually remap 1001 to somewhere else and pretend to the OS
that the block is OK.

s/disk drives/hard drives/

Ok.


(I snipped too much context here, but I'm not fixing it.)

Post by James Harris
and a way to give it lots of
knowledge about intended use cases!

I would believe that actual use cases would work.

When I start up Linux, it

a) loads the boot sector
b) loads the boot loader
c) loads the OS
d) loads the GUI
e) then, I load something, usually Firefox, and a couple terminals ...

This happens like 98% of the time.


Did you ever use Windows 'defrag' with Windows 98/SE/ME? It always
attempted to move the most loaded/used sectors to the lowest blocks.
The OS software was likely keeping track of what loaded, but I see no
reason hardware couldn't do the same. The hardware doesn't need to know
the files, as this can be block-oriented. It just needs to know the
order of the blocks loaded, which it gets when the blocks are
requested, in order.

--

[James Harris]

On 26/02/2021 08:08, Rod Pemberton wrote:

...

Post by Rod Pemberton
When I start up Linux, it
a) loads the boot sector
b) loads the boot loader
c) loads the OS
d) loads the GUI
e) then, I load something, usually Firefox, and a couple terminals ...
This happens like 98% of the time.
Did you ever use Windows 'defrag' with Windows 98/SE/ME? It always
attempted to move the most loaded/used sectors to the lowest blocks.

Makes sense, but see below.

Fortunately, with solid-state storage such concerns are becoming a thing
of the past.

Post by Rod Pemberton
The OS software was likely keeping track of what loaded, but I see no
reason hardware couldn't do the same. The hardware doesn't need to know
the files, as this can be block-oriented. It just needs to know the
order of the blocks loaded, which it gets when the blocks are
requested, in order.

The hardware could, theoretically, build up a picture of a typical use
case and that would allow it to minimise /overall/ IO time but don't
forget that the hardware will not know what accesses are most important
to the user. It may be that the user needs some operation which does not
run frequently to be as fast as possible and the hardware (firmware)
will never be able to guess at that.

So again, AISI it would be better for disk drives to allow the OS to
control file layout rather than remapping sectors to make up for
unusable areas of the medium. The best policy for drives would be to be
honest about their geometry and their flaws....!

[Bernhard Schornak]

Post by James Harris
That's one reason why modern file systems such as ext4 allocate space for files in 'extents'. (IBM
was doing this on mainframes in the 1960s.) It is faster to read a disk cylinder by cylinder and
track by track than it is to have sectors scattered around.

Greetings from Augsburg

Bernhard Schornak

[wolfgang kern]

On 22.02.2021 12:45, James Harris wrote:
...

Post by James Harris
Because a hard drive does not and cannot know how the blocks it is
passed by the OS are intended to be used. An OS (or a storage manager)
will be in a position to know which block comes after another in a file
and can be told or can find out by learning how files are accessed.
Put simply, files which don't need speed could go at the slow end of the
drive near the spindle whereas files which need faster read/write times
could go nearer the edge. No disk drive can know such things.

why bother with physical disk organization ?
FAT exFAT NTFS Loonix gor one thing in common: heavy fragmentation.

so as long you don't use a File System similar to type 4B (kesys) there
will always be a good chance that data are distributed all over the HD.
__
wolfgang
I once needed consecutive LBA for external high speed data acquisition.

[James Harris]

Post by wolfgang kern
...

Post by James Harris
Because a hard drive does not and cannot know how the blocks it is
passed by the OS are intended to be used. An OS (or a storage manager)
will be in a position to know which block comes after another in a
file and can be told or can find out by learning how files are accessed.
Put simply, files which don't need speed could go at the slow end of
the drive near the spindle whereas files which need faster read/write
times could go nearer the edge. No disk drive can know such things.

why bother with physical disk organization ?
FAT exFAT NTFS Loonix gor one thing in common: heavy fragmentation.

Don't use such systems!

Post by wolfgang kern
so as long you don't use a File System similar to type 4B (kesys) there
will always be a good chance that data are distributed all over the HD.
__
wolfgang
I once needed consecutive LBA for external high speed data acquisition.

LBAs are just addresses. They may not be mapped to consecutive physical
blocks.

In fact, drives have long remapped even CHS addresses from logical to
physical. Our erstwhile access to /real/ cylinders, tracks and sectors
has, unfortunately for performance, been taken away.

As I tried to explain in a reply (qv) earlier today to Scott the ATA
standards people have for too long been obsessed with providing an easy
programming environment but at the same time made it harder and harder
for an OS to get the best performance out of a drive.

I don't know about SCSI. That may be better or it may have gone the same
way as ATA.

[Rod Pemberton]

On Sat, 20 Feb 2021 16:52:08 +0000
James Harris <***@gmail.com> wrote:

<snip>

Post by James Harris
1. Most HDDs hide bad sectors from the OS. For one thing they waste
space by setting aside spare sectors and cylinders. Worse from a
performance perspective, they remap bad sectors to the spares. That
hurts performance because it adds both rotational delay and head
movements that the OS is kept in the dark about.
A drive's internal caches help a lot but it would be better to have
both the caches /and/ for the OS to know where the bad sectors were.
If the OS were able to handle bad sectors it could, instead, allow
the much smaller delays of simple rotation past bad sectors. No need
to wait for rotation to where the spare sectors are and no need for
any head movement at all.
2. Since, IIRC, ATA2 an OS doesn't even get to read a disk without
retries. That option was removed.
Indeed. Where the resulting zones begin and end is, IMO, something
else an OS should be made aware of.

I'm thinking the OS should move away from management of tracks and
sectors, towards managing only directories and complete files. Then,
the hard drive can optimally manage the layout of data on the disk.
The advances in hardware and software clearly allow for this. So, the
OS would request a directory from the disk, and then request the file
it wants, perhaps by name or by serial number or checksum, or request a
sub-directory etc. The old CBM drives had their own operating system
and commands. So, today, I see no reason why a storage device couldn't
be as powerful as an old 486, complete with a full OS, not just DOS,
lots of electronics to manage everything, plenty of large buffers,
self-installing boot code, format-on-write, etc.

--

[Rod Pemberton]

On Sat, 20 Feb 2021 02:21:23 -0500

Post by Rod Pemberton
On Fri, 19 Feb 2021 14:07:46 +0000

Post by James Harris
2x8TB Seagate SMR data drives

I haven't kept up with hard disk technology in decades. Was this SMR
technology the reason you were asking about differences in the read
and write head widths a while back? When I searched for SMR, a short
article on PMR versus SMR came up. PMR was what I learned about
decades ago for floppies and hard disks. SMR is novel, but obviously,
you can't rewrite a track easily, as it will overwrite data on the
adjacent track. I'm still not sure why they don't or can't figure out
how to make the write head as narrow as the read head.

Apparently, it was LMR, not PMR which I learned of long ago ...

--

[Rod Pemberton]

On Tue, 16 Feb 2021 14:52:45 +0000

Post by James Harris

Post by James Harris
Well, here's a strange one. After I copied a file from one drive to
another I compared them and found them to be different! :-(
    cp -i /mnt/backups0/disk.img /mnt/backups1/work.img
Only one bit changed. A byte about 1.3% into the file was
originally 0x70 but in the copy it became 0x71.

...
Thanks for the replies so far. I've read them but I haven't replied
yet as I am not sure what to say! What I have done is run the copy a
few more times and, to my astonishment, the first error was not a
simple glitch: each run has ended up with mismatches!

Ruh Roh!

Post by James Harris
In case it was a problem with cp I tried copying the file using rsync
but that also had a problem as follows.

Two commands? Well, that's far less likely to be the software ...

Post by James Harris
I'm still trying to work out where this is happening. I'll run some
more tests to see if I can narrow it down a little.

Personally, I'd try to get a smaller file that consistently fails.

Does your copy always go the same direction? e.g., drive A to B

What happens if you reverse direction?

Are you able to test a third drive?

What happens if you tar or gzip the file first? Still corrupt?

Are any of these external USB drives? Does it have a hard disk or
solid-state disk? New? Old? Is it a Western Digital? FYI, I'm
unable to boot this version of Linux from USB. Could it be a USB
issue? BIOS legacy boot drive emulation issue?

What happens if you reset your BIOS settings to default? What happens
if you lock the BIOS settings to safe speeds for memory bus and video?
What happens if you turn off processor throttling and overclocking?

For now, I'm going to assume that you checked the image mounting and it
was unmounted.

--

[James Harris]

Post by James Harris

Post by James Harris
Well, here's a strange one. After I copied a file from one drive to
another I compared them and found them to be different! :-(

...

Post by James Harris
     cp -i /mnt/backups0/disk.img /mnt/backups1/work.img
Only one bit changed. A byte about 1.3% into the file was originally
0x70 but in the copy it became 0x71.

...
Thanks for the replies so far. I've read them but I haven't replied yet
as I am not sure what to say!

After loads of tests I finally have something to report back. :-)

All my copy tests were inconclusive but the problems seem increasingly
likely to have been caused by a faulty 2GB RAM module (one of two in the
machine).

Most Memtest86+ tests didn't see any problem at all but one of its
tests, the random-number sequence, reported one error when run overnight.

Notably, this morning I (hopefully successfully) got memtest to run its
random-number test repeatedly on just the 16-megabyte chunk of memory
containing the reported address and yet although I let it scan the range
over 500 times it did not find any error. (I guess it's possible that it
does not report an address which it has already reported.)

After a reboot memtest did find the same error in the same place.
Further, after removing one of the two DIMMs memtest found an error in
an address which was exactly half the initially failing address. All of
that makes perfect sense so I am pretty confident that the error is in
the DIMM which I have now removed.

I'll leave memtest running against the other DIMM for a while as a check
but if it seems OK I am thinking to try to run the box on just the one
DIMM for now and have sent off for a full set (which will double the
machine's RAM from 4GB to 8GB).

It's been a curious challenge because it was so intermittent and hard to
detect.

The more interesting question is what an OS could do about such a
problem. Even memtest86+ had trouble finding it. Any ideas?

[James Harris]

Post by James Harris

Post by James Harris

Post by James Harris
Well, here's a strange one. After I copied a file from one drive to
another I compared them and found them to be different! :-(

...

Post by James Harris
     cp -i /mnt/backups0/disk.img /mnt/backups1/work.img
Only one bit changed. A byte about 1.3% into the file was originally
0x70 but in the copy it became 0x71.

...
Thanks for the replies so far. I've read them but I haven't replied
yet as I am not sure what to say!

After loads of tests I finally have something to report back. :-)
All my copy tests were inconclusive but the problems seem increasingly
likely to have been caused by a faulty 2GB RAM module (one of two in the
machine).

On the "increasingly likely" comment the reasons are as follows.

Although most of the memtests found no error the two which did reported
the problem as being in exactly the same place, bit 0 of the byte at
address 0x015a5d02.

In both cases memtest found the bit to be 1 when it should have been 0.

All of the errors found in the file compares were of a bit 0 changing
from 0 to 1.

Further, the /offsets/ of the errors show a pattern. Converting file
offsets to hex gives these offsets:

0x0d_0713_dd02
0x1f_ba12_6d02
0x36_0562_1d02
0x54_7865_1d02
0x4e_bdf3_3d02

The slipper fits!

Note the d02 at the end of not just all of those but also of the memory
address, above. That's what one would expect if the OS had loaded the
blocks of the file with at least 4k (0x1000) alignment - which is very
likely.

Hence I'm increasingly confident that this fault has been tracked down.
Was quite time consuming, though!

I would rather that the OS had identified the fault for me...!

[Rod Pemberton]

On Fri, 19 Feb 2021 11:01:27 +0000

Post by James Harris

Post by James Harris

Post by James Harris
Well, here's a strange one. After I copied a file from one drive
to another I compared them and found them to be different! :-(

...

Post by James Harris
     cp -i /mnt/backups0/disk.img /mnt/backups1/work.img
Only one bit changed. A byte about 1.3% into the file was
originally 0x70 but in the copy it became 0x71.

...
Thanks for the replies so far. I've read them but I haven't replied
yet as I am not sure what to say!

No need.

Post by James Harris
After loads of tests I finally have something to report back. :-)
All my copy tests were inconclusive but the problems seem
increasingly likely to have been caused by a faulty 2GB RAM module
(one of two in the machine).

Yeah, I have to blow the dust off of the memory chips in this machine's
DIMMs about every six months or so. I usually find that the cpu fan
and heat sink needs unclogged too. I'm not sure if this ever caused
any data loss or corruption, but the machine will act glitchy when the
heatsinked DIMMs are clogged, as Firefox's tendency is to consumes all
my available memory. I think Firefox wants 8GB while I only have 4GB.
Unfortunately, the cpu heatsink fins exhaust their hot air from the cpu
fan onto the heatsinked DIMMs, due to poor choice of design orientation
and/or location ...

I've been checking that the fans are all spinning too, as the one in
the power supply stopped rotating about a year ago. It was installed
upside down from the factory ... (Fans should always push air onto a
surface to cool it, and not be used to pull air.) I had to remove it,
pull the fan, clean and re-lubricate the bearings, and flip it over.
Now, the bearings shouldn't need lubrication anymore since they can't
drain/leak, and the power supply should be cooler while operating.

--

[James Harris]

On 20/02/2021 07:20, Rod Pemberton wrote:

...

Post by Rod Pemberton
as Firefox's tendency is to consumes all
my available memory. I think Firefox wants 8GB while I only have 4GB.

I find Firefox consumes more and more memory as long as it's running no
matter how much RAM there is. I have to shut it down and restart it from
time to time.

https://en.wikipedia.org/wiki/Memory_leak

[wolfgang kern]

Post by James Harris
...

Post by Rod Pemberton
as Firefox's tendency is to consumes all
my available memory.  I think Firefox wants 8GB while I only have 4GB.

I find Firefox consumes more and more memory as long as it's running no
matter how much RAM there is. I have to shut it down and restart it from
time to time.
  https://en.wikipedia.org/wiki/Memory_leak

yeah, mozilla firefox and thunderbird became PITA with the recent
updates. HUGE, STUPID and BUGGY as if Bill Gates made it.
I remove the sticky parts in task-manager (view all users) often.
__
wolfgang