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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 23 Jun 2010 16:42:29 +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

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