



ファイルサーバの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にチェックを入れる。
ここでファンの回転数の自動制御について設定することになる。
各設定値の関係は以下の通り。
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になる。
これを変更したい場合、以下のようにする。
diskpartでのフォーマットの仕方は、フォーマット対象のディスクを選択、フォーマット対象のパーティションを選択、フォーマットという流れ。
以下のような感じ。
DISKPART> list disk
ディスク 状態 サイズ 空き ダイナ GPT
### ミック
———— ————- ——- ——- — —
ディスク 0 オンライン 2000 GB 0 B
ディスク 1 オンライン 1726 GB 1442 GB
ディスク 2 メディアなし 0 B 0 B
ディスク 3 メディアなし 0 B 0 BDISKPART> 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 GBDISKPART> 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はきっておいたほうがやりやすい。
以上でユーザディレクトリの実態は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なりにしておいたほうがいいだろう。


More Options ...
Categories
Tag Cloud
Blog RSS
Comments RSS

Void « Default
Life
Earth
Wind
Water
Fire
Light 