Re: In-kernel units for block numbers, etc ...

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 26 Nov 2015 19:33:00 +0000
    From:        David Holland <dholland-tech%netbsd.org@localhost>
    Message-ID:  <20151126193300.GA28388%netbsd.org@localhost>

  | Ewww....

It is easy to see why this happens in the CGD source, I think there's
even an XXX comment that is related ... an easy "fix" would just be to
multiply the size by 8 (by the appropriate factor really, of course) 
but that then makes the CGD look like it is a 512 bye/sec device, which
would permit 512 byte reads on odd boundaries, which the underlying drive
cannot handle.

That could be fixed the same way that drives with 4K sectors and 512 byte
addressing do it, using rd/mod/wrt sequences, doing 4K I/O to the
drive and carving out 512 byte pieces, but I really don't believe that's
the right solution.

Making the CGD believe its underlying sectors are 4K panics the system.
(That's about as far as I got, but I think the problem is related to
translation between units, being done when it shouldn't be.)

  | I was already under the impression that ccd was a candidate for
  | extermination even before this came up.

One possibility might be to keep it, but restrict it to only work when
the underlying drives have 512 byte sectors - simply refuse to operate
on 4k (or other) drives.   That would keep compat for anyone currently
using it (I can more or less guarantee no-one is successfully using it
on 4K disks) and avoid needing to find a fix for it that would be rational.
number, everywhere [...]

  | The problem I see with carrying around unit values at runtime (besides
  | potential overhead) is that at least in FS-level code

I doubt that the FS level code can change much, or needs to.  One thing
I have assumed all along is that the file system structs cannot be
altered (in kernel stuff could have some tweaks if needed, but the on-disk
structs need to be unchanged, to keep compat with existing filesystems).

At most, a translation from file system units (DEV_BSIZE almost for sure,
at least in FFS) to whatever is decided for the lower level parts of the
kernel, done only at the interface between the two, is what is needed.
So, all block numbers in a FFS (even on a 4k sector disk) would still be
in DEV_BSIZE units, they'd just always be conveniently multiples of 8...

kre