Core i7 2600Kを今更OCしてみた

そのうちやろうやろうと思っていたんだけどもやっていなかった2600KのOC。
SandyBridgeのOCの基本は倍率変更で行う。
FSBはいじれないと思っていい。
CPU倍率とコアの電圧だけいじればいいので、920のOCより簡単。

ということでまず軽く4GHzにトライ。
倍率を40に変更。
電圧いじらなくても当然のようにブート。
で、以前行ったCore i7 920の時と同じように、低電圧化も図る。
CPUの電圧をさくっと0.1V下げてみる。
ブート。
さすがやで。
とりあえずOCCTたたく。
固まる。
無茶振りだったらしい。
仕方がないので0.05Vにする。
OCCT。
一見いけてる。
が、ふとCPUの温度に目をやる。

99℃

ハイ駄目。
停止。
すいません、CPUクーラーリテール品です、本当にありがとうございます。
とりあえず、4GHz程度ならたぶん電圧を下げながらもOCできるだけの可能性を秘めたCPUだとは思うけど、やっぱりOCするならリテールクーラーじゃ駄目でした。
ちゃんとしたクーラー買いましょう。

仕方がないのでクロックを定格に戻して低電圧化を行うことに。
-0.1Vは余裕でした。
-0.15Vもいけました。
-0.2Vは死にました。
ということでとりあえず-0.15Vに。
もうちょい煮詰めれば限界見えるんだろうけど、まあ今日のところはこの辺にしておいてやる。

XenカーネルでのNICのカスタマイズ

Xenを使って仮想化しているマシンではネットワークも仮想化される。
そのあたりはこちら参照。

でまあそういうことで、ethtoolなんかでNICの設定をしたい場合は、通常と異なりeth0とかをいじるのではなくて、Dom0でpethをいじるのが正解。
普通はpeth0になってるだろう。

実際にethtoolをたたいてみたら、仮想NICであるethの方はろくに情報が出力されないはずだ。
それに対してpethの方はちゃんと出力されるはず。

# ethtool eth0
Settings for eth0:
        Link detected: yes
# ethtool peth0
Settings for peth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000001 (1)
        Link detected: yes

こんな感じ。

ということでXenカーネルでうごかしてるマシンのNICの設定をいじりたい場合は、pethをいじりましょう。

Postfixで迷惑メール対策

最近スパムが多くて、良いスパム対策はないかと物色。
で、なんか売り文句によると99%のスパムメール撲滅できるというものが。
基本的なコンセプトはこちらに詳しく書いてある。

  • メールサーバがメール中継サーバからのSMTPアクセスは受け入れるがエンドユーザーコンピュータからの直接のSMTPアクセスは拒絶するという単純なもの
  • SMTPアクセスをかけてきたクライアントのFQDNの特徴に基づいて、クライアントがメール中継サーバか、エンドユーザー回線につながったコンピュータかを推定することができる
  • うまく管理されているメール中継サーバのほとんどは、逆引きで得られるFQDNを持つ。逆引きFQDNのないIPアドレスからのSMTPアクセスは、少しの例外を除いて拒絶すればよい。
  • 正規表現を使うことによって、エンドユーザー用回線の逆引きFQDNとメール中継サーバの逆引きFQDNを区別する
  • メールサーバがこれらの規則によってSMTPアクセスを拒絶する時は、「後で再試行せよ」を意味する応答コード「450」を 返すべきである。そうすれば、これらの規則のいずれかに引っかかる正当なメール中継サーバを、後で述べるホワイトリスト(許可リスト)を作ることによって 救済することができる。
  • HELOコマンドが宛先サーバのIPアドレスまたは受信者のドメイン名を通知している
  • 送信者ドメインの検索失敗
  • 内容の検査

なるほどね。
エンドユーザ回線を拒絶するのはでかそうだ。
この方式をS25R(Selective SMTP Rejection)方式というそうだ。
そして、この方式とは別にGreylistingという方式がある。
Greylistingは簡単に言えば、再送要求を一旦返して、ちゃんと再送してきたものを受け取る方式。
S25RとGreylistingを組み合わせた方式がRgrey方式として紹介されている。
また、意図的な応答遅延を行うことで配送タイムアウトが通常のMTAよりも速いものを切り落とすtarpittingという方式もある。
これは、通常、スパム業者は大量のメールを配送する関係から、応答の遅いMTAには配送を早々とあきらめるよう設定されていることが多いことを利用したもの。
S25R+tarpittingによる、Starpitという手法も紹介されている。
そして、全部ごった煮のパターン、S25R + tarpiptting + Greylistingを組み合わせたtaRgrey方式が紹介されていた。
taRgrey方式の簡単な説明は以下の通り。

taRgreyとは、メールサーバ上でスパムやウイルスメールを排除するためのフィルタの手法で、 S25Rとtarpittingとgreylistingというスパム判定手法を組み合わせて使うというものです。
S25Rにより、動的IPっぽいFQDNからの接続からは怪しいと判断し、tarpitting(応答の遅延)を行います。tarpittingを待ちき れずに送信元が接続を切った後、再度送ってきた場合にはgreylisting(再送のチェック)により救済します。S25Rとtarpittingと greylistingと、全てのフィルタを抜けれなかったものだけがスパムとして排除されます。

さて、じゃあtaRgrey方式で、といきたいところだが、ここにかかれている方法はパッチを当てなければならない。
aptでパッケージ管理している関係上、できるだけdebian非公式パッチは当てたくない。
なので、パッチを使わないで実装する方向とする。

ということでどこでチェックしようかpostfixの設定を眺めることしばらく。
smtpd_recipient_restrictionsでやるのがいいかなあ、という結論。
PostfixでのGreylistingはpostgreyを使う。
ホワイトリストは許可して、S25R方式で怪しい奴らにgreylistingをかける。
それを通ったものにはtarpittingをかける。
という流れにする。

postgreyをインストール。

# aptitude install postgrey
/etc/default/postgrey
POSTGREY_OPTS="--inet=127.0.0.1:10023"

127.0.0.1をつけないとipv6でbindしてた。
いや別にいいんだけど。

main.cf
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_client_access regexp:$config_directory/white-list.txt,
check_client_access regexp:$config_directory/permit_client_nots25r,
check_policy_service inet:127.0.0.1:10023,
check_client_access regexp:$config_directory/tarpitting,
permit
white-list.txt

http://www.gabacho-net.jp/anti-spam/white-list.txtのものを使用
permit_client_nots25r
/.(internetdsl|adsl|sdi).tpnet.pl$/ WARN
/^user.+.mindspring.com$/ WARN
/^[0-9a-f]{8}.(.+.)?virtua.com.br$/ WARN
/.catv.broadband.hu$/ WARN
/[0-9a-f]{4}.[a-z]+.pppool.de$/ WARN
/.dip[0-9]+.t-ipconnect.de$/ WARN
/.dip.t-dialin.net$/ WARN
/.dyn.optonline.net$/ WARN
/.(adsl|cable).wanadoo.nl$/ WARN
/.ipt.aol.com$/ WARN
!/(^unknown$)|(^[^.]*[0-9][^0-9.]+[0-9].*.)|(^[^.]*[0-9]{5})|(^([^.]+.)?[0-9][^.]*.[^.]+..+.[a-z])|(^[^.]*[0-9].[^.]*[0-9]-[0-9])|(^[^.]*[0-9].[^.]*[0-9].[^.]+..+.)|(^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9])/ OK
/./ WARN
tarpitting
/./ sleep 65

main.cfでのsmtpd_recipient_restrictionsで基本的な認可のあとに
ホワイトリストによる認証(check_client_access regexp:$config_directory/white-list.txt)
S25RでOKなものの認可(check_client_access regexp:$config_directory/permit_client_nots25r)
微妙なやつらをpostgreyでgreylistチェック(check_policy_service inet:127.0.0.1:10023)
それも抜けたのはtarpitting(check_client_access regexp:$config_directory/tarpitting)
という感じ。

設定してからしばらくログ眺めてたけど良い感じでスパムをブロックしてくれている。
SPFの設定もしようかと思ったけど、あっちは転送時にfailしたりしちゃうことがあるみたいだから、とりあえず今回はやめておいた。
postfix-policyd-spfパッケージ入れてちょいちょいいじれば使えそうなんだけどね。

mdadmで構築したRAID5のチャンクサイズを変更してみた

やり方は簡単で

# mdadm -G -c512 --backup-file=/path/to/backup /dev/mdX

これでチャンクサイズが512kbになる。
ストライピング(RAID0)でも同じだろう。

ところで、5台構成(うち一台欠落中)のRAID5でやるとえらい遅いんだが。。。
renice -20 -p xxx
とかやって優先度かえても遅い。

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md3 : active raid5 sda3[0] sde1[4] sdd1[2] sdb3[1]
      5857284096 blocks super 1.2 level 5, 1024k chunk, algorithm 2 [5/4] [UUU_U]
      [>....................]  reshape =  0.2% (4300800/1464321024) finish=6868.2min speed=3542K/sec

3.5Mしかでてないっすよ。。。
5日ほどかかるようで。。。

reshape中にマシン停止するとどうなるのかは怖くて試せない。

しらべてみると、reshape中に再起動とかさせても平気らしいです。
こちらで実験してました。
いやー、mdadmよくできてる。

LinuxでのHDDのチューニング

そういえばすっかり忘れていたHDDのチューニング。
昔はhdparmでチューニングすることで、HDDの速度が結構伸びたものだ。
ついでにサーバ機なので静音化と省電力化も図りたい。
ということでしらべ直す。
hdparmで速度に関係しそうなオプションは以下のあたり。

 -a   Get/set fs readahead
 -A   Get/set the drive look-ahead flag (0/1)
 -c   Get/set IDE 32-bit IO setting
 -d   Get/set using_dma flag
 -m   Get/set multiple sector count
 -M   Get/set acoustic management (0-254, 128: quiet, 254: fast)
 -Q   Get/set DMA queue_depth (if supported)
 -W   Get/set drive write-caching flag (0/1)
 -X   Set IDE xfer mode (DANGEROUS)

続きを読む LinuxでのHDDのチューニング

windowsからext4へのアクセスについてその後

ext4が出始めの頃、アクセスの仕方をしらべたんだけど、その後進展があったようだ。

windowsからext2系ファイルシステムへのアクセスをするのにはext2fsdが一番だと思う。
が、ext4はなかなか色々と拡張がなされていて、特にextentsオプションが指定されたext4ファイルシステムは読み込みさえできなかった。
んだけど、いつの間にやらとりあえず読み込みに関してはサポートされたようだ。

    1, Ext4 extent readonly support by Bo Branten. Writing is
       possible but with no size-extending

ファイルサイズを拡大しない書き込みなら一応書き込みもできるらしい。
まあ、危ないから書き込みはやめておいた方が無難ですな。
ext2fsdの最新バージョンは0.51で0.50からext4のextentsオプション付きの読み込みに対応したようだ。
もちろんWindows7でも使える。
更新履歴を見るとがんばってext4対応を進めているようだ。

どうしてもLinuxのファイルシステムをWindowsから読み書きを今すぐ自由にしたいなら、とりあえずext3を使うかext4をextentsオプション抜きで利用するかかなあ。
extents付きのext4の読み込みサポートまでおよそ1年半か。
書き込みサポートも気長に待たないとだめっぽいですな。

mdadmでRAID ARRAYのホームホストや名前を変える

レスキューディスクでアレイを作ったらホームホストがそのときのレスキューのホスト名になっちゃってて、ようするにdebianになっちゃってたんで、なんとかしたいと思ったわけですはい。

アレイを組み立てるっていうかassembleするときに–update=で指定できるようで。
でもシステム領域含まれてるんでまたレスキュー使わないといけないんですね、はい。

ということでレスキューに潜り込んで、ホスト名を目的のものにちゃんと設定します。
じゃなかったらassembleの時にオプションで–homehost=で指定します。

# mdadm -A /dev/md1 /dev/sd[ab]1 --update=homehost

ホスト名ちゃんとしたの指定してなかったら

# mdadm -A /dev/md1 /dev/sd[ab]1 --homehost=hogehoge --update=homehost

みたいな感じ。
アレイがすでに起動してたら一回停止してからやりましょう。
アレイのメタデータのバージョンが1系ならmdadm -Dで出てきます。

Name : hogehoge:2  (local to host hogehoge)

のところ。
homehostと今のホストが正しければlocal to host hogehogeのところが出てきます。
mdadm -Dsでかぶってる名前のやついたら一回アレイをとめて

# mdadm -A /dev/md1 /dev/sd[ab]1 --update=name

とかしましょう。
解消されるはずです。

ちなみにmd1とかmd2とかのデバイス名を変えたい場合も同じ感じで、アレイが動いていれば停止して、アセンブルしてやって名前更新かけてやればいいです。

できあがったらシステムをルートにしてシェルを実行して、mdadm -Ds>>/etc/mdadm/mdadm.confたたいて今までのアレイ情報はコメントアウトしましょう。
念のためupdate-initramfs -uk allたたいておいた方が良いかもしれません。
特にデバイス名を変更した場合は必須だと思います。

4KBセクタのことを考えずにパーティション切っちゃってたことに気づいて何とか切り直そうとしてみる

最近4KBセクタのHDD増えましたよね。
ってか割と今更感もあると感じる人も多いかと思うけど、実際のところうちのサーバ機の構成HDDはちょっと前まで4KBセクタのHDDは混じってなかったんです。
でも、HDDの寿命やら故障やらで交換してたら、気づかぬうちに6 本中3本が4KBセクタものになっていました。
そして、そのことに気づいたのが昨日。

さて、パーティションは普通にfdiskで切ってましたよ、ええ。
パーティション開始位置みたら先頭パーティションおもいっきり63セクタですよええ。

ということで、パーティションを切り直す必用がある、というか、必用ではないけど切り直した方がいいのは間違いないわけで。

あ、何が問題なのかわからない人のために一応4KBセクタのお話をすっげー簡単にしておきます。
HDDは基本的に一セクタ512byteでした。
でも大容量化に伴い、一セクタ512byteだと非効率になってきたんで、一セクタ4KiBのHDDが出てきました。
なんだけど、BIOSとかドライバとかまあ根本的なところがHDDの一セクタは512byteっていう前提のものがまだまだ多いんで、内部的には4KiBだけど外面は今まで通り512byteな奴らが出てきました。
でもその関係でなんも考えずに従来通りのパーティション切りをしてると、書き込み性能が低下することがある問題が発生しました。
これ以上詳しい話はこちらのエントリをご覧ください。
そして今まさにその状態なわけです。

さて、そうすると、まず何をしなければならないか。
今のHDDの内訳を作ろう。

sda – ST2000DL003-9VT166
sdb – ST2000DL003-9VT166
4KBセクタ
/bootをミラーリングで構築
各種システムパーティションをLVMミラーで構築
各1.5TずつファイルサーバのRAID5へ組み込み

sdc – WDC WD10EADS-00M2B0
非4KBセクタ
バックアップ用

sdd –  WDC WD15EADS-00P8B0
sde – WDC WD15EADS-00S2B0
sdf – WD15EARS
sdfが4KBセクタ
ファイルサーバ用でRAID5くんでる
このうちsdfは不良により現在失踪中

んーと。
とりあえずRAID5が致命的にやばそうなんだが。。。
sdaの状態を確認してみる。
単位はシリンダじゃなくてセクタに変更してある。

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63      546209      273073+  fd  Linux raid autodetect
/dev/sda2          546210   976751999   488102895   8e  Linux LVM
/dev/sda3       976752000  3907024064  1465136032+  fd  Linux raid autodetect

はい、第一、第二パーティション開始セクタが8の倍数じゃないですね。
んーと。
sda1の開始位置を64にして終了位置を546199に
sda2の開始位置を546200にして終了位置はこのまま
とかやれれば良さそうだ、とりあえず。
ところで今までresize2fsとか結構やってきたけど、それで変わるのってパーティションの終了位置なんだよね。
開始位置の変え方を知らないことに気がついた。

で、resize2fsのmanページにこんなことが書いてある。

resize2fs プログラムは、パーティションのサイズは操作しない。 ファイルシステムを大きくしようとする場合は、 そのファイルシステムがあるパーティションのサイズを大きくできるかを 最初に確認しなければならない。 これは、 fdisk(8) を使ってパーティションを削除した後に より大きなパーティションを再作成することで確認できるし、 論理ボリュームマネージャ lvm(8) を使っている場合は、 lvextend(8) を使って確認できる。 パーティションを再作成する場合、 必ず以前と同じ開始ディスクシリンダで作成すること! そうしないと、サイズ変更の操作は絶対にうまく行かず、 ファイルシステム全体を失ってしまう。 fdisk(8) を実行した後、resize2fs を実行すること。 これにより、ext2 ファイルシステムのサイズを変更し、 拡大した新しいパーティションの全ての領域を使うことができる。

あ、はい。
要するに、一回ファイルシステム消せってことですね、わかります。
とりあえずRAID5の構成要素である第3パーティションはふれないでいいのは幸いだった。
ほんと1/8の偶然。

ということでまずシステムのバックアップとる。
sdb1, sdb2のパーティションを切り直す。

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048      546199      272076   fd  Linux raid autodetect
/dev/sdb2          546200   976751999   488102900   8e  Linux LVM
/dev/sdb3       976752000  3907024064  1465136032+  fd  Linux raid autodetect

再起動。
死んだ。
LVMボリュームがみつからねーっていわれた。
ブートしない。
さすがに無茶だったか。
LVMのミラーリングってじゃあ役に立つのか?
どうせミラーリングするんだからmdにしてしまいたいな。
まあ、この展開になったならもういいわ。
レスキューモードに入ってsda1とsda2のパーティションもぶった切る。
ということでぶった切り。
sda2もLVMじゃなくてLinux RAID autodetectに変更。
で、論理ボリュームとかぼこぼこ削除していったら、vgremoveがうまくいかず、vgreduce –removemissingをしてみろてきな。
あれ、もしかしてこれやれば良かった?
でももうおそい、あとには引けない。
削除。
そして綺麗に掃除したあと、アレイを作り直す。

# mdadm --create /dev/md1 -l1 -n2 --metadata=0.9 /dev/sd[ab]1
# mdadm --create /dev/md2 -l1 -n2 /dev/sd[ab]2

md1にファイルシステムを作ってバックアップを流し込む。
md2はLVMに。

# pvcreate /dev/md2
# vgcreate ms09 /dev/md2
# lvcreate -L 32G -n ms09 ms09

あとはmke2fsしてバックアップから流し込む。

これでとりあえずsdaとsdbはおっけー。

と思ったら起動しない。
grub loading
error 17
でました。
update-grubでいけるかと思ったけど駄目だったのでインストールし直す。
grubの画面までいくようになったけど今度はカーネル選択するとUnknown filesystemでマウントできないっていってerror 17。
レスキューから確認するとmd1がsdb1の方肺になっててgrubはsda1(hd(0,0))みにいってたっていうことでした。
まじね。
ということでmdadm /dev/md1 -a /dev/sda1して同期かけてgrubコマンドで確認して認識したので再起動。
漸くブートきたと思ったら、rootファイルシステムがみつからねーよっていうかmdadmでRAID ARRAY起動失敗っつーてこける。
きてる、きてるよくそはまりパターン。
んーと、なにをやりのがしてる?
んー、initramfsか?initramfsだろ。

update-initramfs -uk ‘all’

と。
はあ、やっと起動した。

とりあえず一旦ここで休憩。