JP2006139588A - ファイル管理システム、ファイル削除方法及びプログラム - Google Patents

ファイル管理システム、ファイル削除方法及びプログラム Download PDF

Info

Publication number
JP2006139588A
JP2006139588A JP2004329357A JP2004329357A JP2006139588A JP 2006139588 A JP2006139588 A JP 2006139588A JP 2004329357 A JP2004329357 A JP 2004329357A JP 2004329357 A JP2004329357 A JP 2004329357A JP 2006139588 A JP2006139588 A JP 2006139588A
Authority
JP
Japan
Prior art keywords
file
files
storage means
file storage
time
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.)
Pending
Application number
JP2004329357A
Other languages
English (en)
Inventor
Yasuhiro Kimura
康浩 木村
Hideaki Sato
英昭 佐藤
Tokuji Shono
篤司 庄野
Yuichi Koba
雄一 木場
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.)
Toshiba Corp
Original Assignee
Toshiba Corp
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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP2004329357A priority Critical patent/JP2006139588A/ja
Publication of JP2006139588A publication Critical patent/JP2006139588A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】ファイルシステム上に多数のファイルが存在するという状況が発生しても、より短い時間でファイル削除処理を実行できるファイル管理システムを提供すること。
【解決手段】本発明では、開始決定処理部31は、ファイルシステム上のファイルのデータ総量と総数のいずれかが閾値を越えているかいずれも越えていないか調べ、閾値時刻決定処理部32は、前者の場合に、ファイルシステム上のファイルのうち、最終使用時刻が或る時刻以前であるファイルを全て削除したとすると、ファイルのデータ総量と総数がいずれも閾値以下になるような該或る時刻を求め、ファイル削除処理部33は、最終使用時刻が該或る時刻以前であるファイルを全て削除する。削除可否の基準に、データ総量とファイル総数を併用することで、より迅速なファイル削除処理が可能になる。
【選択図】 図1

Description

本発明は、ファイルシステム上のファイルを必要に応じて削除するファイル管理システム、ファイル削除方法及びプログラムに関する。
ネットワークを介して様々なサービスを提供するサーバと、所望のサービスをサーバに対して要求するクライアントとから構成される、クライアント・サーバ型の情報システムが広く利用されている。インターネット上でHTTPプロトコルを使って通信するWebサーバ装置とクライアント装置とからなるWorld Wide Webシステム(単にWebとも呼ばれる)は、近年におけるクライアント・サーバ型情報システムの代表例である。
Webのようなクライアント・サーバ型の情報システムにおいては、通常、ネットワークの負荷を軽減させるためにキャッシュ技術が用いられるが、サーバやクライアントに汎用OS(オペレーティングシステム)を用いる場合、キャッシュ機構においては、キャッシュすべきデータの保存に汎用OSのファイルシステムを利用するのが一般的である。
ところで、ファイルシステムに保存可能なデータの総量には、ディスク装置の容量などの要因によって、ある上限が存在する。このため、キャッシュ機構の持続的な動作のためには、ファイルシステム上に存在するファイルのいくつかを削除して、データの総量をある一定値以下に削除するファイル削除処理が必要となる。
"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の閾値を超えている第2の条件の少なくとも一方が成立しているか否かを判断する第1の処理手段と、前記第1の条件又は前記第2の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、そのファイルが使用された最も遅い時刻を示す最終使用時刻が特定の閾値時刻以前であるファイルを全て削除したとすると、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第3の閾値以下になり且つ前記ファイル記憶手段に記憶されているファイルの総数が第4の閾値以下になるような、特定の閾値時刻を求める第2の処理手段と、前記第1の条件又は前記第2の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、前記最終使用時刻が前記特定の時刻以前であるファイルを全て削除する第3の処理手段とを備えたことを特徴とする。
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための(あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための)プログラムとしても成立し、該プログラムを記録したコンピュータ読み取り可能な記録媒体としても成立する。
本発明によれば、ファイルシステム上に多数のファイルが存在する状況において、より短い処理時間でファイルを削除する処理を実行することができるようになる。
以下、図面を参照しながら本発明の実施形態について説明する。
本実施形態では、管理対象とするファイル格納手段として、OS(特に汎用OS)のファイルシステムを想定して説明する。また、Webのようなクライアント・サーバ型の情報システムで使用されるキャッシュ機構が、キャッシュすべきデータの保存に、OSのファイルシステムを利用する場合を想定して説明する。
まず、本実施形態で想定するシステムの基本的な構成と従来システムにおける問題点について詳しく説明する。
Webのようなクライアント・サーバ型の情報システムにおいては、提供されるサービスがどのような形態のものであろうと、基本的にはクライアント・サーバ間でデータ転送が行われることによってサービスが提供される。したがって、クライアントとサーバとの間での通信に用いるネットワークの容量(バンド幅)が、システム全体のボトルネックになりやすい。そこで、前述したように、通常、ネットワークの負荷を軽減させるためにキャッシュ技術が用いられる。
Webシステムの場合、クライアント上で動作するブラウザ等は、キャッシュ機構を使用するものが多く、最近アクセスしたデータをキャッシュしている。また、企業のオフィス内のLAN、研究機関におけるLAN或いは家庭内のLANなどで複数のユーザがいる場合、LANとインターネットとの間にプロキシサーバを置き、プロキシサーバにキャッシュ機構を設けるようにすることも多い。
ところで、クライアント・サーバ型の情報システムを実際に構築するにあたっては、サーバやクライアントに汎用OSを搭載した計算機を用いて、必要な機能をソフトウェアプログラムとして実装する手法が広く用いられている。機能をプログラムとして実装することにより、実装自体を容易に行うことができ、また機能の修正や追加などの保守を容易に行うことができる。Webシステムにおいても、サーバやクライアントにおいて必要な機能を汎用OS上のプログラムとして実装した例が実際に存在し、それらが様々なWebシステムの構築において用いられている。
このように、Webシステムのサーバやクライアントに汎用OSを用いる場合、前述のキャッシュ機構においては、キャッシュすべきデータの保存に汎用OSのファイルシステムを利用するのが一般的である。すなわち、ブラウザやプロキシサーバは、或るURL(Uniform Resouce Locators)へのHTTPリクエストに対するレスポンスを受信すると、それらの内容をファイルシステム上の一つのファイルに保存する。そして後で同じURLへのリクエストが発せられた際に、そのファイルから読み出したデータをHTTPレスポンスとして用いる。
様々なURLへのリクエストが送信され、レスポンスが保存されるにつれて、ファイルシステム上に存在するファイルの総数や、ファイルシステム上に保存されているファイルのデータ総量は増加していく。計算機に接続されているディスク装置の容量などの要因によって、ファイルシステムに保存可能なファイルのデータ総量にはある上限が存在する。そのため、キャッシュ機構の持続的な動作のためには、ファイルシステム上に存在するファイルのいくつかを削除して、データ総量をある一定値以下に削減するファイル削除処理が必要となる。この場合、削除されるファイルとしては、長い間使われていないファイルを削除するのが望ましい。従って、ファイルシステム上に存在する全てのファイルの中から、最終使用時間が古いものを削除して、データ総量を一定値以下に削減することになる。
ところで、Webシステムのデータ転送における特徴として、
・一つのリクエストに対して送信されるレスポンスデータのサイズ(データ量)が比較的小さい、
・クライアント側での一つの処理に対して複数のリクエスト送信&レスポンス受信が行われる、
といったことがあげられる。例えば、ブラウザで特定のURLにアクセスして画面が表示されるという典型的なケースを考えると、Webサーバからブラウザに対して数KByte〜数十KByteのHTMLや画像データが数十個送信されるといった状況になる。従って、このようなデータをファイルシステム上のファイルとして保存していった場合、ファイルシステム上には比較的小さいサイズのファイルが非常に多数存在するという状況が発生しやすい。
従って、ファイル削除処理は、ファイル数が非常に多い状態で実行されるわけであるが、そのような場合には、削除対象のファイルのリストを持つような方法は計算機のリソース的に困難であることが多い。そのため、このような場合には、ファイルの最終使用時刻を一つずつ確認して削除するか否かを決める方式を取ることが多い。
具体的には以下のような手順となる。
(1)「ファイルシステム上のファイルのデータ総量がある閾値を越えた状態である」という条件が成立しているか否かを調べ、成立している場合は次の処理(2)に進む。成立していない場合は処理を終了する。
(2)「ファイルの最終使用時刻がT´以前であるファイルを全て削除すれば、ファイルシステム上のファイルのデータ総量がある閾値以下になる」という条件を満たす時刻T´を求め、次の処理(3)に進む。
(3)ファイルシステム上のファイルのうち、最終使用時刻が上記時刻T´以前であるファイルをすべて削除する。
さて、上記手順において、処理(3)では、各ファイルの最終使用時刻と時刻T´とを比較する処理が必要になるが、この比較処理は、ファイルシステム上の全てのファイルに対して実行されるので、この比較処理に要する時間の総和はファイルシステム上のファイルの総数に依存する。従って、前述のWebのキャッシュ機能のように、ファイルシステム上に比較的小さいサイズのファイルが非常に多数存在するという状況においては、この比較処理に要する総時間が、全体の処理時間に大きく影響してくる。そのため、前述したように、実際に削除するファイルのデータ総量はファイル削除処理前の全ファイルのデータ総量に比べて少ない量であるにもかかわらず、処理全体に擁する時間が非常に長くなるという問題があった。
以下、本実施形態に係るシステムについて詳しく説明する。
図1に、本発明の一実施形態に係るファイル管理システムの構成例を示す。
図1に示されるように、本実施形態のファイル管理システム3は、開始決定処理部31、閾値時刻決定処理部32、削除処理部33を備えている。
図1中、2は、本ファイル管理システム3が管理対象とする、或るOS(図示せず)のファイルシステムを表している。
ファイル管理システム3は、OSが動作する計算機と同一の計算機上で動作するプログラムとして実現してもよいし(この場合に、ファイル管理システムのプログラムは、該OS上で動作するものであってもよい)、同計算機にハードウェアとして組み込まれてもよい。また、OSが動作する計算機と異なる計算機上で動作するプログラムとして実現してもよいし(この場合に、ファイル管理システムのプログラムは、該OS上で動作するものであってもよい)、同計算機にハードウェアとして組み込まれてもよい。
図2に、本ファイル管理システム3の管理対象とするOSのファイルシステム2が、ブラウザ(プロセス)又はプロキシ(プロセス)で使用されるキャッシュにより、データ保存のために使用される場合の構成例を示す。
図2中、20はブラウザ(図示せず)が動作するクライアント装置(計算機)又はプロキシ(図示せず)が動作するプロキシサーバ装置(計算機)等であり、4はこれまで説明してきたようなキャッシュである。なお、図2は、ファイルシステム2とファイル管理システム3とキャッシュ4とが同一の計算機上に存在する場合を例にとっている。
図3に、本ファイル管理システム3の処理に必要な管理情報の一例を示す。図2に示されるように、本管理情報は、ファイルシステム2に記憶されている全ファイルについて、当該ファイルを識別可能なファイル識別情報と、当該ファイルのデータ量と、当該ファイルの最終使用時刻(当該ファイルが書き込み(新規の保存又は内容の変更)、読み出し、削除等の使用をされた最も遅い時刻)とを対応付けて保持するものである。なお、本管理情報には、この他に、ファイルシステム2に記憶されている全ファイルのデータ総量と、ファイル総数を含んでいてもよい。また、全ファイルのデータ総量と、ファイル総数は含まずに、本管理情報から求めてもよい。
なお、この管理情報は、ファイルシステム2側に設けられていて、ファイル管理システム3が必要に応じて必要な情報をファイルシステム2から取得して参照するようにしてもよい。ファイルシステム2からは、個々のファイルのデータ量及び最終使用時刻、並びにデータ総量及びファイル総数を取得するようにしてもよいし、個々のファイルのデータ量及び最終使用時刻を取得し、この情報からデータ総量及びファイル総数を求めるようにしてもよい。
あるいは、この管理情報は、ファイル管理システム3側に設けられていて、ファイルシステム2においてファイルが書き込み(新規のファイルの保存又は既存のファイルの内容の更新)、若しくは読み出し、又は削除されるごとに、ファイルシステム2(図2の例の場合はファイルシステム2又はキャッシュ4)からファイル管理システム3へ、書き込みや読み出しの場合には、そのファイルの識別情報とデータ量と最終使用時刻と(又はこれらに加えて新規保存と内容更新の別)を、削除の場合には、削除されたファイルの識別情報(又はこれに加えて削除の旨)を通知し、ファイル管理システム3は、通知された内容によって、管理情報を更新(新規登録若しくは内容の更新又は削除)するようにしてもよい。なお、本管理情報に、データ総量と、ファイル総数を含む場合には、必要に応じて、これらの値も更新する。なお、管理情報は、ファイルシステム2とファイル管理システム3との両方に設けてられてもよい。
また、図2の例の場合において、この管理情報は、キャッシュ4内に設けられていて、ファイル管理システム3が必要に応じて必要な情報をキャッシュ4から取得して参照するようにしてもよい。
以下、本実施形態のファイル管理システム3のファイル削除処理の手順について説明する。
図4に、本実施形態のファイル削除処理の手順の一例を示す。
なお、以下の説明で用いる具体例において、OS1としてはkernel2.4を用いたLinux(登録商標)を使用し、ファイルシステム2としてはext2ファイルシステムを用いた場合を例にとって説明する。もちろん、Linux(登録商標)のext3、reiser、XFS、Solais(登録商標)のUFS、Windows(登録商標)のFAT、NTFSなど、他のファイルシステムや他のOSのファイルシステムでも実施可能である。
また、ファイルシステム2においては、ext2としてフォーマットされたパーティションが/cache_data/にmountされている場合を例にとる。
また、本具体例においては、一例として、/cache_data/ディレクトリ以下には、現在、次のような配置でファイルが保存されているものとする。
/cache_data/dir000/file000
/cache_data/dir000/file001
/cache_data/dir000/file002
.....
/cache_data/dir000/file998
/cache_data/dir000/file999
/cache_data/dir001/file000
/cache_data/dir001/file001
.....
/cache_data/dir001/file999
/cache_data/dir002/file000
.....
/cache_data/dir499/file000
....
/cache_data/dir499/file999
すなわち、/cache_dataディレクトリの下にはdir000〜dir499の500個のディレクトリが存在し、それぞれのディレクトリにはfile001〜file999の1000個のファイルが存在する場合を例にとる。
また、本具体例においては、説明を簡単にするために、各ファイル(/cache_data/dir???/file???)のサイズ(データ量)は、全て4KByteであるものとする(もちろん、各ファイルのサイズはまちまちであって構わない)。
また、本具体例においては、一例として、ファイル削除処理を開始するか否かを判断するためのデータ総量の閾値B1は4Gbyte、ファイル総数の閾値N1は45万個にそれぞれ設定されているものとすし、他方、各ファイルを削除するか否かの基準となる最終使用時刻に対する閾値時刻Tを算出するのに用いるデータ総量の閾値B2(<B1)は3Gbyte、ファイル総数の閾値N2(<N1)は40万個にそれぞれ設定されているものとする。なお、各閾値はユーザ等が任意に設定できるようにしてもよい。
まず、ステップS1において、ファイル管理システム3の開始決定処理部31は、ファイルシステム2に記憶されているファイルのデータ総量とファイル総数を取得する。
例えば、Linux(登録商標)においては、statfs()システムコールを実行することによって、これらに関する値を得ることができる。
なお、例えば、ファイル管理システム3が前述の管理情報を持つ構成の場合には、この管理情報を参照すればよい。
本具体例の場合には、ファイル数については、
・/cache_dataディレクトリ自身(1個)と、
・/cache_dataの下にあるディレクトリ(500個)と、
・/cache_data/dir000〜/cache_data/dir499の下にあるファイル(500*1000=500000個)と、
を合わせた、500501個が値として得られる。
データ総量については、ファイルに保存されているデータ量を単純に合計すると4[KByte]*500*1000=2,000,000[KB]=2[GByte]である。ただし、実際には、ディレクトリなどで用いられているデータ量も加算されるため、2GByteより幾分大きめの値が得られる。
次に、ステップS2において、開始決定処理部31は、ファイル削除処理を開始するか否かを判断する。すなわち、取得したデータ総量とファイル総数と、設定されている閾値B1と閾値N1について、
データ総量>閾値B1
ファイル総数>閾値N1
のいずれか一方でも成立すれば、ファイル削除処理を開始すると判断し、いずれも成立しなければ、開始しないと判断する。
本具体例の場合、データ総量は閾値の4Gbyteより少ないが、ファイル総数は閾値の45万個より多いので、「ファイル総数>閾値N1」が成立し、ファイル削除処理を開始すると判断される。従って、この場合、処理は次にステップS3へと移る。
ステップS3では、閾値時刻決定処理部32は、「ファイルシステムに記憶されているファイルのうち、最終使用時刻が閾値時刻T以前であるファイルを全て削除した場合には、データ総量は閾値B2以下となり、且つ、ファイル総数は閾値N2以下になる」という条件を満たす閾値時刻Tを求める。
この閾値時刻Tの求め方には、種々の方法が考えられる。例えば、(例えば前述の管理情報を参照するなどして)ファイルシステムに記憶されている個々のファイルのデータ量及び最終使用時刻をもとにして、ファイルの最終使用時刻を横軸とし、最終使用時刻がある一定範囲に収まる全てのファイルのサイズの総和を縦軸とするような第1のヒストグラムと、ファイルの最終使用時刻を横軸とし、最終使用時刻がある一定範囲に収まるファイルのファイル数を縦軸とするような第2のヒストグラムとを作成し、第1のヒストグラムにおいて、ある時刻より右側の部分に相当する量がファイル削除処理におけるデータ総量の閾値B2以下の量になり、且つ、第2のヒストグラムにおいて、その時刻より右側の部分に相当する量がファイル削除処理におけるファイル総数N2以下の量になる最初の時刻を求め、その時刻を閾値時刻Tとする、という方法がある。
この求め方を例示したものが図5の(a)、(b)である。(a)は、データ量の時間分布を表す第1のヒストグラムであり、(b)は、ファイル数の時間分布を表す第2のヒストグラムである。時刻を左から右へと移動させていくと、いずれかの時点で、(a)のハッチングされた部分に相当する量が閾値B2以下となり、(b)のハッチングされた部分に相当する量が閾値N2以下となる時刻が存在する。その時刻が閾値時刻Tとなる。
本具体例では、この方法により、閾値時刻Tとして「2004年2月1日15時00分00秒」が得られたものとする。
次に、この閾値時刻Tを基準として、該当するファイルをファイルシステムから全て削除する一例の処理を行う。
削除処理部33は、まず、ステップS4において、ファイルシステム上のファイルの中から、削除するか否かを判断する対象となるファイルを一つ選択する。
本具体例においては、まず、che_dataディレクトリに対してopendir()とreaddir()を実行し、次いで、得られたエントリ(dir000〜dir499のいずれか)に対して再度opendir()とreaddir()を実行する、という手順によって、500000個のファイルのいずれかを得ることができる。ここでは、一例として、/cache_data/dir000/file000が得られたものとする。
続いて、削除処理部33は、ステップS5において、そのファイルの最終使用時刻を取得する。
例えば、Linux(登録商標)では、/cache_data/dir000/file000に対してstat()システムコールを実行することによって、最終使用時刻を取得することができる。
なお、例えば、ファイル管理システム3が前述の管理情報を持つ構成の場合には、この管理情報を参照すればよい。
本具体例では、/cache_data/dir000/file000の最終使用時刻が「2004年1月15日22時30分30秒」であったとする。
続いて、削除処理部33は、ステップS6において、取得したファイルの最終使用時刻と閾値時刻Tとを比較し、ファイルの最終使用時刻が閾値時刻T以前であれば、そのファイルを削除すべきと判断し、そうでなければ、削除しないと判断する。
本具体例では、ファイルの最終使用時刻が「2004年1月15日22時30分30秒」であるのに対して、閾値時刻Tが「2004年2月1日15時00分00秒」であるから、ファイルの最終使用時刻は閾値時刻T以前であり、/cache_data/dir000/file000は削除すべきと判断される。従って、この場合、処理はステップS7に進む。
ステップS6において、ファイルが削除すべきだと判断された場合、削除処理部33は、ステップS7において、そのファイルをファイルシステムから削除する。
例えば、Linux(登録商標)では、/cache_data/dir000/file000に対してunlin()システムコールを実行することで、ファイルを削除することができる。
なお、ステップS6において、ファイルを削除しないと判断された場合、ステップS7はスキップする。
続いて、ステップS8において、まだ、対象になっていないファイルが存在するか否か調べ、存在すれば、まだ対象になっていないファイルが存在することになるので、ステップS4に戻って同様の処理を繰り返し行い、存在しなければ、全てのファイルについてステップS4以降の一連の処理を行ったことになるので、処理を終了する。
例えば、本具体例においては、/cache_data/dir000に対するreaddir()システムコールが別のエントリを返すので、まだ対象になっていないファイルが存在することになる。従って、ステップS4に戻って同様の処理を継続する。そして、全てのファイルについて一連の処理が終了すると、ステップS8の結果がYesとなって、全体の処理が終了する。
なお、図3に例示したようなファイル削除処理は、例えば、適当な周期で、繰り返し行うようにしてもよい。また、この場合において、ステップS1でYesであったかNoであったかにかかわらずに、一定の時間が経過した後に、次回のファイル削除処理を再実行するようにしてもよいし、ステップS1でNoであった場合には、より短い時間が経過した後に、次回のファイル削除処理を再実行し、ステップS1でYesであった場合には、それよりは長い時間が経過した後に、次回のファイル削除処理を再実行するようにしてもよい。また、例えば、ファイルシステムへの書き込みアクセスが発生した際など、特定のイベントが発生するごとに行うようにしてもよい。また、それら以外の方法によってもよい。
本実施形態によれば、ファイル削除処理の過程においてデータ総量だけでなくファイルの総数が一定値以下に押さえられるため、サイズの小さなファイルが多数存在する状況が発生した結果、実際に削除されるデータ量は僅かであるにもかかわらずファイル削除処理に長い時間がかかるという状況を防ぐことができる。
以上では、ファイル格納手段として、OSのファイルシステムを想定して説明したが、OSのファイルシステム以外のファイル格納手段を管理対象とする場合も実施可能である。
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。
また、本実施形態は、コンピュータに所定の手順を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
本発明の一実施形態に係るファイル管理システムの構成例を示す図 同実施形態に係るファイル管理システムを含むクライアント装置又はプロキシサーバ装置の構成例を示す図 同実施形態に係るファイル管理システムの処理に必要な管理情報の一例を示す図 同実施形態に係るファイル管理システムによるファイル削除処理の手順の一例を示すフローチャート 同実施形態に係るファイル管理システムによるファイル削除処理における閾値時刻を求める方法の一例について説明するための図
符号の説明
1…OS、2…ファイルシステム、3…ファイル管理システム、4…キャッシュ、20…クライアント装置又はプロキシサーバ装置、31…開始決定処理部、32…閾値時刻決定処理部、33…削除処理部

Claims (15)

  1. 複数のファイルを記憶するファイル記憶手段を管理対象とするファイル管理システムであって、
    前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第1の閾値を超えている第1の条件又は前記ファイル記憶手段に保持されているファイルの総数が第2の閾値を超えている第2の条件の少なくとも一方が成立しているか否かを判断する第1の処理手段と、
    前記第1の条件又は前記第2の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、そのファイルが使用された最も遅い時刻を示す最終使用時刻が特定の閾値時刻以前であるファイルを全て削除したとすると、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第3の閾値以下になり且つ前記ファイル記憶手段に記憶されているファイルの総数が第4の閾値以下になるような、特定の閾値時刻を求める第2の処理手段と、
    前記第1の条件又は前記第2の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、前記最終使用時刻が前記特定の時刻以前であるファイルを全て削除する第3の処理手段とを備えたことを特徴とするファイル管理システム。
  2. 少なくとも前記ファイル記憶手段に記憶されている個々のファイルのデータ量及び最終使用時刻を示す情報を記憶する手段を更に備えたことを特徴とする請求項1に記載のファイル管理システム。
  3. 少なくとも前記ファイル記憶手段に記憶されている個々のファイルのデータ量及び最終使用時刻を示す情報を前記ファイル記憶手段から取得する手段を更に備えたことを特徴とする請求項1に記載のファイル管理システム。
  4. 前記第3の閾値は前記第1の閾値より小さい値であり、前記第4の閾値は前記第2の閾値より小さい値であることを特徴とする請求項1に記載のファイル管理システム。
  5. 前記ファイル記憶手段は、特定のオペレーティングシステム上のファイルシステムであることを特徴とする請求項1に記載のファイル管理システム。
  6. 前記第1乃至第3の処理手段は、前記特定のオペレーティングシステムが動作する計算機と同一の計算機上に設けられるものであることを特徴とする請求項5に記載のファイル管理システム。
  7. 前記計算機は、データを要求するブラウザの動作するクライアント装置又はデータを転送するプロキシサーバ装置を構成する計算機であり、
    前記ファイル記憶手段は、前記クライアント装置又は前記プロキシサーバ装置が使用するキャッシュにより、キャッシュすべきデータをファイルとして保存するために使用されるものであることを特徴とする請求項6に記載のファイル管理システム。
  8. 第1乃至第3の処理手段を備え、複数のファイルを記憶するファイル記憶手段を管理対象とする、ファイル管理システムにおけるファイル削除方法において、
    前記第1の処理手段により、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第1の閾値を超えている第1の条件又は前記ファイル記憶手段に保持されているファイルの総数が第2の閾値を超えている第2の条件の少なくとも一方が成立しているか否かを判断するステップと、
    前記第2の処理手段により、前記第1の条件又は前記第2の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、そのファイルが使用された最も遅い時刻を示す最終使用時刻が特定の閾値時刻以前であるファイルを全て削除したとすると、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第3の閾値以下になり且つ前記ファイル記憶手段に記憶されているファイルの総数が第4の閾値以下になるような、特定の閾値時刻を求めるステップと、
    前記第3の処理手段により、前記第1の条件又は前記第2の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、前記最終使用時刻が前記特定の時刻以前であるファイルを全て削除するステップとを有することを特徴とするファイル削除方法。
  9. 第1乃至第3の処理手段を備え、複数のファイルを記憶するファイル記憶手段を管理対象とする、ファイル管理システムとしてコンピュータを機能させるためのプログラムであって、
    前記プログラムは、
    前記第1の処理手段により、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第1の閾値を超えている第1の条件又は前記ファイル記憶手段に保持されているファイルの総数が第2の閾値を超えている第2の条件の少なくとも一方が成立しているか否かを判断するステップと、
    前記第2の処理手段により、前記第1の条件又は前記第2の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、そのファイルが使用された最も遅い時刻を示す最終使用時刻が特定の閾値時刻以前であるファイルを全て削除したとすると、前記ファイル記憶手段に記憶されているファイルのデータ量の総和が第3の閾値以下になり且つ前記ファイル記憶手段に記憶されているファイルの総数が第4の閾値以下になるような、特定の閾値時刻を求めるステップと、
    前記第3の処理手段により、前記第1の条件又は前記第2の条件の少なくとも一方が成立していると判断された場合に、前記ファイル記憶手段に記憶されているファイルのうち、前記最終使用時刻が前記特定の時刻以前であるファイルを全て削除するステップとを前記コンピュータに実行させるものであることを特徴とするプログラム。
  10. 前記ファイル管理システムは、情報記憶手段を更に備え、
    前記プログラムは、前記情報記憶手段により、少なくとも前記ファイル記憶手段に記憶されている個々のファイルのデータ量及び最終使用時刻を示す情報を記憶するステップを更に前記コンピュータに実行させるものであることを特徴とする請求項9に記載のプログラム。
  11. 前記ファイル管理システムは、情報取得手段を更に備え、
    前記プログラムは、前記情報取得手段により、少なくとも前記ファイル記憶手段に記憶されている個々のファイルのデータ量及び最終使用時刻を示す情報を前記ファイル記憶手段から取得するステップを更に前記コンピュータに実行させるものであることを特徴とする請求項9に記載のプログラム。
  12. 前記第3の閾値は前記第1の閾値より小さい値であり、前記第4の閾値は前記第2の閾値より小さい値であることを特徴とする請求項9に記載のプログラム。
  13. 前記ファイル記憶手段は、特定のオペレーティングシステム上のファイルシステムであることを特徴とする請求項9に記載のプログラム。
  14. 前記特定のオペレーティングシステムは、前記コンピュータと同一のコンピュータ上で動作するものであることを特徴とする請求項13に記載のプログラム。
  15. 前記コンピュータは、データを要求するブラウザの動作するクライアント装置又はデータを転送するプロキシサーバ装置を構成するコンピュータであり、
    前記ファイル記憶手段は、前記クライアント装置又は前記プロキシサーバ装置が使用するキャッシュにより、キャッシュすべきデータをファイルとして保存するために使用されるものであることを特徴とする請求項14に記載のプログラム。
JP2004329357A 2004-11-12 2004-11-12 ファイル管理システム、ファイル削除方法及びプログラム Pending JP2006139588A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2004329357A JP2006139588A (ja) 2004-11-12 2004-11-12 ファイル管理システム、ファイル削除方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004329357A JP2006139588A (ja) 2004-11-12 2004-11-12 ファイル管理システム、ファイル削除方法及びプログラム

Publications (1)

Publication Number Publication Date
JP2006139588A true JP2006139588A (ja) 2006-06-01

Family

ID=36620370

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004329357A Pending JP2006139588A (ja) 2004-11-12 2004-11-12 ファイル管理システム、ファイル削除方法及びプログラム

Country Status (1)

Country Link
JP (1) JP2006139588A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104182439A (zh) * 2014-02-26 2014-12-03 无锡天脉聚源传媒科技有限公司 一种文件自动清理的方法及装置
CN104991949A (zh) * 2015-07-16 2015-10-21 北京京东尚科信息技术有限公司 移动终端及其文件管理系统和方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104182439A (zh) * 2014-02-26 2014-12-03 无锡天脉聚源传媒科技有限公司 一种文件自动清理的方法及装置
CN104991949A (zh) * 2015-07-16 2015-10-21 北京京东尚科信息技术有限公司 移动终端及其文件管理系统和方法

Similar Documents

Publication Publication Date Title
JP7378870B2 (ja) ファイルシステムデータアクセス方法およびファイルシステム
US11675811B2 (en) Storage constrained synchronization of shared content items
US9805056B2 (en) Synchronizing file updates between two cloud controllers of a distributed filesystem
US9792294B2 (en) Using byte-range locks to manage multiple concurrent accesses to a file in a distributed filesystem
US9646022B2 (en) Distributed change notifications for a distributed filesystem
US9185164B1 (en) Idle state triggered constrained synchronization of shared content items
JP4263672B2 (ja) キャッシュに格納されたオブジェクトを管理するためのシステムおよび方法
JP4698756B2 (ja) ウェブベースアプリケーションのオフライン実行
EP2062125B1 (en) System and method for providing high availability data
US7243136B2 (en) Approach for managing and providing content to users
KR101587631B1 (ko) 클라우드 기반 로컬 장치와 로컬 장치의 파일 읽기 및 저장 방법
US20080271130A1 (en) Minimizing client-side inconsistencies in a distributed virtual file system
US20150356110A1 (en) Managing opportunistic locks in a distributed filesystem
US20190205056A1 (en) Transparent data movement between a private cloud and storage ecosystem and another storage system
US20170308599A1 (en) Storage Constrained Synchronization Engine
CN107197359B (zh) 视频文件缓存方法及装置
US8706853B2 (en) Content processing apparatus, content processing method, and recording medium
JP6475295B2 (ja) 共有コンテンツアイテムのストレージ制約付きの同期
JP2014056319A (ja) 情報処理装置およびプログラム、制御方法
CN111177159B (zh) 一种数据处理的系统、方法和数据更新设备
JP7209067B2 (ja) ストレージ制約付きの同期エンジン
US11562000B2 (en) Storage constrained synchronization engine
CN112433921A (zh) 用于动态埋点的方法及设备
CN109254958A (zh) 分布式数据读写方法、设备及系统
JP2006139588A (ja) ファイル管理システム、ファイル削除方法及びプログラム

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090210

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090707