On Tue, 4 Jun 2002, Trevin Beattie wrote:

> At 09:49 AM 6/4/2002 -0700, Bill Studenmund wrote:
>
> I like Chuck's suggestion (fs_fshift - DEV_BSHIFT).  Get rid of fs_fsbtodb
> completely.
>
> If we really need to reference the sector size, should we have that stored
> in the file system, or grab it from the disk label, or just ask the
> hardware?  First of all, you have to convince me that we do need the sector
> size at the file system level.

As before, the reason we need the sector size is because the file system
designer decided it would be good to lay things out in terms of physical
sectors. i.e. it was previously designed that way. :-)

> >However since things would work if we'd made DEV_BSIZE == sector size, we
> >have a spec of what to expect.
>
> Let me think about that... you're saying that whatever changes we make, a
> file system created on a 2k/sector disk on a machine with DEV_BSIZE = 512
> should be laid out exactly the same as one created on an unpatched system
> with DEV_BSIZE = 2048?  That sounds reasonable.  I'd be perfectly happy,

Yes. It's prior art, and I've seen no reason to not go with it come up in
this thread. :-)

> though, if we could get a file system created by the former machine that
> simply _works_ with the latter machine, and vice-versa.  (That is, mkfs may
> lay out the blocks differently, but the superblock data is defined well
> enough to allow both machines to read either disk.)

But that's a loose spec. Making the on-disk format be the same for both
cases is actually easier. You have a much tighter spec to deal with, and
I've generally found tight specs easier as you don't have to think about
this case or that.

For one, you shouldn't need to change newfs at all; as I recall I had most
everything checked into the wrstuden-devbsize branch, and there are no
changes there to deal with different sector sizes.

Thus all you have to do is deal with changing the kernel. :-)

> >> 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.
>
> But the kernel ffs depends on values stored in the super-block, which are
> initialized by mkfs.  Here again, if we could get rid of everything in the
> fs that was dependent on DEV_BSIZE or sector size, this wouldn't be an issue.

Yes, but that wouldn't be ffs. That would be ffs+our patches.

For a new fs design, I'd say sure. But I don't think its appropriate for
us to be making that kind of change to ffs.

> >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've got the Red Book sitting on my book shelf; hadn't used it in a year or
> two.  A brief scan through chapters 6-8 didn't reveal much though; it seems
> mostly focused on design philosophy, with little implementation details.
> The closest reference I could find to DEV_BSIZE is on p. 227: "In earlier
> versions of BSD and in most other versions of UNIX, buffers were identified
> by their physical disk block number.  4.4BSD changes this convention to
> identify buffers by their logical block number within the file."
>
> I'm not familiar with Kirk's paper.  Is this available online?

Not sure. There should be a ref to it in the red book. I think it came out
in 84.

Take care,

Bill