mlelstv%serpens.de@localhost (Michael van Elst) writes:
> jdbaker%mylinuxisp.com@localhost ("John D. Baker") writes:
>
>>First, can anyone point me to message threads about how modern 4K-sector
>>disks are to be handled? I must admit some confusion when reading about
>>4K native sectors, but having to deal with a 512-byte emulation mode.
>>At what point does the emulation get out of the way and allow one to address
>>the native 4K sectors?
>
> With 512-byte emulation mode you do not address 4K sectors, that's
> the whole point. You can treat the disks just as disks with 512-byte
> sectors and they will "work". However, you should still arrange the
> data on the disks so that accesses are aligned to the 4K sectors,
> otherwise you will see performance penalties.
>
> In particular:
>
> - start partitions on 4K (or multiple) boundaries. A common value
> is to use 1M alignment (which wastes a few sectors).
> - use filesystem block sizes of 4K (or multiple). With FFS that's
> the _fragment size_. You need to tell newfs about this, because
> it can only see the emulated block size.
Agreed on all of that, but to respond to John's question: the disk has
4K sectors on the media, but has an interface that acts like 512B
sectors. So if you do a write which is aligned to start on 4K and is a
multiple of 4K, it will be a straightforward write of some number of
underlying whole sectors. If the write is misaligned or fractional, it
will result in read-modify-write by the disk controller.
In particular, the common PCism of starting at sector 63 (1 floppy track
in) is a really bad idea. So many disks are 4K these days (or the ones
you buy later to replace a failed member of a RAID set) that all
partitions should be aligned to 8 sectors, or arguably 64 or some higher
power of 2. Amazingly 1MB as mlelstv@ suggests is only 2048 sectors.
It's hard to believe we once used disks with only about 5000 sectors
(e.g. DEC RK05, on which I used 6th Edition...). Wasting part of 1MB
seems bad until you realize it's only 0.25 ppm of a 4T disk!
Attachment:
pgpUuwN_ildKZ.pgp
Description: PGP signature