JP4315876B2 - ファイル管理プログラム、ファイル管理方法、及びファイル管理装置 - Google Patents

ファイル管理プログラム、ファイル管理方法、及びファイル管理装置 Download PDF

Info

Publication number
JP4315876B2
JP4315876B2 JP2004237550A JP2004237550A JP4315876B2 JP 4315876 B2 JP4315876 B2 JP 4315876B2 JP 2004237550 A JP2004237550 A JP 2004237550A JP 2004237550 A JP2004237550 A JP 2004237550A JP 4315876 B2 JP4315876 B2 JP 4315876B2
Authority
JP
Japan
Prior art keywords
hash value
physical block
value range
block number
processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004237550A
Other languages
English (en)
Other versions
JP2006058965A (ja
Inventor
賢輔 塩沢
剛 宮前
慶武 新開
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2004237550A priority Critical patent/JP4315876B2/ja
Priority to US11/036,678 priority patent/US7454405B2/en
Publication of JP2006058965A publication Critical patent/JP2006058965A/ja
Application granted granted Critical
Publication of JP4315876B2 publication Critical patent/JP4315876B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99932—Access augmentation or optimizing

Description

本発明はストレージデバイス内のファイルを管理するためのファイル管理プログラム、ファイル管理方法、及びファイル管理装置に関し、特にextent（エクステント）方式を採用したファイル管理プログラム、ファイル管理方法、及びファイル管理装置に関する。
コンピュータのファイルシステムの効率化技術の１つとして、extent方式がある。extent方式では、ファイルの連続した論理領域（ブロック）をextentという単位でまとめて、ボリューム上にアロケートする。この方式では、複数のブロックを１つのextentとしてアクセスできるため、複数のブロックに渡って格納されているデータへのアクセスを効率的に行うことができる。
近年は、extent方式のファイルシステムが主流となってきている。その多くのシステムでは、ディレクトリファイルを表現する場合、ディレクトリレコードを表す可変長レコードを線型な論理ブロック領域上に無秩序に並べている。即ち、ディレクトリ配下のファイル名が登録されたレコードが、ファイル名とは無関係に並べられている。従って、名前検索処理は、対象ディレクトリファイル全体の線型検索に結びつく。
なお、ディレクトリファイル全体の線形検索の発生を少なくするために、名前キャッシュを利用することができる。名前キャッシュは、一度参照されたディレクトリレコードをメモリ上にキャッシュしておき、同じファイル名に対するアクセスが発生したときは、キャッシュされたディレクトリレコードを取得するようにしたものである。ただし、名前キャッシュがシステム上の全ディレクトリエントリを管理できない以上（メモリ搭載量の制限）、一定の頻度で対象ディレクトリファイル全体の線型検索が発生してしまう。
特に近年ではファイルシステムの管理するデータ量の増大が著しく、膨大な数のファイルを配下に持つ巨大ディレクトリが珍しくなくなっている。ディレクトリが巨大化すればするほど、名前キャッシュのヒット率も低下する。そのため、ディレクトリファイル全体検索が発生する確率が高くなり、ファイルシステム全体の性能劣化に結びつくことがある。
この問題に対しては、ディレクトリファイルに、名前情報のインデックス表を持たせる、所謂ディレクトリインデックスが有効な解法であることが知られている。ディレクトリインデックスの実現方法として、これまで幾つかの手法が提案されてきている。以下に代表的なものを紹介する。
・第１の従来例
メインメモリ内にディレクトリインデックス表を構成する手法である。１回目の当該ディレクトリ検索時に、dirhashと呼ばれるindexを作成し、２回目以降の検索を高速化する。この方法では１回目の検索時間は改善されないが、ディレクトリファイルレイアウトを既存のものから一切変更しなくて良いというメリットがある（例えば、非特許文献１参照）。
・第２の従来例
メインメモリ外にディレクトリファイル毎に名前のハッシュ値をキーとするB+Treeを構成し、ディレクトリエントリをB+Treeのレコードとして管理する（例えば、非特許文献２参照）。
・第３の従来例
extensible hashingというハッシュ技術を用いて、名前を入力情報とするハッシュ関数によりディレクトリエントリの論理ブロック番号の候補を決定する。初めは１ブロックから開始し、ブロックが満杯になったらディレクトリサイズを２の階乗個のブロックまで拡張する。満杯になったらブロックはsplitし、ディレクトリエントリをハッシュ値に従って適切な論理ブロックのほうへ振り分ける（非特許文献３）。
・第４の従来例
既存の論理ブロックの線型空間上に、名前のハッシュ値をキーとするB+Treeを構成する。既存ディレクトリファイルのレイアウトを変更しなくても良いような工夫が施されている（非特許文献４）。
I.Dowse and D.Malone. "Recent File System Optimisation on FreeBSD". In Proc. of the USENIX Annual Technical Conference(FREENIX Track), Monterey, California. June 2002. A. Sweeney, et al. "Scalability in the XFS file system". In USENIX Technical Conference, pp1-14. Usenix, January 1996. F. Schmuck and R. Haskin. "GPFS: A Shared-Disk File System for Large Computing Clusters," In Proc. of the First Conference on File and Storage Technologies (FAST). January 2002. D. Phillips. "A Directory Index for EXT2," In Proceedings of the Fifth Annual Linux Showcase and Conference, November 2001.
しかし、これまで提案されてきた手法には以下の何れかの課題が残されている。
・第１の課題は、メモリ搭載量制限による性能向上の限界が存在することである。即ち、メモリ搭載量の制限から、巨大ディレクトリ用のインデックス表の構成、多数のディレクトリのインデックス表の同時構成が、根本的に実現しにくい。例えば「非特許文献１」の技術がこの課題を抱えている。すなわち、ディレクトリインデックス表はメインメモリ外で構成するほうが望ましい。
・第２の課題は、既存システムに対する大規模な変更が必要となる点である。ディレクトリファイルのインデックス表を、他のファイル種別とは全く個別に構成すると、システムの開発規模が嵩んでしまう。例えば「非特許文献２」の技術がこの課題を抱えている。すなわち、既存の制御方法を用い、開発規模の削減に努めるほうが望ましい。
・第３の課題は、論理ブロックの線型空間の利用による性能劣化が発生する点である。名前情報の集合や、それに対するインデックス表を、論理ブロックの線型空間上に構成すると、論理ブロックから物理ブロックへの変換をしなければ実際のブロックデータを求めることができない。そのため、処理速度が十分とは言えない。例えば「非特許文献３」や「非特許文献４」の技術が、この課題を抱えている。すなわち、名前から直接物理ブロックを求め、更なる性能改善に努めるほうが望ましい。
本発明はこのような点に鑑みてなされたものであり、extent方式のデータアクセス構造を利用して、ディレクトリファイルへの効率の良いデータアクセスを可能とするファイル管理プログラム、ファイル管理方法及びファイル管理装置を提供することを目的とする。
本発明では上記課題を解決するために、図１に示すような機能を有するファイル管理プログラムが提供される。ファイル管理プログラムは、コンピュータでストレージデバイス１内のファイルを管理するためのものである。ファイル管理プログラム実行するコンピュータは、ハッシュ値生成手段２、物理ブロック番号取得手段３、及びディレクトリ処理手段４として機能する。
ハッシュ値生成手段２は、処理対象ファイルの名前情報５ａを含む処理要求５を受け取ると、名前情報５ａに所定のハッシュ関数を適用し、処理対象ファイルのハッシュ値６を生成する。物理ブロック番号取得手段３は、ハッシュ値の包含範囲を定義したハッシュ値レンジと、ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表１ａを参照し、処理対象ファイルのハッシュ値６を包含するハッシュ値レンジが設定されたハッシュ値レンジ情報を抽出し、抽出したハッシュ値レンジ情報から物理ブロック番号７を取得する。ディレクトリ処理手段４は、物理ブロック番号取得手段３で取得された物理ブロック番号７に該当するストレージデバイス１内の物理ブロック１ｃから名前情報５ａを検索し、名前情報５ａを含むレコード１ｄに対して処理要求５に従った処理を行う。
このようなファイル管理プログラムを実行するコンピュータに、処理対象ファイルの名前情報５ａを含む処理要求５が入力されると、ハッシュ値生成手段２により、名前情報５ａに所定のハッシュ関数が適用され、処理対象ファイルのハッシュ値６が生成される。次に、物理ブロック番号取得手段３により、ハッシュ値レンジ表１ａが参照され、処理対象ファイルのハッシュ値６を包含するハッシュ値レンジが設定されたハッシュ値レンジ情報が抽出される。さらに物理ブロック番号取得手段３により、抽出されたハッシュ値レンジ情報から物理ブロック番号７が取得される。そして、ディレクトリ処理手段４により、物理ブロック番号取得手段３で取得された物理ブロック番号７に該当するストレージデバイス１内の物理ブロック１ｃに対して、名前情報５ａを含むレコード１ｄに関する処理要求５に従った処理が行われる。
また、上記課題を解決するために、コンピュータにより、ストレージデバイス内のファイルを管理するためのファイル管理方法において、ハッシュ値生成手段が、処理対象ファイルの名前情報を含む処理要求を受け取ると、前記名前情報に所定のハッシュ関数を適用し、前記処理対象ファイルのハッシュ値を生成し、物理ブロック番号取得手段が、前記ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記処理対象ファイルのハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得し、ディレクトリ処理手段が、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の前記物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行う、ことを特徴とするファイル管理方法が提供される。
また、上記課題を解決するために、ストレージデバイス内のファイルを管理するためのファイル管理装置において、処理対象ファイルの名前情報を含む処理要求を受け取ると、前記名前情報に所定のハッシュ関数を適用し、前記処理対象ファイルのハッシュ値を生成するハッシュ値生成手段と、前記ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記処理対象ファイルのハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得する物理ブロック番号取得手段と、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の前記物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行うディレクトリ処理手段と、を有することを特徴とするファイル管理装置が提供される。
本発明では、名前情報からハッシュ値を求め、ハッシュ値レンジ表を参照して物理ブロック番号を取得するようにした。これにより、名前情報を含むレコードに関する処理の対象が、物理ブロック番号で示された物理ブロックのみとなり、ディレクトリファイルへの効率の良いデータアクセスが可能となる。
以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。
図１は、実施の形態に適用される発明の概念図である。本発明は、ストレージデバイス１内のファイルを管理するためのものであり、ハッシュ値生成手段２、物理ブロック番号取得手段３、及びディレクトリ処理手段４によって構成される。
ストレージデバイス１には、ハッシュ値レンジ表１ａが格納されている。ハッシュ値レンジ表１ａには、ハッシュ値の包含範囲を定義したハッシュ値レンジと、ストレージデバイス１内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されている。
また、ストレージデバイス１内には、ディレクトリの情報が１以上の物理ブロック１ｃに格納されている。ディレクトリの情報には、そのディレクトリ直下のファイル（非ディレクトリファイルとディレクトリファイル）毎のレコード１ｄが含まれている。レコード１ｄは、ファイルの名前情報と、そのファイルの管理情報の識別情報（例えば、dinode番号）が含まれている。なお、非ディレクトリファイルの名前情報は、そのファイルのファイル名である。また、ディレクトリファイルの名前情報は、そのファイルで示されるディレクトリのディレクトリ名である。
ハッシュ値生成手段２は、処理対象ファイルの名前情報５ａを含む処理要求５を受け取ると、名前情報５ａに所定のハッシュ関数を適用し、処理対象ファイルのハッシュ値６を生成する。ハッシュ関数は、名前情報から有限ビット幅の整数値を生成する関数である。ハッシュ値生成手段２は、生成したハッシュ値６を物理ブロック番号取得手段３に渡す。
物理ブロック番号取得手段３は、ハッシュ値レンジ表１ａを参照し、処理対象ファイルのハッシュ値６を包含するハッシュ値レンジが設定されたハッシュ値レンジ情報を抽出する。次に、物理ブロック番号取得手段３は、抽出したハッシュ値レンジ情報から物理ブロック番号７を取得する。そして、物理ブロック番号取得手段３は、取得した物理ブロック番号７を、ディレクトリ処理手段４に渡す。
ディレクトリ処理手段４は、物理ブロック番号取得手段３で取得された物理ブロック番号７に該当するストレージデバイス１内の物理ブロック１ｃに対して、名前情報５ａを含むレコード１ｄに関する処理要求５に従った処理を行う。例えば、名前情報の削除を指示する処理要求５であれば、ディレクトリ処理手段４は、物理ブロック１ｃ内から名前情報５ａを含むレコードを検出し、そのレコードを物理ブロック１ｃから削除する。
このようなファイル管理プログラムを実行するコンピュータに、処理対象ファイルの名前情報５ａを含む処理要求５が入力されると、ハッシュ値生成手段２により、名前情報５ａに所定のハッシュ関数が適用され、処理対象ファイルのハッシュ値６が生成される。
次に、物理ブロック番号取得手段３により、ハッシュ値レンジ表１ａが参照され、処理対象ファイルのハッシュ値６を包含するハッシュ値レンジが設定されたハッシュ値レンジ情報が抽出される。さらに物理ブロック番号取得手段３により、抽出されたハッシュ値レンジ情報から物理ブロック番号７が取得される。
そして、ディレクトリ処理手段４により、物理ブロック番号取得手段３で取得された物理ブロック番号７に該当するストレージデバイス１内の物理ブロック１ｃに対して、名前情報５ａを含むレコード１ｄに関する処理要求５に従った処理が行われる。
これにより、名前情報で示された処理対象のデータを、物理ブロック番号で示された物理ブロックから検出すれば良くなり、ディレクトリファイルへの効率の良いデータアクセスが可能となる。すなわち、ディレクトリファイルの全体を線形検索する必要が無くなり、処理の効率化が図れる。
しかも、本発明は、既存のextentベースファイルシステムに対する追加機能として図１に示す機能を適用することが可能である。そのため、既に稼働しているコンピュータシステムに対して、容易に適用することができる。
すなわち、extentベースファイルシステムには、必ず論理ブロック番号と物理ブロック番号のextent表が存在する。そこで、extentベースファイルシステムに本発明を適用する際には、論理ブロック番号と物理ブロック番号のextent表を、ディレクトリファイルに限り、名前情報のハッシュ値と物理ブロックの対応関係を示すハッシュ値レンジ表に置き換える。そして、図１に示すハッシュ値生成手段２，物理ブロック番号取得手段３及びディレクトリ処理手段４の機能を、extentベースファイルシステムに追加する。
これにより、アクセスすべきファイルの名前情報から、そのファイルの管理情報の識別情報（例えば、dinode）を取得するまでの処理の高速化が図れる。すなわち、常に、名前情報から求められたハッシュ値に対応する物理ブロックを対象とし名前情報検索を行えばよく、検索対象が物理ブロックのサイズを超えることがない。従って、ファイルアクセスの時間が高速化される。
ところで、本発明は、ファイル数が膨大なシステムにおいて、特に大きな効果を発揮する。たとえば、ネットワークを介して接続されたストレージデバイスにシステム全体で共有するデータが格納され、そのデータの管理情報（dinode等）を別のデバイスに格納する場合がある。このように、データの実体と管理情報とを別のストレージデバイスに格納することにより、共有データへのアクセスを効率よく行うことができる。
そこで、データとそのデータの管理情報とを別のストレージデバイスで管理するシステムに本発明を適用した場合の例を、実施の形態として説明する。
図２は、本実施の形態のシステム構成を示す図である。このシステムでは、ネットワーク１０を介して、メタデータサーバ１００、アクセスクライアントホスト２１０，２２０，２３０、クライアント３１０，３２０，・・・が接続されている。
また、アクセスクライアントホスト２１０，２２０，２３０には、データボリューム４１０が接続されている。データボリューム４１０は、システム全体で共有する非ディレクトリファイルのデータが格納されたストレージデバイス（ハードディスクデバイス等）である。データボリューム４１０内のデータは、ファイル単位で格納されている。メタデータサーバ１００には、メタボリューム４２０が接続されている。メタボリューム４２０は、ファイルの管理情報が格納されたストレージデバイス（ハードディスクデバイス等）である。
メタデータサーバ１００は、メタボリューム４２０を用いて、データボリューム４１０内のファイルを管理する。具体的には、メタデータサーバ１００は、アクセスクライアントホスト２１０，２２０，２３０からの要求に応じて、ファイル名に対応するファイルを構成するデータの所在（物理ブロック番号）を応答する。また、メタデータサーバ１００は、アクセスクライアントホスト２１０，２２０，２３０から、ディレクトリファイルに対する処理要求が出された場合、指定されたディレクトリファイルの処理を行い、処理結果を応答する。
アクセスクライアントホスト２１０，２２０，２３０は、クライアント３１０，３２０，・・・からの要求に応じて、データボリューム４１０内の非ディレクトリファイルにアクセスする。なお、アクセスクライアントホスト２１０，２２０，２３０は、ファイルアクセスを行う際には、名前情報とファイル内でのオフセット情報とに基づいて、メタデータサーバ１００から、該当データが格納された物理ブロックの物理ブロック番号を取得する。そして、アクセスクライアントホスト２１０，２２０，２３０は、取得した物理ブロック番号に基づいて、データボリューム４１０にアクセスする。
クライアント３１０，３２０，・・・は、ユーザが操作する端末装置である。クライアント３１０，３２０，・・・は、ユーザの操作入力に応答して、アクセスクライアントホスト２１０，２２０，２３０に対してファイルアクセス等の要求を送信する。
図３は、本実施の形態に用いるメタデータサーバのハードウェア構成例を示す図である。メタデータサーバ１００は、ＣＰＵ(Central Processing Unit)１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ(Random Access Memory)１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および通信インタフェース１０６が接続されている。
ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。
グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。
通信インタフェース１０６は、ネットワーク１０に接続されている。通信インタフェース１０６は、ネットワーク１０を介して、他のコンピュータとの間でデータの送受信を行う。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３にはメタデータサーバ１００のハードウェア構成のみを示したが、アクセスクライアントホスト２１０，２２０，２３０やクライアント３１０，３２０，・・・も同様のハードウェア構成で実現することができる。
以下、クライアント３１０からのファイルアクセス要求がアクセスクライアントホスト２１０に出力された場合を例に採り、本システムでのファイルアクセス機能を具体的に説明する。
図４は、ファイルアクセスの流れを示す概念図である。アクセスクライアントホスト２１０には、アプリケーション２１１、アクセス管理部２１２、ＯＳ２１３の機能が設けられている。アプリケーション２１１は、クライアント３１０に対して各種サービスを提供する処理機能である。アクセス管理部２１２は、アプリケーション２１１を介して受け取ったファイルアクセス要求に応じて、データボリューム４１０内のファイルを操作する処理機能である。ＯＳ２１３は、アクセスクライアントホスト２１０全体を管理していると共に、データボリューム４１０に対するアクセスを行うファイルシステムを有している。
メタデータサーバ１００は、メタデータ管理部１１０、及びＯＳ１２０を有している。ＯＳ１２０は、メタデータサーバ１００全体を管理していると共に、データボリューム４１０に対するアクセスを行うファイルシステムを有している。
このような構成のシステムにおいて、例えば、クライアント３１０からアクセスクライアントホスト２１０に処理要求が出される。すると、アクセスクライアントホスト２１０のアプリケーション２１１は、要求された処理を実行し、その処理がファイルアクセスを伴うとき、そのファイルのアクセス要求をアクセス管理部２１２に渡す。アクセス管理部２１２は、アプリケーション２１１からのアクセス要求で示される名前情報とファイル内でのオフセット情報を指定して、メタデータサーバ１００に対してファイルを構成するデータの位置（物理ブロック番号）を問い合わせる。
メタデータ管理部１１０は、ＯＳ１２０を介してメタボリューム４２０にアクセスし、アクセスクライアントホスト２１０からの要求に応じた処理を行う。処理の内容は、処理対象が非ディレクトリファイルの管理情報なのか、ディレクトリファイルの管理情報なのかによって異なる。
非ディレクトリファイルが処理対象の場合、メタデータ管理部１１０がメタボリューム４２０にアクセスし、アクセスクライアントホスト２１０から指定された名前情報とオフセット情報との組に対応する物理ブロック番号を取得する。そして、メタデータ管理部１１０は、取得した物理ブロック番号をアクセスクライアントホスト２１０に対して送信する。
また、ディレクトリファイルの管理情報が処理対象の場合、メタデータ管理部１１０がメタボリューム４２０にアクセスし、ディレクトリファイルに対して要求に応じた処理を行う。そして、メタデータ管理部１１０が、処理結果をアクセスクライアントホスト２１０に応答する。
アクセスクライアントホスト２１０では、アクセス管理部２１２が、メタデータサーバ１００から受け取った物理ブロック番号に基づいて、データボリューム４１０内の該当ファイルにアクセスする。そして、アクセス管理部２１２は、アクセスの結果をアプリケーション２１１に返す。アプリケーション２１１は、ファイルアクセスを伴う処理を完了し、その結果をクライアント３１０に通知する。
このようにして、アクセスクライアントホスト２１０は、データボリューム４１０に格納されたファイルにアクセスすることができる。また、アクセスクライアントホスト２１０は、メタボリューム４２０内のディレクトリファイルのデータを変更することもできる。
次に、メタデータ管理部１１０の機能を詳細に説明する。
図５は、メタデータ管理部の機能を示すブロック図である。メタデータ管理部１１０は、要求受付部１１１、ハッシュ値生成部１１２、物理ブロック番号取得部１１３、ディレクトリ処理部１１４、及び結果通知部１１５を有している。
要求受付部１１１は、アクセスクライアントホスト２１０からの要求を受け付ける。処理対象が非ディレクトリフィアルであれば、要求受付部１１１は、処理要求を物理ブロック番号取得部１１３に渡す。また、処理対象がディレクトリファイルであれば、要求受付部１１１は、処理要求をハッシュ値生成部１１２に渡す。
ハッシュ値生成部１１２は、処理要求において名前情報に関する情報が含まれている場合、その名前情報を所定のハッシュ関数に基づいてハッシュ値に変換する。例えば、ハッシュ値生成部１１２は、処理要求がファイル名を指定した検索要求であれば、指定されたファイル名をハッシュ値に変換する。そして、ハッシュ値生成部１１２は、生成したハッシュ値と処理要求とを、物理ブロック番号取得部１１３に渡す。
なお、ハッシュ値を生成するためのハッシュ関数としては、例えば、以下のような例がある。以下の例では、３２ビットのデータでハッシュ値が表されるものとする。
・ハッシュ関数の第１の例
名前情報を構成する全文字の文字コードを足し合わせる。２32−１の値を超えた場合、超えた分のデータ（例えば、３２ビットを超えた上位のビット）は切り捨てる。
・ハッシュ関数の第２の例
名前情報を構成する文字列の先頭から、適当なバイト幅（例えば、４バイト）の部分的文字列を繰り返し抽出する。そして、部分的文字列を抽出する毎に、先に抽出されている部分的文字列との間でＸＯＲ演算（排他的論理和演算）を行う。名前情報の文字列の最後まで部分的文字列の抽出及びＸＯＲ演算が完了したとき、最後のＸＯＲ演算の結果をハッシュ値とする。
物理ブロック番号取得部１１３は、メタボリューム４２０に格納されている管理情報を参照し、受け取った処理要求に基づいて物理ブロック番号を取得する。例えば、非ディレクトリファイルに関する処理要求であれば、物理ブロック番号取得部１１３は、処理対象として指定されているファイルに対応するextent表を取得し、そのファイル内の処理対象となるデータが格納された物理ブロック番号を取得する。その場合、物理ブロック番号取得部１１３は、取得した物理ブロック番号を、結果通知部１１５に渡す。
また、ディレクトリファイルに対する処理要求の場合、物理ブロック番号取得部１１３は、処理対象となるディレクトリファイルのハッシュ値レンジ表を取得し、処理要求で指定されたファイル名のハッシュ値から、そのファイル名に関する情報が格納された物理ブロック番号を取得する。この場合、物理ブロック番号取得部１１３は、取得した物理ブロック番号と処理要求とをディレクトリ処理部１１４に渡す。
ディレクトリ処理部１１４は、物理ブロック番号取得部１１３から物理ブロック番号と処理要求とを受け取ると、メタボリューム４２０内の物理ブロック番号に対応するブロックに対してアクセスし、該当するブロック内のデータを取得する。そして、取得したデータに対して、処理要求で示される処理を施す。実行された処理により、取得したデータの内容が更新された場合、ディレクトリ処理部１１４は、更新されたデータを元の物理ブロックに格納する。
次に、データボリューム４１０とメタボリューム４２０とのデータ構造について説明する。
図６は、ボリューム内のデータ構造例を示す図である。データボリューム４１０内の記憶領域は、複数の物理ブロック４１１，４１２，・・・で構成されている。各物理ブロック４１１，４１２，・・・には、非ディレクトリファイルのデータ４１１ａ，４１２ａ，・・・が格納されている。
メタボリューム４２０には、非ディレクトリファイル管理情報４２０ａとディレクトリファイル管理情報４２０ｂとが格納されている。なお、非ディレクトリファイル管理情報４２０ａとディレクトリファイル管理情報４２０ｂとは、メタボリューム４２０内の所定の物理ブロックに格納されている。
非ディレクトリファイル管理情報４２０ａは、ファイル毎に設けられた複数のdinode４２１、各dinode４２１に関連付けられたextent表４２２で構成される。dinode４２１には、非ディレクトリファイル内のデータの論理ブロック番号等の各種管理情報（ファイル名とデータの実体を除く）が含まれている。また、dinode４２１には、対応するextent表４２２に対するポインタも含まれている。
extent表４２２には、非ディレクトリファイルを構成するデータを格納した物理ブロックに対応する１以上のextent情報４２２ａ，４２２ｂ，４２２ｃ，４２２ｄ，４２２ｅが含まれている。extent情報４２２ａ，４２２ｂ，４２２ｃ，４２２ｄ，４２２ｅを参照することで、非ディレクトリファイルを構成するデータの論理ブロック番号から、対応する物理ブロック番号を取得することができる。図６の例では、extent情報４２２ｄが物理ブロック４１１に対応し、extent情報４２２ｅが物理ブロック４１２に対応する。なお、extent表４２２の内容の詳細は、後述する（図７参照）。
ディレクトリファイル管理情報４２０ｂは、ディレクトリファイル毎に設けられた複数のdinode４２３、各dinode４２３に関連付けられたハッシュ値レンジ表４２４で構成される。dinode４２３には、ディレクトリファイルへのアクセス制限等の各種管理情報（ディレクトリファイル名とデータの実体を除く）が含まれている。また、dinode４２３には、対応するハッシュ値レンジ表４２４に対するポインタも含まれている。
ハッシュ値レンジ表４２４には、ファイルを構成するデータを格納した物理ブロックに対応する１以上のハッシュ値レンジ情報４２４ａ，４２４ｂ，４２４ｃ，４２４ｄ，４２４ｅが含まれている。ハッシュ値レンジ情報４２４ａ，４２４ｂ，４２４ｃ，４２４ｄ，４２４ｅを参照することで、ファイル名のハッシュ値から、そのファイルに関する情報が格納された物理ブロック番号を取得することができる。図６の例では、ハッシュ値レンジ情報４２４ｄが物理ブロック４２５に対応し、ハッシュ値レンジ情報４２４ｅが物理ブロック４２６に対応する。なお、ハッシュ値レンジ表４２４の内容の詳細は、後述する（図９参照）。
複数の物理ブロック４２５，４２６，・・・には、ディレクトリファイルの内容が格納されている。ディレクトリファイルは、そのディレクトリの直下のファイルに関する情報が登録されたレコード４２５ａ，４２５ｂ，４２６ａ，４２６ｂが含まれている。各レコード４２５ａ，４２５ｂ，４２６ａ，４２６ｂは、ファイルの名前情報とそのファイルのdinode番号とで構成される。
このように、ディレクトリファイルのオフコア制御データ（メインメモリ外で管理される制御情報）は、大別して、dinode４２３、ハッシュ値レンジ表４２４、物理ブロック４２５，４２６の三要素から構成される。
ファイルは、ディレクトリに限らず、dinode４２１，４２３というデータ構造を中心に管理される。dinode４２１，４２３内には、当該ファイルのデータサイズや、ファイルタイプ、アクセス権限などが格納される。なお、dinode４２１，４２３内にはextent情報４２２ａ，４２２ｂ，４２２ｃ，４２２ｄ，４２２ｅやハッシュ値レンジ情報４２４ａ，４２４ｂ，４２４ｃ，４２４ｄ，４２４ｅの一部を格納することは可能であるが、本実施の形態では、extent情報４２２ａ，４２２ｂ，４２２ｃ，４２２ｄ，４２２ｅは全てextent表４２２に格納され、ハッシュ値レンジ情報４２４ａ，４２４ｂ，４２４ｃ，４２４ｄ，４２４ｅは全てハッシュ値レンジ表４２４に格納されているものとする。この場合、dinode４２１，４２３には、extent表４２２またはハッシュ値レンジ表４２４へのポインタが設定される。
extent表４２２は、該当ファイルの論理ブロックレンジと物理ブロックレンジとの対応表である。論理ブロックとは、ユーザから見える線型なファイルイメージの固定長の構成要素である。一方物理ブロックとは、ストレージデバイス上に格納されるファイルイメージの実体である。任意のファイルを構成するデータは、一般にストレージ上では線型な空間には格納されることはない。このため論理ブロックから、それに対応する物理ブロックの位置情報を得るために、extent表４２２が必要となる。extent情報４２２ａ，４２２ｂ，４２２ｃ，４２２ｄ，４２２ｅには論理ブロックレンジの開始番号と、それに対応する物理ブロックレンジの開始番号、およびレンジの幅が格納される。
一方、ディレクトリファイルに対応するハッシュ値レンジ表４２４では、ハッシュ値レンジと物理ブロックとの対応を示すハッシュ値レンジ情報が格納される。そして、ハッシュ値レンジ情報で位置情報が管理される物理ブロック４２５，４２６内には、ハッシュ値レンジ情報のハッシュ値レンジの範囲内のハッシュ値が生成されるファイルのレコードが格納される。
物理ブロック４１１，４１２，４２５，４２６は、当該ファイルのユーザデータもしくはディレクトリデータを格納するものである。非ディレクトリファイルの１つextent情報では物理ブロックレンジによってデータが格納された物理ブロックが指定される。そのレンジは可変長である（extent情報に長さが管理される）。従って、１つextent情報からストレージ上で互いに隣接する複数の物理ブロックが指定されることがある。
一方、ディレクトリファイルのハッシュ値レンジ情報では、物理ブロックレンジは固定長である。本実施形態では、レンジ長を１（単一物理ブロックで構成されるレンジ）としている。
次に、extent表のデータ構造例と、そのextent表を用いた非ディレクトリファイルへのアクセス方法について説明する。
図７は、extent表のデータ構造例を示す図である。extent表４２２には、非ディレクトリファイルを構成するデータの論理ブロック番号、データの長さ、及び物理ブロック番号が、互いに関連づけられて登録されている。そして、関連付けられた、論理ブロック番号、データの長さ、及び物理ブロック番号の組によって、extent情報４２２ａ，４２２ｂ，・・・が構成されている。
論理ブロック番号は、非ディレクトリファイルを構成するデータの論理ブロックの先頭の番号を示している。長さは、対応する論理ブロックのデータ長を示している。物理ブロック番号は、対応する論理ブロックに含まれるデータのデータボリューム４１０内での格納位置（物理ブロックレンジ）の先頭の物理ブロックの識別番号を示している。
このようなextent表４２２に基づいて、以下のようなアクセスが行われる。
図８は、非ディレクトリファイルへのアクセス状況を示す図である。図８には、非ディレクトリファイルのデータイメージ２０を示している。非ディレクトリファイル内の任意のデータにアクセスする場合、そのファイルの先頭からのオフセットでアクセス対象が指定される。図８の例では、先頭から所定の長さのデータ２１（内容を「データＡ」とする）が配置され、そのデータ２１に続けてファイルの最後（ＥＯＦ）までデータ２２（内容を「データＢ」とする）が配置されている。
例えば、アクセスクライアントホスト２１０のアクセス管理部２１２は、アプリケーション２１１から任意のファイル内の所定のデータに対するアクセス要求を受け取ると、そのデータのオフセット（ファイルの先頭からのデータまでの長さ）を取得する。そして、アクセス管理部２１２は、そのファイル名とオフセットとを含む処理要求を、メタデータサーバ１００に対して送信する。
メタデータサーバ１００では、要求受付部１１１が、非ディレクトリファイルへのアクセスであることを判断し、処理要求を物理ブロック番号取得部１１３に渡す。すると、物理ブロック番号取得部１１３により、メタボリューム４２０から、該当ファイルのdinodeが取得される。なお、物理ブロック番号取得部１１３は、予めdinode番号が分かっている場合には、該当するdinodeが取得する。dinode番号が不明の場合は、物理ブロック番号取得部１１３は、ファイルが存在するディレクトリのディレクトリファイルから、名前情報に対応するdinode番号を取得する。そして、物理ブロック番号取得部１１３は、取得したdinode番号に該当するdinodeを取得する。
物理ブロック番号取得部１１３は、取得したdinodeを参照し、アクセス対象のデータのオフセットから論理ブロック番号を取得する。さらに、物理ブロック番号取得部１１３は、dinodeに対応するextent表を参照し、取得した物理ブロック番号に対応する論理ブロック番号を取得する。
取得された物理ブロック番号は、物理ブロック番号取得部１１３から結果通知部１１５に渡される。結果通知部１１５は、受け取った物理ブロック番号をアクセス管理部２１２に渡す。これにより、アクセス管理部２１２がデータボリューム４１０内の該当物理ブロックにアクセスできる。
例えば、「データＡ」へのアクセスであれば、論理ブロック番号［５０］が取得されたものとする。このとき、図７に示すextent表４２２のextent情報４２２ａが参照される。そして、extent情報４２２ａに基づき、物理ブロック番号［３００］が得られる。その結果、アクセス管理部２１２は、データボリューム４１０内の「データＡ」が格納された物理ブロック４１３にアクセスできる。
また、「データＢ」へのアクセスであれば、論理ブロック番号［１０５］が取得される。すると、extent表４２２内の先頭のextent情報４２２ｂに基づき、物理ブロック番号［５０］が得られる。その結果、アクセス管理部２１２は、データボリューム４１０内の「データＢ」が格納された物理ブロック４１４にアクセスできる。
次に、ハッシュ値レンジ表のデータ構造例と、そのディレクトリ表を用いたディレクトリファイルへのアクセス方法について説明する。
図９は、ハッシュ値レンジ表のデータ構造例を示す図である。ハッシュ値レンジ表４２４には、ハッシュ値レンジ開始値、データの長さ、及び物理ブロック番号が、互いに関連づけられて登録されている。そして、関連付けられた、ハッシュ値レンジ開始値、データの長さ、及び物理ブロック番号の組によって、ハッシュ値レンジ情報４２４ａ，４２４ｂ，・・・が構成されている。
ハッシュ値レンジ開始値は、ファイル名から生成されるハッシュ値のうち、当該ハッシュ値レンジ情報に該当するハッシュ値の範囲（ハッシュ値レンジ）の先頭の値を示している。データの長さは、該当するハッシュ値の範囲の長さを示している。ハッシュ値レンジ開始値とデータの長さとにより、ハッシュ値レンジが一意に決まる。物理ブロック番号は、ファイルの名前情報を含むレコードを格納する物理ブロックの番号を示している。
このようなハッシュ値レンジ表４２４に基づいて、以下のようなアクセスが行われる。
図１０は、ディレクトリファイルへのアクセス状況を示す図である。図１０には、ハッシュ値レンジイメージ３０を示している。図１０の例では、ハッシュ値下限とハッシュ値上限との間が、ハッシュ値レンジ３１とハッシュ値レンジ３２とに分けられている。
レンジディレクトリファイル配下の任意のファイルに対応するレコードにアクセスする場合、ハッシュ値生成部１１２によって、ファイル名からハッシュ値が生成される。すると、物理ブロック番号取得部１１３が、メタボリューム４２０からハッシュ値レンジ表４２４を取得し、生成されたハッシュ値に対応する物理ブロック番号を取得する。
例えば、アクセスクライアントホスト２１０のアクセス管理部２１２が、アプリケーション２１１から任意のディレクトリへのファイルの追加要求を受け取ったものとする。その場合、アクセス管理部２１２は、ディレクトリの指定（木構造上のファイルパス）とファイル名とを含む処理要求を、メタデータサーバ１００に送信する。
メタデータサーバ１００では、要求受付部１１１が、ディレクトリファイルへのアクセスであることを判断し、処理要求をハッシュ値生成部１１２に渡す。ハッシュ値生成部１１２は、所定のハッシュ関数に従って、ファイル名からハッシュ値を生成する。生成されたハッシュ値は、処理要求と共に物理ブロック番号取得部１１３に渡される。
物理ブロック番号取得部１１３は、メタボリューム４２０から処理対象のディレクトリファイルに対応するdinodeを取得する。次に、物理ブロック番号取得部１１３は、取得したdinodeに対応するハッシュ値レンジ表４２４を参照し、受け取ったハッシュ値をハッシュ値レンジ内に含むハッシュ値レンジ情報を抽出する。そして、物理ブロック番号取得部１１３は、抽出したハッシュ値レンジ情報に基づいて、ハッシュ値に対応する論理ブロック番号を取得する。
取得された物理ブロック番号は、物理ブロック番号取得部１１３からディレクトリ処理部１１４に渡される。ディレクトリ処理部１１４は、受け取った物理ブロック番号で指定された物理ブロック内のデータに対し、処理要求で指定されている処理を行う。例えば、ディレクトリ配下へのファイルの追加が指定されていれば、追加されるファイルのレコード（ファイル名とdinode番号とを含む）を、該当する物理ブロック内に格納する。ディレクトリ処理部１１４による処理の結果（例えば、ファイルの追加が成功終了した旨のメッセージ）は、結果通知部１１５に渡される。結果通知部１１５は、受け取った処理結果をアクセス管理部２１２に渡す。
例えば、図９に示すような内容のハッシュ値レンジ表４２４の場合に、ファイル名から生成されたハッシュ値が［７０］であれば、ハッシュ値レンジ情報４２４ａに基づいて、物理ブロック番号［２００］が得られる。その結果、その物理ブロック番号に該当する物理ブロック４２７に対して処理が行われる。また、ファイル名から生成されたハッシュ値が［１６０］であれば、ハッシュ値レンジ情報４２４ｂに基づいて、物理ブロック番号［４０］が得られる。その結果、その物理ブロック番号に該当する物理ブロック４２８に対して処理が行われる。
このようにして、ディレクトリファイルを構成するデータに対して、任意の処理を行うことができる。ディレクトリファイルに対する処理要求は、主に以下の４種類がある。
・名前挿入（direnter）
アプリケーション２１１からディレクトリ配下へのファイル追加指示が出されたときに、アクセス管理部２１２により、ディレクトリファイルに対する名前挿入の処理要求が出される。ＵＮＩＸ（登録商標）系のＯＳであれば、CREATE、MKDIR、SYMLINKなどのＩ／Ｏ要求が発生したとき、指定された親ディレクトリの配下にファイルが作成される。このとき親ディレクトリのディレクトリファイル内に、作成されたファイルのレコード（名前情報とdinode番号）が挿入される。
・名前削除（dirremove）
アプリケーション２１１から任意のディレクトリからのファイルの削除指示が出されたときに、アクセス管理部２１２により、ディレクトリファイルに対する名前削除の処理要求が出される。ＵＮＩＸ系のＯＳであれば、REMOVE・RMDIRなどのＩ／Ｏ要求が発生したとき、指定されたファイルの名前情報が、その親ディレクトリから削除される。
・名前検索（lookup）
アプリケーション２１１からディレクトリ配下に任意のファイル名のファイルがあるか否かの確認指示が出されたとき、アクセス管理部２１２により、ディレクトリファイルに対する名前検索の処理要求が出される。ＵＮＩＸ系のＯＳであれば、LOOKUP要求が発生したとき、指定された親ディレクトリの直下から、指定された名前を持つファイル（非ディレクトリファイルもしくはディレクトリファイル）が検索される。
・名前列挙（readdir）
アプリケーション２１１からディレクトリ配下の全ファイルのファイル名の取得指示が出された際に、アクセス管理部２１２により、名前列挙の処理要求が出される。ＵＮＩＸ系のＯＳであれば、READDIR要求が発生したとき、指定親ディレクトリの管理する直下のファイル／ディレクトリの全名前情報が列挙される。
以下に、各処理要求が出された際のメタデータ管理部１１０における処理手順を、フローチャートを用いて説明する。
図１１は、名前挿入処理のフローチャートを示す図である。以下、図１１に示す処理をステップ番号に沿って説明する。なお、この処理は、アクセス管理部２１２からメタデータ管理部１１０に対して、名前挿入を指示する処理要求が出されたときに実行される。
［ステップＳ１１］処理要求は、要求受付部１１１からハッシュ値生成部１１２に渡される。すると、ハッシュ値生成部１１２により、ファイル名がハッシュ値に変換される。具体的には、ハッシュ値生成部１１２は、挿入を指定されたファイル名にハッシュ関数をかけて、有限ビット幅の整数値に変換する。これによって得られた整数値がハッシュ値である。生成されたハッシュ値は、物理ブロック番号取得部１１３に渡される。
［ステップＳ１２］物理ブロック番号取得部１１３は、ハッシュ値レンジ情報を特定する。具体的には、物理ブロック番号取得部１１３は、処理対象のディレクトリファイルのdinodeを参照し、対応するハッシュ値レンジ表を取得する。そして、物理ブロック番号取得部１１３は、取得したハッシュ値レンジ表に登録されているハッシュ値レンジ情報の中から、ステップＳ１１で得られたハッシュ値をハッシュ値レンジに含むものを特定する。さらに、物理ブロック番号取得部１１３は、特定したハッシュ値レンジ情報で示される物理ブロック番号をディレクトリ処理部１１４に渡す。
［ステップＳ１３］ディレクトリ処理部１１４は、レコードを挿入すべき物理ブロックを読み出す。具体的には、ディレクトリ処理部１１４は、物理ブロック番号取得部１１３から受け取った物理ブロック番号に対応する物理ブロックから、格納されているデータを全て読み出す。
［ステップＳ１４］ディレクトリ処理部１１４は、挿入位置及び挿入の可否を判定する。具体的には、ディレクトリ処理部１１４は、ステップＳ１３で読み出した物理ブロックから、指定されたファイル名のレコードを格納可能な位置を検索する。さらに、ディレクトリ処理部１１４は、新たにレコードを挿入したときに、物理ブロック内のデータ量（データの容量（バイト数）またはレコード数）が所定の上限値を超えるか否か（オーバフローの有無）を判断する。データ量が所定量を超えてしまう場合、挿入不可と判断される。なお、格納されているレコード数が所定値を超えた場合に、挿入不可と判断することもできる。
［ステップＳ１５］ディレクトリ処理部１１４は、挿入可能と判断されたか否かによって、処理を分岐させる。挿入可能であれば、処理がステップＳ１６に進められる。挿入不可能であれば、処理がステップＳ１７に進められる。
［ステップＳ１６］ディレクトリ処理部１１４は、挿入可能な場合、ステップＳ１３で読み出した物理ブロックのデータに名前情報とdinodeとを含むレコードを挿入し、元の物理ブロックに書き戻す。その後、処理が終了する。
［ステップＳ１７］ディレクトリ処理部１１４は、挿入が不可能な場合、ステップＳ１２のハッシュ値レンジ情報を、ハッシュ値を元に２分割（スプリット）する。即ち、ハッシュ値レンジを２つのハッシュ値レンジに分割し、それぞれに対応するハッシュ値レンジ情報を生成する。そして、一方（例えば、ハッシュ値レンジの値が大きい方）のハッシュ値レンジ情報の物理ブロック番号には、ステップＳ１３で特定された物理ブロック番号が設定される。他方のハッシュ値レンジ情報には、新たなメタボリューム４２０内の空きの物理ブロックのブロック番号が設定される。
［ステップＳ１８］ディレクトリ処理部１１４は、元から使用されていた物理ブロック内のレコードを、新たに獲得した物理ブロックに移動する。具体的には、ディレクトリ処理部１１４は、ステップＳ１７の分割の結果、新たに生成したハッシュ値レンジ情報に対応する物理ブロックをアロケート（使用領域として確保すること）する。また、ディレクトリ処理部１１４は、他方のハッシュ値レンジ情報に対応する物理ブロック内のレコードの半分を、アロケートした物理ブロックに移動する。
［ステップＳ１９］ディレクトリ処理部１１４は、ステップＳ１７で分割したハッシュ値レンジ情報のうち、ステップＳ１１で生成したハッシュ値を包含するハッシュ値レンジが設定された方を選択する。更に、ディレクトリ処理部１１４は、選択したハッシュ値レンジ情報に対応する物理ブロックのデータに対して、名前情報とdinodeとを含むレコードを挿入する。そして、ディレクトリ処理部１１４は、レコードを挿入したデータを、元の物理ブロックに書き戻す。その後、処理が終了する。
このように、名前挿入処理を行う場合、挿入対象となる物理ブロックの空き容量が所定値以下になると、ハッシュ値レンジ情報の分割が行われる。これにより、ハッシュ値レンジ情報に対応する物理ブロックのサイズを一定に保つことができる。
なお、ステップＳ１７においては、説明の簡単化のために、ハッシュ値レンジを２分割するものとしているが、物理ブロック内に格納済みの名前情報のハッシュ値分布に従って分割点をずらすこともできる。
図１２は、ハッシュ値レンジが分割される様子を示す図である。図１２の例では、ハッシュ値が３２ビットのデータで表される場合の例である。
第１の状態（ＳＴ１）は、ディレクトリファイルの作成直後の状態を示している。ディレクトリファイルが作成されたときは、ハッシュ値レンジ情報には、０〜２32−１の範囲のハッシュ値レンジ４１が設定される。そして、ハッシュ値レンジ情報で示される物理ブロック番号［３００」に該当する物理ブロック５１にレコードが格納される（図１２では、格納されたレコードを編みかけで示している）。
第２の状態（ＳＴ２）は、物理ブロック５１に格納されるレコードの量が増加した状態を示している。この状態では、物理ブロック５１内の空き容量が少ない。そこで、名前挿入の処理要求が出されると、ハッシュ値レンジ４１が分割される。
第３の状態（ＳＴ３）は、分割後のハッシュ値レンジ４２，４３を示している。この例では、元のハッシュ値レンジ４１を２等分している。ハッシュ値レンジ４２には物理ブロック番号［５２０］の物理ブロック５２が対応付けられており、ハッシュ値レンジ４３には物理ブロック番号［３００］の物理ブロック５１が対応付けられている。新たな物理ブロック５２が確保されたことで、名前情報から生成されるハッシュ値が、ハッシュ値レンジ４３の範囲内とレコードは、物理ブロック５１から物理ブロック５２に移される。
第４の状態（ＳＴ４）は、物理ブロック５２内のレコードが増加した状態を示している。この状態から、更にレコードが増加すると、ハッシュ値レンジ４２が更に分割される。
第５の状態（ＳＴ５）は、ハッシュ値レンジ４２が分割され、ハッシュ値レンジ４４，４５が生成されている。ハッシュ値レンジ４４には物理ブロック番号［３４０］の物理ブロック５３が対応付けられており、ハッシュ値レンジ４５には物理ブロック番号［５２０］の物理ブロック５２が対応付けられている。
このように、物理ブロックに格納されるレコード（名前情報とdinode番号）の量（データ量またはレコード数）が所定値以上になるとハッシュ値レンジが分割され、新たなハッシュ値レンジ情報が生成されると共に、新たに物理ブロックがアロケートされる。これにより、ディレクトリ直下のファイル数が増大しても、物理ブロック内のレコード数が過大になることはない。従って、物理ブロック内のデータに対する名前情報による線形検索を、常に短時間で実行することが可能となる。
次に、名前削除処理の手順について説明する。
図１３は、名前削除処理の手順を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。なお、この処理は、アクセス管理部２１２からメタデータ管理部１１０に対して、名前削除を指示する処理要求が出されたときに実行される。
［ステップＳ２１］処理要求は、要求受付部１１１からハッシュ値生成部１１２に渡される。すると、ハッシュ値生成部１１２により、ファイル名がハッシュ値（有限ビット幅の整数値）に変換される。生成されたハッシュ値は、物理ブロック番号取得部１１３に渡される。
［ステップＳ２２］物理ブロック番号取得部１１３は、ハッシュ値レンジ情報を特定する。具体的には、物理ブロック番号取得部１１３は、処理対象のディレクトリファイルのdinodeを参照し、対応するハッシュ値レンジ表を取得する。そして、物理ブロック番号取得部１１３は、取得したハッシュ値レンジ表に登録されているハッシュ値レンジ情報の中から、ステップＳ２１で得られたハッシュ値をハッシュ値レンジに含むものを特定する。さらに、物理ブロック番号取得部１１３は、特定したハッシュ値レンジ情報で示される物理ブロック番号をディレクトリ処理部１１４に渡す。
［ステップＳ２３］ディレクトリ処理部１１４は、レコードを削除すべき物理ブロックを読み出す。具体的には、ディレクトリ処理部１１４は、物理ブロック番号取得部１１３から受け取った物理ブロック番号に対応する物理ブロックから、格納されているデータを全て読み出す。
［ステップＳ２４］ディレクトリ処理部１１４は、読み出した物理ブロック内のデータから、削除対象の名前情報を線形検索し、該当する名前情報を有するレコードを削除する。
［ステップＳ２５］ディレクトリ処理部１１４は、物理ブロック内のデータ量（データの容量（バイト数）またはレコード数）を判定する。具体的には、ステップＳ２４でレコードを削除した結果、物理ブロック内のデータ量が所定の下限値以下（アンダーフロー）になったか否かを判定する。
［ステップＳ２６］ディレクトリ処理部１１４は、アンダーフローが発生したか否かに応じて、処理を分岐させる。アンダーフローが発生した場合、処理がステップＳ２７に進められる。アンダーフローが発生していない場合、処理が終了する。
［ステップＳ２７］ディレクトリ処理部１１４は、ハッシュ値レンジ情報を統合する。具体的には、ディレクトリ処理部１１４は、ステップＳ２２で特定したハッシュ値レンジ情報（移動元）のハッシュ値レンジに対して、ハッシュ値レンジが隣接する他のハッシュ値レンジ情報（統合先）を選択する。そして、移動元のハッシュ値レンジ情報と統合先のハッシュ値レンジ情報とのそれぞれのハッシュ値レンジを包含するハッシュ値レンジを生成し、そのハッシュ値レンジを統合先のハッシュ値レンジ情報のハッシュ値レンジとする。
［ステップＳ２８］ディレクトリ処理部１１４は、物理ブロックをディアロケートする。具体的には、ディレクトリ処理部１１４は、ステップＳ２３で読み出した物理ブロック内のレコード（ステップＳ２４においてレコードを削除済）を、統合先のハッシュ値レンジ情報に対応する物理ブロックに挿入する。そして、ディレクトリ処理部１１４は、ステップＳ２３で読み出した物理ブロック（移動元）を、ディアロケートする。その後、処理が終了する。
なお、ステップＳ２６のアンダーフロー判定において、当該物理ブロック内に名前情報が皆無となった場合にアンダーフローとすることもできる。その場合、ステップＳ２８の名前情報の移動処理は不要となる。これは、開発規模縮小の上では有効である。
更に、ステップＳ２７のハッシュ値レンジ情報の統合において、統合先のハッシュ値レンジ情報を２つ選択することもできる（３つのハッシュ値レンジ情報を１つに統合する）。また、隣接する２つのハッシュ値レンジ情報から、物理ブロックの利用率が低い方を統合対象として選択することもできる。
図１４は、ハッシュ値レンジ情報統合状況を示す図である。統合前の状態（ＳＴ１１）では、ハッシュ値の空間が３つのハッシュ値レンジ４３，４４，４５に分けられている。この状態で、ハッシュ値レンジ４５に対応する物理ブロック５２（物理ブロック番号［５２０］からのレコードの削除が発生し、物理ブロック５２内のレコード数が下限値以下になった場合、ハッシュ値レンジ情報の統合が行われる。
統合後の状態（ＳＴ１２）では、ハッシュ値レンジ４５とハッシュ値レンジ４４とが統合され、ハッシュ値レンジ４２となっている。また、物理ブロック５２に格納されていたレコードは、統合先として選択されたハッシュ値レンジ４４に対応する物理ブロック５３に移動されている。
次に、名前検索処理の手順について説明する。
図１５は、名前検索処理の手順を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。なお、この処理は、アクセス管理部２１２からメタデータ管理部１１０に対して、名前検索を指示する処理要求が出されたときに実行される。
［ステップＳ３１］処理要求は、要求受付部１１１からハッシュ値生成部１１２に渡される。すると、ハッシュ値生成部１１２により、ファイル名がハッシュ値（有限ビット幅の整数値）に変換される。生成されたハッシュ値は、物理ブロック番号取得部１１３に渡される。
［ステップＳ３２］物理ブロック番号取得部１１３は、ハッシュ値レンジ情報を特定する。具体的には、物理ブロック番号取得部１１３は、処理対象のディレクトリファイルのdinodeを参照し、対応するハッシュ値レンジ表を取得する。そして、物理ブロック番号取得部１１３は、取得したハッシュ値レンジ表に登録されているハッシュ値レンジ情報の中から、ステップＳ３１で得られたハッシュ値をハッシュ値レンジに含むものを特定する。さらに、物理ブロック番号取得部１１３は、特定したハッシュ値レンジ情報で示される物理ブロック番号をディレクトリ処理部１１４に渡す。
［ステップＳ３３］ディレクトリ処理部１１４は、名前検索を行う物理ブロックのデータを読み出す。具体的には、ディレクトリ処理部１１４は、物理ブロック番号取得部１１３から受け取った物理ブロック番号に対応する物理ブロックから、格納されているデータを全て読み出す。
［ステップＳ３４］ディレクトリ処理部１１４は、読み出した物理ブロック内のデータから、削除対象の名前情報を線形検索する。検索結果は、結果通知部１１５を介して、アクセス管理部２１２に通知される。
このようにして、名前検索が行われる。
次に、名前列挙処理について説明する。なお、名前列挙処理では、クッキー値を使用して名前列挙開始位置を管理する。
クッキー値は、列挙開始対象のレコードを指し示す情報である。例えば、１回の名前列挙処理で列挙可能な名前情報の数に制限がある場合、名前列挙処理の終了時に、列挙開始対象のレコードの位置がクッキー値に保存される。すると、次回の名前列挙処理で前回保存したクッキー値を指定すれば、前回列挙された名前情報の後続の名前情報を列挙することができる。すなわち、保存されたクッキー値で示されるレコードが、次回の名前列挙処理において名前列挙の開始位置となる。
クッキー値は、例えば、名前のハッシュ値と、物理ブロック内相対オフセットとで表現される。この場合、ハッシュ値によって、ハッシュ値レンジ情報が特定される。ハッシュ値レンジ情報が特定されれば、列挙開始対象のレコードが格納された物理ブロックが一意に決定する。また、物理ブロック内相対オフセットによって、物理ブロック内での列挙開始対象のレコードの位置が特定される。
クッキー値のフォーマットは、ハッシュ値と物理ブロック内相対オフセットとを表現できればよい。例えば、上３２ビットを名前のハッシュ値、下３２ビットを物理ブロック内相対オフセットとする、合計６４ビットの整数値を、クッキー値とすることができる。
なお、クッキー値内のハッシュ値は、前回の名前列挙処理において、同一物理ブロック内の全名前情報の列挙が済んでいない場合（システム制限で停止）、同じ値が維持される。その場合でも、クッキー値内の物理ブロック内相対オフセットは更新される。これにより、同一名前情報の重複した列挙が防止される。
図１６は、名前列挙処理の手順を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。なお、この処理は、アクセス管理部２１２からメタデータ管理部１１０に対して、名前列挙を指示する処理要求が出されたときに実行される。
［ステップＳ４１］物理ブロック番号取得部１１３は、処理要求においてクッキー値の指定があるか否かを判断する。クッキー値がある場合、処理がステップＳ４３に進められる。クッキー値が無い場合、処理がステップＳ４２に進められる。
［ステップＳ４２］物理ブロック番号取得部１１３は、クッキー値を初期化する。具体的には、ディレクトリ処理部１１４は、列挙開始対象のハッシュ値を０とし、列挙開始対象レコードの物理ブロック内相対オフセットを０とする。
［ステップＳ４３］物理ブロック番号取得部１１３は、クッキー値からハッシュ値と物理ブロック相対オフセットとを抽出する。
［ステップＳ４４］物理ブロック番号取得部１１３は、列挙開始対象のハッシュ値レンジ情報を特定する。具体的には、物理ブロック番号取得部１１３は、ハッシュ値レンジ表から、ステップＳ４３で抽出したハッシュ値を包含するハッシュ値レンジが設定されたハッシュ値レンジ情報を割り出す。さらに、物理ブロック番号取得部１１３は、特定したハッシュ値レンジ情報で示される物理ブロック番号をディレクトリ処理部１１４に渡す。
［ステップＳ４５］ディレクトリ処理部１１４は、列挙開始対象のレコードが格納された物理ブロックのデータを読み出す。具体的には、ディレクトリ処理部１１４は、物理ブロック番号取得部１１３から受け取った物理ブロック番号に対応する物理ブロックから、格納されているデータを全て読み出す。
［ステップＳ４６］ディレクトリ処理部１１４は、物理ブロックのデータから名前情報を抽出する。具体的には、ディレクトリ処理部１１４は、ステップＳ４５で読み出した物理ブロックのデータから、物理ブロック内相対オフセットで示される位置のレコードを列挙開始対象レコードとする。そして、ディレクトリ処理部１１４は、列挙開始対象レコードから順番に（物理ブロックのデータ配列の後方に向かい）、順次レコードを抽出する。ディレクトリ処理部１１４は、抽出したレコードから名前情報を抽出し、列挙する。
ここで、システムで指定された名前列挙数の上限に到達した場合、名前列挙処理を停止する。また、ステップＳ４５で読み出した物理ブロックに格納されていた全てのレコードから名前情報を抽出した場合にも、名前列挙処理を停止する。
［ステップＳ４７］ディレクトリ処理部１１４は、処理対象のディレクトリ配下の全てのファイルの名前列挙が完了したかを判断する。具体的には、ステップＳ４４で特定されたハッシュ値レンジ情報がハッシュ値レンジ表内の最後尾（ハッシュ値レンジの範囲が最も高い）の情報であり、対応する物理ブロック内の全てのレコードから名前情報を抽出した場合、名前列挙が完了したものと判断できる。
名前列挙が完了した場合、処理が終了する。名前列挙処理が完了していない場合、処理がステップＳ４８に進められる。
［ステップＳ４８］ディレクトリ処理部１１４は、ステップＳ４６の処理がシステム制限（名前列挙数の上限に達したこと）で停止したか否かを判断する。システム制限で停止した場合、処理がステップＳ４９に進められる。システム制限以外で停止した場合、処理がステップＳ５０に進められる。
［ステップＳ４９］システム制限で停止した場合、ディレクトリ処理部１１４は、クッキー値の物理ブロック内相対オフセットを更新する。具体的には、ディレクトリ処理部１１４は、クッキー値の物理ブロック内相対オフセットを、ステップＳ４６で最後に抽出したレコードの次のレコードを指し示す値に更新する。その後、処理が終了する。
［ステップＳ５０］システム制限以外で停止した場合、ディレクトリ処理部１１４は、クッキー値のハッシュ値を更新する。具体的には、ディレクトリ処理部１１４は、ハッシュ値レンジ表において、ステップＳ４４で特定したハッシュ値レンジ情報の次のハッシュ値レンジ情報に設定されたハッシュ値レンジ開始値を、クッキー値のハッシュ値とする。その後、処理がステップＳ４４に進められる。
以上のようにして、extentベースファイルシステムにおいて、ディレクトリファイルに限りextetn表をハッシュ値レンジ表に置き換える簡単な修正を加えるだけで、ディレクトリ検索処理の劇的な性能向上を達成することができる。すなわち、近年主流になってきているextentファイルシステムには、論理ブロックレンジと物理ブロックレンジとの対応表（extent表）が必ず存在する。このextent表を、ディレクトリファイルに限り、名前のハッシュ値レンジと物理ブロックレンジとの対応表（ハッシュ値レンジ表）として用いる。従って、既存のextentベースファイルシステムに対して大幅な改良を加えることなく、ディレクトリファイルに対するアクセスの効率化を図ることができる。
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、ファイル管理装置、メタデータサーバ１００、及びアクセスクライアントホスト２１０，２２０，２３０が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。
プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
（付記１） ストレージデバイス内のファイルを管理するために、コンピュータに対してファイル管理処理を行わせるファイル管理プログラムにおいて、
前記コンピュータを、
処理対象ファイルの名前情報を含む処理要求を受け取ると、前記名前情報に所定のハッシュ関数を適用し、前記処理対象ファイルのハッシュ値を生成するハッシュ値生成手段、
ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記処理対象ファイルのハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得する物理ブロック番号取得手段、
前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行うディレクトリ処理手段、
として機能させることを特徴とするファイル管理プログラム。
（付記２） 前記ディレクトリ処理手段は、前記処理要求において前記名前情報の挿入が指示されている場合、前記物理ブロックから取得したデータに前記名前情報を含むレコードを挿入し、前記データを元の前記物理ブロックに書き戻すことを特徴とする付記１記載のファイル管理プログラム。
（付記３） 前記ディレクトリ処理手段は、挿入前に、前記データに前記レコードを挿入可能か否かを判断し、挿入可能な場合、前記データに前記レコードを挿入し、挿入不可能な場合、前記物理ブロック番号取得手段で抽出された前記ハッシュ値レンジ情報の前記ハッシュ値レンジを複数のハッシュ値レンジに分割し、分割後の前記ハッシュ値レンジそれぞれに応じた複数のハッシュ値レンジ情報を前記ハッシュ値レンジ表に登録し、更新後の前記ハッシュ値レンジ表を参照し、前記レコードの挿入処理を行うことを特徴とする付記２記載のファイル管理プログラム。
（付記４） 前記ディレクトリ処理手段は、前記レコードを挿入することで前記物理ブロックのデータ量が所定の上限値を超える場合、前記レコードを挿入不可能と判断することを特徴とする付記３記載のファイル管理プログラム。
（付記５） 前記ディレクトリ処理手段は、前記処理要求において前記名前情報の削除が指示されている場合、前記物理ブロックから取得したデータから前記名前情報を含むレコードを削除し、前記データを元の前記物理ブロックに書き戻すことを特徴とする付記１記載のファイル管理プログラム。
（付記６） 前記ディレクトリ処理手段は、前記物理ブロックから取得したデータから前記レコードを削除後、前記ハッシュ値レンジ情報の統合の要否を判断し、統合が必要と判断された場合、前記処理対象ファイルのハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を、他の前記ハッシュ値レンジ情報と統合することを特徴とする付記５記載のファイル管理プログラム。
（付記７） 前記ディレクトリ処理手段は、前記レコードの削除が行われた前記物理ブロックの内の残りのデータ量が所定の下限値以下になった場合に、前記ハッシュ値レンジ情報の統合が必要と判断することを特徴とする付記６記載のファイル管理プログラム。
（付記８） 前記ディレクトリ処理手段は、前記ハッシュ値レンジ情報の統合を行う場合、前記処理対象ファイルのハッシュ値を包含する前記ハッシュ値レンジに対して隣接するハッシュ値レンジが設定された他の前記ハッシュ値レンジ情報のうち、対応する前記物理ブロックのデータ量が少ない方の前記ハッシュ値レンジ情報を統合相手とすることを特徴とする付記６記載のファイル管理システム。
（付記９） 前記ディレクトリ処理手段は、前記処理要求において前記名前情報の列挙が指示されている場合、前記物理ブロックから前記名前情報を抽出し、列挙することを特徴とする付記１記載のファイル管理プログラム。
（付記１０） コンピュータにより、ストレージデバイス内のファイルを管理するためのファイル管理方法において、
前記コンピュータが、
ハッシュ値生成手段が、処理対象ファイルの名前情報を含む処理要求を受け取ると、前記名前情報に所定のハッシュ関数を適用し、前記処理対象ファイルのハッシュ値を生成し、
物理ブロック番号取得手段が、ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記処理対象ファイルのハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得し、
ディレクトリ処理手段が、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行う、
ことを特徴とするファイル管理方法。
（付記１１） ストレージデバイス内のファイルを管理するためのファイル管理装置において、
処理対象ファイルの名前情報を含む処理要求を受け取ると、前記名前情報に所定のハッシュ関数を適用し、前記処理対象ファイルのハッシュ値を生成するハッシュ値生成手段と、
ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記処理対象ファイルのハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得する物理ブロック番号取得手段と、
前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行うディレクトリ処理手段と、
を有することを特徴とするファイル管理装置。
（付記１２） ストレージデバイス内のファイルを管理するために、コンピュータに対してファイル管理処理を行わせるファイル管理プログラムを記録したコンピュータ読み取り可能な記録媒体において、
前記コンピュータを、
処理対象ファイルの名前情報を含む処理要求を受け取ると、前記名前情報に所定のハッシュ関数を適用し、前記処理対象ファイルのハッシュ値を生成するハッシュ値生成手段、
ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記処理対象ファイルのハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得する物理ブロック番号取得手段、
前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行うディレクトリ処理手段、
として機能させることを特徴とするファイル管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
実施の形態に適用される発明の概念図である。 本実施の形態のシステム構成を示す図である。 本実施の形態に用いるメタデータサーバのハードウェア構成例を示す図である。 ファイルアクセスの流れを示す概念図である。 メタデータ管理部の機能を示すブロック図である。 ボリューム内のデータ構造例を示す図である。 extent表のデータ構造例を示す図である。 非ディレクトリファイルへのアクセス状況を示す図である。 ハッシュ値レンジ表のデータ構造例を示す図である。 ディレクトリファイルへのアクセス状況を示す図である。 名前挿入処理のフローチャートを示す図である。 ハッシュ値レンジが分割される様子を示す図である。 名前削除処理の手順を示すフローチャートである。 ハッシュ値レンジ情報統合状況を示す図である。 名前検索処理の手順を示すフローチャートである。 名前列挙処理の手順を示すフローチャートである。
符号の説明
１ ストレージデバイス
１ａ ハッシュ値レンジ表
１ｃ 物理ブロック
１ｄ レコード
２ ハッシュ値生成手段
３ 物理ブロック番号取得手段
４ ディレクトリ処理手段
５ 処理要求
５ａ 名前情報
６ ハッシュ値
７ 物理ブロック番号

Claims (8)

  1. ストレージデバイス内のファイルを管理するために、コンピュータに対してファイル管理処理を行わせるファイル管理プログラムにおいて、
    前記コンピュータを、
    処理要求を受け取ると、処理対象がディレクトリファイルか非ディレクトリファイルかを判断する要求受付手段、
    前記処理要求の処理対象がディレクトリファイルの場合、前記処理要求に含まれる名前情報に所定のハッシュ関数を適用し、前記名前情報のハッシュ値を生成するハッシュ値生成手段、
    前記処理要求の処理対象が非ディレクトリファイルの場合、dinodeを参照してアクセス対象データの論理ブロック番号を取得し、さらに論理ブロック番号と物理ブロック番号との対応関係を示すextent表を参照して、前記アクセス対象データの物理ブロック番号を取得し、前記処理要求の処理対象がディレクトリファイルの場合、前記extent表に代えて、ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記名前情報のハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得する物理ブロック番号取得手段、
    前記処理要求の処理対象がディレクトリファイルの場合、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行うディレクトリ処理手段、
    として機能させ、
    前記ディレクトリ処理手段は、
    前記処理要求において前記名前情報の挿入が指示されている場合、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記物理ブロック内のデータに前記レコードを挿入可能か否かを、挿入前に判断し、
    挿入可能な場合、前記物理ブロック内の前記データに前記名前情報を含む前記レコードを挿入し、
    挿入不可能な場合、前記物理ブロック番号取得手段で抽出された前記ハッシュ値レンジ情報のハッシュ値レンジを複数のハッシュ値レンジに分割し、分割後の前記ハッシュ値レンジそれぞれに応じた複数のハッシュ値レンジ情報を前記ハッシュ値レンジ表に登録し、分割後の前記ハッシュ値レンジのうち前記名前情報のハッシュ値を包含する前記ハッシュ値レンジの前記ハッシュ値レンジ情報で示される物理ブロック番号に該当する物理ブロック内のデータに、前記名前情報を含む前記レコードを挿入する、
    ことを特徴とするファイル管理プログラム。
  2. 前記ディレクトリ処理手段は、前記レコードを挿入することで前記物理ブロックのデータ量が所定の上限値を超える場合、前記レコードを挿入不可能と判断することを特徴とする請求項１記載のファイル管理プログラム。
  3. ストレージデバイス内のファイルを管理するために、コンピュータに対してファイル管理処理を行わせるファイル管理プログラムにおいて、
    前記コンピュータを、
    処理要求を受け取ると、処理対象がディレクトリファイルか非ディレクトリファイルかを判断する要求受付手段、
    前記処理要求の処理対象がディレクトリファイルの場合、前記処理要求に含まれる名前情報に所定のハッシュ関数を適用し、前記名前情報のハッシュ値を生成するハッシュ値生成手段、
    前記処理要求の処理対象が非ディレクトリファイルの場合、dinodeを参照してアクセス対象データの論理ブロック番号を取得し、さらに論理ブロック番号と物理ブロック番号との対応関係を示すextent表を参照して、前記アクセス対象データの物理ブロック番号を取得し、前記処理要求の処理対象がディレクトリファイルの場合、前記extent表に代えて、ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記名前情報のハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得する物理ブロック番号取得手段、
    前記処理要求の処理対象がディレクトリファイルの場合、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行うディレクトリ処理手段、
    として機能させ、
    前記ディレクトリ処理手段は、
    前記処理要求において前記名前情報の削除が指示されている場合、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記物理ブロック内のデータから前記名前情報を含む前記レコードを削除し、
    前記物理ブロック内の前記データから前記レコードを削除後、前記レコードの削除が行われた前記物理ブロック内の残りのデータ量が所定の下限値以下になったか否かにより、前記ハッシュ値レンジ情報の統合の要否を判断し、
    統合が必要と判断された場合、前記名前情報のハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を、他のハッシュ値レンジ情報と統合して前記ハッシュ値レンジ表に登録する、
    ことを特徴とするファイル管理プログラム。
  4. 前記ディレクトリ処理手段は、前記ハッシュ値レンジ情報の統合を行う場合、前記処理対象ファイルのハッシュ値を包含する前記ハッシュ値レンジに対して隣接するハッシュ値レンジが設定された他のハッシュ値レンジ情報のうち、対応する前記物理ブロックのデータ量が少ない方の前記ハッシュ値レンジ情報を統合相手とすることを特徴とする請求項３記載のファイル管理プログラム。
  5. コンピュータにより、ストレージデバイス内のファイルを管理するためのファイル管理方法において、
    前記コンピュータが、
    処理要求を受け取ると、処理対象がディレクトリファイルか非ディレクトリファイルかを判断し、
    前記処理要求の処理対象がディレクトリファイルの場合、前記処理要求に含まれる名前情報に所定のハッシュ関数を適用し、前記名前情報のハッシュ値を生成し、
    前記処理要求の処理対象が非ディレクトリファイルの場合、dinodeを参照してアクセス対象データの論理ブロック番号を取得し、さらに論理ブロック番号と物理ブロック番号との対応関係を示すextent表を参照して、前記アクセス対象データの物理ブロック番号を取得し、前記処理要求の処理対象がディレクトリファイルの場合、前記extent表に代えて、ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記名前情報のハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得し、
    前記処理要求の処理対象がディレクトリファイルの場合、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行い、
    ディレクトリファイルを処理対象とする前記処理要求において前記名前情報の挿入が指示されている場合、取得された前記物理ブロック番号に該当する前記物理ブロック内のデータに前記レコードを挿入可能か否かを、挿入前に判断し、
    挿入可能な場合、前記物理ブロック内の前記データに前記名前情報を含む前記レコードを挿入し、
    挿入不可能な場合、抽出された前記ハッシュ値レンジ情報のハッシュ値レンジを複数のハッシュ値レンジに分割し、分割後の前記ハッシュ値レンジそれぞれに応じた複数のハッシュ値レンジ情報を前記ハッシュ値レンジ表に登録し、分割後の前記ハッシュ値レンジのうち前記名前情報のハッシュ値を包含する前記ハッシュ値レンジの前記ハッシュ値レンジ情報で示される物理ブロック番号に該当する物理ブロック内のデータに、前記名前情報を含む前記レコードを挿入する、
    ことを特徴とするファイル管理方法。
  6. コンピュータにより、ストレージデバイス内のファイルを管理するためのファイル管理方法において、
    前記コンピュータが、
    処理要求を受け取ると、処理対象がディレクトリファイルか非ディレクトリファイルかを判断し、
    前記処理要求の処理対象がディレクトリファイルの場合、前記処理要求に含まれる名前情報に所定のハッシュ関数を適用し、前記名前情報のハッシュ値を生成し、
    前記処理要求の処理対象が非ディレクトリファイルの場合、dinodeを参照してアクセス対象データの論理ブロック番号を取得し、さらに論理ブロック番号と物理ブロック番号との対応関係を示すextent表を参照して、前記アクセス対象データの物理ブロック番号を取得し、前記処理要求の処理対象がディレクトリファイルの場合、前記extent表に代えて、ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記名前情報のハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得し、
    前記処理要求の処理対象がディレクトリファイルの場合、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行い、
    ディレクトリファイルを処理対象とする前記処理要求において前記名前情報の削除が指示されている場合、取得された前記物理ブロック番号に該当する前記物理ブロック内のデータから前記名前情報を含む前記レコードを削除し、
    前記物理ブロック内の前記データから前記レコードを削除後、前記レコードの削除が行われた前記物理ブロック内の残りのデータ量が所定の下限値以下になったか否かにより、前記ハッシュ値レンジ情報の統合の要否を判断し、
    統合が必要と判断された場合、前記名前情報のハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を、他のハッシュ値レンジ情報と統合して前記ハッシュ値レンジ表に登録する、
    ことを特徴とするファイル管理方法。
  7. ストレージデバイス内のファイルを管理するためのファイル管理装置において、
    処理要求を受け取ると、処理対象がディレクトリファイルか非ディレクトリファイルかを判断する要求受付手段と、
    前記処理要求の処理対象がディレクトリファイルの場合、前記処理要求に含まれる名前情報に所定のハッシュ関数を適用し、前記名前情報のハッシュ値を生成するハッシュ値生成手段と、
    前記処理要求の処理対象が非ディレクトリファイルの場合、dinodeを参照してアクセス対象データの論理ブロック番号を取得し、さらに論理ブロック番号と物理ブロック番号との対応関係を示すextent表を参照して、前記アクセス対象データの物理ブロック番号を取得し、前記処理要求の処理対象がディレクトリファイルの場合、前記extent表に代えて、ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記名前情報のハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得する物理ブロック番号取得手段と、
    前記処理要求の処理対象がディレクトリファイルの場合、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行うディレクトリ処理手段と、
    を有し、
    前記ディレクトリ処理手段は、
    前記処理要求において前記名前情報の挿入が指示されている場合、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記物理ブロック内のデータに前記レコードを挿入可能か否かを、挿入前に判断し、
    挿入可能な場合、前記物理ブロック内の前記データに前記名前情報を含む前記レコードを挿入し、
    挿入不可能な場合、前記物理ブロック番号取得手段で抽出された前記ハッシュ値レンジ情報のハッシュ値レンジを複数のハッシュ値レンジに分割し、分割後の前記ハッシュ値レンジそれぞれに応じた複数のハッシュ値レンジ情報を前記ハッシュ値レンジ表に登録し、分割後の前記ハッシュ値レンジのうち前記名前情報のハッシュ値を包含する前記ハッシュ値レンジの前記ハッシュ値レンジ情報で示される物理ブロック番号に該当する物理ブロック内のデータに、前記名前情報を含む前記レコードを挿入する、
    ことを特徴とするファイル管理装置。
  8. ストレージデバイス内のファイルを管理するためのファイル管理装置において、
    処理要求を受け取ると、処理対象がディレクトリファイルか非ディレクトリファイルかを判断する要求受付手段と、
    前記処理要求の処理対象がディレクトリファイルの場合、前記処理要求に含まれる名前情報に所定のハッシュ関数を適用し、前記名前情報のハッシュ値を生成するハッシュ値生成手段と、
    前記処理要求の処理対象が非ディレクトリファイルの場合、dinodeを参照してアクセス対象データの論理ブロック番号を取得し、さらに論理ブロック番号と物理ブロック番号との対応関係を示すextent表を参照して、前記アクセス対象データの物理ブロック番号を取得し、前記処理要求の処理対象がディレクトリファイルの場合、前記extent表に代えて、ハッシュ値の包含範囲を定義したハッシュ値レンジと、前記ストレージデバイス内のデータ格納領域を一意に示す物理ブロック番号との組からなる１以上のハッシュ値レンジ情報が格納されているハッシュ値レンジ表を参照し、前記名前情報のハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を抽出し、抽出した前記ハッシュ値レンジ情報から前記物理ブロック番号を取得する物理ブロック番号取得手段と、
    前記処理要求の処理対象がディレクトリファイルの場合、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記ストレージデバイス内の物理ブロックに対して、前記名前情報を含むレコードに関する前記処理要求に従った処理を行うディレクトリ処理手段と、
    を有し、
    前記ディレクトリ処理手段は、
    前記処理要求において前記名前情報の削除が指示されている場合、前記物理ブロック番号取得手段で取得された前記物理ブロック番号に該当する前記物理ブロック内のデータから前記名前情報を含む前記レコードを削除し、
    前記物理ブロック内の前記データから前記レコードを削除後、前記レコードの削除が行われた前記物理ブロック内の残りのデータ量が所定の下限値以下になったか否かにより、前記ハッシュ値レンジ情報の統合の要否を判断し、
    統合が必要と判断された場合、前記名前情報のハッシュ値を包含する前記ハッシュ値レンジが設定された前記ハッシュ値レンジ情報を、他のハッシュ値レンジ情報と統合して前記ハッシュ値レンジ表に登録する、
    ことを特徴とするファイル管理装置。
JP2004237550A 2004-08-17 2004-08-17 ファイル管理プログラム、ファイル管理方法、及びファイル管理装置 Expired - Fee Related JP4315876B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2004237550A JP4315876B2 (ja) 2004-08-17 2004-08-17 ファイル管理プログラム、ファイル管理方法、及びファイル管理装置
US11/036,678 US7454405B2 (en) 2004-08-17 2005-01-14 File management program, file management process, and file management apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004237550A JP4315876B2 (ja) 2004-08-17 2004-08-17 ファイル管理プログラム、ファイル管理方法、及びファイル管理装置

Publications (2)

Publication Number Publication Date
JP2006058965A JP2006058965A (ja) 2006-03-02
JP4315876B2 true JP4315876B2 (ja) 2009-08-19

Family

ID=35481840

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004237550A Expired - Fee Related JP4315876B2 (ja) 2004-08-17 2004-08-17 ファイル管理プログラム、ファイル管理方法、及びファイル管理装置

Country Status (2)

Country Link
US (1) US7454405B2 (ja)
JP (1) JP4315876B2 (ja)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8560503B1 (en) * 2006-01-26 2013-10-15 Netapp, Inc. Content addressable storage system
US7734603B1 (en) * 2006-01-26 2010-06-08 Netapp, Inc. Content addressable storage array element
US7707136B2 (en) * 2006-03-31 2010-04-27 Amazon Technologies, Inc. System and method for providing high availability data
KR100809318B1 (ko) * 2006-04-04 2008-03-05 삼성전자주식회사 파일 관리 장치 및 방법
JP4578454B2 (ja) * 2006-09-21 2010-11-10 株式会社ソニー・コンピュータエンタテインメント データベース生成方法および情報処理装置
US8161353B2 (en) * 2007-12-06 2012-04-17 Fusion-Io, Inc. Apparatus, system, and method for validating that a correct data segment is read from a data storage device
US8296337B2 (en) 2006-12-06 2012-10-23 Fusion-Io, Inc. Apparatus, system, and method for managing data from a requesting device with an empty data token directive
US8151082B2 (en) * 2007-12-06 2012-04-03 Fusion-Io, Inc. Apparatus, system, and method for converting a storage request into an append data storage command
US7827201B1 (en) * 2007-04-27 2010-11-02 Network Appliance, Inc. Merging containers in a multi-container system
US7836226B2 (en) 2007-12-06 2010-11-16 Fusion-Io, Inc. Apparatus, system, and method for coordinating storage requests in a multi-processor/multi-thread environment
US9519540B2 (en) 2007-12-06 2016-12-13 Sandisk Technologies Llc Apparatus, system, and method for destaging cached data
US20090204967A1 (en) * 2008-02-08 2009-08-13 Unisys Corporation Reporting of information pertaining to queuing of requests
WO2011111837A1 (ja) * 2010-03-11 2011-09-15 楽天株式会社 情報処理方法、情報処理装置、プログラム及び記録媒体
US8660996B2 (en) * 2010-09-29 2014-02-25 Red Hat, Inc. Monitoring files in cloud-based networks
JP2012137850A (ja) * 2010-12-24 2012-07-19 Fujitsu Ltd 分散ファイル操作プログラム、分散ファイル操作装置、及び分散ファイル操作方法
US9141527B2 (en) 2011-02-25 2015-09-22 Intelligent Intellectual Property Holdings 2 Llc Managing cache pools
JP5733124B2 (ja) * 2011-09-12 2015-06-10 富士通株式会社 データ管理装置、データ管理システム、データ管理方法、及びプログラム
US9251086B2 (en) 2012-01-24 2016-02-02 SanDisk Technologies, Inc. Apparatus, system, and method for managing a cache
US20130218934A1 (en) * 2012-02-17 2013-08-22 Hitachi, Ltd. Method for directory entries split and merge in distributed file system
US20130226888A1 (en) * 2012-02-28 2013-08-29 Netapp, Inc. Systems and methods for caching data files
US9208082B1 (en) * 2012-03-23 2015-12-08 David R. Cheriton Hardware-supported per-process metadata tags
US9438447B2 (en) 2012-12-18 2016-09-06 International Business Machines Corporation Flow distribution algorithm for aggregated links in an ethernet switch
FR3001313B1 (fr) * 2013-01-22 2016-02-12 Univ Aix Marseille Procede de verification d'au moins une metadonnee d'un bloc de donnees numeriques
JP6521978B2 (ja) 2013-09-09 2019-05-29 ユナイテッドレックス コーポレーションＵｎｉｔｅｄｌｅｘ Ｃｏｒｐ． 対話型事案管理システム
JP6515635B2 (ja) * 2015-03-30 2019-05-22 日本電気株式会社 情報処理装置、情報処理システム、情報処理方法、及び、プログラム
US11232079B2 (en) * 2015-07-16 2022-01-25 Pure Storage, Inc. Efficient distribution of large directories
US10698829B2 (en) * 2015-07-27 2020-06-30 Datrium, Inc. Direct host-to-host transfer for local cache in virtualized systems wherein hosting history stores previous hosts that serve as currently-designated host for said data object prior to migration of said data object, and said hosting history is checked during said migration
CN108241710A (zh) * 2016-12-27 2018-07-03 中移(苏州)软件技术有限公司 一种文件创建方法、装置以及文件查询方法、装置
CN109446160A (zh) * 2018-11-06 2019-03-08 郑州云海信息技术有限公司 一种文件读取方法、系统、装置及计算机可读存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5995648A (ja) 1982-11-25 1984-06-01 Mitsubishi Electric Corp フアイル探索方式
US5202982A (en) * 1990-03-27 1993-04-13 Sun Microsystems, Inc. Method and apparatus for the naming of database component files to avoid duplication of files
JPH0540680A (ja) 1991-08-05 1993-02-19 Hitachi Software Eng Co Ltd フアイル階層管理システム
US6308320B1 (en) * 1999-01-15 2001-10-23 Hewlett-Packard Company Method and apparatus for incremental selective compilation of intermediate code files during computer system compilation and linking
JP2000357115A (ja) * 1999-06-15 2000-12-26 Nec Corp ファイル検索装置及びファイル検索方法
US6643654B1 (en) * 2001-06-25 2003-11-04 Network Appliance, Inc. System and method for representing named data streams within an on-disk structure of a file system
US7240211B2 (en) * 2001-10-09 2007-07-03 Activcard Ireland Limited Method of providing an access request to a same server based on a unique identifier
JP4162184B2 (ja) * 2001-11-14 2008-10-08 株式会社日立製作所 データベース管理システムの実行情報を取得する手段を有する記憶装置
EP1471429A4 (en) * 2002-01-31 2007-09-12 Matsushita Electric Ind Co Ltd STORAGE UNIT, END DEVICE AND DATA REPAIR SYSTEM

Also Published As

Publication number Publication date
JP2006058965A (ja) 2006-03-02
US20050283489A1 (en) 2005-12-22
US7454405B2 (en) 2008-11-18

Similar Documents

Publication Publication Date Title
JP4315876B2 (ja) ファイル管理プログラム、ファイル管理方法、及びファイル管理装置
US7860907B2 (en) Data processing
US9208031B2 (en) Log structured content addressable deduplicating storage
US8484172B2 (en) Efficient search for migration and purge candidates
US8219562B1 (en) Efficient storage and retrieval for large number of data objects
US20130297658A1 (en) Method and system for synchronizing a virtual file system at a computing device with a storage device
US8095678B2 (en) Data processing
US9449007B1 (en) Controlling access to XAM metadata
KR100790991B1 (ko) 데이터베이스 관리 시스템을 이용하여 파일시스템의메타데이터를 관리하는 방법
US8938425B1 (en) Managing logical views of storage
US8090925B2 (en) Storing data streams in memory based on upper and lower stream size thresholds
JP5241298B2 (ja) 履歴上のファイル名およびロケーションをインデックス付きにすることによりファイル・サーチおよびファイル操作を支援するためのシステムおよび方法
US8640136B2 (en) Sharing objects between computer systems
KR20090063733A (ko) 다중 복제를 지원하는 분산 파일 시스템에서 데이터 서버의복구 방법 및 그에 적당한 메타데이터 스토리지 및 저장방법
US9178931B2 (en) Method and system for accessing data by a client from a server
US20030221076A1 (en) Apparatus and method for implementing dynamic structure level pointers
US9727588B1 (en) Applying XAM processes
JP2010225024A (ja) ストレージ装置とそのファイル制御方法およびストレージシステム
US8176087B2 (en) Data processing
US8886656B2 (en) Data processing
Tchaye-Kondi et al. Hadoop perfect file: a fast access container for small files with direct in disc metadata access
JP4343669B2 (ja) ファイル管理装置，動的名前空間生成方法および動的名前空間生成プログラム
US8290993B2 (en) Data processing
Du Intelligent storage for information retrieval
WO2024022330A1 (zh) 一种基于文件系统的元数据管理方法及其相关设备

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20051222

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090128

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090203

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090406

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090519

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090519

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120529

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120529

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130529

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130529

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees