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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 23 Jun 2010 19:00:26 +0800
From:	Hsuan-Ting <acht93@...ccu.edu.tw>
To:	Andreas Dilger <adilger@...ger.ca>, tytso@....edu,
	"development\"" <linux-ext4@...r.kernel.org>
Subject: Re: E2fsprogs master branch now has all 64-bit patch applied

Hi Andreas ,

  Sorry, please forgot what I said before.
Base on the log(some build raid error), it seems
I didn't stop the old raid before starting this new test.
So this result isn't correct.

                                                        -HsuanTing

Thanks.

2010/6/23 Hsuan-Ting <acht93@...ccu.edu.tw>:
> 2010/6/23 Andreas Dilger <adilger@...ger.ca>:
>> On 2010-06-22, at 03:15, Hsuan-Ting wrote:
>> 2010/6/22 <tytso@....edu>
>>>> This means that we may want to enable the 64-bit feature flag if there
>>>> is an expectation that the filesystem might be grown to a size large
>>>> enough where this would be an issue.
>>>
>>> Sounds like I must enable 64-bit feature when mkfs.
>>> Then it will work, right?
>>>
>>> But base on my test, it will occur core dump when resize:
>>> (gdb) bt
>>> #0  0x00000000004160bf in ext2fs_test_bit64 ()
>>> #1  0x0000000000416318 in ba_test_bmap ()
>>> #2  0x0000000000410629 in ext2fs_test_generic_bmap ()
>>> #3  0x0000000000410656 in ext2fs_test_block_bitmap_range2 ()
>>> #4  0x000000000040873d in ext2fs_get_free_blocks2 ()
>>> #5  0x000000000040936d in ext2fs_allocate_group_table ()
>>> #6  0x0000000000404456 in adjust_fs_info ()
>>> #7  0x0000000000404a81 in resize_fs ()
>>> #8  0x00000000004069c7 in main ()
>>>
>>> I do the following modification
>>> (to enable "EXT4_FEATURE_INCOMPAT_64BIT" and "EXT2_FLAG_64BITS"):
>>>
>>> misc/mke2fs.c :
>>> @@ -1530,6 +1945,8 @@ static void PRS(int argc, char *argv[])
>>>                        EXT2_BLOCK_SIZE(&fs_param));
>>>                exit(1);
>>>        }
>>> +       fs_param.s_feature_incompat |= EXT4_FEATURE_INCOMPAT_64BIT;
>>
>>
>> You don't need to modify mke2fs for this, just run "mke2fs -O 64bit ..." to tell it to create the filesystem with this feature flag set.
>
> Hi Andreas ,
>
> If the size is not big enough, "-O 64bit" will get the following error messages:
> "/dev/sda3: Cannot create filesystem with requested number of inodes
> while setting up superblock"
>
> And base on my trace, I think "-O 64bit" won't always work.
> It will check the blocks count  as the following code in mke2fs.c:
>    if ((fs_blocks_count > MAX_32_NUM) &&
>        !(fs_param.s_feature_incompat & EXT4_FEATURE_INCOMPAT_64BIT) &&
>        get_bool_from_profile(fs_types, "auto_64-bit_support", 0)) {
>        fs_param.s_feature_incompat |= EXT4_FEATURE_INCOMPAT_64BIT;
>        fs_param.s_feature_compat &= ~EXT2_FEATURE_COMPAT_RESIZE_INODE;
>    }
> So I do the above modification to force 64bit feature enabling.
>
> I also find some strange things when mkfs:
> If the size(ex. 91.3G) isn't big enough it will use "floppy" settings
> in mke2fs.conf instead of "ext4".
>
> I do the following steps, it seems work but still has core dump messages:
> 1. remove "resize_inode" and "flex_bg" features ,and let "floppy"
> settings the same as "ext4" in mke2fs.conf
> 2. build linera raid with a small partition of 1 disks (91.3G)
> 3. mkfs.ext4 to this raid
> 5. grow this linear raid (91.3G + 9 x 2TB disks)
> 6. do resize2fs
> 6. get the following core dump:
> [458783.472100] resize2fs[27376]: segfault at 7fa420f14000 ip
> 0000000000416055 sp 00007fff533a99e8 error 4 in
> resize2fs[400000+1e000]
> Segmentation fault (core dumped)
> (gdb) bt
> #0  0x000000000041606f in ext2fs_test_bit64 ()
> Cannot access memory at address 0x7fff2be12328
> 8. but the fs size have grown (16.3T)
>
> So I think if the 64bit feature is enabled when mkfs, it will reserve
> more room in file system
> And we can grow it up bigger than 16TB.
> It seems there are some issues in "master" still, I'll try "pu" branch later.
>
> Thanks.
>
>                                       -HsuanTing
>
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ