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@xxxxxxxxxxxxxxx, 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
