koie blog

FreeBSD 10.2から11.0にあげたらブート時のzpool importが失敗してあせったが、どうやら/etc/rc.d/hostidに変更が入って、ブラックリストにのっているhostidは認めないということになっているようだ。私のところの環境でいうと/etc/hostidに00020003-0004-0005-0006-000700080009(これはkenv -q smbios.system.uuidで得られる値)が記録されていたのだが、そんないい加減な値はダメだってことでブート時にuuidgenで新しい値をつくられてしまったので、zpool importするときに

Solaris: WARNING: pool 'POOLNAME' could not be loaded as it was last accessed by another system (host: HOSTNAME hostid: 0xHOSTID). See: http://illumos.org/msg/ZFS-8000-EY

といわれてzpool importが失敗していた。

ルートディレクトリが含まれているプールzrootはうまくimportされていたのでfreebsd-updateがうまいことやってくれたのかなぁ（しらん）。

• 2012-12-07 19:05〜22:22
• 資料: http://people.allbsd.org/~hrs/FreeBSD/sato-FBSD20121207.pdf
• まとめ: http://togetter.com/li/419312

夕方に大きな地震があったが、ちょっとダイヤが乱れたくらいで、勉強会は開催。

ZFSの活用とチューニング

使い方(前半)

• FreeBSD9.0/9.1はチューニングしなくてもそこそこ性能はでる。アプリによっては性能が落ちるポイントがある。
• ZFSはハードディスクがいっぱいつながっているのが大前提。1台だとうれしいことはなにもない。
• ZFSは既存のファイルシステムのいいとこどりしている。トレードオフになっているところはCPUなどマシンパワーで解決する。
• zpool = ストレージプール = ブロックデバイスのあつまりに名前をつけたもの
• ZFSデータセット = ZPOOL上に構成できる名前空間 = ファイルシステム/ボリューム/スナップショット
• FreeBSDにはOpenSolarisのコードそのまま取り込まれた。ライセンスはBSDに近いものなので取り込んでも困ることはないもの。
  • StoragePoolAllocator(SPL)のバージョンン: ミラーとか重複排除とかが関係。今は28。
  • ZFS POSIX Layer(ZPL)のバージョン: ユーザからはあまりみえないが、カーネルとのAPI。今は5。
  • この2つのバージョンで使える機能を判断する。
• OpenSolarisは虫の息...
  • OpenSolarisはだんだんオープンじゃなくなってきている。もう1年半以上あたらしいコードが出てない。
  • Nexenta: illumosをベースにしたストレージを出してた。ソフトだけで商売しようとしてる人たち。
  • いろいろZFSのforkができたが、
  • illumos projectがZFSのコードのとりまとめをしてくれそうな感じ。
• FreeBSDのZFSは9系か8.3以降を使うべし。それ以前は落とし穴がいっぱいある。
• マシンはamd64 RAM=4GB以上。1GBでは性能が出ないし止まってしまう可能性もある。
• ZFSの管理が簡単になるというのは、いままでコマンドラインでUFSをさわってた人にはあまり簡単になったとは思えないかも。
• FFSのスナップショットはつかいものにならないがZFSのはつかえる。
• jailの中からでもファイルシステムの安全に操作できるのがメリットの1つ。
• ZFSはライセンス汚染を避けるためにモジュールになっている。使おうとした瞬間にロードされる。明示的に設定しなくてもよい。
• zpool create pool da1 da2 でプールをつくったらすぐに/poolがつかえるようになってしまう。
• ストライピング幅は動的に決まる。
• zfsがマウントされるのは、プールが認識されたらすぐにマウントされる。/etc/fstabは見ない。
• zfs_enable=YESが評価されてプールが認識されるのは/etc/fstabを見るよりも前。
• zpool destroyでデータも全部消える。確認はない。
• "zfs create プール名/データセット名" でファイルシステムができる。ファイルシステムのサイズは指定されてないことに注意。複数ファイルシステムをつくったらシェアされる。
• データセットは階層構造をもっているが、マウントポイントの階層構造はそれとは関係なく設定できる。
• 設定は設定ファイルではなくプロパティにはいっているのでコマンドをバンバンたたいていく。(Solaris流儀)
• "zfs snapshot プール名/データセット名@スナップショット名" でスナップショットがつくれる。スナップショット名は自由に決められる。
• スナップショットをつくってもマウントポイント設定されない。ディスクの使用量USEDは0。スナップショットの一覧は "zfs list -t all" でみえる。
• スナップショットは "zfs set snapdir=visible" にしておくと.zfsの下にみえるようになる。
• "zfs rollback プール名/データセット名@スナップショット名" でスナップショット時点の内容に戻る。
• "zfs clone プール名/データセット名@スナップショット名 プール名/新データセット名" でファイルシステムの複製をつくれば容量をつかわずに複製がつくれる。(スナップショットは書き込みできないのでcloneする必要がある)。
  • 微妙に設定がちがうシステムディレクトリをつくるときとか。jailで便利につかえる。
  • クローンというデータセットがあるわけではなく、あくまでもファイルシステムとスナップショットの合わせ技でしかない。
• バックアップはzfs sendでできる。
  • 従来のファイルシステムではスナップショットやチェックポイントをネイティブでもっているものは少ない。
  • fileコマンドはsendの出力をしっているので、スナップショットの作成日などが表示される。
  • zfs recvでリストアできる。zfs cloneとちがって本当の複製。
  • "zfs send -p" でプロパティもバックアップされるがマウントポイントの設定も保存されてしまうので、
  • "zfs recv -u" で自動マウントされれないようにすべし。(なんで自動マウントがデフォルトなのかは知らん。)
• zfs destroyはスナップショットがあると消せない。destroy -rでまるごと消せるが注意して。
• "zfs create -V サイズ プール名/データセット名" でボリュームがつくれる。"/dev/zvol/プール名/データセット名" として見える。
  • ZFSをボリュームマネージャとしてつかうことができる。
  • ボリューム上にファイルシステムをつくっておけばブートシーケンスで、ZFSが読み込まれたあとに/etc/fstabでマウントできる。
  • send/recvもできる。つかってるブロックだけをバックアップできる。
• ディスクの中にストレージプールの情報が入っているが起動時に全部のディスクを読んでたら時間がかかるので、/boot/zfs/zpool.caccheにも書いてあるが、これが壊れていると起動できなくなる。(つくりなおすことは可能)

[2012-12-07 20:06]

休憩

いつもはぶっ通しでダレてくるので今回は途中で10分休憩を入れることに。

[2012-12-07 20:15]

使い方(後半)

• UNIXは設定ファイルの文化だがSolarisはコマンドで設定データベースをいじる文化になっていった。
• ファイルシステムはかならず2レベルにすること。プール名とおなじデータセットは使わない。スナップショットやバックアップをとるときにめんどくさい。
  • zfs set mountpoint=none poolと設定すればマウントされなくなる。
  • zfs recvのときにsendしたときと同じ場所に戻せないので困る。"zfs send pool@snap | zfs recv pool" はできない。"zfs send pool@snap | zfs recv pool/pool2" はできる。
• zfs send -Iでスナップショット間の差分バックアップができる。
• zfs sendでパスワードファイルもそのままはいってしまうので暗号化できる経路をつかうべし。
• zfs sendが遅い原因の1つはファイルシステムを読みながら出力するので連続的に出てこない。gzipはブロック単位に処理するのでsshにスムーズにデータが流れない原因になる。
  • ddを二段接続してバッファリングしてgzipが暇にならないようにする→gzipの出力に隙間が空かないようにする。10%くらい性能がかわる。
• zfs diffでファイル単位で差分を抽出できる。スクリプトで処理するときに便利?
• ストレージプールの種類として「ストライププール」は公式にはそういう名前は書かれてないが便宜上そう呼ぶことに。
• ミラープールは中身が一致しているわけではない(俺:RAID1のような一致ではないという意味だとおもう)。どちらか1台が故障してもだいじょうぶ。
• 4台構成でミラーにしないんだったらダブルパリティのRAIDZ2にするのがおすすめ。2台壊れてもだいじょうぶ。
• とにかくZFSではプールは冗長構成にすべき。コピーをつくることで信頼性を担保しているので。
• ホットスペアも指定できる。指定しておけば自動的につかってくれる?
• zpool replaceで動作中にディスク交換できる。
• zpool addではプールの形式を変えないで追加される、zpool attachではミラーに構成を変えて追加される。
• zpool scrubはfsckのように一貫性をチェックするものでは「ない」。(やすいディスクなどで)ビットの反転などを検出するためのもの。
  • dailyで動かす必要はない。zfsがアクセスしたときに自動修復してくれるので。アクセスされてないデータを強制的にアクセスするためのもの。
  • scrubの頻度は機器の信頼度による。業務でつかうようなディスクなら1〜2ヶ月でok。エラーが検出されるようならコネクタとかメモリを疑ってみる。
  • scrubは/etc/periodic.confで設定できる。いろいろ議論した結果デフォルト周期は35日。(ただし、デフォルトではscrubしない)
• zpool export/importは自動で読み込むかどうかの切り替え。
  • 別のマシンに一時的にディスクをもっていってつないだ場合には/boot/zfs/zpool.cacheを書き換えて自動マウントされるようにはなってほしくない。
• FreeBSD9.1以降ではRootFS on ZFSはつかえるようになるはず。それ以前はいろいろ落とし穴があった。でも手動でやる必要がある。
  • ひみつのgpart add -s 122 -t freebsd-boot..
  • rpoolはroot poolの意味
  • zpool.cacheを自分のファイルシステムの中につくらないといけないのと、CDROMブートだと書ける場所がないのがめんどうなところ。
  • そのうちメニューを選んでできるようになるはずだが..
  • おまじない zpool set cachefile="" rpool
  • zpooltest.shでブートできるかチェックできる。ブートに失敗するとリカバリーがたいへんなので事前にチェック。
  • システム更新したらとにかくzpooltest.shでチェックすべし。zpoolが読めないとヤバい。zpooltest.shが通ったら*たぶん*だいじょうぶ...
  • 起動プールとデータのプールは分けておいた方が、管理が簡単。

[2012-12-07 21:03]

性能とチューニング

• ZFSはリンクをたくさんたどるがキャッシュ効いているはず、という仮定がおかれている。
• UFSとちがってZFSは複数のディスクをあつかうのでストライプが効くはず、という仮定もある。
• 書き込みは、ディスクのwrite backキャッシュが効くのにCoWのせいでランダムアクアセス読み込みが発生して、キャッシュがヒットしないと性能がぜんぜん出なくなる。
  • ベンチマークだとZFSが瞬間的な性能が出ないせいで悪い値がでてしまう。
  • disk 3本でベンチした例: gstripeは性能が出るのにzfsストライプだとディスク単体のIOPSしか出ない。原因は書き込みでも読み込みが入るため。
  • ベンチマークはキャッシュが効かないように工夫されてるのでZFSでは性能評価は低くでる。
• 空き容量が20%を切ると性能が落ちる。ここをなんとかしようというのはないので、ディスクを追加すべし。
  • 残り0%になると変な動作をする.. ファイルが消せなくなったり...
• zfs set atime=off: onだとデータ書き込まなくても読んだだけでスナップショットの容量が増えてしまうし、性能がガンガン落ちる。
  • atimeが重要なアプリケーションもあるがzfsでは切った方がよさげ。
• zfs set compression=: データが主に圧縮される。デキストファイルでは効果があるがCPUをかなり喰うので要調整。圧縮する必要があるかも要検討。lzjbよりも圧縮率がよいlz4というのも検討されている。
• dedup(デダップ): ぜったいに使うな。メモリをくいまくる(対策なし)。一度onにするとoffにできない(データを書き直さないと元にもどらない)。使えてる人はだれもいない... 小さな規模なら動くけど、小さかったら意味ないし、圧縮の方がよっぽど小さくなる。
  • メモリを喰うのは、おなじ内容のデータがどこにあるのか探すの時間がかかるのと、キャッシュを広くしなければいけないのが問題。メモリがたっぷりあれば別かもしれないが。トラブルがおこったときにも調査がたいへんになる。
• 小さいファイルのreadが多いワークロード(webサーバ): メタデータのキャッシュが効きているか？ vfs.zfs.arc_meta_limitを大きくする。mmap/sendfileをつかうとzfsとbuffer cacheとで二重にキャッシュしてしまうので、アプリをmmap/sendfileを使わない設定にするのがよい。
• データベースなど固定レコード長もの: recordsize=を合わせておかないと128kBで書き込みされて無駄がでてベンチマーク結果がとんでもないことに。
• ファイルサーバ: スナップショットの数を減らすことで参照数管理のコストが減ってよい。
• L2ARCキャッシュでZFSのランダム読み込みを減らす。
• ZIL: 特に設定しないと各ディスクから少量ずつログ領域をもらってる。分離させて(slog)SSDに置くとよい。
• zfetch: パラメータが複雑。2プロセスの同時readによるストライド・パターンを検出してread回数を減らす。disableできないが基本設定で問題ないはず。
• vdev cache: 0にしとけ。シークの時間を減らす効果があるが、いまのデバイスはシーク時間が短かいので効果ない。負荷によらず0でよいが、古いディスクならチューニングする価値があるかもしれない。
• tgx: COWをまとめてIOを減らすためのしかけ。
  • min_pending,max_pending： 忙しすぎたらwrite止め、暇そうだったら書くスレッショルド。
  • 書き込みをグルーングしてフラグメンテーションを抑えるようになっているのでtxg.timeout=1にするとフラグメントしやすくなる。
  • ベンチマークではなくて自分の負荷に対してトータルの性能がどうなっているか見ること。長いスパンで性能評価するとよい。
  • インパルス的な書き込みとかストリーム的なワークロードに対してはtimeoutを短かくする効果があることも。
• 統計データをみるには zfs-mon, zfs-stats をつかう。
• allbsd.orgは細かいファイルアクセスが多いのでメタデータのキャッシュヒット率を上げないといけない。
  • L2ARCはSSD 64GBだがあまりヒット率は高くない。でかいファイルが多いためか?
  • wwwなどが入っているcvsrootはgzipの圧縮率はめいいっぱい上げて1/3に圧縮。他はあまり圧縮が効いてない。
  • arc_meta_limitを上げてメタデータをキャッシュする。
  • txg.timeoutを30秒に。
  • NFSクライアントのキャッシュも有効期限を長く。
  • チューニング結果UFSとおなじくらいの性能が出てる。
• チューニングのまとめ: webをみて試すよりもまず統計をとる。

[2012-12-07 21:56]

「NEC Express5800サーバ FreeBSDへの取り組みについて」

• タワーサーバは店舗とかデジタルサイネージとかにつかわれている(郵便局とか)
• 空調の電力を抑えるために35度→40度で動作サポート
• 電力的には外資よりも省電力らしい
• NECはストレージもスイッチも40度に対応してるよ。背面は50度くらいになって保守員はたいへん!なのでちょっと下げた方が..

冗長電源は分けて温度を下げるようにしてる(特許申請中)

• IPMIは古い設計なので
• IPMIはスタンバイ電源で動いているので、IPMIがハングすると電源をひっこぬくしかなかったが、BMCのリセットボタンを用意した!
• raidカードの情報をよめるようにしたり。

[2012-12-07 22:12]

[2012-12-07 22:14]

「FreeBSD勉強会」 by BSDコンサルティング(株) 後藤大地

• 講師はつらすぎてやってられないので、
• 参加費の八掛けを講師の方にお渡ししている。
• つまり、佐藤先生の睡眠時間を金で買っているということ!
• InfiniBandのドライバをゴニョゴニョしている。
• 7系をつかっている客も多いが、サポートしきれないので止めてほしい。9系への移行をサポートします!

[2012-12-07 22:22]

佐藤先生に質問

• Q: snapshotはunmountされない?
• A: ZFSとのインタフェイスを決めるときにそうしただけ。気にする必要はない。
• Q: raidzは2台以上とスライドにあったが2台で構築できる?
• A: 3台ないと構築はできない。
• Q: ホットスペアを指定すると、障害があったときに自動でディスクをreplaceしてくれる? (昔みたときはdevdにメッセージがとんでくるだけだったような気が)
• A: スペアのディスクを選んできて入れ替えるコードが入ったような気がする(うるおぼえ)。

懇親会 〜23:15

帰宅

ZFS 仮想化されたファイルシステムの徹底活用

Solaris 10 ZFS Essentials (Oracle Solaris System Administration Series)

• http://atnd.org/events/30273
• 資料: (そのうちuploadされるはず)
• http://togetter.com/li/361800

トラブル

プロジェクターにスライドがでてこない。プロジェクターをリブートしたらうつった。

[2012-08-24 18:47]

• ここ1年半くらのトラブルを経験したマシンがある。
• 半導体のことを大学で教えている。たいていツールはUNIXでしか動かない。半導体の先生は情報工学を学んでないのでボタンが3つ以上あるとつかえない。学生は自分でUNIXを学ばなければならない。
• UNIXの伝統:デバイスは特殊ファイルとして見える。
• GEOMで使いやすくした。

性能

• 記憶装置の性能: かかる時間=データ待ち時間+データ転送時間
• USB3対応メモリ8GB(700円くらい)。60MB/sでつかえると書いてある。
• まずカーネルの性能を知っておかないといけない: dd if=/dev/zero of=/dev/null s=1024x1024 bs=80
• 1024x1024と書くのがPOSIX的に正しい(ポータビリティが高い)
• dd if=/dev/da2 of=/dev/da3 bs=1024x1024 count=80 → 8MB/s
• dd if=/dev/da2 of=/dev/null .. 読むだけなら速いはず → 23.5MB/s
• dd if=/dev/zero of=/dev/da3 .. → 12.4MB/s ?? 8MB/sじゃない!!
• read:23.5MB/s + write:12.4MB/s = rw 8MB/s
• デバイスの待ち時間ができるので遅くなる。
• ddを2つ3つと並列で動かすと待ち時間が減るので速くなる。
• データ転送速度とIOPS(処理遅延)に分けて評価すべし。
• iostat: OSによって微妙にフォーマットが違う。
  • iostat -x da2 -w 1
  • svc_t: サービス待ち時間 (転送サイズが同じならほとんど変わらない:一定)
  • カーネルソースコードが読めないときには統計情報から転送サイズを読み取るしかない。
• 測定データとIOPSと想定したアクセスパターンをつきあわせてみる。
• 家庭用一般向けの消費電力の少ないHDDは回転数は落して転送サイズは大きくして転送速度を稼いでいる。
• アクセス時間 = 固定時間 + データ量依存時間: アプリケーションが最大負荷のときにiostatで統計をとる。
• IOPS=1000なら1万i-nodeをアクセスするのに10秒かかる。(ls -lとかで差がでる)
  • 1メール1ファイルのようなメールシステムとか。
• キャッシュが効きやすいようなファイルレイアウトにするとか。
• UFS_DIRHASH: vfs.ufs.dirhash_maxmemを大きくするとi-nodeキャッシュが改善する。
• BSD系OSは64KiBが基本転送サイズ。これを大きくしてもそれほど性能がかわらないことが経験的に知られている。
• dd bs=で1MiBで指定してもカーネルが64KiBに分割してしまう。
• iostat の %b は利用率。100%になってないと限界までつかってない。
• GEOM用のstatもある。ミラーしたときの末端のデバイスの性能だけではなくGEOMの性能も知りたい。

gmirrorの設定

• システムディスクのハンドブックの記述はまちがっている。
• まず1台(ada1)だけのミラーをつくってada0の内容をコピーする。そのあとリブートしてada0をミラーに組み入れる。これが一番安全。ダウンタイムが短かい。シングルユーザに落ちなくてもリモートからできる(ただし失敗したらアウトだが)。
• パーティションの末尾に512Bのgmirrorの情報を書くが、空きがないとこまる。ディスクを使い切ることはめったにないが。(近いうちにちゃんとハンドブックに書くよ)
• ハードディスクをホットスワップできるかはハードウェアの仕様できまる。
• BIOSはミラーされてるかどうか知らないので、障害時にブートデバイスを変えないといけないかも。ソフトウェアRAIDなのでOSの世界から抜けるとミラーじゃなくなってしまう。
• ルートパーティションだけにしちゃう一派 → CDROMもUSBメモリも使えないサーバがたまにある。そうなるとディスクをひっこぬくしかなくなる。
• / と /usr はreadonlyにして運用するというとはよくやる。書き込むのは/varのみに。そうしておくとミスオペ(rm -rf /)に耐えられる。
• オススメ:
  • / = 3GB
  • swap = メインメモリ以上
  • /var = 30GB
  • /usr = 20GB
  • /tmp = 1GBのメモリディスク
  • 残り = サービスに必要な容量
• クラッシュダンプはswapに書き出される。パニックしたときにファイルシステムは信用できない。

RAID0,1,3

• アクセスパターンを再現できるツールをつかう。(最初に乱数でアクセスパターンを生成して、違う構成での性能を比較する。)
• RAID3はRAID5とちがってパリティディスクが固定されて、ストリーミングのような連続書き込みが速くなる。
• gmirrorにはreadのストライピングの戦略を選べる。
• ソフトウェアRAIDは単発でつかったときに性能が上がるのか下がるのか。geomはそんなに悪くない。

HAST

• GEOMベースでgmirrorの動きをするネットワーク越しに動作する。
• VRRPやCARPと組み合せると片側だけでも動けるようになる。
• /etc/hast.confに書く。両方のマシンに同じ設定ファイルを置く。
• /dev/hast/〜にデバイスができる。
• UCARP(ユーザランドのCARP実装)をHASTとつかうと便利。
• 実績はある。暗号化して共有するのもgeomでできる。

ZFS

• 従来: デバイス→ボリュームマネージャ→ファイルシステム
• ZFS: ZPOOL→DMU→ZFS
  • たくさんのデバイスがあったときにスケーラビリティを達成する。HDDが2台3台じゃ旨みがない。
  • 堅牢性とかはおまけ。
  • クラスタファイルシステムではない。
  • 既存ファイルシステムの欠点(アカデミックなこととか)はたいていつぶしてある。
• ZPOOLでできることは既存のボリュームマネージャとできることはかわってないが組み込まれているところがちがう。
• ZPOOLの上にデータセットをつくれる。データセットとはファイルシステムとか。
• geomがzpoolにおきかわったと見ればよい。
• dnode: inodeみたいなもの。ZFSのデータセットを構成する。UFSとはちがって固定的な場所はない。
• DMU: data management unit. dnodeを操作するカーネル部分。
• VDEVラベル: L0,L1,L2,L3: スーパーブロック相当。1こ128KiB。前後512KiBをつぶせば認識されなくなる。
• ラベル=ブートラベル、ZAPオブジェクト、UB0..127。
• MOS(Meta Object Set): dnodeの配列がふくまれている。
• リンクをつくるときはかならずコピーがつくられる→堅牢性のキャッチコピーはここから
• tank : マトリクスから。
• ファイルシステムもdnodeで管理してファイルとディレクトリもdnodeで管理するという二段になった点だけが違う。
• コピー3とリンクの途中にログを入れるところが違うくらい。
• CoW: 書き換えないでコピーする。でも欠点にもなる。
• ZFSはUFS以上にリンクをたくさん辿るのでdnodeアクセス性能に敏感になる。複数のディスクに分散することで回避することになっている。
• CoWだと書き込みも読み込みを伴うので書き込みつづけるということができない。
• 1つのファイルをランダムライトするようなアプリは遅くなる。原理的に回避不可能。書く前に読むアクセスパターンだらけなので性能が100%出ない。トランザクショングループにまとめて書く回数を減らすようにしているが、メモリ上にたくさん覚えておく必要がある。
• tips
  • amd64: メモリが使えないことのほかに、i386はアクセス効率(MMU)が悪い。
  • vfs.zfs.vdev.cache.size=0: ほとんど効かないのでメモリのムダ。将来的にこの項目はなくなる予定。
  • vfs.zfs.vdev.cache.bshiftは小さいIOをまとめる設定 (default 64Kib(16))。アクセスパターンによって変えるとよい。
  • vfs.zfs.arc_meta_limitを設定してdnodeキャッシュを稼ぐ。 データ量/(8KiB*128B)。 ざっくり1TB=16GBくらい。
    • データアクセスが中心なのかfindするようなメタデータ中心なのかでちがってる。読む方はキャッシュを積めが改善する。

ZFS構築事例

• allbsd.orgを生贄に。
• IOPSをみる。
• writeは5秒に1回になるように設定している。デフォルトは10〜15sだが性能が落ちるので短かくした。アプリによるので測ってみるしかない。IOPSに余裕があれば細かく書くようにすればよい。
• 120Mbps:内部向けファイルサーバとして
• 20Mbps:外向のサービス
• パーソナルで使うくらいならチューニングしなくてもつかえる。
• FreeBSD9以降は大きなトラブルはないとおもってよい。
• たくさんのディスクを載せてなければ性能がおちる。

[2012-08-24 21:13]

QA

• Q: GPTでパーティションをきった理由は
• A: ブートできるように。p1だけをつかう。gmirrorをつかうときにサイズをあわせるためにそうしてただけ。
• Q: SSDがつかわれるようになってきたが。
• A: UFSにはハードディスク前提の最適化としてシリンダーグループがある。でもハードディスクの内部で順番に並んでるとは限らない。UFS2ではシリンダーグループはなくなった。SSD向けにファイルを消したときにTRIMが出るようになっている(UFSのみ)。ZFSもTRIM対応される予定。GEOMレベルで入るらしい。

ZFS: SUNが手を引いてOracleが2年以上ソースを出さなくなった。illumosに開発者が移動している。商用のデバイスをそのコードをつかって商売していて、FreeBSDに入ってきている。FreeBSDのコミュニティーに技術がたまってきているので突然消えたりしないので安心して。

[2012-08-24 21:24]

懇親会。ワイン白+赤+日本酒+つまみ。

[2012-08-25 11:00]

Q: scrubするとパフォーマンスが落ちるんですが。

A: scrubする必要はない。periodicに入ってしまったが必要ない。

• 2012-07-20 18:30〜20:50
• http://atnd.org/events/29931

第9回FreeBSD勉強会 ストレージの管理: GEOM, UFS, ZFS / 佐藤広生

GEOM

• 一次元の配列のように見える。
• GEOMを回避してストレージにアクセスできない。どうやっても通る。
• /dev/ada0とか1バイト単位でアクセスできるようになっている。FreeBSDではcdev,bdevの区別をすてた。ブロックデバイスはない。
• デバイスノード → コンシューマ → プロバイダ → ディスクノード
• プロバイダとコンシューマはペアになる。
• ストレージデバイスがつながれたらGEOMの構造が自動でつくられる。伝統的なUNIXと同じように見えるようになっている。
• BSDラベルのなかにBSDラベルをきっても対応できるらしい。
• sysctl kern.geom.confdot でgraphviz形式でダンプできる。
• mirror classは勝手には作られないが、デバイスの最後のブロックにgmirror(8)で書き込むとカーネルがちら見して、設定を読んでミラークラスをつくってくれる。→ tasting と呼ばれている。
• mirror/mymirrorという名前でもいいけど、UNIX likeなgm0とかにおちついた。
• ミラーのprimaryの指定は後から変更できるが、基本はlabelの先頭のやつ。
• ストレージを切り離すにはgmirror forgetという分かりにくい。
• gmirrorはGENERICに入ってないのでgmirror loadしないといけない。loader.confに入れてブート時に読み込まれるようにしておくこと。
• 基本的に専用コマンドでGEOMメタデータを書き込む。
• ZFSを実現するためにGEOMをくみあわせてつかっている(が表にはみえてこない)。

ファイルシステム

• マウントポイントはディレクトリ基本だが、一部のOSではNFSなどファイル単位でマウントできるものもある。
• mdconfig -a -t swap -u 0 -s 10m でメモリデバイスをつくる。本当にシステムのメモリが枯渇すると落ちるので注意。
• UFSはinode領域はディスクの真中あたりに置いてあって先頭に置くよりも平均的にはアクセスが速くなる。
• inode=2がルートディレクトリ。
• カーネルをアップデートしても落ちるケースはスーパーブロックやinodeが壊れているかもしれない。
• ファイルシステムが壊れてたらmountするとパニックしちゃうのでfsckが終わるまでmountできないようになっている。
• fsckは未使用ブロックの解放をおこなうがメモリがたくさん要る。ディスク1GBに対して0.5MBのメモリが必要。
• fsckはswaponの前なので注意。
• inodeを非同期で書き込むと速くなるが信頼性が落ちる。FreeBSDは遅いといわれると悲しい→softupdatesが開発された。
• softupdatesは削除は参照されないようにしてからブロックを消す。追加はブロックをつくってから参照をいれる。
• softupdatesを有効にしてても未使用ブロック管理の回収でfsckが必要になる。fsckの時間は短かくならないが損傷の可能性は低くなる。
• ジャーナリングでメタデータ操作の手順を記録する→復旧時にリプレイすればok。リプレイは何度やっても同じ結果になる。fsckの時間はほぼなくなったが、電源断で戻る幅がおおきくなった。やってないことになる量が増えたということ。10分とか15分とかのオーダで戻る。
• 現状ジャーナリングを有効にるとdump -Lがつかえなくなる。改修中。

• Q バグは9.1で直る? A: リリース前にレポートしてほしい、リリース直後は疲弊していてメールをよみとばしてしまう傾向が..
• Q dragonflyのhammerは移植されるか? A: hammer FSはVFSの改造が入っているのでもってくるのはむつかしい。fuseの形で動かせるが、FreeBSDにもってきてても性能が出ない。技術的に難しい。hammer2でOSもかきかわってきているので。

[2012-07-20 20:37]

FreeBSDとCloudCore VPSと私 / 小原聖健

• 自宅に置く電気代よりも安いよ。
• たくさん購入すると安くなるよ。
• そのうち新しいメニューが出るよ。

[2012-07-20 20:42]

FreeBSD勉強会 / 後藤大地

• portsはバージョン管理されていないのでどんどん新しくなってしまう、古いバージョンにセキュリティパッチだけあてるサービス。
• RedHatのような動作検証サポート。検証結果だけでなくてプログラム自体を提供するとか。

懇親会

～22:50

日本酒がいっぱいならんでました。

次回以降

• 10th 後編 http://atnd.org/events/30273
• 11th BHyVe? http://atnd.org/events/30986

L2ARCとして使っていたSSDを取り外した。

取り外す前にsmartの値をみてみたら、書き込み量が読み込みより数倍多いことがわかる。

L2ARCの挙動としてはオンメモリのARCから押し出されたものをどんどん書き込むので、まさにそのとおりになっている。

L2ARCの書き込み単位は大きく読み出し単位は小さいというのもみえてくる。この特性はNAND Flashの性質にぴったり。

ID# ATTRIBUTE_NAME            RAW_VALUE
  1 Raw_Read_Error_Rate       6
  9 Power_On_Hours            7520
 12 Power_Cycle_Count         52
184 Initial_Bad_Block_Count   123
195 Program_Failure_Blk_Ct    0
196 Erase_Failure_Blk_Ct      0
197 Read_Failure_Blk_Ct       0
198 Read_Sectors_Tot_Ct       3839845191
199 Write_Sectors_Tot_Ct      11750223536
200 Read_Commands_Tot_Ct      148228624
201 Write_Commands_Tot_Ct     41284400
202 Error_Bits_Flash_Tot_Ct   3642321
203 Corr_Read_Errors_Tot_Ct   3504621
204 Bad_Block_Full_Flag       0
205 Max_PE_Count_Spec         10000
206 Min_Erase_Count           824
207 Max_Erase_Count           1803
208 Average_Erase_Count       979
209 Remaining_Lifetime_Perc   91
211 SATA_Error_Ct_CRC         0
212 SATA_Error_Ct_Handshake   0
213 Indilinx_Internal         0

Write_Sectors_Tot_Ct/Read_Sectors_Tot_Ct = 3.06
Write_Commands_Tot_Ct/Read_Commands_Tot_Ct = 0.278
Write_Sectors_Tot_Ct/Write_Commands_Tot_Ct = 284   (142KiB/access)
Read_Sectors_Tot_Ct/Read_Commands_Tot_Ct = 25.9048 (13KiB/access)

手順:

1. zpool remove tank dev 論理的に取り外し
2. 電源offしてケーブルの取り外し
3. ブート

arc_summaryの結果をみてると、L2ARCがなくなるとそのぶんをオンメモリのARCが肥大するようで1〜2GBくらいサイズが大きい。

5日ほど経過してL2ARCの熟成具合をみてみると、Hit Ratioが49%となかなか高い。でもARC Sizeが2.57GiBと小さいのはなぜだろう。Target Sizeは4.34GiBなので全然埋まってない。

あと気になるのはtop -aHS (-aはargv表示、-Hはスレッド表示、-Sはシステムプロセスも表示)で観察していると、l2arc_feed_threadが1%ほどCPUを喰いつづけている。vfs.zfs.l2arc_feed_secs=1秒間隔でチェックしてるだけで1%ということは1回まわるのに1msかかっているということで、けっこう重い処理なんだなぁ。WITNESSを有効にしているので一時的にdebug.witness.watch=0にしてみて負荷が軽くなるかとおもったら、まったく変化なし。

% zpool iostat -v tank
                capacity     operations    bandwidth
pool         alloc   free   read  write   read  write
-----------  -----  -----  -----  -----  -----  -----
tank          884G  1.07T     43     13  1.87M   213K
  raidz1      884G  1.07T     43     13  1.87M   192K
    ada1s2       -      -     15      6  1.07M  97.2K
    ada2s2       -      -     16      6  1.07M  97.2K
    ada3s2       -      -     15      6  1.07M  97.2K
logs             -      -      -      -      -      -
  label/zil  1.44M  1.95G      0      0      3  21.1K
cache            -      -      -      -      -      -
  ada4       46.6G  72.6G      9      2  54.9K   144K
-----------  -----  -----  -----  -----  -----  -----

% arc_summary
------------------------------------------------------------------------
ZFS Subsystem Report				Mon Dec 12 10:48:33 2011
------------------------------------------------------------------------

System Memory:
	1.60%	174.12	MiB Active,	2.58%	280.89	MiB Inact
	84.55%	8.99	GiB Wired,	0.14%	15.25	MiB Cache
	11.12%	1.18	GiB Free,	0.02%	2.02	MiB Gap

	Real Installed:				12.00	GiB
	Real Available:			91.54%	10.98	GiB
	Real Managed:			96.82%	10.64	GiB

	Logical Total:				12.00	GiB
	Logical Used:			87.74%	10.53	GiB
	Logical Free:			12.26%	1.47	GiB

Kernel Memory:					304.88	MiB
	DATA:				91.44%	278.79	MiB
	TEXT:				8.56%	26.08	MiB

	KMAP:					5.61	GiB
	FREE:				4.69%	269.40	MiB
								Page:  1
------------------------------------------------------------------------

ARC Summary: (THROTTLED)
	Storage pool Version:			28
	Filesystem Version:			5
	Memory Throttle Count:			7

ARC Misc:
	Deleted:				3.41m
	Recycle Misses:				2.56m
	Mutex Misses:				12.40k
	Evict Skips:				12.40k

ARC Size:				42.77%	2.57	GiB
	Target Size: (Adaptive)		72.30%	4.34	GiB
	Min Size (Hard Limit):		66.67%	4.00	GiB
	Max Size (High Water):		1:1	6.00	GiB

ARC Size Breakdown:
	Recently Used Cache Size:	12.40%	550.78	MiB
	Frequently Used Cache Size:	87.60%	3.80	GiB

ARC Hash Breakdown:
	Elements Max:				1.14m
	Elements Current:		98.64%	1.12m
	Collisions:				3.11m
	Chain Max:				17
	Chains:					241.78k
								Page:  2
------------------------------------------------------------------------

ARC Efficiency:					97.95m
	Cache Hit Ratio:		93.06%	91.15m
	Cache Miss Ratio:		6.94%	6.80m
	Actual Hit Ratio:		80.38%	78.73m

	Data Demand Efficiency:		94.23%	30.25m
	Data Prefetch Efficiency:	56.08%	457.86k

	CACHE HITS BY CACHE LIST:
	  Anonymously Used:		9.75%	8.88m
	  Most Recently Used:		5.75%	5.24m
	  Most Frequently Used:		80.62%	73.49m
	  Most Recently Used Ghost:	1.51%	1.37m
	  Most Frequently Used Ghost:	2.37%	2.16m

	CACHE HITS BY DATA TYPE:
	  Demand Data:			31.28%	28.51m
	  Prefetch Data:		0.28%	256.78k
	  Demand Metadata:		52.71%	48.04m
	  Prefetch Metadata:		15.73%	14.34m

	CACHE MISSES BY DATA TYPE:
	  Demand Data:			25.68%	1.75m
	  Prefetch Data:		2.96%	201.08k
	  Demand Metadata:		40.86%	2.78m
	  Prefetch Metadata:		30.50%	2.07m
								Page:  3
------------------------------------------------------------------------

L2 ARC Summary: (HEALTHY)
	Passed Headroom:			2.51m
	Tried Lock Failures:			6.73m
	IO In Progress:				38.63k
	Low Memory Aborts:			33
	Free on Write:				3.36k
	Writes While Full:			4.03k
	R/W Clashes:				541
	Bad Checksums:				0
	IO Errors:				0
	SPA Mismatch:				539.89m

L2 ARC Size: (Adaptive)				36.97	GiB
	Header Size:			0.48%	181.02	MiB

L2 ARC Breakdown:				6.80m
	Hit Ratio:			48.99%	3.33m
	Miss Ratio:			51.01%	3.47m
	Feeds:					340.70k

L2 ARC Buffer:
	Bytes Scanned:				722.28	TiB
	Buffer Iterations:			340.70k
	List Iterations:			21.76m
	NULL List Iterations:			769.00k

L2 ARC Writes:
	Writes Sent:			100.00%	33.61k
								Page:  4
------------------------------------------------------------------------

File-Level Prefetch: (HEALTHY)

DMU Efficiency:					288.43m
	Hit Ratio:			73.56%	212.17m
	Miss Ratio:			26.44%	76.26m

	Colinear:				76.26m
	  Hit Ratio:			0.01%	7.12k
	  Miss Ratio:			99.99%	76.25m

	Stride:					210.90m
	  Hit Ratio:			99.97%	210.84m
	  Miss Ratio:			0.03%	64.77k

DMU Misc:
	Reclaim:				76.25m
	  Successes:			0.23%	174.33k
	  Failures:			99.77%	76.08m

	Streams:				1.33m
	  +Resets:			0.06%	841
	  -Resets:			99.94%	1.33m
	  Bogus:				0
								Page:  5
------------------------------------------------------------------------

VDEV Cache Summary:				11.57m
	Hit Ratio:			57.01%	6.60m
	Miss Ratio:			22.79%	2.64m
	Delegations:			20.20%	2.34m
								Page:  6
------------------------------------------------------------------------

ZFS Tunable (sysctl):
	kern.maxusers=384
	vfs.zfs.l2c_only_size=36178498560
	vfs.zfs.mfu_ghost_data_lsize=352977920
	vfs.zfs.mfu_ghost_metadata_lsize=343705600
	vfs.zfs.mfu_ghost_size=696683520
	vfs.zfs.mfu_data_lsize=826750976
	vfs.zfs.mfu_metadata_lsize=424857088
	vfs.zfs.mfu_size=1475247616
	vfs.zfs.mru_ghost_data_lsize=192281088
	vfs.zfs.mru_ghost_metadata_lsize=3768553472
	vfs.zfs.mru_ghost_size=3960834560
	vfs.zfs.mru_data_lsize=318336000
	vfs.zfs.mru_metadata_lsize=55524352
	vfs.zfs.mru_size=389883904
	vfs.zfs.anon_data_lsize=0
	vfs.zfs.anon_metadata_lsize=0
	vfs.zfs.anon_size=3495936
	vfs.zfs.l2arc_norw=1
	vfs.zfs.l2arc_feed_again=1
	vfs.zfs.l2arc_noprefetch=1
	vfs.zfs.l2arc_feed_min_ms=200
	vfs.zfs.l2arc_feed_secs=1
	vfs.zfs.l2arc_headroom=10
	vfs.zfs.l2arc_write_boost=8388608
	vfs.zfs.l2arc_write_max=8388608
	vfs.zfs.arc_meta_limit=1610612736
	vfs.zfs.arc_meta_used=1610368104
	vfs.zfs.arc_min=4294967296
	vfs.zfs.arc_max=6442450944
	vfs.zfs.dedup.prefetch=1
	vfs.zfs.mdcomp_disable=0
	vfs.zfs.write_limit_override=0
	vfs.zfs.write_limit_inflated=35384819712
	vfs.zfs.write_limit_max=1474367488
	vfs.zfs.write_limit_min=33554432
	vfs.zfs.write_limit_shift=3
	vfs.zfs.no_write_throttle=0
	vfs.zfs.zfetch.array_rd_sz=1048576
	vfs.zfs.zfetch.block_cap=256
	vfs.zfs.zfetch.min_sec_reap=2
	vfs.zfs.zfetch.max_streams=8
	vfs.zfs.prefetch_disable=0
	vfs.zfs.mg_alloc_failures=8
	vfs.zfs.check_hostid=1
	vfs.zfs.recover=0
	vfs.zfs.txg.synctime_ms=1000
	vfs.zfs.txg.timeout=5
	vfs.zfs.scrub_limit=10
	vfs.zfs.vdev.cache.bshift=16
	vfs.zfs.vdev.cache.size=104857600
	vfs.zfs.vdev.cache.max=16384
	vfs.zfs.vdev.write_gap_limit=4096
	vfs.zfs.vdev.read_gap_limit=32768
	vfs.zfs.vdev.aggregation_limit=131072
	vfs.zfs.vdev.ramp_rate=2
	vfs.zfs.vdev.time_shift=6
	vfs.zfs.vdev.min_pending=4
	vfs.zfs.vdev.max_pending=10
	vfs.zfs.vdev.bio_flush_disable=0
	vfs.zfs.cache_flush_disable=0
	vfs.zfs.zil_replay_disable=0
	vfs.zfs.zio.use_uma=1
	vfs.zfs.version.zpl=5
	vfs.zfs.version.spa=28
	vfs.zfs.version.acl=1
	vfs.zfs.debug=0
	vfs.zfs.super_owner=0
	vm.kmem_size=8589934592
	vm.kmem_size_scale=1
	vm.kmem_size_min=0
	vm.kmem_size_max=329853485875
								Page:  7
------------------------------------------------------------------------

つかわれてないSSDがあるのでL2ARCとしてつかってみた。

これで追加ok↓

zpool add tank cache /dev/ada4

で、とりあえずSMARTでも調べてみるかとsmartctl -ax /dev/ada4ってしたらOSごとプチフリーズした。

もどってきたけどzpool statusでみると REMOVED になってた。

% zpool status  tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0 in 7h6m with 0 errors on Wed Nov 30 10:52:13 2011
config:

        NAME                    STATE     READ WRITE CKSUM
        tank                    ONLINE       0     0     0
          raidz1-0              ONLINE       0     0     0
            ada1s2              ONLINE       0     0     0
            ada2s2              ONLINE       0     0     0
            ada3s2              ONLINE       0     0     0
        logs
          label/zil             ONLINE       0     0     0
        cache
          12789752023354324186  REMOVED      0     0     0  was /dev/ada4

errors: No known data errors

いったんL2ARCから外す。

zpool remove tank cache /dev/ada4

なんか返事がかえってこないし、CPUもブンブン回っている。

  PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
    0 root          -88    0     0K  5184K CPU3    3   1:25 100.00% [kernel{thread taskq}]

しばらくしたら正常になったが、このデバイスにはSMARTしちゃいけないみたいだ。朝、マシンのZFS関係がのきなみzfsのロックでひっかかって使用不能状態になってた。夜中のdailyでSMARTで値を監視しているところでハングアップしたようだ。

dailyでSMARTをとらないようにして一晩経過。なかなかL2ARCは効いているようだ。

zpool iostat -v tankの結果

                capacity     operations    bandwidth
pool         alloc   free   read  write   read  write
-----------  -----  -----  -----  -----  -----  -----
tank          885G  1.07T     12     18   176K   339K
  raidz1      885G  1.07T     12     17   176K   311K
    ada1s2       -      -      4      8   135K   157K
    ada2s2       -      -      4      8   136K   157K
    ada3s2       -      -      4      8   135K   157K
logs             -      -      -      -      -      -
  label/zil  1.19M  1.95G      0      0     13  28.0K
cache            -      -      -      -      -      -
  ada4       21.1G  98.2G      9      4  69.1K   283K
-----------  -----  -----  -----  -----  -----  -----

arc_summaryの結果

------------------------------------------------------------------------
ZFS Subsystem Report				Fri Dec  9 10:35:44 2011
------------------------------------------------------------------------

System Memory:
	1.58%	172.32	MiB Active,	2.54%	276.75	MiB Inact
	83.34%	8.86	GiB Wired,	0.03%	3.69	MiB Cache
	12.49%	1.33	GiB Free,	0.01%	1.44	MiB Gap

	Real Installed:				12.00	GiB
	Real Available:			91.54%	10.98	GiB
	Real Managed:			96.82%	10.64	GiB

	Logical Total:				12.00	GiB
	Logical Used:			86.65%	10.40	GiB
	Logical Free:			13.35%	1.60	GiB

Kernel Memory:					280.84	MiB
	DATA:				90.71%	254.76	MiB
	TEXT:				9.29%	26.08	MiB

	KMAP:					5.63	GiB
	FREE:				21.38%	1.20	GiB
								Page:  1
------------------------------------------------------------------------

ARC Summary: (THROTTLED)
	Storage pool Version:			28
	Filesystem Version:			5
	Memory Throttle Count:			1

ARC Misc:
	Deleted:				741.62k
	Recycle Misses:				546.38k
	Mutex Misses:				2.11k
	Evict Skips:				2.11k

ARC Size:				54.46%	3.27	GiB
	Target Size: (Adaptive)		84.34%	5.06	GiB
	Min Size (Hard Limit):		66.67%	4.00	GiB
	Max Size (High Water):		1:1	6.00	GiB

ARC Size Breakdown:
	Recently Used Cache Size:	46.35%	2.35	GiB
	Frequently Used Cache Size:	53.65%	2.71	GiB

ARC Hash Breakdown:
	Elements Max:				810.84k
	Elements Current:		100.00%	810.84k
	Collisions:				1.23m
	Chain Max:				13
	Chains:					213.53k
								Page:  2
------------------------------------------------------------------------

ARC Efficiency:					27.16m
	Cache Hit Ratio:		92.91%	25.23m
	Cache Miss Ratio:		7.09%	1.93m
	Actual Hit Ratio:		84.06%	22.83m

	Data Demand Efficiency:		92.59%	10.07m
	Data Prefetch Efficiency:	29.31%	107.15k

	CACHE HITS BY CACHE LIST:
	  Anonymously Used:		5.53%	1.39m
	  Most Recently Used:		13.31%	3.36m
	  Most Frequently Used:		77.17%	19.47m
	  Most Recently Used Ghost:	1.73%	437.57k
	  Most Frequently Used Ghost:	2.27%	571.79k

	CACHE HITS BY DATA TYPE:
	  Demand Data:			36.96%	9.33m
	  Prefetch Data:		0.12%	31.40k
	  Demand Metadata:		53.51%	13.50m
	  Prefetch Metadata:		9.41%	2.37m

	CACHE MISSES BY DATA TYPE:
	  Demand Data:			38.77%	746.85k
	  Prefetch Data:		3.93%	75.75k
	  Demand Metadata:		43.50%	837.98k
	  Prefetch Metadata:		13.79%	265.66k
								Page:  3
------------------------------------------------------------------------

L2 ARC Summary: (HEALTHY)
	Passed Headroom:			1.69m
	Tried Lock Failures:			2.13m
	IO In Progress:				2.29k
	Low Memory Aborts:			13
	Free on Write:				2.37k
	Writes While Full:			1.62k
	R/W Clashes:				320
	Bad Checksums:				0
	IO Errors:				0
	SPA Mismatch:				472.43m

L2 ARC Size: (Adaptive)				18.11	GiB
	Header Size:			0.43%	79.62	MiB

L2 ARC Breakdown:				1.93m
	Hit Ratio:			36.49%	702.93k
	Miss Ratio:			63.51%	1.22m
	Feeds:					78.65k

L2 ARC Buffer:
	Bytes Scanned:				188.16	TiB
	Buffer Iterations:			78.65k
	List Iterations:			5.01m
	NULL List Iterations:			614.57k

L2 ARC Writes:
	Writes Sent:			100.00%	12.04k
								Page:  4
------------------------------------------------------------------------

File-Level Prefetch: (HEALTHY)

DMU Efficiency:					90.34m
	Hit Ratio:			74.24%	67.07m
	Miss Ratio:			25.76%	23.27m

	Colinear:				23.27m
	  Hit Ratio:			0.01%	2.54k
	  Miss Ratio:			99.99%	23.27m

	Stride:					66.75m
	  Hit Ratio:			99.94%	66.70m
	  Miss Ratio:			0.06%	41.48k

DMU Misc:
	Reclaim:				23.27m
	  Successes:			0.36%	83.31k
	  Failures:			99.64%	23.18m

	Streams:				364.79k
	  +Resets:			0.08%	300
	  -Resets:			99.92%	364.49k
	  Bogus:				0
								Page:  5
------------------------------------------------------------------------

VDEV Cache Summary:				1.00m
	Hit Ratio:			60.34%	605.51k
	Miss Ratio:			29.96%	300.61k
	Delegations:			9.70%	97.35k
								Page:  6
------------------------------------------------------------------------

ZFS Tunable (sysctl):
	kern.maxusers=384
	vfs.zfs.l2c_only_size=13392641536
	vfs.zfs.mfu_ghost_data_lsize=670471168
	vfs.zfs.mfu_ghost_metadata_lsize=765786112
	vfs.zfs.mfu_ghost_size=1436257280
	vfs.zfs.mfu_data_lsize=848583168
	vfs.zfs.mfu_metadata_lsize=379664896
	vfs.zfs.mfu_size=1382747136
	vfs.zfs.mru_ghost_data_lsize=2289632256
	vfs.zfs.mru_ghost_metadata_lsize=1683590656
	vfs.zfs.mru_ghost_size=3973222912
	vfs.zfs.mru_data_lsize=1204788736
	vfs.zfs.mru_metadata_lsize=153126912
	vfs.zfs.mru_size=1384736256
	vfs.zfs.anon_data_lsize=0
	vfs.zfs.anon_metadata_lsize=0
	vfs.zfs.anon_size=2969600
	vfs.zfs.l2arc_norw=1
	vfs.zfs.l2arc_feed_again=1
	vfs.zfs.l2arc_noprefetch=1
	vfs.zfs.l2arc_feed_min_ms=200
	vfs.zfs.l2arc_feed_secs=1
	vfs.zfs.l2arc_headroom=10
	vfs.zfs.l2arc_write_boost=8388608
	vfs.zfs.l2arc_write_max=8388608
	vfs.zfs.arc_meta_limit=1610612736
	vfs.zfs.arc_meta_used=1455369960
	vfs.zfs.arc_min=4294967296
	vfs.zfs.arc_max=6442450944
	vfs.zfs.dedup.prefetch=1
	vfs.zfs.mdcomp_disable=0
	vfs.zfs.write_limit_override=0
	vfs.zfs.write_limit_inflated=35384819712
	vfs.zfs.write_limit_max=1474367488
	vfs.zfs.write_limit_min=33554432
	vfs.zfs.write_limit_shift=3
	vfs.zfs.no_write_throttle=0
	vfs.zfs.zfetch.array_rd_sz=1048576
	vfs.zfs.zfetch.block_cap=256
	vfs.zfs.zfetch.min_sec_reap=2
	vfs.zfs.zfetch.max_streams=8
	vfs.zfs.prefetch_disable=0
	vfs.zfs.mg_alloc_failures=8
	vfs.zfs.check_hostid=1
	vfs.zfs.recover=0
	vfs.zfs.txg.synctime_ms=1000
	vfs.zfs.txg.timeout=5
	vfs.zfs.scrub_limit=10
	vfs.zfs.vdev.cache.bshift=16
	vfs.zfs.vdev.cache.size=104857600
	vfs.zfs.vdev.cache.max=16384
	vfs.zfs.vdev.write_gap_limit=4096
	vfs.zfs.vdev.read_gap_limit=32768
	vfs.zfs.vdev.aggregation_limit=131072
	vfs.zfs.vdev.ramp_rate=2
	vfs.zfs.vdev.time_shift=6
	vfs.zfs.vdev.min_pending=4
	vfs.zfs.vdev.max_pending=10
	vfs.zfs.vdev.bio_flush_disable=0
	vfs.zfs.cache_flush_disable=0
	vfs.zfs.zil_replay_disable=0
	vfs.zfs.zio.use_uma=1
	vfs.zfs.version.zpl=5
	vfs.zfs.version.spa=28
	vfs.zfs.version.acl=1
	vfs.zfs.debug=0
	vfs.zfs.super_owner=0
	vm.kmem_size=8589934592
	vm.kmem_size_scale=1
	vm.kmem_size_min=0
	vm.kmem_size_max=329853485875
								Page:  7
------------------------------------------------------------------------

• 2011-10-15 13:30〜18:50
• http://atnd.org/events/19348
• http://twitter.com/#!/search/#zfsday
• http://togetter.com/li/200791
• http://www.ainoniwa.net/doku/storage/zfs/zfsday/start

午前のswex学会(桜上水)を午前で抜け、スニッカーズをぶちこんで移動。外苑前には昼着。

青山のマクドナルドで昼飯。やたらオシャレなかんじ。ベレー帽だし。

ZFS Dayのとなりではphfesなるものをやっていた部屋が4倍くらい大きなところでやってた。

13:30 - 13:40 挨拶・諸注意など

[2011-10-15 13:37]

ZFS はどうすごい？(概要 + 宣伝)」(hiroa) @nslope

• http://www.ustream.tv/recorded/17884409
• ファイルシステムをつくるには10年はかかる。
• 128bit: ぜんぶ用意すると全海水を沸騰させられるほどの容量。
• 80%を越えたあたりからあやしくなってくる。
• fault injectionにたいしてはZFSは堅牢
• 実は性能にはかなり工数をかけている
• random writeをsequentialに変換する (write sequentialization)
• read-modify-write: 小さいwriteではパリティ計算に時間がかかるのではなくてreadに時間がかかる。
• URE un recoverable error
  • RAID5 3D+1P のときrebuild失敗は2(URE10^14)〜20%(URE10^15)の失敗確率。RAID6ならほぼ0%になる。
• ちいさなランダムreadは弱い。シーケンシャルやランダムwriteはよい。
• OOW20011
  • ZFSSA Gen3 SPC-1 137000IPPS fast safe cheap. Pick 3!!

[2011-10-15 14:19]

[2011-10-15 14:25]

「Linux で ZFS」(Kazuhisa Hara) @kazuhisya

• http://www.slideshare.net/kazuhisa/zfs-day
• http://www.ustream.tv/recorded/17885194
• ライセンスCDDL vs GPL。
• 2010年まで
  • LLNL(ローレンス・リバモア国立研究所)
  • zfs-fuse 2006年から
• 2010年なかばからネイティブ版プロジェクトがでてきた
  • Knowledge Quest Infotech版 (こっちだけ話題になった)
  • zfsonlinux.org版
• 用語
  • SPL: Solaris Porting Layer
  • ZPL: ZFS POSIX Layer (lzfs) マウントしてつかえるようにするために必要
• KQ Infotech版
  • SPLを実装。ZFSはCDDLをそのまま。
  • コミットがとまったとおもったら→会社が買収されてた→STEC社に。(2011-04-11が最後)。最新のカーネルでビルドできない。
• zfsonlinux.org版
  • githubにけっこうコミットされている。
  • つかうならこっち。
  • 安定板ではZPLがまだ実装されていない。開発バージョンには入った。
  • ZFS=CDDL. SPL=GPL.
  • ふつうにつかえる。
• DKMS(dynamic kernel module suppoert)でない。カーネルアップデートのたびにビルドしなおし。
• 本番はむり。望みはある。
• バフォーマンス
  • NexentaStor 3.1.1 x86_64 (zfs v5, zpool v28)
  • Scientific LInux 6.1 x64_64
  • RAID-Z1 (4本) パラメータはデフォルトのままで。noatimeとかelevatorとかはいじってない。
  • fio 1.55をつかって測定。ARCはのせてる。
  • HP micro server
  • NFS
    • seq-write(400KB/s), rand-write-512k が絶望的に遅い。Issue #229,#361既知の問題。syncを何度もしちゃうらしい。
    • asyncにしたら、それなりになった。
    • sync + no_wdelayは効果なし。
  • iSCSI
  • まずまず。結構いける。rand-512k-write,rand-4k-read-ncqは遅い。
• lsb_release -a でディストリビユーションがわかる
• Q: ARCの設定は?
• A: /etc/の下にあったはずだが..。 topで出てこない。 zfsstatもzfsonlinux用のが必要。
• Q: fsck。btrfsのはこわれてても直してくれない。
• A: scrub。修復できた。どうやったかというと仮想マシンだったのでホストからrmしただけ。
• Q: 問題があったら?
• A: ZFSにissueはたまるが、SPLにいろいろコミットがはいる。

[2011-10-15 15:24]

休憩

• 無料レギュラーコーヒーをいただく。
• コーヒーの写真をとってtwitterに流したら隣りがnabekenさんだった。

2011/10/15 15:36:36
コーヒー http://t.co/G1LGWso9

2011/10/15 15:38:47
となりに @koie さんがいた

「FreeBSDさんとZFSさん」「FreeBSD と ZFS（仮）」(@team_eririn)

[2011-10-15 15:41]

• http://www.ustream.tv/recorded/17886255
• http://www.ainoniwa.net/data/txt/ZFSDay_2011.10_FreeBSD_and_ZFS/
• 初登場: FreeeBSD 7.0-RELEASE zfs v1, zpool v6 だった。バグだらけなのでこわかった。
• ZFSguru 0.1.8というのもある。
• 障害からの復旧
  • zpool import -m: zilが壊れたとき
  • zpoo clear -F: rolback
  • zpool import -F: rollback
• ZFSの方がファイルシステムをつくるコマンド数は少ないけど、中でなにやってるかは謎..
• zfs set shareiscsi: not supported
• zfs set sharesmb: not supported
• zfs set sharenfsの利点はmountdをrestartしなくてよい点くらい。
• NFSでZILがボトルネックになって1MB/sくらいしか出ない。
  • SSDにするかZILの無効化するか上のレイヤでasyncに設定。zvolのときは常に同期書き込みになってしまう。
• UFSでdumpしてZFSでrestoreはできる。でもrsyncの方が簡単じゃね?
• ZFSはJBOD/RAID3はできない。(UFS+GEOMはできる)
• 階層: HW→driver→GEOM→devfs→buffercache/VM→FS
• ZFSとGEOMの関係: 4KiBセクタと暗号化。
  • gnopに4KiBとZFSにおしえる。初回だけ必要。phys sec sizeを4KiBと報告してくれるなら不要。
  • 4KiB: zdb -C tank | grep ashift が 12になればok。
  • geom_eliで暗号化
  • ZFSの実装は一部GEOMをつかっている: geom_vdev, geom_zvol
  • zvolつくった上にzfsつくったらパニックしたかも?
• VMではzvolじゃなくてfileをつかっている。ファイルならリサイズ簡単。バイナリエディタでいじろうとおもったがvimはクラッシュして

しまった。ZILも止めたいし。

• ディスクのいれかえ方法
  • (ATA)
  • atacontrol list
  • atacontrol detach ata2
  • atacontrol attach ata2
  • zpool replace ad4
  • (SCSI)
  • camcontrol devlist
  • camcontrol eject 0:1:0
  • camcontrol rescan all
  • zpool replace da1
• RAIDカードをつかうと先頭にメタデータ領域をとられたりするので、つかいたくない。
• Q:ポートマルチプライヤー
• A:1台抜いたときに他のも道連れになることがあるので避けている。仮想マシンがたくさん動いてたりルータになってたりにするので落したくないから。

[2011-10-15 16:36]

休憩

「Solaris と ZFS」(lum) @mari_lum

[2011-10-15 16:50]

• http://www.ustream.tv/recorded/17887065
• 最小のファイルシステムをつくってためす:
  • makefile 12m zp
  • zpoolcreate tetpool `pwd`/zp
  • zdb -vvvv testpool >step1
  • cp /usr/dict/words /testpool/words
  • zdb -vvvv testpool >step2
  • mkdir /testpool/subdir
  • zdb -vvvv testpool >step3
  • ln /testpool/words /testpool/subdir/words
  • zdb -vvvv testpool >step4
• 「On-Disk Format Review」
  • VDEV labelは先頭に2つ(L0,L1)、最後尾に2つ(L2,L3)ある。ラベルがすべておなじだったらトランザクション成功したことになる。
  • 先頭と最後に分けることで全滅する可能性をへらしている。
  • Labelのなかみは、8K VTOC用ブランク、8K boot hreader, 112KB name-value pair、128K 1Kのuberblockがリングになっている。
  • ミラーされているときにはname-valueにchildlenがどうのこうのと書いてある。
  • Block Pointers
    • ポインタ 128バイト
    • asize: actual size (ディスク上に確保したサイズ)
    • lsize: logical (圧縮前)
    • pssize: physical(圧縮後)
    • G: ギャングビット。容量がすくなくなってきたときにつかうなにか。
  • Dnode
    • すべてのデータはこれからポインタトされる。512バイト。
    • おしりのボーナス領域にタイプごとのデータがはいる。できるだけ固定長で。
  • Metadnode
    • dnodeからdode_phys_tがポイントされる。
• ZAP
  • zfs attribute processor
  • micro-zapとfat-zap
  • ディレクトリのような名前とポインタだけのようなものはmicro-zapをつかう。
  • linked-list
• Intent Log
  • linked-list
• ZVOLの方がVirtualBoxとか速くなる。
• ちいさなトランザクションをグループにまとめる。QUIESCINGでどこに書くか決めてチェックサム計算。
• OPEN→QUIESCING→QUIESCED→SYNCING→SYNCED
• キュージング
• 128KBを連続で確保できないときにギャングでブロックポインタで小さなブロックを複数指して、論理的には1つにみせる仕掛。

ショートセッション「ZFSのソースコードをチラ見してみる」（@ko1kun）

[2011-10-15 17:42]

• http://www.ustream.tv/recorded/17887575
• http://www.slideshare.net/ko1kun/zfs-9717655
• タイポ: succssfulとか。
• ウィット: plow on. do itやtry itよりも度力が必要なニュアンスがある。I guess I link to go overbroad. あまりなかった。
• 気になるコード片: continueをつかっている! 四半世紀前からCをつかっているが。 最後のcase:やdefault:にbreakがある。breakをつけるとnop命令が入った! x86は可変長のjumpなのでリンカのためにlong call用の場所がとってある可能性。sparcならdelay slotかも。
• pythonをつかっている。execv(python, argv-1);
• 配列長を sizeof a / sizeof a[0] で計算している。
• ZFSは保守的に書いてある。あまり関数ポインタとかビット操作とかつかっていない。

[2011-10-15 17:56]

パネルディスカッション「激突！ZFSを使うなら、なんのOS？」(司会： @kohju)

[2011-10-15 17:58]

• http://www.ustream.tv/recorded/17887740

メリット

• linux: ドライバがそろってる。ふだんつかってる。
• freebsd: ソースコードの最新版をとってこれる。ライセンスはBSDでかんたん。BSDにはインストールが簡単なアプライアンスがある。(linuxにはみあたらない)
• solaris: 最新のZFSがつかえる。でもどれをつかうか? solaris11の方がSMBがらく。sambaより設定が簡単。aclがあるのでufsにコピーできない問題がある。ftpで。
• solaris: comstarとかInfinibandとか連携できるのがメリット。I/Oまわりとの連携があるので性能面でのメリット。オリジナル有利!
• 長いことZFSの最新コードがでてこないが、独自パッチ(バグもいっぱいみつかってるし)はどうなってる?
  • illumosは元sunの人がはいっている。
  • linuxはあまりいじりたくないようだ。
  • freebsdはマニュアルをかきかえてないのでsharenfsとかあってない。本体はいじってない。sun->oracleでバグDBをおいかけられなくなって、みんながバラバラにいじりだした。まるごともってきても動くようにしている。

デメリット

• open indianaはバイナリコンパチをめざいしているのでsolaris本家にひきづられる。
• linuxはcomstarとかない。
• freebsdはnfsまわりは弱い。freebsdもzfsも悪くないんだけど組み合せると...
• solarisはハードウェアサポートがよわい。インストーラが動かないとか、いきなりハングアップとか。CPUとかSASのカードとか。

純正CIFSだと右クリックで以前のバージョンがでてくる。

[2011-10-15 18:47]

帰りはシリアルバーをくって電車で爆睡。

zfs diffがはいったのをすっかりわすれてたので、あわててためしてみた。

とりあえずつかいかたをみる

% zfs diff
must provide at least one snapshot name
usage:
        diff [-FHt] <snapshot> [snapshot|filesystem]

For the property list, run: zfs set|get

For the delegated permission list, run: zfs allow|unallow

スナップショットは1つは指定しないとだめってことか。

usageの最後にpropertyとpermissionの記述がくっついてるのを不思議におもったが、/usr/src/cddl/contrib/opensolaris/cmd/zfs/zfs_main.c:usage()をみたら、とりあえず全部のヘルプにくっつけてるんだな。これまで気にしてなかった。

とりあえず動かしてみる。

% zfs diff tank/home/koie
Badly formed snapshot name tank/home/koie: missing '@' delimiter in snapshot name

おっとファイルシステムを指定したら文句をいわれた。ちゃんとusageよめよ>俺

% zfs diff tank/home/koie@__hour-01
The diff delegated permission is needed in order
to create a just-in-time snapshot for diffing
: unable to generate diffs

1引数だと/usr/src/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_diff.c:make_temp_snapshot()でスナップショットをとるみたいだ。ライブファイルシステムとスナップショットのdiffはスナップショット間のdiffにおとしこまれるようだ。スナップショットの作成コストが軽いからできるワザだな。それにしてもエラーメッセージの最後の行がくさっとる。

ちなみにzfs diff中にzfs list -t snapshot -r tank/home/koieしてみたら tank/home/koie@zfs-diff-55659-000000009f26d0d5 というスナップショットが作られてた。ソースコードをみると最初の数字はPIDなのはわかったが、後の方はわからんかった。

% zfs diff tank/home/koie@__hour-01 tank/home/koie@_hour-02
Unable to obtain diffs: そのようなファイルまたはディレクトリはありません

第2引数をタイポしたら不親切なメッセージがでた。

うちなおし。

% zfs diff tank/home/koie@__hour-01 tank/home/koie@__hour-02
Unable to obtain diffs:
   The sys_mount privilege or diff delegated permission is needed
   to execute the diff ioctl

特権が必要なようだ。あるいはzfs allowで許可しておくかどちらか。

% sudo zfs diff tank/home/koie@__hour-01 tank/home/koie@__hour-02
Password:
M       /home/koie/
M       /home/koie/Mail
M       /home/koie/Mail/trash/.mew-mtime
 ...
-       /home/koie/MailDB/id.db
-       /home/koie/.recentf.~2197~
 ...
R       /home/koie/.recentf -> /home/koie/.recentf.~2198~
+       /home/koie/MailDB/id.db
 ...
+       /home/koie/.recentf
 ...

libzfs_diff.cをみると先頭の文字は以下のようになっている:

ファイルシステムレベルでおいかけてるから、MODIFIEDなのかREMOVED+ADDなのかを区別できているな。ファイルを書き換えたなら"M"、一旦unlinkしてから作り直したら"-"と"+"がでる。上の例でいうとid.dbがそう。

man zfsしてもzfs diffの記述がまだないので/usr/src/cddl/contrib/opensolaris/cmd/zfs/zfs_main.c:zfs_do_diff()をみると、オプションはこうなってた:

ファイルタイプは以下のとおり

引数の1番目は "@〜" と書けるようだ。そのときは2番目の引数は必須で、つかいかたはたぶんこんなかんじ:

% sudo zfs diff @__hour-14 tank/home/koie

べんりじゃな。libzfs_diff.c:get_snapshot_names()をみると、そのほかにもいろいろなバリエーションがあるようだ:

        /*
         * Can accept
         *    dataset@snap1
         *    dataset@snap1 dataset@snap2
         *    dataset@snap1 @snap2
         *    dataset@snap1 dataset
         *    @snap1 dataset@snap2
         */

そんなところでおしまい。

zfs send -DというのがあるのでFreeBSDであそんでみた。

まずはファイルシステムをつくってdedupが効きそうなファイルを5つ作る。

# zfs create tank/test
# cd /tank/test
# dd if=/dev/urandom of=file1 bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes transferred in 2.452660 secs (42752602 bytes/sec)
# ls -l file1
-rw-r--r--  1 root  wheel  104857600  6月 14 23:51 file1
# cp file1 file2
# cp file1 file3
# cp file1 file4
# cp file1 file5
# df -h /tank/test
Filesystem    Size    Used   Avail Capacity  Mounted on
tank/test     640G    499M    639G     0%    /tank/test

※tank/testはdedup=off

スナップショットをつくってファイルシステムイメージ(full stream)をとる。

# zfs snapshot tank/test@freeze
# zfs send tank/test@freeze >/tmp/tank-test-freeze.zfs
# zfs send -D tank/test@freeze >/tmp/tank-test-freeze.ddzfs
# ls -l /tmp/tank-test-freeze*zfs
-rw-r--r--  1 root  wheel  106120104  6月 14 23:55 /tmp/tank-test-freeze.ddzfs
-rw-r--r--  1 root  wheel  525550504  6月 14 23:55 /tmp/tank-test-freeze.zfs

zfs send -Dで作成するとdedupが効いて1/5になっているのがわかる。

受け側のファイルシステムをつくってファイルシステムを複製する。

# zpool create pool /dev/ada1s4 /dev/ada2s4 /dev/ada3s4
# zpool list pool
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
pool  29.2G  81.5K  29.2G     0%  1.00x  ONLINE  -
# zfs receive pool/test </tmp/tank-test-freeze.ddzfs
# zpool list pool
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
pool  29.2G   501M  28.8G     1%  1.00x  ONLINE  -

dedupが効いたストリームをreceiveしただけではdedupが効かないようだ。

明示的にdedup=onにしてファイルシステムをつくって複製するとOKだった。

# zfs destroy -r pool/test
# zfs create -o dedup=on pool/test
# zfs receive -F pool/test </tmp/tank-test-freeze.ddzfs
# zpool list pool
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
pool  29.2G   101M  29.2G     0%  5.00x  ONLINE  -
# zfs send pool/test@freeze >/tmp/pool-test-freeze.zfs
# ls -l /tmp/pool-test-freeze.zfs
-rw-r--r--  1 root  wheel  525550504  6月 15 00:51 /tmp/pool-test-freeze.zfs

dedupが効いているファイルシステムのイメージをとってもdedupが効いたストリームにはならないようだ。

というわけでファイルシステムのdedupとストリームのdedupはまったく別物のようだ。

zfs send -Dでdedupしなくても圧縮プログラムがうまいことやってくれるかもとおもって試してみたが、まったく圧縮されなかった(ファイルの繰り返しの周期が1MiBなのが原因かな)。

% gzip <tank-test-freeze.zfs >tank-test-freeze.zfs.gz
% xz <tank-test-freeze.zfs >tank-test-freeze.zfs.xz
% ls -l tank-test*
-rw-r--r--  1 root  wheel  525550504  6月 15 00:50 tank-test-freeze.zfs
-rw-r--r--  1 koie  wheel  524886344  6月 15 23:52 tank-test-freeze.zfs.gz
-rw-r--r--  1 koie  wheel  525564756  6月 16 00:01 tank-test-freeze.zfs.xz
%