On Wed, Apr 09, 2008 at 07:53:42PM +0200, supersud501 wrote:
> Theodore Tso wrote:
>> That patch which I just sent out passes the regression test suite, but
>> it hasn't been extensively tested for actual *huge* files.
>> (Specifically, files with the EXT4_HUGE_FILE_FL because they are
>> larger than 2TB and so i_blocks had to be specified in units of
>> filesystem blocksize, instead of units of 512 bytes.)
>> If you could apply the patch I just sent out and then run "e2fsck -nf
>> /dev/sdXXX" and let me know you get, that would be much appreciated.
>
> I'll do when the patch arrives in git (or where do i get it from?)
I mailed it to the linux-ext4 list for reiview, I'll send it to you
directly.
> Yeah, i'm getting some (~80) errors about i blocks being wrong (besides
> errors that a fast symlink has extents_fl set), and the error is always
> from the type: "i_blocks is x, should be x+8", so it always wants to add 8
> to the existing number. is this the mentioned miscalculation?
x+8, or x*8? I would have expected the latter.
> so i wonder why the flag is set on my drive and if the i_blocks errors i
> get are because of some miscalculation (which shouldn't happen, because i
> have no huge files, right?) or really are some errors (but it's weird
> e2fsck wants to set them always to x+8). doesn't make much sense to me yet.
Using debugfs, can you use the stat command to dump out the inode, and
send the results?
i.e., if you get the message:
Inode 45994, i_blocks is 24, should be 192. Fix? no
Then when you use debugfs, you might see:
debugfs 1.40.8 (13-Mar-2008)
debugfs: features
Filesystem features: has_journal resize_inode dir_index filetype sparse_super large_file huge_file
debugfs: stat <45994>
Inode: 45994 Type: regular Mode: 0644 Flags: 0x0 Generation: 124890615
User: 0 Group: 0 Size: 90118
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 24
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x47ddb871 -- Sun Mar 16 20:16:49 2008
atime: 0x47fbd5d3 -- Tue Apr 8 16:30:11 2008
mtime: 0x47dca16f -- Sun Mar 16 00:26:23 2008
BLOCKS:
(0-11):140798-140809, (IND):140810, (12-22):140811-140821
TOTAL: 24
So with the huge file, note the Blockcount (i_blocks) of 24, and that
debugfs reports the total number of blocks is 24.
Without the huge_file feature, you'll see this:
debugfs 1.40.8 (13-Mar-2008)
debugfs: features
Filesystem features: has_journal resize_inode dir_index filetype sparse_super large_file
debugfs: stat <45994>
Inode: 45994 Type: regular Mode: 0644 Flags: 0x0 Generation: 124890615
User: 0 Group: 0 Size: 90118
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 192
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x47ddb871 -- Sun Mar 16 20:16:49 2008
atime: 0x47fbd5d3 -- Tue Apr 8 16:30:11 2008
mtime: 0x47dca16f -- Sun Mar 16 00:26:23 2008
BLOCKS:
(0-11):140798-140809, (IND):140810, (12-22):140811-140821
TOTAL: 24
Note that the blockcount (i.e., i_blocks) is 192 blocks (in Single
Unix Specification legacy 512-byte units). Since this filesystem is
using a 4k filesystem blocksize, and there are 8 legacy SuS blocks per
filesystem block, when you take the 192 blockcount, and divide by 8,
you get 24 blocks --- which matches with the "TOTAL: 24" display.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
