COW COW
⑤: メタデータのコピー中に 変更されたメタデータの
④ : ファイルシステム停止
⑥: ファイルシステム再開
Any: FS への要求
⑤: メタデータのコピー中に
変更されたメタデータの
再コピー
必要な機能 : ブロック解放抑止
ブロック解放時のスナップショットのデータの保護
スナップショット取得後は、スナップショットが該当ブロッ クを参照している可能性があり、もし参照している場合 はブロック解放しない
ブロック解放抑止のタイミング
ブロック解放時
free_blocks()
処理Copy-On-Write
時と異なり、解放処理はジャーナルされ ない(
必要がない)
ために解放抑止処理はブロック解放 時で問題無い2005/06/01 Linux Conference 2005 33
必要な機能 : スナップショット用デバイス スナップショットの利用
スナップ取得元デバイスのデータとスナップショットファ イルを選択的に読み込む専用ブロックデバイスから利 用
…
1 2 4
スナップショット取得元FS
スナップショットファイルスナップショット専用 ブロックデバイス
0 0
1’
1
2’
2
3 3
4’
4
5 5
6 6
…
…
…
1 2 4
=
スナップショット取得後に更新されていないデータブロック
=
スナップショット取得後に 更新されたデータブロックext3 スナップショット
現時点の実装状況
2005/06/01 Linux Conference 2005 35
現時点での実装
スナップショットの基本動作は実装完了
FS
毎に1
つのスナップショットが取得でき、スナップショッ ト用デバイスを介してスナップショットをマウントし読み 出せ、スナップショットを解放できる制約条件
アンマウントやシステムクラッシュによりスナップショットは消 滅する
ディスクフル時はスナップショット取得元
FS
がReadOnly
へ移 行するディスクフルに関与しない部分への読み出しはスナップショット・取得
FS
共に可能現時点で実装した機能
実装済が青色 , 未実装が赤色
ffs
スナップショットと異なる方式で実装する機能Copy-On-Write
before
イメージジャーナル既存のジャーナル量を増やして
data=journal
でスナップショットファイ ルをジャーナルしたアドホックな実装スナップショットファイルの
delayed allocation
クラッシュリカバリffs
スナップショットと同じ考え方で実装する機能スナップショット初期化
(
スナップショットファイル作成)
ブロック解放抑止スナップショット用デバイス
ext3 スナップショット
現時点の実装の評価
評価観点と測定内容 評価観点
LVM
スナップショット(ext3 on LVM)
との比較スナップショット未取得時のデータ更新・新規作成の速さ スナップショットを取得する速さ
スナップショット取得後のデータ更新の速さ
スナップショット取得後のデータ新規作成の速さ
ext3スナップショットではCopy-On-Write処理が発生しないが、LVMス
ナップショットではCopy-On-Write
処理が発生する測定内容 (3 回測定した各平均時間 )
スナップショット未取得時のデータ更新・新規作成の時間 スナップショット取得の時間とその際の
FS
停止の時間スナップショット取得後の既存ファイルのデータ更新の時間 スナップショット取得後の新規ファイルのデータ作成の時間
2005/06/01 Linux Conference 2005 39
既存データ更新と新規データ作成の時間
•
データの更新・新規作成ともに若干遅い•
Copy-On-Writeのために予約するジャーナル量が増え、ジャー ナルのディスク書き出し動作が増えているため既存データ更新時間 新規データ作成時間
既存データ更新時間 (スナップショット未取得時)
0 50 100 150 200 250 300 350
200MB x 2 / 1GB 1GB x 2 / 20GB 既存データ更新容量 / 取得元FS容量
se c
ext3ssLVMss
新規データ作成時間 (スナップショット未取得時)
0 50 100 150 200 250 300 350
200MB x 2 / 1GB 1GB x 2 / 20GB 新規データ作成容量 / 取得元FS容量
se c
ext3ssLVMss
スナップショット取得の時間
スナップショット取得時間
dd
コマンドで新規データ作成しながら スナップショットを取得スナップショット取得時間(I/O負荷無)
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
1GB 20GB
スナップショット取得元FS容量
se c
ext3ssLVMss
スナップショット取得時間(I/O負荷有)
0 20 40 60 80 100 120 140 160
1GB 20GB
スナップショット取得元FS容量
se c
ext3ssLVMss
•ext3
の方が3
〜4
倍程度遅い•
メタデータのコピー処理で必要なブ ロックを前もって確保するのではなく、その都度ブロックを確保しているため
•
両者とも数十秒以上掛かっている•
LVMはI/O高負荷時スナップショット 取得が遅いためかdd
コマンドによる データの作成が速いためか2005/06/01 Linux Conference 2005 41
スナップショット取得時の FS 停止の時間
スナップショット取得時FS停止時間
•I/O
負荷が無い時は問題無いdd
コマンドで新規データ作成しながら スナップショットを取得•I/O負荷が有る時は数十秒もFS停
止していて問題有り•
もしくは やむを得ない(
かも)
FS停止時間(I/O負荷有)
0 5 10 15 20 25 30 35 40 45
1GB 20GB
スナップショット取得元FS容量
se c
ext3ss FS停止時間(I/O負荷無)
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
1GB 20GB
スナップショット取得元FS容量
se c
ext3ss
既存データ更新と新規データ作成の時間
既存データ更新時間 新規データ作成時間
新規データ作成時間 (スナップショット取得時)
0 200 400 600 800 1000 1200 1400
200MB x 2 / 1GB 1GB x 2 / 20GB 新規データ作成容量 / 取得元FS容量
se c
ext3ssLVMss 既存データ更新時間
(スナップショット取得時)
0 200 400 600 800 1000 1200 1400
200MB x 2 / 1GB 1GB x 2 / 20GB 既存データ更新容量 / 取得元FS容量
se c
ext3ssLVMss
•
ext3の方が1.5〜4倍程度遅い•
LVMの方がCopy-On-Write単 位が大きいため、効率が良い•
少し遅すぎる(かも)•
ext3の方が1.5倍〜3倍程度速い•
LVMの方がCopy-On-Write単 位が大きいため、余分なCopy-On-Writeが発生している2005/06/01 Linux Conference 2005 43
現時点の実装の評価のまとめ (LVM との比較 ) 利点
スナップショット取得後の新規データ作成が速い
更新されないデータは
Copy-On-Write
されないので、余 分なディスク容量の消費が無い欠点 (= 今後の課題 )
スナップショット取得後の既存データ更新が遅い
スナップショット取得時間や
I/O
高負荷下のFS
停止が長 い•
課題はあるもののFS
レイヤで実装する事により、LVM
スナップショットと異なる性能特性を示し、ext3
スナップショットの存在意義が認められる•
ただし実装途中なので数値は参考程度にext3 スナップショット デモ
時間があれば …
2005/06/01 Linux Conference 2005 45
ext3 スナップショットの利用の流れ 利用例
スナップショットの取得から利用まで
スナップショットの利用終了から解放まで
# e3snapconfig –c /mnt/src/snapshot.img …
①# ssdevconfig –c /mnt/src/snapshot.img /dev/ssdev/0 …
②# mount /dev/ssdev/0 /mnt/ss …
③# cd /mnt/ss …
④…
…
# umount /mnt/ss …
⑤# ssdevconfig –d /dev/ssdev/0 …
⑥# e3snapconfig –d /mnt/src/snapshot.img …
⑦まとめ
2005/06/01 Linux Conference 2005 47
まとめ
ext3FS へのスナップショット機能追加の設計と実装
について述べ、その存在意義を示した
現時点のソースコード及び利用手順を以下で公開して いる
http://sourceforge.net/projects/ext3snapshot/
今後の課題
スナップショット取得の性能向上 未実装部分の実装
スナップショットの永続化
before
イメージジャーナルの実装 クラッシュリカバリの実装複数のスナップショットの取得
スナップショットファイルの