dm-writeboost-kernelvm

WARNING!
この発表には
コードが出てきません
git cloneの準備はいいですか？

Sunday, December 8, 2013

dm-writeboost開発しました
オポください
@akiradeveloper

DM野郎だが
何か？
(注) DM = デバイスマッパー


オポ
•
•
•

“オポ”チュニティの略
通常は, Job Opportunityのこと. 楽天が使い出したことでその語感がブームに
弊社では概念が拡張

•
•
•


例1) タダ飯オポ
例2) MLにおけるレスをオポと呼ぶ (マイクオポ, カーゴンオポ)

実例

Hello!
自己紹介

•
•
•
•
•

名前: 早川輝 (はやかわあきら)
所属: 完全に黙秘
勉強会で発表するのは初
会社入ってからカーネルの存在を知った (カーネル歴2.5年の素人です)
はてなブログ「テストステ論」やってます

発表の目的
• ライトブーストの技術背景・動作原理・
設計・性能を理解してもらう

• 開発やコミュニティ提案の経緯
• 今後の計画を共有

dm-writeboost
今すぐgit cloneせよ
https://github.com/akiradeveloper/dm-writeboost


dm-writeboost
is 何
write + boost
(writeを加速する)


元ネタの論文
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)

当時はログ書きが熱かったらしい

応用例
ブロックレベルの
ログ書き自体は新しくない
•

Grifﬁn (MS Research, 2010)

•

バッキングとしてSSD, キャッシュとしてHDDを使い, そこで上書き
を吸収することでSSDへの書き込みを減らす.

•

Mercury (NetApp, 2011)

•

Write Through Cache. SSDに書く前にRAMでバッファリングして, ま
とめて書く.

•

bcache (Kent Overstreet)

•

ドキュメントによると, 同様にキャッシュへのログ書きをしている
らしい.

•

SMR (ベンダーが議論中)

•

HDD内でログ構造化を行う.

ディベロパあるある
1. 文献読む
2. 「この技術やばい・・・作りたい・・・」
3. 「書いてあることが曖昧な気がする. これ本当に正
しく動くのか？？？確かめたい・・・」
4. 「おれさまならこの論文に書いてあるより効率良
く作れてしまうな」
5. 「Linux向けに最高の実装をおれが作る！！！」


世はまさに
SSD Cache 戦国時代！
立身出世！オポ！オポ！

• bache (Kent, 3.9-)
• dm-cache (RedHat, 3.10-)
• dm-writeboost (おれ, 3.?-)
• FlashCache (Facebook)
• enhanceIO (sTec)
• XtremSW Cache (EMC, not OSS)

と、いうわけで。
オポのために開発開始

• 毎年恒例の正月開発
• 2012 12/26にﬁrst commit (READMEのみ)
• 2013 1/11にはrubyのコンパイルが通って
る (1200行ほどのプロトタイプ)

• 1/2, 3 完全に意識消失して実家帰った

コード規模 (現在)
計3639行
39 dm-writeboost-daemon.h
52 dm-writeboost-metadata.h
485 dm-writeboost.h
626 dm-writeboost-daemon.c
1197 dm-writeboost-metadata.c
1240 dm-writeboost-target.c


ざっくりと
アーキテクチャ
RAM Buffer
(8-512KB)

Flush
Daemon

Migrate
Daemon

All daemons run
asynchronously
SSD (64GB)


もし, SSDのシーケンシャルライトが無限に速く容量が無限ならば,
スループットはRAMバッファへの書き込みに律速される.

when buffer is full
queue the buffer for
future write.

Defer acks
for barrier write.

SSDへのフラッシュにおけるポイント:

Migration is
autonomous
and batched.

HDD (16TB)

ざっくりと
ディスクフォーマット
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;

...

初期化
Example
# superblockを潰す
dd if=/dev/zero of=$CACHE bs=512 count=1 oﬂag=direct
# /dev/mapper/mydevを作る
# <type> <backing> <cache>
# <type>はRAM bufferの種類を意味する
dmsetup create mydev --table ¥
“0 $sz writeboost 0 $BACKING $CACHE”


性能評価実験
内容

•

ﬁoを利用

• 設定は, bcacheやdmcacheの測定でも利用さ
れている.

• 測定対象のディスクに
対して, 4KBのrandwrite

[global]
filename=/dev/...
randrepeat=1
ioengine=libaio
bs=4k
ba=4k
size=16GB
direct=1
gtod_reduce=1
norandommap
iodepth=64
stonewall
[perf]
rw=randwrite

性能評価実験
結果
x293 boosts
than HDD only


性能評価実験
blktrace + bno_plot.py
可視化してみた

仮想デバイスへのwrite


キャッシュデバイスへのwrite

dm-writeboost
差別化ポイント
•

device-mapper層で実装

•
•
•


将来的にはLVM2のサポートも？

全部でたったの3.5k LOC (小さい)

•
•
•
•

dmが提供する機能を活用出来る.

bcache 15k, dm-cache 10k
dm-cacheはバグりすぎ.
bcacheはKent以外誰も分からない.

Writeに特化. Readはキャッシュしない.

Writeに特化
Readはキャッシュしない
なぜ？ (1)
•

正常なシステムではReadはページキャッシュでかなりヒットしちゃう.
DRAMは結構安い.

•

Readキャッシュだったら, dm-cacheをもう一段stackする方向で良い
と思う.

•
•

RAIDは, ReadよりWriteの方が重い. 解決すべき問題はWrite.
実装上, Writeはダーティフラグなど, 持つべきメタデータが多くなる可
能性がある. Write専用とRead専用を切り分ける方が, トータルでは効率
が良くなる可能性がある.

•

キャッシュサイズ, 先読みのON/OFFなど, WriteキャッシュとRead
キャッシュで求められる機能も違う. 混ぜるな危険.


Writeに特化
Readはキャッシュしない
なぜ？ (2)

•

Readキャッシュは, 完全にワークロード依存. めんどくさいの
で付き合いたくない. 測定もwarmupが必要だったりして鬱陶
しい.

•

Writeに特化することで拓ける道があるはず. シンプルなアー
キテクチャの中でしか実現出来ないものもある.

•

WriteもReadもサポートするとなると, bcacheとどう違うの？
dm-cacheとどう違うの？うるさくなって辛い.

•

フルタイムで開発してるわけではないし, 同じ路線で行く
と勝つのは難しくなる. ニッチを攻める.


コミュニティに
提案しよう！
完全にオポのために！！！
ノーオポ！ノーライフ！


勇気を振り絞って
はじめての投稿
•
•

2013 7/16 [RFC] dm-lc target -> 無視
2013 7/28 Re: (自分で)

•

前回の投稿ではコードだけ送りつけてどやぁ？だった
ので, PDFでドキュメントを作ってupdateを報告した.

•
•

2013 7/29 Joe Thornber: This is nicely orthogonal to dmcache.

•

これが良かった.

この評価は狙いどおり.

すぐさま
LWNで紹介

• 本記事ではないのでインパクトは薄い
らしく, ネット上でもあまり話題になら
ず. 社会の厳しさを知る.

• 注目されているということは分かった.

糞みたいな
ユーザランドツールとsysfs
やめろ (Mike Snitzer)

•

カーネルはシンプルに, 多くをユーザランドにと
いう設計思想だった.

•

/sys/module/dm_lcという階層を作り, ユーザラ
ンドにデータを公開, Pythonスクリプトから操
作する

•

LVM2で初期化することも考えろ. dmsetupのみで
済ませろ. 他のターゲットに準拠した設計にせよ.


きな臭いので
キャッシュ共有やめろ (Mike Snitzer)
•

そうしていたのは, キャッシュ共有(一つのキャッシュを複数
のbacking storeが共有)のためでもあった. これも完全否定

•

device-mapperの実装上, すべてのデータ構造はctr/dtrで確
保/解放されねばならない. そうなっていないので, (理由は
不明だが)デッドロックを起こす可能性があるとのこと.

•

強烈なこだわりがあった部分ではなかったので, ユーザラン
ドツール廃止の件と一緒に一気に再設計した.

•

ここらへんの話は, 一言でいうと「DMフレームワークの限
界」. 譲歩出来るところは譲歩しておくのが吉.


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 beneﬁt it doesn’t need wide-spread users as justiﬁcation for going
in”というコメントが出て, staging行きはナシになった.


オポ
Phoronixで紹介ｋｔｋｒ！！！

•
•

ロシアの掲示板で(ロシア語で)沸騰した
こちらはかなりインパクトあったらしく, ライトブーストが有名になった感が
あった

•

「LWNやPhoronixで紹介され, 注目されている. 早くリリースする必要がある」
とかいう駆け引き材料にも使った (その後テストやコードレビューが始まった).

•

正直これはかなり興奮した.

ファイルを分割せよ
1枚で3000行はレビュー出来ない
(Mike Snitzer)

•

と言われたので, 一日かけて合計20個のファ
イルに分割して「どや？」って言ったら

•

Mike: Unfortunately I think you went too far
with all these different small files, I was hoping
to see 2 or 3 .c files and a couple of .h files.

•
•

なん・・・だと・・・.

さらにやり直して, 今の形になった.

緻密なコードレビュー
(by Mikulas Patocka)
•

Mikulasは, SpadFS(http://en.wikipedia.org/wiki/
SpadFS)の開発者. このネタでチェコの東大か
らDrとってるガチのストレージカーネル野郎

•

膨大な指摘と丁寧な解説が送られてきて, 消
化するのに2週間かかった. ものすごく勉強に
なった (http://www.redhat.com/archives/dmdevel/2013-October/msg00024.html)


Dave Chinner (XFS野郎)
との戦い
•

write barrierへの遅延ACK(後述)について “That rings alarm bells”というハ
イテンションで文句を言ってきた.

•
•

これは後に理解された.

デバイスの閉塞について, XFSを使ってやったらXFSがおかしな挙動をし
たと言ったら「XFSは安定してる. 今までいくつもブロックドライバの
バグフィックスに貢献してる. 今度のどうせドライバが悪い」という論
理で悪い者呼ばわりされ(その割には熱心にバグ追求してくれたが)

•
•

これは本当におれが悪かった.
XFSがブロックに何を期待しているかなども知ることが出来て勉強
になった.


ユーザによる
利用・バグ指摘
•

インド人3名: うち一名はパッチを送ってくれ
た.

•

韓国人3名: うち一名(韓国のﬂash応用会社の人.
Androidで動作させたらしい)は2つバグ指摘し
てくれた.

•

日本人が全く使ってくれないことに憤りを感
じております. 冷たい。。。


LinuxCon Europe
akiradeveloper meets Ric Wheeler
•

10/21- エジンバラ@UK行ってきました

•

ありがたい会社マネーです. @mhiramatらと一緒
に

•

Ric Wheeler (RedHatのストレージ部門最高権力者)
に「同僚からライトブーストのことは聞いてるよ.
とても面白いと言ってた. ありがとう」と言われた.

•

ライトブーストキテる！？

ジョーのテストスイート
(device-mapper-test-suite)
に貢献中

•
•

DMのテストスイートをRHチームが作ってる
「ライトブーストのテストを追加したいんだけど」とメール送ってから開始

•


まだ3つしかテストない. 今後追加していく.

韓国フラッシュアカデミック野郎が興味もった.
研究の踏み台に？

ファッ!? rwcache!?
•
•
•

Yongseok「GCあるの？Readはキャッシュするの？」
Akira「両方ないよ. 必要ないと思うわ」
Yongseok「おー残念. スクラッチか改造か迷うなー」
=> 改造着手？

•

なんかやばいアイデアがあるならくれ・・・

将来の計画
永続メモリ応用


(問題)
RAMバッファと
write barrierの相性が悪い

•

RAMバッファに全部たまらないとキャッシュに書か
ないのは, write barrier (REQ_FUA, REQ_FLUSH)が永
遠にACK出来ず, ユーザランドが永遠に眠る可能性が
ある.

•

では, write barrierを受け取った瞬間に, 同期的にバッ
ファを未完成のまま書き出してしまいますか？

•

これでは, ライトブーストの良い点が完全に引き出せ
ない.


(現在)
write barrierへの遅延ACK
•

妥協案として, 「同期的に書き出す」ではなくちょっと遅延して,
write barrierをまとめるということにする.

•

(1) 複数プロセスが書いてる場合はバッファがフルになりやすくな
る (2) write barrierがたくさん降ってきた時のペナルティが小さい.

•

これは, Daveによると, XFSのメタデータジャーナリングでもやって
いることだし, dm-cacheやdm-thinでもやってる手法

•

Daveによると, XFSでもやってるのにさらにブロックでも遅延？
重複だしやめろ！とのこと

•

本質的な解決にはなってない.

(将来)
永続メモリを使う
•

問題は, RAMバッファがvolatileであるからなのだし, non-volatileにす
れば問題解決だよね！

•

永続メモリは, block I/Fがまず提供されて, その後, byte-addressableな
I/Fが提供される予定.

•

まずは, block I/Fを持った永続メモリを使うコードを書く (type 1)

•

これは, 適当なblock deviceを使ってテスト出来るので今でも実
装可能

•

将来的には, byte-addressableな永続メモリ対応を行う (type 2)

•

まだインターフェイスがないので実装も不可能

大いなる可能性
• ライトブーストは, ファイルシステムの
実装をシンプルにする可能性がある.

• ストレージに必須の部品となる.
• すべての機能はブロックで追加するべ
き.


さいごに


dm-writeboostは
オポを加速するものだったのか

•
•

OSSはオポ力を高める.
DMやライトブーストに関する執筆
依頼お待ちしてます！

•
•

利用者フィードバックもウェルカム
ライトブーストのロゴも欲しい

Thanks
ライトブースト
使ってください


dm-writeboost-kernelvm

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a dm-writeboost-kernelvm

Similar a dm-writeboost-kernelvm (20)

Último

Último (9)

dm-writeboost-kernelvm