JavaScriptプロトタイプコードは、論理ボリュームを整理するタスクを解決するときに、ベースシステムユーティリティDISKPART.EXEよりも確実に高速です。
プロトタイプJavaScriptコードの実装は、問題を解決するまでにリファレンスシステムユーティリティDISKPART.EXEを確実に上回るアルゴリズムが記述されています。 アルゴリズムのベースとなる原理が説明されています。 DISKPART.EXEがJavaScriptコードよりもゆっくりと問題を解決する理由について、可能性のある説明が提供されていますが、証拠ではありません。 Windows 10 RTM TH1を含むさまざまな出版物のWindows環境での競争力のある結果が示されています。 Windows 10のさまざまなエディションで行われた変更が、速度を多少犠牲にしてはいますが、信頼性を高めるためにアルゴリズムを何度もやり直すことを強制した方法について説明します。
エントリー
論理ボリュームはOSの基礎となります。 論理ボリュームがない限り、システムには配置する場所がありません。 論理ボリュームの準備には、物理ストレージデバイス上のスペースの割り当て（つまり、データボリューム、ストレージ＃ボリューム、多くの場合、正確にパーティションと呼ばれない場合があります）の割り当て、およびOSのコンポーネントが配置されるファイルシステムの作成が含まれます。 以下は、Windows OSに関連して論理ボリュームを注文するタスクを解決するためのアルゴリズムですが、GitHubに投稿されたアルゴリズムの詳細な説明では、他のOSと比較されます。
説明されたアルゴリズムが基づいている原則
説明されているアルゴリズムは、2つの原則に基づいています。
1.子オブジェクトが親オブジェクトから取得した一意の「遺伝的」プロパティによる「自然な並べ替え」の使用。
2.親オブジェクトの「遺伝コード」に基づいて、オブジェクトの「住所」、オブジェクトに関する詳細情報のキャリア、親から1つの距離の計算。
親から1レベル離れた各オブジェクトは、同じ親によって生成された他のオブジェクトと区別する多数の一意のプロパティを取得します。たとえば、誕生日、一意のシンボリック識別子、一意の数値識別子、シンボリック、一般名、保存されるデータの量などに関する技術仕様
機器メーカーによって割り当てられたまったく同じ識別子で2つのデバイスがシステムに表示される場合の衝突を避けるため、デバイスがシステムに最初に表示されるときに「番号付きタグ」がそのような各識別子に添付されます。
機器メーカーとオペレーティングシステムによるストレージデバイスの識別
さまざまなサブクラスのハードドライブ、フラッシュドライブ、DVDおよびCDドライブ（内部、外部、仮想、読み取り専用、読み取りおよび書き込み、記憶媒体の選択あり）、テープドライブ、フロッピードライブのメーカー。
機器の製造業者（製造業者）は、製品の寿命を延ばす瞬間から一意で、破壊せず、既存のものを提供します。 システムで呼び出される識別子「PnPDeviceID」は、かなり長いテキスト文字列で表され、「＆」記号でサブグループに分割されます。 サブグループには、製造元の名前、特定の製品の名前、バージョン番号、製品クラスなどが含まれます。
ストレージデバイスのいずれかが特定のオペレーティングシステムによって最初に認識されるとすぐに、対応するデバイスは（1つの例外を除いて）GUIDと呼ばれる非常に短く、厳密に形式化された一意の識別子を取得します。 GUIDの長さは42 ASCII文字で、そのうち6文字はサービス文字です。 この点で重要なのは32桁の16進文字のみであり、特定のアルゴリズムに従って、システムはこれをすぐに8バイトの数値QWORDに変換します。 システムハッシュアルゴリズムを使用するこれらの8バイトの数値は、対応するオブジェクトへの「直接アクセス」および列挙を作成してオブジェクトを順序付けるためにさらに使用されます。
例外。 GUIDを持たないストレージデバイスの少なくとも1つは、すべてのエディションおよびエディションのWindows環境で、「cdrom」ドライバー、HKLM \ SYSTEM \ CurrentControlClass \ Services \ cdrom \ Enumによって提供される一般名「DVD-ROM」のデバイスクラスです。 。
そのようなデバイスの場合、OSによって割り当てられた識別子PnPDeviceIDがシステム内の唯一のデバイス識別子です。
Windows衝突解決
Windowsは、産科病院でのベビーシッターとまったく同じことを行い、新生児の手にタグを結びます。OSがPnPDeviceIDを認識し、同じからの別の類似デバイスに割り当てる必要がある場合、OSは製造業者からの識別子に「番号付きタグ」を割り当てますメーカー。 この「番号付きタグ」は、最後に標準の区切り文字「＆」を使用して割り当てられ、まったく同じPnPDeviceIDを持つ2つのデバイスがシステムに表示されないようにします。
PnPDeviceIDは、システムによって最初に認識された絶対にすべてのストレージデバイスに対して作成されます。 ただし、前述のように、「DVD-ROM」以外のすべてのデバイスの場合、システムはGUIDも作成します。 それでは、製造元のまったく同じ識別子を持つ2つのデバイスでGUIDがどのように異なるのでしょうか。GUIDの「番号付きタグ」はどこでハングしますか？ タグ番号は、最初のGUIDフィールドの最後の2つの16進数文字です。 8.1とWindows 10 RTM TH1のプログラムレポートを比較する場合、より詳細な説明を以下に示します。
追加のユニークなストレージ機能
論理ボリュームに適用：
ボリュームのシリアル番号SerialNumber 。 OSは、仮想DVD-ROMも含めて、絶対にすべての論理ボリュームデバイスに割り当てられます。 シリアル番号は8桁の16進文字で表されます。 このフィールドでは、排除できないコリジョンが発生する可能性があり、システムは必要がないため、これを試みません。 シリアル番号「00000000」は、何らかの方法で完全に暗号化されたすべての論理ボリュームによって取得され、システムは、ボリュームがデコードコードでマウントされるまでボリュームのシリアル番号を読み取ることができません。 したがって、論理ボリュームのSerialNumberフィールドの8つのゼロは、このボリュームが暗号化されていることを自信を持って示しています。
ストレージデバイスの場合：
デバイスのシリアル番号、SerialNumber 。 デバイスの製造元によって割り当てられます。 8つの16進文字。 論理ボリュームのみが何らかの方法で暗号化されたデバイスでも、システムに保存されます。
署名ディスク、署名 。 デバイスの製造元によって割り当てられます。 8つの16進文字。
ディスクにGpt形式のパーティションが含まれている場合、すべてのオペレーティングシステムはシステム内のディスク署名の表示をブロックします。 これは間違いなく、ディスクシグネチャの有無によって、ディスクの低レベルI / O操作を使用せずに、ディスク上のパーティションをフォーマットするスタイル：Mbr / Gptを決定できるシステムトリックです。 これは、HKLM \ HARDWARE \ DESCRIPTION \ System \ MultifunctionAdapter \ 0 \ DiskController \ 0 \ DiskPeripheralに格納されているディスクプロパティで非常にエレガントに示されています。プロパティ "Identifier" = "9cb5ff90-00000000-A"が格納されます。 実際のディスク署名の代わりに疑いなくOSによって特別に書き込まれた8つのゼロは、ディスク上のパーティションがGptフォーマットスタイルを持っていることを示します。
異なるバージョンのWindowsを実行した結果
Windows 10 RTM TH1ビルド10240
|
N
| EnumDevicesAndVolumes.wsf
| DISKPART.EXE
|
1
| 2.140
| 6.235
|
2
| 1.452
| 2.936
|
3
| 2.530
| 2.953
|
4
| 2.541
| 2.867
|
5
| 1.448
| 2.905
|
Windows 8.1ビルド9600
|
N
| EnumDevicesAndVolumes.wsf
| DISKPART.EXE
|
1
| 1.243
| 5.274
|
2
| 1.222
| 2.558
|
3
| 1.218
| 1.289
|
4
| 1,200
| 1.379
|
5
| 1.379
| 1.425
|
Windows 7 SP1ビルド7601
|
N
| EnumDevicesAndVolumes.wsf
| DISKPART.EXE
|
1
| 1.406
| 11.913
|
2
| 1.319
| 2.130
|
3
| 1.338
| 2.662
|
4
| 1.310
| 2.788
|
5
| 1.287
| 2.698
|
小さいサイズのJavaScriptコード、WhoIsFaster.jsは、EnumDevicesAndVolumes.wsfおよびDISKPART.EXEの実行に対応するコマンドライン（WShell.Exec）を順次実行しました。 1つのプログラムと他のプログラムの実行中に、StdOutのプログラムによって表示される行と読み取り行が読み取られ、コード実行のプロセッサー時間を非常に正確に測定するためにバッファーされました。 ミリ秒の精度で測定が行われ、表のいたるところに秒とミリ秒が表示されます。
残念ながら、これらの数値はプロセッサ時間を反映するだけではありません。EnumDevicesAndVolumes.wsfは、主な作業を完了し、すべてのレポートを表示した後、DISKPART.EXEを実行するコマンドラインで使用される現在のディレクトリに入力ファイルも作成しました。 したがって、両方のプログラムで使用されるプロセッサ時間に、ディスクI / Oに費やされる時間も追加する必要があります。 ディスクへの書き込みにかかる時間は読み取り時間より明らかに長いため、DISKPART.EXEにはこのパラメーターに関していくつかの利点がありました。
ハードウェアプラットフォーム
Thinkpad R500、2.4Gz、8Gb RAM、ATI Mobility Radeon HD 3400、1650x1080、2つの内部ドライブ。 最初のメインの4つのセクション。 第二に、2つのセクション。
Windowsのさまざまなバージョンにインストールされたアプリケーション
Windows 7エンタープライズ評価。 Total CommanderとFree Javascript Editorのみがインストールされます。 同じプログラムが他のシステムにインストールされています。
Windows 8.1：MS Office 2013、Acronis True Image 2015、Acronis Disk Director 12、バックアップの作成とパーティションのサービスのためのAOMEIのプログラム。 HKLM \ SYSTEM \ CurrentControlSet \ Servicesに列挙を作成する独自のドライバーフィルターを実行するアプリケーションのみが一覧表示されます。
Windows 10：Technical Preview Build 10049以降、インストールされているアプリケーションとその設定を失うことなくWindows 8.1を更新できるようになったとき、現在のバージョン8.1が更新されました。 将来、Windows 10は公式にリリースされたすべてのアセンブリによる更新を受けたため、9600および10240環境でのアプリケーションソフトウェアの構成は完全に一致しました。
結果の解釈
Windowsの3つのエディションすべての競争力のある結果は非常に近いものです。 Windows 10では、プロトタイプコードの速度は、以前のエディションよりもOneDriveとの同期サービスを自動的に開始する多数の開いているページ、MS Office 2013 Wordを備えたパラレルブラウザーの影響をより大きく受けることに注意してください。 そのため、Windowsを起動した直後は、常に「競合」が同等の条件で保持されています。
Windows 8.1で解釈されたEnumDevicesAndVolumes.wsfコードと比較して、DISKPART.EXEの大幅に遅い速度を説明するにはどうすればよいですか？ 根拠のない説明は1つだけです。 すでに述べたように、すべてのストレージデバイスと、それらに作成されたデータボリュームと論理ボリュームに対して、システムはQWORDキー（8バイト）を使用してハッシュテーブルを操作します。
説明したアルゴリズムは、同じ目的のために、フィールド1のGUIDフィールドのみを使用します。これは、システムがQWORDに変換します。 システムハッシュテーブルへのアクセス速度の依存関係を評価するのに十分な知識とデータはありませんが、この依存関係は非線形であり、最良の場合はN * log（N）に反比例するようです。Nはビットまたはバイト単位のキーの長さです。 したがって、DISKPART.EXEのラグを説明できるのは、説明されているアルゴリズムで使用される短いキーです。
Windows 10 RTM TH1 Build 10240が登場する前は、さまざまなアセンブリの環境での競合結果は8.1の結果とわずかに異なっていました。 ただし、アセンブリ環境10240では、キー列挙アルゴリズムが根本的に変更されました
HKU \ SID \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ MountPoints2 \ CPC \ Volume：7601から10166で終わる「children goes family」、つまり、同じ物理ディスク上に作成されたすべての論理ボリュームが厳密に従うディスクの先頭からの変位が大きい順に次々と、環境10240で論理ボリュームの「自然な」順序付けが初めて導入され、ボリュームがシステムにマウントされた順序で厳密にリストされます。 この変更は、論理ボリュームを使用してシステムを高速化するためのものでした。 DISKPART.EXEは、まだこの列挙を使用しておらず、cdromドライバーによって提供されるデバイスをフロントランクにプッシュしているようです。
問題解決の結果の視覚的提示
図1DISKPART.EXEによる論理ボリュームに関する情報のこの出力は、「従うべきタスク」であり、迅速な解決アルゴリズムを作成しました。 以下の図2と3は、EnumDevicesAndVolumes.wsfによって生成される多くのレポートの1つです。 これらは、EnumDevicesAndVolumes.wsfによって生成されるすべてのレポートの中で最も短いものです。 それでも、このレポートでさえ、上記のDISKPARTレポートよりも多くの情報が含まれており、Statusカラムのように無意味な情報は含まれていません。すべてのボリュームが正常であるのは当然です。
図2
図3図2は、Windows 8.1のEnumDevicesAndVolumes.wsfの簡単なレポートを示し、非常に類似した図3は、Windows 10 RTM TH1の類似のレポートを示しています。 違いはF1フィールドの値にのみ見られます。「714ce4NN」に注意してください。最後の2文字のみが、異なるMbrフォーマットのディスク、SDカード、2つのGptフォーマットVHDの最初のパーティションに対してDevGUID.F1の違いを提供します。 さらに、Mbrフォーマットのディスク上のパーティションに対応する異なるVolGUID.F1のフォーマットは同じです。 ただし、既に述べたように、VolumeGUID作成アルゴリズムが変更されたWindows 10では、「714ce4NN」は2つのボリュームにのみ割り当てられます。1つは最初のディスク、System Reservedラベルと2つ目のディスク、TOSH-MK1646GSXラベルです。 さまざまなGUIDの「遺伝的親和性」の識別のより詳細な分析であるEnumDevicesAndVolumes.wsf JSスクリプトは、ShowResemblanse（）メソッドによって作成された特別に作成されたレポートに表示されます。
刊行物の最初の部分に関する結論
私の考えでは、ロシア語の「レジストリ」は「納屋の本」に似ており、Windowsレジストリである階層データベースではなく「フラットファイル」を指すという事実によって、「システムレジストリ」の代わりに「Windowsレジストリ」の使用について説明します。
なぜ「プロトタイプコード」なのですか？ 当初、DISKPART.EXEを模倣して、FADコード「Fast And Dirty」を書くことが計画されていましたが、人生とマイクロソフトは最初にFastという単語を削除することを強制しました。 それでも、コードは、3つのコレクションのコードによって配置されたオブジェクトに関連する機能を提供しないという意味で、プロトタイプのままです。
第2部では、アルゴリズムの4つのステップを説明する予定です。最初の3つは、この出版物の冒頭で宣言した2つの原則に厳密に従います。 最初の3つの各ステップは、列挙の読み取りから始まり、特定の「ごみ箱」から詳細なプロパティを抽出することから始まり、対応するコレクションに必要なすべてのプロパティを備えた詳細なオブジェクトを配置します。
ただし、希望する人は、2番目の部分を待たずに、リンクでEnumDevicesAndVolumes.wsf、WhoIsFaster.jsを見て収縮させることができます。
https://github.com/sysprg-46/EnumerateDevicesAndVolumesWin/tree/masterDOCXおよびPDF形式でのロシア語の完全な説明、およびWindows 7、Windows 8.1、およびWindows 10環境での10〜15回の「長い」競争サイクルのスクリーンショットも掲載されています。