16TBの制限を超えてext4パーティションのサイズを変更するにはどうすればよいですか？

64ビットフラグなしで作成された古いext4パーティションのサイズを変更しようとすると、新しいサイズが16TiB以上の場合、resize2fs 1.42は失敗します。

$ resize2fs -p /dev/mapper/target-device
resize2fs: New size too large to be expressed in 32 bits

ファイルを外部メディアにコピーしたくありません。データ損失の危険性もありません。ボリュームのサイズを安全に変更するにはどうすればよいですか？

-O 64bitオプションがデフォルトになる前に作成されたファイルシステムのサイズを変更しようとしています。extファイルシステムを64ビットアドレスにアップグレードして、大幅に大きい（16 TiBではなく1024 PiB）ボリュームに拡張することができます。

ターゲットデバイスが呼び出されると仮定すると/dev/mapper/target-device、これはあなたがする必要があることです：

前提条件

1. ボリュームのこのサイズは、RAIDによってサポートされる必要があります。そうしないと、定期的なディスクエラーが発生します。
2. それでも、RAIDはバックアップではありません。貴重品は他の場所にも保管する必要があります。
3. まず、周囲のすべてのボリューム（パーティションテーブル、暗号化、lvm）のサイズを変更して確認します。
4. ハードウェアRAID構成を変更した後、Linuxは新しい最大サイズをすぐに確認する場合としない場合があります。$ cat /proc/partitions必要に応じて確認して再起動します。

最新の安定したカーネルとe2fsprogsを使用する

1. uname -r64ビットext4ファイルシステムを適切に処理できるカーネルを実行していることを確認（チェック）します- 4.4.xカーネル以降（デフォルトのUbuntu 16以降）を使用する必要があります。

2. 少なくともバージョンのe2fsprogsを取得する 1.43

   • Ubuntu 16.04（2016-04-21）はe2fsprogs 1.42.12（2014-08-25）でリリースされました
   • e2fsprogs 1.43 （2016-05-17）は、extfsアドレスサイズをアップグレードできる最初のリリースです。
   • Ubuntu 18.04（2018-04-26）e2fsprogs 1.44.x（good！）に同梱

現在16.04、Ubuntuリリースにアップグレードできない場合は、ソースパッケージサポートを有効にして、新しいバージョンを手動でインストールする必要があります。

$ resize2fs
# if this  prints version 1.43 or above, continue to step 1
$ sudo apt update
$ sudo apt install git
$ sudo apt build-dep e2fsprogs
$ cd $(mktemp -d)
$ git clone -b v1.44.2 https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git e2fsprogs && cd e2fsprogs
$ ./configure
$ make
$ cd resize
$ ./resize2fs
# this should print 1.43 or higher
# if this prints any lower version, panic
# use `./resize2fs` instead of `resize2fs` for the rest of the steps

リサイズ

ステップ1：ファイルシステムを適切にアンマウントする

$ sudo umount /dev/mapper/target-device

ステップ2：ファイルシステムのエラーを確認する

$ sudo e2fsck -fn /dev/mapper/target-device

ステップ3：ファイルシステムで64ビットサポートを有効にする

相談man tune2fsしてくださいman resize2fs-あなたはいくつかのファイルシステムフラグを変更することがあります。

$ sudo resize2fs -b /dev/mapper/target-device

一般的なHDD RAIDでは、これには4分間の高IOおよびCPU負荷がかかります。

ステップ4：ファイルシステムのサイズを変更する

$ sudo resize2fs -p /dev/mapper/target-device

コマンドラインでサイズを渡さない場合、resize2fsは「利用可能なすべてのスペースに拡張する」と想定します-これは通常、まさにあなたが望むものです。-pいくつかの初期段階の後で、それらの表示のみ-フラグは、プログレスバーを有効に。

一般的なHDD RAIDでは、これには4分間の高IOおよびCPU負荷がかかります。

もう一度確認する

ファイルシステムをもう一度確認してください

$ sudo e2fsck -fn /dev/mapper/target-device

新しいバージョンのe2fsckは、以前のバージョンが不適切に処理したタイムスタンプまたはエクステントツリーを修正することを提案する場合があります。これは深刻な問題を示唆するものではなく、今すぐまたは後で修正することを選択できます。

エラーが発生した場合は、ないないパニックやんではないボリュームへの書き込みを試みます。さらに操作を行うとデータが破壊される可能性があるため、ファイルシステムに関する広範な知識を持つ人に相談してください！

エラーが発生しない場合、デバイスを再マウントします。

$ sudo mount /dev/mapper/target-device

成功！

アップグレードされたファイルシステムの操作を継続するために、e2fsprogsの非Ubuntuバージョンは必要ありません-カーネルは現在、かなり長い間それらをサポートしています。アップグレードの開始のみが必要でした。

参考のために、不適切なオプションを使用して巨大なデバイスを作成するように求められた場合、mke2fsが印刷する同様のエラーメッセージがあります。

$ mke2fs -O ^64bit /dev/huge
mke2fs: Size of device (0x123456789 blocks) is too big to be expressed in 32 bits using a blocksize of 4096.

最近、Ubuntu 18.04が16.04 Ubuntuで最初にインストールされた後に更新されたため、ストレージアレイ（/ dev / sdb）が最初に2つの14 TBパーティションに分割されていました。問題が発生した28 TBの最初のパーティション。

resize2fsの新しいバージョンをダウンロードする必要はありませんでした。それは非常に新しいからです。

# resize2fs 
resize2fs 1.44.1 (24-Mar-2018)

唯一の問題は、32ビットでフォーマットされた64ビットパーティション1を変換することでした...読者にtune2fsのドキュメントを参照するように依頼する代わりに（Axが示唆するように）、実際の例を提案します！

# tune2fs -O 64bit /dev/sdb1
tune2fs 1.44.1 (24-Mar-2018)
Please run "resize2fs -b /dev/sdb1" to enable 64-bit mode.

# resize2fs -b /dev/sdb1
resize2fs 1.44.1 (24-Mar-2018)
Convert the file system to 64 bits.
The file system on /dev/sdb1 now has a size of 3662109119 blocks (4k).

最後に、ディスクパーティションを拡大します！

# resize2fs /dev/sdb1
resize2fs 1.44.1 (24-Mar-2018)
Resizing the file system on /dev/sdb1 to 7324303099 (4k) blocks.
The file system on / dev / sdb1 now has a size of 7324303099 blocks (4k).