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.


> >Chuck Silvers mentioned he wants to address this issue some time.  You
> >might want to send him some email to see what his thoughts are.
> 
> I thought he was on the mailing list?  Guess I shouldn't assume.  Maybe
> that's why I haven't seen a comment from him...

I just wasn't reading mailing lists over the weekend.

-Chuck