linux-ext4 - Re: E2fsprogs master branch now has all 64-bit patch applied

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-next>] [day] [month] [year] [list]

Message-ID: <20100621170556.GB6843@thunk.org>
Date:	Mon, 21 Jun 2010 13:05:56 -0400
From:	tytso@....edu
To:	Hsuan-Ting <acht93@...ccu.edu.tw>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: E2fsprogs master branch now has all 64-bit patch applied

On Mon, Jun 21, 2010 at 09:44:31PM +0800, Hsuan-Ting wrote:
> Hi Ted,
> 
>    Resize seems not work when the size is bigger than 16TB (offline resize).
> 
> My test machine:
> x64 platform 2.6.32 kernel + this newest patch
> 
> 1. <16TB ext4 enlarge to >16TB (offline)
>     a. I use "8 x 2TB WD disks" and "mdadm" build linear raid
>     b. then use mkfs.ext4 to make ext4 file system
>     c. grow the linear raid to "10 X 2TB"
>     d. finally it grow to "2.X TB" smaller than before

This doesn't surprise me.  We should add some checks to simply not
allow the file system growing greater than 16TB if the 64-bit feature
is not set for now.  Making this work is going to be tricky, because
enabling the 64-bit feature doubles the size of the block group
descriptors, which means we have to make room for them.  This could
involve moving files out of the way, as well as moving the inode
table.

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.

> 2. >16TB offline resize, the steps is similiar as before.
>    a. I use "9 x 2TB WD disks" build linear raid
>    b. mkfs.ext4 and not mount
>    c. grow the linear raid to "10 X 2TB"
>    d. do resize
>    e. finally it grow to "2.X TB" smaller than before
> 
> I try to on "EXT4_FEATURE_INCOMPAT_64BIT" and "EXT2_FLAG_64BITS"
> when mkfs and resize.
> And modify ext2fs_div_ceil code to ext2fs_div64_ceil.
> It seems work something, the fs size isn't grow but also not deduce,
> remain the same.

I'm not sure I understand that last sentence; it's not parsing as an
understandable English sentence, sorry.  Are you saying that both
attempts to grow and shrink the filesystem is failing?  If so, how?
Are you getting an error message?  Is it appearing to succeed but the
file system size isn't changing?

Thanks for the bug report,

					- Ted
--
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