カテゴリー別アーカイブ: Windows

Windows7でユーザフォルダをシステムドライブ以外に配置する

ユーザフォルダの位置はレジストリで記述されているので、これをいじれば別のパスなりドライブなりに変更できる。
レジストリキーは以下にある。

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList

ここのProfilesDirectoryを書きかえれば、ユーザプロファイルディレクトリを変更できる。

ただ、当然行儀の悪いプログラムはいるわけで、プロファイルディレクトリを決めうちしているようなプログラムもある。
そのため、%SystemDrive%Usersから実態へのシンボリックリンクを張るほうが都合がいいだろう。

ということで、ここではC:UsersからD:Usersへプロファイルディレクトリを変更する手順を書く。
たぶんUACはきっておいたほうがやりやすい。

  1. regedit.exeで
    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileListProfilesDirectory
    の値を
    %SystemDrive%Users
    から
    D:Users
    に書き換える。
  2. 一時的な管理者アカウントを作成する。(ここではtempユーザとする)
  3. ログオフ
  4. tempユーザでログイン
  5. C:UsersをD:Usersにコピー
  6. C:Usersを削除
  7. 管理者権限でコマンドプロンプトを起動して、以下のコマンドを入力
    mklink /D C:Users D:Users
  8. regedit.exeで
    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileListProfilesDirectory
    の値を
    %SystemDrive%Users
    に戻す
  9. ログアウト
  10. 元のユーザでログイン
  11. tempユーザを削除

以上でユーザディレクトリの実態はD:Usersへ配置され、C:UsersはD:Usersへのシンボリックリンクとなる。

一時ユーザを使わずにいけないか試してみたけど、レスキューモードレベルじゃだめだった。
ユーザフォルダ以下の特定ファイルがシステムからオープンされていてコピーできない。
Windowsのインストールディスクからコマンドラインを実行すれば、もしかしたらxcopyあたりでコピーできるかもしれない。
けどインストールディスクの起動時間結構遅いし、それなら一時ユーザ作ってやっちゃえ、ということになった。

ちなみにmklinkでシンボリックリンクじゃなくて/Jを使ってジャンクションを作っても別に問題はないはず。
Linuxユーザにとってはジャンクションなんて中途半端で気持ち悪いとおもうんだけど。

4KBセクタのHDDのRAIDその2

前のエントリでICHxRでのRAIDについてのIntelからのお話を書いたが、今度は一般的な話。

RAIDってのは複数のディスクをひとまとめにして、速度と冗長性を確保する技術だ。
ひとつのデータを複数のディスクにまたがって記録することで実現する。

とまあ、とっても当たり前の話をする。
さて、RAIDにもいくつかの種類があることはご存知だろう。
ここではミラーリングは問題の対象外であるため、RAID1は除外する。

問題が発生しうるのは、RAID0やRAID5、あるいはその他複合RAIDである。

一番シンプルなデータ分散書き込み構成であるディスク2枚によるストライピング構成を考える。

Windows 2000以降のNTFSファイルシステムにおける既定のアロケーションユニットサイズ(クラスターサイズ)は、通常4KBになる。(ディスク領域が2G未満であったり、16TBを超えるディスクからは既定のアロケーションユニットサイズが変わってくるが)
アロケーションユニットサイズは、ファイルを保持するのに割り当て可能な最小ディスク領域となる。
1byteのファイルであっても、アロケーションユニットサイズが4KBなら、実際にディスク上で占める領域は4KBとなる。

ここで、ディスク2枚のストライピングにおいて、アロケーションユニットサイズが4KBである場合、実データは各ディスクに2KBずつに分散して記録される。

さあ、ここであれ?って思わないでしょうか。
read modify write
の発生が頭をよぎります。

大嘘でした。
strip size(ストライプサイズ)ごとにデータを分散させるように書き込むため、stripe sizeが128Kの場合は256Kの書き込みなら同時に二つに書き出すけど、4Kなら片方のディスクしか使わない。

とりあえず、先日、wd20ears-00mvwb0を2枚ぽちった。
で、IntelのRapid Storage TechnologyのドライバでRAID0組みました。
Windows7とりあえず入れてみました。
で、上記のような意識があったので、実際のところパフォーマンスに影響があるのかどうか、アロケーションユニットサイズを変えてCrystalDiskMarkを何パターンか走らせてみた。

512byte


2048byte


4096byte


8192byte


16KB


64KB


シーケンシャルアクセスではアロケーションユニットサイズの影響はないことがみてとれる。
4KBのランダムリードでも差はないようだ。
512KBのランダムリードでは8192byteまでは速度向上がみられ、それ以上のアロケーションユニットサイズではスケールアップしないようだ。
4KBのランダムライトでは2048byteまでと4096byteで大きく違い、それ以上はスケールアップしない。
512KBのランダムライトでは4096byteまでと8192byteで大きく違い、16KBで少々のスケールアップがみられる。

さて、この結果をどう考えるか、いろいろ考えていたんだけども、4KBのランダムライトではアロケーションユニットサイズ4KBと8KBで差が出なかったのでいまいち結論付けに困っている件。

512KBのランダムライトではread modify writeが発生していることによる速度差だと思う。
4KBだとおきないのかっていうと、おきると思ってたんだけどなぁ。
ちなみに、ランダムライトの4Kは4000byteで、クラスタサイズのほうは4096byte。
書き込み単位がクラスタサイズに収まっていることが関係しているんだろうか?
stripe sizeを今回128Kで構築しているので、read modify writeは発生しない。
とすると単なるクラスタサイズによるスケールアップとみるのが妥当か。

とりあえず、512Kのランダムライトのパフォーマンスの差を見る限り、4KB物理セクタのHDDディスク2枚でのストライピングを構成する際には、アロケーションユニットサイズを8192byteなり16KBなりにしておいたほうがいいだろう。

4KBセクタのHDDのRAID

インテルのICHxRの場合、ちょっとしたというか、なんかでかそうな注意点があるようだ。
詳しくはこちら

要約すると以下のような感じ。

Intel® Rapid Storage Technology (Intel® RST) version 9.6で4KBセクタのHDD(まあ今時のやつならWD20EARSとかWD15EARSのことだろう)に対応した。
それより前のバージョンのドライバでOSをインストールしようとすると失敗するかもしれない。
それより前のバージョンのドライバでOSのインストールが成功したらアップグレードしないでね。

RAIDでOSをインストールする時は、RST 9.6のF6ドライバ(32bit, 64bit)を使ってインストールしてね。
AHCIはいらないよ。

Windows Vista, Windows 7向け情報

ってことだそうだ。

ところでRapid Storage Technologyって最初なんのことかとおもった。
意味合い的にRAIDコントローラ関係っぽいきはしたけど。
Matrix Storage Managerから名前変えただけだった。
紛らわしい。

ところで、こっちではIntelはICHxRでRAIDを構築するときにVistaなら(7も大丈夫だろう)ドライバはいらないっていってるんだけど、わざわざ4KBセクタのHDDではOS名指しでインストールしてけれっていってるから、やっぱいるのかの。
たぶん正確にはいらないんだけど、取り回し方がなんかちがうんだろうなぁ。
でも普通に使えてる報告あるしよくわからない。
まあ、使うのがインテル推奨ってことかの。

ffmpegのWindowsバイナリの作成

Windows環境でtsファイルをエンコードする方法をいろいろ調べていたんだけども、やっぱりffmpegでlibx264使ってエンコードが一番幸せな気がしてきた。
んだけどもffmpegはWindowsバイナリは配布していないので、自前でコンパイルする必要がある。
で、WindowsでコンパイルするにはMinGMとかcygwin使うのが一般的だと思うんだけども、コンパイル環境を整えるのはまあいいとして、肝心のコーデックやらなんやらのライブラリ群をそろえるほうがめんどくさい。
というかバージョンとか気にするとやってらんない。
で、コンパイル方法に関してはffmpeg公式にドキュメントがあり、そこを眺めていたところ、クロスコンパイルオプションがある。
ってことは、普通にLinuxでクロスコンパイルしたほうがきっと幸せになれる気がした。

さて、Windows用バイナリをLinuxでクロスコンパイルするのに手っ取り早いのは、すでにLinux環境がある人はそれで作ればいいけど、そうじゃない人はVMWareとかで適当にLinuxゲストを作るのがいいだろう。
ということでとりあえずいつもどおりdebianを使う。

。。。。。。。ってここまで書いたところでみつけてしまった。
Windowsバイナリのデイリービルド。
ここ
余裕でダウンロードできたし。

ちなみにWin64では既知のバグがあるからコンパイル中止してるらしい。
逆に言えば、自前でWin64バイナリ作ってもバグってるってことだ。
とりあえずstatic 32を当面は使っていればいいだろう。

MediaCoderを使おうかとおもったが

CUDAを試すために入れてみたMediaCoderだけど、この子いろいろな使い方ができる優秀な子っぽい。

MediaCoderはそもそも多々のCodecやらフロントエンドを使ってエンコード、デコード等々の作業をするためのフロントエンドとなる。
実際に仕事をする連中はインストールフォルダ以下のcodecsフォルダやtoolsフォルダ等にいる。

中を見ると、どうやらffmpegやらmplayerやらをWindows環境でコンパイルしたバイナリを付属して、そいつらに仕事をさせているらしい。
んだけど、実際に使おうとしてみたけど、どう考えてもLinux環境の方が幸せになれそうなので結局少々いじったところで使うのをやめた。
たぶん使いこなせばかなり強力なんだけどね。

CUDAを使った動画エンコード

今のところフリーでCUDAを使ったエンコードに対応しているソフトはMediaCoderだけのようだ。
ということでこれを入れてみる。

えーと。
使い方は。

こんな感じにするとCUDAを使ったエンコードができるみたい。

CUDAエンコードに用いるコーデックはcudaH264Enc64.exe(64bitじゃなかったらcudaH264Enc.exe)を使うようだ。
名前の通りCUDAを使ったエンコードはh.264形式にしか対応していない。
ついでに2passにも対応してない。

GPU GTX 295
CPU Core i7 920

でエンコードしてみたところ、GPU負荷は片方のみだ。
SLI構成している場合はCUDAプログラム側からは一つのGPUしか見えないって話を見かけたが、そうするとGPUに対する負荷の振り分けはドライバ側でやることになると思うんだが、めっちゃ片方しか使ってない。
ということで現時点ではMediaCoderを使ったCUDAエンコーディングでは、マルチGPUの恩恵はないとみていいだろう。

ちなみにできあがったものの画質はいまいち。
速度は速いが。

USBメモリにLinuxディストリビューションのインストーラを入れる話のその後

いつだか忘れたがUSBメモリにLinuxのインストーラCDイメージを流し込む方法やらなんやらかいた気がする。
で、なんかツールも紹介した気がする。
そのときUnetbootinを紹介したんだけど、その子、純粋なインストーライメージではなくてLive CDに勝手にしちゃったりするでぃすとりもあるみたい。
っていうかUbuntuで試したらそうだった。
で、インストール時にいろいろごたごた起きて無理矢理突破してインストールしたものの、initrdにraid関連のものが入ってなくてディスクが見えないっていう落ちでオワワ状態に。

んで、Ubuntu公式がおぬぬめしてるツールがあって、そっちでやって試したら平和にいけたんで、そっちを紹介。
前置きが長くなったけど、Universal USB Installerっていうやつ。
使い方は以下の流れ。

  1. 入れたいディストリビューションのインストーラCDなりDVDなりのISOイメージをダウンロード
  2. Universal USB Installerを起動
  3. ディストリビューションを指定
  4. ISOファイルを指定
  5. USBメモリがマウントされいているドライブを指定
  6. 特に理由がなければフォーマットにチェック
  7. 作成

BDMVあれこれ

BDMVはブルーレイのムービー形式。

市販のBDMVをHDDにコピーしたい場合には基本的にリッピングソフトを使う必要がある。
これはコピープロテクトがだいたい存在しているため。

Windows XPではまずUDF2.5(Blu-rayで採用されている標準フォーマット)を読むためのドライバが必要。
XBOX360.HD-DVDRom.UDF.Reader.v2.5.WindowsXP-BluePrintでぐぐって出てきたやつをインストールするなり、ドライブのメーカーのサイトから拾ってくるなりする。

フリーのソフトではDVDFab HD DecryptorがBDMVのリッピングが可能。
といっても30日間のtrialなので微妙だが。
ファイルへリッピングすることもISOイメージとしてリッピングすることも選択できる。
Blu-ray to Blu-rayでディスク全体を指定。
ソースにはBDMVのディスクあるいはフォルダを指定。
ターゲットにはフォルダを指定するとファイルに、isoを指定するとisoでリッピングされる。
買うならAnyDVDの方がいいかもね。

既存のリップされたBDMVのファイルからISOイメージを構築するには、DVDFab HD Decryptorでソースをそのフォルダに指定して、ターゲットをISOイメージにすることでできる。
あるいは、すでにプロテクトが外れているならImgBurnでファイル/フォルダからイメージファイルを作成を選択してもできる。

BDMVの再生はWindows標準では対応していない。
DVDドライブにバンドルされているソフトによっては再生可能だが、フリーのものではWindows Media Player Classic Homecinemaが可能。
DVDFab HD Decryptorのプレビュー機能を使って再生するという技もある。

Ext2fsdがWindows7でブルースクリーンを引き起こす

Ext2fsdをWindows7で利用するとBAD_POOL_HEADERエラーを引き起こしてブルースクリーンが発生する。
これは解放されたメモリを参照していることによって発生するらしい。
で、これを解消したパッチがあげられている。
このパッチの使い方は、freフォルダの、OSが32bitならi386の、64bitならamd64のext2fsd.sysを、Windowssystem32driversフォルダに放り込む。
ただし、このドライバは署名されていないため、64bitで利用するにはWindowsの起動時にF8でドライバの署名を強制しないオプションを指定しなければならない。

Linuxのbootable Live USBドライブの作成

Linuxをインストールしたいと思ったとき、毎回CD-Rにやくのも面倒。
USBメモリからインストールできたら楽なことがある。
で、いいものをみつけた。

UNetbootinというもの。

これがかなりの優れもの。
LinuxではもちろんWindowsでもブータブルUSBドライブを作成でき、ビルトインで対応しているディストリビューション・バージョンのものは自動でイメージをダウンロードしてくれたりし、もちろん事前に用意したCDイメージやFDD/HDDイメージ、ISOイメージからkernel/initrdファイルまでもう何でもござれ状態。

使い方は起動してみればわかるレベルなので、USBメモリブートディスクを作りたい人はとりあえずダウンロードして起動してみるといい。