(57)【要約】【課題】ファイルシステム上に多数のファイルが存在するという状況が発生しても、より短い時間でファイル削除処理を実行できるファイル管理システムを提供すること。【解決手段】本発明では、開始決定処理部３１は、ファイルシステム上のファイルのデータ総量と総数のいずれかが閾値を越えているかいずれも越えていないか調べ、閾値時刻決定処理部３２は、前者の場合に、ファイルシステム上のファイルのうち、最終使用時刻が或る時刻以前であるファイルを全て削除したとすると、ファイルのデータ総量と総数がいずれも閾値以下になるような該或る時刻を求め、ファイル削除処理部３３は、最終使用時刻が該或る時刻以前であるファイルを全て削除する。削除可否の基準に、データ総量とファイル総数を併用することで、より迅速なファイル削除処理が可能になる。【選択図】      図１
2006139588.tif 000002
【特許請求の範囲】
【請求項１】
複数のファイルを記憶するファイル記憶手段を管理対象とするファイル管理システムであって、
前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第1の閾値を超えている第1の条件又は前記ファイル記憶手段に保持されているファイルの総数が第２の閾値を超えている第2の条件の少なくとも一方が成立しているか否かを判断する第１の処理手段と、
前記第1の条件又は前記第２の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、そのファイルが使用された最も遅い時刻を示す最終使用時刻が特定の閾値時刻以前であるファイルを全て削除したとすると、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第３の閾値以下になり且つ前記ファイル記憶手段に記憶されているファイルの総数が第４の閾値以下になるような、特定の閾値時刻を求める第２の処理手段と、
前記第1の条件又は前記第２の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、前記最終使用時刻が前記特定の時刻以前であるファイルを全て削除する第３の処理手段とを備えたことを特徴とするファイル管理システム。
【請求項２】
少なくとも前記ファイル記憶手段に記憶されている個々のファイルのデータ量及び最終使用時刻を示す情報を記憶する手段を更に備えたことを特徴とする請求項１に記載のファイル管理システム。
【請求項３】
少なくとも前記ファイル記憶手段に記憶されている個々のファイルのデータ量及び最終使用時刻を示す情報を前記ファイル記憶手段から取得する手段を更に備えたことを特徴とする請求項１に記載のファイル管理システム。
【請求項４】
前記第３の閾値は前記第１の閾値より小さい値であり、前記第４の閾値は前記第２の閾値より小さい値であることを特徴とする請求項１に記載のファイル管理システム。
【請求項５】
前記ファイル記憶手段は、特定のオペレーティングシステム上のファイルシステムであることを特徴とする請求項１に記載のファイル管理システム。
【請求項６】
前記第１乃至第３の処理手段は、前記特定のオペレーティングシステムが動作する計算機と同一の計算機上に設けられるものであることを特徴とする請求項５に記載のファイル管理システム。
【請求項７】
前記計算機は、データを要求するブラウザの動作するクライアント装置又はデータを転送するプロキシサーバ装置を構成する計算機であり、
前記ファイル記憶手段は、前記クライアント装置又は前記プロキシサーバ装置が使用するキャッシュにより、キャッシュすべきデータをファイルとして保存するために使用されるものであることを特徴とする請求項６に記載のファイル管理システム。
【請求項８】
第１乃至第３の処理手段を備え、複数のファイルを記憶するファイル記憶手段を管理対象とする、ファイル管理システムにおけるファイル削除方法において、
前記第１の処理手段により、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第1の閾値を超えている第1の条件又は前記ファイル記憶手段に保持されているファイルの総数が第２の閾値を超えている第2の条件の少なくとも一方が成立しているか否かを判断するステップと、
前記第２の処理手段により、前記第1の条件又は前記第２の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、そのファイルが使用された最も遅い時刻を示す最終使用時刻が特定の閾値時刻以前であるファイルを全て削除したとすると、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第３の閾値以下になり且つ前記ファイル記憶手段に記憶されているファイルの総数が第４の閾値以下になるような、特定の閾値時刻を求めるステップと、
前記第３の処理手段により、前記第1の条件又は前記第２の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、前記最終使用時刻が前記特定の時刻以前であるファイルを全て削除するステップとを有することを特徴とするファイル削除方法。
【請求項９】
第１乃至第３の処理手段を備え、複数のファイルを記憶するファイル記憶手段を管理対象とする、ファイル管理システムとしてコンピュータを機能させるためのプログラムであって、
前記プログラムは、
前記第１の処理手段により、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第1の閾値を超えている第1の条件又は前記ファイル記憶手段に保持されているファイルの総数が第２の閾値を超えている第2の条件の少なくとも一方が成立しているか否かを判断するステップと、
前記第２の処理手段により、前記第1の条件又は前記第２の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、そのファイルが使用された最も遅い時刻を示す最終使用時刻が特定の閾値時刻以前であるファイルを全て削除したとすると、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第３の閾値以下になり且つ前記ファイル記憶手段に記憶されているファイルの総数が第４の閾値以下になるような、特定の閾値時刻を求めるステップと、
前記第３の処理手段により、前記第1の条件又は前記第２の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、前記最終使用時刻が前記特定の時刻以前であるファイルを全て削除するステップとを前記コンピュータに実行させるものであることを特徴とするプログラム。
【請求項１０】
前記ファイル管理システムは、情報記憶手段を更に備え、
前記プログラムは、前記情報記憶手段により、少なくとも前記ファイル記憶手段に記憶されている個々のファイルのデータ量及び最終使用時刻を示す情報を記憶するステップを更に前記コンピュータに実行させるものであることを特徴とする請求項９に記載のプログラム。
【請求項１１】
前記ファイル管理システムは、情報取得手段を更に備え、
前記プログラムは、前記情報取得手段により、少なくとも前記ファイル記憶手段に記憶されている個々のファイルのデータ量及び最終使用時刻を示す情報を前記ファイル記憶手段から取得するステップを更に前記コンピュータに実行させるものであることを特徴とする請求項９に記載のプログラム。
【請求項１２】
前記第３の閾値は前記第１の閾値より小さい値であり、前記第４の閾値は前記第２の閾値より小さい値であることを特徴とする請求項９に記載のプログラム。
【請求項１３】
前記ファイル記憶手段は、特定のオペレーティングシステム上のファイルシステムであることを特徴とする請求項９に記載のプログラム。
【請求項１４】
前記特定のオペレーティングシステムは、前記コンピュータと同一のコンピュータ上で動作するものであることを特徴とする請求項１３に記載のプログラム。
【請求項１５】
前記コンピュータは、データを要求するブラウザの動作するクライアント装置又はデータを転送するプロキシサーバ装置を構成するコンピュータであり、
前記ファイル記憶手段は、前記クライアント装置又は前記プロキシサーバ装置が使用するキャッシュにより、キャッシュすべきデータをファイルとして保存するために使用されるものであることを特徴とする請求項１４に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイルシステム上のファイルを必要に応じて削除するファイル管理システム、ファイル削除方法及びプログラムに関する。
【背景技術】
【０００２】
ネットワークを介して様々なサービスを提供するサーバと、所望のサービスをサーバに対して要求するクライアントとから構成される、クライアント・サーバ型の情報システムが広く利用されている。インターネット上でＨＴＴＰプロトコルを使って通信するＷｅｂサーバ装置とクライアント装置とからなるWorld Wide Webシステム（単にＷｅｂとも呼ばれる）は、近年におけるクライアント・サーバ型情報システムの代表例である。
【０００３】
Ｗｅｂのようなクライアント・サーバ型の情報システムにおいては、通常、ネットワークの負荷を軽減させるためにキャッシュ技術が用いられるが、サーバやクライアントに汎用ＯＳ（オペレーティングシステム）を用いる場合、キャッシュ機構においては、キャッシュすべきデータの保存に汎用ＯＳのファイルシステムを利用するのが一般的である。
【０００４】
ところで、ファイルシステムに保存可能なデータの総量には、ディスク装置の容量などの要因によって、ある上限が存在する。このため、キャッシュ機構の持続的な動作のためには、ファイルシステム上に存在するファイルのいくつかを削除して、データの総量をある一定値以下に削除するファイル削除処理が必要となる。
【非特許文献１】“A Survey of Web Cache Replacement Strageties”, STEFAN PODLIPNIG AND LASZLO BOESZOERMENYI, ACM Computing Surveys, Vol. 35, No.4, December 2003, pp. 374-398
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来、ファイルシステム上に多数のファイルが存在する状況においてファイル削除処理が実行される際に、実際に削除されるファイルの総量はファイル削除処理前の全ファイルのデータ総量に比べて少ない量であるにもかかわらず、処理全体に要する時間が非常に長くなるという問題点があった。
【０００６】
本発明は、上記事情を考慮してなされたもので、ファイルシステム上に多数のファイルが存在する状況が発生しても、より短い時間でファイルを削除する処理を実行することのできるファイル管理システム、ファイル削除方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、複数のファイルを記憶するファイル記憶手段を管理対象とするファイル管理システムであって、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第1の閾値を超えている第1の条件又は前記ファイル記憶手段に保持されているファイルの総数が第２の閾値を超えている第2の条件の少なくとも一方が成立しているか否かを判断する第１の処理手段と、前記第1の条件又は前記第２の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、そのファイルが使用された最も遅い時刻を示す最終使用時刻が特定の閾値時刻以前であるファイルを全て削除したとすると、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第３の閾値以下になり且つ前記ファイル記憶手段に記憶されているファイルの総数が第４の閾値以下になるような、特定の閾値時刻を求める第２の処理手段と、前記第1の条件又は前記第２の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、前記最終使用時刻が前記特定の時刻以前であるファイルを全て削除する第３の処理手段とを備えたことを特徴とする。
【０００８】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。  
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読み取り可能な記録媒体としても成立する。
【発明の効果】
【０００９】
本発明によれば、ファイルシステム上に多数のファイルが存在する状況において、より短い処理時間でファイルを削除する処理を実行することができるようになる。
【発明を実施するための最良の形態】
【００１０】
以下、図面を参照しながら本発明の実施形態について説明する。
【００１１】
本実施形態では、管理対象とするファイル格納手段として、ＯＳ（特に汎用ＯＳ）のファイルシステムを想定して説明する。また、Ｗｅｂのようなクライアント・サーバ型の情報システムで使用されるキャッシュ機構が、キャッシュすべきデータの保存に、ＯＳのファイルシステムを利用する場合を想定して説明する。
【００１２】
まず、本実施形態で想定するシステムの基本的な構成と従来システムにおける問題点について詳しく説明する。
【００１３】
Ｗｅｂのようなクライアント・サーバ型の情報システムにおいては、提供されるサービスがどのような形態のものであろうと、基本的にはクライアント・サーバ間でデータ転送が行われることによってサービスが提供される。したがって、クライアントとサーバとの間での通信に用いるネットワークの容量（バンド幅）が、システム全体のボトルネックになりやすい。そこで、前述したように、通常、ネットワークの負荷を軽減させるためにキャッシュ技術が用いられる。
【００１４】
Ｗｅｂシステムの場合、クライアント上で動作するブラウザ等は、キャッシュ機構を使用するものが多く、最近アクセスしたデータをキャッシュしている。また、企業のオフィス内のＬＡＮ、研究機関におけるＬＡＮ或いは家庭内のＬＡＮなどで複数のユーザがいる場合、ＬＡＮとインターネットとの間にプロキシサーバを置き、プロキシサーバにキャッシュ機構を設けるようにすることも多い。
【００１５】
ところで、クライアント・サーバ型の情報システムを実際に構築するにあたっては、サーバやクライアントに汎用ＯＳを搭載した計算機を用いて、必要な機能をソフトウェアプログラムとして実装する手法が広く用いられている。機能をプログラムとして実装することにより、実装自体を容易に行うことができ、また機能の修正や追加などの保守を容易に行うことができる。Ｗｅｂシステムにおいても、サーバやクライアントにおいて必要な機能を汎用ＯＳ上のプログラムとして実装した例が実際に存在し、それらが様々なＷｅｂシステムの構築において用いられている。
【００１６】
このように、Ｗｅｂシステムのサーバやクライアントに汎用ＯＳを用いる場合、前述のキャッシュ機構においては、キャッシュすべきデータの保存に汎用ＯＳのファイルシステムを利用するのが一般的である。すなわち、ブラウザやプロキシサーバは、或るＵＲＬ(Uniform Resouce Locators)へのＨＴＴＰリクエストに対するレスポンスを受信すると、それらの内容をファイルシステム上の一つのファイルに保存する。そして後で同じＵＲＬへのリクエストが発せられた際に、そのファイルから読み出したデータをＨＴＴＰレスポンスとして用いる。
【００１７】
様々なＵＲＬへのリクエストが送信され、レスポンスが保存されるにつれて、ファイルシステム上に存在するファイルの総数や、ファイルシステム上に保存されているファイルのデータ総量は増加していく。計算機に接続されているディスク装置の容量などの要因によって、ファイルシステムに保存可能なファイルのデータ総量にはある上限が存在する。そのため、キャッシュ機構の持続的な動作のためには、ファイルシステム上に存在するファイルのいくつかを削除して、データ総量をある一定値以下に削減するファイル削除処理が必要となる。この場合、削除されるファイルとしては、長い間使われていないファイルを削除するのが望ましい。従って、ファイルシステム上に存在する全てのファイルの中から、最終使用時間が古いものを削除して、データ総量を一定値以下に削減することになる。
【００１８】
ところで、Ｗｅｂシステムのデータ転送における特徴として、  
・一つのリクエストに対して送信されるレスポンスデータのサイズ（データ量）が比較的小さい、  
・クライアント側での一つの処理に対して複数のリクエスト送信＆レスポンス受信が行われる、  
といったことがあげられる。例えば、ブラウザで特定のＵＲＬにアクセスして画面が表示されるという典型的なケースを考えると、Ｗｅｂサーバからブラウザに対して数ＫＢｙｔｅ〜数十ＫＢｙｔｅのＨＴＭＬや画像データが数十個送信されるといった状況になる。従って、このようなデータをファイルシステム上のファイルとして保存していった場合、ファイルシステム上には比較的小さいサイズのファイルが非常に多数存在するという状況が発生しやすい。
【００１９】
従って、ファイル削除処理は、ファイル数が非常に多い状態で実行されるわけであるが、そのような場合には、削除対象のファイルのリストを持つような方法は計算機のリソース的に困難であることが多い。そのため、このような場合には、ファイルの最終使用時刻を一つずつ確認して削除するか否かを決める方式を取ることが多い。
【００２０】
具体的には以下のような手順となる。  
（１）「ファイルシステム上のファイルのデータ総量がある閾値を越えた状態である」という条件が成立しているか否かを調べ、成立している場合は次の処理（２）に進む。成立していない場合は処理を終了する。  
（２）「ファイルの最終使用時刻がＴ´以前であるファイルを全て削除すれば、ファイルシステム上のファイルのデータ総量がある閾値以下になる」という条件を満たす時刻Ｔ´を求め、次の処理（３）に進む。  
（３）ファイルシステム上のファイルのうち、最終使用時刻が上記時刻Ｔ´以前であるファイルをすべて削除する。
【００２１】
さて、上記手順において、処理（３）では、各ファイルの最終使用時刻と時刻Ｔ´とを比較する処理が必要になるが、この比較処理は、ファイルシステム上の全てのファイルに対して実行されるので、この比較処理に要する時間の総和はファイルシステム上のファイルの総数に依存する。従って、前述のＷｅｂのキャッシュ機能のように、ファイルシステム上に比較的小さいサイズのファイルが非常に多数存在するという状況においては、この比較処理に要する総時間が、全体の処理時間に大きく影響してくる。そのため、前述したように、実際に削除するファイルのデータ総量はファイル削除処理前の全ファイルのデータ総量に比べて少ない量であるにもかかわらず、処理全体に擁する時間が非常に長くなるという問題があった。
【００２２】
以下、本実施形態に係るシステムについて詳しく説明する。
【００２３】
図１に、本発明の一実施形態に係るファイル管理システムの構成例を示す。
【００２４】
図１に示されるように、本実施形態のファイル管理システム３は、開始決定処理部３１、閾値時刻決定処理部３２、削除処理部３３を備えている。
【００２５】
図１中、２は、本ファイル管理システム３が管理対象とする、或るＯＳ（図示せず）のファイルシステムを表している。
【００２６】
ファイル管理システム３は、ＯＳが動作する計算機と同一の計算機上で動作するプログラムとして実現してもよいし（この場合に、ファイル管理システムのプログラムは、該ＯＳ上で動作するものであってもよい）、同計算機にハードウェアとして組み込まれてもよい。また、ＯＳが動作する計算機と異なる計算機上で動作するプログラムとして実現してもよいし（この場合に、ファイル管理システムのプログラムは、該ＯＳ上で動作するものであってもよい）、同計算機にハードウェアとして組み込まれてもよい。
【００２７】
図２に、本ファイル管理システム３の管理対象とするＯＳのファイルシステム２が、ブラウザ（プロセス）又はプロキシ（プロセス）で使用されるキャッシュにより、データ保存のために使用される場合の構成例を示す。
【００２８】
図２中、２０はブラウザ（図示せず）が動作するクライアント装置（計算機）又はプロキシ（図示せず）が動作するプロキシサーバ装置（計算機）等であり、４はこれまで説明してきたようなキャッシュである。なお、図２は、ファイルシステム２とファイル管理システム３とキャッシュ４とが同一の計算機上に存在する場合を例にとっている。
【００２９】
図３に、本ファイル管理システム３の処理に必要な管理情報の一例を示す。図２に示されるように、本管理情報は、ファイルシステム２に記憶されている全ファイルについて、当該ファイルを識別可能なファイル識別情報と、当該ファイルのデータ量と、当該ファイルの最終使用時刻（当該ファイルが書き込み（新規の保存又は内容の変更）、読み出し、削除等の使用をされた最も遅い時刻）とを対応付けて保持するものである。なお、本管理情報には、この他に、ファイルシステム２に記憶されている全ファイルのデータ総量と、ファイル総数を含んでいてもよい。また、全ファイルのデータ総量と、ファイル総数は含まずに、本管理情報から求めてもよい。
【００３０】
なお、この管理情報は、ファイルシステム２側に設けられていて、ファイル管理システム３が必要に応じて必要な情報をファイルシステム２から取得して参照するようにしてもよい。ファイルシステム２からは、個々のファイルのデータ量及び最終使用時刻、並びにデータ総量及びファイル総数を取得するようにしてもよいし、個々のファイルのデータ量及び最終使用時刻を取得し、この情報からデータ総量及びファイル総数を求めるようにしてもよい。
【００３１】
あるいは、この管理情報は、ファイル管理システム３側に設けられていて、ファイルシステム２においてファイルが書き込み（新規のファイルの保存又は既存のファイルの内容の更新）、若しくは読み出し、又は削除されるごとに、ファイルシステム２（図２の例の場合はファイルシステム２又はキャッシュ４）からファイル管理システム３へ、書き込みや読み出しの場合には、そのファイルの識別情報とデータ量と最終使用時刻と（又はこれらに加えて新規保存と内容更新の別）を、削除の場合には、削除されたファイルの識別情報（又はこれに加えて削除の旨）を通知し、ファイル管理システム３は、通知された内容によって、管理情報を更新（新規登録若しくは内容の更新又は削除）するようにしてもよい。なお、本管理情報に、データ総量と、ファイル総数を含む場合には、必要に応じて、これらの値も更新する。なお、管理情報は、ファイルシステム２とファイル管理システム３との両方に設けてられてもよい。
【００３２】
また、図２の例の場合において、この管理情報は、キャッシュ４内に設けられていて、ファイル管理システム３が必要に応じて必要な情報をキャッシュ４から取得して参照するようにしてもよい。
【００３３】
以下、本実施形態のファイル管理システム３のファイル削除処理の手順について説明する。
【００３４】
図４に、本実施形態のファイル削除処理の手順の一例を示す。
【００３５】
なお、以下の説明で用いる具体例において、ＯＳ１としてはｋｅｒｎｅｌ２．４を用いたＬｉｎｕｘ（登録商標）を使用し、ファイルシステム２としてはｅｘｔ２ファイルシステムを用いた場合を例にとって説明する。もちろん、Ｌｉｎｕｘ（登録商標）のｅｘｔ３、ｒｅｉｓｅｒ、ＸＦＳ、Ｓｏｌａｉｓ（登録商標）のＵＦＳ、Ｗｉｎｄｏｗｓ（登録商標）のＦＡＴ、ＮＴＦＳなど、他のファイルシステムや他のＯＳのファイルシステムでも実施可能である。
【００３６】
また、ファイルシステム２においては、ｅｘｔ２としてフォーマットされたパーティションが／ｃａｃｈｅ＿ｄａｔａ／にｍｏｕｎｔされている場合を例にとる。
【００３７】
また、本具体例においては、一例として、／ｃａｃｈｅ＿ｄａｔａ／ディレクトリ以下には、現在、次のような配置でファイルが保存されているものとする。  
／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００／ｆｉｌｅ０００  
／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００／ｆｉｌｅ００１  
／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００／ｆｉｌｅ００２  
．．．．．  
／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００／ｆｉｌｅ９９８  
／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００／ｆｉｌｅ９９９  
／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ００１／ｆｉｌｅ０００  
／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ００１／ｆｉｌｅ００１  
．．．．．  
／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ００１／ｆｉｌｅ９９９  
／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ００２／ｆｉｌｅ０００  
．．．．．  
／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ４９９／ｆｉｌｅ０００  
．．．．  
／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ４９９／ｆｉｌｅ９９９
すなわち、／ｃａｃｈｅ＿ｄａｔａディレクトリの下にはｄｉｒ０００〜ｄｉｒ４９９の５００個のディレクトリが存在し、それぞれのディレクトリにはｆｉｌｅ００１〜ｆｉｌｅ９９９の１０００個のファイルが存在する場合を例にとる。
【００３８】
また、本具体例においては、説明を簡単にするために、各ファイル（／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ？？？／ｆｉｌｅ？？？）のサイズ（データ量）は、全て４ＫＢｙｔｅであるものとする（もちろん、各ファイルのサイズはまちまちであって構わない）。
【００３９】
また、本具体例においては、一例として、ファイル削除処理を開始するか否かを判断するためのデータ総量の閾値Ｂ１は４Ｇｂｙｔｅ、ファイル総数の閾値Ｎ１は４５万個にそれぞれ設定されているものとすし、他方、各ファイルを削除するか否かの基準となる最終使用時刻に対する閾値時刻Ｔを算出するのに用いるデータ総量の閾値Ｂ２（＜Ｂ１）は３Ｇｂｙｔｅ、ファイル総数の閾値Ｎ２（＜Ｎ１）は４０万個にそれぞれ設定されているものとする。なお、各閾値はユーザ等が任意に設定できるようにしてもよい。
【００４０】
まず、ステップＳ１において、ファイル管理システム３の開始決定処理部３１は、ファイルシステム２に記憶されているファイルのデータ総量とファイル総数を取得する。
【００４１】
例えば、Ｌｉｎｕｘ（登録商標）においては、ｓｔａｔｆｓ（）システムコールを実行することによって、これらに関する値を得ることができる。
【００４２】
なお、例えば、ファイル管理システム３が前述の管理情報を持つ構成の場合には、この管理情報を参照すればよい。
【００４３】
本具体例の場合には、ファイル数については、  
・／ｃａｃｈｅ＿ｄａｔａディレクトリ自身（１個）と、  
・／ｃａｃｈｅ＿ｄａｔａの下にあるディレクトリ（５００個）と、  
・／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００〜／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ４９９の下にあるファイル（５００＊１０００＝５０００００個）と、  
を合わせた、５００５０１個が値として得られる。  
データ総量については、ファイルに保存されているデータ量を単純に合計すると４［ＫＢｙｔｅ］＊５００＊１０００＝２，０００，０００［ＫＢ］＝２［ＧＢｙｔｅ］である。ただし、実際には、ディレクトリなどで用いられているデータ量も加算されるため、２ＧＢｙｔｅより幾分大きめの値が得られる。
【００４４】
次に、ステップＳ２において、開始決定処理部３１は、ファイル削除処理を開始するか否かを判断する。すなわち、取得したデータ総量とファイル総数と、設定されている閾値Ｂ１と閾値Ｎ１について、  
データ総量＞閾値Ｂ１  
ファイル総数＞閾値Ｎ１  
のいずれか一方でも成立すれば、ファイル削除処理を開始すると判断し、いずれも成立しなければ、開始しないと判断する。
【００４５】
本具体例の場合、データ総量は閾値の４Ｇｂｙｔｅより少ないが、ファイル総数は閾値の４５万個より多いので、「ファイル総数＞閾値Ｎ１」が成立し、ファイル削除処理を開始すると判断される。従って、この場合、処理は次にステップＳ３へと移る。
【００４６】
ステップＳ３では、閾値時刻決定処理部３２は、「ファイルシステムに記憶されているファイルのうち、最終使用時刻が閾値時刻Ｔ以前であるファイルを全て削除した場合には、データ総量は閾値Ｂ２以下となり、且つ、ファイル総数は閾値Ｎ２以下になる」という条件を満たす閾値時刻Ｔを求める。
【００４７】
この閾値時刻Ｔの求め方には、種々の方法が考えられる。例えば、（例えば前述の管理情報を参照するなどして）ファイルシステムに記憶されている個々のファイルのデータ量及び最終使用時刻をもとにして、ファイルの最終使用時刻を横軸とし、最終使用時刻がある一定範囲に収まる全てのファイルのサイズの総和を縦軸とするような第１のヒストグラムと、ファイルの最終使用時刻を横軸とし、最終使用時刻がある一定範囲に収まるファイルのファイル数を縦軸とするような第２のヒストグラムとを作成し、第１のヒストグラムにおいて、ある時刻より右側の部分に相当する量がファイル削除処理におけるデータ総量の閾値Ｂ２以下の量になり、且つ、第２のヒストグラムにおいて、その時刻より右側の部分に相当する量がファイル削除処理におけるファイル総数Ｎ２以下の量になる最初の時刻を求め、その時刻を閾値時刻Ｔとする、という方法がある。
【００４８】
この求め方を例示したものが図５の（ａ）、（ｂ）である。（ａ）は、データ量の時間分布を表す第１のヒストグラムであり、（ｂ）は、ファイル数の時間分布を表す第２のヒストグラムである。時刻を左から右へと移動させていくと、いずれかの時点で、（ａ）のハッチングされた部分に相当する量が閾値Ｂ２以下となり、（ｂ）のハッチングされた部分に相当する量が閾値Ｎ２以下となる時刻が存在する。その時刻が閾値時刻Ｔとなる。
【００４９】
本具体例では、この方法により、閾値時刻Ｔとして「２００４年２月１日１５時００分００秒」が得られたものとする。
【００５０】
次に、この閾値時刻Ｔを基準として、該当するファイルをファイルシステムから全て削除する一例の処理を行う。
【００５１】
削除処理部３３は、まず、ステップＳ４において、ファイルシステム上のファイルの中から、削除するか否かを判断する対象となるファイルを一つ選択する。
【００５２】
本具体例においては、まず、ｃｈｅ＿ｄａｔａディレクトリに対してｏｐｅｎｄｉｒ（）とｒｅａｄｄｉｒ（）を実行し、次いで、得られたエントリ（ｄｉｒ０００〜ｄｉｒ４９９のいずれか）に対して再度ｏｐｅｎｄｉｒ（）とｒｅａｄｄｉｒ（）を実行する、という手順によって、５０００００個のファイルのいずれかを得ることができる。ここでは、一例として、／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００／ｆｉｌｅ０００が得られたものとする。
【００５３】
続いて、削除処理部３３は、ステップＳ５において、そのファイルの最終使用時刻を取得する。
【００５４】
例えば、Ｌｉｎｕｘ（登録商標）では、／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００／ｆｉｌｅ０００に対してｓｔａｔ（）システムコールを実行することによって、最終使用時刻を取得することができる。
【００５５】
なお、例えば、ファイル管理システム３が前述の管理情報を持つ構成の場合には、この管理情報を参照すればよい。
【００５６】
本具体例では、／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００／ｆｉｌｅ０００の最終使用時刻が「２００４年１月１５日２２時３０分３０秒」であったとする。
【００５７】
続いて、削除処理部３３は、ステップＳ６において、取得したファイルの最終使用時刻と閾値時刻Ｔとを比較し、ファイルの最終使用時刻が閾値時刻Ｔ以前であれば、そのファイルを削除すべきと判断し、そうでなければ、削除しないと判断する。
【００５８】
本具体例では、ファイルの最終使用時刻が「２００４年１月１５日２２時３０分３０秒」であるのに対して、閾値時刻Ｔが「２００４年２月１日１５時００分００秒」であるから、ファイルの最終使用時刻は閾値時刻Ｔ以前であり、／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００／ｆｉｌｅ０００は削除すべきと判断される。従って、この場合、処理はステップＳ７に進む。
【００５９】
ステップＳ６において、ファイルが削除すべきだと判断された場合、削除処理部３３は、ステップＳ７において、そのファイルをファイルシステムから削除する。
【００６０】
例えば、Ｌｉｎｕｘ（登録商標）では、／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００／ｆｉｌｅ０００に対してｕｎｌｉｎ（）システムコールを実行することで、ファイルを削除することができる。
【００６１】
なお、ステップＳ６において、ファイルを削除しないと判断された場合、ステップＳ７はスキップする。
【００６２】
続いて、ステップＳ８において、まだ、対象になっていないファイルが存在するか否か調べ、存在すれば、まだ対象になっていないファイルが存在することになるので、ステップＳ４に戻って同様の処理を繰り返し行い、存在しなければ、全てのファイルについてステップＳ４以降の一連の処理を行ったことになるので、処理を終了する。
【００６３】
例えば、本具体例においては、／ｃａｃｈｅ＿ｄａｔａ／ｄｉｒ０００に対するｒｅａｄｄｉｒ（）システムコールが別のエントリを返すので、まだ対象になっていないファイルが存在することになる。従って、ステップＳ４に戻って同様の処理を継続する。そして、全てのファイルについて一連の処理が終了すると、ステップＳ８の結果がＹｅｓとなって、全体の処理が終了する。
【００６４】
なお、図３に例示したようなファイル削除処理は、例えば、適当な周期で、繰り返し行うようにしてもよい。また、この場合において、ステップＳ１でＹｅｓであったかＮｏであったかにかかわらずに、一定の時間が経過した後に、次回のファイル削除処理を再実行するようにしてもよいし、ステップＳ１でＮｏであった場合には、より短い時間が経過した後に、次回のファイル削除処理を再実行し、ステップＳ１でＹｅｓであった場合には、それよりは長い時間が経過した後に、次回のファイル削除処理を再実行するようにしてもよい。また、例えば、ファイルシステムへの書き込みアクセスが発生した際など、特定のイベントが発生するごとに行うようにしてもよい。また、それら以外の方法によってもよい。
【００６５】
本実施形態によれば、ファイル削除処理の過程においてデータ総量だけでなくファイルの総数が一定値以下に押さえられるため、サイズの小さなファイルが多数存在する状況が発生した結果、実際に削除されるデータ量は僅かであるにもかかわらずファイル削除処理に長い時間がかかるという状況を防ぐことができる。
【００６６】
以上では、ファイル格納手段として、ＯＳのファイルシステムを想定して説明したが、ＯＳのファイルシステム以外のファイル格納手段を管理対象とする場合も実施可能である。
【００６７】
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。  
また、本実施形態は、コンピュータに所定の手順を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【００６８】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００６９】
【図１】本発明の一実施形態に係るファイル管理システムの構成例を示す図
【図２】同実施形態に係るファイル管理システムを含むクライアント装置又はプロキシサーバ装置の構成例を示す図
【図３】同実施形態に係るファイル管理システムの処理に必要な管理情報の一例を示す図
【図４】同実施形態に係るファイル管理システムによるファイル削除処理の手順の一例を示すフローチャート
【図５】同実施形態に係るファイル管理システムによるファイル削除処理における閾値時刻を求める方法の一例について説明するための図
【符号の説明】
【００７０】
１…ＯＳ、２…ファイルシステム、３…ファイル管理システム、４…キャッシュ、２０…クライアント装置又はプロキシサーバ装置、３１…開始決定処理部、３２…閾値時刻決定処理部、３３…削除処理部
【図１】
2006139588.tif 000003
【図２】
2006139588.tif 000004
【図３】
2006139588.tif 000005
【図４】
2006139588.tif 000006
【図５】
2006139588.tif 000007