Re: e2fsck (git) on ext4: unsupported feature(s): huge_file

[Theodore Tso <tytso@MIT.EDU>]

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