On Wed, Aug 17, 2011 at 12:28 AM, Yongqiang Yang <xiaoqiangnk@xxxxxxxxx> wrote: > On Tue, Aug 16, 2011 at 8:22 AM, Justin Maggard <jmaggard10@xxxxxxxxx> wrote: > > 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. > > 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. > > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
