Subject: Filesystem block/device block size discrepancy
To: None <current-users@sun-lamp.cs.berkeley.edu>
From: Michael L. Hitch <osymh@gemini.oscs.montana.edu>
List: current-users
Date: 08/24/1994 20:01:03
  Has anyone been running (or attempted to run) an ffs file system on a
disk with other than 512 byte sectors?  I have been involved in
attempting to use Magneto Optical drives on NetBSD running on an Amiga. 
When using a cartridge with 1024 byte sectors, I have run into what
appears to be a nasty little discrepancy in how the b_blkno value passed
to the disk drivers is being interpreted.

  Both the SCSI hard disk (sd*) and CDROM (cd*) drivers take the b_blkno
field as the block number of a 512-byte (DEV_BSIZE) block and convert it
to the actual block number of the physical block of the disk.  The
character special devices are accessed through physio() which converts
the device offset (in bytes) to a 512-byte block number, which the
drivers expect. The block special devices convert the offset to the
actual block number on the device based on the sector size in the disk
label. As far as I can tell, the ffs routines are also using the actual
device block numbers, and are thus accessing the incorrect blocks on a
device with 1024 byte blocks.  [The cd9660 file system appears to be
setting b_blkno to the proper 512-byte block numbers, which the cd
driver converts to the proper 2048-byte block number of the CDROM.]

  I can see two different ways to correct this:  changing the ffs and
block special device access to use a 512-byte b_blkno, or change the
character special device access and the cd9660 file system to use actual
device block numbers.  I'm not certain which would be the most "correct"
way to go.

  The msdosfs and adosfs file systems could also be potentially
affected, but at the moment, the adosfs file system will only work with
512 byte blocks, and I think the msdosfs file system only works with 512
byte blocks as well.

  I would be nice to have this fixed in the 1.0 release, but I suspect
making the changes and fully testing them would not be feasible prior to
the release [when ever that might be].

Michael

-- 
Michael L. Hitch			INTERNET:  osymh@montana.edu
Computer Consultant
Office of Systems and Computing Services
Montana State University	Bozeman, MT	USA

------------------------------------------------------------------------------