最近の変更サイトマップ

Windowsの記憶域階層の挙動(SSD層が優先的に使われるよ)

Windowsの記憶域階層について調べてたら、MSの中の人が書いたUnderstand Storage Space Tiering in Windows Server 2012 R2がとても分かりやすかった。Windows Server 2000 R2時代のものだけど、今でも通じる内容でしょう多分。記憶域階層使おうとしてる人は一読しといた方がいいと思う。

元記事の焼き直しでしかないが、気になったことをメモっておく。

書き込み時

  • 記憶域階層に入ってくるデータは、まずはSSD層に満杯になるまで書き込まれる。
  • SSD層が満杯になると、ランダムライトはSSD層内に予め確保されているライトバックキャッシュの方に書き込まれる。
  • ライトバックキャッシュも一杯になると、HDD層の方に書き込まれると共にライトバックキャッシュのHDD層へのフラッシュが行われる。
  • ライトバックキャッシュが空けば、ランダムライトは再びキャッシュの方に書き込まれる。

ここでのライトバックキャッシュとは、記憶域階層が持っている機能を指している。仮想ディスク毎にSSD層に確保される領域で、標準では1GBだがNew-VirtualDiskコマンドレットの引数-WriteCacheSizeで任意の容量を指定できる。前述の通り、SSD層が埋まらないとライトバックキャッシュは使われないため、あまり大きな領域を確保しても無駄だと思われる。

自分はてっきり、ライトバックキャッシュという名前の通り、その領域分が書き込み全般のキャッシュとして使われると思っていた。Crystal Disk Markでキャッシュサイズを超えるテストサイズでベンチ回しても速度が全く落ちずに不思議だったが、なるほどSSD層全体がキャッシュとして使われてたとはね。

読み込み時

読み込みの方は明確な説明がないので間違ってるかも…。

  • SSD層にあるデータはSSD層から読まれる。
  • SSD層にないデータはHDD層から読まれる。
  • 毎日の記憶域階層最適化によりSSD層とHDD層でデータの入れ替えが行われ、よく使われるデータはサブファイル単位でSSD層に配置される。

自分はZFSしか知らんのでZFSとの比較になっちゃうけど、読み込みキャッシュの方は割と慎ましい挙動のように思う。記憶域階層最適化のサブファイル単位というのは、1MBブロック単位らしい。

これらの挙動から分かる通り、記憶域階層ではSSD層が酷使されるため、相応のSSDと相応のデータ保護手段を用いた運用にしないとトラブりそう。SSD層が死んだ場合に、記憶域スペース/仮想ディスクがどうなるかは未確認&情報がない…。仕組み的にはSSD層にあるデータが死ぬだけで済みそうに思うんだけど、どうだかなー。現状、一旦記憶域階層として作ったが最後、後からSSD層を取り外す事もできないしなー。

参考サイト

Windowsの記憶域階層な共有フォルダがプチフリする謎現象

Windows Storage Server 2016の記憶域階層上に作成したCIFSな共有フォルダに別マシンからファイルを書き込むと、途中で処理が止まったようになり、当該フォルダを開くのですら超絶時間が掛かるようになる問題に遭遇中。なんとなく、SSD層が一杯になったタイミングで発生してるような気がするけど、有効な解決策は未だ見つけられず…。

記憶域階層は以下のような構成。

  • SSD層
    • Intel DC S3500 240GB×2 (RAID-0)
  • HDD層
    • 8TB 7200RPM SATA×6(HDD×2のミラーリングが3セットのRAID-10)

いずれもハードウェアRAIDカードで仮想ドライブになってるので、記憶域からはSSDとHDDが1台ずつ見えてる感じ(ま、この構成自体がそもそも非推奨なんだけど。)

そこに1KB~4GBの96ファイル計25.2GBをコピーすると、最初は順調なのに途中でパタリと処理が止まる。タスクマネージャを見ると「記憶域階層管理」なるものが動いているので、おそらくSSDが一杯になってHDDへのデータ移動が行われているのだろう。

でもって、リソースモニタでディスクの状態を見てみると、処理対象のファイルの応答時間がなんと1000ミリ秒を超えているじゃーありませんか。キューもめっちゃ溜まってるし(順調に処理が行われてる時は1未満。多くても3~4ってとこ。)データ移動待ちにしては、流石にレイテンシ長すぎじゃないですかね…。

実際の操作感としては、SSDに一定の空きができるまでファイルI/Oがブロックされてるような感じ。MSの中の人によれば、SSD層が一杯になるとIOPSが劇的に下がる──といってもHDD層相当の性能は出るんだけど(記事中のTest Case 1: Write to Used Storage Spaceらへん)、処理が完全に止まってしまうような感じになならなさそう。

ネットに上がってる記憶域階層の使用例は殆どがHyper-Vがらみなので、ファイルサーバ向けに記憶域階層を使うってのがそもそもの間違いなのかしら?そうは言っても、使用頻度の高いデータをSSD層において高速化するって場面は、FSでもふつーにありそうな感じがするんだけどなぁ…。

Sambaだと大量のファイルの扱いに難あり、ってところからCIFSの純正実装なら安心だろうってことでWindows Serverを選択したのに、トホホですよ本当。僕たちの調査の旅はこれからだ…!

(2018-08-16 追記)

何の役にも立たないと(僕の中で)名高いMSKKのフォーラムに同様の報告があった→記憶域スペースで階層化構築時における急激なパフォーマンス低下について。いつものごとく箸にも棒にもかからない回答で乾いた笑いしか出ないわけですが。

Windowsインストール時にdiskpartで手動でパーティションを作る方法

いつごろからは知らんが少なくともWindows 10では、大規模更新時に回復パーティションの容量が不足していると、新たな回復パーティションを作るという大変お行儀の悪いことをしてくれやがる。だもんで、最近は手動でパーティションを切るようにしてるのだが、毎度やり方を忘れるのでメモ。

diskpartの起動

Windowsインストーラのパーティション設定画面でShift+F10を押すとコマンドプロンプトが開く。そこでdiskpartに入る。

パーティションの設定

GPT/UEFIで必要なパーティションと容量は下表の通り。

MS推奨

種類 ファイルシステム 容量 備考
ESP FAT32 従来100MiB、4kセクタの場合260MiB
MSR - 16MiB
Windows NTFS 最低20GiB Windowsのインストール先
回復 NTFS 最低300MiB、推奨1GiB

オレオレ構成

種類 ファイルシステム 容量 備考
ESP FAT32 512MiB 根拠:ESPの容量は512MiB以上が推奨らしい
MSR - 128MiB Windows 7ではこの容量だったので踏襲。後から足りなくなるよりはマシかと。
回復 NTFS 3072MiB 推奨容量×2+念のため1GiB
Windows NTFS 20GiB〜 パーティションを拡大・縮小する可能性があるので最後に配置

diskpartで設定

ディスクや容量は適宜読み替えてくだしあ。

GPTで初期化

select disk 0
clean
convert gpt

MSRが勝手に作成される(ことがある)ので一旦削除

select partition 1
delete partition override

ESP

create partition efi size=512
format quick fs=fat32 label="System"
assign letter="S"

MSR

create partition msr size=128

回復

create partition primary size=3072
format quick fs=ntfs label="Recovery tools"
assign letter="R"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001

Windows

create partition primary
format quick fs=ntfs label="Windows"
assign letter="W"

list volume, list partitionで↓こんな感じになってればおk

パーティション情報のリロード

コマンドプロンプトをexitか右上のバッテンを押して終了後、パーティション設定ウィンドウの「最新の情報に更新」を押し、設定したパーティション情報を認識させる。

あとは通常通りWindowsをインストールする。

参考サイト

FreeBSD 12でRAID-Zのvdev拡張が出来るようになるかもしれない

Twitterを眺めてたら「ZFS RAIDZ expansion」なるパワーワードが目に飛び込んできた。

調べたところOpenZFS Developer Summit 2017で発表された機能で、その名の通りRAID-Zプールの構成を後から拡張できる機能のようだ。我らがFreeBSD Foundationからも声明が出ていた。Delphixとの協業のようで。

ご存知の通り、現在のRAID-Zでは後からプールのvdev構成を変更することが出来ない。この制約のため、例えばHDD×3本でRAID-Zプールを作ったが最後、容量が足りなくなったからといって、後からHDDを1本追加してHDD×4本構成にするといったことが不可能なのだ。容量を増やしたければ、vdevの構成HDDを大容量のものに入れ替えるか、別のvdevを追加するか(先の例で言えばHDD×3本のRAID-Zセットを追加してRAID-Zのストライピングにする)しかない。だがしかーし、RAID-Z expansionが実装されれば、これまで不可能だった直感的なプール拡張が出来るようになる。ZFSが今以上に使いやすくなること間違い無し!

声明によれば”FreeBSD 12.0で利用可能になるだろう”(RAID-Z expansion is expected to become available in FreeBSD 12.0.)とのこと。”expect”は7割くらいの確度だから実現性は結構高い。OpenZFSとしての実装になるようなので、実現の暁には多くの環境に恩恵があるだろう。FreeBSDのみならずZFS界隈にとって、なかなかインパクトのあるニュースではなかろうか。

現時点でFreeBSD 12のリリーススケジュールは未定だけど、とにかく楽しみな機能ですわー。

OpenZFS Developer Summit関連ついでに、ZFSをWindowsに移植するプロジェクトZFSinの存在も知った。マイルストンを見るに殆どの機能が実装されており、問題なく動きそうな雰囲気…!これも胸熱……!!

参考サイト

HP Z210 CMTはSATAのモードをAHCIにしてもIDEが生えてくる

ひょんな事からHP製のデスクトップPC、Z210 CMTを購入した。Sandy Bridge世代のマシンだけど大抵の用途には十分すぎるほどの性能を有していながら、OSなしなら中古で2万円と相当なお買い得品。OSありでも2.5万円ほどからで、この世代のメーカー製PCは本当にお買い得だと思う。下手に自作するより全然安上がりだ。

さて、そんなZ210に手持ちの余剰Windows 7ライセンスでWindows 10を入れたのだが、デバイスマネージャを見てみたらストレージコントローラが標準IDEになってるじゃないですかー、やだー!!

Z210でAHCIモードなのに標準IDEコントローラがある

BIOS設定がIDEのままインスコしたか!?と思って確認するもRAID+AHCIになってるし、IDE→AHCI変更のレジストリをいじっても、再度OSを入れ直しても相変わらずIDEコントローラはいるしで訳が分からないよ!AHCI設定はどこに消えちゃったの…。

もうIDEでいいや…と、諦めかけたその時!デバイスマネージャを良く見たら、下の方にAHCIコントローラがあるじゃん…。ちゃんと有効になってるじゃないですかー、やだー!!

ちゃんとAHCIコントローラがあった

というわけで、Z210 CMT(多分Z210 SFFも)はSATAをAHCIモードにしてもIDEコントローラが生えてくるのであった。もしかして他のマシン、つーかWindowsってそういう仕様だっけ・・・?Windowsいじるの久々で忘れちゃった☆(・ω<) → 会社PCで確認したら、やっぱりAHCIの場合はIDEは生えない模様。

start.txt · 最終更新: 2016-05-07 17:46 by decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0