最近、2台のWD Easystore 8TB外付けUSBドライブを購入して、それらをシャックし、WD Red NASドライブをコンピューターの内部で使用しました。(ArchLinux)最初はWD Whiteラベルドライブ(WD80EMAZ)になりました。 -00WJTA0)、2番目は確かに赤でした。(WD80EFAX-68LHPN0)
私は白いものをインストールしました、そしてすべてがうまく見えました。 5TB近くのデータを問題なくコピーしましたが、後で、作業中の別のドライブでgpartedを使用するとGPTエラーに関するメッセージが表示されました。私のデータはアクセス可能のようですので、まだ何もしていません。
今日、Redドライブをインストールしましたが、パーティション分割やフォーマットを行う前に、そのドライブでもまったく同じエラーが発生します。私は解決策を探していて、それはホスト保護領域(HPA)を持つことと関係があると思いますが、それを確実に確認する方法、または解決する場合はどうすればよいかわかりません。これは、ホワイトドライブのデータをそのままにして修正できますか? Redドライブで実験することはできますが、何を試すべきかわかりません。
$ Sudo gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.3
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Command (? for help): p
Disk /dev/sdb: 15628053168 sectors, 7.3 TiB
Model: WDC WD80EMAZ-00W
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 6837F2B2-3A65-4260-B87E-B4682BAEE5FF
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15628052446
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 15628050431 7.3 TiB 0700 WD_8TB
Command (? for help): v
Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.
Identified 1 problems!
そして..
$ Sudo hdparm -N /dev/sdb
/dev/sdb:
max sectors = 15628053168/15628053168, HPA is disabled
hdparm
の出力は、HPAがdisabled、であることを示しているため、問題はそれに関係ありません。
この問題の最も一般的な原因は、ここや他のフォーラムに投稿された同様の問題から判断すると、マザーボードベースのソフトウェアRAID(「偽のRAID」と呼ばれることもありますが、これは欺瞞的な用語です)の使用です。このタイプのソフトウェアRAIDの問題は、使用するデータ構造について合意するために、ファームウェアとOSの少なくとも2つのソフトウェアコンポーネントが必要になることです。マルチブートコンピューターの場合、すべてのOSが同じRAIDデータ構造を理解する必要があるため、一致させるには3つ以上の構成が必要になります。いずれにせよ、ファームウェアがディスクがマザーボードベースのソフトウェアRAIDを使用していると見なし、OSが使用していないと判断した場合、結果としてバックアップGPTデータ構造が損傷する可能性があります。その理由は、これらのデータ構造がディスクの最後の数セクターを占めるためです。これは、マザーボードベースのソフトウェアRAIDが通常格納する場所でもありますitsデータ構造。したがって、データ構造の1つのセットが他のセットを一掃します。奇抜さが続く。 (ただし、以下を参照してください。)すべてが同期している場合、それは透過的です。マザーボードはデータ構造をディスクの最後に配置し、OSはこれを理解してディスクのその部分を非表示にするので、心配する必要はありません。
ただし、パーティションテーブルを作成しなかった場合は、問題の原因がディスクの製造元、またはその間にディスクを処理した人(たとえば、 、ディスクが他の誰かに販売されてから返品され、返品ビンから入手した場合)。この場合、w
でgdisk
を実行すると、パーティションテーブルが書き直され、エラーメッセージが消えます。 GPTバックアップデータ構造は何らかの理由で存在するため、これを行うことをお勧めしますbackup、ある種のバグ、ユーザーエラー、またはハードウェア障害が損傷した場合に使用されますプライマリデータ構造(ディスクの先頭に保存されます)。ほとんどのOSとツールは、バックアップデータ構造が欠落している状態で正常に起動しますが、それらがないと、利点を放棄することになります。また、一部のツールが損傷によって混乱し、何か悪いことをする可能性があります。 (この例はわかりませんが、新しいツールが常に作成されており、古いツールでは新しいバグが発生する可能性があるため、そのようなバグの可能性は常に存在します。)
もう1つのポイント:gdisk
のv
は、バックアップパーティションデータがディスクの最後に存在しないことを示します。これを修正するには、x
と入力してエキスパートメニューに移動し、次にe
と入力してバックアップデータ構造を再配置します。この誤って配置されたバックアップパーティションテーブルは、ファームウェアでのマザーボードベースのソフトウェアRAIDの使用と一致していますが、OSによるものではなく、その他のさまざまな問題(拡張されたハードウェアRAIDアレイや、小さい方から小さい方から複製されたディスクなど)と一致しています。より大きなディスク)。通常、バックアップデータ構造を再配置することをお勧めします。場合によっては、ディスクの全容量を使用する必要があります。 (あなたの場合、約2,000セクターしか回復しないので、容量の点では大したことではありません。)ただし、マザーボードがソフトウェアRAIDを使用するように構成されている場合、バックアップデータ構造を移動すると消去されます。ソフトウェアRAIDデータ。これによりマザーボードが混乱する可能性があり、マザーボードがデータを書き換えて、次に再起動したときにGPTが損傷する可能性があります。解決策は、ファームウェアセットアップツールでソフトウェアRAIDオプションを無効にしてから、gdisk
またはその他のツールを使用してGPTデータ構造を移動することです。