Clarrification on fs block size

[Bruce Evans]

On Wed, 22 Apr 2009, litepc.com wrote:

> I'm trying to to track down files that are using bad disk blocks as
> reported by SMART drive tests
>
> I'm struggling indentifying which inodes are using which disk sectors
> because the various utilities appear to define "blocks" differently.
>
> In the context of  smartctl, fdisk, and bsdlabel a "disk block" is a
> 512 byte sector
>
> In the context of UFS file system a "file system block" is 16384
> bytes and a "fragment" is 2048 bytes

Actually, ffs has 2 types of blocks, "logical blocks" of configurable
size (default 16384) and ordinary "blocks" ("fragments") of configurable
size (default 2048).  Logical blocks are used mainly within files and
ordinary blocks are used in most other contexts, in particular for all
block numbers in metadata.  Block numbers in metadata need to have the
smaller units so that they can address fragments.

> So to my mind this means there are 32 x 512byte blocks in each 16384
> byte file system block.
>
> However...
>
> dumpfs reports "fsbtodb 2"  which means a disk block = file system
> block * 2^2  so there are 4  disk blocks in each file system block -
> this is verified using the fsdb "blocks" command to list block
> numbers assigned to an inode...which then must be multiplied by 4 to
> use the fsdb "findblk" command to find the correct inode.

4 is the conversion factor for ordinary ffs blocks of size 2048 and
virtual disk blocks of size 512 (actual disk blocks may have a different
size though 512 is normal (perhaps due to virtualization in the disk
itself).

> Which seems to indicate that a "file system block" to dumpfs and fsdb
> must be equivalent to a 2048 byte "fragment".   Is this correct?

Yes.

> What is confusing is that if dumpfs reports "bsize" as 16384 then the
> "b" in "bsize" and "b" in "fsbtodb" appear to be different "block"
> definitions.

It's confusing in ffs sources too.

> I want to be sure that I can take the identified currupt LBA address
> in smartctl, then locate the correct file system and adjusted offset
> using bsdlabel and then plug this block number straight into fsdb's
> "findblk" command to identify which inode owns the corrupted block.
> If  fsdb's findblk is expecting some other definition of "disk block"
> then its not going to locate the correct inode!

"findblk" seems to convert from and to virtual disk block units, so you
don't need to know anything about either of ffs's.  This is a strange
interface since its blocks have different units from the ordinary block
numbers printed by the "blocks" command.  "findblk" seems to be the
only command in fsdb that does these conversions.

Bruce