More Related Content Similar to dm-writeboost-kernelvm Similar to dm-writeboost-kernelvm (20) 8. 元ネタの論文
Disk Caching Disk (DCD)
•
RAM Bufferにダーティデータと対応するメタ
データをログ書きして, フルになったら
Cache Diskに吐く.
•
ControllerはテーブルをDRAM上に管理して,
lookupを行う.
•
これ自体, Sprite LFS (Rosenblum, 1992)に影響
を受けて, ブロックで実現する着想
(or backing store)
•
http://www.ele.uri.edu/research/hpcl/DCD/DCD.html
Y. Hu and Q.Yang, DCD -- Disk Caching Disk: A New
Approach for Boosting I/O Performance (1995)
Sunday, December 8, 2013
当時はログ書きが熱かったらしい
9. 応用例
ブロックレベルの
ログ書き自体は新しくない
•
Griffin (MS Research, 2010)
•
バッキングとしてSSD, キャッシュとしてHDDを使い, そこで上書き
を吸収することでSSDへの書き込みを減らす.
•
Mercury (NetApp, 2011)
•
Write Through Cache. SSDに書く前にRAMでバッファリングして, ま
とめて書く.
•
bcache (Kent Overstreet)
•
ドキュメントによると, 同様にキャッシュへのログ書きをしている
らしい.
•
SMR (ベンダーが議論中)
•
Sunday, December 8, 2013
HDD内でログ構造化を行う.
11. 世はまさに
SSD Cache 戦国時代！
立身出世！オポ！オポ！
• bache (Kent, 3.9-)
• dm-cache (RedHat, 3.10-)
• dm-writeboost (おれ, 3.?-)
• FlashCache (Facebook)
• enhanceIO (sTec)
• XtremSW Cache (EMC, not OSS)
Sunday, December 8, 2013
15. ざっくりと
ディスクフォーマット
super block
segment[1]
...
segment[k]
~512KB
4KB
segment
_header Data[1] Data[2]
_device
...
Data
[127]
struct segment_header_device {
!
/* - FROM ------------------------------------ */
!
__le64 global_id;
!
__le32 lap;
!
u8 padding[512 - (8 + 4)]; /* 512B */
!
/* - TO -------------------------------------- */
!
struct metablock_device mbarr[0]; /* 16B * N */
} __packed;
struct metablock_device {
!
__le64 sector;
!
__le32 lap;
!
u8 dirty_bits;
!
u8 padding[16 - (8 + 4 + 1)]; /* 16B */
} __packed;
Sunday, December 8, 2013
...
16. 初期化
Example
# superblockを潰す
dd if=/dev/zero of=$CACHE bs=512 count=1 oflag=direct
# /dev/mapper/mydevを作る
# <type> <backing> <cache>
# <type>はRAM bufferの種類を意味する
dmsetup create mydev --table ¥
“0 $sz writeboost 0 $BACKING $CACHE”
Sunday, December 8, 2013
22. Writeに特化
Readはキャッシュしない
なぜ？ (2)
•
Readキャッシュは, 完全にワークロード依存. めんどくさいの
で付き合いたくない. 測定もwarmupが必要だったりして鬱陶
しい.
•
Writeに特化することで拓ける道があるはず. シンプルなアー
キテクチャの中でしか実現出来ないものもある.
•
WriteもReadもサポートするとなると, bcacheとどう違うの？
dm-cacheとどう違うの？うるさくなって辛い.
•
フルタイムで開発してるわけではないし, 同じ路線で行く
と勝つのは難しくなる. ニッチを攻める.
Sunday, December 8, 2013
24. 勇気を振り絞って
はじめての投稿
•
•
2013 7/16 [RFC] dm-lc target -> 無視
2013 7/28 Re: (自分で)
•
前回の投稿ではコードだけ送りつけてどやぁ？だった
ので, PDFでドキュメントを作ってupdateを報告した.
•
•
2013 7/29 Joe Thornber: This is nicely orthogonal to dmcache.
•
Sunday, December 8, 2013
これが良かった.
この評価は狙いどおり.
27. きな臭いので
キャッシュ共有やめろ (Mike Snitzer)
•
そうしていたのは, キャッシュ共有(一つのキャッシュを複数
のbacking storeが共有)のためでもあった. これも完全否定
•
device-mapperの実装上, すべてのデータ構造はctr/dtrで確
保/解放されねばならない. そうなっていないので, (理由は
不明だが)デッドロックを起こす可能性があるとのこと.
•
強烈なこだわりがあった部分ではなかったので, ユーザラン
ドツール廃止の件と一緒に一気に再設計した.
•
ここらへんの話は, 一言でいうと「DMフレームワークの限
界」. 譲歩出来るところは譲歩しておくのが吉.
Sunday, December 8, 2013
28. dm-lcは意味不明なので
名前変更せよ (Alasdair Kergon)
•
•
マージされるか不安だったのでstagingに行こうとしたことがある.
•
おれ: LC is also the name of my favorite anime character from “God only
Alasdair: Agree a new and meaningful target name with us so you don’t have
to change it later. “lc” means nothing, I am afraid
knows” (訳: 神のみのエルシィ知らんのか！) という反論を一応した.
•
•
•
おれ: logcache, lscache, writeboostという候補どうですか？
Aladair: (writeboostについて) I quite like that option. <- 当時は意外だった
結局, Mikeから”If the dm-writeboost target is designed well and provides a
tangible benefit it doesn’t need wide-spread users as justification for going
in”というコメントが出て, staging行きはナシになった.
Sunday, December 8, 2013
31. 緻密なコードレビュー
(by Mikulas Patocka)
•
Mikulasは, SpadFS(http://en.wikipedia.org/wiki/
SpadFS)の開発者. このネタでチェコの東大か
らDrとってるガチのストレージカーネル野郎
•
膨大な指摘と丁寧な解説が送られてきて, 消
化するのに2週間かかった. ものすごく勉強に
なった (http://www.redhat.com/archives/dmdevel/2013-October/msg00024.html)
Sunday, December 8, 2013
32. Dave Chinner (XFS野郎)
との戦い
•
write barrierへの遅延ACK(後述)について “That rings alarm bells”というハ
イテンションで文句を言ってきた.
•
•
これは後に理解された.
デバイスの閉塞について, XFSを使ってやったらXFSがおかしな挙動をし
たと言ったら「XFSは安定してる. 今までいくつもブロックドライバの
バグフィックスに貢献してる. 今度のどうせドライバが悪い」という論
理で悪い者呼ばわりされ(その割には熱心にバグ追求してくれたが)
•
•
これは本当におれが悪かった.
XFSがブロックに何を期待しているかなども知ることが出来て勉強
になった.
Sunday, December 8, 2013
34. LinuxCon Europe
akiradeveloper meets Ric Wheeler
•
10/21- エジンバラ@UK行ってきました
•
ありがたい会社マネーです. @mhiramatらと一緒
に
•
Ric Wheeler (RedHatのストレージ部門最高権力者)
に「同僚からライトブーストのことは聞いてるよ.
とても面白いと言ってた. ありがとう」と言われた.
•
Sunday, December 8, 2013
ライトブーストキテる！？
39. (現在)
write barrierへの遅延ACK
•
妥協案として, 「同期的に書き出す」ではなくちょっと遅延して,
write barrierをまとめるということにする.
•
(1) 複数プロセスが書いてる場合はバッファがフルになりやすくな
る (2) write barrierがたくさん降ってきた時のペナルティが小さい.
•
これは, Daveによると, XFSのメタデータジャーナリングでもやって
いることだし, dm-cacheやdm-thinでもやってる手法
•
Daveによると, XFSでもやってるのにさらにブロックでも遅延？
重複だしやめろ！とのこと
•
Sunday, December 8, 2013
本質的な解決にはなってない.
40. (将来)
永続メモリを使う
•
問題は, RAMバッファがvolatileであるからなのだし, non-volatileにす
れば問題解決だよね！
•
永続メモリは, block I/Fがまず提供されて, その後, byte-addressableな
I/Fが提供される予定.
•
まずは, block I/Fを持った永続メモリを使うコードを書く (type 1)
•
これは, 適当なblock deviceを使ってテスト出来るので今でも実
装可能
•
将来的には, byte-addressableな永続メモリ対応を行う (type 2)
•
Sunday, December 8, 2013
まだインターフェイスがないので実装も不可能
