tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: blocksizes

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

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

Home | Main Index | Thread Index | Old Index