Re: blocksizes

[mlelstv%serpens.de@localhost (Michael van Elst)]

tsutsui%ceres.dti.ne.jp@localhost (Izumi Tsutsui) writes:

>---
>diff -u src/sys/ufs/ffs/fs.h:1.54 src/sys/ufs/ffs/fs.h:1.55
> :
>@@ -599,8 +599,13 @@
>  * Turn file system block numbers into disk block addresses.
>  * This maps file system blocks to device size blocks.
>  */
>+#if defined (_KERNEL)
>+#define       fsbtodb(fs, b)  ((b) << ((fs)->fs_fshift - DEV_BSHIFT))
>+#define       dbtofsb(fs, b)  ((b) >> ((fs)->fs_fshift - DEV_BSHIFT))
>+#else
> #define       fsbtodb(fs, b)  ((b) << (fs)->fs_fsbtodb)
> #define       dbtofsb(fs, b)  ((b) >> (fs)->fs_fsbtodb)
>+#endif
>---

>I doubt this would work properly.

That's how the filesystem translates its own blocks (the fragments)
to the disk blocks.

The kernel addresses disk blocks in DEV_BSIZE units, and that's
why this change yields the correct values.

One possible solution would be to store the 'correct' value into
the superblock for a disk with DEV_BSIZE units. However, that is
incompatible with other systems. That's why here the kernel
is adjusted to ignore the fs_fsbtodb value and compute the correct
value from the filesystem block size.

The macros are also used in userland where the code still treats
everything in disk block units.


>Isn't it better to have new macros
>for raw I/O size

DEV_BSIZE is the raw I/O size as far as the kernel is concerned.

I thought about using new macros and changing all places in
the filesystem code to refer to the new macros. But that would
just confuse the issue, which is that the filesystem talks
to devices that are addressed in DEV_BSIZE units.

There is one more place where the fs_fsbtodb value is also
used, the bmap code in ufs/ufs. Since the bmap code doesn't
store the shift value anywhere on disk, it can simply use
the correct value internally:

        ump->um_bptrtodb = fs->fs_fshift - DEV_BSHIFT;


>and to replace old ones with them for bread(9)
>or blkno etc?

>I think fsbtodb()/dbtofsb() should be left as is because
>they are for the "FFS disk block size stored in superblock"
>which is still used in dinode and it could be different from
>raw I/O size.


>> Can you please test with your 2K MO?

>It's not easy to test it without working newfs(8) command.
>(if you need hardware I can send the drive and media..)

I have tested on vnd (after fixing sector size handling in vnd).
newfs failed on 2K disks (but not 1K) because it tries to
read a 1K Apple UFS label.

fsck_ffs had the same problem.


>> N.B. newfs doesn't yet know how to deduce sector sizes, you need
>> to use the -S option.

>newfs(8) doesn't work even with -S 2048 option.

It now does :)  Still, it should not need that option.

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