Re: blocksizes

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Mon, Feb 01, 2010 at 10:11:08PM +0900, Izumi Tsutsui wrote:

> 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?

For fsck_ffs nothing has changed. FFS itself can handle different
sector sizes, of course I cannot rule out bugs, but these have
little to do with the driver API.

You are right that now the filesystem and fsck_ffs, newfs or fsdb
may have different views on the data if fs_fsbtodb doesn't reflect
reality. However, fs_fsbtodb is (and must be) initialized correctly
when creating the image for compatibility with other systems and
the userland tools and the worst thing can happen is that the
kernel code still understands the data while the userland tools
do not. This can easily happen if you copy the image between disks
with different block sizes.

The same issue also exists when dealing with the filesystem images
themselves. You have to resort to vnd(4) to provide the concept
of block sizes or give this information as a parameter (newfs
can do this, but badly). This is some place that needs improvement.


> (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?

DIRBLKSIZE it is the chunk size used to access directory 'files'.
The function ufs_blkatoff() translates the offset into block numbers.

Block counts stored in dinode are measured in DEV_BSIZE blocks.
This is what a stat() or fstatvfs() report and what quotas
should count and how it is documented for NetBSD. I verified
that FreeBSD choses the same units, so the on-disk data should
be the same.

So, both numbers are not related to addressing disk blocks.

I would not expect issues there as the code has been used on disks
with different block sizes in the past. Maybe there are bugs in
the dirhash code.


Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."