JP2005135126A

JP2005135126A - フラグメント防止ファイルシステム

Info

Publication number: JP2005135126A
Application number: JP2003369816A
Authority: JP
Inventors: Takayoshi Nakamura; 隆喜中村; Kenzo Moriyama; 建三森山; Toshiaki Mori; 利明森
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2003-10-30
Filing date: 2003-10-30
Publication date: 2005-05-26
Also published as: US20050108296A1

Abstract

【課題】領域予約可能なファイルシステムにおいて、ディスクフラグメントを防止しつつ、ファイルシステム領域不足になり難い方式を実現する。また、小サイズでのファイル作成の応答時間が短い方式を実現する。
【解決手段】ファイルの書き込み処理時に、ファイルサイズとあらかじめ設定しておいた複数の閾値とを比較して、ファイルサイズに応じた予約サイズで予約を行う。またファイルシステム容量不足により予約に失敗した場合は、実I/Oサイズで再度予約を試みることによりファイルシステムの領域を有効に活用する。ファイルサイズがあらかじめ設定しておいた最小の閾値に満たない場合は、実I/Oサイズで予約を行うことで、最小の閾値以下のファイルの予約解放処理をスキップ可能とする。
【選択図】図１

Description

本発明は、ディスク格納領域の予約が可能なファイルシステムにおける、ディスクフラグメント防止の方法に関するものである。

従来のUNIX（登録商標）系のファイルシステムでは、ファイルは、ファイルの管理情報であるメタデータ(inode)と、実際のファイルの中身であるユーザデータとに分かれる。ユーザデータは、ファイルシステムブロックサイズ(例えば4KB)単位で管理される。メタデータは、自身のユーザデータをディスクのどのブロック位置に格納しているかを管理するため、ファイルオフセットとファイルシステムのブロック番号とのマッピングテーブルを持っている。従来のファイルシステムでは、上記で述べたマッピングテーブルは、ファイルシステムブロック番号の配列として保持し、ファイルオフセットが大きくなるにつれて、ブロック番号の参照が間接的になるブロック管理アルゴリズムが主流だった。

ブロック管理アルゴリズムを図２を例にとり説明する。ブロック管理アルゴリズムではファイルのinode情報の一部にマッピングテーブル201を持つ。このテーブルの先頭数エントリにはユーザデータ位置を示すブロック番号が格納されている。最初のエントリのブロック番号は、ユーザデータのファイルオフセット0のデータが格納されている事を示し、二番目のエントリのブロック番号は、ファイルオフセット4KBのデータが格納されている事を示している。201の大きさは固定サイズでそれほど大きくは取れないため、最後の３エントリは直接ユーザデータ位置を指すのではなく、間接的にユーザデータ位置のブロック番号を指す。201の第一間接参照ブロック番号は、第一間接参照テーブル202aを指し、202aのエントリにはユーザデータのブロック番号が格納されている。201の第二間接参照ブロック番号は、第二間接参照テーブル203aを指す。203aのエントリには第一間接参照ブロック番号が格納されており、それぞれは202b,202c等の第一間接参照テーブルを指す。201の第三間接参照ブロック番号は、第三間接参照テーブル204aを指す。204aのエントリには第二間接参照ブロック番号が格納されており、それぞれは203b,203c等の第二間接参照テーブルを指す。202b〜202gは202aと同様の機能、203b,203cは203aと同様の機能である。
例えばLinuxのEXT2ファイルシステムだと、inode内に15エントリがあり、最初の12エントリは直接ブロック番号をポイントする。残りの三つのエントリはそれぞれ、第一間接参照、第二間接参照、第三間接参照となる。

近年のディスク・ファイルシステム・ファイルの大容量化に伴い、上記のブロック管理アルゴリズムでは、対応可能なファイルサイズや性能で限界が生じてきた。そこで、ブロック管理アルゴリズムのようにファイルオフセットとブロックをブロックサイズ毎に一対一にマッピングした情報を管理するのではなく、図3のように先頭ファイルオフセット、先頭ブロック番号、ブロック長の情報を管理するエクステント方式が主流になりつつある。エクステント方式には、図３のようにinodeに単一のテーブルを持つ方式だけでなく、B-Tree等で階層化して管理する方法もある。エクステント方式を採用しているファイルシステムには、JFS(IBM),XFS(SGI),VxFS(VERITAS)等がある。

ディスクの連続領域が割り当て可能な場合、エクステント形式は少ないエントリ数でユーザデータとディスク位置のマッピングを表現することができ、大規模ファイルに対して非常に効果的である。ただし、連続領域が既に他のファイルによって使用されているなどの要因により、必ずしも連続領域が割り当てられるとは限らない。一つのファイルに割り当てられたディスクのブロック位置が分散している状態を外部フラグメントと呼ぶ。
エクステント形式のファイルシステムでフラグメントが発生した場合、性能が低下するだけでなく、マッピングテーブルが巨大化する。マッピングテーブルが巨大化するとメモリ不足を引き起こしやすくなり、OSを不安定(デッドロック、スローダウン、パニック)にさせる要因となる。

そこで、フラグメント防止のために、例えばXFSでは以下の施策を行っている。
(1) 非同期writeシステムコールでは、ブロックの領域(大きさ)のみを予約し、ディスクに実際に書き出す際にブロック番号を確定させるDelaying Allocation方式の採用。これによりブロック番号の確定を極限まで遅らせることができ、エクステントの結合が期待できる。
(2) 予約時に実際のI/O要求長よりも大きめに予約(64KB)しておくことによって、予約長は必ず連続となる事を保証する。
(3) 大きめに予約した領域の未使用領域の解放はcloseの延長で行う。

ローカルアクセスの場合は、上記の施策でフラグメントはかなり防止できる。
NFS経由のアクセスでは、NFSクライアントでのI/O要求サイズに関わらず、要求がネットワークパケット化の過程で分断されるために、最終的にサーバでのI/O長は4KB〜8KB程度となる。NFS経由のwriteアクセスでは、open→write(4K〜8KB,非同期/同期両方あり)→fsync(書き込み保証)→closeの繰り返しとなり、一回のI/O毎にディスクへの書き出しが発生するため、(1)の効果は期待できない。

また、(3)はNFS経由のアクセスでは、4K〜8KB毎に予約が解放されることになり、連続領域確保にとって致命的なので、追加で以下の対策を行っている。
(4) NFS経由のwriteアクセス時には、キャッシュに登録し、そのキャッシュに登録されている限りclose時には未使用領域の解放は行わない。

(4)が有効に機能している限りにおいては、最悪ケースで(2)の予約サイズ(64KB)程度のフラグメントとなる。
XFSでは一つのエクステントエントリに16Byteを使用しており、1TBのファイルが64KBでフラグメントすると、マッピングテーブルが256MBとなってしまう。現在のハイエンドNASシステムは100TB超のストレージ容量に対して、数GBのメインメモリであるため、フラグメントした数TBのファイルに同時にアクセスすれば容易にメモリ不足となる。

また、VERITAS社のVxFSでは追加エクステントの取得時に現在のファイルサイズの倍の領域を予約するアルゴリズムを採用している。本方式ではフラグメントをかなり防止できるが、この弊害として余分に領域を取りすぎてしまうため、ファイルシステムフルになりやすい。
従来のファイルシステムでは、フラグメントを防止しようとすると、そのトレードオフとしてファイルシステムフルが発生しやすいという問題があった。また領域を大きめに予約すれば、当然あまった領域は解放しなければならないため、この処理コストにも注意を払う必要がある。

特許文献１には、複数の大きさの記憶領域を重複して予約し、実際のデータの格納時にその中から適合する大きさの記憶領域を選択して格納を行う技術が示される。これにより必要以上に大きな予約領域への格納が避けられ、フラグメント（ファイル断片化）の防止に一定の効果がある。しかし、記憶装置に余裕が無くなると複数領域の予約自体が困難になり、初期の効果が得られない。また、予約領域の開放処理のコストが増大するという問題もある。

特開平8−115238号公報

従来のファイルシステムでは、フラグメントの防止とファイルシステムフルのなり難さを両立することは難しかった。そこで本発明は、フラグメントを防止しつつ、ファイルシステムフルになり難いファイルシステムを実現することを課題とする。また、更に小規模ファイルに対して不要領域の解放コストを低減することを課題とする。

本発明は、領域の予約ポリシーや予約サイズをファイルのサイズに応じて変化させることで上記の課題を解決する。具体的には、小サイズファイルでは実I/O要求長での予約を行ない、中サイズ以上のファイルでは、そのファイルサイズに応じたあらかじめ指定した予約サイズでの予約を行う。また中サイズ以上の領域予約時に、ファイルシステム空き容量不足のため予約が失敗した場合には、実I/O要求長での予約を試みることによって、ファイルシステムフルを起こし難くする。また、小サイズファイルでは実I/O要求長での予約を行うことを利用し、小サイズファイルでの予約領域の解放処理を行わないことにより、小サイズファイルのI/O応答性をよくする。

本発明は、ファイルサイズに応じて予約サイズを変更することにより、ディスクのフラグメントを防止しつつ、ホールファイルや大サイズでの予約の失敗を考慮することにより、ファイルシステム容量不足がおきにくいファイルシステムを実現している。

また、ファイルサイズが小サイズでは、要求I/Oサイズでの予約とすることで、小サイズでの予約解放処理をスキップ可能とし、小サイズでのファイル作成、書き込みの応答性が向上する。

以下に、本発明の実施の形態を図面を参照して説明する。

図４は本発明のある実施の形態のファイルシステムの構成を表したブロック図である。本ブロック図では、本発明に関連する部分のみを記載してある。

Writeシステムコールが発行されると、カーネル空間のWrite処理部400に制御が移る。Write処理部400では、領域予約発行部401により決定した予約サイズで、領域予約解放管理部420に対して予約要求を行う。

予約が成功すると、バッファー生成部402においてバッファーを生成し、I/O発行部403においてI/O発行の準備を行う。非同期I/Oの場合は、I/O発行可能のキューに繋いでWriteシステムコールを終了する。同期I/Oの場合は、I/Oを発行し、その完了を待って正常に終了したことを確認してからWriteシステムコールを終了する。

つぎに、予約の解放処理について説明する。Closeシステムコールが発行されると、カーネル空間のClose処理部410に制御が移る。Close処理部410では、予約領域解放決定部411で領域の解放処理を行うかどうかを決定する。行うと決定した場合には、領域予約解放管理部420に対して予約の未使用領域の解放処理を要求する。そして、リソース解放部412にてファイルディスクリプタ等の解放処理を行う。本形態では、Closeシステムコールの延長で予約領域の解放を行うが、Umountシステムコールの延長や、メモリ上のinodeの破棄の延長で予約領域の解放を行う形態も考えられる。

次に図４の領域予約発行部401の処理内容の詳細を図１を参照して説明する。まず、101において非同期writeもしくはNFS経由のwriteであるかを判定する。この条件に該当しない場合は122へ処理が移り、420に予約要求を行うことにより、実I/O要求サイズで予約を行う。条件に該当した場合には、102に処理を移す。

102では、書き込みを行おうとしているファイルディスクリプタの先頭オフセットは現在のファイルサイズとホールファイル判定用閾値(例えば8KB)の和より大きいかどうかの判定を行う。
先頭オフセットが和と等しいもしくは和より大きい場合は111のホールファイル用の予約サイズ(例えば16KB)を適用する。また、ホールファイル用の予約サイズを適用する実施形態の他に、122の実要求サイズをいきなり適用する実施形態や、114の第一段階の予約サイズを適用する実施形態も考えられる。
先頭オフセットが和より小さい場合は103へ処理が移る。103では、ファイルサイズは第三段階の閾値(例えば512MB)より大きいかどうかの判定を行う。ファイルサイズが第三段階の閾値以上だった場合には、112の第三段階の予約サイズ(例えば16MB)を適用する。
第三段階の閾値に満たない場合は104へ処理が移る。104では、ファイルサイズは第二段階の閾値(例えば32MB)より大きいかどうかの判定を行う。ファイルサイズが第二段階の閾値以上だった場合には、113の第二段階の予約サイズ(例えば1MB)を適用する。
第二段階の閾値に満たない場合は105へ処理が移る。105では、ファイルサイズは第一段階の閾値(例えば64KB)より大きいかどうかの判定を行う。ファイルサイズが第一段階の閾値以上だった場合には、114の第一段階の予約サイズ(例えば64KB)を適用する。
ここまで第一段階の閾値、第二段階の閾値、第三段階の閾値の比較対象がファイルサイズである実施形態を述べてきたが、比較対象をファイルオフセットとする実施形態も考えられる。
102〜105までの条件にいずれも適合しなかった場合には、122にて、420に予約要求を行うことにより、実I/Oサイズで予約を行う。111〜114のいずれかに該当する場合、120にて、420に予約要求を行うことにより、それぞれの適用予約サイズで予約を行う。そして、121にて領域の予約がファイルシステム容量不足で失敗したかどうかの判定を行う。ファイルシステム容量不足で失敗した場合は、122で実I/O要求サイズで再度予約を試みる。121の条件に適合しなかった場合、つまり成功、もしくはファイルシステム容量不足以外の失敗の場合は、123に処理が移る。また122実行後にも123に処理が移る。
123では、領域の予約を行った結果、予約が成功したかどうかを判定する。予約が成功した場合は132にてwrite処理を続行し、402バッファー生成部へ制御を移す。予約が失敗した場合には131にてwrite処理は失敗し、ユーザプログラムにエラーを通知する。

本実施例では、ファイルサイズの判定を３段階の実施形態で示したが、段数は何段でもよい。また、第一段階の閾値には0も指定可能である。この場合は105から122へ直接処理が移ることはない。

次に図５を参照して、図４の411の処理内容を説明する。411に処理が移ると、501にてファイルサイズが第一段階の閾値(例えば64KB)より大きいかどうかを判定する。ファイルサイズが第一段階の閾値より大きい場合には、502へ処理を移す。502では予約解放処理を続行し、402の領域解放管理部へ未使用予約領域の解放を要求する。解放が終わると、412のリソース解放部に処理を移し、ファイルディスクリプタ等の資源を解放し、Close処理を終了する。
501の条件に合致しない場合には、503へ処理を移す。503では予約解放処理をスキップするため、420を行うことなく、412のリソース解放部に処理を移し、Close処理を終了する。
Close処理の説明で述べてきた第一段階の閾値は、図1の105の第一段階の閾値と常に一致していることが望ましい。
これまで述べてきた、第一段階の閾値、第二段階の閾値、第三段階の閾値、第一段階の予約サイズ、第二段階の予約サイズ、第三段階の予約サイズ、ホールファイル判定用閾値、ホールファイル用予約サイズは、あらかじめデフォルト値を定めておくが、システム単位、ファイルシステム単位、ファイル単位などでユーザが再設定できることが望ましい。
図６に予約サイズ決定に用いるパラメータを設定、参照するユーザ-カーネル間インターフェースのブロック図を示す。601は図1での予約サイズ決定の際使用する、第一段階の閾値、第二段階の閾値、第三段階の閾値、第一段階の予約サイズ、第二段階の予約サイズ、第三段階の予約サイズ、ホールファイル判定用閾値、ホールファイル用予約サイズを格納するテーブルである。これらテーブル内のパラメータはあらかじめデフォルト値が設定されている。

本発明に基づくファイルシステムでは、ユーザ空間からの設定要求に対して、602のカーネル-ユーザー間インターフェースを利用し、601のパラメータの値を置き換え可能である。またユーザ空間からの参照要求に対して、602のカーネル-ユーザー間インターフェースを利用し、601のパラメータの現在値を参照可能である。602のカーネル-ユーザー間インターフェースにはLinuxの/proc/sysファイルシステムや、UNIX（登録商標）のioctl等を利用する。

本発明のファイルシステムを搭載した情報処理装置の実施形態の構成図を図７に示す。情報処理装置710は、プロセッサ701、主記憶702、IO制御部703、ディスクコントローラ704、ネットワークカード705、補助記憶706からなり、703は701,702,704,705とそれぞれ接続し、704のディスクコントローラは装置内の補助記憶706と、装置の外部にある外部補助記憶707と接続する。705はLANなどの外部ネットワークと接続する。本情報処理装置上で、本発明のファイルシステムが稼動し、補助記憶706や外部補助記憶707に入出力を行う。

本発明によれは、余分な予約動作を防止して領域解放の処理コストを低減するとともにフラグメント発生を有効に防止できるファイルシステムが実現するので、そのファイルシステムはディスク記憶装置を備えた情報処理装置に広く利用可能である。

本発明の実施の形態のwrite処理時の領域予約処理のフローチャートである。従来のファイルシステムのブロック管理方式のマッピングテーブルの内容を示すブロック図である。従来のファイルシステムのエクステント方式のマッピングテーブルの内容を示すブロック図である。本発明の実施の形態のファイルシステムの概要を示すブロック図である。本発明の実施の形態のclose処理時の未使用予約領域の解放処理のフローチャートである。本発明の実施の形態の予約サイズ判定条件に用いるパラメータの設定・参照を行うためのカーネル-ユーザー間インターフェースのブロック図である。本発明のファイルシステムを搭載した情報処理装置の構成図である。

符号の説明

201 ブロック管理方式のマッピングテーブル
202a, 202b, 202c, 202d, 202e, 202f, 202g 第一間接参照テーブル
203a, 203b, 203c 第二間接参照テーブル
204a 第三間接参照テーブル
301 エクステント方式のマッピングテーブル
601 予約サイズ決定用テーブル
602 カーネル-ユーザー間インターフェース。

Claims

書き込み領域の予約が可能なファイルシステムにおいて、ファイルの書き込み処理時に、書き込みを行おうとしているファイルのファイルサイズまたはファイルオフセットと、あらかじめ指定した閾値とを比較し、その比較結果に応じて書き込み領域の予約サイズを変更することを特徴とするファイルシステム。
ファイルの書き込み処理時に、書き込みを行おうとしているファイルのファイルサイズまたはファイルオフセットが予め指定した閾値以上のときは予め指定した予約サイズで予約を行い、それ以外の場合は、書き込み要求サイズで予約を行うことを特徴とする請求項１に記載のファイルシステム。
前記予め指定した予約サイズでの予約がファイルシステムの領域不足により失敗した場合には書き込み要求サイズで再度予約を行うことを特徴とする請求項２に記載のファイルシステム。
予約した領域の未使用領域の解放時に、解放を行おうとしているファイルのファイルサイズが、前記予め指定した閾値未満の場合は開放の処理を中断し、指定した閾値以上の場合には解放処理を続行することを特徴とする請求項２に記載のファイルシステム
ファイルサイズに関する複数の閾値と、それぞれの閾値に対応する予約サイズが指定され、書き込みを行おうとするファイルのファイルサイズが上記閾値のいずれにも達しないときには書き込み要求サイズによる予約を行い、上記書き込みを行おうとするファイルのファイルサイズがいずれかの閾値に達する場合はその閾値に対応する予約サイズで予約を行うことを特徴とする請求項２に記載のファイルシステム。
予約した領域の未使用領域の解放時に、解放を行おうとしているファイルのファイルサイズが、前記複数の閾値のうちの最小の閾値未満の場合は処理を中断し、該最小の閾値以上の場合には解放処理を続行することを特徴とする請求項５に記載のファイルシステム。
書き込み開始オフセットが、書き込みを行おうとしているファイルのファイルサイズとあらかじめ指定した値との和と等しいもしくは和より大きかった場合には、書き込み要求サイズまたは前記予め指定した予約サイズと異なる第２の予約サイズで予約を行うこと特徴とする請求項２に記載のファイルシステム。
ユーザが値を指定すると、請求項１乃至請求項７のいずれかに記載のファイルシステムで使用する閾値や予約サイズを格納するカーネルのテーブルの該当個所に値を反映するカーネル-ユーザー間インターフェース。
請求項１乃至請求項７のいずれかに記載のファイルシステムで使用する閾値や予約サイズを格納するカーネルのテーブルの値をユーザが参照することができるカーネル-ユーザー間インターフェース。
請求項１乃至請求項７のいずれかに記載のファイルシステムを搭載した、プロセッサ、主記憶、I/O制御部、ディスクコントローラ、補助記憶、ネットワークカードによって構成される情報処理装置。
記憶装置の記憶領域を一定のサイズのブロック単位で管理し、且つファイル書き込みの要求があったらそのファイルに対する書き込み予定サイズもしくは書き込み予定のブロックを設定する予約動作を行い、順次書き込み処理を行うファイル書き込み方法であって、
書き込みを行おうとしているファイルのファイルオフセットと、ファイルオフセットに関する予め指定された閾値とを比較する第１の判定手順、及び
書き込みを行おうとしているファイルのファイルサイズと、ファイルサイズに関する予め指定された閾値を比較する第２の判定手順、を有し
上記第１の判定手順でその閾値に達していたら予め指定された第１の予約サイズで上記予約動作を行い、第２の判定手順でその閾値に達していたら予め指定された第２の予約サイズで上記予約動作を行い、上記第１、第２の判定手順でともにそれら閾値に達していなければ書き込み要求サイズで上記予約動作を行うファイル書き込み方法。