GParted を使用して、外付け USB ハード ドライブを 2 つのパーティションに分割しました。どちらも FAT32 としてフォーマットされたプライマリ パーティションで、サイズは同じ (500 GB) です。出力は次のようになりますfile -s。
/dev/sdb1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 64, reserved sectors 64, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 2048, sectors 976760832 (volumes > 32 MB), FAT (32 bit), sectors/FAT 119232, reserved 0x3, serial number 0x99034dfb, label: "TOSHIBA1 "
/dev/sdb2: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 64, reserved sectors 64, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 976762880, sectors 976760832 (volumes > 32 MB), FAT (32 bit), sectors/FAT 119232, reserved 0x1, serial number 0x96cbe274, label: "TOSHIBA2 "
では/dev/sdb2、 とは何ですか。hidden sectorsまた、なぜ より大きいのですか。その差は 2048 で、これは のsectorsの値と同じです。これは偶然でしょうか。GParted またはコマンドのエラーでしょうか。さらに重要なのは、これは心配すべきことでしょうか。hidden sectors/dev/sdb1file
答え1
要約
心配することはありません。
ウィキペディアの記事FATファイルシステムの設計「隠しセクター」については数回言及されており、関連するメタデータエントリの一般的な説明は次の通りです。
この FAT ボリュームを含むパーティションの前の隠しセクターの数。パーティション化されていないメディアでは、このフィールドは常に 0 になります。
(多少の癖はありますが) この説明は、特定のケースで観察される値に適合しているようです。
Linux ツールはデフォルトでこの値を使用しないと思います。あなたの場合、それぞれの値2048と は976762880のコンテキストで有効ですが、 とをそれぞれ/dev/sdb考慮すると、これらのデバイスはパーティション分割されていないため、そのコンテキストでは「隠しセクター」は になるはずです。/dev/sdb1/dev/sdb20
のようにマウントするのが一般的ですmount /dev/sdb1 /some/mountpointが、パーティションが512バイトの2048セクターのオフセットから始まる場合は、次のように同じことができます。
mount -o offset=$((2048*512)) /dev/sdb /some/mountpoint
したがって、Linux に関する限り、どのコンテキストが「正しい」ものであるかは明確に示されていません。「隠しセクター」の値が重要ではないことを示すもう 1 つのヒントは、パーティション テーブルに属する情報がファイルシステムのメタデータ構造に埋め込まれているという事実です。今日では、このような抽象化レイヤーを混在させる傾向はありません。2 つの情報を「非同期化」するのは比較的簡単です。また、OS はそもそもファイルシステムを見つけるためにパーティション テーブルを読み取る必要があるため、オフセットを既に知っている場合にのみ利用できるオフセットに関する冗長な情報はほとんど役に立ちません。
もう一つの冗長な情報があります: パーティションテーブルにはパーティションID(MBR) またはパーティションタイプ GUID(GPT) はパーティション内の実際のファイルシステムに対応しているはずですが、そうでない場合もあります。しかし、この情報が一貫性があれば、パーティションテーブルを調べるだけで何が期待できるか (OS、マルチブートの可能性、スワップパーティション) を知ることができるので非常に便利です。実際には、これは人間にとって役立つ場合もあれば、マシンにとって役立つ場合もあります。特に UEFI はどのパーティションがEFI システム パーティションただし、Linux に指示すると、mount /dev/sdb1 …検査するのではなく、実際のファイルシステムを検出して/dev/sdbパーティション テーブルを読み取り、パーティション ID/GUID を使用するようになります。
「隠しセクター」の背後にある根拠が何だったのかは分かりません。しかし、何らかの形でこの値に依存しているデバイスがいくつかあったようです。比較man 8 mkfs.fat:
-h number-of-hidden-sectors
ボリューム内の隠しセクターの数を選択します。どうやら、一部のデジタル カメラでは、このような隠しセクターのない CF カードを挿入すると消化不良を起こすようですが、このオプションを使用すると、それらの問題を解決できます。0コマンド ラインで値が指定されていない場合は、これが想定されます。
GPartedは「一部のデジタルカメラ」などにも対応しようとしたようです。これは良いこと別のツールでやり直す必要はまったくありません。
答え2
「隠しセクター」は、FATまたはNTFSブートセクターに格納されているパーティションオフセットの誤った名称であり、データ構造（これも誤解を招く）BIOS パラメータ ブロック; ここで、「BIOS」はシステム ファームウェアではなく、MS-DOS のコンポーネントを指します。値は、ディスク上のブート セクターに先行するセクターの数です (そのはずです)。それ以上でもそれ以下でもありません。パーティション化されていないメディア上に存在し、ディスク全体にまたがる FAT ファイル システムの場合、この値は 0 である必要があります。
FAT または NTFS ブート セクターがロードされると、ディスク上のパーティションを見つけるために「隠しセクター」値が使用されます。そこから、ブート セクターはファイル システム構造を見つけ、IO.SYS (MSLOAD)、NTLDR、BOOTMGR などの後期ブートローダーをロードできます。それ以外では、この値は通常使用されません。したがって、BIOS システムでそのファイル システムからブートする予定がない場合は、まったく問題になりません... ただし、どのようなクレイジーな FAT 実装に遭遇するかはわかりません。