On Wed, Aug 17, 2011 at 12:28 AM, Yongqiang Yang [off-list ref] wrote:

On Tue, Aug 16, 2011 at 8:22 AM, Justin Maggard [off-list ref] wrote:

quoted

Does this patch set combined with your e2fsprogs patch add 64-bit resize
support now, or does it just make it easier to add later?

YES. e2fsprgos's patch is ready too.

So I finally got around to gather the hardware and patching all the
software components to try out this 64-bit expansion code.  The first
thing I noticed is that there is still a check to make sure the block
count is 32 bits.  However, I can get around it by specifying a size
string (something like "20T") rather than a block count, in which case
it will actually try the expansion.

quoted

If I am making a 64-bit ext4 filesystem today (20TB), and hoping to resize
it next year to 30TB what features should I set?  In my searching it sounded
like maybe I would need meta_bg, but it is not compatible with the default
resize_inode.

You can understand meta_bg here http://linuxsoftware.co.nz/wiki/ext4.
Now, ext4 with meta_bg does not support resize.  It is in ext4's TODO list.
The feature you should set is resize_inode.

quoted

Also, if I am making a <16TB filesystem today, should I turn on the 64-bit
flag in order to expand to >16TB in the future?

Yes.  You should turn on 64 bit feature.  If the block number is 32
bit, the size it can support is 2^32 * 2^(log blocksize),  4K
blocksize as an example, it maximum size of a filesystem is 2^32 *
2^12 = 2^44 = 16TB.

I think this is where the real problem is with this 64-bit resize
support.  With the 64-bit flag set, the most I can expand by online is
just 8TB over the life of the filesystem, because my reserved GDT
blocks get used up twice as fast as with a 32-bit filesystem.  Is
there any way around this?

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