Re: blocksizes

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

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

<ufs/ufs/dir.h> says:
>> * A directory consists of some number of blocks of DIRBLKSIZ
>> * bytes, where DIRBLKSIZ is chosen such that it can be transferred
>> * to disk in a single atomic operation (e.g. 512 bytes on most machines).

Probably DEV_BSIZE which could be smaller than physical sector size
might be able to handle atomic ops, but I wonder if someone actually
considered how it should work on >DEV_BSIZE sector media.

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

Is there any working code used on disks with different blocks sizes
in the past? Probably some code like msdosfs might work, but
not a whole kernel.

I wondered not only if current code would work or not but also
how all related APIs had been (or should be) designed and defined.
FFS sources used both DEV_BSIZE and fs_fsbtodb (or physical sector
size stored in disklabel) to access disk blocks, and you just "fixed"
the latter ones as "bugs". Yes, after fixing one more "bug" which was
there since initial import ffs seems working on a raw partition on
4KB/sect disk, but there are still several sources that pass
physical block numbers stored in disklabel to I/O functions directly,
like subr_disk.c etc.

It's fine if you have a certain plan how to fix rest of bugs,
but it might be better to have some review before proceeding.

Actaully it would not look so difficult to fix them, but
I wonder if we should have some proper names which explicitly
describe physical or logical blocks because passing logical
block numbers in DEV_BSIZE to a function named "read_sector()"
looks a bit confusing, for example.
---
Izumi Tsutsui


Index: ufs/ffs/ffs_vfsops.c
===================================================================
RCS file: /cvsroot/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.256
diff -u -r1.256 ffs_vfsops.c
--- ufs/ffs/ffs_vfsops.c        31 Jan 2010 10:54:10 -0000      1.256
+++ ufs/ffs/ffs_vfsops.c        3 Feb 2010 11:07:52 -0000
@@ -1931,7 +1931,7 @@
        u_int32_t saveflag;
 
        error = ffs_getblk(mp->um_devvp,
-           fs->fs_sblockloc >> (fs->fs_fshift - fs->fs_fsbtodb), FFS_NOBLK,
+           fs->fs_sblockloc / DEV_BSIZE, FFS_NOBLK,
            fs->fs_sbsize, false, &bp);
        if (error)
                return error;