On Mon, 3 Jun 2002, Trevin Beattie wrote:

> >Off-list? Ok. :-)
>
> Oops!  Sorry, Bill; I just forgot to send the reply to tech-kern.  {:-}
> >I agree about geometry being faked up. And that newfs sometimes gets quite
> >fussy about things that don't matter. But are you sure about ffs throwing
> >away the sector size? :-) fs_fsbtodb includes it, and the patches I came
> >up with (on the devbsize branch) only had to make sure it was correct to
> >get the fs working on 2k disks.
>
> Okay, technical point here.  fs_fsbtodb (before I patched it) is computed
> in terms of sector size, and I suppose you could re-compute the sector size
> as [1 << (fs_fshift - fs_fsbtodb)].  But the plain sector size itself (or
> log2(sectorsize)) is not stored in the fs structure.

Well, we're splitting nits. :-) To me, having log2(sectorsize) is the
same as (or even more useful than) sectorsize. :-)

> The reason I changed fs_fsbtodb to use DEV_BSIZE units is because most of
> the instances of fsbtodb that I've found pass the result to bread() or
> set/compare the value to b_blkno, which require DEV_BSIZE units.

The ones that pass it to bread should use the alternate fs_fsbtodb.

> >But is our implementation breaking?
>
> With the exception of NeXTSTEP 3.0, I haven't found an implementation that
> *isn't* broken WRT large sectors.  This includes NetBSD, although I must
> say our implementation has greatly improved since I first looked at the
> problem, at least three years ago.

Did you try compiling a NetBSD kernel (and userland) with DEV_BSIZE set to
2048?

That's the supported way of handling 2k-sector disks. And unless we broke
it, it works (and has worked for YEARS).

If you didn't compile a system with a changed DEV_BSIZE, then yes, it
doesn't work.

That's what we're trying to fix.

However since things would work if we'd made DEV_BSIZE == sector size, we
have a spec of what to expect.

> To sum up: the i386 port gets the sector boundary check wrong by a factor
> of sector-size / DEV_BSIZE.  (I haven't looked at the other ports to see
> whether they have similar bugs.)  ffs_mountfs(9) is broken WRT the location
> of the super-block; it passes a sector number to bread, which is expecting
> a DEV_BSIZE block number.  There were also several smaller problems with
> mkfs computing fs fields in the superblock in terms of sector size; I don't
> recall what they were offhand, but they'll be easy to recreate if you're
> interested.

mkfs should do things in terms of sectors. Only in-kernel ffs should deal
with DEV_BSIZE.

> >I think that when you add a non-DEV_BSIZE disk to a system, our FS tools
> >make/read the file system exactly as a kernel with DEV_BSIZE==that disk
> >size would.
>
> I'm sorry; trying to figure that one is giving me a headache again. :^P

That's ok. :-)

Just think of DEV_BSIZE as a kernel-only parameter. Everything else should
be in terms of sectors.

> >It should work with the actual sector size now. It just won't transition
> >to DEV_BSIZE too well.
>
> It's just something I have to visualize and understand before I can trust
> it.  Maybe if I tried to figure it out on paper...

Have you read either the Red Book (Design & Implementation of the 4.4 BSD
operating system by McKusic) or read Kirk's paper on FFS? Thous would
probably help.

> >I think the thing to do is find uses of fs_fsbtodb and separate them into
> >uses to determine an offset to disk (i.e. where newfs put something) and
> >uses to determine an offset in the buffer cache. The latter should use
> >"fs_fstoDEV_BSIZEb" - an offset we will make up.
>
> Ouch!  There's a *lot* of code (well, 49 lines in ffs) that uses fsbtodb or
> dbtofsb, and you say they may not all convert to/from b_blkno??  Well, I'll
> look into it -- carefully.  But since most of the calls to fsbtodb and
> dbtofsb use DEV_BSIZE blocks, wouldn't it be easier just to leave those
> alone and change any that expect sector sizes?

cd /usr/pkgsrc/devel/id-utils; make && make install; cd /sys;
mkid; eid dbtofsb

You'll be in a vi (well $EDITOR) session for all of the files containing
dbtofsb. Search for it, and deal with them one by one & you're set.

> Thanks for the feedback!

No problem.

Take care,

Bill