Re: few ext2/ext3 questions (i_blocks usage and updating superblock in r-only)

[tytso@mit.edu]

On Tue, Mar 09, 2010 at 06:27:27PM +0300, Evgeniy Ivanov wrote:
> Hello,
> 
> What is correct way to treat i_blocks? i_blocks is a block counter,
> but its values differ from real number of used blocks (e.g. 1 block is
> used and written to i_block, but i_blocks is set to 8 and if I set
> i_blocks to 1 e2fsck always wants to set it to 8). As I understand
> preallocation shouldn't affect i_blocks and there are no unix holes.

This is a question which is better asked on
linux-ext4@vger.kernel.org, since it's an ext4 specific question.

i_blocks was historically marked in units of 512 byte sectors because
st_blocks as returned by stat(2) is in units of 512 byte sectors, and
so it was easier to pass i_blocks straight on through to st_blocks.

In ext4, if the HUGE_FL flag set in the inode's i_flags, and
EXT4_FEATURE_RO_COMPAT_HUGE_FILE feature flag is set, then i_blocks is
stored in units of the file system block size, and it's up to ext4's
stat method to convert that to the units expected by st_blocks.

> Nothing on fs should be updated, when it's mounted in r-only (I mean
> mount time, mount point attributes of superblock), right?

Correct.

> Btw, when I don't have problems with i_blocks, e2fsck's exit status is
> 1 (my ext2 implementation is guilty), but it doesn't say what was
> wrong even with "-v". How can I get more verbose results?

The exit status of 1 means that something was changed by fsck.  See
the man page for fsck or e2fsck, in the "EXIT CODES" section.  There
were a few cases where e2fsck didn't explain what it was that it fixed
up or updated, but I thought all of that has been fixed.  What version
of e2fsck are you using, and can you easily replicate this?  If so,
I'd like to see a file system image.

					- Ted