Date: Wed, 22 Apr 2009 18:05:09 +1000 From: "litepc.com" <sb345@litepc.com> To: freebsd-fs@freebsd.org Subject: Clarrification on fs block size Message-ID: <49EF5C55.7178.1CEB83C@sb345.litepc.com>
next in thread | raw e-mail | index | archive | help
Hello, 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 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. Which seems to indicate that a "file system block" to dumpfs and fsdb must be equivalent to a 2048 byte "fragment". Is this correct? 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. Can anyone clarify? 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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49EF5C55.7178.1CEB83C>