相方が携帯紛失

ファイルサーバのHDDが死にかけたので再セットアップ。

lvmでパーティションきりきり。

で、ファイルシステム作成。

# mkfs.ext3 /dev/fileserver/fssystem
# mkswap /dev/fileserver/fsswap
# mkfs.ext4 /dev/fileserver/file

ベースシステムのセットアップ。

# mount /dev/fileserver/fssystem /mnt/temp
# debootstrap --arch=amd64 lenny /mnt/temp http://ftp.jp.debian.org/debian

いろいろと書き換え

fstabの設定
# cd temp
# vi etc/fstab

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/xvda1      none            swap    sw              0       0
/dev/xvda2      /               ext3    errors=remount-ro 0     1
/dev/xvda3      /fileserver     ext4    defaults        0       0

ホスト名の設定
# vi etc/hostname

files

hostsの設定
# vi etc/hosts

127.0.0.1       localhost
192.168.1.x     files.waterblue.net     files

nicの設定
# vi etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
 address 192.168.1.x
 network 192.168.1.0
 netmask 255.255.255.0
 broadcast 192.168.1.255
 gateway 192.168.1.1

ネームサーバの設定
# vi etc/resolv.conf

nameserver 192.168.1.x

aptの設定
# vi etc/apt/sources.list

deb http://security.debian.org/ lenny/updates main contrib non-free
deb http://ftp.jp.debian.org/debian lenny main contrib non-free

シリアルコンソールの設定
hvc0を使うようにしてttyは起動しない
# vi etc/inittab

1:2345:respawn:/sbin/getty 38400 hvc0
#1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

# vi etc/securetty
hvc0

hvc0の作成
# cd dev
# mknod hvc0 c 229 0

xenのDomU用設定ファイルを作る。

#
# Configuration file for the Xen instance file, created
# by xen-tools 3.9 on Sun Oct 11 14:47:01 2009.
#

#
#  Kernel + memory size
#
kernel      = '/boot/vmlinuz-2.6.32-5-xen-amd64'
ramdisk     = '/boot/initrd.img-2.6.32-2-xen-amd64'
memory      = '512'

#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [
 'phy:/dev/fileserver/fsswap,xvda1,w',
 'phy:/dev/fileserver/fssystem,xvda2,w',
 'phy:/dev/fileserver/file,xvda3,w',
 ]

#
#  Hostname
#
name        = 'file'

#
#  Networking
#
vif         = [ 'ip=192.168.1.x,mac=xx:xx:xx:xx:xx:xx' ]

#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

あとは/mnt/tempをアンマウントしてxm create file -cで起動してコンソールログインしてお好きに。
ちなみに、ext4ファイルシステムはカーネル2.6.26だと

# tune2fs -E test_fs /dev/fileserver/file

やってからext4devじゃないとマウントできなかった。
2.6.32だとext4じゃないとマウントできなかった。

最近突然全体フリーズ現象がちょこちょこ発生したりして、頭を悩ませていた。
突然フリーズするんで、原因がなんなのかさっぱり。

傾向として、TVTestを起動している時に発生している気がする。
んだが、平気なときは数時間経過しても全く何ともない。

直感的にはグラボに関係するような気がしている。
だが、確証は全くない。

グラボを買い換えようかとも考えた。
しかし、現在使っているのがGTX 295であり、買い換えるならシングルでも同等とはいわなくともそれに迫る性能のカードがほしい。
そうすると、RADEON HD 5870あたりのクラスを狙う感じになる。
だが、どうにもRADEONのドライバはゴミっぽい。
ゲームに関してはどう考えてもnVidiaの方が最適化が進んでいるし、GTX 295よりもパフォーマンスがおそらく落ちるであろう5870にわざわざ高い金出して乗り換えるメリットといえばシングルGPUソリューションである点くらいだ。
値段的に中古でも40K近い相場だし、積極的に乗り換える気は起きない。
かといってFermiは高い。
だいたい根本的に原因がグラボだっていうのは完全なる直感だ。

んで、ドライバをふと197系に戻してみることにした。
256系のドライバはなんかいろいろ大改修してるっぽいし、なんかよくわからんバグが潜んでるかもしれないっていうかきっと潜んでるし。
そのなんかにTVTestがひっかかったとかそういうのだったりするかなーとかなんとかかんとか妄想してみて。

結果、2週間以上フリーズせず今に至る。
どうもドライバだったらしい。
ただ、たぶんこれはハードウェア構成とかも関係しているんじゃないだろうかと妄想。
問題が発生しない環境の人はたぶん全然発生しない。
うちがGTX 295でデュアルディスプレイで、両方DVI接続だけども、片方は内部的にはHDMI接続になっており、メインディスプレイがそのHDMI接続のディスプレイであり、サブディスプレイの方がX座標で負の位置（サブディスプレイが物理的に向かって左）にある、っていうことと、TVTestでの描画に関連するなにがしか、これらが絶妙に何かを引き起こしてフリーズが発生しているんじゃないかなー、と何となく予想。

グラフィックカードのファンの回転数は自動制御されているが、これをカスタマイズしたい場合。
RivaTunerを使う。
モニタリングにはRivaTuner用のVistaサイドバーガジェットがあるので、これを使ってみる。

RivaTunerをインストール、起動。
pluginのRivaTuner GPU Monitor Vista Sidebar Gadgetもインストール起動。
RivaTuner初回起動時は警告とレジストリ作成が行われる。

で、まず、SettingsタブでSend to tray on closeとRun at Windows startupにチェック。
レジストリ経由かスタートアップフォルダかは好みで。

MainタブからCustomizeを選び、一番右のHardware Monitoringを選択。

enable background monitoringを選択してHardware monitoringを終了。

これでサイドバーガジェットは使えるようになってるはず。

で、Power userタブを開き、RivaTuner\FanのAutoFanSpeedControlの値に3を設定。

Mainタブのcustomizeから一番左のLow-level system settingsを選択。
Enable low-level fan controlにチェックを入れる。
なんか出てきたらdetect nowをクリック。（ほかにファンを制御しているソフト等がある場合は一度再起動した方がいい）
Apply fan settings at Windows startupにチェックを入れる。

ここでファンの回転数の自動制御について設定することになる。

• Duty cycle min – ファンの最低回転数（%）
• Duty cycle max – ファンの最大回転数（%）
• T min – 最低温度。この温度付近までコアの温度が下がるとファンの回転数がDuty cycle minになる。
• T range – ファンが最大回転数に達するまでの温度幅に関係する。
• T operating, T low limit, T high limit -T minを動的に操作して ファン回転数を強制する値。リニアに温度とファンの回転数を制御するためは不要なのであり得ない数値を設定する。

各設定値の関係は以下の通り。

T range=2/3*(T max – T min)*100/(Duty cycle max – Duty cycle min)

T max=3/2*T range*(Duty cycle max – Duty cycle min)/100 + T min

何を意味してるのかわかりにくいので、T minから1度上昇するにつれてどれだけファンの回転数があがるのかに着目する。

(Duty cycle current – Duty cycle min) / (T current – T min) = 100*2/3/T range

つまり、66.666/T rangeが1度上昇するにつき増加するファンの回転速度（%）になる。
従って、T rangeが大きくなればなるほど、温度1度あたりのファンの回転速度変化は小さくなる。
ただし、それは分母係数であるため、リニアではなく値が大きくなればなるほどなだらかな変化差となる。

なお、実際にT rangeを定める際は、最低回転速度を20%、最大回転速度を100%、ファンの制御開始温度を50度、最大温度を80度と最大回転数に達する温度を決めて、

T range=2/3*(T max – T min)*100/(Duty cycle max – Duty cycle min)

に値を代入して計算する。
この場合は25になる。

ということで、自分の好みのDuty cycle min, Duty cycle max, T min, T rangeを決めて設定する。
T operating, T low limit, T high limitは151, 0, 151とでも設定しておく。

proftpdをインストール。

# aptitude install proftpd

debian lennyだと一緒にproftpd-mod-ldapもインストールされる。
なければ入れること。

/etc/proftpd/proftpd.conf
認証時、最初にldapで行うようにし、ldap.confを読み込むように。
ほかは普通に設定。

AuthOrder                       mod_ldap.c* mod_auth_pam.c* mod_auth_unix.c
Include /etc/proftpd/ldap.conf
# ログインシェルが定義されていないなら以下も
RequireValidShell               off

/etc/proftpd/modules.conf

LoadModule mod_ldap.c

/etc/proftpd/ldap.conf

<IfModule mod_ldap.c>
#
# This is used for ordinary LDAP connections, with or without TLS
#
LDAPServer 192.168.1.x
LDAPDNInfo "cn=admin,dc=waterblue,dc=net" "somepassword"
LDAPDoAuth on "ou=Users,dc=waterblue,dc=net"
# 以下はLDAP認証したユーザを強制的に特定ユーザにマッピングする設定
# うちの都合
LDAPDefaultUID xx
LDAPDefaultGID yy
LDAPForceDefaultUID on
LDAPForceDefaultGID on

</IfModule>

LDAPDNInfoでrootdnのパスワードを記述することになるので、/etc/proftpd/ldap.confのパーミッションを変更。

# chmod 600 /etc/proftpd/ldap.conf

もしくは、LDAPDNInfoを使わず、anonymousでもLDAP認証可能なようにLDAPサーバのアクセス制御を構成しておく。
LDAPサーバの/etc/ldap/slapd.confで

access to attrs=userPassword
        by self write
        by anonymous auth
        by * none

access to *
        by self write
        by * read

みたいな感じ。

なんか昔書いたけどかなり適当だったので、ちゃんと今回は書く。

今回は以下のようなシステムレイアウト。

RAID0のアレイ1 -+- システムで予約済みのパーティション
                +- Windows7のインストールパーティション
                +- データ用パーティション

RAID0のアレイ2 -+- Ubuntu 10.04のインストールパーティション
                +- swap
                +- Debianのインストールパーティション

アレイ1のMBRにbootmgrを、アレイ2のMBRにgrubをインストールしてある。

bootmgrからはWindows7、grub4dosのエントリを作成、grub4dosはアレイ2のMBRにチェインロードするようにし、Linux系OSの起動はアレイ2のgrubから行う。

まず、Windows7を起動。
grub4dosを入手し、展開する。
ディスクの管理から、システムで予約済みの領域をマウントする。
そのパーティションのルートにはbootmgrがあるはず。
環境によってはすでにマウント済みの領域にあるかもしれない。
そこにgrub4dosのgrldr.mbrをコピーする。
menu.lstを同じフォルダに作成。
内容を以下のように記述。

title linux
rootnoverify (hd1)
chainloader (hd1)+1

これでgrub4dosからは二つ目のアレイのMBRにチェーンロードする形になる。
そこからはgrubが呼び出されるのでそっちに任せる。

bootmgrからgrub4dosを呼び出すエントリを作成する。
コマンドプロンプトを管理者権限で起動して、以下を入力。
{ID}はGRUB4DOSエントリのID。

   bcdedit /create /d "GRUB4DOS" /application bootsector
   bcdedit /set {id} device boot
   bcdedit /set {id} path \grldr.mbr
   bcdedit /displayorder {id} /addlast

これでbootmgrからgrub4dosを呼び出せる。

アロケーションユニットサイズは通常4KBで、普通にWindows7のインストーラでパーティションをきってインストールすると、やはり4KBになる。
これを変更したい場合、以下のようにする。

1. Windows7のインストーラでパーティションをきる
2. インストーラを終了させてコマンドプロンプトを起動する
3. diskpartを起動
4. インストールパーティションをアロケーションユニットサイズを指定してフォーマット
5. 再起動して対象のパーティションにインストール

diskpartでのフォーマットの仕方は、フォーマット対象のディスクを選択、フォーマット対象のパーティションを選択、フォーマットという流れ。
以下のような感じ。

DISKPART> list disk

ディスク      状態           サイズ   空き   ダイナ GPT
###                                          ミック
————  ————-  ——-  ——-  —  —
ディスク 0    オンライン          2000 GB      0 B
ディスク 1    オンライン          1726 GB  1442 GB
ディスク 2    メディアなし             0 B      0 B
ディスク 3    メディアなし             0 B      0 B

DISKPART> select disk 0

ディスク 0 が選択されました。

DISKPART> list partition

Partition ###  Type                Size     Offset
————-  ——————  ——-  ——-
Partition 1    プライマリ              100 MB  1024 KB
Partition 2    プライマリ              200 GB   101 MB
Partition 3    プライマリ             1799 GB   200 GB

DISKPART> select partition 2

パーティション 2 が選択されました。

DISKPART> format fs=ntfs unit=16k quick

いまさらながら、単純にdiskpart使わないでformatコマンドでもよかったきはする。
formatコマンドの場合は

format c: /fs:ntfs /q /a:8192

みたいなかんじ。

ちなみに、Windows7がシステムとして予約する100MBのパーティションはいじらないこと。
あそこはアロケーションユニットサイズが4KBじゃないとうまく動かない。

MBRが破損した場合に限らず、grubなんかのブートローダからbcdに切り替えたい場合も。

Windows7のインストールディスクから起動して、システム回復オプションを選択するなり、Windows7がブート可能な場合には、F8でコンピュータを修復するを選択して、コマンドプロンプトを立ち上げて、以下のコマンドを入力。

bootrec /fixmbr
bootrec /fixboot
必要があれば
bootrec /rebuildbcd

もしくはWindows7が立ち上がるなら、EasyBCDをインストールして、Manage Bootloaderからreinstall the Vista Bootloaderを選んでWrite MBRでもいける。

32bit版は試してないのでわからないが、64bit版だとインストーラにバグがある。

dmraidを使っているシステムでインストールしようとすると、インストーラでパーティションをきってインストールしようとしたとき、ファイルシステムの作成に失敗してインストールが続行できない。
/dev/mapper以下をみてみると、正しいデバイス名ではなく、末尾にpがついてその後にパーティション番号が振られたデバイスが生まれている。
この状態になったら、一回アレイをとめて再開してやってから、インストール先のパーティションをフォーマットしてやる。
インストーラから抜けて、シェルを起動、sudo suしてから以下のような感じ。

# dmraid -an
# dmraid -ay
# mkfs.ext4 /dev/mapper/isw_xxxxx_yyy1

それからインストーラを起動して、パーティションの設定をするときに、既存のパーティションのデータをそのまま使うようにして進めてやればうまくいく。

あるいは、USBメモリからインストーラを起動している場合なんかは、アップデートしてからインストーラを起動してやるとこのバグは修正されているようだ。
普通に

# aptitude update
# aptitude upgrade

してからインストーラを起動すればいけた。

あと、拡張でgrubのインストール先を選択できるが、実際のところは一番最初に見えるディスクにインストールしてしまう。
これはインストールしない以外の回避方法がみつからなかった。

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

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ユーザにとってはジャンクションなんて中途半端で気持ち悪いとおもうんだけど。

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