Re: blocksizes

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

> > Why do you leave fsbtodb() to use fs_fsbtodb for userland?
> > To have less changes?
> 
> Kernel uses DEV_BSIZE devices and needs a proper translations function.
> Userland uses device block sizes and needs a proper translation function.
> Only the translation function (==fsbtodb()) needs to be implemented
> differently because of the different environment. Other parts of the code,
> shared by kernel and userland, simply use this abstraction.

IMO using different implementation against shared structures among
kernel and userland will confuse readers and have less maintainablility.

Using different translation function might be acceptable, but
I don't think it's a good idea to ignore fs_fsbtodb value
stoerd in superblock in kernel ops while userland refers it.
Can fsck_ffs(8) do proper checks, for example?

Anyway I have no further comment if it's approved by responsible persons
since it isn't my work area.

> This is not about redesigning the driver API and only marginally about
> cleaning up old code.

Current implementation uses DEV_BSIZE or fsbtodb() for following values:

(1) blkno passed to I/O layer
(2) block count stored in dinode
(3) DIRBLKSIZ

API issue you mentioned is about (1), but what about (2) and (3)
that should be defined in file system layer itself?
Have you confirmed that current implementations for (2) and (3)
are properly designed for !512byte physical blocksize and
they require only "cleaning up old code"?
Don't they require physical blocksize value stored in superblock?
---
Izumi Tsutsui