dm-writeboost-cybozu-lab

2,854 views
2,746 views

Published on

Thank you for inviting to me to Cybozu workshop. I talked about my dm-writeboost.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,854
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
5
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

dm-writeboost-cybozu-lab

  1. 1. dm-writeboost の紹介 Akira Hayakawa (@akiradeveloper) 2013/12/26 Cybozu Lab.
  2. 2. 発表の目的 • この前: kernelvmで発表 (http://www.slideshare.net/ akirahayakawa716/dm-writeboostkernelvm) • 技術的な概要 + コミュニティ活動の ハイライト • 今回: もう少し技術的寄りにしたい.
  3. 3. dm-writeboost? • device-mapperを利用して作られたkernel module • • • Githubで管理 (https://github.com/akiradeveloper/dm-writeboost/) bcacheやdm-cacheなどと同様に, SSDをキャッシュとして使う. 特徴: writeしかキャッシュしない. readのstagingとかしない. read は間に合ってる前提 • 複数のwriteをログとしてまとめ書きする, log-structured caching • random writeスループットは, SSDのseq write相当まで引き上げ ることが可能 (ただし, 上限はある).
  4. 4. 元ネタの論文 Disk Caching Disk (DCD) • RAM Bufferにダーティデータと対応するメタ データをログ書きして, fullになったら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) 当時はログ書きが流行っていた.
  5. 5. blktrace + bno_plot.py 可視化してみた 仮想デバイスへのwrite キャッシュデバイスへのwrite
  6. 6. Overview rambuf_pool (fixed size) RAM Buffer (8-512KB) when buffer is full queue flush job with a buffer RAM bufferとsegmentは rotationで使いまわす (すぐに手に入らない場合は寝る) Flush Daemon Defer acks for barrier write. Migrate Daemon All daemons run asynchronously Migration is autonomous and batched. SSD (64GB) sb seg seg HDD (16TB)
  7. 7. Disk Format (SSD) super block segment[1] ... segment[k] ... ~512KB 4KB segment _header Data[1] Data[2] _device header (512KB) : - segmentのid - lap (partial write対策) metablock_device[i] : Data[i] のメタデータ を保持 ... 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; // 穢れをsector単位で管理 ! __u8 padding[16 - (8 + 4 + 1)]; /* 16B */ } __packed; sectorをまたがないように, paddingして16Bに. partial write対策
  8. 8. ログからの データ再現 • 電断があっても, ディスク上のメタデータ からデータ再現出来る (永続化にACK返し たもののみだが) • • • 状態t0 + [ログ t0 ~ t] = 状態t resume_cache()以下で行っている. 最近までバグってた. 結構ややこしい.
  9. 9. foreground処理 mutex_lock() • 前のcacheがI/Oなしにinvalidate出来ないこと もある (4KB全部dirtyじゃない場合とか考慮 する必要ある). ht_lookup() hit? 必要ならinvalidate_previous_cache() • queue_current_buffer()では, 新しく使うbuffer やsegmentを待つこともある. • 並行性が課題. writeの並行性を高めることが maxスループット向上への 必要なら prepare_segment_header() • & queue_current_buffer() 複数スレッドで思い切りwriteすると衝突 しすぎる. atomic_inc(seg->nr_inflight_ios) • mutex_unlock() write_on_buffer() atomic_dec(seg->nr_inflight_ios) 1.5GB/secくらいがrand writeのpeek. 目指 せ10倍. どうしたらいいの. • あと, rw_semaphoreを使いたくないのでread が若干犠牲に.
  10. 10. Flush Daemonの動作 しばらく寝る & 起きる list_empty? pop one flush job from the queue dm_io SSDにbufferをwrite • • • foregroundとは独立に動作. looping kernel thread flush jobがqueueされていたらこれを刈 り取ってI/Oする • write barrierが遅延されていたら, SSDに データを永続化したあとにACKする. complete_all(seg->flush_done) & complete_all(rambuf->done) • (未実装) 複数のthreadが並行してI/Oを 発行することが可能 (な気がする) もしwrite barrierのbioが このflush jobに繋がれていたら blkdev_issue_flush(SSD) & bio_endio(bio) for all bio • 永続化についてid順を守らせるため にちょっとだけコーディング必要.
  11. 11. Migrate Daemonの動作 • • looping kernel thread last_flushed_id - last_migrated_id = 一気にmigrate出来る最大の セグメント数 • • 複数のsegmentを非同期writeでmigrateする (閾値は設定可能). 実装の簡単化のため, SSD上ですでに永続化されたものと仮 定しているため, 複数segmentをmigrateした後にREQ_FLUSH 発行. • ここまでやって初めてこれらsegmentの再利用が可能とな る (それまで上位はblockされる).
  12. 12. ライトデータをremoteに アーカイブしたいかも? • あらゆる瞬間の状態を再現出来る. • • segment_header_deviceに時間を追加する? (案1) キャッシュデバイスを仮想化して, SSDに書くのと同時 にremoteにも書く. DRBDみたいな感じ • • ただし, RAID1ではなく, SSDの方でACKをとる. (案2) migrate daemonと同様に, remoteにログを送り続ける archive daemonを作る. • こっちの方が楽かな?

×