01 7月 2010 @ 7:19 PM 

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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

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

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

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

  1. regedit.exeで
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory
    の値を
    %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_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory
    の値を
    %SystemDrive%\Users
    に戻す
  9. ログアウト
  10. 元のユーザでログイン
  11. tempユーザを削除

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

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

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


Posted By: ゆ。
Last Edit: 01 7月 2010 @ 07:19 PM

EmailPermalinkComments (0)
Tags
Tags:
Categories: PC, Windows
 01 7月 2010 @ 1:59 AM 

前のエントリで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なりにしておいたほうがいいだろう。


Posted By: ゆ。
Last Edit: 03 7月 2010 @ 01:18 AM

EmailPermalinkComments (0)
Tags
Categories: Linux, PC, Windows

 Last 50 Posts
 Back
Change Theme...
  • Users » 100
  • Posts/Pages » 314
  • Comments » 177
Change Theme...
  • VoidVoid « Default
  • LifeLife
  • EarthEarth
  • WindWind
  • WaterWater
  • FireFire
  • LightLight