フォーマット、その2~論理フォーマット

フォーマット、その1~物理フォーマット」】

三、論理フォーマット

1. 論理フォーマットとは

 物理フォーマットないしローレベル・フォーマット対して、論理フォーマット(Logical Format)がある。
 論理フォーマットとは、コンピュータ等の電子機器において記録媒体にデータを読み書きできるようにするためのデータの管理・記録方式(これをファイルシステムという)を適用することをいう。従って、論理フォーマットは、厳密には、ファイルシステム・フォーマット(File System Format、Filesystem Formatとも表記される)を指す。PC等で行われる「フォーマット」は、通常この論理フォーマットであるFile System Formatを指す。既に作成されているパーティションが「未フォーマット」と表示される場合の「フォーマット」は、まさにこの意味である。

 また、MBR又はGPTの設定、パーティションの作成及びPBRの設定を含むファイルシステムの適用という一連の作業又はその作業によってできたものを「フォーマット」と呼ぶこともある。これは広義の論理フォーマットということができよう。例えば、Windowsのコマンドプロンプトで「DiskPart は選択されたディスクを MBR フォーマットに正常に変換しました。」と表示される場合の「フォーマット」は、この広義の論理フォーマットといえる。

 PCにおいては、ファイルシステム・フォーマットによって、ストレージとして使用される記録媒体は、大きく2つに分けることができる。1つは、パーティションを前提として、その内部にファイルシステムを適用するものであり、主にHDDやSSDがそれにあたる。もう1つは、パーティションという区画を用いることなくファイルシステムが適用されるものであり、主にCD、DVD、BD等の光学ディスクがそれにあたる。

 なお、パーティションとボリュームという語が使われる。パーティションはデバイス上の物理的な区画に焦点を当てた用語であり、ボリュームはそのパーティションをどのように管理するかといった観点から用いられる用語である。通常、両者は、同一の対象を指すが、RAIDを構成することによって複数のパーティションを1つのボリュームとして管理する場合には、それぞれの示す対象が異なることになる。Windowsにおいては、Partition Manager(Partmgr.sys)、Volume Manager(Volmgr.sys)、各File System Driver、I/O Manager等が相互に関連しつつディスクを制御・管理している。

2. HDD・SSD等におけるファイルシステム・フォーマット

 PCでは、HDD等のストレージにおいて、パーティションを作成し、そのパーティションで使われるファイルシステムというデータ管理方式を指定し、適用することがこの場合の論理フォーマットである。PC以外のHDDレコーダなどの機器では、パーティションという区画を用いない管理方式や独自の管理方式が採用されていることもあるため、PCでは他の機器で使用していたHDDの内容を認識できないことが多い。

 OSによって使用可能なファイルシステムは異なり、パーティション毎に特定のファイルシステムが指定され適用されて、初めてユーザがそのパーティションにおいてファイルの書き込み・読み出しを行うことが可能となる。ファイルシステムには、Macであれば、HFS+、Windowsであれば、FAT32(FAT: File Allocation Table)・exFAT・NTFS(New Technology File System)、Linuxであれば、ext3・ext4などがある。1つのHDD内の複数のパーティションに対してそれぞれ異なるファイルシステムを適用することは当然可能である。

(1) パーティションの作成

 ゼロフィルが行われて真っさらとなったHDDに対しては、先ず、パーティションの作成・管理方式をMaster Boot Record(MBR)かGUID Partition Table(GPT)のいずれかに決定しなければならない。これは「ディスクの初期化」とも呼ばれる(拙文「初期化について」l参照)。その後、それに基づいてパーティションの作成を行うことになる。

 なお、ここで扱うパーティションは、プライマリ・パーティションという物理パーティションである。かつてMBR方式しか存在しない時代に、論理パーティション(拡張パーティション)は、プライマリ・パーティションが4つしか設けることができないという制約から生み出されたものであり、OSによっては起動パーティションに使用できないという制約も持つ。今日では、GPT方式をとれば、理論的には物理パーティションの数は無制限である(OSによっては最大128個に制限される場合もある)ことから、論理パーティションを使用する必要がある場面はほとんどないであろう。

● MBRディスクの場合

 HDDやSSDの先頭のセクタであるセクタ 0に存在するMBRは、主にOS等のプログラムを起動するためのコードを格納する領域とディスクの管理用情報を格納する領域で構成されている。

 前者の領域として、Bootstrap Code Area(ブートストラップ・ローダ領域、マスター・ブート・ローダ領域、マスター・ブート・コード領域、イニシャル・プログラム・ローダ(IPL)領域などとも呼ばれる)その他が、先頭から440バイト割り当てられる。これは、通常、アクティブなパーティションを探し、さらに起動可能なパーティションの先頭セクタを見つけ、それをメモリにロードして、そこにある実行可能なコードに制御を渡す役割を担う。OSが起動する前に働くこの領域に着目してここにウイルスが仕掛けられることがあるので、留意しておくべきである。

 後者の領域として、それに続く(アドレス、0x01B8)4バイト(DWORD)がDisk Signature(Disk Identifier、NT Signatureとも)と呼ばれるディスクを識別するための固有の値を格納し[※1]、その後の(0x01BC)2バイト(WORD)は通常使われないが、0x5A5Aとするとディスクの複製が禁止される。続く(0x01BE)64バイトにパーティション・テーブル(Partition Table)が割り当てられ、4つのエントリに各16バイトが割り当てられる。最後の2バイトがブート・シグニチャ(Boot Signature:0xAA55)となっている。

註※1 Disk Signature:
 Disk Signatureは、MBRを作成する際などにランダムで生成され、ディスクを識別するために使用される。Windowsでは、Disk Signatureはレジストリ(HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices等)やBoot Configuration Database(BCD)にも記録され、そのディスクに関する情報にアクセスするためにインデックスとして用いられる(TechNet、「Master Boot Record」)。そのため、Windowsを含めてマルチブートを構成する際には注意を要する(Disklessfun、「Tips: マルチブートするなら2段階ブート方式に統一しよう」)。

 さらに、ディスクのクローンを作成したことによりPC内のあるディスクと同一のDisk Signatureを持つディスクがそのPCに接続される場合があり、Disk Signatureの競合(Disk Signature Collision)が起こることがある(Windows 7以降)。その場合「ディスクの管理」画面に「オンラインである他のディスクと署名が競合しているために、ディスクはオフラインです」との警告が出て、エクスプローラで操作することができない状態となる。そのディスクが単なるデータ用のディスクであれば、「ディスクの管理」でディスクを右クリックし、「オンライン」を選択すれば、自動的に新たなDisk Signatureが生成され、そのPCで使うことが可能となる。DiskPartのonline diskコマンドを使っても同じである。

 しかし、これがWindowsのインストールされたディスクであって、PCを起動させるために使用するというのであれば、オンラインにしない方がよい。オンラインにしてしまうと、MBRに書き込まれた新たなDisk SignatureとBCDやレジストリに記録された以前のDisk Signatureとに齟齬が生じてOSが起動できないことになる。止むを得ず、あるいは誤ってオンラインにしてしまった場合の対処法としては、BCD及びレジストリに記録されている古いDisk Signatureを全て新たなDisk Signatureに手動で書き換えるという方法があるが、これはかなり厄介な作業となる。簡便な方法としては、そのディスクのBCDというハイブ・ファイルを他のWindowsのレジストリにロードして元の古いDisk Signatureを調べ(BCDハイブの「Windows Boot Manager」というElementを持つキーと同じ配下11000001キーのElement内のオフセット0x38に記録されている)、DiskPartのuniqueidコマンドで(Windows 7以降で使用可能)、「uniqueid disk id=XXXXXXXX」とその調べた値(リトルエンディアン)を入力して、元のDisk Signatureに戻すというやり方がある。これに関しては、TechNetの「Fixing Disk Signature Collisions」(Mark Russinovich)に詳細な解説がある。また、Lifewireの「What is a Disk Signature?」(Tim Fisher)も参考になる。

 また、後述のGPTディスクにおいては、ディスクの識別にDisk GUIDが用いられ、そのGUIDがBCDのレジストリ・ハイブの同じ場所に登録されているため、この署名の競合(Signature Collision)はGUIDが競合する場合に発生することになろう。この場合、DiskPartのuniqueid diskコマンドは、GUIDにも対応しているので(TechNet、「Uniqueid」)、例えば、「uniqueid disk id=baf784e7-6bbd-4cfb-aaac-e86c96e166ee」と入力することになろう。

 なお、USBフラッシュメモリにおいては、WindowsのグレードによってDisk Signatureの扱いが異なることに注意を要する。「フォーマット、その1~物理フォーマット」の二、の3.の(2)「USBフラッシュメモリにおけるCleanコマンド」で述べたように、DiskPartでclean(clean all)コマンドを実行した際、Windows 7では、Disk Signatureは消去されるが、Windows 10では、書き換えられるだけである。さらに、Windows 7においてUSBメモリをFATでフォーマットすると、Disk Signatureは付与されないが、Windows 10でフォーマットすれば、FATであってもFAT32と同様Disk Signatureが付与される。

 そのパーティション・テーブルの各エントリには、以下のようなパーティションの基本情報が格納されている。

各パーティション・エントリの構成
バイト
オフセット
フィールド長内容
0x001バイトBoot Indicator(Boot Flagとも)と呼ばれる。この値が0x80であれば、そのパーティションがアクティブパーティションであることが示され、起動可能なパーティションとしてBIOSから認識されることになる。0x00であれば、そのパーティションは非アクティブであるとなる。それ以外の値は、無効である。
0x013バイトCHS(Cylinder-head-sector)によるパーティションの開始セクタを示す。
0x041バイトパーティション・タイプ(Partition Type;Partition ID、System IDとも呼ばれる)を表す。この値によってファイルシステムが区別される。その値は、OSが起動時にどのファイルシステム・ドライバを読み込むかを決定するために使われるのである。
0x053バイトCHSによるパーティションの終了セクタを示す。パーティション・テーブルのCHS値のビットアサイン(bit assignment)は少し理解しにくいが、Webページ「MBR(Master Boot Recode)の構造」(Hazymoon)の図示が分かりやすい。INT 13h(Interrupt 13h)を用いるBIOSが対応可能なCHSの範囲は、シリンダ番号は0~1023、ヘッド番号は0~255であるのに対して、かつては慣例としてセクタの番号は1から始めることになっていたため、セクタ番号は1~63となっている。そのため、理論上は、1024×256×63×512(バイト)=8,455,716,864バイト=8,064MiB=7.875GiBがBIOSがアクセスできる最大の領域となるはずである(DEW Associates Corporation、「BIOS Interrupt 13h Extensions」。Hazymoon、「HDDの話」)。ところが、実際には、パーティション・テーブルのオフセット0x05の最大値は、0xFF(255)となっておらず、0xFE(254)となっている。よって、1024×255×63×512=8,422,686,720バイト=8,032.5MiB=約7.84GiBがアクセス可能な最大領域となる。なぜヘッド番号の最大値が0xFEなのか、その理由については諸説あるようである(Wikipedia、「INT 13H」)。いずれにしろ、先頭から8,032.5MiBを超える位置にパーティションの最終セクタがくる場合には、この3バイトの値は意味のないものとなる。
0x084バイトRelative Sectorsと呼ばれる。LBA(Logical Block Address[ing])でパーティションの開始セクタを示す(リトルエンディアン:Little-Endian)。
0x0C4バイトTotal Sectorsと呼ばれる。パーティションの総セクタ数を示す(リトルエンディアン)。

 オフセット0x04のパーティション・タイプは、多くの値が定義されている。主なものは、以下の通りである。

 0x00は、Empty、
 0x01は、FAT12、
 0x04は、FAT16(16MB以上32MB未満)、
 0x06は、FAT16(32MB以上4GB未満)、
 0x0Bは、FAT32(CHSアドレシング対応)、
 0x0Cは、FAT32(拡張INT 13h、LBA対応)、
 0x0Eは、FAT16(拡張INT 13h、LBA対応)、
 0x07は、NTFS、exFAT、
 0x83は、ext3、ext4、
 等々。
 また、0xEDは、GPT Hybrid MBRを表し、0xEEは、GPT Protective MBRを表し、0xEFは、EFI Sysytem Partition(ESP)を表す。

 例えば、Windowsのformatコマンドやディスク管理スナップインを使ってフォーマットする場合、FAT32を選択すると、そのパーティションの最終セクタがディスクの先頭より8,032.5MiB以内にあればCHSアドレッシングで対応可能であるため、0x0Bとなるが、8,032.5MiBを超える位置に定めることになれば、LBAで対応するしかないため、0x0Cとなる。また、FATを選択するとき、パーティションのサイズが16MiB未満であれば、FAT12で0x01となり、16MiB以上32MiB未満であれば、0x04のFAT16フォーマットとなるが、32MiB以上4,096MiB未満であれば、0x06のFAT16となる。FATを選択する場合も、そのパーティションの最終セクタが8,032.5MiBを超える位置にくることになれば、LBA対応のFAT16を示す0x0Eとなる。

 MBRは、HDDやSSDのみならず、USBフラッシュメモリやSDカード[※2]等の先頭セクタにも存在し、凡そストレージ・デバイスの論理フォーマットの基準となるものということができる。

註※2 SDカード:
 SDカードの規格には、SD(最大2GB)、SDHC(2GB~32GB)、SDXC(32GB~2TB)があり、それぞれのファイルシステムは、順にFAT12・FAT16、FAT32、exFATとされている。但し、SDカードの規格を策定する規格団体であるSDアソシエーションは、SDカード固有の規格仕様ゆえにSDカードをフォーマットする際に、OS付属のフォーマット・ツールではなく、専用のSDメモリカード・フォーマッターを使用することを強く推奨している(SD Association、「SDメモリカードフォーマッター」)。

 以上、TechNetの「Master Boot Record」、Wikipediaの「Master Boot Record」・「Partition type」等を参照。

 図-1 実例-MBRのセクタ内容(disk editorはHxD.exeを使用。以下同じ)
 Format2-Figure1-MBR
 【これは、OSがインストールされているディスクのMBRの例である。第1エントリの先頭セクタは、「80h」とあり、Boot Flagが立っているので、これがアクティブパーティションであることが示され(「システムで予約済み」)、第2エントリのそれは「00h」と非アクティブになっている。Partition Typeは、両者とも「07h」となっているので、ファイルシステムはNTFSないしexFATである。第1エントリのStarting Sectorは「00h 08h 00h 00h」となっており、リトルエンディアンであるから、800hは十進数で2,048となり、そのTotal Sectorsは「00h 20h 03h 00h」で同じくリトルエンディアンであるから、32000hは十進数で204,800となる。従って、第1パーティションは、開始セクタがセクタ 2,048(LBA 2,048)で、サイズが204,800セクタ×512バイト=104,857,600バイト=100MiBとなる。同様に、第2パーティションの開始セクタは、「00h 28h 03h 00h」、32800hだからセクタ 206,848(LBA 206,848)で、そのサイズは、「00h 38h CCh 1Dh」、1DCC3800hだから499,922,944セクタ×512バイト=255,960,547,328バイト、約238.4GiBとなる。】

● GPTディスクの場合

 GPT方式を採るディスクであっても、先頭のセクタ 0(LBA 0)には、必ずMBRが書き込まれるが、それはHybrid MBR(ハイブリッドMBR)の場合とProtective MBR(保護MBR)の場合とがある(拙文「初期化について」参照)。Windows等では通常、Protective MBRが使われる。その場合、第1エントリのパーティション・タイプは0xEE、開始セクタは0x01 0x00 0x00 0x00、総セクタ数は0xFF 0xFF 0xFF 0xFFとなる。

 それに続くセクタ 1(LBA 1)には、プライマリGPTヘッダ(Primary GPT Header)が割り当てられ、デフォルトでは続くセクタ 2(LBA 2)以降セクタ 33(LBA 33)までにパーティションのエントリが割り当てられており、各セクタに4エントリ、各々128バイトが割り当てられている(Primary Partition Entry Array)。さらに、ディスク最後尾のセクタにバックアップとしてセカンダリGPTヘッダ(Secondary GPT Header)が、その前のセクタにパーティション・エントリのバックアップ(Secondary Partition Entry Array)が記録され、冗長化が図られている。

プライマリGPTヘッダの構成
バイト
オフセット
フィールド長内容
0x008バイトシグニチャ:"EFI PART"(0x45 46 49 20 50 41 52 54)
0x084バイトリヴィジョン(GPTバージョン1.0に対する改訂)(0x00 00 01 00)
0x0C4バイト当ヘッダのサイズ(通常、0x5C 00 00 00:92バイト)
0x104バイトヘッダのCRC-32チェックサム
0x144バイト予約領域(通常ゼロ)
0x184バイト当ヘッダの位置を示すLBA(通常、0x01 00 00 00 00 00 00 00)
0x208バイト当ヘッダのバックアップのLBA(ディスクの最終セクタ)
0x288バイトパーティションとして使用可能な最初のLBA(Windowsでは、0x22 00 00 00 00 00 00 00:34)
0x308バイト使用可能な最後のLBA(バックアップのエントリ・アレイの先頭セクタの1つ前)
0x3816バイトDisk GUID(Disk Identifier)
0x488バイトパーティション・エントリの開始LBA(0x02 00 00 00 00 00 00 00)
0x504バイトパーティション・エントリ数(通常、0x80 00 00 00:128)
0x544バイトパーティション・エントリのサイズ(通常、0x80 00 00 00:128バイト)
0x584バイトパーティション・エントリ・アレイのCRC-32チェックサム
 【数値はリトルエンディアン】

 続くセクタ 2以降にプライマリ・パーティション・エントリ・アレイが配置される。

プライマリ・パーティション・エントリの構成
バイト
オフセット
フィールド長内容
0x0016バイトPartition type GUID(Partition GUID Code)
0x1016バイトPartition GUID(命名規則に従って付与される)
0x208バイト開始LBA(リトルエンディアン)
0x288バイト終了LBA(リトルエンディアン)
0x308バイト属性
0x3872バイトパーティション名

 パーティション・タイプGUIDは、例えば、EFI System Partitionは、C12A7328-F81F-11D2-BA4B-00A0C93EC93Bであるが、先頭から3グループ、4バイト-2バイト-2バイトは、リトルエンディアンであるため、セクタ上には28 73 2A C1 1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3Bと並んでいる。Microsoft予約パーティション(Microsoft Reserved Partition:MSR)は、E3C9E316-0B5C-4DB8-817D-F92DF00215AE(16 E3 C9 E3 5C 0B B8 4D 81 7D F9 2D F0 02 15 AE)である。また、WindowsとLinuxはデータ・パーティションを表すGUIDとして同じID、EBD0A0A2-B9E5-4433-87C0-68B6B72699C7(A2 A0 D0 EB E5 B9 33 44 87 C0 68 B6 B7 26 99 C7)を使用している。なお、GPTでは、エントリの段階でパーティションのファイルシステムが明示されることはない。

 以上、NTFS.comの「GPT - Technical Documentation」、Wikipediaの「GUID Partition Table」、MSDNの「Windows and GPT FAQ」等を参照。

 図-2 実例-GPTのセクタ内容
 Format2-Figure2-GPT
【これは、OSがインストールされているディスクのGPTの例である。ディスク先頭のセクタ 0(LBA 0)のMBRは、その最初のパーティション・エントリのパーティション・タイプがEEhとあるから、Protective MBRとなる。続くセクタ 1(LBA 1)の冒頭の8バイトには、45h 46h 49h 20h 50h 41h 52h 54h("EFI PART")とあり、そのセクタがプライマリGPTヘッダであることを表す「シグニチャ」が示されている。パーティションとして使用可能な領域は、「使用可能な最初のLBA」として22h、即ち十進数で34だから、セクタ 34(LBA 34)から、「使用可能な最後のLBA」として1DCF328Eh、即ち十進数で500,118,158だから、セクタ 500,118,158(LBA 500,118,158)までとなる。それは、Protective MBRとプライマリGPTヘッダとプライマリ・パーティション・エントリ・アレイがセクタ 33(LBA 33)まで存在し、ディスク最後尾の33セクタにバックアップのためのセコンダリGPTヘッダとセコンダリ・パーティション・エントリ・アレイが配置されているので、それらを除いた範囲となっている。】

 なお、Windows 8.1以前では、USBフラッシュメモリに1つのパーティションしか設定できない仕様となっている。DiskPartで2つ目のパーティションを作成しようとすると、「仮想ディスク サービス エラー: 空でないリムーバブル ディスク上では、この操作はサポートされていません。」と表示される。MBRの場合はもとより、GPTの場合であっても(DiskPartを使えば、USBメモリもGPTにすることは可能だが)、複数のパーティションを作成することはできない。他のソフトウェアによって作成した2番目以降のパーティションは認識されることもない。しかし、Windows 10においては、複数のパーティションを設定・認識することが可能となっている。

(2) ファイルシステム・フォーマットの基本構成

 MBRあるいはGPTに示された位置に各パーティションは作成される。そのパーティションの先頭のセクタは、Partition Boot Record(PBR)、Partition Boot Sector(PBS)、Volume Boot Record(VBR)又はVolume Boot Sector(VBS)と呼ばれる。そこにパーティションの基本情報、データを管理するためのファイルシステムに関する基本情報等が格納される。それは適用されるファイルシステムによって構成が異なり、それに基づいて各種のメタデータ・ファイル(metadata file)がパーティション内に配置されることになる。これらの設定を行うことが、まさにファイルシステム・フォーマットなのである。

 PBRには、もう一つBootstrap Codeというパーティション内のある特定のプログラムを起動するコードが書き込まれる領域がある。そのプログラムは通常OSということになるが、起動すべきOSを含まない、単にデータ保存のためのパーティションでは重要ではない。

 MBRを持たないフロッピーディスクの先頭セクタには、このPBRと同様の情報が記録される。パーティションという区分がないため、その領域は単にブート・セクタ(Boot Sector)と呼ばれるが、フロッピーディスク全体を一つのパーティションと捉えることもできる。なお、このブート・セクタという用語は、OS等のプログラムの起動という観点から、MBR及びPBRの総称としても用いれる(Microsoftでは、PBRだけをブート・セクタと呼んでいる)。BIOSは、先ず最初にストレージ・デバイスの先頭セクタの末尾に0xAA55があるブート・セクタを探し、そのブートストラップ・コードを実行しようとするのである。

 PBRの構成はOSやファイルシステムによって異なり、OSによってはPBRを使わないものもある。

 例として、NTFSとFAT32のPBRの構成を見てみる。

● NTFSのPartition Boot Record(Boot Sector)

NTFSのPBRの構成
バイト
オフセット
フィールド長内容
0x003バイトジャンプ命令(Jump Instruction)(0xEB 52 90)
0x038バイトOEM ID(OEM Name)
0x0B25バイトBPB(BIOS Parameter Block;Boot Parameter Blockとも呼ぶ)
0x2448バイトExtended BPB
0x54426バイトBootstrap Code
0x01FE2バイトシグニチャ(End of Sector Marker)(0x55 AA、リトルエンディアン:0xAA55)

 さらに、上記のOEM ID、BPB、Extended BPB(これらをまとめてディスク・パラメータと呼ぶこともある)の構成内容を見る。

NTFSのBIOS Parameter Block(BPB)等の構成
バイト
オフセット
フィールド長内容
0x038バイトOEM ID(OEM Name)("NTFS"、0x4E 54 56 43 20 20 20 20)
BPB
0x0B2バイト1セクタあたりのバイト数(0x00 02:512)
0x0D1バイト1クラスタあたりのセクタ数(0x08)
0x0E2バイト予約セクタ(0)
0x103バイト常にゼロ
0x132バイトNTFSでは不使用(0)
0x151バイトメディア・ディスクリプタ(0xF8)
0x162バイト常にゼロ
0x182バイト1トラックあたりのセクタ数(0x3F 00:63)
0x1A2バイトヘッド数(0xFF 00:255)
0x1C4バイトHidden Sectors(パーティションの先頭セクタまでのセクタ数、即ち当該パーティションの位置を表す。第1パーティションであれば、通常、0x00 08 00 00:2048)
0x204バイトNTFSでは不使用(0)
Extended BPB
0x244バイトNTFSでは不使用(シグニチャとの説明もある)(通常、0x80 00 80 00)
0x288バイト総セクタ数(当該PBRの1セクタを除いた数である)
0x308バイト$MFT(Master File Table)の開始クラスタ番号(メタデータファイル名の前には$が付く)
0x388バイト$MFTMirr($MFTのバックアップ)の開始クラスタ番号
0x404バイト1ファイル・レコード・セグメント(File Record Segment:FRS)あたりのクラスタ数(0xF6 00 00 00:246)
0x444バイト1インデックス・ブロックあたりのクラスタ数(0x01 00 00 00:1)
0x488バイトボリュームシリアルナンバー(フォーマット時にランダムに付与される)
0x504バイトチェックサム(NTFSでは常にゼロ)
 【数値はリトルエンディアン】

 NTFSでは、パーティションの最後尾のセクタにPBRのバックアップが保存される(「NTFS パーティション上の NTFS ブート セクタの回復」)。

 図-3 実例-NTFSパーティションのPBR
 Format2-Figure3-NTFS-PBR
【このパーティションの場合、Hidden Sectorsは、「00h 08h 00h 00h」とあるから、開始セクタはセクタ 2048(LBA 2048)である。総セクタは、「FFh FFh 7Fh 07h 00h 00h 00h 00h」であるから、125,829,119セクタであり、それにPBRの1セクタを加えて、512バイトを掛けると、このパーティションのサイズが、64,424,509,440バイト=60GiBであることが分かる。$MFTの開始クラスタは、「00h 00h 0Ch 00h」であり、1クラスタは8セクタであるから、786,432クラスタ×8セクタ=6,291,456セクタであり、これに2048セクタを加えれば、$MFTの開始アドレスがセクタ 6,293,504(LBA 6,293,504)であることが分かる。同様に$MFTMirrの開始アドレスは、セクタ 2064(LBA 2064)となる。】

● FAT32のPartition Boot Record(Boot Sector)

FAT32のPBRの構成
バイト
オフセット
フィールド長内容
0x003バイトジャンプ命令(0xEB 58 90)
0x038バイトOEM ID(OEM Name)
0x0B53バイトBPB
0x4026バイトExtended BPB
0x5A420バイトBootstrap Code
0x01FE2バイトシグニチャ(0xAA55)

FAT32のBPB等の構成
バイト
オフセット
フィールド長内容
0x038バイトOEM ID(OEM Name)("MSDOS5.0":0x4D 53 44 4F 53 35 2E 30。Linuxの場合、"SYSLINUX":0x53 59 53 4C 49 4E 55 58)
BPB(BIOS Parameter Block)
0x0B2バイト1セクタあたりのバイト数(0x00 02:512)
0x0D1バイト1クラスタあたりのセクタ数(0x20:32、パーティションのサイズで決まる)
0x0E2バイト予約セクタ数(FAT領域の開始位置までのセクタ数)
0x101バイトFATの数(FATのコピー数)(常に、0x02:2)
0x112バイトルートエントリ数(FAT12/16のみで使用)(FAT32ではゼロ)
0x132バイトSmall Sectors(FAT12/16のみで使用)(セクタ数が16bitで表される65,536までの場合のみ設定。FAT32ではゼロ)
0x151バイトメディア・ディスクリプタ(Media Descriptor)(0xF8は、HDDを示す)
0x162バイト1FATあたりのセクタ数(FAT12/16のみで使用)(FAT32ではゼロ)
0x182バイト1トラックあたりのセクタ数(0x3F 00:63)
0x1A2バイトヘッド数(0xFF 00:255)
0x1C4バイトHidden Sectors(パーティションの先頭セクタまでのセクタ数、即ち当該パーティションの位置を表す。第1パーティションであれば、通常、0x00 08 00 00:2048)
0x204バイトFAT32の総セクタ数(Large Sectors)[※3
0x244バイト1FATあたりのセクタ数(FAT32のみで使用)(PCはこの数とFATの数とHidden Sectorsの数を使って、ルートディレクトリの開始位置を定める。)
0x282バイト拡張フラッグ(Extended Flags)(FAT32のみで使用)(通常ゼロ)
0x2A2バイトファイルシステム・バージョン(FAT32のみで使用)(通常ゼロ)
0x2C4バイトルートディレクトリの開始クラスタ番号(FAT32のみで使用)(通常は、0x02 00 00 00:2)
0x302バイトFile System Information(FSINFO)のセクタ番号(FAT32のみで使用)(通常は、0x01 00:1)
0x322バイトバックアップ・ブート・セクタ(バックアップPBR)の位置(FAT32のみで使用)(通常は、0x06 00:6) ※【TechNetの「Boot Sector」のこのオフセットは、0x34と誤っている。】
0x3412バイト予約領域(FAT32のみで使用)(通常ゼロ) ※【TechNetの「Boot Sector」のこのオフセットは、0x36と誤っている。】
Extended BPB
0x401バイト物理ドライブ番号(HDDならば、0x80)
0x411バイト予約領域(通常ゼロ)
0x421バイト拡張ブート・シグニチャ(通常、0x29)
0x434バイトボリュームシリアルナンバー(フォーマット時にランダムに付与される)
0x4711バイトボリュームラベル("NO NAME":0x4E 4F 20 4E 41 4D 45 20 20 20 20)
0x528バイトファイルシステム・タイプ("FAT32":0x46 41 54 33 32 20 20 20)
 【数値はリトルエンディアン】

註※3 FAT32の総セクタ数:
 総セクタ数には、4バイトが割り当てられいるが、WindowsのDiskPartやMMCスナップインの「ディスクの管理」によって新たに作成することができるFAT32パーティションのサイズは、32GBが上限とされている。従って、その場合、このフィールドの最大値は、0x00 00 00 04である(67,108,864セクタ)。もっとも、他のソフトウェアで作成した32GBを超えるFAT32パーティションをWindowsで扱うことは可能である。

 図-4 実例-FAT32のPBR
 Format2-Figure4-FAT32-PBR
【FAT32の場合は、NTFSと異なり、総セクタ数にPBRの1セクタも含まれており、このパーティションの総セクタ数は、「00h 00h 00h 04h」となっているから、67,108,864セクタ×512バイト=34,359,738,368バイト=32GiBがこのパーティションのサイズとなる。】

 以上、TechNetの「Boot Sector」、NTFS.comの「NTFS Partition Boot Sector」、Wikipediaの「Design of the FAT file system」、UiUicyの「ディスクパラメータの構造」等を参照。

(3) クイックフォーマット

 以上のような書き込みがドライブになされることによって、論理フォーマットが行われる。その場合、通常のフォーマット(Full Format)とクイックフォーマット(Quick Format)を選択できることがある。Windowsの場合、クイックフォーマットを選択すると、選択されたファイルシステムに従って、上記のMBR領域の関連する項目、PBR及びファイルシステムに関連するデータ管理情報等だけが書き込まれる。

 改めて確認しておくが、パーティションを作成することとそのパーティションをある特定のファイルシステムによってフォーマットすることとは、別個の作業である。前者は、MBRないしGPTのパーティション・テーブルに必要な変更・追加がなされるだけである。後者は、主に対象となるパーティションの内部に指定されたファイルシステムが要求する管理情報等を書き込むことである。単に、パーティションを作成するときに、引き続いてファイルシステムを適用することが一般的な流れであるというにすぎないのである。

 通常は、クイックフォーマットを選択することになろう。実際にクイックフォーマットがどのように行われるか、見てみる。ゼロフィルを実行し、何も書き込まれていない古いHDD(80GB)を用意した。

● MBRディスクの場合

 先ず、このHDDに対して、WindowsのDiskPartにより、MBR領域を作成する(この操作は「ディスクの初期化」とも呼ばれる)。

DISKPART> select disk #(対象となるディスク番号)
DISKPART> convert mbr

 図-5 MBR領域の作成
 Format2-Figure5-MBR-only

 次に、パーティションのみを作成する。例として60GBと残り約16GBの2つのパーティションを作成。

DISKPART> create partition primary size=61440
DISKPART> create partition primary

 図-6 MBR-パーティションのみの作成
 Format2-Figure6-MBR-Partitions

 フォーマットをせず、パーティションだけを作成した場合は、MBRのパーティション・テーブルに作成した数のエントリが書き加えられる。この場合は、2つである。しかし、それぞれのパーティションの先頭セクタには何も書き込まれない。

 この状態では、MBRのパーティション・タイプの値は、0x00とはならず、Windowsにおいては0x06となっている。これがWindowsのデフォルトであろう。ただ、パーティションの開始セクタに何も書き込まれていないため、その領域はパーティションとして認識されるものの、ファイルシステムは「RAW」、「未フォーマット」、「unknown」などと表示されることになる。これは、Windowsの「ディスクの管理」スナップインの「パーティションのフォーマット」で「このボリュームをフォーマットしない」を選択した場合も同様である。

 この段階で、ドライブレター(Drive Letter、ドライブ文字)を割り振らなければ、ファイルシステムは「RAW」と表示されず、オフラインとなる。ドライブレターは、ドライブやボリュームを識別するために用いられるアルファベットであり、MS-DOSやWindowsの独自のシステムで他のOSでは使用されていない。当然ながら、対象ディスクのMBRやGPT、PBR等にドライブレターを記録する所はない。Windowsのレジストリ、HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices内に"\DosDevices\C:"といった形式で各ドライブの文字が記録されている。

 ところで、Linuxのfdiskコマンドでは、パーティションを作成する場合、パーティション・タイプをEmptyの「0」と変更・指定することが可能である(図-7)。その際、MBRのパーティション・テーブルにおいては、パーティション・タイプの値は、0x00となり、パーティションの開始セクタ・総セクタ数など他の値は書き込まれるが、パーティションの先頭セクタには何も書き込まれない。この状態では、当該パーティション領域は、WindowsやLinuxにおいて未割り当て領域と認識されることになる(図-9・10)。

 図-7 fdiskで「0」
 Format2-Figure7-fdisk-Type00
【fdiskで上記と同様の60GBと約16GBのパーティションを作成し、各パーティション・タイプをデフォルトの「83」(Linux)から前者は「7」(NTFS)に、後者は「0」に変更してみた。ご覧のように「タイプ0は多くのシステムでは空白を示します。パーティションのタイプを0にすることはおそらく賢明ではないでしょう。」と警告が表示される。それをdisk editor(図-8)、GParted(図-9)、Windowsの「ディスクの管理」(図-10)で表示したところである。】

 図-8 disk editor
 Format2-Figure8-MBR-Type00

 図-9 GParted
 Format2-Figure9-GParted-Type00

 図-10 Windowsの「ディスクの管理」
 Format2-Figure10-DiskManagement-Type00

 これは、要するに、MBRにおいて、パーティションのみを作成してフォーマットをしない場合、MBRのパーティション・テーブルには、デフォルトで定められている何らかのパーティション・タイプの値を持った有効なエントリが作成されるが、当該パーティションの先頭の開始セクタ以降パーティション内には何も書き込まれないことになっている。この場合は、パーティションとして認識されるも、ファイルシステムはRAWないし未フォーマットと認識される。しかしながら、パーティション・テーブル・エントリのパーティション・タイプの値が0x00と設定されると、エントリ内の他の値が有効に設定されているとしても、そのパーティションはパーティションとして認識されることはなく、当該パーティション領域は未割り当て領域と認識されることになる。

 パーティション・タイプ(パーティションID)の0x00という値は、「Empty」あるいは「空のパーティション」などと説明されるが、実際にはこの値がゼロとなると、当該エントリの他の値もゼロと同様に扱われ、OSからは当該パーティションは存在しないものと見做されることになる。

 これらのパーティションをクイックフォーマットしてみる。それぞれファイルシステムはNTFSとFAT32とする。DiskPartでは、パーティションを作成した場合、ドライブレターを設定しなければ、「オフライン」と認識され、そのボリュームをフォーマットすることができないことがある。その場合は、先にドライブレターを割り振る必要がある。ここでは、それぞれ「V」、「W」とする。

DISKPART> select volume #(対象となるボリューム番号)
DISKPART> assign letter=v
DISKPART> format fs=ntfs quick

DISKPART> select volume #(対象となるボリューム番号)
DISKPART> assign letter=w
DISKPART> format fs=fat32 quick

 図-11 MBR-フォーマット後
 Format2-Figure11-MBR-Formatted

 図-12 NTFSのPBR
 Format2-Figure12-NTFS-PBR-Formatted

 図-13 FAT32のPBR
 Format2-Figure13-FAT32-PBR-Formatted

 MBRのパーティション・テーブル・エントリで指定されたパーティションの開始セクタに、各々NTFSとFAT32のPBR(ブート・セクタ)が書き込まれる(図-12、図-13)。それと同時に各ファイルシステムに必要なメタデータ等が書き込まれる。これでようやく、パーティション内においてファイルの読み書きが可能となる。

● GPTディスクの場合

 WindowsのDiskPartにより、GPTディスクを作成する。

DISKPART> select disk #(対象となるディスク番号)
DISKPART> convert gpt

 図-14 GPT領域の作成
 Format2-Figure14-GPT

 このとき、セクタ 0(LBA 0)には、Protective MBRが作成され、セクタ 1(LBA 1)には、GPTヘッダが書き込まれる。セクタ 2(LBA 2)の先頭のエントリ1には、ご覧のようにMSR(Microsoft Reserved Partition、Microsoft予約パーティション)が、「パーティション管理をサポートするために」(MSDN、「UEFI/GPT ベースのハード ドライブ パーティション」)、自動的にWindowsにより作成される(128MB、Windows10以降では16MB)。MSRは、GPTディスクでのみ使用され、「他のシステム パーティションに関する情報が格納され、この情報はMicrosoftアプリケーションで使用され」(TechNet、「UEFI ベースの推奨ディスク パーティション構成」)る特殊なパーティションである。

 上記MBRと同様、60GBと約16GBの2つのパーティションだけを作成する。

 図-15 GPT-パーティションのみの作成
 Format2-Figure15-GPT-Partitions

 セクタ 2のエントリ2・3に各パーティションのタイプGUIDや開始・終了セクタ等が追加されるだけで、実際のパーティションの開始セクタには何も書き込まれないのは、MBRの場合と同じである。その結果、パーティションの領域として認識されるが、ファイルシステムは「RAW」又は「unknown」などと表示される点も同じである。

 それぞれファイルシステムをNTFSとFAT32として、パーティションをクイックフォーマットすると、各パーティションの開始セクタにPBRが書き込まれる。フォーマットに関してはMBRと異なる点はない。

 なお、GPT fdisk[※4]やGPartedを使えば、当然ながらMSR領域を作成することなく、GPTディスクにパーティションを作成することは可能である(図-16)。しかし、Windowsで使用する、又はそれと共有する可能性のあるドライブであれば、Microsoftが「すべてのドライブに用意することをお勧めします」(「UEFI ベースの推奨ディスク パーティション構成」)と述べ、「A Microsoft Reserved partition is required on every GPT disk.」(「Create partition msr」)とも述べている以上、作成しておくのが賢明であろう。

 図-16 gdisk
 Format2-Figure16-gdisk

註※4 GPT fdisk:
 Roderick W. Smithの手になるGPT fdisk(gdisk、sgdisk、cgdiskの総称)は有益なプログラムである(http://www.rodsbooks.com/gdisk/)。なかでも、gdiskは、fdiskに類似したインタラクティブなプログラムであって、LinuxのみならずWindowsのコマンドプロンプトでそのまま使用することができ、セクタ単位でGPTディスクのパーティションを作成することができる有用なプログラムである。MBRディスクをGPTディスクに変換し、MBRで使用していたOSをそのままGPTディスクに戻して、さらにマルチブートに構成するときなどに、このgdiskは重宝する。

 図-17 Windowsにおけるgdisk
 Format2-Figure17-gdisk-onWindows
【上記サイトより入手したgdisk32.exe又はgdisk64.exeをコマンドプロプトで起動し、「\\.\physicaldrive#」(#は対象となるディスク番号)と入力する。】

(4) 通常のフォーマット

 Windowsにおいては、クイックフォーマットではなく、通常のフォーマットを行うと、クイックフォーマットで行われる作業に加えて、パーティション内全域のセクタに対してチェックディスク(Chkdsk)が実施され、既存のデータは全て消去される。フォーマット完了は、パーティションのサイズによっては、かなりの時間を要することになる。

 フォーマット時のChkdskの実行は、NTFSでは重要な意味を持つ。Chkdskによって不良セクタが検出されると、それを含むクラスタは、NTFSメタデータであるMFT(Master File Table)のエントリ8にある$BadClus(Bad-cluster file)の不良クラスタのリストに記録され、クラスタの再配置(remapping)がなされて、以後そのクラスタが再使用されることはない。これは、フォーマット時でなくとも、データにアクセスしたときにデータが読み出せず、不良セクタであることが判明した場合にも行われる。その場合、耐障害性のある(fault-tolerant)冗長ボリューム(redundant volume)であれば(RAID 1、RAID 5等)、データは回復できるが、通常のボリュームではデータは失われる。但し、データの書き込み時に不良セクタであることが明らかになった場合には、再配置が行われて代替処理された後、新たなクラスタに書き込みがなされるので、データが失われることはない。(Mark Russinovich 他、『Windows Internals Sixth Edition Part 2』、「Dynamic Bad-Cluster Remapping」 p.429、「NTFS Bad-Cluster Recovery」 pp.487-490)

 もっとも、不良セクタが何時発生するかは不明であり、フォーマット時に不良セクタが発見されたとしても、その後新たに不良セクタが発生しない保証はなく、たとえそのときに不良セクタがなくとも、その後に不良セクタが発生することがあるので、フォーマット時にチェックディスクを行う必要性は必ずしも高くない。特に新しいHDDに不良セクタが存在するおそれはほとんどないので、時間をかけて通常フォーマットを行う必要はなかろう。とはいえ、古いHDDに改めてパーティションを作成する場合には、フォーマット時にチェックディスクを行っておくに越したことはない。通常のフォーマットかクイックフォーマット、いずれを選択すべきかは、時間と安全を比較衡量してその都度判断するほかない。

(5) 既存ファイルと両フォーマットの挙動

 このように見てくると、何らかの原因でPBRが壊れてファイルシステムが正しく認識されず、「フォーマットの必要があります。フォーマットしますか?」と訊かれた場合でも、PBRは修復することが可能であることが分かる。「Tips: 強力な(?)NTFSのPBR修復法」などのWebサイトが参考になろう。その際、慌ててフォーマットをしてしまわないことである。特に、存在するファイルをゼロで上書きする通常のフォーマットを行ってしまうと、ファイルの復元の可能性は断たれてしまう。パーティション内には、上記で見た如く、PBRや$MFTなどのメタデータのバックアップが保存されており、それを利用してパーティションを修復・復元してくれるソフトがあるので、先ずそれを試してみてもよいであろう。それがうまくいかなければ、データ復元ソフトを使うことになろうか。勿論、金銭に換えがたい重要なデータが含まれているならば、何も手を加えず、データ復旧専門の業者に頼むのが最善である(おくやま電脳工房、「データ復旧のプロが見た"間違いだらけのデータ復旧"」)。

 また、クイックフォーマットをしてしまった場合であっても、ファイル自体はそのまま残っているので、ほとんどのファイルは復元することが可能である。但し、NTFSを例にとると、ファイル名等を記録しているMFTはクイックフォーマットにより上書きされるため(『Windows Internals Sixth Edition Part 2』、「File Names」、pp.449-453)、データ復元ソフトを通じてファイル本体は復元することができるものの、ファイル名は復元することはできず、ファイルの種類毎に通し番号などが付されることになる。試しに、クイックフォーマットを行う前に、disk editorを使ってMFTを保存しておき、クイックフォーマットをした後にMFTを書き戻して、データ復元ソフトで復元を行ってみると、ファイル名を伴ったファイルを復元することが可能であった。

 これに対し、LinuxのGPartedでは、フォーマットにクイックや通常といった選択肢はない。例えば、WindowsでNTFSにフォーマットしたパーティションにテスト用のファイルを保存したものに対して、GpartedでNTFSフォーマットを行ってみると、短時間でフォーマットは終了する。その中をdisk editorで確認すると、保存されていたファイルの消去はなされておらず、先頭セクタのPBR及びMFTのメタデータのみが書き込まれている。GPartedのフォーマットは、いわゆるクイックフォーマットである。但し、MFTの保存位置がWindowsとは異なっており、そのためテスト用ファイルの一部が上書きされていた。

 Linuxのmkfsコマンドでは、オプションを使わなければ、通常のフォーマットが行われるようである。フォーマット後にセクタを確認すると、フォーマット以前に存在したファイルは全て消去され、ゼロで上書きされている。クイックフォーマットを行うには、一般的には例えば、NTFSでフォーマットする場合、

mkfs -t ntfs -E lazy_itable_init=1 /dev/sdx

とするとされるが、-Qというオプションも使えるようである。Qは、おそらくQuickの頭文字であろう。

mkfs -t ntfs -Q /dev/sdx

 図-18 mkfsでクイックフォーマット
 Format2-Figure18-mkfs-t-ntfs-Q

 これを実行した後にセクタを確認すると、上述のGPartedでフォーマットした状態と同じ結果であった。このmkfsコマンドは、自らコードを実行しているわけではなく、各ファイルシステムを設定するプログラムを呼び出しているだけであるとされる。同じLinuxディストリビューションであれば、GPartedのフォーマットもmkfsコマンドのクイックフォーマットも同一のプログラムを実行していることになる。

 なお、アプリケーションによる個々のファイルシステムへのアクセスは、実際には仮想ファイルシステム(Virtual File System、VFS)を介して行われる。仮想ファイルシステムは、「どのアプリケーションからでも、同じような手順でファイル操作(媒体へのアクセス)が行えるような、単一のインターフェイスを提供」するものであり(菅谷みどり、@IT、「VFSとファイルシステムの基礎技術 (2/2)」)、それが「ファイルシステム共通の機能を受け持つことで、各ファイルシステムはその機能をより特化させることが可能にな」ると同時に、「ユーザーは複数のファイルシステムを統一的な方法で扱えるようにな」るのである(「VFSとファイルシステムの基礎技術 (1/2)」)。これはUNIX上で発展したもので、LinuxやWindowsなどでもコア技術として採用されているとされる。特にLinuxにおいては、「ドライバやI/Oサブシステムに対しても統一的なインターフェイスを提供している」(「同 (2/2)」)ことから、多種のファイルシステムに対応することが可能であり、近時ではNTFSの読み書きも可能となっている。

(6) Windowsレジストリへの記録

 Windowsにおいては、ストレージ・デバイスが接続されマウントされると、前述したMBRのディスク・シグナチャ(ディスクID)、Disk GUID、パーティションのシリアルナンバーやGUID等のデバイスの情報がレジストリに記録される(Martin Brinkmann、ghacks.net、「Remove Unconnected Storage Device Information From Windows」)。


HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume
HKEY_USERS\<ユーザSID>\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
HKEY_USERS\<ユーザSID>\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\0\DiskController\0\DiskPeripheral

 主に上記のサブキーに接続情報が記録される。ひとたびストレージが接続されると記録され、その情報は保持されることにもなる。MBR・GPTを設定し直し、パーティションを作成し直すたびに、新たなディスクIDやパーティションGUID等がそれぞれの命名規則に基づいてランダムに付与され、と同時にそれらはレジストリに記録されることになる。これは、ディスクやパーティションの管理あるいはcomputer forensicsには有用であろうが、独自にディスクやパーティションに変更を加えようとする場合には、問題が生じることもあるので注意が必要である(註※1参照)。

 また、Virtual Disk Service(VDS、仮想ディスクサービス)は、「ディスクの構成、管理を行うための、統一されたインターフェイスを提供するためのサービス」であり、「ディスクの作成やフォーマット、あるいはハードウェアRAIDアダプターを管理する」ものであって、「Diskpart コマンドや [ディスクの管理] MMC スナップインは、VDS API ベースのプログラム」である(TechNet、「仮想ディスク サービス (VDS) について」)。例えば、パーティションに対して独自の操作を行っている場合に、VDSからの情報の取得要求が行われるも、そのためにパスの切断などが発生してその取得に失敗したときには、VDS Basic Providerに関し「予期しないエラーが発生しました。エラー コード: D@01010004」といったイベントが記録されることがある。このエラーは、原因が明白であるから、無視してよいであろうが、それが記録されない状態にしておく必要はあろう。

(7) NTFSのLog Fileの構造とバージョン問題

 Windows XP及びWindows Server 2003以降で使用されるNTFS(New Technology File System)は、バージョン3.1で共通である。ところが、NTFSボリュームではファイルの変更等の情報を記録する$LogFileというメタデータ・ファイルが用いられるが、Windows 8において、システムのパフォーマンスの向上を図り、Log Fileの書き込みの I/Oカウントを減らすためにLog Fileの構造が変更されている。そのバージョンは、それまでの1.1から2.0とされる。これに関する詳細な説明は、Mark Russinovichの「Windows 8 volume compatibility considerations with prior versions of Windows」(TechNet Articles)にある。(それを日本語で解説したブログは、ぼくんちのTV別館の「Windows8以降とそれ以前のWindowsの、Diskの互換性とその注意事項について-その1」ないし「その3」にある。)

 それによると、大要以下の通りである。

● 問題状況

 NTFSにおいて、Windows 7以前ではLog File構造(Log File structure、LFS)のバージョンは、1.1であるが、Windows 8以降ではバージョン2.0が原則として用いられる。Windows 8以降のOSはいずれのバージョンにも対応しているが、Windows 7以前のOSは、LFSバージョン2.0のNTFSを認識することができない。そこで、互換性を保つために、Windows 8以降のNTFSドライバは、内蔵のストレージ・デバイスについては起動したとき、又は外部のストレージ・デバイスについては接続したときに、NTFSのパーティションのlog file structureとバージョン番号をアップグレードして2.0にしてアクセスすることにし、シャットダウンされるとき、又は「安全な取り外し」によって当該ストレージが取り外されるときに、log file structureとバージョン番号をダウングレードして1.1にすることにしている、という。

 これは実に巧妙なギミックであるが、場合によっては危ういともいえる。Windows 7以前のOSとWindows 8以降のOSをデュアルブートないしマルチブートで利用する場合に、不都合が生ずるおそれがある。

 Windows 8以降で採用されるハイブリッド・ブート(Hybrid Boot、高速スタートアップ)は、休止状態(Hibernate)が利用され、完全なシャットダウンが行われないため、NTFSパーティションのLFSバージョンは2.0のままとなる。その後、Windows 8以降のOSとWindows 7以前のOSとをマルチブート構成にしている場合に、PCを起動すると、OSの選択画面が表示される前に、休止状態にあったOSはHybrid bootが適用されてWindows 8以降のOSの起動準備が完了する。そのとき、他のOSが選ばれると、再起動がかかり、LFSバージョンは2.0から1.1にダウングレードされるという手間がかかることになる。

 このHybrid boot利用の休止状態に入ったときの外付けのHDD等が取り外されて、Windows 7以前のOSに接続されるとNTFSパーティションは認識されないことになるので、留意が必要である。

 実際に、Windows 7とWindows 10とのデュアルブート構成にしているノートPCにおいて、NTFSパーティションのLFSバージョンがどうなっているのか、fsutil fsinfoコマンドを使って確認してみる。例えば、CドライブのNTFSの情報を表示するには、コマンドプロプトで、

>fsutil fsinfo ntfsinfo C:
と入力する。

 このコマンドで見ると、Windows 10でPCを起動しいる場合、Windows 10のインストールされているCドライブのみならず、Windows 7のインストールされているDドライブも、共用のEドライブも全てLFSバージョンは、2.0となっている。

 Windows 7でこのコマンドを使っても、LFSバージョンは表示されないので、Window10をシャットダウンした後の各パーティションのLFSバージョンはどうなっているかを、Windows10のインストール・メディアからコマンドプロンプトを起動して確認する。Window7や共用のパーティションだけでなく、Windows10自身のパーティションもLFSバージョンは、1.1になっている。それゆえ、Window7で起動した場合、Windows10がインストールされているパーティションにさえアクセス可能となっている。

 このようなデュアルブートにおいては、万が一Windows10を起動中に不具合が発生し、正常なシャットダウンがなされず、Windows10が起動できない事態となった場合、全てのNTFSパーティションのLFSバージョンが2.0のままとなり、Windows7の起動に支障が生ずる。

 このTechNetの記事では、Windows 7以前のOSでLFSバージョン2.0のNTFSパーティションが接続されると、Log Fileが破損していると認識されてchkdskの実行が要求され、チェックディスク終了後に正常な状態となると説明される。しかしながら、Webには一部のファイルが失われることもあるとされている以上、かかる事態に至らないように手立てを講じておくに越したことはない。

● 対処法

 先ず、Hybrid boot(高速スタートアップ)は無効にしておく。休止状態を利用しない者にとっては無関係であろうが、念のためである。コントロールパネルの電源オプションの「電源ボタンの動作の選択」から「現在利用可能ではない設定を変更します」をクリックし、「高速スタートアップを有効にする(推奨)」のチェックを外して、再起動する。

 さらに、レジストリでNTFSドライバがLFSのアップグレードを行わない設定にしておく。"regedit.exe"を起動し、下のレジストリキーに移動する。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem

 右ペインでREG_DWORDの"NtfsDisableLfsUpgrade"という名のエントリを探す。なければ、DWORD値で新規作成する。

 その値のデータを「0」以外の値(推奨は「1」)に変更して、再起動する(シャットダウンではない)。

 これで、NTFSドライバは、NTFSボリュームのLog File structureとバージョン番号をアップグレードすることはない。

 なお、fsutil fsinfo ntfsinfoのコマンドラインで表示される「LFS」という頭文字語・頭字語(initialism)は、どの言葉の頭文字なのかという些細だが紛らわしい問題がある。

 確かに、Windowsにおいては、LFSは、通常Log File Serviceを指すと考えられる。前掲書『Windows Internals, Sixth Edition, Part 2』の第12章、「File System」の「NTFS Recovery Support」というセクションの「Metadata Logging」という項目の中に、「Log File Service」という小項目があり(pp.479-480)、「The log file service (LFS) is...」という書き出しでLFSの説明がなされている。即ち、Log File Service(LFS)とは、Log Fileにディスクの書き込みを記録するサービスを提供するNTFSドライバに含まれるカーネルモードのルーティンであり、そのLog Fileはシステム障害が生じた場合にNTFSボリュームをリカバリするために使用されるものである、と説明されている(同書、p.440、p.479)。

 しかしながら、この場合、Log File Service自体がアップグレードされるわけではなく、上記TechNetの記事には、「Log File Service」という言葉は一度も使用されず、「log file structure and version」という表現が12回も使用されており、各NTFSボリューム内のLog File structure(Log File構造)の相違が問題なのであるから、当該LFSはlog file structureの頭文字と解すべきであろう。

 因みに、Windowsでは、Common Log File System(CLFS)という用語も頻繁に使用される。前掲書の同じく「File System」の章内に、「Common Log File System」という大きな独立したセクションがある(同書、pp.416-424)。Common Log File System(CLFS)については、Windowsは、ファイル又はエントリに含まれるデータ又はメタデータに加えられた変更を、「元に戻す(undo)」や「繰り返す(redo)」を行うため、又はその変更を後に有効とするために、「logging」と呼ばれる作業によって「log records」と呼ばれるデータ構造体に保存するといったloggingサービスをCommon Log File Systemを通じて提供すると説明される(同書、pp.416-417)。

 その上で、「Note that although LFS and CLFS have similar sounding names, they are separate logging implementations used for different purposes, although their operation is similar in many ways.」(LFSとCLFSが似通った表記であって、両者の作用は多くの点で類似しているが、両者は異なる目的に使用するために実装された別個のlogging機能であることに注意を要する。)、とわざわざ注記されている(同書、p.479)。

 今後は、さらにlog file structureを表すLFSとの違いにも注意すべきである、という注意書きが加わることになろうか。

 このLFSのバージョン問題については、Webには誤解している記述が散見され、上記TechNetのサイトの説明を改めて確認することが望まれる。

※参考:
・Phooen, Sonpooshi. 2015. 「初期化について」. http://blog.phooen.com/blog-entry-68.html

・TechNet Microsoft. "Master Boot Record". https://technet.microsoft.com/en-us/library/cc976786.aspx

・Disklessfun. 2016. 「Tips: マルチブートするなら2段階ブート方式に統一しよう」. http://wikiwiki.jp/disklessfun/?multipleboot

・Russinovich, Mark (TechNet Microsoft). "Fixing Disk Signature Collisions". https://blogs.technet.microsoft.com/markrussinovich/2011/11/06/fixing-disk-signature-collisions/

・Fisher, Tim (Lifewire). "What is a Disk Signature?". https://www.lifewire.com/what-is-a-disk-signature-2625851

・TechNet Microsoft. "Uniqueid". https://technet.microsoft.com/ja-jp/library/cc730793%28v=ws.11%29.aspx

・Hazymoon. 2008. 「MBR(Master Boot Recode)の構造」. http://caspar.hazymoon.jp/OpenBSD/arch/i386/stand/mbr/mbr_structure.html

・DEW Associates Corporation. "BIOS Interrupt 13h Extensions". http://www.dewassoc.com/support/bios/bios_interrupt_13h_extensions.htm

・Hazymoon. 2008. 「HDDの話」. http://caspar.hazymoon.jp/OpenBSD/misc/hdd.html

・Wikipedia. "INT 13H". https://en.wikipedia.org/wiki/INT_13H

・SD Association. 「SDメモリカードフォーマッター」. https://www.sdcard.org/jp/downloads/formatter_4/index.html

・Wikipedia. "Master Boot Record". https://en.wikipedia.org/wiki/Master_boot_record

・Wikipedia. "Partition type". https://en.wikipedia.org/wiki/Partition_type

・NTFS.com. "GPT - Technical Documentation". http://www.ntfs.com/guid-part-table.htm

・Wikipedia. "GUID Partition Table". https://en.wikipedia.org/wiki/GUID_Partition_Table

・MSDN Microsoft. "Windows and GPT FAQ". https://msdn.microsoft.com/en-us/library/windows/hardware/dn640535%28v=vs.85%29.aspx

・Microsoft. 「NTFS パーティション上の NTFS ブート セクタの回復」. https://support.microsoft.com/ja-jp/help/153973/recovering-ntfs-boot-sector-on-ntfs-partitions

・TechNet Microsoft. "Boot Sector". https://technet.microsoft.com/en-us/library/cc976796.aspx

・TechNet Microsoft. "Disk Concepts and Troubleshooting". https://technet.microsoft.com/en-us/library/cc977221.aspx

・NTFS.com. "NTFS Partition Boot Sector". http://www.ntfs.com/ntfs-partition-boot-sector.htm

・Wikipedia. "Design of the FAT file system". https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system

・UiUicy. 「ディスクパラメータの構造」. http://uiuicy.cs.land.to/discpara.html

・MSDN Microsoft. 「BIOS/MBR ベースのハード ドライブ パーティション」(Windows10). https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn898504%28v=vs.85%29.aspx

・MSDN Microsoft. 「UEFI/GPT ベースのハード ドライブ パーティション」(Windows10). https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn898510%28v=vs.85%29.aspx

・TechNet Microsoft. 「BIOS ベースの推奨ディスク パーティション構成」(Windows7). https://technet.microsoft.com/ja-jp/library/dd744364%28v=ws.10%29.aspx

・TechNet Microsoft. 「UEFI ベースの推奨ディスク パーティション構成」(Windows7). https://technet.microsoft.com/ja-jp/library/dd744301%28v=ws.10%29.aspx

・Microsoft. 2017. "UEFI/GPT-based hard drive partitions". https://docs.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions

・Microsoft. 2017. "BIOS/MBR-based hard drive partitions". https://docs.microsoft.com/ja-jp/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions

・TechNet Microsoft. "Create partition msr". https://technet.microsoft.com/ja-jp/library/cc770438%28v=ws.10%29.aspx

・Smith, Rod. "GPT fdisk Tutorial". http://www.rodsbooks.com/gdisk/

・Russinovich, Mark et al. 2012. Windows Internals, Sixth Edition, Part 2, "Chapter 12 File Systems", pp.391-498. Microsoft Press. Washington.

・Disklessfun. 2012. 「Tips: 強力な(?)NTFSのPBR修復法」. http://wikiwiki.jp/disklessfun/?fixpbr

・おくやま電脳工房. 「データ復旧のプロが見た"間違いだらけのデータ復旧"」. http://www.den-now.com/pc-otasuke2.html

・菅谷みどり(@IT). 2003. 「VFSとファイルシステムの基礎技術」. http://www.atmarkit.co.jp/ait/articles/0305/20/news002.html

・Brinkmann, Martin(ghacks.net). 2009. "Remove Unconnected Storage Device Information From Windows". https://www.ghacks.net/2009/12/05/remove-unconnected-storage-device-information-from-windows/

・TechNet Microsoft. 「仮想ディスク サービス (VDS) について」. https://blogs.technet.microsoft.com/askcorejp/2012/12/02/vds/

・Russinovich, Mark (TechNet). "Windows 8 volume compatibility considerations with prior versions of Windows". https://social.technet.microsoft.com/wiki/contents/articles/15645.windows-8-volume-compatibility-considerations-with-prior-versions-of-windows.aspx
(以上閲覧日:2017年7月17日)


3. 光学ディスクのフォーマット

 光学ディスクは、成形時に物理フォーマットないしローレベル・フォーマットが施され、一般のユーザがそれを変更することは不可能な記録媒体である。ユーザが光学ディスクに対して行うことのできるのフォーマットは、論理フォーマット、つまりファイルシステム・フォーマットのみである。それは「初期化」と呼ばれることもある。

 PCにおいて用いられる光学ディスクのファイルシステム・フォーマットは、大きく2種類に分かれている。Compact Disc File System(CDFS) とUniversal Disk Format(UDF)である。

(1) Compact Disc File System(CDFS)

 Compact Disc File System(CDFS)という規格は、ISO 9660として標準化されている(Wikipedia、「ISO 9660」)。これは、1988年にISOで標準化されたもので、当然ながら当時はCD向けであったが、その後DVDやBDにも用いられている。これには様々な拡張規格があり、Windowsでは、ファイル名形式につき8.3形式(名前は最大8文字、拡張子は最大3文字で表記される)から最大32文字のファイル名を使えるようにしたJolietという拡張規格が用いられる(MSDN、「Disc Formats」)。

 ISO 9660で書き込む場合、通常はディスク・アット・ワンス(Disc at once)という記録開始を表すリードインから記録終了を表すリードアウトまでを1回で書き込む方式がとられる。この方式だとディスクに容量が余っていたとしても追記することはできないが、最も互換性が高くほとんどの機器で読み取ることができるようになる。

 しかし、この方式はCD-Rにとって無駄が多すぎることから、ライティングソフトによって、トラック・アット・ワンス(Track at once)やセッション・アット・ワンス(Session at once)などトラックやセッションごとにリードイン・リードアウトを書き込み、追記を可能にする方式がとられるようになった。但し、それらの方式はライティングソフト固有のものであるため、同じライティングソフトがなければ、読み取ることも追記することもできない。従って、最終的にはファイナライズ(Finalize)という共通の処理を施して読み取り専用のディスクにすることによって、互換性を高めることになる。

(2) Universal Disk Format(UDF)

 ISO 9660に代わるファイルシステムとして、Universal Disk Format(UDF)が1995年に策定され、ISO/IEC 13346として規格化された。(Wikipedia、「ユニバーサルディスクフォーマット」)。

 これには、UDF 1.01(1995年)、UDF 1.02(1996年)、UDF 1.50(1997年)、UDF 2.00(1998年)、UDF 2.01(2000年)、UDF 2.50(2003年)、UDF 2.60(2005年)のバージョンがある(小町 祐史、「一連のUDF (Universal Disc Format)に対応するJISの整備」)。UDF 1.50でファイナライズの必要のないパケットライトに対応するようになった。このフォーマットを使えば、CD-RやDVD-Rであってもデータの書き込みや読み取りが随時可能となるが、データを削除した場合、その部分は空き容量として復活することはなく、書き込み不可となっていく。

 このUDFが、Windowsでは、「ディスクの書き込み」を行う際に、「USBフラッシュドライブと同じように使用する」(ライブファイルシステム)を選択すると適用されるフォーマットである。

 また、UDF BridgeというUDFとISO 9660の両方を兼ね備えたフォーマットがあり、UDFに対応していない機器でもISO 9660によって読み出すことができる。Windowsで「CD/DVDプレイヤーで使用する」(マスター)を選択すると、このUDF Bridgeが適用される。この場合のUDFは1.02だとされる(ウェブノコエ、「ディスクアットワンス方式・ISO9660でCD/DVDに書き込む」)。

 なお、CD-R、DVD-R、BD-Rは、フォーマットの書き直しが不可能であるから、いずれかのフォーマットが既に適用されていれば、当然他のフォーマットで使用することはできない。CD-RW、DVD±RW、DVD-RAM、BD-REは、フォーマットの書き直しが可能であるから、どのフォーマットでも繰り返し使用できるが、PC以外の機器によっては対応していないディスクがあるので注意する必要がある。

(3) ISOイメージ(ISO image)

 ISOイメージ・ファイルは、光学ディスクに書き込まれるファイルやファイルシステムなど全ての情報が正確に写し取られて1つにまとめられたものである。このファイルシステムには、ISO 9660のファイルシステムだけでなく、UDFのファイルシステムも含めることができる。ISOイメージ・ファイルを書き込むときに、ファイルシステム・フォーマットが行われると捉えることができる。それゆえ、CD-RやDVD-Rなどは、未フォーマットの状態でなければ、ISOイメージを書き込むことはできない。

 ISOイメージ・ファイルは、勿論光学ディスクに書き込むものであるが、それ以外の方法で使用することも可能である。ISOイメージをUSBメモリ等に書き込むこと、あるいはISOイメージが書き込まれたディスクとして仮想光学ドライブをPCにマウントすることを可能にするソフトウェアがある。Webにはそのようなフリーウェアがいくつもあり、利用している人も多い。

※参考:
・Wikipedia. 「ISO 9660」. https://ja.wikipedia.org/wiki/ISO_9660

・MSDN Microsoft. "Disc Formats". https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa364836%28v=vs.85%29.aspx#udf

・Wikipedia. 「ユニバーサルディスクフォーマット」. https://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%8B%E3%83%90%E3%83%BC%E3%82%B5%E3%83%AB%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88

・小町 祐史(国士舘大学). 「一連のUDF (Universal Disc Format)に対応するJISの整備」. http://www.y-adagio.com/public/confs/miscel/oit/doc1_3.pdf

・ウェブノコエ. 2017. 「ディスクアットワンス方式・ISO9660でCD/DVDに書き込む」. http://www.review-rank.net/?p=4512

・加藤和利(日立製作所). 1999. 『第2特集 急速な普及を始めたDVDの世界』. 「第1章 UDFの詳細とWindowsにおけるDVDの制御方法」, 「DVD-RAMの仕組み」. http://www.cqpub.co.jp/try/1999-9/toku2-1.htm
(以上閲覧日:2017年7月23日)

フォーマット、その1~物理フォーマット」】

tag : 論理フォーマット MBR GPT PBR パーティション NTFS FAT32

コメントの投稿

管理者にだけ表示を許可する

プロフィール

そんぷうし ふうえん

Author:そんぷうし ふうえん

忙中閑は、こっそりと見出す。
カミさんと子どもたちが寝静まるのを待って、夜な夜なPCの前に端座し、その不可思議なる箱の内奥にそっと手を入れては、悦に入る日々なのであります。
時としてその手はPC以外の内奥にも。


※ リンク貼付及び引用は自由ですが、引用する場合は該当ページのURL及びタイトルを明記して下さい。

Automatic Translation
If you click a language below on any page, the translator is supposed to display the latest page at first. So you need to jump back to the previous page you were about to read.
Please note that there are some translations that are non-grammatical and do not accurately reflect the meaning of the originals because of machine translation.
 【Translated by Google Translate】
全記事一覧表示

   全ての記事のタイトルを表示する

最新記事
カテゴリ別アーカイブ
最新コメント
月別アーカイブ
検索フォーム
リンク
最新トラックバック
RSSリンクの表示
累計閲覧回数
  
QRコード
QR