Re: kern/42573: DIRBLKSIZ in <ufs/ufs/dir.h> should not beDEV_BSIZE constant

[David Laight <david%l8s.co.uk@localhost>]

The following reply was made to PR kern/42573; it has been noted by GNATS.

From: David Laight <david%l8s.co.uk@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/42573: DIRBLKSIZ in <ufs/ufs/dir.h> should not beDEV_BSIZE 
constant
Date: Sun, 3 Jan 2010 18:25:11 +0000

 On Mon, Jan 04, 2010 at 02:34:27AM +0900, Izumi Tsutsui wrote:
 > >  At this rate you're going to have non-512-byte volumes working soon :-)
 > 
 > Well, I'm afraid there are much more other problems around
 > DEV_BSIZE (and DEV_BSHIFT) constant.
 > Probably we should nuke them from <machine/param.h>.
 > 
 > - there are many btodb() and dbtob() (which uses DEV_BSHIFT) under sys/ufs
 > - some disklabel sources (MD disksubr.c etc) use DEV_BSIZE to calculate
 >   offsets in several places (and lp->d_secsize is used in other places)
 > - etc. etc.
 
 My thoughts are the DEV_BSIZE should remain forever as 512
 (cygwin fubar not withstanding).
 
 So the majority of code is largely unaware of the physical sector size.
 Clearly the raw devices need only accept transfers that are appropriately
 aligned, so file systems must be initialiased with appropriate parameters.
 (For ffs this probably just means a fragment size larger than the
 physical sector size.
 
 Programs like fdisk, disklabel and installboot to have problems!
 But to make everything fit (eg i386 boot code) the byte alignments
 cannot change - the label has to remain in bytes 512-1203.
 (I have a USB memory stick with 2k sectors, the 0x55, 0xaa are in
 bytes 510 and 511 as usual.)
 
 One current difficulty (that needs fixing) is that many of the disk
 drivers (eg ata) keep on using the sector size from the label!
 
 There are also some other PR with patches ....
 
        David
 
 -- 
 David Laight: david%l8s.co.uk@localhost