On Tue, 4 Jun 2002, Trevin Beattie wrote:

# I think I just found another problem.
# sys/arch/i386/stand/installboot/installboot.c creates a 'fraglist' array of
# block numbers + block counts, which (I presume) the boot sector uses to
# load the 2nd-stage boot program.  The boot sector definitely uses the
# fraglist values as physical sectors.  installboot, however, generates the
# values as follows:
#
#
# 	/* convert to disk blocks */
# 	blk = fsbtodb(fs, blk);
# 	nblk = fs->fs_bsize / DEV_BSIZE;
#
# Now, fsbtodb, as originally written, converts file system frags to physical
# sectors.  So the first assignment yields a sector number, but the second
# assignment yields a DEV_BSIZE count!  This is certainly wrong.

I think you don't see what it's doing up there.

fsbtodb converts filesystem _blocks_ to physical sectors, not frags.

I don't think that looks wrong at all, except in the case where DEV_BSIZE
as a constant should be replaced with dev_bsize as a variable, one would
think -- it doesn't make sense to have to recompile a kernel AND all of
userland to handle a different underlying medium size.

But, then, that's what this whole thing appears to be about.

But I digress.  I guess what I'm looking at, there, and I haven't yet read
the rest of the replies, so apologies in advance, is the block offset
gets converted from a requested base offset into an offset relative to
the desired filesystem; the number of blocks to use appears to be the
filesystem's block size divided by the underlying sector size of the
medium, which would be entirely reasonable, obviously.

...or Did I Miss Something Here?

				--*greywolf;
--
NetBSD:  You choose the hardware, we'll bring the OS.