On Thu, Jan 21, 2010 at 10:30:20PM +0000, Michael van Elst wrote: > IMHO there need to be three different ways to specify block > offsets and block counts: > > 1. in units of blocks of the physical device > 2. in units of blocks of DEV_BSIZE bytes > 3. in bytes
Don't forget: 4. in units of the filesystem block size... > and we need to establish what units are used where. IM (fairly strong) O everything should be kept in byte counts, and never block counts because if you have more than one unit in use it is far too easy to accidentally mix them or provide the wrong one, and because they're all the same language-level type there's little hope of detecting such problems automatically. Furthermore, Murphy's Law dictates that in any particular place the count you are given is frequently not in the units you need to give something else, and then you end up converting back and forth all over everywhere. This serves no purpose and tends to obfuscate the code base. Since in practice nothing can be larger than the maximum value of off_t anyway, and all counts should be getting carried around as 64-bit values, using byte counts instead of block counts does not change the maximum addressable size of anything and therefore has no particular downside. Things should only be converted to block counts right when talking to hardware, in which case the correct size to use is immediately available, or right when reporting to userlevel using interfaces standardized that way, in which case ditto. > The necessary changes are rather small. In particular, dkwedge_info needs > to be extended to keep track of the physical sector size so that the dk > driver can do the transformations. The physical sector size should be available to callers (just not part of the API/ABI) so this ought to be done regardless. -- David A. Holland dholl...@netbsd.org
