| On Mon, Jun 03, 2002 at 06:05:46PM -0700, Trevin Beattie wrote:
| > At 11:51 PM 6/3/2002 -0000, eeh@netbsd.org wrote:
| > >
| > >| I've implemented a fix for the ffs filesystem so that all upper-level disk
| > >| operations use DEV_BSIZE blocks, and the actual sector size is left to the
| > >| physical device driver (below the buffer cache).  I've successfully
| > >| created, mounted, and written to a virtual disk using 2048-byte sectors.
| > >| Next thing I need to do is run the patched NetBSD on real hardware (I've
| > >| been using VMware for testing :-) and see if it will work with a SCSI MO
| > >| drive.
| > >
| > >I don't think that's a very good way of doing this.  This means you have to
| > >fix every single filesystem to handle different block sizes. 
| > 
| > What's wrong with fixing everything?  ;-)
| > Seriously, though, what I'd rather do is fix every filesystem (as far as
| > they remain backwards compatible) to *ignore* different block or sector sizes.
|
| currently every disk driver and almost all of the rest of the system
| assume b_blkno is in units of DEV_BSIZE, so it would definitely be easier
| to fix the few places that assume something else than to switch everything
| that assumes units of DEV_BSIZE.
|
| as for FFS, I think the only place it has a problem is in its usage of
| the fs_fsbtodb field in the superblock.  code that uses this field is
| attempting to convert from a fragment size to the units of b_blkno,
| so such code should really just compute the desired value
| 	(fs->fs_fshift - DEV_BSHIFT)
| rather than using the value in the superblock.

Where do you do the read-modify-write operations needed to write data in
increments smaller then the device block size?  And how do you make sure
you don't get corruption when there are two operations that want to write
to different DEV_BSIZE parts of a single device block?  Don't forget that
things like fsck need to be able to do those sorts of operations without
the benefit of the buffer cache.

Eduardo