Date : Mon, 05 Apr 2010 16:56:42 +0200
From : rick@... (Rick Murray)
Subject: ADFS & 512 byte sectors
On 05/04/2010 15:50, Mark Usher wrote:
> Yes, sorry, should have been more specific. I meant with hard drives, not
> the floppies.
Awwww... and all that research. :-(
> So was just wondering where in the OS history this change took place.
I think this is down more to drive technology than Acorn. Early
harddiscs used 256 byte sectors, and the CHS addressing mechanism. When
this started to seem like a limit, an "easy fix" was to increase the
sector size to 512 bytes. This wasn't a massive problem as the older
memory-restricted hardware was starting to die out and with the early
PCs, Ataris, etc... these things had more then 20-50K onboard so could
afford more space for drive buffering.
When THAT started to look like a limit, the LBA (logical block
addressing) system was introduced. This is why I *think* the RISC OS
ADFS harddiscs use 1024 byte sectors. The drive itself is using
something else, but then the drive is probably reporting something silly
like 63 heads and 19 tracks. :-) The IDE part itself translates the
computer's view of the disc to the harddiscs view of the disc. And with
such features as automatic moving of data on sectors that are starting
to fail, the two can be very different...
In the old days, physical harddiscs used 256 byte sectors and this was
talked to more or less directly. This is, incidentally, I believe to be
why I am having no luck with SCSI drives on my FileStore - I think the
sector size is wrong.
In the newer days, physical harddiscs use 512 byte sectors, but this
pretty quickly started to be abstracted from the computer's idea of the
disc layout.
In modern days, it is totally abstract. Probe a FAT formatted MP3 player
and you'll find 512 byte sectors. Look up the Flash chip used, and
you'll find it is probably 2Kb or 4Kb sectors, which - IMPORTANT - are
erased in blocks of 32Kb-128Kb at a time. How is this possible? Some
memory and intelligence in the controller chip in the MP3 player to take
the Flash NAND and present it like a generic harddisc. Indeed, some
harddiscs use 1024 byte sectors and as of next year it looks like the
major players will use 4096 byte sectors. But since this is abstracted
from what the computer can 'see', it matters little. The only big loss
will be in file allocation unit wastage for holding twenty files
containing eight bytes each would consume some 80K. But that's a small
loss on a terrabyte sized disc! It's all fairly irrelevant given modern
technologies anyway. I opened Explorer and clicked Properties in the
menu over C:\Windows. It reported:
Size 3.07 GB (3,300,984,522 bytes)
Size on disc 2.44 GB (2,630,661,264 bytes)
14,193 files, 1,532 folders
while my blog, on the other hand, reports:
Size 46.0 MB (48,269,853 bytes)
Size on disc 47.6 MB (49,963,008 bytes)
948 files, 7 folders
The blog folder is more what you'd expect from a traditional setup (such
as ADFS) that simply stores data, while the Windows folder includes
elements which are automatically compressed depending on importance
and/or usage.
And they're all totally faking it. Windows is on C: which is a
Flash-based SSD, while blog is on E: which is a 4Gb SD card. Neither of
which *actually* have a 512 byte sector size. I need to load up Everest
to see the SSD reports as 15636 cylinders, 16 heads, 63 sectors per
track, 512 bytes per sector (traditional view)...
There's some nerdy stuff about aligning filesystems to work better with
SSDs here:
http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/
Best wishes,
Rick.
--
Rick Murray, eeePC901 & ADSL WiFI'd into it, all ETLAs!
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...