From mboxrd@z Thu Jan 1 00:00:00 1970 From: dave@horsfall.org (Dave Horsfall) Date: Mon, 22 Feb 2016 12:58:35 +1100 (EST) Subject: [TUHS] Unix v6 File System information In-Reply-To: <20160221172101.GH2332@mercury.ccil.org> References: <20160221114412.62D8B18C0F6@mercury.lcs.mit.edu> <20160221172101.GH2332@mercury.ccil.org> Message-ID: 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."