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

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Nov 26, 2015 at 11:38:14PM +0700, Robert Elz wrote:
 > (for 4K sector drives, cgd and lvm both give you 1/8 the space that
 > you should have had on the device.)

Ewww....

 > ccd (especially if combining a 4k byte sector device with a 512 byte sector
 > device) is simply a mess - perhaps almost a candidate for extermination.
 > (Or maybe it can be resuscitated, who knows right now?)

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

Does ccd serve any purpose that raidframe doesn't? (other than
compatibility with existing deployments, which I don't think are many)

 > I see two (wildly different) approaches (currently see) that could be
 > used to fix the problems...
 > 
 > One is to convert the kernel to use byte offsets absolutely everywhere.
 > [...]
 > The other is to carry explicit unit designators along with every blk/sec
 > number, everywhere [...]

I have long thought that everything should be done in bytes, because
in the absence of compiler- or lint-level support for reasoning about
units of values one ends up mixing units by accident; periodically
discovering bugs like fixed in -r1.247 of sys/ufs/lfs/lfs_segment.c
has done nothing to weaken this opinion.

The problem I see with carrying around unit values at runtime (besides
potential overhead) is that at least in FS-level code it'll make a
huge mess. FFS, for example, has hardware-level sectors, DEV_BSIZE
blocks, fragments, its own blocks, and maybe other things; LFS, which
I've been looking at more recently, has all of these and also
segments, offsets in terms of counts of inodes, offsets in terms of
counts of ifile structures, etc. etc. And the existing code converts
back and forth among these units with wild abandon, using macros with
names like "sntod" that don't mean very much even to the initiated.
Tracking every one of these with a parallel units variable would add a
lot of complexity and mess and one would probably never get it right
anyway.

I wonder though if static program analysis for units is feasible; or
rather, the analysis definitely is -- the question is whether there's
any way to deploy it without spending six months on tooling.

Otherwise I think sucking up the overhead of 64-bit byte values is
probably the least awful way to go.

-- 
David A. Holland
dholland%netbsd.org@localhost