ホストコンピュータの.vdiサイズを15.5Gから120Gに調整しました。ゲスト(Ubuntuサーバー)を使用してパーティションのサイズを変更したいと思います。resize2fs
root@ubuntu:~# sudo resize2fs /dev/sda2 115G
resize2fs 1.42.13 (17-May-2015)
resize2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda2
Couldn't find valid filesystem superblock.
今私が理解したところによると、状況は/dev/sda2
崩壊しました。しかし、私のサーバーVMはまだうまく機能し、問題なくパーティションで実行されます。fdisk -l /dev/sda
出力:
Disk /dev/sda: 120 GiB, 128849018880 bytes, 251658240 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x32955267
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 999423 997376 487M 83 Linux
/dev/sda2 1001470 33552383 32550914 15.5G 5 Extended
/dev/sda5 1001472 33552383 32550912 15.5G 8e Linux LVM
今私の質問は、これがサーバー上で正常で健全ですか?うまくいかない場合はどうすれば修正できますか?
答え1
resize2fs
e2fsprogsファミリの他のツールは、read
システムコールが要求された合計サイズを返すか、エラーが発生すると仮定します。通常、これは真実ではありません。read
より少ない値を返すことが許可されているため、ループから呼び出す必要があります。私はLinuxカーネルがread
特定の状況でブロックデバイス上のすべてのデータを返すことを保証すると思いましたが、過去にはe2fsprogsがカーネルについて間違った仮定をしていたので、この問題は苦労しました。
e2fsprogsが繰り返されないという事実はread
実際にはバグです。せいぜいこれは制限です。おそらくコードの書き方は正しいです。一部ブロックデバイスにアクセスするときのLinuxカーネルバージョン。ただし、この制限はどこにも文書化されていません。画像ファイルにアクセスすると、このコードに間違いなく何か問題があるようです。
カーネルログでエラーを確認してください。カーネルがエラーを報告する場合、問題はresize2fsのバグではありません(または少なくとも誤ったエラー報告にすぎません)。
カーネルがディスクエラーを報告しない場合は、次を実行します。
strace -o resize2fs.strace sudo resize2fs /dev/sda2 115G
そして、read
システムコールを確認してください。
読む(3,"...",必要) =読む
その場合は、簡単にお読みください。必要≠読む。これを観察して再現できる場合は、バグレポートを作成する価値があります。これをどのようにトリガーしたかを正確に説明してください。正確なカーネルバージョン、カーネルのコンパイル方法、resize2fsの正確なバージョン、それを管理するハードウェアドライバ/dev/sda
、実行される仮想マシンソフトウェア。アップストリームは一般的に非専門家と話すのに慣れていないため、アップストリームではなくUbuntuにバグを報告することをお勧めします。