nkjmkzk.net

powered by Kazuki Nakajima

Archive for the ‘ext4’ tag

最新のLinux KernelでサポートされているFilesystem

2010/11/10現在、Linux Kernelの最新安定バージョンは2.6.36です。このKernelで組み込まれている比較的新しいFilesystemを簡単に整理してみました。

Ext4

  • Ext2/3との後方互換性を保ちつつ、より巨大なファイルシステム/ファイルのサポート・エクステント管理・マルチブロックアロケーション・遅延アロケーションといったモダンなファイルシステムの機能を実装する
  • Kernel 2.6.19でマージされた
  • Kernel 2.6.28で安定板としてリリースされた
  • More Info: https://ext4.wiki.kernel.org/index.php/Main_Page
  • More Info: http://nkjmkzk.net/?p=185

UBIFS

  • JFF2をベースに開発されているRaw Flash専用ファイルシステム。一般的なHDD,  SD Card, USB Flash, SSDでは使用できない
  • Kernel 2.6.28でマージされた(依存モジュールのUBIは2.6.22でマージされた)
  • More Info: http://www.linux-mtd.infradead.org/doc/ubifs.html

Btrfs

  • Linuxでの次世代デファクトファイルシステムを目指してスクラッチから開発されている。後方互換性を考慮する必要がないためモダンなコンセプトをふんだんに取り入れ、ファイルシステムで一般的になりつつあるエクステント管理やCoW等を実装しつつ、動的なボリュームの追加削除・ファイルシステムサイズの変更やスナップショット機能を実装する
  • Kernel 2.6.29でunstableとしてマージされた
  • More Info: https://btrfs.wiki.kernel.org/index.php/Main_Page
  • More Info: http://nkjmkzk.net/?tag=btrfs

NILFS2

  • ログ構造化ファイルシステム。連続的かつ自動的なチェックポイントによるファイルシステムのバージョン管理機能が特徴。NTTが主体的に開発を進めている
  • Kernel 2.6.30でマージされた
  • More Info: http://www.nilfs.org/ja/

LogFS

  • UBIFSと同じくRaw Flash専用ファイルシステム
  • Kernel 2.6.34でマージされた
  • More Info: http://logfs.org/git/

Ceph

  • 分散ネットワークファイルシステム。動的にストレージノードを追加することによるスケールアウトが可能で、新たな構成に合わせて既存データのリバランスを行う
  • Kernel 2.6.34でマージされた
  • More Info: http://ceph.newdream.net

without comments

Written by 中嶋 一樹

11月 10th, 2010 at 4:31 pm

Posted in Uncategorized

Tagged with , , , , , ,

Ext4, ついに安定版リリース

12/24にLinux kernel 2.6.28がリリースされました。このリリースの目玉としてExt4実装があります。Ext4はExt3と互換性を保ちながらも多くの改良がなされたものになっているようです。kernelnewbies.orgに記載されているNew featureを意訳してまとめてみました。

 
互換性

既存のExt3ファイルシステムはExt4にリフォーマットすることなく移行可能。具体的には該当ボリュームをReadOnlyでマウントしていくつかコマンド叩くだけでOK。

 

より大きなファイルシステムサイズ、ファイルサイズのサポート

Ext3からExt4ではそれぞれの制限は以下の通り。

ファイルシステムサイズ:16TB -> 1EB (エクサバイト)

ファイルサイズ:2TB -> 16TB

ちなみにEBとは、 (1 EB = 1024 PB, 1 PB = 1024 TB, 1 TB = 1024 GB)なぐらい大きい。

 

無制限のサブディレクトリ数

Ext3からExt4でのサブディレクトリ制限は以下の通り。

320000 -> 無制限

 

エクステントによる大きなファイル操作の効率化

これまでは「ファイル」のデータはディスクという円盤のいろんなところに「ブロック」としてバラバラと格納されていたが、このような大きなファイルを物理的に連続したブロック(これがエクステント)として格納するこで、特にdelete等の操作を効率化する。

 

マルチブロックアロケーションによる内部ブロック割当処理の効率化

これまでは連続してデータを書き込む際、ディスク上の空いているブロックを1ブロックずつ探してきて割り当てる、という処理になっていたがこれをブロックアロケータ自身に必要合計ブロック数を認識させることで、単一コールで複数ブロックを割り当てれるようになりオーバヘッドが緩和される。

 

遅延アロケーションによる性能改善

これまではデータが書き込まれるやいなやブロック割当てを実行していたが、これをしばらく遅らせることで連続データ書き込み時のブロック割当て処理をまとめて行えるようになりその分オーバヘッドが軽減できると同時にフラグメンテーションも抑えることができる。これは前述のエクステント、マルチブロックアロケーションと連携して相乗効果を発揮する仕組みになっている。

 

Fast fsck

fsckが対象とするinodeを全inodeから使用したinodeのみに絞り込むことでfsckにかかる所要時間を大幅に短縮する(環境によって1/2〜1/20程度に)。ただしinodeを使用したか未使用かを判断するにはfsckをその前後で走らせる必要があることに注意。

 

Journal checksum

ジャーナルの完全性を高めるためにチェックサム機構を取り入れた。これによって信頼性だけでなく、既存Ext3の2フェーズコミットをシングルコミットとすることができ性能の改善も期待できる(環境によっては20%程度向上の可能性も)。

 

オンライン・デフラグメンテーション

今回のkernelリリース(2.6.28)ではまだ実装していないが、将来のリリースではこのオンラインでのデフラグ機構が盛り込まれる予定。e4defragと呼ばれるツールで実装する。

 

inode関連の変更

ディレクトリ作成時にあらかじめinodeを作成しておくことにより、ファイル作成時のinode作成処理にかかるオーバヘッドを軽減する。

タイムスタンプを秒 -> ナノ秒に拡張。

上記にともないinodeのサイズを128バイトから256バイトに変更。

 

先行ディスク領域割当

アプリケーションがあらかじめ使用予定の領域を確保しておける仕組み。3つの利点があり、1つ目はアプリケーションが独自にこれを行おうとすると、あらかじめ領域を0で埋め尽くさなければ行けないがこれを回避できる。2つ目として、領域をあらかじめ一括して確保できるのでフラグメンテーションを抑制できる。3つ目として、必要な領域がなくなってしまうということがなくなることが挙げられる。

 

バリア機能がデフォルト有効に

ハードウェアが内部write-cacheをもって独自のキャッシュフラッシュ処理(順番入れ替え)を行うような場合でもジャーナルが確実にデータコミット前にディスクに書き込まれるように制御する。性能を若干犠牲にしてデータの完全性を高めるための選択。ただしマウント時に”mount -o barrier=0″とすることでこのバリアを無効にできる。

 

フーム、Ext4ではエクステント、マルチブロックアロケーション、遅延割当等を連携させて論理的に連続するデータを物理的にも連続させて管理やI/Oの効率化を計るところにかなり注力しているようです。素晴らしいー。

with one comment

Written by 中嶋 一樹

12月 27th, 2008 at 10:51 am

Posted in Uncategorized

Tagged with ,