Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   =?utf-8?B?0JHQu9Cw0LPQvtC00LDRgNC10L3QutC+INCQ0YDRgtGR0Lw=?= 
        <artem.blagodarenko@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: 1024TB Ext4 partition
Message-Id: <8A6F6DF3-F920-4291-91C2-E4AAF1E63ADE@gmail.com>
Date:   Thu, 24 Oct 2019 16:23:15 +0300
Cc:     Andreas Dilger <adilger@dilger.ca>,
        "Theodore Y. Ts'o" <tytso@mit.edu>
To:     linux-ext4 <linux-ext4@vger.kernel.org>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

Hello,

Lustre FS successfully uses LDISKFS(ext4) partitions with size near =
512TB.
This 512TB is current "verified limit". This means that we do not expect =
any troubles in
production with such large partitions.

Our new challenge now is 1024TB because hardware allows to assemble such =
partition.
The question is: do you know any possible issues with EXT4 (and =
e2fsprogs) for such large partitions?

I know about this possible problems:
1. E2fsck is too slow. But parallel e2fsck project is being developed by =
Li Xi
2. Block groups reading takes a lot of time. We have fixes for special =
cases like e2label.=20
    Bigalloc also allows to decrease metadata size, but sometimes =
meta_bg is preferable.
3. Aged fs and allocator that process all groups to find good group. =
There is solution, but with some issues.
4. 32 bit inode counter. Not a problem for Lustre FS users, that prefer =
use DNE for inode scaling,
    but probably somebody wants to store a lot inodes on the same =
partition. Project was not finished.
    Looks nobody require it now.
   =20

Could you please, point me to other possible problems?

Thanks.
Artem Blagodarenko.