From mboxrd@z Thu Jan 1 00:00:00 1970 From: tytso@mit.edu Subject: Re: few ext2/ext3 questions (i_blocks usage and updating superblock in r-only) Date: Tue, 9 Mar 2010 11:46:35 -0500 Message-ID: <20100309164635.GF13487@thunk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Evgeniy Ivanov Return-path: Received: from thunk.org ([69.25.196.29]:33693 "EHLO thunker.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755041Ab0CIQql (ORCPT ); Tue, 9 Mar 2010 11:46:41 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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