Supporting efficient operations on drives with 4K physical sectors

[Simon 'corecode' Schubert]

Matthew Dillon wrote:
>     It looks like a number of newer drives are going to a 4K physical
>     sector size (but retaining the 512 byte logical sector size for
>     the interface).  Properly aligned operations wind up being more
>     efficient.

They might support larger (optional?) logical blocks as well, later.

Be aware, the standard does not specify that 4KB blocks need to be
aligned on 4KB boundaries.  HDDs report the alignment and the
granularity separately.  In light of this, we might want to be able to
use an arbitrary offset in the file system or disklabel?

>     So here's the issue for us.  The fdisk program initializes slice 1
>     starting at (512 byte) sector #63 instead of 64 in order to align
>     to the system's idea of a cylinder boundary.  This is due to
>     the 63 sectors/track value:
> 
> cylinders=242251 heads=256 sectors/track=63 (16128 blks/cyl)

This value is completely arbitrary, as far as I can tell...

> Media sector size is 512
> Warning: BIOS sector numbering starts with sector 1
> Information from DOS bootblock is:
> The data for partition 1 is:
> sysid 165,(DragonFly/FreeBSD/NetBSD/386BSD)
>     start 63, size 3907024065 (1907726 Meg), flag 80 (active)
>         beg: cyl 0/ head 1/ sector 1;
>         end: cyl 1023/ head 255/ sector 63
> The data for partition 2 is:
> 
>      The question is, can we safely modify fdisk to start the
>      slice in the second sector of the cylinder instead of the
>      first (cyl 0 head 1 sector 2) in order to align it to
>      logical sector #64?

I think so - every modern system should anyways only use the lba.  We
should maybe the use 32 sectors per track for CHS (I don't think 64 are
allowed)

cheers
  simon


Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00001.pgp
Type: application/octet-stream
Size: 260 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20091228/2a0242c5/attachment-0020.obj>