28歳の誕生日となりましたので今日からサバンナに行ってきます。せっかくだから「お前それサバンナでも同じ事言えんの？」ってことを言ってこようと思います
ほしいものリストからなにかぽちってくれるとサバンナから生還した暁に喜びます。では
http://www.amazon.co.jp/registry/wishlist/1L7MBLZGS6AA/ref=cm_sw_r_tw_ws_x_k9XfybK6A8KPC
寄席に行った
先日寄席に行った。通算3回目。浅草演芸ホールは今回初めて
一応、お目当ては神田松之丞さん。渋谷らくごで一度見てあっというまに覚えてしまった。講談というとどうにも固くよくわからない昔のことを語ってはい〜いところでぶつりと切ってしまうというイメージがあったがそれを一変させてくれた。ほんと毎回よいんですな・・・。ぜひ独演会などにも行ってみたい。
今回は講談あるあるネタ?をマクラに江戸時代の剣術名人のお話. いつも通り大変におもしろかった……
今回は昼の部全部いるつもりだったので、お弁当を買った。寄席の外にもドンキやらお弁当屋さんがあるし、中でもお弁当を売っている。外のお弁当屋さんは安い&かなりヘビーな感じだった。今回は中でお弁当を購入。助六寿司
適当に印象に残った方を紹介
最初は神田 みのりさんの講談からだった。宮本武蔵の話
鯉ん(こいん)さん、名前のインパクトで完全に覚えてしまった
古今亭 寿輔師匠. 「小言念仏」がほんっとおもしろかった。 「小言念仏」自体は以前別の人で聞いたことがあったのだが、その時はまあいまいちで。人による違いを実感できた。
鏡味 味千代さんの太神楽。
五階茶碗という芸で、こんな感じで茶碗をのせた台を棒やら鞠やらでささえていく芸。単純に見てわかってすごい。なかでも、この画像の鞠のところに扇子をはさんで、手をつかわずにとりだす(身体を横にふって扇子を落とす)のに驚いた。
他にもよくある桝を傘でまわすやつなど、初めて生で見てよいものであった。
この方、おもしろいな〜と思ってふとぐぐってみると、トリリンガルだったり、元OLで30歳でこの道に入っていたりとおもしろい経歴の方でした。
東京太・ゆめ子さんの仲のいいw夫婦漫才。夫婦漫才ってなぜこんなに安定してるんですかね・・・。
P.S. 落語芸術協会さんは画像をmetaにいれておくと上の方のインラインがいい感じになると思います
今週読んだ本 (9/11-9/17)
今週は本を4つ、コミックを33読み終わっていた。
開発現場のストレスを減らすアサーティブ会話術 キッチリ上達する7日間講座 (エンジニア道場)
- 作者: 吉田珠江
- 出版社/メーカー: 翔泳社
- 発売日: 2008/08/05
- メディア: 単行本（ソフトカバー）
- 購入: 2人 クリック: 21回
- この商品を含むブログ (4件) を見る
こんなふうに話していくと楽なのかなと学べてよかったですね。実践したいところだ。
やっぱり変な漫画だった。サイコー。まだ2巻ないようなので続きに期待している。
主人公の能力が結構おもしろくってこれからに期待している。楽しみ。
舞台が変わってしまったがどうなるのやら。アクション性が上がった気がして, それはよい
にこやかだけどなにか違和感のある心臓を掴んでくるようなプレッシャーのある顔の父親がこわかった。ビジネスのような顔で家族に語りかけてくる. 見ていて違和感をかきたてられるいやな顔. みなさんのバックグラウンドが少しずつ出てきて楽しみですな
ソフィーの世界は何度か読んでるのだけど、いつも分かったような分からんような気持ちになって終わる。ところが、いまのところは大体分かったような気になっていて、これは多分下巻でわけわからなくなるフラグなんだな
昔、これ大丈夫だったんだなあ・・・
この巻、映画を見にいくってやつがあって最近のシンゴジラとからめて読むとめっちゃおもしろい感じになる.
ろくろ首なだけのラブコメかと思ってたけどだんだん背景が出てきた? ちょいと気になるあたりで終わってしまった
いやー, ついに清算しちまいましたね. どうするのかな. どうなるのかな.
最後、おま・・・おまえーっ!って感じだったけどいっきに特別感が出てきた。よかったぞ。
人殺してくだけかと思っていたら, いつのまにかキャラ立った人増えてきましたね. 変人殺人者バトルみたいな感じになってきていいぞ
昔最初だけ読んでてどうなったのかと思ってまたいま読んでたが…最後なあ…演説バトルになってしまってどうも…. 昔そのまま読んでたらまだよかったかな.
最近のタイムトラベルは展開がはやい!みたいな感じになってる. ところどころ演出が昔っぽいのはこれは…なんでなんだ?
わ・・・わかいー・・・って感じでした・・・・。 ういういしさではなく, わかい〜な感じの出来事が高速で起きていくのでちょっとわたしにはきつい…. イベントがおこりすぎて, いまいち余韻が…
![ソフトウェアデザイン 2016年 09 月号 [雑誌]](http://ecx.images-amazon.com/images/I/51X21-QBTNL._SL160_.jpg "ソフトウェアデザイン 2016年 09 月号 [雑誌]")
魔人探偵脳噛ネウロ モノクロ版 10 (ジャンプコミックスDIGITAL)
- 作者: 松井優征
- 出版社/メーカー: 集英社
- 発売日: 2012/10/12
- メディア: Kindle版
- クリック: 1回
- この商品を含むブログを見る
今週読んだ本 (9/3-9/10)
Kindle Unlimitedにあったので.
Kindle Unlimitedから. stop ひばりくん好きなので読んでみてるけどまあぼちぼち。
TSUTAYAレンタル. 紅の新刊読む前にコミック読んでおくかと思って。人々がかわいくてすごい。
TSUTAYAレンタル. はれグウ好きだったな〜と読んでみたらめっちゃはまってる。主人公が嘘ついて泥沼になっていくんだけど、その沼いところがおもしろい。金田一氏のラブコメは変な設定で沼ですんげーおもしろい
TSUTAYAレンタル。 大正ロマン。由貴香織里氏というとどうもゴシックというか西洋な感じだったけど大正か〜と思ってたらやっぱり西洋か!そんな感じ
TSUTAYAレンタル。なんで読んだのか忘れたけど、これはおもしろい。よい恋〜という感じで先が気になります。
TSUTAYAレンタルx3。新宿スワン, だんだん人の名前がわからなくなってきて「あんたは!」みたいなシーンに「えっだれこの人…」ってなっていてきびしい.
図書館. Inter Sexualの話。まあ基本的につらさがほんのりとあるのだけど、そこを受けとめた上ではっぴーなのでなかなか好き。
Kindle UnlimitedからSF.
TSUTAYAレンタル. 読んでくとビートルズの時代感ってのがわかってくるのかな〜と思って読んでる. まあ続きは読みたい感じ
レンタル。きびしい気持ちになる
レンタル。近年ぶっとんででわらえる黒執事だけどこの巻ひさしぶりによいおもしろさだったように感じた。
Kindle? 金田一蓮十郎氏の変な設定ラブコメその2. いやあほんとサイコーですわ
レンタル。工具おもしろいですね。よい
レンタル。わりとちゃんと恋愛もの・・・なのか? ちょっと沼が見えてきたのでこれからに期待
レンタル。満州あたりの話を読みたいな〜と思って読んでる。なかなかおもしろいぞ。この巻じゃないけど、対談とかがいい
図書館。Monster、なんどか読んでるんだけどいつも途中でわかんなくなんですよ〜ってことでまた読んでる。いまのところわかっててすごい
魔女系?タカハシマコ短編集? (アクションコミックス（コミックハイ！）)
- 作者: タカハシマコ
- 出版社/メーカー: 双葉社
- 発売日: 2011/12/12
- メディア: コミック
- 購入: 2人 クリック: 15回
- この商品を含むブログ (8件) を見る
レンタル。「それは私と少女は言った」が大変よかったのでタカハシマコ作品もっと読んでみよう!ということで読んでいる。結果大当たりですね。どんどん読んでいきたい
図書館。おいしい関係、本当にいい!!この本のせいでこのエントリを書くことになっている! 7あたりから関係が大きく動きはじめてどんどんと壁にぶつかっていく、その中でプロとはなにかといったものにむきあっているのがとてもよい。心にじくじく来る作品になっている。そんな中で主人公の恋愛スタンスも変化してほんとうに恋とはよいものだと思わせてくれる。
このコマがね、好き
おいしい関係9, このコマが良いすぎて激エモおいしい関係紹介記事書きたくなってる pic.twitter.com/qplH7tB1fZ
— としぁ (@naota344) 2016年9月7日
このシーンは、これまで気持ちが先行していたけどあまり料理人としてはできていなかった主人公がプロとして高いレベルの料理人を目指していく決意のシーンなんですよね。
あとこれ
私の結婚観はねどんどん変化して変わらない関係。 自分のこと見てても他人のこと見てても「これは絶対 変わらない!」なんて思ってたってどんどん変化していくんだ人間って。 へこんだりふくらんだり外へとび出したり破裂したり。 どんなに自分が変化しても変わらない夢。 変わらない好き。 そういう所が一緒の人とくっついたり離れたりしてつきあっていくの そーゆーのがいい!
このセリフのあたりは恋愛模様的にサイコー. 主人公と織田さん(主人公の好きな人)がご飯を食べているのだが, このへんで「2人の世界」に入りこみ, 普段ぶっきらぼうな織田さんがいろんな表情を見せてくれる. セリフが全くなく表情が続くのだが, それが主人公の期待感を感じさせてとてもよい. 相手の言葉を待って相手の顔を見ていろんな顔にいろんな気持ちを感じとってしまう時間が見える.
……そして答えが出ないまま, 急にふっとフォーカスアウトして「2人の世界」から元のレストランに戻ってしまう. その時のざわざわという音の書きこみが, あっ戻ってきたんだなというのを感じさせてよいシーンだった.
おいしい関係 9巻, 恋愛模様も仕事模様も抜群によいシーンが続く. そしてまだまだこの先にも期待が持てる展開, 続きが楽しみになる.
＜関ヶ原合戦＞迫る決戦 戦略・戦術上の謎 (歴史群像デジタルアーカイブス)
- 作者: 桐野作人
- 出版社/メーカー: 学研プラス
- 発売日: 2014/09/26
- メディア: Kindle版
- この商品を含むブログを見る
Kindle. 短いが値段相応. この分野くわしくないので内容評価はできないけれど、まあおもしろかった。
Kindle Unlimited, イチのさらに後みたいな。まあ・・・殺し屋1が好きな人がサブストーリー的に楽しむ感じの
Surface Bookを買ったのでWindowsで暮らしていくぞ！
Surface Bookを買ったのでしばらくWindows生活でもしてみようかと思っています。
ということで、現況のWindows状態のメモエントリ。Windowsを自分のPCとして使うのはXP以来ぐらいなのでなんかいろいろ変わってて面白いような、昔使ってたものがするっと動いていてすごいようなそんな気持ち。
インストールしたもの
- Atom: エディタ。NTEmacsと迷ってせっかくだからトライしてみるかとトライしている
- flux: 夕方になると画面が赤くなるやつ。寝やすい(気がする)
- Dynaファイラー: 昔々に使ってたやつ。いま見るといろいろプラグインいれなきゃいけなくて大変だ。操作思い出してなくて、あんまり使ってない。
- Executor: ランチャー。いろいろ登録していかないといまひとつほしいものが起動できない気がしている。
- Launchyというのも試したがHigh-DPI環境では小さくてだめだった
- Flantter: Twitterクライアント。なにがいいのかよくわからんのでストアにあったこれを使っている。だいたいいい感じがする。
- Github Desktop: 試しにこれだけで操作できるかやってるが…うーん
- MobaXterm: どのターミナルがよいのやらいくつか見て結局これにした。
- Google日本語入力: mozcより賢いっぽい気がする。でも、マルチモニタ&High-DPIの扱いがよくない。
- Nozbe: TODOリスト。ElectronなのでLinuxと変わらない。
- Slack: これもElectronなので変わらない。
- Google Chrome: ほんとなんも変わらない
- BashOnWindows: 結局ほとんど触ってない。コマンド使うようなことはSSHつなげてLinuxでするしな…。
- MigMix: 快適な生活のためにフォントをいれた。いつもの感じになってよかった。
Atom
プラグインいくつかいれていじってみてる。Markdownのプレビューが好き。 - vim-mode-plus - git-plus - hatena-blog-and-fotolife
現状テーマが少し暗くて文字が見にくい気がするのでなんかテーマ見つくろいたい。本格的なコーディングはしていないからそのへんの力量はわかっていないが、どうせLinuxまわりでしかコーディングはしないのでSSHでつないだVimでやるので関係なさそう。
言語設定
最初は英語に設定してたんだけど、SlackとかNozbeが中華フォントになって辛かったので日本語にした
VPN
ネットワーク一覧みたいなとこからプロパティを開いてPAPを有効にするをやればL2TPがするっとつながった。LinuxもするするL2TPつながってほしい。
Actionセンターに通知をいれていると、すぐに通知が止まりだすのでActionセンターには入れないようにしよう。
ターミナル
Inconsoleta for Powerlineのフォントをいれたら、SSH先のPowerlineもわりかし見えてていい感じになった。
端末いい感じになってきた pic.twitter.com/VZuNg10Vhm
— 夏のファイルシステム大三角△ (@naota344) 2016年8月20日
仮想デスクトップ
Linuxデスクトップのアレみたいでべんり。あとなんかよくわかんないけど、twitterアプリと違うデスクトップにいたら通知が来ていない気がする。誰のせいかはわからないけど、集中にはよさそう。
できれば仮想デスクトップの切り替えをWin+数字でやりたい。Win+1で仮想デスクトップ1、Win+2で仮想デスクトップ2みたいな。AutoHotKeyとDLL入れればできそうに見えるが…さて…。このへん簡単にいじれないのはあまり好きじゃない。
その他
- HHKBが乗せやすい
- わりとすんなり乗ってくれる。ケーブルがモニタにあたるとタッチ認識されたりするので注意。
- Google日本語入力がバグるのでマルチモニタはびみょう
- 外部モニタとメインモニタで拡大率が違う場合に外部モニタで入力していると、変換候補の表示がずれたり、メインモニタ側で表示されたりする
- つまりHigh-DPIな外部モニタを買えばバグが解決するぞ!!!!(ぐるぐるぐる)
- focus-fllow-mouseの設定あるじゃんと思ったらWindowが上に上がってきてほんと使いにくい。レジストリをいじることで解決した。相変わらずレジストリが必要な子だった。
ペンはよくわからん。イラストとか描く人ならいいのかな。
現況、Linuxデスクトップ(i3wm)に比べてふべんを感じていない。まあタイル型でも左右二分割できればだいたいいいものね。不便さに関してはこれからどの程度コマンドを使いたくなるか、ターミナルの感じはどうかが勝負だと思う。あとは
これが圧倒的べんり～と感じたのはWindows Hello以外では特にない。だいたい同じアプリケーションを使っているのでそんなもんかもしれない。T-Code環境はあまりよくないけど、まあGoogle日本語入力のテーブル変換で我慢。
ファイルシステムソムリエになる話
利きファイルシステムができるのかという話を見かけたので、できそうだなと思って書いたやつです。
「ここに何かのファイルシステムがあります。ファイル操作を行って、どのファイルシステムか当ててください。なおディスクイメージを見ることはできません。」という問題を解く方法について考えます。
ぱっと思いつく方法はこれでしょうからやっていきます
ディレクトリのなかにファイル作っていってinode番号見ればbtrfsとext4とXFSは区別できる気がしますね
— シャルロット・びーる尽き太郎の憂鬱 (@naota344) 2016年6月15日
以下のスクリプトを走らせます。512GBで各FSのイメージ作って、ディレクトリをいくつか掘ってinode番号を表示させるだけです。
#!/bin/sh FS="btrfs ext4 xfs" DIR=/mnt/test for f in $FS; do echo ${f} truncate -s 512G ${f}.img && mkfs.${f} ${f}.img >/dev/null && mount ${f}.img ${DIR} && mkdir -p ${DIR}/{0,1}/{0,1,2,3} && ls -ldi ${DIR}/{0,1}/{,0,1,2,3} && umount /mnt/test && rm ${f}.img done
結果はこんな感じ:
btrfs
257 drwxr-xr-x 1 root root 8 Jun 16 23:36 /mnt/test/0/
258 drwxr-xr-x 1 root root 0 Jun 16 23:36 /mnt/test/0/0
259 drwxr-xr-x 1 root root 0 Jun 16 23:36 /mnt/test/0/1
260 drwxr-xr-x 1 root root 0 Jun 16 23:36 /mnt/test/0/2
261 drwxr-xr-x 1 root root 0 Jun 16 23:36 /mnt/test/0/3
262 drwxr-xr-x 1 root root 8 Jun 16 23:36 /mnt/test/1/
263 drwxr-xr-x 1 root root 0 Jun 16 23:36 /mnt/test/1/0
264 drwxr-xr-x 1 root root 0 Jun 16 23:36 /mnt/test/1/1
265 drwxr-xr-x 1 root root 0 Jun 16 23:36 /mnt/test/1/2
266 drwxr-xr-x 1 root root 0 Jun 16 23:36 /mnt/test/1/3
ext4
mke2fs 1.42.13 (17-May-2015)
2097153 drwxr-xr-x 6 root root 4096 Jun 16 23:56 /mnt/test/0/
2097154 drwxr-xr-x 2 root root 4096 Jun 16 23:56 /mnt/test/0/0
2097155 drwxr-xr-x 2 root root 4096 Jun 16 23:56 /mnt/test/0/1
2097156 drwxr-xr-x 2 root root 4096 Jun 16 23:56 /mnt/test/0/2
2097157 drwxr-xr-x 2 root root 4096 Jun 16 23:56 /mnt/test/0/3
7077889 drwxr-xr-x 6 root root 4096 Jun 16 23:56 /mnt/test/1/
7077890 drwxr-xr-x 2 root root 4096 Jun 16 23:56 /mnt/test/1/0
7077891 drwxr-xr-x 2 root root 4096 Jun 16 23:56 /mnt/test/1/1
7077892 drwxr-xr-x 2 root root 4096 Jun 16 23:56 /mnt/test/1/2
7077893 drwxr-xr-x 2 root root 4096 Jun 16 23:56 /mnt/test/1/3
xfs
99 drwxr-xr-x 6 root root 42 Jun 16 23:36 /mnt/test/0/
268435552 drwxr-xr-x 2 root root 6 Jun 16 23:36 /mnt/test/0/0
537395296 drwxr-xr-x 2 root root 6 Jun 16 23:36 /mnt/test/0/1
805306464 drwxr-xr-x 2 root root 6 Jun 16 23:36 /mnt/test/0/2
100 drwxr-xr-x 2 root root 6 Jun 16 23:36 /mnt/test/0/3
268435553 drwxr-xr-x 6 root root 42 Jun 16 23:36 /mnt/test/1/
537395297 drwxr-xr-x 2 root root 6 Jun 16 23:36 /mnt/test/1/0
805306465 drwxr-xr-x 2 root root 6 Jun 16 23:36 /mnt/test/1/1
101 drwxr-xr-x 2 root root 6 Jun 16 23:36 /mnt/test/1/2
268435554 drwxr-xr-x 2 root root 6 Jun 16 23:36 /mnt/test/1/3わかりやすいですね。 btrfsはinode番号がシーケンシャルに増えていきます。ext4とXFSではinode番号が飛んでいます。ext4とXFSで比べるとext4では同じディレクトリ内のファイル(0/{,0,1,2,3}の組および1/{,0,1,2,3})はinode番号が固まっています。一方、XFSでは同一ディレクトリ内のファイルでもinode番号が飛んでいます。
こうしたinode番号のallocのされ方の違いは各FSのレイアウト・allocation policyに起因しています。詳しく見ていきましょう。
Ext4
Ext4はファイルシステム内部がBlock Group(BG)という領域に分割されています。各BGは空きブロックの数・空きinodeの数・どのinodeが空いているのかを示すbitmapを持ちます。inodeのallocateはどこかのBGから行われます。
たとえば今回の結果だと、"0/*"がBG#256から、"1/*"がBG#864からallocされていることがわかります。"Group 256"の"Free inodes"が"2097158-"と"0/3"の次のinode番号になり、同様に"Group 864"でも"Free inodes"が"1/3"の次である"7077894-"となっています。
# dumpe2fs ext4.img … Group 256: (Blocks 8388608-8421375) [ITABLE_ZEROED] Checksum 0xb0b5, unused inodes 8187 Block bitmap at 8388608 (+0), Inode bitmap at 8388624 (+16) Inode table at 8388640-8389151 (+32) 24539 free blocks, 8187 free inodes, 5 directories, 8187 unused inodes Free blocks: 8396837-8421375 Free inodes: 2097158-2105344 … Group 864: (Blocks 28311552-28344319) [ITABLE_ZEROED] Checksum 0xf815, unused inodes 8187 Block bitmap at 28311552 (+0), Inode bitmap at 28311568 (+16) Inode table at 28311584-28312095 (+32) 24539 free blocks, 8187 free inodes, 5 directories, 8187 unused inodes Free blocks: 28319781-28344319 Free inodes: 7077894-7086080
Ext4は新しいinodeを(ルート直下の場合を除いて)親ディレクトリと同じBG内にallocしようとします。、一般にディレクトリのinodeへのアクセスの後にはその中のファイルにアクセスすることが予想されます。ext4では同一BG内のinodeは固まって配置されているため、同一BGにallocすることでディレクトリinodeの読みこみがついでにその中のファイルのinodeの読みこみもやってくれる可能性が高まります。おそらくこの効果による速度向上を狙ったinode allocation policyなのでしょう。まとめるとext4は"locality"を重視したallocationを行っているわけです。
XFS
XFSでもExt4のBGと同様にファイルシステムの内部をAllocation Groupという領域に分割しています。ただし、Ext4では上記のように800以上にも分割されていましたが、XFSでは多くの場合(FSが128MBから4TBの間なら)、4つのAGに分割されるだけです。
そう思ってよくよくXFSのinode番号の結果を見てみると、4つごとにinode番号のだいたいの大きさがそろっていますね。それぞれAG#0-AG#3にallocationされているというわけです。
せっかくなので、こっちもallocationされている様子を見ておきましょう。まず、AG#0の情報をdumpします。
# xfs_db xfs.img xfs_db> agi 0 xfs_db> p magicnum = 0x58414749 versionnum = 1 seqno = 0 length = 33554432 count = 64 root = 3 level = 1 freecount = 58 newino = 96 dirino = null unlinked[0-63] = uuid = 3dd1af10-10f6-45dc-b466-c10a727d9842 lsn = 0x100000002 crc = 0x7df3830f (correct) free_root = 4 free_level = 1
ここの"root"がこのAGでinodeを管理しているB+treeのrootがあるブロックです。該当部分をinodeのB+treeとしてdumpします。
xfs_db> fsblock 3 xfs_db> type inobt xfs_db> p magic = 0x49414233 level = 0 numrecs = 1 leftsib = null rightsib = null bno = 24 lsn = 0x100000002 uuid = 3dd1af10-10f6-45dc-b466-c10a727d9842 owner = 0 crc = 0x1b9f870b (correct) recs[1] = [startino,freecount,free] 1:[96,58,0xffffffffffffffc0]
"[startino,freecount,free] 1:[96,58,0xffffffffffffffc0]" がinode管理情報です。XFSではinodeは64個の塊で動的にallocされていきます。このエントリはinode番号96から64個分のinodeについて管理しています。"freecount"が58なので64-58=6個のinodeが使用されており、どこが空いているのかは"free" bitmapを見ることでわかります。実際96-101に相当する下位6bitが0で残りが1になっていることが見てとれます。
同様にAG#1のinode B+treeも見てみると…。(agi 1+addrでAG#1のoffsetを確認し、そこに3足したところがAG#1のinode B+tree root)
xfs_db> agi 1
xfs_db> addr
current
byte offset 137438954496, length 512
buffer block 268435458 (fsbno 33554432), 1 bb
inode -1, dir inode -1, type agi
xfs_db> fsblock 33554435
xfs_db> type inobt
xfs_db> p
magic = 0x49414233
level = 0
numrecs = 1
leftsib = null
rightsib = null
bno = 268435480
lsn = 0x100000002
uuid = 3dd1af10-10f6-45dc-b466-c10a727d9842
owner = 1
crc = 0x687eec0e (correct)
recs[1] = [startino,freecount,free] 1:[96,61,0xfffffffffffffff8]こちらもinode番号96から、となっていますね。ここに記録される96というのはAG内localのinode番号でFSでのinode番号にするには上位bit領域にAGの番号を入れる必要があります。そう思って"0/0"のinode番号を見ると"268435552"というのは"0x10000060"というわけで"0x60=96"と"0x1"=AGの番号が見てとれます。
さてXFSのinode allocation policyの話に行きましょう。XFSではディレクトリの場合、FS全体でラウンドロビンにAGを(優先して)選択していきます。そのため最初の実験結果のようにディレクトリごとにAGが変わっていっているわけですね。一方でファイルであればディレクトリと同じAGを優先するので、さきほどのスクリプトをディレクトリ0,1以下はファイルを作るようにするとこうなります。
xfs
96 drwxr-xr-x 4 root root 24 Jun 17 01:18 /mnt/test
99 drwxr-xr-x 2 root root 42 Jun 17 01:18 /mnt/test/0/
100 -rw-r--r-- 1 root root 0 Jun 17 01:18 /mnt/test/0/0
101 -rw-r--r-- 1 root root 0 Jun 17 01:18 /mnt/test/0/1
102 -rw-r--r-- 1 root root 0 Jun 17 01:18 /mnt/test/0/2
103 -rw-r--r-- 1 root root 0 Jun 17 01:18 /mnt/test/0/3
268435552 drwxr-xr-x 2 root root 42 Jun 17 01:18 /mnt/test/1/
268435553 -rw-r--r-- 1 root root 0 Jun 17 01:18 /mnt/test/1/0
268435554 -rw-r--r-- 1 root root 0 Jun 17 01:18 /mnt/test/1/1
268435555 -rw-r--r-- 1 root root 0 Jun 17 01:18 /mnt/test/1/2
268435556 -rw-r--r-- 1 root root 0 Jun 17 01:18 /mnt/test/1/3ディレクトリをFS全体でラウンドロビンに配置していくことで、個々のディレクトリ内の操作はAGが異なれば独立して進めることができ、scalabiltyが向上しています。このようにXFSでは"scalability"を意識したallocation policyが使われています。
Btrfs
Btrfsでは、ディレクトリとファイルとの親子関係・inodeデータ・ファイルのデータ位置情報が全て「ファイルシステムツリー」(FS tree)と呼ばれるB-treeで管理されます。また、Btrfsにおいては「どこのinodeが空いているか」を管理するまとまった情報(ext4やXFSのbitmapみたいな)は(デフォルトでは)存在しません。treeの中でファイル削除などで空いてしまったinode番号を発見する最速の方法はFS treeを全部scanすることです。前述の通り、FS treeには様々な情報が載っているのでこれをなめていくのはかなりの時間がかかります。ということで、Btrfsではこれまでにallocした最大のinode番号を覚えておいて、これまでに割り当てたことのないinode番号を割り当てるというallocation policyをとっています。そのため、最初の結果のようにシーケンシャルになっています。なんですかね、"simple"なallocation policyとでも言っておくといいんでしょうか。
(Btrfsはext4, XFSみたいにFS領域分割しないのかというのがありますが、一応chunkという単位に分かれています。ただ、localityやscalabilityのためでは(多分)なく管理しやすさぐらい…。localityなんてやろうとしてもどうせCoW FSだからそのうち崩壊するだろうし、デフォルトでinode番号管理構造ないからallocするinode番号を開けていくようにするのはうまくいかないし…。inode_cacheを仮定してallocするinode番号を変えるなどするのはおもしろいのかもしれないが…もう2時なのでもうこんな感じで)
まとめ
それぞれのFSがBtrfsはsimple, Ext4はlocality, XFSはscalabilityと違ったinode allocation policyを取っています。そのおかげであなたも明日からファイルシステムソムリエです。おめでとうございます。
補則
今回は作りたてのFSだったけれど、じゃあ、ある程度使われたFSだとどうなるってことなんですが、inode_cacheなしのbtrfsだとやはりシーケンシャルに当たるのでわかりやすい。ext4とXFSではinodeの空き方によって複雑になる気がします。まあXFSの方が性質上inode番号が大きくなりがちなんでそこ見ていけばいいかなとか、inode領域が動的確保なことを利用してあるAG内のファイルにデータを書きまくる->その後にそのAG内でallocされたinode番号を見るといったことをすればいいんじゃないでしょうか。
あとbtrfs、inode割り当て一周したらどーすんのってのはちゃんとinode_cacheというmount optionでどこが空いているかのデータベース作ってそこ見てくれるようになるんで安心してください。でも64bit環境ならそうそうなくならんし普通はなくてもいいんじゃないかな。
おまけ: f2fsとnilfs2
f2fs
4 drwxr-xr-x 6 root root 4096 Jun 17 02:20 /mnt/test/0/
5 drwxr-xr-x 2 root root 4096 Jun 17 02:20 /mnt/test/0/0
6 drwxr-xr-x 2 root root 4096 Jun 17 02:20 /mnt/test/0/1
7 drwxr-xr-x 2 root root 4096 Jun 17 02:20 /mnt/test/0/2
8 drwxr-xr-x 2 root root 4096 Jun 17 02:20 /mnt/test/0/3
9 drwxr-xr-x 6 root root 4096 Jun 17 02:20 /mnt/test/1/
10 drwxr-xr-x 2 root root 4096 Jun 17 02:20 /mnt/test/1/0
11 drwxr-xr-x 2 root root 4096 Jun 17 02:20 /mnt/test/1/1
12 drwxr-xr-x 2 root root 4096 Jun 17 02:20 /mnt/test/1/2
13 drwxr-xr-x 2 root root 4096 Jun 17 02:20 /mnt/test/1/3
nilfs2
mkfs.nilfs2 (nilfs-utils 2.1.6)
Start writing file system initial data to the device
Blocksize:4096 Device:nilfs2.img Device Size:549755813888
File system initialization succeeded !!
12 drwxr-xr-x 6 root root 4096 Jun 17 02:32 /mnt/test/0/
17 drwxr-xr-x 2 root root 4096 Jun 17 02:32 /mnt/test/0/0
18 drwxr-xr-x 2 root root 4096 Jun 17 02:32 /mnt/test/0/1
19 drwxr-xr-x 2 root root 4096 Jun 17 02:32 /mnt/test/0/2
20 drwxr-xr-x 2 root root 4096 Jun 17 02:32 /mnt/test/0/3
21 drwxr-xr-x 6 root root 4096 Jun 17 02:32 /mnt/test/1/
22 drwxr-xr-x 2 root root 4096 Jun 17 02:32 /mnt/test/1/0
23 drwxr-xr-x 2 root root 4096 Jun 17 02:32 /mnt/test/1/1
24 drwxr-xr-x 2 root root 4096 Jun 17 02:32 /mnt/test/1/2
25 drwxr-xr-x 2 root root 4096 Jun 17 02:32 /mnt/test/1/3allocation policy 知らないけどどうもシーケンシャルな様子。log structuredだからそんなもんですな。Btrfsではroot inode番号256なことを使って判別すればいいかなという気がする。あとBtrfsはlink-countしないので全部"1"になってるとこでも判別できる。そうやって見ていくと、directoryのsizeのとこでもFS判別できるね。ソムリエ道は奥が深い。
というか、 root directoryのinode番号で結構わかるね(涙 (btrfs:256, ext4:2, xfs:96(設定によるが), f2fs:3, nilfs2: 2)
まだおまけ
こうなるとどうしても root inode番号見ずにf2fsとnilfs2を区別したい。ということで、0/{0,1,2,3}を作る->一度0/{0,1,2,3}を削除->sync->もう一度0/{0,1,2,3}を作るとしてみた結果
f2fs
4 drwxr-xr-x 6 root root 4096 Jun 17 02:36 /mnt/test/0/
9 drwxr-xr-x 2 root root 4096 Jun 17 02:36 /mnt/test/0/0
10 drwxr-xr-x 2 root root 4096 Jun 17 02:36 /mnt/test/0/1
11 drwxr-xr-x 2 root root 4096 Jun 17 02:36 /mnt/test/0/2
12 drwxr-xr-x 2 root root 4096 Jun 17 02:36 /mnt/test/0/3
nilfs2
mkfs.nilfs2 (nilfs-utils 2.1.6)
Start writing file system initial data to the device
Blocksize:4096 Device:nilfs2.img Device Size:549755813888
File system initialization succeeded !!
12 drwxr-xr-x 6 root root 4096 Jun 17 02:36 /mnt/test/0/
13 drwxr-xr-x 2 root root 4096 Jun 17 02:36 /mnt/test/0/0
14 drwxr-xr-x 2 root root 4096 Jun 17 02:36 /mnt/test/0/1
15 drwxr-xr-x 2 root root 4096 Jun 17 02:36 /mnt/test/0/2
16 drwxr-xr-x 2 root root 4096 Jun 17 02:36 /mnt/test/0/3inode番号がf2fsでは不連続、nilfs2では連続しているのがわかる。syncしているのがポイントでsyncしないとnilfs2でもうまく連続にはならない。
