It is my understanding that modern magnetic media really hides what's going on at the platter level. This is not like the old days with MFM or RLL hard drives (before IDE). It is my understanding the modern disk controllers maintain their own mappings, and can in fact remap bad sectors on their own. I didn't think any of this information was available at the operating system level to the extent that it can be usefully modified outside the drive's own logic.
It surprises me, because the drive has much more knowledge of typical access patterns combined with the hardware characteristics, so could easily do things like store two copies of some data so that whichever is closest to the read head can be read. I guess manufacturers just aren't interested in speed optimizations anymore now that SSD's exist.
(also https://en.wikipedia.org/wiki/The_Story_of_Mel for background)
But isn’t this slowing things down by shoving all the data out toward track zero? I thought that for head movement efficiency and speed the ideal was to put everything as close to track 18 as possible.
> Every file is stored as a linked list. Every block holds the track/sector tuple of the next block in its first two bytes, followed by 254 data bytes.
On ZX Spectrum, TR-DOS, one of available disk OSes, didn't support file fragmentation at all: files occupied consecutive sectors, and new files could be written only to free space at the end of floppy. Once file is deleted, it continued to occupy space. Instead of defragmentation, there was "MOVE" command that packed files together by moving towards start of the disk to fill freed space.
https://www.worldofspectrum.org/pub/sinclair/hardware-info/B... (section 9.3)
(I don't know, however, how ZX Spectrum +3 filesystem works (another disk system for ZX Spectrum) (http://www.worldofspectrum.org/ZXSpectrum128+3Manual/)
(The BBC Micro's ordinary disc filing system also stored contiguous files. I'd always assumed that this would be pretty standard for 8-bit systems... it simplifies reading and writing of files, and reduces the amount of metadata that needs storing.)
"Files in CP/M can be thought of as a sequence of up to 65536 records of 128 bytes each, numbered from 0 through 65535, thus allowing a maximum of 8 megabytes per file. Note, however, that although the records may be considered logically contiguous, they may not be physically contiguous in the disk data area. Internally, all files are divided into 16K byte segments called logical extents, so that counters are easily maintained as 8-bit values. The division into extents is discussed in the paragraphs that follow: however, they are not particularly significant for the programmer, because each extent is automatically accessed in both sequential and random access modes".
CP/M: extent map made up of directory entries. The file size is in units of sectors, but text files end with ^Z. Ctrl-M Ctrl-J is end of line.
TRSDOS (TRS-80), also used extents.
This whole extent concept came from DOS/360 from IBM mainframes.
Apple DOS: directory entry points to a linked-list of indirection sectors which hold pointers to the sectors that make up the file. The size of a file is in units of sectors, except that for text files, the end of the file is indicated with NUL. Ctrl-M is end of line.
Atari DOS: just like the C64- a linked list of sectors, but with 3 bytes of overhead per 128 byte sector (the extra byte contains the number of valid data bytes in the sector). The file size is in units of bytes due to this. End of line for text files is 0x9b. (ESC with 7th bit set).
MS-DOS: files are made of a linked-list of clusters, but the linked list for all the files are stored in one place- the FAT (nicely eliminating the need for a free-space bitmap). But if you overwrite the FAT, you lose everything!
Early version of UNIX (SCO Xenix) didn't use a bitmap for the free blocks, instead it kept them a linked list. This was a really bad idea, files instantly became fragmented.
If I possibly can, I'm going to dust off ye olde 1541, plug it into the somewhat less dusty C64, boot it all, find a working "diskette" and see if I can't run this.
Why? For the sweet satisfaction.