22 Feb
2016
22 Feb
'16
7:58 a.m.
On Sun, 21 Feb 2016, John Cowan wrote:
The RSX-11 file system, later known as ODS-1, was
similar in this
respect: the root directory contained entries for the bad-block file
(BADBLK.SYS), the inode-file-equivalent (INDEXF.SYS) and even itself
(000000.DIR).
Ah, but my idea (never implemented, because disk drives got beyond ye olde
RK-05) was that it never appeared as a directory entry.
Thus, Shell utilities would never see those blocks, and "dump" would never
see them either, because it "knew" that inodes started at 1... The only
way you would see them was via a raw disk copy.
But, as I said, times moved on from the RK-05 (and the RP-04, and other
air-exposed packs), thus my idea was dead.
Mind you, these "IBM PC" thingie drives are pretty awful at times :-)
And as for SSDs, don't ask, because they won't tell you about bad blocks;
they are merely quietly remapped on the side[*].
[*]
I've been doing a fair bit of reading on these things. Did you know that,
for example, up to half the available silicon is dedicated towards the bad
sectors that always crop up? And the thing won't even tell you when it
remaps a bad sector[#]? It's because, amongst other things, that what you
and I think of as a "block" is actually a huge chunk, so one bad bit in a
cell could cause up to something like 64KB to be remapped.
In other words, if you knew how SSDs worked, you wouldn't stake your balls
on them; they're just a large USB stick (and we know how cheaply they're
made).
[#]
Because the proprietary on-board controller is saying "Everything's OK,
boss!" whilst madly emptying a swampful of alligators.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."