Re: Support for 4KB sectors size disk ?

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

david%l8s.co.uk@localhost wrote:
> On Tue, Jan 12, 2010 at 11:15:09PM +0900, Izumi Tsutsui wrote:
> > 
> > On i386 and amd64, there is another problem around bootloader.
> > 
> > Currently FFS has only 8KB free space for bootloader.
> > On x86, the first sector contains PBR that loads
> > bootxx_ffsvN stored in the following sectors:
> > 
> > sector 0:    PBR (pbr.S in src/sys/arch/i386/stand/bootxx/)
> > sector 1:    NetBSD disklabel
> > sector 2-15: primary boot (bootxx.S, boot1.c, and fs specific code)
> > 
> > But on 4KB/sector disk, sector 1 is at 4KB (that should have disklabel?),
> > and sector 2 is at 8KB where FFS superblock should be stored.
> 
> On the 2k sector USB stick I have, the 0x55aa is still at byte offset 0x1fe.
> If the bios is likely to be doing compat-mode 512 byte transfers this
> will remain true.

How is the location of the magic relevant to hardware sector size?
Is there any practical implementation which puts the magic at
other than 0x1fe?

Probably we should check 640MB SCSI MO disks which have 2KB/sector..

> Which may mean that the mbr treats the disk as if it has 512 byte sectors?
> 
> So bytes 0x200-0x3ff can be used for the disklabel, and bytes 0x400 on
> for bootxx_xxxfs. Installboot will do this - it always does 8k read/modify/
> write sequences on the start of the disk.

The disklabel(9) should belong to kernel design like subr_disk_mbr.c.
Bootloaders should follow that implementation after the design is done
(and investigation how BIOS treats 4KB/sector disks is done).

Anyway, it's easier to throw away disklabel support on >512bytes/sector
disks because we can't use it on >16TB (4KB * 2^32 blocks) disks
with 4KB/sector, which is designed for such huge capacity.

> Note that, even if the bios does 2k/4k reads, the i386 initial boot sequence
> will still work. Although the transfers will be longer than expected
> they won't overwrite anything important.  The fs specific code will need
> to transfer the correct number of bytes - but it has more code space and
> is reading file system blocks, not disk sectors.

FFS structures might also depends on I/O implementation of the kernel.
---
Izumi Tsutsui