ext3からext4への更新概要

ext3からext4で何がかわったか、動作がどのように変更されたかを紹介します

Transcript

1. Copyright Red Hat K.K. All rights reserved. 1 ext3からext4への更新概要 Kazuo Moriwaka <kmoriwak@redhat.com> 2013-03-18
2. Copyright Red Hat K.K. All rights reserved. 2 agenda ▪ ext4についてのRHEL6サポート上の制限 ▪ inode データ構造のext3から4への変化 ▪ ext3のブロック管理 ▪ ext4のブロック管理 ▪ read 時のディスクアクセス ▪ write時のディスクアクセス • 遅延アロケーション • トランザクション • write動作の比較(data=writeback, data=ordered(ext3,4)) • 遅延アロケーションによる部分的な非互換 • 遅延アロケーションによる非互換対策 ▪ ジャーナル付加を減らすための工夫 ▪ メタデータ整合性を保つための工夫 • チェックサム • barrier ▪ その他ext4で新規に登場したオプション
3. Copyright Red Hat K.K. All rights reserved. 3 ext4についてのRHEL6のサポート上の制限 ▪ ファイルシステム全体のサイズは16TBまで • RHEL7で拡張予定 ▪ ext3からのフォーマットなしでの移行はサポートされない ▪ ext3のindirect形式との混在はサポートされない • 移行だけでなく混在して利用すること自体がサポート対象 外です ▪ ジャーナルについてはdata=orderedのみサポート対象 • data=writeback, data=journalはサポート対象外
4. Copyright Red Hat K.K. All rights reserved. 4 inodeデータ構造の ext3から4への変化 ▪ extentベース管理 • i_blockの利用方式 を変更 ▪ ナノ秒timestamp ▪ バージョニング • フィールドを新規追 加・転用 • inodeサイズを拡張 する • NFSv4で利用 ▪ inode内にチェックサ ム追加(RHEL6では未対 応) struct ext4_inode { __le16 i_mode; /* File mode */ __le16 i_uid; /* Low 16 bits of Owner Uid */ __le32 i_size_lo; /* Size in bytes */ __le32 i_atime; /* Access time */ __le32 i_ctime; /* Inode Change time */ __le32 i_mtime; /* Modification time */ __le32 i_dtime; /* Deletion Time */ __le16 i_gid; /* Low 16 bits of Group Id */ __le16 i_links_count; /* Links count */ __le32 i_blocks_lo; /* Blocks count */ __le32 i_flags; /* File flags */ ...中略... } osd1; /* OS dependent 1 */ __le32 i_block[EXT4_N_BLOCKS];/* Pointers to blocks */ __le32 i_generation; /* File version (for NFS) */ __le32 i_file_acl_lo; /* File ACL */ __le32 i_size_high; __le32 i_obso_faddr; /* Obsoleted fragment address */ union { struct { __le16 l_i_blocks_high; /* were l_i_reserved1 */ __le16 l_i_file_acl_high; __le16 l_i_uid_high; /* these 2 fields */ __le16 l_i_gid_high; /* were reserved2[0] */ __le16 l_i_checksum_lo;/* crc32c(uuid+inum+inode) LE __le16 l_i_reserved; } linux2; ...中略... } osd2; /* OS dependent 2 */ __le16 i_extra_isize; __le16 i_checksum_hi; /* crc32c(uuid+inum+inode) BE */ __le32 i_ctime_extra; /* extra Change time (nsec << 2 | epoch) __le32 i_mtime_extra; /* extra Modification time(nsec << 2 | epoch) __le32 i_atime_extra; /* extra Access time (nsec << 2 | epoch) __le32 i_crtime; /* File Creation time */ __le32 i_crtime_extra; /* extra FileCreationtime (nsec << 2 | epoch) __le32 i_version_hi; /* high 32 bits for 64-bit version */ }; 新規追加 利用方式変更
5. Copyright Red Hat K.K. All rights reserved. 5 ext3のブロック管理 ▪ 間接参照ブロックを利用し た古典的なFFSにならった 実装 ▪ i_block[]内0〜11は直接参 照 ▪ 12〜14はそれぞれ1段, 2 段, 3段間接参照 ▪ 小さいファイルサイズを仮 定すると速い i_block
6. Copyright Red Hat K.K. All rights reserved. 6 用語 ▪ 論理ブロック • ファイルの先頭からのオフセットをブロックサイズで切り 分けた単位 ▪ 物理ブロック • ファイルシステムが構成されているブロックデバイス上の オフセットをブロックサイズで切り分けた単位 ▪ extent • 論理ブロックと物理ブロックが連続して一対一に対応する まとまり。ext4ではファイル上のブロックをextentで管理 する • ブロック割り当てが連続していれば効率的な管理が可能 ブロックデバイス ファイル extent extent extent
7. Copyright Red Hat K.K. All rights reserved. 7 extent header 未使用 extent index extent index 未使用 ext4のブロック管理 extent header extent extent extent 未使用 : : extent extent checksum extent header : : extent extent checksum extent header : : ツリーの深さは1ファイル内で一定 i_block i_block node node eh_depth=1 eh_depth=0 eh_depth=0 eh_depth=0 ファイル ファイル
8. Copyright Red Hat K.K. All rights reserved. 8 付録: extentのデータ構造（1） ▪ extent: 論理ブロックと物理ブロックの対応 (96bit) • ファイル内論理ブロック番号(32bit) → 4kB * 2^32 = 16TBが1ファイルの上限 • 連続ブロック数(15bit) → 4kB * 2^15 = 128MBが1extentの上限 • 初期化済みフラグ(1bit) preallocate時に利用 • ディスク内物理ブロック番号(48bit) → 4kB * 2^48 = 1EBが1ファイルシステムの上限 (サポー ト上限は16TB) ▪ extent index: extentへのインデックス (96bit) • ファイル内論理ブロック番号(32bit) • ディスク内物理ブロック番号(48bit) • 未使用(16bit)
9. Copyright Red Hat K.K. All rights reserved. 9 付録: extentのデータ構造（2） ▪ extent_header: i_blockおよび ブロックのヘッダ (96bit) • マジックナンバー(16bit) → 未初期化等の異常検知 • エントリ数 (16bit) → ブロックやi_blockに含まれているextentの数 • 最大エントリ数(16bit) → i_blockまたはblockに含むことができるextentの最大数 • ツリーの深さ(16bit) →後述のextent管理のツリーがあと何段あるか • 未使用(32bit) ▪ checksum (32bit) • extent関連データのサイズが全て96bit = 12bytes = 4 * 3 bytes なので、ブロック(512〜4096の2のべき乗)に書く際 に必ず割り切れずに4bytes以上の余りがでる。このため チェックサムのために追加のブロックを必要としない。
10. Copyright Red Hat K.K. All rights reserved. 10 付録: extentのデータ構造（3） ▪ extent tree • 起点にはi_block[15] (4bytes * 15 = 60bytes)を転用 ▶ extent_header ▶ extent または extent_index(最大4個) • extentはツリーのleafのみに存在する ▶ 1ファイル内では全体でツリーの深さは同じ • extent4個で不足する場合extent indexを利用してツリー状 の構造をつくる ▶ ブロックを利用する場合は終端に32bitのchecksumを記 録する
11. Copyright Red Hat K.K. All rights reserved. 11 read 時のディスクアクセス 通常は各層でキャッシュが利用されますが最悪ケースでは: ▪ open時 • ディレクトリエントリからinode番号を検索 • inodeを読み込み ▪ read時 • extent headerからツリーの深さを読み込み • extent treeを探索して、読みこみたい論理ブロック番号か ら対応する物理ブロック番号を探索 ▶ みつかればブロックを読み込み ▶ みつからない部分(hole)は0で埋める • atimeまたはrel_atimeの書き込み
12. Copyright Red Hat K.K. All rights reserved. 12 write時のディスクアクセスの契機 ▪ 特にext3, ext4で違いはありません ▪ 明示的な呼出し • sync(), fsync(), fdatasync() • O_SYNCでの書き出し ▪ 明示的でない呼出し → ここから先はこちらを扱います • kjournald ▶ ジャーナルの書き出し ▶ アトミック操作完了後5秒後, ジャーナルサイズの1/4以上消 費などのタイミングで起床 • flusher kernel thread ▶ pdflush(RHEL5), flush-デバイス番号(RHEL6) ▶ 古いDirtyページ回収のためのタイマ ⚫ /proc/sys/vm/dirty_writeback_centisecs, dirty_expire_centisecs ▶ Dirtyページの増加 ⚫ /proc/sys/vm/dirty_background_ratio, dirty_ratio
13. Copyright Red Hat K.K. All rights reserved. 13 遅延アロケーション ▪ 基本的な考え方 • 複数のシステムコールに由来するブロック配置をまとめて 処理する ▶ 利用可能な容量だけ削減しておく • 割り当て時にはmultiblock allocatorを利用して複数ブロッ クをまとめて確保する ▶ できるだけ連続領域を割り当てる ▪ 期待される効果 • 複数回のwrite()による書き込みなどで、より連続した配置 が可能になる →フラグメンテーションの削減による性能向上 →extent数削減によるメタデータ量の削減 • 短時間しか存在しないテンポラリファイルなどについて、 ディスク上でのデータ更新を回避してメタデータの更新だ けで対応できるケースもある
14. Copyright Red Hat K.K. All rights reserved. 14 一般的なwrite処理 プロセスからページキャッシュ（1/2） プロセス writeシステムコール呼び出し ページ キャッシュ ページ キャッシュ ページ キャッシュ ページ キャッシュ ページ キャッシュ data copy ページ キャッシュ データの変更がディスクへ反映されている(clean) データの変更がディスクへ反映されていない（dirty） ページ キャッシュ
15. Copyright Red Hat K.K. All rights reserved. 15 一般的なwrite処理 プロセスからページキャッシュ（2/2） ページ キャッシュ ページ キャッシュ ページ キャッシュ ページ キャッシュ ページ キャッシュ プロセス writeシステムコール呼び出し data ↑ アプリケーションからの書き込みによりdirtyになる ext3ではこの書き込み時点で対応するブロックを決定する ext4では未割り当てのブロックについてはここで決定しない
16. Copyright Red Hat K.K. All rights reserved. 16 一般的なwrite処理 ページキャッシュをio request queueへ接続 ページ キャッシュ ページ キャッシュ ページ キャッシュ ページ キャッシュ /dev/sdXの リクエスト セクター2に 書いて セクター7に 書いて セクター11に 書いて io request queue ext4ファイルシステムドライバー 書き込み先セクターを決める。 時間が経つと変更のあった キ ャ ッ シ ュ を デ ィ ス ク へ フラッシュする(flush-xx:xx) ext4はこの時点でブロックを 決定する
17. Copyright Red Hat K.K. All rights reserved. 17 extent header 未使用 未使用 extent 未使用 i_block ファイル extent header 未使用 未使用 未使用 未使用 inode ディレクトリ エントリ newfile 1. inode作成 2. inodeビットマップ更新 3. ディレクトリエントリ作成 1. ブロックbitmap更新 2. extent treeを更新 3. inodeのサイズ情報更新 トランザクション 複数操作をアトミックに行うことで メタデータ整合性を維持する ブロック割り当て ファイル作成
18. Copyright Red Hat K.K. All rights reserved. 18 write動作の比較(遅延アロケーション時) メタデータ 更新 未初期化 かも？ inode等のメタデータを更新してブロック への参照作成、サイズ変更など 非同期でデータ更新 前後関係は不定 ext3, ext4の data=writeback メタデータ inode等のメタデータを更新してブロック への参照作成、サイズ変更など ext3での data=ordered 更新 関連データ更新 完了を待つ 更新済み メタデータ 非同期でのデータ更新時に データ更新後メタデータを 更新する新規トランザクションを作成 ext4での data=ordered 更新 メタデータ ここでブロックは 割り当てない 更新済み 点線部分は 非アトミック 点線部分は 非アトミック
19. Copyright Red Hat K.K. All rights reserved. 19 遅延アロケーションによる部分的な非互換(前提) ▪ ext3でのdata=orderedは • データを書き出したあと対応するメタデータを書き出す • これは未初期化ブロックが見えないようにするためのセ キュリティ上の要請からきたもの ▪ ext4でのdata=orderedは • データ書き出しのタイミングでブロックを割り当て、書き 出してから、メタデータを更新する。この部分は元のシス テムコールとは別のトランザクションになる • 未初期化ブロックはみえない ▪ どちらでも • kjournaldは5秒程度の遅延でジャーナルをディスク上に記 録する
20. Copyright Red Hat K.K. All rights reserved. 遅延アロケーションによる部分的な非互換(1/2) ▪ ext3では: • データは対応するメタデータより前にディスク上に書き出 すために、ジャーナルコミット時にデータの書き出しが呼 ばれ、結果として5秒程度で書き出しが開始される • アプリケーションがfsync等を呼ばないでcrashした場合に 更新が反映されていない期間が5秒程度になる ▪ ext4では: • flush-xx:xx により最大30秒程度遅延してからデータが書き だされる • アプリケーションがfsync等を呼ばないでcrashした場合に 更新が反映されない期間が30秒程度になる • この時間は dirty_expire_centisecs に由来する
21. Copyright Red Hat K.K. All rights reserved. 21 遅延アロケーションによる部分的な非互換(2/2) ▪ 過去に問題になったケース • ファイル"foo"が既に存在している状態で以下の操作をする • creat("foo.tmp"), write(), close() • rename("foo.tmp", "foo") ▪ 書いたユーザの意図 • rename()によるアトミックなファイル置き換え • 途中でクラッシュしても古いデータか新しいデータのどち らかが存在するはず ▪ 実際にありうる挙動 • rename()時点ではwrite()で書かれたブロックが遅延アロ ケーションのためまだディスク上に書かれていない • サイズ0のファイル"foo"が存在する期間がある ▪ 問題点 • close()前にfsync()しておくべきだがしていない • ext3でdata=orderedの場合期待通りに動いてしまうため気 付かれない
22. Copyright Red Hat K.K. All rights reserved. 22 遅延アロケーションの非互換対策 ▪ アプリケーションの必要に応じて、sync, fsync, fdatasyncを 呼び出す、O_SYNCフラグをつけてファイルをopenする • POSIX前提であればこうあるべき ▶ ディスク上への同期を一般的に保証する方法が他にない • この問題に影響される場合、ext4以外のXFS等のファイル システムでも問題があるはず ▪ nodelallocオプションにより遅延アロケーションを無効にする • 非常に遅くなります ▪ ext3風の動作を期待するアプリケーションへの対策として、 auto_da_allocオプション(デフォルト)により以下を検出し て、ブロック割り当てを即時に行う対策を含んでいる • renameによるinodeの置き換え • truncate(0)後のファイル追記
23. Copyright Red Hat K.K. All rights reserved. 23 ジャーナル負荷を減らすための工夫 ▪ atime: 最終アクセス時刻 • 更新をともなわないreadでもメタデータの更新が発生する • noatime ▶ アクセス時刻を一切記録しない(ext3と同様) ▶ 「最近アクセスされたファイル」などを操作したい場合 には問題 • rel_atime ▶ 現在のアクセス時刻があらかじめ決めた一定時間(デ フォルトは3600秒)以上過去の場合にのみatimeを更新 する ▶ atime更新頻度を落とすことでreadが中心的な負荷での ジャーナル書き込みを減らす ▪ ジャーナルを別diskへ分離(ext3と同様) • ジャーナルを別のディスクへ分けることでIOPS負荷を分割 する
24. Copyright Red Hat K.K. All rights reserved. 24 メタデータ整合性を保つためのext4での工夫
25. Copyright Red Hat K.K. All rights reserved. 25 メタデータへのチェックサム付与 メタデータにチェックサムを付与しfsck時の障害検出を補助 ▪ ※RHEL6.4時点では以下に対応 • ジャーナル ▶ ジャーナルにチェックサムを付与することで一部が壊れ たジャーナルを検出 • extent treeのblock • block group descriptor ▪ Upstreamではさらに以下へチェックサムを追加中 • superblock • inode • inode bitmap, block bitmap • ディレクトリエントリのblock • ディレクトリのハッシュHTree • 拡張属性block • MMP block
26. Copyright Red Hat K.K. All rights reserved. 26 write barrier ▪ 最近はディスクにwriteback cacheが存在している • ディスクへコマンドを発行しても、その順序で実行される とは限らない ▪ ディスクへ発行したコマンド実行の前後関係を保証するた め、barrierを導入 • barrierの前に発行した命令全ての完了を待って完了するま で、barrier後に発行した命令を実行開始しない • 今のキャッシュを書き出す ▪ ext4では以下を保証するためbarrierを利用 • ジャーナルの前後関係 • fsync()などでディスクに永続的な書き出しをおこなうこと ▪ パフォーマンスに影響がある • fsync()の実行が多い場合 • 小さなファイルの作成/削除などメタデータ操作が多い場合
27. Copyright Red Hat K.K. All rights reserved. write barrierを外して問題ないケース ▪ writeback cacheが存在しない場合 • 明示的にdisableすることもできる(hdparm) ▪ バッテリ等でwriteback cacheを維持し、コマンド送信完了時 点で(実際にディスク上へ反映されない場合であっても)情報が 失われないことを保証できる場合 ▪ ドキュメント「Storage Adminitration Guide」: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/ html/Storage_Administration_Guide/writebarr.html
28. Copyright Red Hat K.K. All rights reserved. 28 その他のext4新機能 ▪ Multiple Mount Protection(MMP) • 複数サーバから同時にmountやfsckをされないよう保護 ▪ persistent pre-allocation • 初期化せずにブロックを確保してファイルに割り当てる。 大きなファイルの初期化に有用 • extentの初期化ビットを利用して未初期化であるという情 報を維持する ▪ 1ディレクトリ上のサブディレクトリ数上限を拡張 ▪ block discarding対応 ▪ 16TB以上のファイルシステム ▪ flex_bg: block groupを複数まとめて1つのblock groupとして 扱う • 従来のblock groupは(4096 * 32768=)128MBが上限 • メタデータの位置を集約してfsck時間の短縮とキャッシュ 用のreadaheadの効果を高める ▪ 未使用inodeについての情報を保持してfsck時間の短縮
29. Copyright Red Hat K.K. All rights reserved. 29 その他ext4で新規に登場したオプションの紹介 ▪ mke2fs • lazy_itable_init, lazy_journal_init: inode table, journalの 初期化をmke2fs時に完全に行わず利用時に行う • uninit_bg: block groupの初期化をmke2fs時に完全に行わ なず利用時に行う • discard: mke2fs時に0で初期化するかわりにdiscardを発 行する • mmp_update_interval: 複数マウント回避情報の更新頻度 • stride, stripe-width: RAID時にチャンクのサイズとストラ イプのサイズを指定して、チャンク境界を考慮したブロッ ク割り当てを行う ▪ mount option • journal_async_commit: ジャーナルのレコードを非同期に 書きこむ
30. Copyright Red Hat K.K. All rights reserved. 30 まとめ ▪ ext4では、ext3より連続したブロック割り当てを効率的に実施 • 遅延アロケーション+extentによる管理+multiblock allocatorの組み合わせにより実現 • 特にサイズの大きなファイルの管理が効率化 ▪ 遅延アロケーションの導入によりext3までと同一の操作をして も同一の状態にならないケースがある • 正常系では基本的に同じだが障害時に差が見える • POSIXのコンテキストは維持 • fsync等をなにもおこなわない場合(そもそもPOSIXではディ スク上にあると保証されないが) ext3では5秒程度、 ext4で は30秒程度ディスクに書かれない時間が存在する • 2つの典型的なケースについてはext4でもワークアラウンド を実装している ▶ truncateでサイズを0にした後の再生成時 ▶ renameによるファイル置き換え