linux-ext4 - Re: fsck get error with the file which is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4CC0752A.20905@redhat.com>
Date:	Thu, 21 Oct 2010 12:15:22 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Justin Maggard <jmaggard10@...il.com>
CC:	ck ya <ykwan0201@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: fsck get error with the file which is > 2TB in 4k block file
 system

Justin Maggard wrote:
> On Thu, Oct 21, 2010 at 8:06 AM, Eric Sandeen <sandeen@...hat.com> wrote:
>> ck ya wrote:
>>> I compiled the latest e2fsprogs, and do fsck with -nvf on my ext4 file system.
>>> It showed
>>> Inode 18, i_blocks is 17179870744, should be 17179870744. Fix? no
>>> The i_blocks is the same.
>>>
>>> I found ext2fs_inode_i_blocks() has problem.  The function check
>>> EXT4_FEATURE_RO_COMPAT_HUGE_FILE with "s_feature_compat".  It should
>>> be "s_feature_ro_compat".
>> Seems right to me, if you add [PATCH] to the subject emails like
>> these, and add:
>>
>> Signed-off-by: ck ya <ykwan0201@...il.com>
>> ---
>>
>> after the patch,
>>
>> it'd be ideal.
>>
>> Thanks,
>> -Eric
>>
>>> Thanks.
>>>
>>> diff --git a/lib/ext2fs/blknum.c b/lib/ext2fs/blknum.c
>>> index a48b696..d67c6ec 100644
>>> --- a/lib/ext2fs/blknum.c
>>> +++ b/lib/ext2fs/blknum.c
>>> @@ -49,7 +49,7 @@ blk64_t ext2fs_inode_data_blocks2(ext2_filsys fs,
>>>                                         struct ext2_inode *inode)
>>>  {
>>>         return (inode->i_blocks |
>>> -               ((fs->super->s_feature_incompat &
>>> +               ((fs->super->s_feature_ro_incompat &
>>>                   EXT4_FEATURE_RO_COMPAT_HUGE_FILE) ?
>>>                  (__u64) inode->osd2.linux2.l_i_blocks_hi << 32 : 0)) -
>>>                 (inode->i_file_acl ? fs->blocksize >> 9 : 0);
>>> @@ -62,7 +62,7 @@ blk64_t ext2fs_inode_i_blocks(ext2_filsys fs,
>>>                                         struct ext2_inode *inode)
>>>  {
>>>         return (inode->i_blocks |
>>> -               ((fs->super->s_feature_incompat &
>>> +               ((fs->super->s_feature_ro_incompat &
>>>                   EXT4_FEATURE_RO_COMPAT_HUGE_FILE) ?
>>>                  (__u64)inode->osd2.linux2.l_i_blocks_hi << 32 : 0));
>>>  }
> 
> Hmm, looks strikingly similar to what I posted nearly two months ago. :)

Whoops, glad you remembered it :)

Ted, I guess that's a ping to merge the fix for that bug ;)

-Eric

> -Justin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html