4 TBドライブをDellH200コントローラーに接続しています。ドライブはGPTを使用してWindowsでフォーマットされており、Windowsでは4TBを正しく表示します。
Linux(Ubuntu 16.04)で起動した同じコンピューターの同じドライブは、4TBであると完全には認識されません。
ランニング gdisk /dev/sdb -l
結果
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Warning! Secondary partition table overlaps the last partition by
3519068194 blocks!
You will need to delete this partition or resize it in another utility.
ディスク/ dev/sdb:4294967295セクター、2.0 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): F8EA0B25-8D84-4BBB-88EB-BA90615C5318
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 4294967261
Partitions will be aligned on 8-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 34 262177 128.0 MiB 0C01 Microsoft reserved ...
2 264192 7814035455 3.6 TiB 0700 Basic data partition
上記の太字の「2.0TiB」に注目してください
私もそれをマウントすることはできません。/dev/sdb1をマウントすると、「mount:wrong fs type ...」エラーが発生し、/ dev/sdb2をマウントすると「
mount: special device /dev/sdb2 does not exist
最初はH200コントローラーのファームウェアの問題だと思っていましたが、LinuxではなくWindowsで動作する理由と、マウントできない理由は説明されていません。 Linuxにドライブを認識させるにはどうすればよいですか? Linuxを使用してドライブを再フォーマットする必要がありますか?将来、どちらかのオペレーティングシステムがドライブを正しく認識できるようにするにはどうすればよいですか?
更新:
さて、今は少しばかげています。それはずっとH200コントローラーファームウェアの問題だったことがわかりました。
最初にH200コントローラーのファームウェアを更新しようとしましたが、gdisk
は正しく返されます。
Disk /dev/sdb: 7814037168 sectors, 3.6 TiB
および/ dev/sdb2は問題なくマウントされます。私が今理解しようとしているのは、古いH200ファームウェアを搭載したLinuxではなく、Windows(7)でディスクが正しく読み取られていた理由です。
状況は私にははっきりしているように見えますが、それが起こった理由はあまりはっきりしていません。出力状態:
Warning! Secondary partition table overlaps the last partition by 3519068194 blocks!
GPTには2つのパーティションテーブルがあります。1つはディスクの先頭にあり、2つ目(またはバックアップ)はディスクの最後の33セクター(16K)にあります。 これまでに役立つArch Linuxwiki を参照してください。この。
ディスクを手動でパーティション分割するときに、バックアップPTの余地を残さないことがよくあります。これにより、ディスクユーティリティから、セカンダリパーティションテーブルがないという苦情が寄せられ、最後のパーティションのサイズを33セクター縮小してサイズを変更するよう警告されます。 。
バックアップPTが3.5x10 ^ 9セクター(\約1.8TB)になるのが早すぎることを除いて、まったく同じケースがあります。言い換えると、gdisk
ユーティリティは、誤って配置されたバックアップPTを認識し、これがディスクの終わりであると見なします。したがって、ディスクサイズが小さくなり(4TBではなく2TiB)、ディスク(推定)エッジをはるかに超えて拡張するパーティションをマウントできなくなります。
これはどのようにして起こったのですか?推測することしかできませんが、バックアップPTが正確に2TiB、理論上の上限の最後に表示されるのはかなり独特です( 右端を参照)このウィキペディアの記事のボックス )FAT32ファイルシステム(512Bセクター)用。 gdisk
、0x0700
の出力からのファイルシステムのコードは、あまり有益ではありません。 RodSmithの本によると 、
Windowsは、FATまたはNTFSを問わず、すべてのデータパーティションに単一のGUIDコードを使用します
これは本質的にコード0x0700です。したがって、それがFAT32であるかNTFSであるかはわかりませんが、FAT32である場合は、自分が直面している難問を理解できます。さらに厄介なのは、使用可能なディスクよりも大きいパーティション(sdb2
)の存在です。
... last usable sector is 4294967261
一方、sdb2
のエンドセクターは7814035455であり、エラーメッセージが表示されます。
mount: special device /dev/sdb2 does not exist
おそらく、いくつかのエラー/バグ/ whatchamacallitを伴う、パーティション分割のいくつかの試みの結果が表示されています。
また、gdisk
はあなたの選択について固執しています:
You will need to delete this partition or resize it in another utility.
どちらのオプションもデータの損失を意味します。あなたのディスクに何が入っているのか、それが真新しいのか、それとも念願の個人データでいっぱいなのか、私にはわかりません。もちろん、すべてをバックアップし(Windowsから)、ディスクを再フォーマットし(Linuxの場合)、実際に何かを保存する前にWindowsでディスクを試してみるのは、合理的な行動のように思えます。また、ディスクサイズの制限がない(または少なくとも4TiBディスクに関連するものがない)NTFSのようなファイルシステムを選択することをお勧めします。 このウィキペディアの記事の右端のボックスでこれを参照してください 。