web-dev-qa-db-ja.com

ファイルシステムを縮小した後、パーティションのサイズを小さすぎる値に変更しました

ext4ファイルシステムをresize2fsで縮小しました。

resize2fs -p /dev/sdn1 3500G

（FSは2.3 TBに使用されます）

次に、パーティションのサイズを分割してサイズを変更し、新しい端を設定するときに0.3％のマージン（〜10 GB）を残しました。

(parted) resizepart 1 3681027097kb

最終的に、これはきつすぎることが判明しました。

# e2fsck -f /dev/sdn1
e2fsck 1.42.9 (4-Feb-2014)
The filesystem size (according to the superblock) is 917504000 blocks
The physical size of the device is 898688000 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

次に、パーティションのサイズを再度変更しました。今回は3％のマージンを使用します。

(parted) resizepart 1 3681027097kb

この後、ファイルシステムチェックは合格です。

# e2fsck -f /dev/sdn1
e2fsck 1.42.9 (4-Feb-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdn1: 278040/114688000 files (12.4% non-contiguous), 608536948/917504000 blocks

2つのresizepartコマンドの後にpartprobe /dev/sdnを実行しました。

プロセス全体でファイルシステムをマウントしていません（まだマウントしていません）。

パーティションのサイズを小さすぎる値に変更した中間ステップで、fsが破損した可能性がありますか？

e2fsckの正常な実行は、データが破損していないことを確認するのに十分ですか？

partitionfsckpartedresize2fse2fsck
1
Vincenzo Pii

パーティションのサイズを小さすぎる値に変更したため、fsが破損しましたか？

特にあなたがそのfs（c）killerを止めてくれたので、あなたの場合はありそうにありませんが、その可能性を完全に排除することはできません。

たとえば、msdosパーティションテーブルの拡張パーティション内の論理パーティションの場合、破損が発生します。論理パーティションはリンクリストであるため、論理パーティション間には、リスト内の次のパーティションを指すために使用されるセクターがあります。このような論理パーティションを縮小/サイズ変更すると、ディスクの中央のどこかに（部分的に）上書きされたセクターがあります。

また、一部のパーティショナープログラムは、ゼロ化を楽しむ場合があります。これはLVMにも当てはまり、各lvcreateで、作成されたLVの最初の4Kのようにゼロになります。さらに、失敗したlvresizeを元に戻すと、以前に使用されたのと同じエクステントが返されるという保証はありません。運が悪ければ、LVは物理的に別の場所にある可能性があります。そのため、lvresizeの前に作成された/etc/lvm/{backup,archive}/からvgcfgrestore何かによってのみそのような事故を元に戻すことができます。

SSDには、このTRIMの流行があり、あらゆる種類のプログラムがSSDに不当なTRIMコマンドを発行します。 LVMは、lvm.confのissue_discards=1（常に0に設定）の場合にこれを行います。これは、さまざまなパーティショニングプログラムがこの動作を採用しないことを期待するためです。

E2fsckの正常な実行は、データが損傷していないことを確認するのに十分ですか？

ほとんどのファイルシステムは、独自のメタデータ以外のデータ破損を検出できません。あなたはこれらのようなスタントを引くことになっていないので、これは通常問題ではありません。バックアップがある場合は、ファイルのタイムスタンプ/チェックサムをバックアップにあるものと比較できます。

プロセス全体でファイルシステムをマウントしていません（まだマウントしていません）。

次のように読み取り専用でマウントできます。

mount -o loop,ro /dev/sdn1 /mnt/somewhere

次に、ファイルをチェックアウトします。

loop,roは、読み取り専用ループデバイスを作成してマウントするようにマウントに指示します。驚いたことに、ro自体は、ext4を含む一部のファイルシステムの読み取り専用性を保証しません。 （また、btrfsのような複数デバイスのファイルシステムの場合、loop,roは、すべてではなく1つのデバイスにのみ影響するため、影響しません）。

2
frostschutz