へぇぇぇぇ。
[sandbox@proliant2 work]$ touch -- '-rf' '~'
[sandbox@proliant2 work]$ strace rm *
execve("/bin/rm", ["rm", "-rf", "~"], [/* 23 vars */]) = 0
brk(0) = 0x87c000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f840a966000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=94094, ...}) = 0
mmap(NULL, 94094, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f840a94f000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\357\1n?\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1995840, ...}) = 0
mmap(0x3f6e000000, 3814616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3f6e000000
mprotect(0x3f6e19a000, 2093056, PROT_NONE) = 0
mmap(0x3f6e399000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x199000) = 0x3f6e399000
mmap(0x3f6e39e000, 21720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3f6e39e000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f840a94e000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f840a94c000
arch_prctl(ARCH_SET_FS, 0x7f840a94c720) = 0
mprotect(0x3f6e399000, 16384, PROT_READ) = 0
mprotect(0x3f6de20000, 4096, PROT_READ) = 0
munmap(0x7f840a94f000, 94094) = 0
brk(0) = 0x87c000
brk(0x89d000) = 0x89d000
brk(0) = 0x89d000
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=99154656, ...}) = 0
mmap(NULL, 99154656, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8404abc000
close(3) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 opost isig icanon echo ...}) = 0
lstat("/", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
newfstatat(AT_FDCWD, "~", {st_mode=S_IFREG|0664, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0
unlinkat(AT_FDCWD, "~", 0) = 0
close(0) = 0
close(1) = 0
close(2) = 0
exit_group(0) = ?
[sandbox@proliant2 work]$
シェルによりワイルドカード指定で見つかったファイルの ~ カレントディレクトリパスに置き換えられないため問題ないのね。
しかし意図的にファイルを置いておくことで -i を迂回できるね。怖い……！
※Fedora 14 の環境でためしました。
2012年1月13日金曜日
2012年1月10日火曜日
Tabキーでウインドウ上のボタンにフォーカスをあてるには
「えっ、いまさら？」と言われそうなネタで自分への備忘録がてら一本。。。。
MacOS XのUIでボタンなどをフォーカスしたいときに Tab キーで反応してくれないのに割と困っていたんですが、設定ひとつで挙動が変えられるんですね。感動しました。。。。
たとえば次のウインドウの場合、このダイアログにはチェックボックスとボタン２つ、合計３つのコントロールがあります。 Windows であれば標準設定でもこの３コントロール間を Tab で行き来できるのですが、 Mac OS X ではデフォルトでは Tab によるコントロール移動が効きません。なおこの画像は実際に Cancel にフォーカスをあてている状態です。
これは、設定＞キーボードで変更できます。
教えてくださった @akisutesama さん、ありがとうございます _o_
MacOS XのUIでボタンなどをフォーカスしたいときに Tab キーで反応してくれないのに割と困っていたんですが、設定ひとつで挙動が変えられるんですね。感動しました。。。。
たとえば次のウインドウの場合、このダイアログにはチェックボックスとボタン２つ、合計３つのコントロールがあります。 Windows であれば標準設定でもこの３コントロール間を Tab で行き来できるのですが、 Mac OS X ではデフォルトでは Tab によるコントロール移動が効きません。なおこの画像は実際に Cancel にフォーカスをあてている状態です。
これは、設定＞キーボードで変更できます。
教えてくださった @akisutesama さん、ありがとうございます _o_
2012年1月5日木曜日
FreeBSDで使うLinux KVM準仮想化タイマ
こんにちわ。@hasegawです。あけましておめでとうございます。今年もよろしくお願いします！
かなり久々のブログ更新となりますが、本日は カーネル／VM Advent Calendar にてまたまた私の当番！ってことで、今回は FreeBSD 8.1-RELEASE に Linux KVM 用のタイムカウンタを実装してみたというネタでお話しようかと思います。
昨年のネタ: FreeBSD VIMAGEを使ったTCP/IPのルーティング デモンストレーション
■ Linux KVM のタイマ機能
まずバックグラウンドについて説明しておきましょう。 FreeBSD のはじめとする殆どの OS では、以下の計算式でシステム時間（年月日・時分秒）を把握しています。
システム時間 = システム起動時の時間 + システム起動後の経過時間
このうち「システム起動時の時間」はRTC（リアルタイムクロック）の値で初期化し、「システム起動後の経過時間」はOSが定期的にカウンタをインクリメントしています。しかし、仮想化環境ではこの仕組みをそのまま適用すると時刻ズレの原因となりやすいことは、この記事を読むような方であればご存じのことでしょう。
そこで、タイマの仮想化です。 Linux KVM でもタイマの準仮想化機能があります。
KVM PVclock
http://www.linux-kvm.org/page/KVMClock
これは、ゲスト OS が「おいら時間情報がほしいから、メモリのここに定期的に書いておいてちょ」と仮想マシンモニタにお願いすると、適当な間隔で仮想マシンモニタが指定されたメモリ上に時刻情報を書いておいてくれる、という仕組みです。
ただ、 KVM のサイトを見るとこの機能は Linux guests only. と書いてあります。
どうして
Linux でしか使えないの？
それは、ゲスト OS が KVM PV Clock に対応する必要があるからです。
しかし KVM の PV Clock は決して難しいものではありません。もともと Xen にインスパイアされて殆ど同じ汎用的なデータ構造を持っているので、すでに BSDL で Xen 対応のコードがある FreeBSD であれば私のヘナチョコがちょろちょろっとコピペして済むレベルです。対応するかしないかは仮想マシンモニタ開発側＆ゲスト OS 開発側のモチベーション次第なだけなのです！よっしゃ、私は最近 FreeBSD 使っていないけど、やってみるかー。
ってことでとりあえず動くモノを作ってみましたとさ。
■ FreeBSD 用 timecounter: kvmclock 失敗編
時は 2011 年 10 月。今回のモノは FreeBSD の timecounter として実装しました。 Linux で言う clocksource ですね。システム起動時には以下のイメージで初期化されます。
Timecounter "kvmclock" frequency 1800000536 Hz quality 900
このタイムカウンタは、 Linux KVM が定期的に TSC のカウンタをメモリに書いてくれるので、それを使って時を刻んでいます。
struct pvclock_vcpu_time_info {
u32 version;
u32 pad0;
u64 tsc_timestamp;
u64 system_time;
u32 tsc_to_system_mul;
s8 tsc_shift;
u8 pad[3];
} __attribute__((__packed__)); /* 32 bytes */
とりあえず動いたのですが、しかし実際には問題が起きて使い物になりませんでした。理由は桁あふれです。1.8GHzでカウントアップされていくタイマだと、あっという間に32ビットのカウンタは一週してゼロに戻ります。この結果、アイドル時間が多いと時計が遅れるという最高にイケていないタイムカウンタになりました。なお while true; do date > /dev/null ; done とかしていると非常に精度が高いカウンタであったことは申し添えておきます！
■ FreeBSD用timecounter: kvmclock その２
時は２０１１年１２月２９日。年末年始はスノーボードに行くので今作らなかったら Advent Calendar のネタがありません。ってことで、とりあえずバージョンアップしました。
Timecounter "kvmclock" frequency 1000000 Hz quality 900
このタイマはゲストOSに対して仮想的にマイクロ秒精度のタイマ機能を提供します。
前回は Linux KVM がシャドウしてくれた TSC の値を使って時を刻んでいましたが、今回は Linux KVM がシャドウしてくれたシステム時間をベースに時を刻みます。
struct pvclock_wall_clock {
u32 version;
u32 sec;
u32 nsec;
} __attribute__((__packed__));
このデータ自体はナノ秒オーダーのものですが、 t = sec * 1000 + nsec / 1000 としてマイクロ秒のオーダーに変換し、これの情報を OS 側に食わせます。この形であればカーネルが気づかないうちに桁あふれなんてことがそうそう起きません。
■ 評価
早速作ったタイムカウンタで仮想マシンを動かしてみました。素人ハックの結果としては割と良好かと思います。
これは while true; do date; sleep 1; done の結果をゲスト（上）とホスト（下）で実行しっぱなしにした結果です。
5時8分0秒が飛んでいるので不安定っぽく見えますが、 sleep 1 の待ち時間がフラついているという問題はあるもののホスト OS から 1 秒以上時間がずれることは無くなりました。 sleep の精度が低い問題はありつつも gettimeofday は安定しているようです。
また、vCPUがアイドルの場合も、負荷をかけた場合でも、システムの時刻がホストとゲストの間で大きくズレることはないようです。
12 月 29 日から 1 月 4 日までの 5 日間放置しても、システム時間のずれは生じなかった
■ もっと頑張らないといけないこと
とりあえず自覚している課題は以下の部分です。
現時点のやるきのないコードの一部（試行錯誤の跡付き）
■ おわりに
というわけで、「タイマ作りました、動いてます」というとっても退屈な記事ですが、、こんな事してみましたよ、ってことで。私のようなヘボでもいじくれる所があるというのは有り難いものです。
Advent Calendar 参加者の皆さんの記事、楽しく読ませていただきました。今後ともよろしくお願いします。
かなり久々のブログ更新となりますが、本日は カーネル／VM Advent Calendar にてまたまた私の当番！ってことで、今回は FreeBSD 8.1-RELEASE に Linux KVM 用のタイムカウンタを実装してみたというネタでお話しようかと思います。
昨年のネタ: FreeBSD VIMAGEを使ったTCP/IPのルーティング デモンストレーション
■ Linux KVM のタイマ機能
まずバックグラウンドについて説明しておきましょう。 FreeBSD のはじめとする殆どの OS では、以下の計算式でシステム時間（年月日・時分秒）を把握しています。
システム時間 = システム起動時の時間 + システム起動後の経過時間
このうち「システム起動時の時間」はRTC（リアルタイムクロック）の値で初期化し、「システム起動後の経過時間」はOSが定期的にカウンタをインクリメントしています。しかし、仮想化環境ではこの仕組みをそのまま適用すると時刻ズレの原因となりやすいことは、この記事を読むような方であればご存じのことでしょう。
そこで、タイマの仮想化です。 Linux KVM でもタイマの準仮想化機能があります。
KVM PVclock
http://www.linux-kvm.org/page/KVMClock
これは、ゲスト OS が「おいら時間情報がほしいから、メモリのここに定期的に書いておいてちょ」と仮想マシンモニタにお願いすると、適当な間隔で仮想マシンモニタが指定されたメモリ上に時刻情報を書いておいてくれる、という仕組みです。
ただ、 KVM のサイトを見るとこの機能は Linux guests only. と書いてあります。
どうして
Linux でしか使えないの？
それは、ゲスト OS が KVM PV Clock に対応する必要があるからです。
しかし KVM の PV Clock は決して難しいものではありません。もともと Xen にインスパイアされて殆ど同じ汎用的なデータ構造を持っているので、すでに BSDL で Xen 対応のコードがある FreeBSD であれば私のヘナチョコがちょろちょろっとコピペして済むレベルです。対応するかしないかは仮想マシンモニタ開発側＆ゲスト OS 開発側のモチベーション次第なだけなのです！よっしゃ、私は最近 FreeBSD 使っていないけど、やってみるかー。
ってことでとりあえず動くモノを作ってみましたとさ。
■ FreeBSD 用 timecounter: kvmclock 失敗編
時は 2011 年 10 月。今回のモノは FreeBSD の timecounter として実装しました。 Linux で言う clocksource ですね。システム起動時には以下のイメージで初期化されます。
Timecounter "kvmclock" frequency 1800000536 Hz quality 900
このタイムカウンタは、 Linux KVM が定期的に TSC のカウンタをメモリに書いてくれるので、それを使って時を刻んでいます。
struct pvclock_vcpu_time_info {
u32 version;
u32 pad0;
u64 tsc_timestamp;
u64 system_time;
u32 tsc_to_system_mul;
s8 tsc_shift;
u8 pad[3];
} __attribute__((__packed__)); /* 32 bytes */
とりあえず動いたのですが、しかし実際には問題が起きて使い物になりませんでした。理由は桁あふれです。1.8GHzでカウントアップされていくタイマだと、あっという間に32ビットのカウンタは一週してゼロに戻ります。この結果、アイドル時間が多いと時計が遅れるという最高にイケていないタイムカウンタになりました。なお while true; do date > /dev/null ; done とかしていると非常に精度が高いカウンタであったことは申し添えておきます！
■ FreeBSD用timecounter: kvmclock その２
時は２０１１年１２月２９日。年末年始はスノーボードに行くので今作らなかったら Advent Calendar のネタがありません。ってことで、とりあえずバージョンアップしました。
Timecounter "kvmclock" frequency 1000000 Hz quality 900
このタイマはゲストOSに対して仮想的にマイクロ秒精度のタイマ機能を提供します。
前回は Linux KVM がシャドウしてくれた TSC の値を使って時を刻んでいましたが、今回は Linux KVM がシャドウしてくれたシステム時間をベースに時を刻みます。
struct pvclock_wall_clock {
u32 version;
u32 sec;
u32 nsec;
} __attribute__((__packed__));
このデータ自体はナノ秒オーダーのものですが、 t = sec * 1000 + nsec / 1000 としてマイクロ秒のオーダーに変換し、これの情報を OS 側に食わせます。この形であればカーネルが気づかないうちに桁あふれなんてことがそうそう起きません。
■ 評価
早速作ったタイムカウンタで仮想マシンを動かしてみました。素人ハックの結果としては割と良好かと思います。
これは while true; do date; sleep 1; done の結果をゲスト（上）とホスト（下）で実行しっぱなしにした結果です。
5時8分0秒が飛んでいるので不安定っぽく見えますが、 sleep 1 の待ち時間がフラついているという問題はあるもののホスト OS から 1 秒以上時間がずれることは無くなりました。 sleep の精度が低い問題はありつつも gettimeofday は安定しているようです。
また、vCPUがアイドルの場合も、負荷をかけた場合でも、システムの時刻がホストとゲストの間で大きくズレることはないようです。
12 月 29 日から 1 月 4 日までの 5 日間放置しても、システム時間のずれは生じなかった
■ もっと頑張らないといけないこと
とりあえず自覚している課題は以下の部分です。
- 実はまだ KVM のプローブをしていない。 MSR を一発たたけばいいので、いつでもできます。
- vCPU != 1 の場合を想定していないし、評価していない。vCPU ごとにカウンタを進める必要がありますので、今のコードのままではまずい。このままでも動くかもしれないけど。
- sleep 1 が不安定 ﾟ+.(･ω･)ﾟ+.ﾟ ヘボグラマなので細かい修正はエキスパートにお願いすればいいかなっと。
現時点のやるきのないコードの一部（試行錯誤の跡付き）
■ おわりに
というわけで、「タイマ作りました、動いてます」というとっても退屈な記事ですが、、こんな事してみましたよ、ってことで。私のようなヘボでもいじくれる所があるというのは有り難いものです。
Advent Calendar 参加者の皆さんの記事、楽しく読ませていただきました。今後ともよろしくお願いします。
2011年6月4日土曜日
退職のお知らせ
既にご存知の方も多いかと思いますが、株式会社SRAを退職いたしました。
SRAには2004年に新卒として入社、以後7年間に渡りIAサーバを中心に、システム構築および運用サービスに従事しておりました。サーバの構築には学生時代から興味をもって取り組んでいたものの、ビジネスとして取り組むITは非常に新鮮で、同社社員、およびお客様方から大変多くのことについて学ぶことができました。自分にとって忘れられない7年間になりました。ありがとうございました。
在籍期間中、職場の同僚やマネージャ陣には大変お世話になりました。直接の業務ではないXen徹底入門の執筆、また、昨年に公開した仮想マシンのしくみの解説スライドなどのプロジェクトに必要な時間をやりくりして来られたのは、職場や上司の理解があり、時には、少なからずのバックアップいただけたという事情もあり、同社の社員としてこれまで業務に取り組めた事をありがたく、大変誇りに思っております。
6/1からの三日間はLinuxCon JAPAN 2011にアテンドさせていただきました。日本中、世界中のエンジニアとまた新たなつながりができました。会期中に受けた刺激で充電し、これから自分がどのようにITインフラストラクチャに関わっていけるかを考えていきたいと思っております。
SRA在職中は、多くの方々に大変お世話になりました。今後も引き続きご指導のほど、よろしくお願いいたします。
Takeshi HASEGAWA aka hasegaw
SRAには2004年に新卒として入社、以後7年間に渡りIAサーバを中心に、システム構築および運用サービスに従事しておりました。サーバの構築には学生時代から興味をもって取り組んでいたものの、ビジネスとして取り組むITは非常に新鮮で、同社社員、およびお客様方から大変多くのことについて学ぶことができました。自分にとって忘れられない7年間になりました。ありがとうございました。
在籍期間中、職場の同僚やマネージャ陣には大変お世話になりました。直接の業務ではないXen徹底入門の執筆、また、昨年に公開した仮想マシンのしくみの解説スライドなどのプロジェクトに必要な時間をやりくりして来られたのは、職場や上司の理解があり、時には、少なからずのバックアップいただけたという事情もあり、同社の社員としてこれまで業務に取り組めた事をありがたく、大変誇りに思っております。
6/1からの三日間はLinuxCon JAPAN 2011にアテンドさせていただきました。日本中、世界中のエンジニアとまた新たなつながりができました。会期中に受けた刺激で充電し、これから自分がどのようにITインフラストラクチャに関わっていけるかを考えていきたいと思っております。
SRA在職中は、多くの方々に大変お世話になりました。今後も引き続きご指導のほど、よろしくお願いいたします。
Takeshi HASEGAWA aka hasegaw
2011年5月30日月曜日
#ssmjp に参加してきました。
5月26日(水)に開催されたささみの会(#ssmjp、新橋勉強会とか別の名前が色々あるようですが)にてプロジェクトマネジメント的観点からプレゼンテーションをさせていただきました。ちょっと私のスケジュールがテンパっていた都合、事実上私の都合に合わせて開催していただいたような感じで……。 @togakushi さんには大変ご迷惑おかけしました。
さて、プロジェクトマネジメントというと、普通は限られた予算・時間・リソース内でいかに仕事を片付けるかという話が一般的にされるわけですが、今回はそれとはちょっと違います。本業における私の立場では、プロジェクトマネジメントというよりはプロジェクトをリードする立場で、いかにプロジェクトが円滑に回るように、最短で片付くように、という観点から支援していく立場にあります。この立場で仕事をしているうちに思ったことなどを資料にまとめて 30 分ほどお話しさせていただきました。
前日の夜、酔いつぶれた状態で資料を作り始め、途中でやめて寝てしまうという事件があったため（ｗあまり内容がまとまっていない、私の私見と独断ベースの「仲間と一緒に戦うための心得」みたいな感じになってしまいましたが……。
某社の新人さんも何名かいらっしゃっていたようで……もし、私の話を聞いて、今後、より主体的に仕事に取り組んでくれるような若手になってくれたら ——— この夜の目的としては達成と言えるのかな、とか、そんなことを思っています。
さて、プロジェクトマネジメントというと、普通は限られた予算・時間・リソース内でいかに仕事を片付けるかという話が一般的にされるわけですが、今回はそれとはちょっと違います。本業における私の立場では、プロジェクトマネジメントというよりはプロジェクトをリードする立場で、いかにプロジェクトが円滑に回るように、最短で片付くように、という観点から支援していく立場にあります。この立場で仕事をしているうちに思ったことなどを資料にまとめて 30 分ほどお話しさせていただきました。
前日の夜、酔いつぶれた状態で資料を作り始め、途中でやめて寝てしまうという事件があったため（ｗあまり内容がまとまっていない、私の私見と独断ベースの「仲間と一緒に戦うための心得」みたいな感じになってしまいましたが……。
某社の新人さんも何名かいらっしゃっていたようで……もし、私の話を聞いて、今後、より主体的に仕事に取り組んでくれるような若手になってくれたら ——— この夜の目的としては達成と言えるのかな、とか、そんなことを思っています。
東京OpenSolaris勉強会 2011.05に参加してきました。
5月28日(土)に開催された、東京OpenSolaris勉強会 2011.05に参加してきました。
@nslope さんに「自宅ZFSで盛り上がろうず！」とお声がけをいただいたので、構成的にヘンタイな我が家のZFS環境について簡単に紹介させていただきました。
OpenSolaris 界隈の方はマニアックな方々ばかりなので今頃私が ZFS 自体の話をしても全然面白くなりませんし、ということで、あくまでもZFS的に非一般的な我が家のZFS環境についての紹介とさせていただきました。
私の自宅では、 CentOS 5 の Xen 環境において OpenSolaris の開発版スナップショットが動いており、 ZFS ファイルサーバとして利用しています。こうしてある理由としてはファイルサーバとしてZFSの最新機能を活用しつつ Linux とのコンソリデーションを実現する、またOpenSolarisに対応できないような安価なハードウェアでもZFSの恩恵を得るために、そういった構成にしています。
ZFSのオイシイところは、信頼性と管理性だと思います。Linuxのmdraidなどは意図せぬ停電やカーネルパニックでアレイの不整合などが起きると大変です。しかし、ZFSの場合は書き込み操作がトランザクション保護されており、中途半端な書き込み操作が多少起きたぐらいではデグレードしません。仮にデグレードしても、 End-to-end checksum による確認が可能なので、デグレ中や復旧作業後にデータが維持できているかどうかを判断できる点も魅力です。また、（喩えれば水と油を１つのバケツに溜めておける、と私はZFSを紹介することが多いのですが）データの管理が非常にフレキシブルなのもポイントです。
私は基本的には「重要なデータは持たない」（データを持つと管理コストが生じるので）という方針にしていますので、仮に手元のデータがロスしても精々数日ヘコむぐらいで済むよう心の覚悟をいつもしている（つもりな）のですが、これまで３年以上の運用期間中に２回のデグレが発生しても、嬉しいことに、データロスにまでは至っていません。また、これまでの経験から、使い始めた当初は色々と罠があった ZFS ですが、だいたいイケるところが見えてきたので、これからも ZFS を使っていくつもりです。
青山のオラクルさんのビルにて Linux の上に乗った OpenSolaris の話をしたり、リプレース時のOS候補は FreeBSD-current だとか話をしたりとかなり KY でしたがニヤニヤしながら聞いてくださった参加者の皆さん、ありがとうございました。
@nslope さんに「自宅ZFSで盛り上がろうず！」とお声がけをいただいたので、構成的にヘンタイな我が家のZFS環境について簡単に紹介させていただきました。
OpenSolaris 界隈の方はマニアックな方々ばかりなので今頃私が ZFS 自体の話をしても全然面白くなりませんし、ということで、あくまでもZFS的に非一般的な我が家のZFS環境についての紹介とさせていただきました。
私の自宅では、 CentOS 5 の Xen 環境において OpenSolaris の開発版スナップショットが動いており、 ZFS ファイルサーバとして利用しています。こうしてある理由としてはファイルサーバとしてZFSの最新機能を活用しつつ Linux とのコンソリデーションを実現する、またOpenSolarisに対応できないような安価なハードウェアでもZFSの恩恵を得るために、そういった構成にしています。
ZFSのオイシイところは、信頼性と管理性だと思います。Linuxのmdraidなどは意図せぬ停電やカーネルパニックでアレイの不整合などが起きると大変です。しかし、ZFSの場合は書き込み操作がトランザクション保護されており、中途半端な書き込み操作が多少起きたぐらいではデグレードしません。仮にデグレードしても、 End-to-end checksum による確認が可能なので、デグレ中や復旧作業後にデータが維持できているかどうかを判断できる点も魅力です。また、（喩えれば水と油を１つのバケツに溜めておける、と私はZFSを紹介することが多いのですが）データの管理が非常にフレキシブルなのもポイントです。
私は基本的には「重要なデータは持たない」（データを持つと管理コストが生じるので）という方針にしていますので、仮に手元のデータがロスしても精々数日ヘコむぐらいで済むよう心の覚悟をいつもしている（つもりな）のですが、これまで３年以上の運用期間中に２回のデグレが発生しても、嬉しいことに、データロスにまでは至っていません。また、これまでの経験から、使い始めた当初は色々と罠があった ZFS ですが、だいたいイケるところが見えてきたので、これからも ZFS を使っていくつもりです。
青山のオラクルさんのビルにて Linux の上に乗った OpenSolaris の話をしたり、リプレース時のOS候補は FreeBSD-current だとか話をしたりとかなり KY でしたがニヤニヤしながら聞いてくださった参加者の皆さん、ありがとうございました。
qpstudy 06 の懇親会に参加してきました。
5月28日(土)に開催された qpstudy 06 の懇親会に参加してきました。 qpstudy は IT インフラストラクチャを扱うエンカイチックな勉強会で、 qpstudy 03 の頃から、都合がつけばできる限り参加するようにしています。これまで勉強会の参加記録などは blog には書いてなかったんですが、折角 trackback 企画があるのでチャレンジ！
（本当は本編にも参加したかったんだけど、東京 OpenSolaris 勉強会 2011.05でテーマとして ZFS を扱うということで、 @nslope さんに私の都合を考慮して（？？）日程を決めていただいていた事もあり……昼過ぎ〜夕方には東京 OpenSolaris 勉強会＠外苑前、それが終わってから割と急いで大森のニフティさんにハシゴするという感じに……）
本編では @sho7650 さんのリードにより、普段の宴会チックな qpstudy とは全く雰囲気が違う勉強会になっているなーというのを Twitter のタイムライン越しに感じていたのですが、残念ながらそれが終わった頃にやっとこ現地到着。あ、通用口まで迎えにきてくださった @ysaotome さん、ありがとうございます。
懇親会は例によってピザとビールを囲んでの LT 大会です。折角なので私も LT やらせていただきました。
本当は別のネタを仕込んでいたのですが、このスライドのほうが、勉強会本編のテーマにも沿ってるかも知れなくてGoodかな？と思い、セレクト。簡単にご紹介すると、明治３５年に行われた八甲田山の雪中行軍のお話をベースに、プロジェクトを円滑を進めるためには以下のような点が重要だよね？という感じでまとめさせていただきました。
今あらためて見るとヘボいスライドだなぁ……
◇
後、もう一本。ちょっと時間が余っているということだったので、 LT で @masudaK さんが発表されていた「海外MLに積極的に出ようよ！」という内容に共感したので、全くの突然でしたが、カーネル／VM探検隊向けに作成した LT 資料でも簡単に発表させてもらいました。
なお、 LT の発表時間実績が 5 分 0 秒ジャストだったのは、、、、、偶然ですｗ
（本当は本編にも参加したかったんだけど、東京 OpenSolaris 勉強会 2011.05でテーマとして ZFS を扱うということで、 @nslope さんに私の都合を考慮して（？？）日程を決めていただいていた事もあり……昼過ぎ〜夕方には東京 OpenSolaris 勉強会＠外苑前、それが終わってから割と急いで大森のニフティさんにハシゴするという感じに……）
本編では @sho7650 さんのリードにより、普段の宴会チックな qpstudy とは全く雰囲気が違う勉強会になっているなーというのを Twitter のタイムライン越しに感じていたのですが、残念ながらそれが終わった頃にやっとこ現地到着。あ、通用口まで迎えにきてくださった @ysaotome さん、ありがとうございます。
懇親会は例によってピザとビールを囲んでの LT 大会です。折角なので私も LT やらせていただきました。
本当は別のネタを仕込んでいたのですが、このスライドのほうが、勉強会本編のテーマにも沿ってるかも知れなくてGoodかな？と思い、セレクト。簡単にご紹介すると、明治３５年に行われた八甲田山の雪中行軍のお話をベースに、プロジェクトを円滑を進めるためには以下のような点が重要だよね？という感じでまとめさせていただきました。
- スコープを把握する
- 問題を見つけたら対策をとる。判断を先送りしない
- 主体的・積極的に問題に取り組む。他人まかせにしない
今あらためて見るとヘボいスライドだなぁ……
◇
後、もう一本。ちょっと時間が余っているということだったので、 LT で @masudaK さんが発表されていた「海外MLに積極的に出ようよ！」という内容に共感したので、全くの突然でしたが、カーネル／VM探検隊向けに作成した LT 資料でも簡単に発表させてもらいました。
なお、 LT の発表時間実績が 5 分 0 秒ジャストだったのは、、、、、偶然ですｗ
登録:
投稿 (Atom)