/dev/sda2を開こうとするときは、短く読んでください。

/dev/sda2を開こうとするときは、短く読んでください。

ホストコンピュータの.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

resize2fse2fsprogsファミリの他のツールは、readシステムコールが要求された合計サイズを返すか、エラーが発生すると仮定します。通常、これは真実ではありません。readより少ない値を返すことが許可されているため、ループから呼び出す必要があります。私はLinuxカーネルがread特定の状況でブロックデバイス上のすべてのデータを返すことを保証すると思いましたが、過去にはe2fsprogsがカーネルについて間違った仮定をしていたので、この問題は苦労しました。

e2fsprogsが繰り返されないという事実はread実際にはバグです。せいぜいこれは制限です。おそらくコードの書き方は正しいです。一部ブロックデバイスにアクセスするときのLinuxカーネルバージョン。ただし、この制限はどこにも文書化されていません。画像ファイルにアクセスすると、このコードに間違いなく何か問題があるようです。

カーネルログでエラーを確認してください。カーネルがエラーを報告する場合、問題はresize2fsのバグではありません(または少なくとも誤ったエラー報告にすぎません)。

カーネルがディスクエラーを報告しない場合は、次を実行します。

strace -o resize2fs.strace sudo resize2fs /dev/sda2 115G

そして、readシステムコールを確認してください。

読む(3,"...",必要) =読む

その場合は、簡単にお読みください。必要読む。これを観察して再現できる場合は、バグレポートを作成する価値があります。これをどのようにトリガーしたかを正確に説明してください。正確なカーネルバージョン、カーネルのコンパイル方法、resize2fsの正確なバージョン、それを管理するハードウェアドライバ/dev/sda、実行される仮想マシンソフトウェア。アップストリームは一般的に非専門家と話すのに慣れていないため、アップストリームではなくUbuntuにバグを報告することをお勧めします。

関連情報