hagio.org - 日記

Index

今月のアルバム U.S. Beers! [ 投稿 | 編集 ]

編集

October 2010

Oct 14 (Thu)

19:59

LVM の件、完結編。

まずは、昨日の状態から、バックアップ用の領域を PV の最後に作成して、移動する lv03_share をまるごと dump でバックアップした。寝てる間にやったが、これだけで 7 時間もかかった。さすがに、うちでは実績がほとんどない LVM で、謎のオプションを使って同一 PV 内での pvmove を行なうってのをバックアップなしにぶつけ本番でやる度胸はオレにはないのである。

--- Physical Segments --- Physical extent 0 to 81919: FREE Physical extent 81920 to 184319: Logical volume /dev/vg01/lv03_share Logical extents 0 to 102399 Physical extent 184320 to 376930: FREE Physical extent 376931 to 476930: Logical volume /dev/vg01/lv99_temp Logical extents 0 to 99999

バックアップが終わったところで、まずは lv03_share の半分程度を移動開始。一発でずらすだけのスペースは無いので、2 回に分ける必要がある。

# pvmove -v -i 60 --alloc anywhere /dev/sdc1:81920-140000 /dev/sdc1:0-58080 Finding volume group "vg01" Archiving volume group "vg01" metadata (seqno 46). Creating logical volume pvmove0 Moving 58081 extents of logical volume vg01/lv03_share ... /dev/sdc1: Moved: 98.1% /dev/sdc1: Moved: 99.1% /dev/sdc1: Moved: 100.0% ... # pvdisplay -m ... --- Physical Segments --- Physical extent 0 to 58080: Logical volume /dev/vg01/lv03_share Logical extents 0 to 58080 Physical extent 58081 to 140000: FREE Physical extent 140001 to 184319: Logical volume /dev/vg01/lv03_share Logical extents 58081 to 102399 Physical extent 184320 to 376930: FREE Physical extent 376931 to 476930: Logical volume /dev/vg01/lv99_temp Logical extents 0 to 99999

これは問題なく完了。あとは、残り半分を移動すれば良い。
その際、エクステント数を計算するのが面倒だったので、自動で計算してくれるだろうと思い、横着したところ・・・

# pvmove -v -i 60 --alloc anywhere /dev/sdc1:140001-184319 /dev/sdc1:58081- ★横着 ... # pvdisplay -m ... --- Physical Segments --- Physical extent 0 to 58080: Logical volume /dev/vg01/lv03_share Logical extents 0 to 58080 Physical extent 58081 to 184319: FREE Physical extent 184320 to 228638: Logical volume /dev/vg01/lv03_share Logical extents 58081 to 102399 Physical extent 228639 to 376930: FREE Physical extent 376931 to 476930: Logical volume /dev/vg01/lv99_temp Logical extents 0 to 99999

うぇっぷ、なぜか後ろにずれてしまった…。横着したために、58081 以降の PE ならどこでも良いと判断されてしまったのだろうか。処理内容をよく知らないくせに横着するもんじゃないですね…。
今度はちゃんと開始 PE と終端 PE を指定して、場所が一意に決まるように実行した。

# pvmove -v -i 60 --alloc anywhere /dev/sdc1:184320-228638 /dev/sdc1:58081-102400 ... # pvdisplay -m ... --- Physical Segments --- Physical extent 0 to 102399: Logical volume /dev/vg01/lv03_share Logical extents 0 to 102399 Physical extent 102400 to 376930: FREE Physical extent 376931 to 476930: Logical volume /dev/vg01/lv99_temp Logical extents 0 to 99999

スッキリ!!

01:38

運動しはじめてわかったのだが、体の疲れと頭の疲れはまったく別物みたいだ。運動をはじめる前に考えていたのは、仕事から帰ると急激に眠くなってしまうことが多いので、運動して体力をつけると眠くなることも多少は少なくなるかなと期待をしていたのだが、そんなことはまったくなさそうである。まだそんなに体力がついたわけでもないが、多少体力をつけても、仕事の後に眠いのは変わらないし、逆にいくら運動しても頭だけはシャキッとしていることもある (シャキッとしていることがあるの、というツッコミはなしで)。

つまり、フィジカルなスタミナとは別に、メンタルなスタミナをつけなければならないってことのようですね。

しばらくはフィジカルを主に頑張るつもりだが、メンタルなスタミナってどうやってつければ良いのだろうかね。

00:29

ぐむむ、、絶望的に間に合わん。

Oct 13 (Wed)

00:34

ソースを見たところでは、以下の部分が非常にクサい。

/* Don't allocate onto the PV we're clearing! */ if ((alloc != ALLOC_ANYWHERE) && (pvl->pv->dev == pv_dev(pv))) { dm_list_del(&pvl->list); continue; }

ということで、man には全然説明がないけど、こうかっ!!

# pvmove --alloc anywhere /dev/sdc1:184320-184320 /dev/sdc1:0-0 /dev/sdc1: Moved: 100.0% # pvdisplay -m /dev/sdc1 ... --- Physical Segments --- Physical extent 0 to 0: Logical volume /dev/vg01/lv99_test Logical extents 0 to 0 Physical extent 1 to 81919: FREE Physical extent 81920 to 184319: Logical volume /dev/vg01/lv03_share Logical extents 0 to 102399 Physical extent 184320 to 476930: FREE

当たった!! 同じ PV 内での移動も pvmove で可能だった。

これを使って lv03_share をずらせば、気持ち悪い空きスペースをなくせそうだ。

Oct 12 (Tue)

23:49

土曜日の VLM の件。

# pvdisplay -m /dev/sdc1 ... --- Physical Segments --- Physical extent 0 to 81919: FREE Physical extent 81920 to 184319: Logical volume /dev/vg01/lv03_share Logical extents 0 to 102399 Physical extent 184320 to 184320: Logical volume /dev/vg01/lv99_test Logical extents 0 to 0 Physical extent 184321 to 476930: FREE

こういう状況で、

# pvmove /dev/sdc1:184320-184320 /dev/sdc1:1-1 No extents available for allocation

こういうことがやれるかと思ったのだが、ダメだった。ソース見てみるか。

LVM 関連のコマンドは、-v を付けまくるとかなり細かく挙動を確認できるのでフレンドリー。

# pvmove -vvvv /dev/sdc1:184320-184320 /dev/sdc1:0-0 ... #metadata/pv_manip.c:284 /dev/sdc1 0: 0 81920: NULL(0:0) #metadata/pv_manip.c:284 /dev/sdc1 1: 81920 102400: lv03_share(0:0) #metadata/pv_manip.c:284 /dev/sdc1 2: 184320 1: lv99_test(0:0) #metadata/pv_manip.c:284 /dev/sdc1 3: 184321 292610: NULL(0:0) #metadata/pv_manip.c:284 /dev/sdb1 0: 0 40960: lv01_dump(0:0) #metadata/pv_manip.c:284 /dev/sdb1 1: 40960 78274: lv02_vmware(0:0) #toollib.c:938 Adding PE range: start PE 184320 length 1 on /dev/sdc1 #toollib.c:938 Adding PE range: start PE 0 length 1 on /dev/sdc1 #pvmove.c:102 No extents available for allocation #pvmove.c:369 <backtrace> #locking/file_locking.c:59 Unlocking /var/lock/lvm/V_vg01 #device/dev-io.c:491 Closed /dev/sdc1 #device/dev-io.c:491 Closed /dev/sdb1 #pvmove.c:565 <backtrace>

19:52

[メモ] 実物見たいチャリ

調べれば調べるほど、予算がだんだんつり上がってゆく。。

19:02

愚痴なので co。
要は、幼稚園に子供を迎えに行くのに戦車を使ってはいけないヨ、ということです。

あーー、こういう日こそ泳ぎに行きたいのに。

のに

な

Oct 11 (Mon)

20:39

勉強が全然はかどらない。まず間に合わない感触なので、今週はプールに行くのを自粛するか…。
自転車がなかなか買えなくてもどかしい。欲しいと思ったら在庫切れとか、来年の 3 月入荷予定とか…。そんなに待てるかい。
FELT はあきらめて、Pinarello か Cannondale にするかも。乗ってる人めっちゃいるけど。
電車で同じ車両にいた 8 割の人が携帯を見ててなんか気持ち悪かった。ボクらは携帯に何を求めているのか。本当に求めているものはそこにはないことをわかっているのに。
リンガーハットで餃子についてくる柚子胡椒をチャンポンにも入れちゃう派。

Oct 10 (Sun)

09:50

速い!!

09:33

かなり楽しそう!!

Oct 9 (Sat)

23:56

LVM 上の ext3 のオンラインリサイズを試してみた。かなり恐かったが (VM 10 個分の構築工数がかかっているので…) 成功したみたい…。

# lvextend -l +37314 /dev/vg01/lv02_vmware Extending logical volume lv02_vmware to 305.76 GB Logical volume lv02_vmware successfully resized # resize2fs -p /dev/vg01/lv02_vmware resize2fs 1.39 (29-May-2006) Filesystem at /dev/vg01/lv02_vmware is mounted on /vmware; on-line resizing required Performing an on-line resize of /dev/vg01/lv02_vmware to 80152576 (4k) blocks. The filesystem on /dev/vg01/lv02_vmware is now 80152576 blocks long.

それにしても、1 つのパーティションが複数のディスクにまたがるのが嫌なオレは、 LVM なんか使うべきではないのかもしれないなぁ。

あと、下のように、pvmove とかやってるうちにディスク上で前後に空きがある状態になってしまって非常に気持ち悪いんだけど、なんとかならんものか。同一ディスク内での pvmove ができたらいいのに…。

# pvdisplay -m ... --- Physical Segments --- Physical extent 0 to 81919: FREE Physical extent 81920 to 184319: Logical volume /dev/vg01/lv03_share Logical extents 0 to 102399 Physical extent 184320 to 476930: FREE

追記：
むむ、これはまさか…。

# pvmove --help pvmove: Move extents from one physical volume to another ... [{-n|--name} LogicalVolume] SourcePhysicalVolume[:PhysicalExtent[-PhysicalExtent]...]} [DestinationPhysicalVolume[:PhysicalExtent[-PhysicalExtent]...]...] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

19:42

[メモ] 7:19 発 8:19 着 → 東口 7 番森32 8:35

つか、明日雨っぽいがトライアスロンやるんすかね。
友人によると、波が高いとスイムが中止になって、ラン → バイク → ランになるらしい。

15:34

サーバの温度グラフからオレの生活リズムがわかってしまう件…。窓の開閉と連動しすぎだろー。

15:28

100BASE-T ですが、スイッチングハブ LSW2-TX-5EP/C が余っているので、欲しい方には差し上げます。
ただし、知り合いに限る。箱、説明書、保証書、プチプチ袋まで全部揃ってます。あ、保証は切れてるわ。

Oct 8 (Fri)

23:10

今日は、アップ 100、800、100 x 4、一個メ、後退プル、ダウン 100 で 1.5 km くらい。前より頻度は減ったけど、疲れてくると足がつりやすくなる。疲労と関係あるんかね。

Oct 7 (Thu)

21:23

だんだんわかってきた。

RHEL4 は、基本的に jiffies が中心にあって、xtime は tick 毎にほぼ一定値が増加されるし、 nanosleep システムコールは jiffies 駆動のタイマを利用している。

RHEL5 も、jiffies はあるんだけど依存度が低下していて、xtime は clocksource のカウンタの差分によって増加されるし、 nanosleep システムコールには hrtimer という xtime 駆動のタイマを利用している。このため、clocksource が TSC や HPET などの外部カウンタだと、jiffies を加速させても xtime が加速しない。 xtime が加速しないので、hrtimer を使っている部分が加速せず、カーネル全体は加速しないしないことになる。 clocksource を jiffies にすると、RHEL4 とほぼ同じような動作・精度となる (はず)。

ちなみに、hrtimer は下のような箇所で用いられているとのこと。(kernel/hrtimer.c より)

* High-resolution kernel timers * * In contrast to the low-resolution timeout API implemented in * kernel/timer.c, hrtimers provide finer resolution and accuracy * depending on system configuration and capabilities. * * These timers are currently used for: * - itimers * - POSIX timers * - nanosleep * - precise in-kernel timing

ガッテン! ガッテン!

18:32

下の加速方法を使っていて疑問が生じたのだが、sleep コマンドなども clocksource を jiffies にしないと加速しない。ということは、nanosleep システムコールが使用しているタイマは jiffies を使用しているわけではないということになる。ザッと見たところ hrtimer というものみたいだが、これどうやって駆動しているのだろう。

あー、ネットワークの勉強しなきゃならんのに、気になることがどんどん出てきて全然進まない。。

Oct 5 (Tue)

18:25

さっき、仕事中に、Linux サポートエンジニアにとってはかなりおいしいはずの画期的なレシピを思いついたので、リアルタイムクッキングしてみる。

今日のメニューは、動的可変加速カーネル by SystemTap です。カーネルの時間の進み方を、再起動なしにコマンド 1 発で変更することができる優れもの。

用意するもの：

RHEL4.7 以上の環境 (i386, x86_64 確認済み)
RHEL5.1 以上の環境 (i386, x86_64 確認済み)
- RHEL5 の場合、clocksource として jiffies を使用できる必要があります。
  
  # cat /sys/devices/system/clocksource/clocksource0/available_clocksource acpi_pm jiffies★ tsc pit
以下のパッケージ (要は、SystemTap を使える環境)
- kernel-debuginfo および kernel-debuginfo-common
- kernel-devel
- systemtap および systemtap-runtime
- 開発環境 (gcc 関連) は当然必須

用意ができたら、調理開始!!

以下の SystemTap スクリプト (accel.stp) を用意し、実行権限を付与します。

#!/usr/bin/stap -g probe kernel.function("do_timer_interrupt_hook") { ★RHEL4, RHEL5 i386 の場合 probe kernel.function("main_timer_handler") { ★RHEL5 x86_64 の場合 probe kernel.function("timer_interrupt") { ★RHEL4 x86_64 の場合 printf("tick_divider = %d\n", $tick_divider) if ($1 > 0) { $tick_divider = $1 printf("changed to: tick_divider = %d\n", $tick_divider) } exit() }
# chmod +x accel.stp
clocksource を jiffies に変更します。(RHEL5 のみ)
# echo jiffies > /sys/devices/system/clocksource/clocksource0/current_clocksource
10 倍速にしたい場合、以下のようにスクリプトを実行します。
# ./accel.stp 10
1 秒が超速くなっていることを確認します。
# while true; do date; sleep 1; done

こんなに簡単!! あっというまに加速カーネルのできあがりです。

ちなみに、以下のコマンドでいつでも元のスピードに戻せます。
# ./accel.stp 1

このレシピの肝は、お分かりの通り tick_divider (起動パラメータ名は divider) を利用するところにある。 tick_divider とは、仮想化環境など割り込みを 1000 Hz で発生させることが困難な場合に、割り込みを毎秒 HZ/divider 回に減らし、1 回のタイマ割り込みで divider 回のタイマ割り込み処理を行なうことで、見かけ上 HZ=1000 (jiffies が 1 秒で 1000 増加する) を再現するためのパラメータである。今回の場合、divider の設定はしていないので、HZ=1000 のままにも関わらず強引に divider を書き換えることにより、 1 回のタイマ割り込みでタイマ割り込み処理を上記であれば 10 回行ない、10 倍の時間を進めさせるというものだ。

tick_divider は、割り込みを減らして時間を速く進めるためのカーネル自体に組み込まれた機能のため、おそらく問題なく加速できるものと考えられる。

17 static inline void do_timer_interrupt_hook(struct pt_regs *regs) 18 { 19 int i; 20 for (i = 0; i < tick_divider; i++) { 21 do_timer(regs); 22 #ifndef CONFIG_SMP 23 update_process_times(user_mode_vm(regs), regs); 24 #endif 25 }

Oct 4 (Mon)

22:42

キタ

[root@lab ~]# ethtool eth0 Settings for eth0: ... Advertised auto-negotiation: Yes Speed: 1000Mb/s ★ Duplex: Full ...

結局なんだったかというと、サーバとハブの間のケーブルが 2 対 4 線の UTP ケーブルだったのが問題だった。 ethtool などで色々試してもどうにもならないので諦めかけていたのだが、 100BASE-TX は 2 対 4 線、1000BASE-T は 4 対 8 線ということをチラッと思い出して、そんなことはないよなーと思ってプラグの透明部分をよく見てみると、4 線しかきてないという…。どんなヘボケーブル使ってたんだー。

トラブルの際は、とりあえず超基本的な部分から調べるべきということですな。知識があっても、使い方がなってないとむしろ足枷になってしまう。あー、恥ずかし。

18:38

今や、1000BASE-T 対応のスイッチングハブが 3,000 円を下回っている時代である。うちも MacBook と Express5800 は 1000BASE-T に対応しているので、遅ればせながらギガビットにしてみた。しかし… 接続してみたところ、Express5800 が 1000Mbps にならねえ!!

[root@lab ~]# ethtool eth0 Settings for eth0: 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 auto-negotiation: Yes Speed: 100Mb/s ★ Duplex: Full Port: Twisted Pair ...

これからまた仕事 (と同じようなことをやること) になりそうです。

Oct 3 (Sun)

21:50

なんだか水泳日記になってるけれども。まぁ自分のための記録なのでいいか。今日は 45 分で 1.5km くらい。 800m を必ずメニューに組み込むことにした。最低限 750m には慣れなきゃいけないのでね。しかしそうすると体力的に 1.5km くらいで限界がきて、これ以上泳いでもダラダラするだけだなと思ったので、早々に切り上げた。どうなんだろう、もしかすると、そこからどれだけ頑張るかで体力が付くかどうかが決まってくるかもしれなくて、運動に関して詳しくないので、非効率的なことをやっているのかもしれない。そういうところはやっぱりちゃんとしたスクールに通わないとわからないとこだね。

今日は 20 時から泳ぎ始めたので人が少なく、これはチャンスと思い本気で 50m 泳いでみたところ、32 秒程度。ちぇ…、さすがにたった 1 ヶ月やそこらの練習じゃあ、現役のときのベストには全然かなわないか…。泳いでる感触ではだいぶスムーズに進んでるんだけどなぁ。まぁ、これまで短距離の練習をまったくしていないから、いきなり猛ダッシュしていいタイムが出るわけないし、ストロークも大きめのゆったりしたものになってるので、泳ぎ方が短距離向きではないのである。

そういや、遠泳だけの大会に出てみるのも面白いかもなー。

Oct 1 (Fri)

22:19

今日は 45 分で 1.7km。なかなかいいペースになってきたが、やはり長距離はしんどくて泳げない。 500m x 2 を泳いで、あとは適当だったが、500m の時間を計ったところ、だいたい 10 分くらいかかっていた。これはまあ、途中で前の人にひっかかって止められたりしていたので、ぼちぼちと言ったところかな。次の目標は、1.5km 泳ぎ続けることと、50 分で 2km のペース。

あー、というか、今日は、会議室を確保するの忘れてて会議を中止にしちゃうし (やってしまった)、頭はいつも以上に回らないし、仕事は理不尽だしでしんどかったので (我慢ならないので愚痴を言うと、あんなのとばっちりもいいとこだ!!)、どうしても泳ぎたくなって閉館の 1 時間前にバタバタ行ったのだが (まあ、友達としゃべってたので遅くなったのだけど)、ホント泳ぎに行って良かった。体力的には泳ぐ前より疲れているはずが、なぜか一気にリフレッシュしてしまったのである。ストレス解消を明らかに感じられるのだから、水泳はやめられない…。

それから、会社の同期でトライアスロンをやっている人を見つけたので、いろいろ教えてもらえそうである。その人は入社後からマラソンを始めて、今年の 4 月くらいからトライアスロンを始めたらしい。来年は、一緒に出場できたらいいな。

ということで、まずは早く自転車を買わなきゃね。

9 月(2) へ

↑戻る