JP2013525869A - サーバ装置及びサーバ装置の制御方法 - Google Patents

サーバ装置及びサーバ装置の制御方法 Download PDF

Info

Publication number
JP2013525869A
JP2013525869A JP2012546280A JP2012546280A JP2013525869A JP 2013525869 A JP2013525869 A JP 2013525869A JP 2012546280 A JP2012546280 A JP 2012546280A JP 2012546280 A JP2012546280 A JP 2012546280A JP 2013525869 A JP2013525869 A JP 2013525869A
Authority
JP
Japan
Prior art keywords
file
quota
user
server device
storage device
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.)
Granted
Application number
JP2012546280A
Other languages
English (en)
Other versions
JP5439607B2 (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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Publication of JP2013525869A publication Critical patent/JP2013525869A/ja
Application granted granted Critical
Publication of JP5439607B2 publication Critical patent/JP5439607B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0653—Monitoring storage devices or systems
    • 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
    • G06F16/17—Details of further file system functions
    • G06F16/178—Techniques for file synchronisation in file systems
    • 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
    • G06F16/18—File system types
    • G06F16/185—Hierarchical storage management [HSM] systems, e.g. file migration or policies thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0647—Migration mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3485—Performance evaluation by tracing or monitoring for I/O devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

マイグレーションによって生じる他のユーザへの影響を抑えつつ、マイグレーションを適切に行えるようにする。第１ストレージ装置１０ａ、及び第２ストレージ装置１０ｂが接続する第２サーバ装置３ｂとが接続する第１サーバ装置３ａにおいて、使用量がユーザクオータに基づく閾値を超えているユーザが所有するファイルを第２ストレージ装置１０ｂへのマイグレーション対象とするユーザクオータに基づく管理を行い、マイグレーション対象とされているファイルのうち複数ユーザによって使用されているファイルをユーザクオータに基づく管理対象から外し、そのファイルを使用している複数ユーザのユーザクオータから供出されるファイルクオータに基づく管理の対象とするようにする。ファイルの容量がファイルクオータを超えた場合はそのファイルを再びユーザクオータに基づく管理対象とする。
【選択図】 図１２

Description

この発明は、サーバ装置及びサーバ装置の制御方法に関し、特にファイルをマイグレーションすることによって生じる他のユーザへの影響を抑えつつ、マイグレーションを適切に行えるようにするための技術に関する。
特許文献１には、２つのサーバ（ファイルサーバ）間でファイルのデータをマイグレーション（Migration）する技術に関し、クライアント、１次ストレージを有する第１サーバ、２次ストレージを有する第２サーバ、及び制御装置を含むシステムにおいて、１次ストレージから２次ストレージにマイグレーションされた実ファイルの位置情報を記録したスタブファイルを１次ストレージに配置し、制御装置が、クライアントから第１のサーバの１次ストレージへのファイルアクセス要求を受けた場合にアクセス対象のファイルがスタブファイルであるか否か判定し、判定の結果、アクセス対象のファイルがスタブファイルであり、かつ、ファイルアクセス要求が実ファイルへのアクセスを必要とする場合に、スタブファイルの情報に基づき２次ストレージの実ファイルにアクセスしてクライアントに応答を返すことが記載されている。
また同文献には、ファイルをスタブ化するトリガーとして、ストレージ容量が閾値に達した場合にスタブ化を行うこと、スタブ化はアクセスがないファイルから行うこと、クオータ設定値に応じてアクセスの古いファイルを下階層に移動することなどが記載されている。
特開２００６−１６４２１１号公報
ところで、上記のように、ストレージ容量が閾値に達した場合にスタブ化を行うようにした場合、ファイルサーバを利用するあるユーザが所有するファイルのファイルサイズ（データサイズ）が大きくなると他のユーザが所有するファイルについてもスタブ化の対象となり、他のユーザが実ファイルにアクセスする際にリコール（第２サーバからの実ファイルを取得）が発生し、アクセス性能が低下するなど他のユーザのサービスにも影響が生じてしまう。またクオータ設定値に応じてスタブ化を行うようにした場合でも、あるユーザが所有するファイルが他のユーザによっても使用（共用）されている場合には、あるユーザが所有するファイルがマイグレーションされてスタブ化されることにより、そのファイルにアクセスしている他のユーザに影響が生じてしまうことになる。
本発明はこのような背景に鑑みてなされたもので、マイグレーションを適切に行うとともに、マイグレーションによって生じる他のユーザへの影響を抑えることが可能な、サーバ装置及びサーバ装置の制御方法の制御方法を提供することを主たる目的とする。
上記目的を達成するための本発明の一つは、クライアント装置と、第１ストレージ装置と、第２ストレージ装置が通信可能に接続する第２サーバ装置と、が通信可能に接続する第１サーバ装置であって、前記クライアント装置から前記ファイルに対するアクセス要求を受け付けると、前記第１ストレージ装置に格納されている前記ファイルのデータに対して書き込み又は読み出しを行い、ユーザごとの記憶資源の使用量の制限を規定した情報であるユーザクオータを管理し、あるユーザの使用量が前記ユーザクオータに基づく閾値を超えている場合に、そのユーザが所有するファイルを前記第２ストレージ装置へのマイグレーションの対象とする、ユーザクオータに基づく管理を行い、マイグレーションの対象として特定された前記ファイルのうち、複数のユーザによって使用されているファイルを前記ユーザクオータに基づく管理の対象から外すとともに、当該ファイルを、そのファイルを使用している複数のユーザの前記ユーザクオータから供出される、ファイルごとの容量の制限を規定した情報であるファイルクオータに基づく管理の対象とし、前記ファイルクオータに基づく管理対象とされているあるファイルの容量が、前記ファイルクオータに基づく閾値を超えている場合に、そのファイルを前記ファイルクオータに基づく管理対象から外すとともに、当該ファイルを前記ユーザクオータに基づく管理対象とすることとする。
その他本願が開示する課題やその解決方法については、発明の実施形態の欄及び図面により明らかにされる。
本発明によれば、ファイルをマイグレーションすることによって生じる他のユーザへの影響を抑えつつ、マイグレーションを適切に行うことができる。
情報処理システム１の概略的な構成を示す図である。 クライアント装置２のハードウエアの一例である。 第１サーバ装置３ａ又は第２サーバ装置３ｂとして利用可能な情報処理装置のハードウエアの一例である。 第１ストレージ装置１０ａ又は第２ストレージ装置１０ｂのハードウエアの一例である。 チャネル基板１１のハードウエアの一例である。 プロセッサ基板１２のハードウエアの一例である。 ドライブ基板１３のハードウエアの一例である。 ストレージ装置１０の基本的な機能を示す図である。 書き込み処理Ｓ９００を説明するフローチャートである。 読み出し処理Ｓ１０００を説明するフローチャートである。 クライアント装置２が備える主な機能を示す図である。 第１サーバ装置３ａが備える主な機能、及び第１サーバ装置３ａにおいて管理される主な情報（データ）を示す図である。 ユーザクオータ管理テーブル３３１の一例である。 ファイルクオータ管理テーブル３３２の一例である。 ファイルアクセスログ３３５の一例である。 第２サーバ装置３ｂが備える主な機能、及び第２サーバ装置３ｂにおいて管理される主な情報（データ）を示す図である。 ファイルシステム構造１７００を説明する図である。 ｉｎｏｄｅを説明する図である。 ｉｎｏｄｅの概念を説明する図である。 ｉｎｏｄｅ管理テーブル１７１２の一例である。 本実施形態のｉｎｏｄｅ管理テーブル１７１２の構成を示す図である。 レプリケーション開始処理Ｓ２２００を説明する図である。 マイグレーション候補設定処理Ｓ２３００を説明する図である。 クオータ管理方式変更処理Ｓ２４００を説明する図である。 マイグレーション実施処理Ｓ２５００を説明する図である。 レプリケーションファイル更新処理Ｓ２６００を説明する図である。 同期処理Ｓ２７００を説明する図である。 メタデータアクセス処理Ｓ２８００を説明する図である。 マイグレーションファイル参照処理Ｓ２９００を説明する図である。 マイグレーションファイル更新処理Ｓ３０００を説明する図である。 ユーザクオータ管理テーブル３３１の一例である。 ファイルアクセスログ３３５に基づき把握される情報の一例である。 ファイルクオータ管理テーブル３３２の一例である。 ユーザクオータ管理テーブル３３１の一例である。 ユーザクオータ管理テーブル３３１の一例である。 ファイルアクセス時処理Ｓ３６００を説明するフローチャートである。 スタブ化フラグＯＦＦ時処理Ｓ３６６０を説明するフローチャートである。 参照、更新以外処理Ｓ３６７０を説明するフローチャートである。 参照、更新以外処理Ｓ３９００を説明するフローチャートである。 レプリケーション処理Ｓ４０００を説明するフローチャートである。 同期処理Ｓ４１００を説明するフローチャートである。 ファイル格納処理Ｓ４２００を説明するフローチャートである。 ユーザクオータ超過検出処理Ｓ４３００を説明するフローチャートである。 ファイルクオータ管理方式移行処理Ｓ４４００を説明するフローチャートである。 ファイルクオータ返却処理Ｓ４５００を説明するフローチャートである。 ファイルクオータ徴収処理Ｓ４６００を説明するフローチャートである。 監視処理Ｓ４７００を説明するフローチャートである。 監視処理Ｓ４８００を説明するフローチャートである。
以下、図面を参照しつつ実施形態について説明する。
図１に実施形態として説明する情報処理システム１の概略的な構成を示している。同図に示すように、この情報処理システム１は、第１サーバ装置３ａ、第１ストレージ装置１０ａ、クライアント装置２（サーバ装置）、第２サーバ装置３ｂ、及び第２ストレージ装置１０ｂを含む。
このうち第１サーバ装置３ａは、例えば、クライアント装置２に対してファイル単位でのデータ管理機能を提供するファイルシステムを備えたファイルストレージ装置である。また第２サーバ装置３ｂは、例えば、第１サーバ装置３ａが第１ストレージ装置１０ａに管理するデータのアーカイブ（書庫）先として機能するアーカイブ装置である。
第１サーバ装置３ａ、第１ストレージ装置１０ａ、及びクライアント装置２は、例えば、企業における支点や事業所などのユーザが実際に業務を行う拠点（エッジ（Edge））に設けられる。また第２サーバ装置３ｂ及び第２ストレージ装置１０ｂは、例えば、データセンタなどの、企業等において使用される情報処理システム（アプリケーションサーバ／ストレージシステム等）の管理やクラウドサービスの提供などを行う拠点（コア（Core））に設けられる。
同図に示すように、クライアント装置２と第１サーバ装置３ａとは、通信ネットワーク５を介して通信可能に接続されている。また第１サーバ装置３ａと第１ストレージ装置１０ａとは、第１ストレージネットワーク６ａを介して通信可能に接続している。また第２サーバ装置３ｂと第２ストレージ装置１０ｂとは、第２ストレージネットワーク６ｂを介して通信可能に接続している。また第１サーバ装置３ａと第２サーバ装置３ｂとは、通信ネットワーク７を介して通信可能に接続している。
通信ネットワーク５並びに通信ネットワーク７は、例えば、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット、公衆通信網、専用線等である。また第１ストレージネットワーク６ａ並びに第２ストレージネットワーク６ｂは、例えば、ＬＡＮ、ＷＡＮ、ＳＡＮ（Storage Area Network）、インターネット、公衆通信網、専用線等である。
通信ネットワーク５、通信ネットワーク７、第１ストレージネットワーク６ａ、及び第２ストレージネットワーク６ｂを介して行われる通信は、例えば、ＴＣＰ／ＩＰ、ｉＳＣＳＩ（internet Small Computer System Interface）、ファイバーチャネルプロトコル（Fibre Channel Protocol）、ＦＩＣＯＮ（Fibre Connection）（登録商標）、ＥＳＣＯＮ（Enterprise System Connection） （登録商標）、ＡＣＯＮＡＲＣ（Advanced Connection Architecture）（登録商標）、ＦＩＢＡＲＣ（Fibre Connection Architecture）（登録商標）などの所定のプロトコルに従って行われる。
クライアント装置２は、第１サーバ装置３ａを介して第１ストレージ装置１０ａが提供する記憶領域を利用する情報処理装置（コンピュータ）であって、例えば、パーソナルコンピュータ、オフィスコンピュータ等である。クライアント装置２では、ファイルシステム、カーネル／ドライバ等のソフトウエアモジュールを実行することにより実現されるオペレーティングシステム（Operating System）、及びアプリケーション等が機能している。
図２にクライアント装置２のハードウエアの一例を示している。同図に示すように、この装置は、ＣＰＵ２１、揮発性または不揮発性のメモリ２２（ＲＡＭまたはＲＯＭ）、記憶装置２３（例えばハードディスクドライブ、半導体記憶装置（ＳＳＤ（Solid State Drive）））、キーボードやマウス等の入力装置２４、液晶モニタやプリンタ等の出力装置２５、及びＮＩＣ（Network Interface Card）（以下、ＬＡＮアダプタ２６１と称する。）等の通信インタフェース（通信Ｉ／Ｆ２６と称する。）を備えている。
第１サーバ装置３ａは、第１ストレージ装置１０ａが提供する記憶領域（データの記憶領域）を利用する情報処理装置である。第１サーバ装置３ａは、パーソナルコンピュータ、メインフレーム（Mainframe）、オフィスコンピュータ等を用いて構成されている。第１サーバ装置３ａは、上記記憶領域へのアクセスに際し、第１ストレージネットワーク６ａを介して、データＩ／Ｏ要求（データ書き込み要求、データ読み出し要求等）を含んだデータフレーム（以下、フレームと略記する。）を第１ストレージ装置１０ａに送信する。フレームは、例えばファイバーチャネルのフレーム（ＦＣフレーム（FC: Fibre Channel））である。
第２サーバ装置３ｂは、第２ストレージ装置１０ｂが提供する記憶領域（データの記憶領域）を利用する情報処理装置である。第２サーバ装置３ｂは、パーソナルコンピュータ、メインフレーム、オフィスコンピュータ等を用いて構成されている。第２サーバ装置３ｂは、上記記憶領域へのアクセスに際し、第２ストレージネットワーク６ｂを介して、データＩ／Ｏ要求を含んだフレームを第２ストレージ装置１０ｂに送信する。
図３は、第１サーバ装置３ａ又は第２サーバ装置３ｂとして利用可能な情報処理装置のハードウエアの一例である。同図に示すように、この装置は、ＣＰＵ３１、揮発性または不揮発性のメモリ３２（ＲＡＭまたはＲＯＭ）、記憶装置３３（例えばハードディスクドライブ、半導体記憶装置（ＳＳＤ））、キーボードやマウス等の入力装置３４、液晶モニタやプリンタ等の出力装置３５、ＮＩＣ（以下、ＬＡＮアダプタ３６１と称する。）やＨＢＡ（以下、ＦＣアダプタ３６２と称する。）等の通信インタフェース（通信Ｉ／Ｆ３６と表記する。）、及びタイマ回路やＲＴＣ等を用いて構成される計時装置３７を備えている。
図４は、第１ストレージ装置１０ａ又は第２ストレージ装置１０ｂのハードウエアの一例である。第１ストレージ装置１０ａ又は第２ストレージ装置１０ｂは、例えば、ディスクアレイ装置である。同図に示すように、このストレージ装置１０は、サーバ装置３（第１サーバ装置３ａ又は第２サーバ装置３ｂ。以下同様）から送られてくるデータＩ／Ｏ要求に応じて記録媒体にアクセスし、サーバ装置３にデータやレスポンスを送信する。
同図に示すように、ストレージ装置１０は、一つ以上のチャネル基板１１、一つ以上のプロセッサ基板１２（Micro Processor）、一つ以上のドライブ基板１３、キャッシュメモリ１４（Cache Memory）、共有メモリ１５（Shared Memory）、内部スイッチ１６、記憶装置１７、及び保守装置１８（SVP: SerVice Processor）を備えている。尚、チャネル基板１１、プロセッサ基板１２、ドライブ基板１３、キャッシュメモリ１４、及び共有メモリ１５は、内部スイッチ１６を介して互いに通信可能に接続されている。
チャネル基板１１は、サーバ装置３から送られてくるフレームを受信し、受信したフレームに含まれているデータＩ／Ｏ要求についての処理の応答（例えば読み出したデータ、読み出し完了報告、書き込み完了報告）を含んだフレームをサーバ装置３に送信する。
プロセッサ基板１２は、チャネル基板１１が受信したフレームに含まれている上記データＩ／Ｏ要求に応じて、チャネル基板１１、ドライブ基板１３、及びキャッシュメモリ１４の間で行われるデータ転送（ＤＭＡ（Direct Memory Access）等を用いた高速大容量のデータ転送)に関する処理を行う。プロセッサ基板１２は、キャッシュメモリ１４を介して行われる、チャネル基板１１とドライブ基板１３との間のデータ（記憶装置１７から読み出したデータ、記憶装置１７に書き込むデータ）の転送（引き渡し）や、キャッシュメモリ１４に格納されるデータのステージング（記憶装置１７からのデータの読み出し）及びデステージング（記憶装置１７への書き出し）等を行う。
キャッシュメモリ１４は、高速アクセスが可能なＲＡＭ（Random Access Memory）を用いて構成されている。キャッシュメモリ１４には、記憶装置１７に書き込まれるデータ（以下、書き込みデータと称する。）や記憶装置１７から読み出されたデータ（以下、読み出しデータと記載する。）等が格納される。共有メモリ１５には、ストレージ装置１０の制御に用いられる様々な情報が格納される。
ドライブ基板１３は、記憶装置１７からのデータの読み出しや記憶装置１７へのデータの書き込みに際して記憶装置１７と通信を行う。内部スイッチ１６は、例えば高速クロスバースイッチ（Cross Bar Switch）を用いて構成される。尚、内部スイッチ１６を介して行われる通信は、例えば、ファイバーチャネル、ｉＳＣＳＩ、ＴＣＰ／ＩＰ等のプロトコルに従って行われる。
記憶装置１７は、複数の記憶ドライブ１７１を備えて構成されている。記憶ドライブ１７１は、例えば、ＳＡＳ（Serial Attached SCSI）、ＳＡＴＡ（Serial ATA）、ＦＣ（Fibre Channel）、ＰＡＴＡ（Parallel ATA）、ＳＣＳＩ等のタイプのハードディスクドライブ、半導体記憶装置（ＳＳＤ）等である。
記憶装置１７は、記憶ドライブ１７１を、例えば、ＲＡＩＤ（Redundant Arrays of Inexpensive （or Independent) Disks）等の方式で制御することによって提供される論理的な記憶領域を単位としてサーバ装置３に記憶装置１７の記憶領域を提供する。この論理的な記憶領域は、例えばＲＡＩＤグループ（パリティグループ（Parity Group））を用いて構成される論理装置（ＬＤＥＶ１７２（LDEV: Logical Device））である。
またストレージ装置１０は、サーバ装置３に対してＬＤＥＶ１７２を用いて構成される論理的な記憶領域（以下、ＬＵ（Logical Unit、Logical Volume、論理ボリューム）と称する。）を提供する。ストレージ装置１０は、ＬＵとＬＤＥＶ１７２との対応（関係）を管理しており、ストレージ装置１０は、この対応に基づきＬＵに対応するＬＤＥＶ１７２の特定、もしくは、ＬＤＥＶ１７２に対応するＬＵの特定を行う。
図５にチャネル基板１１のハードウエア構成を示している。同図に示すように、チャネル基板１１は、サーバ装置３と通信するためのポート（通信ポート）を有する外部通信インタフェース（以下、外部通信Ｉ／Ｆ１１１と表記する。）、プロセッサ１１２（フレーム処理チップ及びフレーム転送チップを含む）、メモリ１１３、プロセッサ基板１２と通信するためのポート（通信ポート）を有する内部通信インタフェース（以下、内部通信Ｉ／Ｆ１１４と表記する。）を備えている。
外部Ｉ／Ｆ１１１は、ＮＩＣ（Network Interface Card）やＨＢＡ（Host Bus Adaptor）等を用いて構成されている。プロセッサ１１２は、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等を用いて構成されている。メモリ１１３は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）である。メモリ１１３にはマイクロプログラムが格納されている。プロセッサ１１２が、メモリ１１３から上記マイクロプログラムを読み出して実行することにより、チャネル基板１１が提供する各種の機能が実現される。内部通信Ｉ／Ｆ１１４は、内部スイッチ１６を介してプロセッサ基板１２、ドライブ基板１３、キャッシュメモリ１４、共有メモリ１５と通信する。
図６にプロセッサ基板１２のハードウエア構成を示している。プロセッサ基板１２は、内部通信インタフェース（以下、内部通信Ｉ／Ｆ１２１と表記する。）、プロセッサ１２２、及び共有メモリ１５に比べてプロセッサ１２２からのアクセス性能が高い（高速アクセスが可能な）メモリ１２３（ローカルメモリ）を備えている。メモリ１２３にはマイクロプログラムが格納されている。プロセッサ１２２が、メモリ１２３から上記マイクロプログラムを読み出して実行することにより、プロセッサ基板１２が提供する各種の機能が実現される。
内部通信Ｉ／Ｆ１２１は、内部スイッチ１６を介してチャネル基板１１、ドライブ基板１３、キャッシュメモリ１４、及び共有メモリ１５と通信を行う。プロセッサ１２２は、ＣＰＵ、ＭＰＵ、ＤＭＡ（Direct Memory Access）等を用いて構成されている。メモリ１２３は、ＲＡＭ又はＲＯＭである。プロセッサ１２２は、メモリ１２３及び共有メモリ１５のいずれにもアクセスすることができる。
図７にドライブ基板１３のハードウエア構成を示している。ドライブ基板１３は、内部通信インタフェース（以下、内部通信Ｉ／Ｆ１３１と表記する。）、プロセッサ１３２、メモリ１３３、及びドライブインタフェース（以下、ドライブＩ／Ｆ１３４と表記する。）を備えている。メモリ１３３にはマイクロプログラムが格納されている。プロセッサ１３２が、メモリ１３３から上記マイクロプログラムを読み出して実行することにより、ドライブ基板１３が提供する各種の機能が実現される。内部通信Ｉ／Ｆ１３１は、内部スイッチ１６を介して、チャネル基板１１、プロセッサ基板１２、キャッシュメモリ１４、及び共有メモリ１５と通信する。プロセッサ１３２は、ＣＰＵ、ＭＰＵ等を用いて構成されている。メモリ１３３は、例えば、ＲＡＭ、ＲＯＭである。ドライブＩ／Ｆ１３４は、記憶装置１７との間で通信を行う。
図４に示した保守装置１８は、ストレージ装置１０の各構成要素の制御や状態監視を行う。保守装置１８は、パーソナルコンピュータやオフィスコンピュータ等である。保守装置１８は、内部スイッチ１６又はＬＡＮ等の通信手段を介してチャネル基板１１、プロセッサ基板１２、ドライブ基板１３、キャッシュメモリ１４、共有メモリ１５、及び内部スイッチ１６等のストレージ装置１０の構成要素と随時通信を行い、各構成要素から稼働情報等を取得して管理装置１９に提供する。また保守装置１８は管理装置１９から送られてくる制御情報や稼働情報に基づき、各構成要素の設定や制御、保守（ソフトウエアの導入や更新を含む）を行う。
管理装置１９は、保守装置１８とＬＡＮ等を介して通信可能に接続されるコンピュータである。管理装置１９はストレージ装置１０の制御や監視のためのＧＵＩ（Graphical User Interface）やＣＬＩ（Command Line Interface）等を用いたユーザインタフェースを備える。
図８にストレージ装置１０の基本的な機能を示している。同図に示すように、ストレージ装置１０は、基本的な機能としてＩ／Ｏ処理部８１１を備えている。Ｉ／Ｏ処理部８１１は、記憶装置１７への書き込みに関する処理を行うデータ書き込み処理部８１１１、記憶装置１７からのデータの読み出しに関する処理を行うデータ読み出し処理部８１１２を備えている。尚、Ｉ／Ｏ処理部８１１の機能は、ストレージ装置１０のチャネル基板１１やプロセッサ基板１２、ドライブ基板１３が備えるハードウエアにより、又はプロセッサ１１２，１２２，１３２が、メモリ１１３，１２３，１３３に格納されているマイクロプログラムを読み出して実行することにより実現される。
図９は、ストレージ装置１０（第１ストレージ装置１０ａ又は第２ストレージ装置１０ｂ。以下同様。）が、サーバ装置３（第１サーバ装置３ａ又は第２サーバ装置３ｂ）からデータ書き込み要求を含んだフレームを受信した場合に、Ｉ／Ｏ処理部８１１のデータ書き込み処理部８１１１によって行われる基本的な処理（以下、書き込み処理Ｓ９００と称する。）を説明するフローチャートである。以下、同図とともに書き込み処理Ｓ９００について説明する。尚、以下の説明において、符号の前に付している「Ｓ」の文字はステップを意味する。
同図に示すように、まずサーバ装置３から送信されてくるデータ書き込み要求のフレームが、ストレージ装置１０のチャネル基板１１によって受信される（Ｓ９１１，Ｓ９１２）。
チャネル基板１１は、サーバ装置３からデータ書き込み要求を含んだフレームを受信すると、その旨をプロセッサ基板１２に通知する（Ｓ９１３）。
プロセッサ基板１２は、チャネル基板１１から上記通知を受信すると（Ｓ９２１）、当該フレームのデータ書き込み要求に基づくドライブ書き込み要求を生成し、書き込みデータをキャッシュメモリ１４に格納し、チャネル基板１１に上記通知の受信通知を応答する（Ｓ９２２）。またプロセッサ基板１２は、生成したドライブ書き込み要求をドライブ基板１３に送信する（Ｓ９２３）。
一方、チャネル基板１１は、プロセッサ基板１２からの上記応答を受信すると、サーバ装置３に完了報告を送信し（Ｓ９１４）、サーバ装置３は、チャネル基板１１から完了報告を受信する（Ｓ９１５）。
ドライブ基板１３は、プロセッサ基板１２からドライブ書き込み要求を受信すると、受信したドライブ書き込み要求を書き込み処理待ちキューに登録する（Ｓ９２４）。
ドライブ基板１３は、書き込み処理待ちキューからドライブ書き込み要求を随時読み出し（Ｓ９２５）、読み出したドライブ書き込み要求に指定されている書き込みデータをキャッシュメモリ１４から読み出して、読み出した書き込みデータを物理ドライブ１７１に書き込む（Ｓ９２６）。そしてドライブ基板１３は、ドライブ書き込み要求について書き込みデータの書き込みが完了した旨の報告（完了報告）をプロセッサ基板１２に通知する（Ｓ９２７）。
プロセッサ基板１２は、ドライブ基板１３から送られてきた完了報告を受信する（Ｓ９２８）。
図１０は、ストレージ装置１０が、サーバ装置３からデータ読み出し要求を含んだフレームを受信した場合に、ストレージ装置１０のＩ／Ｏ処理部８１１の読み出し処理部８１１２によって行われるＩ／Ｏ処理（以下、読み出し処理Ｓ１０００と称する。）を説明するフローチャートである。以下、同図とともに読み出し処理Ｓ１０００について説明する。
同図に示すように、まずサーバ装置３から送信されてくるフレームが、ストレージ装置１０のチャネル基板１１によって受信される（Ｓ１０１１，Ｓ１０１２）。
チャネル基板１１は、サーバ装置３からデータ読み出し要求を含んだフレームを受信すると、その旨をプロセッサ基板１２及びドライブ基板１３に通知する（Ｓ１０１３）。
ドライブ基板１３は、チャネル基板１１から上記通知を受信すると（Ｓ１０１４）、当該フレームに含まれているデータ読み出し要求に指定されているデータ（例えばＬＢＡ（Logical Block Address）によって指定される）を、記憶装置１７（物理ドライブ１７１）から読み出す（Ｓ１０１５）。尚、キャッシュメモリ１４に読み出しデータが存在する場合（キャッシュヒットした場合）には、記憶装置１７からの読み出し処理（Ｓ１０１５）は省略される。
プロセッサ基板１２は、ドライブ基板１３によって読み出されたデータをキャッシュメモリ１４に書き込む（Ｓ１０１６）。そしてプロセッサ基板１２は、キャッシュメモリ１４に書き込んだデータを通信Ｉ／Ｆに随時転送する（Ｓ１０１７）。
チャネル基板１１は、プロセッサ基板１２から随時送られてくる読み出しデータを受信すると、それらをサーバ装置３に順次送信する（Ｓ１０１８）。読み出しデータの送信が完了すると、チャネル基板１１は、サーバ装置３に完了報告を送信する（Ｓ１０１９）。サーバ装置３は、読み出しデータ及び完了報告を受信する（Ｓ１０２０，Ｓ１０２１）。
図１１は、クライアント装置２が備える主な機能を説明する図である。同図に示すように、クライアント装置２は、アプリケーション２１１、ファイルシステム２１２、及びカーネル／ドライバ２１３の各機能を備える。尚、これらの機能は、クライアント装置２のＣＰＵ２１が、メモリ２２や記憶装置２３に格納されているプログラムを読み出して実行することにより実現される。
ファイルシステム２１２は、クライアント装置２に対してファイル単位又はディレクトリ単位での論理ボリューム（ＬＵ）へのＩ／Ｏ機能を実現する。ファイルシステム２１３は、例えば、ＦＡＴ(File Allocation Table）、ＮＴＦＳ、ＨＦＳ（Hierarchical File System）、ｅｘｔ２（second extended file system）、ｅｘｔ３(third extended file system)、ｅｘｔ４(fourth extended file system)、ＵＤＦ（Universal Disk Format）、ＨＰＦＳ（High Performance File system）、ＪＦＳ（Journaled File System）、ＵＦＳ（Unix File System）、ＶＴＯＣ(Volume Table Of Contents)、ＸＦＳ等である。
カーネル／ドライバ２１３は、オペレーティングシステムのソフトウエアを構成しているカーネルモジュールやドライバモジュールを実行することにより実現される。カーネルモジュールには、クライアント装置２において実行されるソフトウエアについて、プロセスの管理、プロセスのスケジューリング、記憶領域の管理、ハードウエアからの割り込み要求のハンドリング等、オペレーティングシステムが備える基本的な機能を実現するためのプログラムが含まれる。ドライバモジュールには、クライアント装置２を構成しているハードウエアやクライアント装置２に接続して用いられる周辺機器とカーネルモジュールとが通信するためのプログラム等が含まれる。
図１２に第１サーバ装置３ａが備える主な機能、及び第１サーバ装置３ａにおいて管理される主な情報（データ）を示している。同図に示すように、第１サーバ装置３ａは、ファイル共有処理部３１１、ファイルシステム３１２、データ操作要求受付部３１３、データ複製／移動処理部３１４、ユーザクオータ管理部３１５、ファイルクオータ管理部３１６、ファイルアクセスログ取得部３１７、及びカーネル／ドライバ３１８の各機能を備える。
尚、データ操作要求受付部３１３、データ複製／移動処理部３１４、ユーザクオータ管理部３１５、ファイルクオータ管理部３１６、ファイルアクセスログ取得部３１７の各機能は、ファイルシステム３１２の機能として実現してもよいし、ファイルシステム３１２とは独立した機能として実現してもよい。
また同図に示すように、第１サーバ装置３ａは、ユーザクオータ管理テーブル３３１、ファイルクオータ管理テーブル３３２、ファイルリスト３３３、メタデータ３３４（第１ストレージ装置１０ａ又は第２ストレージ装置１０ｂに管理されているファイルのメタデータ）、及びファイルアクセスログ３３５などの情報（データ）を管理している。これらの情報は、例えば、第１サーバ装置３ａのメモリ３２や記憶装置３３に記憶されている。またこれらの情報は、第１ストレージ１０ａから第１サーバ装置３ａに随時読み出されて第１サーバ装置３ａのメモリ３２や記憶装置３３に格納される。
ファイル共有処理部３１１は、クライアント装置２に対してファイルの共有環境を提供する。ファイル共有処理部３１１は、例えばＮＦＳ（Network File System）、ＣＩＦＳ（Common Internet File System）、ＡＦＳ（Andrew File System）等のプロトコルに規定される機能を提供する。
ファイルシステム３１２は、クライアント装置２に対して、第１ストレージ装置１０ａによって提供される論理ボリューム（ＬＵ）に管理されるファイルやディレクトリに対するＩ／Ｏ機能を提供する。ファイルシステム３１２は、例えばＦＡＴ(File Allocation Table）、ＮＴＦＳ、ＨＦＳ（Hierarchical File System）、ｅｘｔ２（second extended file system）、ｅｘｔ３(third extended file system)、ｅｘｔ４(fourth extended file system)、ＵＤＦ（Universal Disk Format）、ＨＰＦＳ（High Performance File system）、ＪＦＳ（Journaled File System）、ＵＦＳ（Unix File System）、ＶＴＯＣ(Volume Table Of Contents)、ＸＦＳ等である。
データ操作要求受付部３１３は、クライアント装置２から送信されてくる、第１ストレージ装置１０ａと第２ストレージ装置１０ｂとの間でのデータの操作要求（主に後述する、レプリケーション（Replication）による管理方式やマイグレーション（Migration）による管理方式に関する操作要求。以下、データ操作要求と称する。）を受け付ける。またデータ操作要求受付部３１３は、第１サーバ装置３ａ内で発生したデータ操作要求を受け付ける。
データ複製／移動処理部３１４は、データ操作要求受付部３１３が受け付けたデータ操作要求に応じて、第１ストレージ装置１０ａと第２ストレージ装置１０ｂとの間でのデータの複製や移動を行う。
ユーザクオータ管理部３１５は、個々のユーザや個々のユーザグループに対して設定されるユーザ（又はユーザグループ）ごとの記憶資源（第１サーバ装置３ａのファイルシステム３１２に提供されている第１ストレージ装置１０ａの記憶領域）の使用量の制限を規定した情報（以下、ユーザクオータと称する。）の管理、並びに上記制限に関する処理を
行う。ユーザクオータ管理部３１５は、ユーザクオータに基づき上記記憶資源を管理する。以下、この管理方式のことをユーザクオータ管理方式と称する。尚、ユーザクオータ管理方式の一例として、ＵＮＩＸ（登録商標）ベースのオペレーティングシステムが備えるクオータ（quota）管理方式がある。
ユーザクオータ管理部３１５は、ユーザクオータを、ユーザクオータ管理テーブル３３１に管理する。図１３にユーザクオータ管理テーブル３３１の一例を示している。同図に示すように、ユーザクオータ管理テーブル３３１は、ユーザ名３３１１、ユーザクオータ３３１２、及び使用量３３１３の各項目からなる一つ以上のレコードで構成されている。このうちユーザ名３３１には、ファイルシステム３１２のユーザ（又はユーザグループ）を一意に特定する識別子（ユーザＩＤ又はグループＩＤ）が設定される。ユーザクオータ３３１２には、ユーザクオータが設定される。尚、本実施形態では、ユーザクオータとして、そのユーザ（又はユーザグループ）が使用可能な容量の上限値（ユーザクオータに基づく閾値）が設定されるものとする。但し、ユーザクオータは、安全率を見込む等、情報処理システム１の構成、性質、運用状況、情報処理システム１に対するユーザニーズ、その他の環境や状況に応じて適切に設定することができる。使用量３３１３には、そのユーザの現在の記憶資源の使用量が設定される。
図１２に示すファイルクオータ管理部３１６は、ファイルシステム３１２によって管理されるファイル（又はディレクトリ（フォルダ））ごとに設定される記憶容量の制限を規定した情報（以下、ファイルクオータと称する。）の管理、並びに上記制限に関する処理を行う。ファイルクオータ管理部３１６は、ファイルクオータに基づき、ファイル（又はディレクトリ（フォルダ））を管理する。以下、この管理方式のことをファイルクオータ管理方式と称する。尚、以下の説明において、ユーザクオータ管理方式及びファイルクオータ管理方式のことを総称してクオータ管理方式と称する。
ファイルクオータ管理部３１６は、ファイルクオータを、ファイルクオータ管理テーブル３３２に管理する。図１４にファイルクオータ管理テーブル３３２の一例を示している。同図に示すように、ファイルクオータ管理テーブル３３２は、ファイル名３３２１、ファイルクオータ３３２２、ユーザ数３３２３、ユーザＩＤ／提供クオータ３３２４〜３３２６、及び使用量３３２７の各項目からなるレコードで構成されている。
ファイル名３３２１には、ファイルシステム３１２によって管理されるファイルの識別子であるパス名（ファイルパス名、ディレクトリパス名）が設定される。
ファイルクオータ３３２２には、ファイルクオータが設定される。尚、本実施形態では、ファイルクオータとして、そのファイルについて使用可能な容量の上限値（ファイルクオータに基づく閾値）が設定されるものとする。但し、ファイルクオータは、安全率を見込む等、情報処理システム１の構成、性質、運用状況、情報処理システム１に対するユーザニーズ、その他の環境や状況に応じて適切に設定することができる。
ユーザ数３３２３には、そのファイル（又はディレクトリ）を現在使用しているユーザの数が設定される。尚、このユーザ数は、例えば、ファイルアクセスログ３３５から取得される。
ユーザＩＤ／提供クオータ３３２４〜３３２６には、ファイルクオータ３３２２に設定されているファイルクオータを負担している（供出）しているユーザのユーザＩＤ及びそのユーザが負担している記憶資源の容量（クオータ）を示す情報が設定される。尚、同図では、ユーザＩＤ／提供クオータ３３２４〜３３２６として３つの項目が設けられているが、この項目の数はファイルを使用するユーザ数に応じて変化する。
使用量３３２７には、そのファイルの現在の容量(ファイルサイズ（データサイズ））（スラッシュ記号「／」の左側の値）と、クオータ管理方式の変更時（後述）における、そのファイルの容量（スラッシュ記号「／」の右側の値）が設定される。
図１２に示すファイルアクセスログ取得部３１７は、ストレージ装置１０の論理ボリューム（ＬＵ）に格納されているファイルへのアクセス（ファイルの更新（Write, Update）、ファイルの読み出し（Read）、ファイルのオープン（Open）、ファイルのクローズ（Close）等）が行われると、そのアクセスの内容（履歴）を示す情報（以下、アクセスログと称する。）を、計時装置３７から取得される日時情報に基づくタイムスタンプを付与してファイルアクセスログ３３５として記憶する。
図１５にファイルアクセスログ３３５の一例を示している。同図に示すように、ファイルアクセスログ３３５には、アクセス日時３３５１、ファイル名３３５２、及びユーザＩＤ３３５３の各項目からなる一つ以上のレコードで構成されるアクセスログが記録される。このうちアクセス日時３３５１には、そのファイルに対するアクセスがされた日時が設定される。ファイル名３３５２には、アクセス対象となったファイルのファイル名が設定される。ユーザＩＤ３３５３には、そのファイルにアクセスしたユーザのユーザＩＤが設定される。
図１２に示すカーネル／ドライバ３１８は、オペレーティングシステムのソフトウエアを構成しているカーネルモジュールやドライバモジュールを実行することにより実現される。カーネルモジュールには、第１サーバ装置３ａにおいて実行されるソフトウエアについて、プロセスの管理、プロセスのスケジューリング、記憶領域の管理、ハードウエアからの割り込み要求のハンドリング等、オペレーティングシステムが備える基本的な機能を実現するためのプログラムが含まれる。ドライバモジュールには、第１サーバ装置３ａを構成しているハードウエアや第１サーバ装置３ａに接続して用いられる周辺機器とカーネルモジュールとが通信するためのプログラムが含まれる。
図１６に第２サーバ装置３ｂが備える主な機能、及び第２サーバ装置３ｂにおいて管理される主な情報（データ）を示している。同図に示すように、第２サーバ装置３ｂは、ファイル共有処理部３５１、ファイルシステム３５２、データ複製／移動処理部３５４、及びカーネル／ドライバ３５８の各機能を備える。尚、データ複製／移動処理部３５４の機能は、ファイルシステム３５２の機能として実現してもよいし、ファイルシステム３５２とは独立した機能として実現してもよい。
また同図に示すように、第２サーバ装置３ｂは、メタデータ３６４（第１ストレージ装置１０ａ又は第２ストレージ装置１０ｂに格納されているファイルのメタデータ）を管理している。
ファイル共有処理部３５１は、第１サーバ装置３ａに対してファイルの共有環境を提供する。ファイル共有処理部３５１は、例えばＮＦＳ、ＣＩＦＳ、ＡＦＳ等のプロトコルを用いて実現される。
ファイルシステム３５２は、第２ストレージ装置１０ｂによって提供される論理ボリューム（ＬＵ）を用い、第１サーバ装置３ａに対してファイル単位又はディレクトリ単位での論理ボリューム（ＬＵ）へのＩ／Ｏ機能を提供する。ファイルシステム３５２は、例えばＦＡＴ、ＮＴＦＳ、ＨＦＳ、ｅｘｔ２、ｅｘｔ３、ｅｘｔ４、ＵＤＦ、ＨＰＦＳ、ＪＦＳ、ＵＦＳ、ＶＴＯＣ、ＸＦＳなどである。
データ複製／移動処理部３５４は、受け付けたデータ操作要求に応じて、第１ストレージ装置１０ａと第２ストレージ装置１０ｂとの間でのデータの移動や複製に関する処理を行う。
カーネル／ドライバ３５８は、オペレーティングシステムのソフトウエアを構成しているカーネルモジュールやドライバモジュールを実行することにより実現される。カーネルモジュールには、第２サーバ装置３ｂにおいて実行されるソフトウエアについて、プロセスの管理、プロセスのスケジューリング、記憶領域の管理、ハードウエアからの割り込み要求のハンドリング等、オペレーティングシステムが備える基本的な機能を実現するためのプログラムが含まれる。ドライバモジュールには、第２サーバ装置３ｂを構成しているハードウエアや第２サーバ装置３ｂに接続して用いられる周辺機器とカーネルモジュールとが通信するためのプログラムが含まれる。
次に第１サーバ３ａが備えるファイルシステム３１２（第２サーバ３ｂが備えるファイルシステム３５２も同様である。）について詳細に説明する。
図１７は、ファイルシステム３１２が論理ボリューム（ＬＵ）上に管理するデータの構造（以下、ファイルシステム構造１７００と称する。）の一例である。同図に示すように、ファイルシステム構造１７００には、スーパーブロック１７１１、ｉｎｏｄｅ管理テーブル１７１２、ファイルの実体（データ）が格納されるデータブロック１７１３の各記憶領域が含まれている。
このうちスーパーブロック１７１１には、ファイルシステムに関する情報（ファイルシステムが取り扱う記憶領域の容量、使用量、空き容量等）が格納される。スーパーブロック１７１１は、原則としてディスク区画（論理ボリューム（ＬＵ）上に設定されるパーティション）ごとに設けられる。スーパーブロック１７１１に格納される上記情報の具体例として、区画内のデータブロック数、ブロックサイズ、空きブロック数、空きｉｎｏｄｅ数、当該区画のマウント数、最新の整合性チェック時からの経過時間等がある。
ｉｎｏｄｅ管理テーブル１７１２には、論理ボリューム（ＬＵ）に格納されるファイルの管理情報（以下、ｉｎｏｄｅと称する。）が格納される。ファイルシステム３１２は、１つのファイル（又はディレクトリ）に対して１つのｉｎｏｄｅを対応させて管理している。ｉｎｏｄｅのうちディレクトリに関する情報のみを含むものはディレクトリエントリと称される。ファイルに対するアクセスが行われる場合にはディレクトリエントリを参照してアクセス対象のファイルのデータブロックにアクセスする。例えば、「/home/user-01/a.txt」というファイルにアクセスする場合には、図１８に示すように、ｉｎｏｄｅ番号２→１０→１５→１００とディレクトリエントリを順に辿ってアクセス対象ファイルのデータブロックにアクセスする。
図１９に一般的なファイルシステム（例えば、ＵＮＩＸ（登録商標）系のオペレーティングシステムが備えるファイルシステム）におけるｉｎｏｄｅの概念を示している。また図２０に、ｉｎｏｄｅ管理テーブル１７１２の例を示している。これらの図に示すように、ｉｎｏｄｅには、個々のｉｎｏｄｅを区別する識別子であるｉｎｏｄｅ番号２０１１、当該ファイル（又はディレクトリ）の所有者２０１２、当該ファイル（又はディレクトリ）について設定されているアクセス権２０１３、当該ファイル（又はディレクトリ）のファイルサイズ２０１４、当該ファイル（又はディレクトリ）の最終更新日時２０１５、当該ｉｎｏｄｅがディレクトリエントリである場合に設定される当該ディレクトリの親ディレクトリ２０１６、当該ｉｎｏｄｅがディレクトリエントリである場合に設定される当該ディレクトリの子ディレクトリ２０１７、当該ファイルのデータの実体が格納されるデータブロックを特定する情報（以下、ブロックアドレス２０１８と称する。）などの情報が含まれる。
図２１に示すように、本実施形態のファイルシステム３１２は、ｉｎｏｄｅ管理テーブル１７１２に、上記一般的なファイルシステムにおけるｉｎｏｄｅ管理テーブル１７１２の内容に加えて更にスタブ化フラグ２１１１、メタデータ同期要フラグ２１１２、データ実体同期要フラグ２１１３、レプリケーションフラグ２１１４、及びリンク先２１１５を管理している。
同図において、スタブ化フラグ２１１１には、当該ｉｎｏｄｅに対応するファイルがスタブ化されているか否かを示す情報が設定される。ここでスタブ化とは、第１ストレージ装置１０ａから第２ストレージ装置１０ｂにファイルを移動（マイグレーション）するに際し、移動元の第１ストレージ装置１０ａからそのファイルのデータのうち実体のみ削除し、そのファイルのデータのうちメタデータについては削除せずに移動元の第１ストレージ装置１０ａに残すことをいう。尚、スタブ（stub）とは、その場合に第１ストレージ装置１０ａに残留するメタデータのことをいう。当該ｉｎｏｄｅに対応するファイルがスタブ化されていればスタブ化フラグ２１１１にＯＮが設定され、スタブ化されていない場合はスタブ化フラグ２１１１にＯＦＦが設定される。
メタデータ同期要フラグ２１１２には、複製元の第１ストレージ装置１０ａのファイルのメタデータと複製先の第２ストレージ装置１０ｂのファイルのメタデータとの間で同期をとる必要（内容を一致させる必要）が有るか否かを示す情報が設定される。メタデータの同期が必要な状態ではメタデータ同期要フラグ２１１２にＯＮが設定され、同期が不要な状態ではメタデータ同期要フラグ２１１２にＯＦＦが設定される。
データ実体同期要フラグ２１１３には、複製元の第１ストレージ装置１０ａのファイルのデータの実体と複製先の第２ストレージ装置１０ｂのファイルのデータの実体との間で同期をとる必要（内容を一致させる必要）が有るか否かを示す情報が設定される。ファイルのデータの実体について同期が必要な状況ではデータ実体同期要フラグ２１１３にＯＮが設定され、同期が不要な状況ではデータ実体同期要フラグ２１１３にＯＦＦが設定される。
レプリケーションフラグ２１１４には、そのｉｎｏｄｅに対応するファイルが、現在、後述するレプリケーション管理方式による管理の対象になっているか否かを示す情報が設定される。当該ｉｎｏｄｅに対応するファイルが、現在、レプリケーション管理方式による管理の対象になっている場合はレプリケーションフラグ２１１４にＯＮが設定され、レプリケーションによる管理の対象になっていない場合はレプリケーションフラグ２１１４にＯＦＦが設定される。
リンク先２１１５には、そのｉｎｏｄｅに対応するファイルが、後述するレプリケーション管理方式で管理されている場合は、そのファイルの複製先を示す情報（例えば、格納先を特定するパス名、ＵＲＬ（Uniform Resource Locator）、ＬＵ等）が設定される。またそのｉｎｏｄｅに対応するファイルが、後述するマイグレーションによる管理方式で管理されている場合は、リンク先２１１５にそのファイルの移動先を示す情報（例えば、パス名、ＵＲＬ、ＬＵ等）が設定される。
＜機能説明＞
以下、以上の構成からなる情報処理システム１にて行われる機能について説明する。
図２２は、第１サーバ装置３ａのデータ操作要求受付部３１３が、第１ストレージ装置１０ａに格納されているファイルについてのレプリケーションによる管理方式を開始する旨の要求（以下、レプリケーション開始要求と称する。）を受け付けた場合に、情報処理システム１にて行われる処理（以下、レプリケーション開始処理Ｓ２２００と称する）の概要を説明する図である。
ここでレプリケーションによる管理方式とは、ファイル（メタデータ及び実体）を、第１ストレージ装置１０ａ及び第２ストレージ装置１０ｂの双方において管理する方式である。レプリケーションによる管理方式では、第１ストレージ装置１０ａのファイルの実体又はメタデータが更新されると、第２ストレージ装置１０ｂ側のファイルのメタデータ又は実体が同期又は非同期に更新される。
第１サーバ装置３ａのデータ操作要求受付部３１３は、例えば、通信ネットワーク５を介してクライアント装置２から上記レプリケーション実施要求を受け付ける。またデータ操作要求受付部３１３は、例えば、第１サーバ装置３ａの内部（ファイル共有処理部３１１、ファイルシステム３１２、カーネル／ドライバ３１８等）で発生した上記レプリケーション実施要求を受け付ける。
同図に示すように、第１サーバ装置３ａのデータ操作要求受付部３１３が上記レプリケーション実施要求を受け付けると（Ｓ２２１１）、第１サーバ装置３ａのデータ複製移動処理部３１４は、受け付けたレプリケーション実施要求に指定されているファイルのデータ（メタデータ及び実体）を第１ストレージ装置１０ａから読み出し、読み出したファイルのデータを第２サーバ装置１０ｂに転送する（Ｓ２２１２）。
第２サーバ３ｂのデータ複製移動処理部３５４は、第１サーバ装置３ａから送られてくる上記ファイルのデータを受信すると、受信したデータを第２ストレージ装置１０ｂに格納する（Ｓ２２１３）。また上記転送に際し、第１サーバ装置３ａのデータ複製移動処理部３１４は、転送元ファイルのレプリケーションフラグ２１１４をＯＮに設定する（Ｓ２２１４）。
図２３は、第１ストレージ装置１０ａに格納されている、レプリケーション管理方式により管理されている第２ストレージ装置１０ｂに複製済のファイル（レプリケーションフラグ２１１４がＯＮに設定されているファイル。以下、レプリケーションファイルと称する。）をマイグレーションによる管理方式の候補に設定する処理（以下、マイグレーション候補設定処理Ｓ２３００と称する。）を説明する図である。
ここでマイグレーションによる管理方式とは、第１ストレージ装置１０ａにおいてはファイルのデータのうちメタデータは管理（記憶）するが、ファイルの実体については管理（記憶）せず、実体については第２ストレージ装置１０ｂにおいて管理するという管理方式である。第１サーバ装置３ａは、レプリケーションファイルが、所定の条件を満たした場合、そのファイルをマイグレーションによる管理方式による管理の対象に設定する（マイグレーション管理方式の対象とされても、そのファイルについて直ちにマイグレーションによる管理方式が実施されるわけではない。）。
図２３に示すように、第１サーバ装置３ａのデータ複製／移動処理部３１４は、ユーザクオータ管理テーブル３３１の各ユーザの使用量３３１３を随時（定期的、リアルタイム等）監視している（Ｓ２３１１）。この監視において、データ複製／移動処理部３１４は、使用量３３１３がユーザクオータ３３１２を超過しているユーザの存在を検知すると、そのユーザが所有しているファイルのうち、レプリケーションファイルの一部又は全部をマイグレーションによる管理方式の候補として設定する（Ｓ２３１２）。ここでこの設定は、具体的には、設定対象のレプリケーションファイルのスタブ化フラグ２１１１をＯＮに設定し、かつ、レプリケーションファイルのレプリケーションフラグをＯＦＦに設定することにより行われる（Ｓ２３１２）。
図２４は、第１ストレージ装置１０ａに格納されているレプリケーションファイルのうち、複数のユーザによって共用されているファイルのクオータ管理方式を変更する処理（以下、クオータ管理方式変更処理Ｓ２４００と称する。）を説明する図である。
第１サーバ装置３ａのデータ複製／移動処理部３１４は、ユーザクオータ管理テーブル３３１を随時（定期的、リアルタイム等）監視している（Ｓ２４１１）。データ複製／移動処理部３１４は、ユーザクオータ管理テーブル３３１の使用量３３１３が、ユーザクオータ３３１２を超過しているユーザが存在し、かつ、そのユーザが所有するレプリケーションファイルが複数のユーザによって使用（共用）されているという条件を満たす場合、そのレプリケーションファイルについてファイルクオータ管理方式による管理を開始する（Ｓ２４１２）。尚、ファイルクオータ管理方式による管理対象になっているレプリケーションファイルは、ユーザクオータ管理方式においてマイグレーション管理方式の対象から外される（図２３のＳ２３１２における候補から除外される）。
またデータ複製／移動処理部３１４は、上記レプリケーションファイルが上記条件を満たさなくなった場合、上記レプリケーションファイルについてのファイルクオータ管理方式による管理を終了する。
ここでファイルが複数のユーザによって使用（共用）されているか否かは、例えば、ファイルアクセスログ３３５の内容（例えば、所定時間前から現在までの間に複数のユーザがアクセスしたか否か）やファイルに設定されているアクセス権（そのファイルに複数ユーザのアクセスを可能とするアクセス権が設定されているか否か）に基づき判断する。尚、ファイルクオータ管理方式による管理対象にならなくなったレプリケーションファイルは、再びユーザクオータ管理方式におけるマイグレーション管理方式の対象となり得る（図２３のＳ２３１２における候補とされる可能性がある。）。
図２５は、第１ストレージ装置１０ａに格納されているレプリケーションファイルの実体を第１ストレージ装置１０ａから削除する際、即ち、マイグレーションを実施（開始）する際、情報処理システム１にて行われる処理（以下、マイグレーション実施処理Ｓ２５００と称する。）を説明する図である。
同図に示すように、第１サーバ装置３ａのファイルシステム３１２（データ複製／移動処理部３１４でもよい）は、レプリケーションファイルが所定の条件を満たしているか否かを随時（定期的、リアルタイム等）判断する。ファイルシステム３１２は、レプリケーションファイルが所定の条件を満たしていることを検知すると、そのレプリケーションファイルの実体を第１ストレージ装置１０ａから削除する（Ｓ２５１１）。尚、複製済ファイルのメタデータについては第１ストレージ装置１０ａにスタブとしてそのまま残される（スタブ化）。
ここで上記所定の条件としては、例えば、そのレプリケーションファイルの使用量がファイルクオータ管理テーブル３３２に管理されているファイルクオータ３３２２の値を超えた場合、クライアント装置２等からの、そのレプリケーションファイルに対するアクセスが終了した場合などがある。尚、後者における、レプリケーションファイルに対するアクセスが終了したことは、例えば、ファイルの参照カウンタ（ファイルがオープン（Open）される度にインクリメントされ、ファイルがクローズ（Close）される度にデクリメントされるカウンタ）の値がゼロになったことをもって判断する。
図２６は、クライアント装置２からレプリケーションファイルに対する更新要求（ファイルのメタデータ又は実体の変更を生じさせる要求）を受け付けた場合に、情報処理システム１にて行われる処理（以下、レプリケーションファイル更新処理Ｓ２６００と称する。）を説明する図である。
第１サーバ装置３ａのファイルシステム３１２は、クライアント装置２からレプリケーションファイルに対する更新要求を受け付けると（Ｓ２６１１）、そのレプリケーションファイルのデータのメタデータ、又はファイルのデータの実体を更新要求に従って更新する（Ｓ２６１２）。ファイルシステム３１２は、メタデータを更新した場合、そのレプリケーションファイルのメタデータ同期要フラグ２１１２をＯＮに設定する。またファイルシステム３１２は、ファイルの実体を更新した場合、そのレプリケーションファイルのデータ実体同期要フラグ２１１３をＯＮに設定する（Ｓ２６１３）。
図２７は、第１サーバ装置３ａのデータ操作要求受付部３１３が、第１ストレージ装置１０ａに格納されているレプリケーションファイルとその第２ストレージ装置１０ｂ側のファイル（以下、アーカイブファイルと称する。）との内容を一致させる旨の要求（以下、同期要求と称する。）を受け付けた際に情報処理システム１にて行われる処理（以下、同期処理Ｓ２７００と称する。）を説明する図である。尚、データ操作要求受付部３１３は、例えば、通信ネットワーク５を介してクライアント装置２から上記同期要求を受け付ける。またデータ操作要求受付部３１３は、例えば、第１サーバ装置３ａの内部（ファイル共有処理部３１１、ファイルシステム３１２、カーネル／ドライバ３１８等）から上記同期要求を受け付ける。
同図に示すように、第１サーバ装置３ａのデータ操作要求受付部３１３が同期要求を受け付けると（Ｓ２７１１）、第１サーバ装置３ａのデータ複製／移動処理部３１４は、第１ストレージ装置１０ａに格納されているレプリケーションファイルのうち、メタデータ同期要フラグ２１１２又はデータ実体同期要フラグ２１１３がＯＮに設定されているファイルを取得する（Ｓ２７１２）。そしてデータ複製／移動処理部３１４は、取得したファイルのデータのメタデータ又はファイルのデータの実体を第２サーバ装置３ｂに転送し、転送したレプリケーションファイルのメタデータ同期要フラグ２１１２又はデータ実体同期要フラグ２１１３をＯＦＦに設定する（Ｓ２７１３）。第２サーバ装置３ｂのデータ複製／移動処理部３５４は、メタデータ又は実体を受信すると（Ｓ２７１４）、第２ストレージ装置１０ｂに格納されている該当のアーカイブファイルのメタデータ又は実体を受信したメタデータ又は実体の内容に更新する（Ｓ２７１５）。
図２８は、第１サーバ装置３ａのファイルシステム３１２が、スタブ化フラグがＯＮに設定されているファイル（以下、マイグレーションファイルと称する。）のメタデータに対するアクセス要求（参照要求又は更新要求）を受け付けた場合に情報処理システム１にて行われる処理（以下、メタデータアクセス処理Ｓ２８００と称する。）を説明する図である。尚、ファイルシステム３１２は、例えば、通信ネットワーク５を介してクライアント装置２から上記アクセス要求を受け付ける。またファイルシステム３１２は、例えば、第１サーバ装置３ａの内部（ファイル共有処理部３１１、ファイルシステム３１２、カーネル／ドライバ３１８等）から上記アクセス要求を受け付ける。
同図に示すように、ファイルシステム３１２は、マイグレーションファイルのメタデータに対するアクセスを受け付けると（Ｓ２８１１）、アクセス要求の対象になっている第１ストレージ装置１０ａのマイグレーションファイルのメタデータを取得し、アクセス要求の内容に従って処理（参照、更新）を行う（Ｓ２８１２）。またメタデータの内容を更新した場合には、そのマイグレーションファイルのメタデータ同期要フラグ２１１２にＯＮを設定する（Ｓ２８１３）。
このように、第１サーバ装置３ａは、第２ストレージ装置１０ｂに管理されているマイグレーションファイルに対するアクセス要求があった場合でも、そのアクセス要求がメタデータを対象とする場合には、第１ストレージ装置１０ａに格納されているメタデータを用いてアクセス要求に対応する。
図２９は、第１サーバ装置３ａのファイルシステム３１２が、クライアント装置２からマイグレーションファイルの実体に対する参照要求を受け付けた場合に、情報処理システム１にて行われる処理（以下、マイグレーションファイル参照処理Ｓ２９００と称する。）を説明する図である。
ファイルシステム３１２は、クライアント装置２からマイグレーションファイルの実体に対する参照要求を受け付けると（Ｓ２９１１）、対象のマイグレーションファイルのメタデータを取得し、取得したメタデータに基づき当該マイグレーションファイルの実体が第１ストレージ装置１０ａに格納されているか否かを判断する（Ｓ２９１２）。
上記判断は、例えば、取得したメタデータに、マイグレーションファイルの実体の格納先を示す情報（例えばブロックアドレス）が有効な状態で設定されているか否かを調べることにより行う。例えば、先行して他の更新要求が行われている状況では、そのマイグレーションファイルの実体が既に第１ストレージ装置１０ａに格納されている状態となる。
上記判断の結果、マイグレーションファイルの実体が第１ストレージ装置１０ａに格納されている場合には、ファイルシステム３１２は、第１ストレージ装置１０ａから当該マイグレーションファイルの実体を読み出し、読み出した内容をクライアント装置２に応答する（Ｓ２９１３）。
一方、上記判断の結果、マイグレーションファイルの実体が第１ストレージ装置１０ａに格納されていない場合には、ファイルシステム３１２は、第２サーバ装置３ｂに対し、当該マイグレーションファイルに対応するアーカイブファイルの取得要求（リコール）を送信する（Ｓ２９１４）。そしてファイルシステム３１２は、上記取得要求に応じて第２サーバ装置３ｂから送られてくるアーカイブファイルを受信すると（Ｓ２９１５）、受信したアーカイブファイルの内容をクライアント装置２に応答する（Ｓ２９１６）。
尚、第２サーバ装置３ｂからのアーカイブファイルの取得要求は、必ずしも一度の取得要求でアーカイブファイルの全体を取得しなくてもよい。例えば、上記取得要求は、アーカイブファイルの一部を要求するものであってもよい。またその場合、アーカイブファイルの一部の実体ごとに上記判断（第１ストレージ装置１０ａに実体が格納されているか否かの判断）を行うようにしてもよい。
図３０は、第１サーバ装置３ａのファイルシステム３１２が、クライアント装置２からマイグレーションファイルの実体に対する更新要求を受け付けた場合に、情報処理システム１にて行われる処理（以下、マイグレーションファイル更新処理Ｓ３０００と称する。）を説明する図である。
ファイルシステム３１２は、マイグレーションファイルの実体に対する更新要求を受け付けると（Ｓ３０１１）、更新要求の対象になっているマイグレーションファイルのメタデータを取得し、取得したメタデータに基づき当該マイグレーションファイルの実体が第１ストレージ装置１０ａに格納されているか否かを判断する（Ｓ３０１２）。尚、この判断方法についてはマイグレーションファイル参照処理Ｓ２９００の場合と同様である。
上記判断の結果、マイグレーションファイルの実体が第１ストレージ装置１０ａに格納されている場合には、ファイルシステム３１２は、第１ストレージ装置１０ａに格納されている当該マイグレーションファイルの実体を、更新要求の内容に従って更新し、当該マイグレーションファイルのデータ実体同期要フラグ２１１３をＯＮに設定する（Ｓ３０１３）。
一方、上記判断の結果、マイグレーションファイルの実体が第１ストレージ装置１０ａに格納されていない場合には、ファイルシステム３１２は、第２サーバ装置３ｂに対し、当該マイグレーションファイルに対応するアーカイブファイルの取得要求を送信し（Ｓ３０１４）、これに応じて第２サーバ装置３ｂから送られてくるアーカイブファイルを受信する（Ｓ３０１５）。そしてファイルシステム３１２は、受信したアーカイブファイルの内容を更新要求の内容に従って更新し、更新後のアーカイブファイルを当該マイグレーションファイルの実体として第１ストレージ装置１０ａに格納する（Ｓ３０１６）。
またファイルシステム３１２は、当該マイグレーションファイルのスタブ化フラグ２１１１をオフに設定し、レプリケーションフラグ２１１４をＯＮに設定し（つまりレプリケーション管理方式に戻す。）、当該マイグレーションファイルのメタデータ同期要フラグ２１１２をＯＮに設定し、当該マイグレーションファイルのデータ実体同期要フラグ２１１３をＯＮに設定する。尚、当該マイグレーションファイルがファイルクオータ管理方式で管理されており、この更新処理によって当該マイグレーションファイルの使用量（ファイルサイズ（データサイズ））が増加した場合には、その増分についてユーザからクオータを徴収する。
次に、図２４に示したクオータ管理方式変更処理Ｓ２４００において、ユーザクオータ管理テーブル３３１及びファイルクオータ管理テーブル３３２の設定方法について具体的に説明する。
図３１はユーザクオータ管理テーブル３３１の一例である。同図に示すように、このユーザクオータ管理テーブル３３１には、ユーザＩＤが「User01」というユーザのクオータが２０００［MB］、ユーザＩＤが「User02」というユーザのクオータが２０００［MB］、ユーザＩＤが「User03」というユーザのクオータが２０００［MB］との内容が設定されている。
またこのユーザクオータ管理テーブル３３１には、ユーザＩＤが「User01」というユーザの現在の使用量が１０００［MB］、ユーザＩＤが「User02」というユーザの現在の使用量が１５００［MB］、ユーザＩＤが「User03」というユーザの現在の使用量が１１００［MB］であるとの設定がされている。
図３２は、ファイルアクセスログ３３５に基づき把握される、ファイル名（ファイルパス名）が「/home/User01/a.txt」というファイルに対する各ユーザのアクセス回数の一例である。同図に示すように、このファイルアクセスログ３３５には、上記ファイルに対し、所定時間前から現在までの間に、ユーザＩＤが「User01」であるユーザが２５回、ユーザＩＤが「User02」であるユーザが３５回、ユーザＩＤが「User03」であるユーザが４０回アクセスしたことが記録されている。
ここで上記ファイル（ファイル名が「/home/User01/a.txt」というファイル）についてファイルクオータ管理方式による管理を開始する場合、第１サーバ装置３ａのファイルクオータ管理部３１６は、以下のようにしてファイルクオータ管理テーブル３３２の内容を設定する。
まずファイルクオータ管理部３１６は、ファイルアクセスログ３３５の内容に基づき、各ユーザについて次のように重み付けを行う。
User01の重み＝25/（25+35+40）＝0.25
User02の重み＝35/（25+35+40）＝0.35
User03の重み＝40/（25+35+40）＝0.40
次にファイルクオータ管理部３１６は、上記ファイルの現在のファイルサイズ（ここでは100［MB］であるものとする。）と、余裕係数（ここでは1.5とする。）と、上記重みとに基づき、各ユーザが負担すべきクオータの値を次のようにして求め、求めた値を用いて、図３３に示すような上記ファイルについてのファイルクオータ管理テーブル３３２を生成する。
User01が負担すべきクオータ値＝100［MB］ * 1.5 * 0.25 ＝37.5［MB］
User02が負担すべきクオータ値＝100［MB］ * 1.5 * 0.35 ＝52.5［MB］
User03が負担すべきクオータ値＝100［MB］ * 1.5 * 0.40 ＝60.0［MB］
尚、上記余裕係数は1.0以上の任意の値であり、情報処理システム１の運用状態やユーザニーズ等に応じて適切な値に設定される。
このように、各ユーザから上記ファイルへの夫々のアクセス頻度に応じたユーザクオータを徴収するようにすることで、各ユーザから公平にユーザクオータを徴収することができる。またこの例では各ユーザに重み付けを行って各ユーザが負担すべきクオータ値を求めているが、上記ファイルの現在のファイルサイズ（100［MB］）を各ユーザに均等に負担させるようにしてもよい（例えば、余裕計数を1.5とした場合には、各ユーザに100［MB］*1.5/3=50［MB］という均等なクオータ値を負担させる。）。各ユーザから均等にユーザクオータを徴収するようにすれば、各ユーザから平等にユーザクオータを徴収することができる。
ファイルクオータ管理テーブル３３２が生成されると、第１サーバ装置３ａのユーザクオータ管理部３１５は、各ユーザが負担（供出）したクオータ値をユーザクオータ管理テーブル３３１の各ユーザのクオータ値から差し引く。図３４に、図３３のファイルクオータ管理テーブル３３２が生成された場合における、差し引き後のユーザクオータ管理テーブル３３１の内容を示す。
図３３に示すファイルクオータ管理テーブル３３２が生成されて上記ファイルについてのファイルクオータ管理方式による管理が開始された後、当該管理を終了する場合には、上記ファイルについてファイルクオータ管理方式で管理するために各ユーザに負担させていたクオータ値を各ユーザに返却する。またファイルクオータ管理方式による管理がされている間に上記ファイルのファイルサイズが増加した場合には、その増分をユーザクオータ管理テーブル３３１の各ユーザの使用量３３１３に所定の比率で分配する。
例えば図３５に示すように、ファイルクオータ管理方式による管理がされている間に上記ファイルのファイルサイズが50［MB］増加して150［MB］になった場合には、50［MB］を所定の比率（例えば、同図に示すように前述の比率（0.25:0.35:0.40）や均等な比率（0.33:0.33:0.33））で各ユーザの使用量３３１３に分配する。
尚、このようにファイルクオータ管理方式による管理を終了する時点において按分計算を行って増分を各ユーザに配分するのではなく、上記ファイルの前記増分についての各ユーザの寄与分をファイルクオータ管理テーブル３３２に予め記録しておき、記録しておいた各ユーザの寄与分をファイルクオータ管理方式による管理を終了する時点で各ユーザの使用量３３１３に反映させるようにしてもよい。そのようにすれば、各ユーザにより公平にファイルクオータを負担させることができる。
＜処理説明＞
次に情報処理システム１にて行われる処理の詳細について説明する。
図３６は、第１サーバ装置３ａが、クライアント装置２から、ファイルに対するアクセス要求を受け付けた際に行われる処理（以下、ファイルアクセス時処理Ｓ３６００と称する。）を説明するフローチャートである。以下、同図とともに説明する。
第１サーバ装置３ａは、クライアント装置２からファイルに対するアクセス要求を受け付けると（Ｓ３６１１）、アクセス要求に指定されているアクセス先のファイル（以下、対象ファイルと称する。）のスタブ化フラグ２１１１の内容を調べる（Ｓ３６１２）。
スタブ化フラグ２１１１がＯＮである場合は（Ｓ３６１２：ＯＮ）、Ｓ３６２１に進み、スタブ化フラグ２１１１がＯＦＦである場合は（Ｓ３６１２：ＯＦＦ）、Ｓ３６６０に進む。
Ｓ３６２１では、第１サーバ装置３ａは、受け付けたアクセス要求に指定されている処理内容を判断する。処理内容がファイルの参照（Read）であれば（Ｓ３６２１：参照）、Ｓ３６２２に進み、処理内容がファイルの参照以外であれば（Ｓ３６２１：参照以外）、Ｓ３６３１に進む。
Ｓ３６２２では、第１サーバ装置３ａは、対象ファイルの実体が第１ストレージ装置１０ａに存在するか否かを判断する。対象ファイルの実体が存在するか否かは、例えば対象ファイルのメタデータに、第１ストレージ装置１０ａの有効な格納先（論理ボリュームの識別子やブロックアドレス）が設定されているか否かに基づき判断する。対象ファイルの実体が第１ストレージ装置１０ａに存在する場合は（Ｓ３６２２：ＹＥＳ）、Ｓ３６２３に進み、存在しない場合は（Ｓ３６２２：ＮＯ）、Ｓ３６２４に進む。
Ｓ３６２３では、第１サーバ装置３ａは、第１ストレージ装置１０ａから対象ファイルの実体を取得する。その後はＳ３６２５に進む。Ｓ３６２４では、第１サーバ装置３ａは、第２ストレージ装置１０ｂからファイルの実体を取得する。その後はＳ３６２５に進む。Ｓ３６２５では、第１サーバ装置３ａは、取得したファイルの実体を要求元に返す。
Ｓ３６２６では、第１サーバ装置３ａは、対象ファイルについて行った参照に関する以上の処理の履歴をファイルアクセスログ３３５に記録する。その後はＳ３６１１に戻り、再びクライアント装置２から送られてくるアクセス要求を待機する。
Ｓ３６３１では、第１サーバ装置３ａは、アクセス要求に指定されている処理内容を判断する。処理内容がファイルの更新（Write）であれば（Ｓ３６３１：更新）、Ｓ３６４１に進み、処理内容がファイルの更新以外であれば（Ｓ３６３１：更新以外）、Ｓ３６７０に進む。
Ｓ３６４１では、第１サーバ装置３ａは、第２ストレージ装置１０ｂからファイルの実体を取得する。
続いて第１サーバ装置３ａは、ファイルクオータ管理テーブル３３２を参照し、当該アクセス要求に従って対象ファイルを更新することにより、対象ファイルの容量（ファイルサイズ）がファイルクオータ３３２２を超過するか否かを判断する（Ｓ３６４２）。対象ファイルの容量がファイルクオータ３３２２を超過する場合は（Ｓ３６４２：ＹＥＳ）、Ｓ３６５１に進み、超過しない場合は（Ｓ３６４２：ＮＯ）、Ｓ３６４３に進む。
Ｓ３６４３では、第１サーバ装置３ａは、ユーザクオータ管理テーブル３３１を参照し、当該アクセス要求に従って対象ファイルを更新することにより、対象ファイルの所有者（ユーザ）の記憶資源の使用量３３１３が、当該ユーザのユーザクオータ３３１２を超過するか否かを判断する。当該ユーザの記憶資源の使用量３３１３が、当該ユーザのユーザクオータ３３１２を超過する場合は（Ｓ３６４３：ＹＥＳ）、Ｓ３６４４に進み、超過しない場合は（Ｓ３６４３：ＮＯ）、Ｓ３６５３に進む。
Ｓ３６４４では、第１サーバ装置３ａは、対象ファイルのスタブ化フラグ２１１１をＯＮに設定し、対象ファイルをマイグレーション管理方式の候補に設定する。またこれに伴い、第１サーバ装置３ａは、対象ファイルのレプリケーションフラグ２１１４をＯＦＦに設定する（Ｓ３６４５）。その後はＳ３６２６に進む。
一方、Ｓ３６５１では、第１サーバ装置３ａは、更新によるファイルクオータの超過分（＝更新後の対象ファイルのファイルサイズ−対象ファイルのファイルクオータ）を、当該ユーザのユーザクオータから徴収（減算）し、ユーザクオータ管理テーブル３３１３の当該ユーザのユーザクオータ３３１２の値を徴収後の値に更新する。また第１サーバ装置３ａは、徴収したユーザクオータを、対象ファイルのファイルクオータに加算し、ファイルクオータ管理テーブル３３２のファイルクオータ３３２２の値を加算後の値に更新する（Ｓ３６５２）。
このように、ファイルの更新によってファイルの容量がファイルクオータを超える場合には、当該ファイルを使用するユーザから随時ユーザクオータを徴収してファイルクオータに追加するので、更新によって当該ファイルがファイルクオータによる管理から頻繁に外されてしまうのを防ぐことができる。
続いて第１サーバ装置３ａは、対象ファイルの実体をアクセス要求に従って実際に更新し（Ｓ３６５３）、対象ファイルのメタデータ同期要フラグ２１１２及びデータ実体同期要フラグ２１１３をいずれもＯＮに設定する（Ｓ３６５４）。またこのとき第１サーバ装置３ａは、対象ファイルのスタブ化フラグ２１１１をＯＦＦに設定し（Ｓ３６５５）、対象ファイルのレプリケーションフラグ２１１４をＯＮに設定する（Ｓ３６５６）。その後はＳ３６２６に進む。
図３７は図３６のＳ３６６０の処理（以下、スタブ化フラグＯＦＦ時処理Ｓ３６６０と称する。）を説明するフローチャートである。以下、同図とともに説明する。
まず第１サーバ装置３ａは、アクセス要求に指定されている処理内容を判断する（Ｓ３７１１）。処理内容がファイルの更新（Write）であれば（Ｓ３７１１：更新）、Ｓ３７２１に進み、処理内容がファイルの更新以外であれば（Ｓ３７１１：更新以外）、Ｓ３７１２に進む。
Ｓ３７１２では、第１サーバ装置３ａは、対象ファイルについて更新以外の処理（例えば、対象ファイルの参照処理、対象ファイルのファイルオープン、対象ファイルのファイルクローズ）を行う。その後は図３６のＳ３６２６に戻る。
Ｓ３７２１では、第１サーバ装置３ａは、ユーザクオータ管理テーブル３３１を参照し、当該アクセス要求に従って対象ファイルを更新することにより、対象ファイルの所有者（ユーザ）の使用量３３１３が、当該ユーザのユーザクオータ３３１２を超過するか否かを判断する。当該ユーザの使用量３３１３が、当該ユーザのユーザクオータ３３１２を超過する場合は（Ｓ３７２１：ＹＥＳ）、要求元のクライアント装置２にエラー（クオータを超過した旨のエラー）を返し（Ｓ３７３１）、その後は図３６のＳ３６２６に戻る。
一方、対象ファイルの所有者（ユーザ）の使用量３３１３が、当該ユーザのユーザクオータ３３１２を超過しない場合は（Ｓ３７２１：ＮＯ）、Ｓ３７２２に進む。
Ｓ３７２２では、第１サーバ装置３ａは、対象ファイルの実体をアクセス要求に従って実際に更新する。また対象ファイルのレプリケーションフラグ２１１４がＯＮに設定されている場合（Ｓ２７２３：ＯＮ）、第１サーバ装置３ａは、対象ファイルのメタデータ同期要フラグ２１１２及びデータ実体同期要フラグ２１１３をいずれもＯＮに設定する（Ｓ３７２４）。その後は図３６のＳ３６２６に戻る。
図３８は、図３６のＳ３６７０の処理を説明するフローチャートである。
参照、更新以外処理Ｓ３６７０では、第１サーバ装置３ａは、対象ファイルについて更新以外の処理（例えば、対象ファイルのオープンやクローズ）を行う（Ｓ３８１１）。その後は図３６のＳ３６２６に戻る。
図３９は、図３６のＳ３６７０の処理（以下、参照、更新以外処理Ｓ３９００と称する。）の他の態様を説明するフローチャートである。図３８の場合と異なり、この態様では対象ファイルのオープンに際してインクリメントされファイルのクローズに際してデクリメントされる参照カウンタの値がゼロになったことを契機として、対象ファイルの実体を第１ストレージ装置１０ａから削除し、対象ファイルをスタブ化するようにしている。
同図に示すように、まず第１サーバ装置３ａは、アクセス要求に指定されている処理内容を判断する（Ｓ３９１１）。処理内容がファイルのオープンであれば（Ｓ３９１１：ＯＰＥＮ）、Ｓ３９１２に進み、処理内容がファイルのクローズであれば（Ｓ３９１１：ＣＬＯＳＥ）、Ｓ３９２１に進む。
Ｓ３９１２では、第１サーバ装置３ａは、対象ファイルの参照カウンタをインクリメント（＋１）し、対象ファイルをオープンする（Ｓ３９１３）。その後は図３６のＳ３６２６に戻る。
Ｓ３９２１では、第１サーバ装置３ａは、対象ファイルの参照カウンタをデクリメント（−１）し、対象ファイルをクローズする（Ｓ３９２２）。
続いて第１サーバ装置３ａは、対象ファイルの使用者が、対象ファイルの所有者のみであるか否かを判断する（Ｓ３９２３）。対象ファイルの使用者が、対象ファイルの所有者のみでなければ（Ｓ３９２３：ＮＯ）、図３６のＳ３６２６に戻る。対象ファイルの使用者が、対象ファイルの所有者のみであれば（Ｓ３９２３：ＹＥＳ）、Ｓ３９２４に進む。
Ｓ３９２４では、第１サーバ装置３ａは、対象ファイルの参照カウンタの値がゼロであり、かつ、対象ファイルのメタデータ同期要フラグ２１１２及びデータ実体同期要フラグ２１１３がいずれもＯＦＦであるか否かを判断する。上記条件を満たさない場合は（Ｓ３９２４：ＮＯ）、図３６のＳ３６２６に戻る。上記条件を満たす場合は（Ｓ３９２４：ＹＥＳ）、Ｓ３９２５に進む。
Ｓ３９２５では、第１サーバ装置３ａは、対象ファイルの実体を第１ストレージ装置１０ａから削除し、対象ファイルをスタブ化する。またそれに伴い、第１サーバ装置３ａは、ユーザクオータ管理テーブル３３１の対象ファイルの所有者の使用量３３１３をスタブ化後の値に更新する（Ｓ３９２６）。その後は図３６のＳ３６２６に戻る。
このように、マイグレーションの実施は、ファイルの参照カウンタが０となり、メタデータ及び実体の同期が不要となったタイミングで行うことで、適切かつ安全にマイグレーションを行うことができる。
図４０は、第１サーバ装置３ａが、第１ストレージ装置１０ａに格納されているファイルについてレプリケーション管理方式に移行する旨の要求（以下、レプリケーション要求と称する。）を受け付けた場合に第１サーバ装置３ａによって行われる処理（以下、レプリケーション処理Ｓ４０００と称する。）を説明するフローチャートである。
第１サーバ装置３ａは、レプリケーション要求を受け付けると（Ｓ４０１１：ＹＥＳ）、レプリケーション要求に指定されているファイル（以下、レプリケーション対象ファイルと称する。）についてのレプリケーション先（複製ファイルの格納場所）を、第２サーバ装置３ｂから取得する（Ｓ４０１２）。尚、第１サーバ装置３ａは、例えば、クライアント装置２から上記レプリケーション要求を受け付ける。また第１サーバ装置３ａは、例えば、第１サーバ装置３ａの内部（ファイル共有処理部３１１、ファイルシステム３１２、カーネル／ドライバ３１８等）から上記レプリケーション要求を受け付ける。
次に第１サーバ装置３ａは、レプリケーション対象ファイルのメタデータ及び実体を第１ストレージ装置１０ａから取得し（Ｓ４０１３）、取得したメタデータ及び実体の複製を第２サーバ装置３ｂに転送し（Ｓ４０１４）、レプリケーション対象ファイルのレプリケーションフラグ２１１４をＯＮに設定する（Ｓ４０１５）。その後はＳ４０１１に戻り、第１サーバ装置３ａは、次のレプリケーション要求を待機する。
図４１は、第１サーバ装置３ａが、第１ストレージ装置１０ａに格納されているファイルについて前述した同期要求を受け付けた場合に、第１サーバ装置３ａによって行われる処理(以下、同期処理Ｓ４１００と称する。）を説明するフローチャートである。
第１サーバ装置３ａは、同期要求を受け付けると（Ｓ４１１１：ＹＥＳ）、第１ストレージ装置１０ａに格納されているファイルのうち、メタデータ同期要フラグ２１１２がＯＮに設定されているファイルのメタデータ、及びデータ実体同期要フラグ２１１３がＯＮに設定されているファイルの実体を取得し、取得したメタデータ及び実体を第２サーバ装置３ｂに転送する（Ｓ４１１３）。また第１サーバ装置３ａは、転送したファイルのメタデータ同期要フラグ２１１２及びデータ実体同期要フラグ２１１３をＯＦＦに設定する（Ｓ４１１４）。
図４２は、第２サーバ装置３ｂが、前述したレプリケーション処理Ｓ４０００又は前述した同期処理Ｓ４１００が実行されることにより第１サーバ装置３ａから送信されてきたメタデータ又は実体を受信した場合に、第２サーバ装置３ｂにて行われる処理（以下、ファイル格納処理Ｓ４２００と称する。）を説明するフローチャートである。
第２サーバ装置３ｂは、第１サーバ装置３ａからメタデータ又は実体を受信すると（Ｓ４２１１）、受信したメタデータ又は実体を第２ストレージ装置１０ｂに格納する（Ｓ４２１２）。
図４３は、第１サーバ装置３ａが、ユーザの使用量がユーザクオータ３３１２を超過していることを検出した場合に第１サーバ装置３ａによって行われる処理（以下、ユーザクオータ超過検出処理Ｓ４３００と称する。）を説明するフローチャートである。
第１サーバ装置３ａは、ユーザクオータ管理テーブル３３１を参照し、ユーザの使用量３３１３がユーザクオータ３３１２を超過しているか否かを随時（定期的、リアルタイム等）監視している（Ｓ４３１１）。あるユーザの使用量３３１２がユーザクオータ３３１２を超過していることを検知すると（Ｓ４３１１：ＹＥＳ）、第１サーバ装置３ａは、そのユーザが所有しているファイルのスタブ化フラグ２１１１をＯＮに設定し、また当該ファイルのレプリケーションフラグ２１１４をＯＦＦに設定する（Ｓ４３１２）。
次に第１サーバ装置３ａは、ファイルアクセスログ３３５を参照し、そのユーザが所有しているファイルのうち、他のユーザも使用（共用）しているファイルを抽出し（Ｓ４３１３）、抽出したファイルを対象として、ファイルクオータ管理方式への移行を行う（Ｓ４３１４）。その後はＳ４３１１に戻り、使用量３３１３がユーザクオータ３３１２を超過しているか否かの監視を開始する。
図４４は、図４３のＳ４３１４における処理（以下、ファイルクオータ管理方式移行処理Ｓ４４００と称する。）を説明するフローチャートである。尚、同図に示す処理は、図４３のＳ４３１３にて抽出したファイルの夫々について行われる。以下、同図とともに説明する。
まず第１サーバ装置３ａは、抽出したファイルをファイルクオータ管理方式に移行するに際し、そのファイルについてのファイルクオータの負担割合の決定方式を取得する（Ｓ４４１１）。負担割合の決定方式には、例えば、前述した重み付けによる方法や、均等に割り付ける方法等がある。ここではこれら２通りの決定方式があるものとして説明する。尚、上記決定方式の取得は、例えば、予めファイルの所有者ごとに設定された情報を参照する等して行われる。取得した決定方式が重み付けによる方法である場合には（Ｓ４４１１：重み付け）、Ｓ４４１２に進み、均等割付である場合には（Ｓ４４１１：均等）、Ｓ４４１３に進む。
Ｓ４４１２では、第１サーバ装置３ａは、抽出したファイルについて、各ユーザの負担割合を算出する（Ｓ４４１２）。
Ｓ４４１３では、第１サーバ装置３ａは、各ユーザに負担させるファイルクオータを算出する。決定方式が重み付けである場合はＳ４４１２にて算出した負担割合を用いて各ユーザに負担させるファイルクオータを算出する。決定方式が均等割付である場合は、抽出したファイルのファイルサイズを、当該ファイルを使用しているユーザ数で按分することにより各ユーザに負担させるファイルクオータを算出する。
Ｓ４４１４では、第１サーバ装置３ａは、ユーザクオータ管理テーブル３３１に管理されている各ユーザのユーザクオータ３３１２から、夫々に負担させるファイルクオータ分を減算する。
Ｓ４４１５では、第１サーバ装置３ａは、抽出したファイルをファイルクオータ管理方式で管理するための情報をファイルクオータ管理テーブル３３２に登録する。
図４５は、第１サーバ装置３ａが、ファイルクオータ管理方式にて管理されているファイルのファイルクオータを負担しているユーザのうち、当該ファイルに対するアクセスが少ないユーザのファイルクオータの負担を返却（ファイルクオータをユーザクオータに変更）する処理（以下、ファイルクオータ返却処理Ｓ４５００と称する。）を示している。尚、ファイルクオータ返却処理Ｓ４５００は、随時（定期的、リアルタイム等）に行われる。また同図に示す処理は、ファイルクオータ管理テーブル３３２に管理されている個々のファイルについて個別に行われる。
まず第１サーバ装置３ａは、ファイルアクセスログ３３５を参照し、ファイルクオータ管理テーブル３３２に管理されているファイルについて、そのファイルへのアクセス数が少ないユーザ（所定時間前から現在までの当該ファイルへのアクセス数が予め設定された閾値以下であるユーザ）を特定する（Ｓ４５１１）。
次に第１サーバ装置３ａは、特定したユーザが負担しているファイルクオータを、ユーザクオータに返却する（Ｓ４５１２）。この返却は、具体的には、ファイルクオータ管理テーブル３３２の当該ユーザの負担するファイルクオータ（全部又は一部）をユーザクオータ管理テーブル３３１の当該ユーザのユーザクオータ３３１２に加算し、加算した分をファイルクオータ管理テーブル３３２の当該ユーザの負担分から減算し、その分、当該ファイルについての他のユーザの負担分を増加させる（減算前のファイルクオータ３３２２の値が維持されるように増加させる）ことにより行う。
このように、ファイルクオータ管理方式で管理されているファイルへのアクセス頻度が少ないユーザに対しては、ユーザクオータが自動的に返却されるので、ファイルクオータを公平にユーザに負担させることができる。
図４６は、第１サーバ装置３ａが、ファイルクオータ管理方式にて管理されているファイルを使用しているにも拘わらずファイルクオータを現在負担していないユーザをファイルアクセスログ３３５に基づき抽出し、抽出したユーザからそのファイルのファイルクオータを徴収する処理(以下、ファイルクオータ徴収処理Ｓ４６００と称する。）を説明するフローチャートである。尚、ファイルクオータ徴収処理Ｓ４６００は、随時（定期的、リアルタイム等）に行われる。また同図に示す処理は、ファイルクオータ管理テーブル３３２に管理されている個々のファイルについて個別に行われる。
まず第１サーバ装置３ａは、ファイルアクセスログ３３５とファイルクオータ管理テーブル３３２とを対照し、ファイルクオータ管理方式にて管理されているファイルを使用しているにも拘わらずファイルクオータを現在負担していないユーザ（以下、徴収候補ユーザと称する。）をファイルアクセスログ３３５に基づき特定する（Ｓ４６１１）。具体的には、例えば、第１サーバ装置３ａは、所定時間前から現在までの間に当該ファイルを使用した回数が予め設定された閾値を超えているユーザを徴収候補ユーザとして抽出する。
次に第１サーバ装置３ａは、徴収候補ユーザが負担すべきファイルクオータを算出し（例えば、前述した重み付けや均等割付により算出する。）、算出した結果に基づきファイルクオータ管理テーブル３３２及びユーザクオータ管理テーブル３３１を更新する（Ｓ４６１２）。
このように、ファイルクオータ管理方式で管理されているファイルについては、ファイルクオータを供出していないユーザのアクセス頻度が高くなると、自動的にそのユーザからファイルクオータを徴収するので、ファイルクオータを公平にユーザに負担させることができる。
図４７は、ファイルクオータ管理方式で管理されているファイルのユーザクオータ管理方式による管理への移行、及び、ユーザクオータ管理方式で管理されているファイルのマイグレーションの実行に関する処理(以下、監視処理Ｓ４７００と称する。）を説明するフローチャートである。
第１サーバ装置３ａは、ファイルクオータ管理方式で管理されているファイル（以下、対象ファイルと称する。）のファイルサイズが、ファイルクオータを超過しているか否かを随時（定期的、リアルタイム、予め設定された時機等）判断する（Ｓ４７１１）。第１サーバ装置３ａが、対象ファイルのファイルサイズが、ファイルクオータを超過していると判断した場合は（Ｓ４７１１：ＹＥＳ）、Ｓ４７１２に進む。
Ｓ４７１２では、第１サーバ装置３ａは、対象ファイルのファイルクオータをユーザクオータに全て返却し、当該ファイルについてのファイルクオータ管理方式による管理を終了する。尚、第１サーバ装置３ａは、ユーザクオータ管理テーブル３３１及びファイルクオータ管理テーブル３３２の内容を返却後の状態に更新する。
次に第１サーバ装置３ａは、マイグレーションを実施するか否かを判断する（Ｓ４３１３）。ここでマイグレーションを実施するか否かの判断は、例えば、ユーザクオータ管理テーブル３３１を参照し、使用量３３１３がユーザクオータ３３１２の所定の閾値を超えているか否かに基づき行う。マイグレーションを実施する場合には（Ｓ４７１３：ＹＥＳ）、Ｓ４７１４に進み、マイグレーションを実施しない場合には（Ｓ４７１３：ＮＯ）、Ｓ４７１１に戻る。
Ｓ４７１４では、第１サーバ装置３ａは、対象ファイルの実体を第１ストレージ装置１０ａから削除し、当該ファイルのマイグレーションを実施（スタブ化）する。また第１サーバ装置３ａは、ユーザクオータ管理テーブル３３１を削除後の状態に更新する（Ｓ４７１５）。
図４８は、所有者のみが使用しているファイルについてマイグレーションを実施（スタブ化）する処理（以下、監視処理Ｓ４８００と称する。）を説明するフローチャートである。尚、監視処理Ｓ４８００は、第１サーバ装置３ａによって随時（定期的、リアルタイム等）に行われる。
第１サーバ装置３ａは、第１ストレージ装置１０ａに格納されているファイルのうち、所有者のみが使用しているファイル（所定時間前から現在までの間に他のユーザによってアクセスされていないファイル。）であり、スタブ化フラグ２１１１がＯＮに設定され、メタデータ同期要フラグ２１１２及びデータ実体同期要フラグ２１１３がいずれもＯＦＦに設定され、かつ、所定期間以上アクセスがされていないファイルを抽出する（Ｓ４８１１）。
次に第１サーバ装置３ａは、抽出したファイルの実体を第１ストレージ装置１０ａから削除（マイグレーションの実施）し（Ｓ４８１２）、ユーザクオータ管理テーブル３３１をファイル削除後の状態に更新する（Ｓ４８１３）。
以上に説明したように、本実施形態の情報処理システム１にあっては、ユーザクオータに基づく管理においてマイグレーションの対象とされたファイル（尚、マイグレーションの対象とされても、そのファイルについて直ちにマイグレーションが実行されるわけではない）のうち、複数のユーザによって使用されているファイルをファイルクオータに基づく管理の対象とする。そのため、あるファイルがユーザクオータに基づく管理においてマイグレーションの対象とされていても、そのファイルが複数のユーザによって使用（共用）されているファイルであれば、そのファイルはユーザクオータに基づく管理の対象から外されてファイルクオータに基づく管理下に置かれることになる（図４３）。
このように、本実施形態の情報処理システム１にあっては、ファイルシステム３１２に提供されている記憶資源の枯渇を防ぐべく、基本的にはユーザクオータに基づく管理を行うが、ユーザクオータを超えるファイルであっても、複数のユーザによって使用されているファイルについては、特定のユーザ（所有者ユーザ）の都合のみによってマイグレーションの要否が判断されてしまう可能性があるユーザクオータ管理方式から外されて、複数のユーザのユーザクオータによって供出されるファイルクオータ管理方式による管理対象とされる。このため、ファイルクオータ管理方式による管理対象とされている間は、特定のユーザの都合のみによってマイグレーションが実施されてしまい、他のユーザのサービスに影響が生じるのを防ぐことができる。
またファイルクオータに基づく管理対象とされているあるファイルの容量がファイルクオータに基づく閾値を超えている場合は、そのファイルはファイルクオータに基づく管理対象から外されて再びユーザクオータに基づく管理対象とされるので（図４７）、ファイルシステム３１２に提供されている記憶資源の確保が疎かにされることはない。このように本実施形態の情報処理システム１によれば、ファイルをマイグレーションすることによって生じる他のユーザへの影響を抑えつつ、記憶資源の確保のためのマイグレーションを適切に行うことができる。
またファイルの更新によってファイルの容量がファイルクオータを超える場合には、当該ファイルを使用するユーザから随時ユーザクオータを徴収してファイルクオータに追加するので（図３６）、更新によって当該ファイルがファイルクオータによる管理から頻繁に外されてしまうのを防ぐことができる（ファイルクオータによる管理から外されてユーザクオータによる管理に戻るのは、原則として監視処理（図４７）による判断時に限られる）。
またファイルクオータ管理方式で管理されているファイルへのアクセス頻度が少ないユーザに対しては、ユーザクオータが自動的に返却されるので（図４５）、ファイルクオータを公平にユーザに負担させることができる。またファイルクオータ管理方式で管理されているファイルについては、ファイルクオータを供出していないユーザのアクセス頻度が高くなると、自動的にそのユーザからファイルクオータを徴収するので、ファイルクオータを公平にユーザに負担させることができる（図４６）。
以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。

Claims (15)

  1. クライアント装置と、第１ストレージ装置と、第２ストレージ装置が通信可能に接続する第２サーバ装置と、が通信可能に接続する第１サーバ装置であって、
    前記クライアント装置から前記ファイルに対するアクセス要求を受け付けると、前記第１ストレージ装置に格納されているファイルのデータに対して書き込み又は読み出しを行い、
    ユーザごとの記憶資源の使用量の制限を規定した情報であるユーザクオータを管理し、
    あるユーザの使用量が前記ユーザクオータに基づく閾値を超えている場合に、そのユーザが所有するファイルを前記第２ストレージ装置へのマイグレーションの対象とする、ユーザクオータに基づく管理を行い、
    マイグレーションの対象として特定された前記ファイルのうち、複数のユーザによって使用されているファイルを前記ユーザクオータに基づく管理の対象から外すとともに、当該ファイルを、そのファイルを使用している複数のユーザの前記ユーザクオータから供出される、ファイルごとの容量の制限を規定した情報であるファイルクオータに基づく管理の対象とし、
    前記ファイルクオータに基づく管理対象とされているあるファイルの容量が、前記ファイルクオータに基づく閾値を超えている場合に、そのファイルを前記ファイルクオータに基づく管理対象から外すとともに、当該ファイルを前記ユーザクオータに基づく管理対象とする
    サーバ装置。
  2. 請求項１に記載のサーバ装置であって、
    前記ファイルを前記ファイルクオータに基づく管理の対象とするに際し、当該ファイルを使用しているユーザの夫々から、各ユーザの当該ファイルに対するアクセス頻度に応じたユーザクオータを徴収し、徴収したユーザクオータを前記ファイルクオータとし、
    前記ファイルを前記ファイルクオータに基づく管理の対象とするに際し、当該ファイルを使用しているユーザの夫々から、均等にユーザクオータを徴収し、徴収したユーザクオータを前記ファイルクオータとする
    前記クライアント装置から、前記第１ストレージに格納されているファイルに対する更新要求を受信すると、その更新要求に基づく更新により当該ファイルの容量が前記ファイルクオータに基づく閾値を超えるか否かを判断し、閾値を超える場合は、当該ファイルを使用しているユーザの前記ユーザクオータを新たに徴収して前記ファイルクオータに追加し、
    前記ファイルクオータに基づく管理の対象であるファイルに前記ユーザクオータを供出しているユーザの当該ファイルに対するアクセス頻度が、予め設定された閾値以下である場合、そのユーザがそのファイルに供出しているファイルクオータをそのユーザのユーザクオータに返却し、
    前記ファイルクオータに基づく管理の対象であるファイルに前記ユーザクオータを供出していないユーザの当該ファイルに対するアクセス頻度が、予め設定された閾値を超えている場合、そのユーザからユーザクオータを徴収して前記ファイルの前記ファイルクオータに追加し、
    前記クライアント装置から、前記第１ストレージに格納されているファイルについてのオープン要求を受信すると、そのファイルをオープンするとともに、当該ファイルの参照カウンタをインクリメントし、
    前記クライアント装置から、前記第１ストレージに格納されているファイルについてのクローズ要求を受信すると、そのファイルをクローズするとともに、当該ファイルの参照カウンタをデクリメントし、
    前記クライアント装置から、前記第１ストレージに格納されているファイルについてのクローズ要求を受信したのに応じてそのファイルをクローズし、その結果、前記参照カウンタの値がゼロとなった場合に、当該ファイルがその所有者のみが使用するファイルであるならば、前記第１ストレージ装置から当該ファイルの実体のみを削除して当該ファイルのメタデータのみを残すことにより、当該ファイルをスタブ化し、
    前記第１ストレージ装置に格納されているあるファイルについてレプリケーション要求が発生すると、当該ファイルのデータを、前記第２サーバ装置を介して前記第２ストレージ装置に転送して当該ファイルについてのレプリケーションによる管理の対象とし、
    前記レプリケーションによる管理の対象とされており、かつ、前記ユーザクオータに基づく管理においてマイグレーションの対象とされている前記ファイルを、前記第２ストレージ装置にマイグレーションするに際し、前記第１ストレージ装置から当該ファイルの実体のみを削除して当該ファイルのメタデータのみを残すことにより、当該ファイルをスタブ化し、
    前記レプリケーションによる管理の対象になっているファイルについて、前記第１ストレージ装置に格納されているファイルのデータの内容と前記第２ストレージ装置に格納されているファイルのデータの内容とが不一致である場合に、両者について同期処理が必要である旨の情報を管理し、
    前記情報により前記同期処理が必要であるとされているファイルについては、前記マイグレーションの対象から外す
    サーバ装置。
  3. 請求項１に記載のサーバ装置であって、
    前記ファイルを前記ファイルクオータに基づく管理の対象とするに際し、当該ファイルを使用しているユーザの夫々から、各ユーザの当該ファイルに対するアクセス頻度に応じたユーザクオータを徴収し、徴収したユーザクオータを前記ファイルクオータとする
    サーバ装置。
  4. 請求項１に記載のサーバ装置であって、
    前記ファイルを前記ファイルクオータに基づく管理の対象とするに際し、当該ファイルを使用しているユーザの夫々から、均等にユーザクオータを徴収し、徴収したユーザクオータを前記ファイルクオータとする
    サーバ装置。
  5. 請求項１に記載のサーバ装置であって、
    前記クライアント装置から、前記第１ストレージに格納されているファイルに対する更新要求を受信すると、その更新要求に基づく更新により当該ファイルの容量が前記ファイルクオータに基づく閾値を超えるか否かを判断し、閾値を超える場合は、当該ファイルを使用しているユーザの前記ユーザクオータを新たに徴収して前記ファイルクオータに追加する
    サーバ装置。
  6. 請求項１に記載のサーバ装置であって、
    前記ファイルクオータに基づく管理の対象であるファイルに前記ユーザクオータを供出しているユーザの当該ファイルに対するアクセス頻度が、予め設定された閾値以下である場合、そのユーザがそのファイルに供出しているファイルクオータをそのユーザのユーザクオータに返却する
    サーバ装置。
  7. 請求項１に記載のサーバ装置であって、
    前記ファイルクオータに基づく管理の対象であるファイルに前記ユーザクオータを供出していないユーザの当該ファイルに対するアクセス頻度が、予め設定された閾値を超えている場合、そのユーザからユーザクオータを徴収して前記ファイルの前記ファイルクオータに追加する
    サーバ装置。
  8. 請求項１に記載のサーバ装置であって、
    前記クライアント装置から、前記第１ストレージに格納されているファイルについてのオープン要求を受信すると、そのファイルをオープンするとともに、当該ファイルの参照カウンタをインクリメントし、
    前記クライアント装置から、前記第１ストレージに格納されているファイルについてのクローズ要求を受信すると、そのファイルをクローズするとともに、当該ファイルの参照カウンタをデクリメントし、
    前記クライアント装置から、前記第１ストレージに格納されているファイルについてのクローズ要求を受信したのに応じてそのファイルをクローズし、その結果、前記参照カウンタの値がゼロとなった場合に、当該ファイルがその所有者のみが使用するファイルであるならば、前記第１ストレージ装置から当該ファイルの実体のみを削除して当該ファイルのメタデータのみを残すことにより、当該ファイルをスタブ化する
    サーバ装置。
  9. 請求項１に記載のサーバ装置であって、
    前記第１ストレージ装置に格納されているあるファイルについてレプリケーション要求が発生すると、当該ファイルのデータを、前記第２サーバ装置を介して前記第２ストレージ装置に転送して当該ファイルについてのレプリケーションによる管理の対象とし、
    前記レプリケーションによる管理の対象とされており、かつ、前記ユーザクオータに基づく管理においてマイグレーションの対象とされている前記ファイルを、前記第２ストレージ装置にマイグレーションするに際し、前記第１ストレージ装置から当該ファイルの実体のみを削除して当該ファイルのメタデータのみを残すことにより、当該ファイルをスタブ化する
    サーバ装置。
  10. 請求項９に記載のサーバ装置であって、
    前記レプリケーションによる管理の対象になっているファイルについて、前記第１ストレージ装置に格納されているファイルのデータの内容と前記第２ストレージ装置に格納されているファイルのデータの内容とが不一致である場合に、両者について同期処理が必要である旨の情報を管理し、
    前記情報により前記同期処理が必要であるとされているファイルについては、前記マイグレーションの対象から外す
    サーバ装置。
  11. クライアント装置と、第１ストレージ装置と、第２ストレージ装置が通信可能に接続する第２サーバ装置と、が通信可能に接続する第１サーバ装置の制御方法であって、
    前記第１サーバ装置が、
    前記クライアント装置からファイルに対するアクセス要求を受け付けると、前記第１ストレージ装置に格納されている前記ファイルのデータに対して書き込み又は読み出しを行い、
    ユーザごとの記憶資源の使用量の制限を規定した情報であるユーザクオータを管理し、
    あるユーザの使用量が前記ユーザクオータに基づく閾値を超えている場合に、そのユーザが所有するファイルを前記第２ストレージ装置へのマイグレーションの対象とする、ユーザクオータに基づく管理を行い、
    マイグレーションの対象として特定された前記ファイルのうち、複数のユーザによって使用されているファイルを前記ユーザクオータに基づく管理の対象から外すとともに、当該ファイルを、そのファイルを使用している複数のユーザの前記ユーザクオータから供出される、ファイルごとの容量の制限を規定した情報であるファイルクオータに基づく管理の対象とし、
    前記ファイルクオータに基づく管理対象とされているあるファイルの容量が、前記ファイルクオータに基づく閾値を超えている場合に、そのファイルを前記ファイルクオータに基づく管理対象から外すとともに、当該ファイルを前記ユーザクオータに基づく管理対象とする
    サーバ装置の制御方法。
  12. 請求項１１に記載のサーバ装置の制御方法であって、
    前記ファイルをファイルクオータに基づく管理の対象とするに際し、当該ファイルを使用しているユーザの夫々から、各ユーザの当該ファイルに対するアクセス頻度に応じたユーザクオータを徴収し、徴収したユーザクオータを前記ファイルクオータとする
    サーバ装置の制御方法。
  13. 請求項１１に記載のサーバ装置の制御方法であって、
    前記ファイルをファイルクオータに基づく管理の対象とするに際し、当該ファイルを使用しているユーザの夫々から、均等にユーザクオータを徴収し、徴収したユーザクオータを前記ファイルクオータとする
    サーバ装置の制御方法。
  14. 請求項１１に記載のサーバ装置の制御方法であって、
    前記クライアント装置から、前記第１ストレージに格納されているファイルに対する更新要求を受信すると、その更新要求に基づく更新により当該ファイルの容量が前記ファイルクオータに基づく閾値を超えるか否かを判断し、閾値を超える場合は、当該ファイルを使用しているユーザの前記ユーザクオータを新たに徴収して前記ファイルクオータに追加する
    サーバ装置の制御方法。
  15. 請求項１１に記載のサーバ装置の制御方法であって、
    前記ファイルクオータに基づく管理の対象であるファイルに前記ユーザクオータを供出しているユーザの当該ファイルに対するアクセス頻度が、予め設定された閾値以下である場合、そのユーザがそのファイルに供出しているファイルクオータをそのユーザのユーザクオータに返却する
    サーバ装置の制御方法。
JP2012546280A 2010-09-14 2010-09-14 サーバ装置及びサーバ装置の制御方法 Expired - Fee Related JP5439607B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/005593 WO2012035574A1 (en) 2010-09-14 2010-09-14 Server apparatus and control method of the same for migrating file based on user quota and file quota

Publications (2)

Publication Number Publication Date
JP2013525869A true JP2013525869A (ja) 2013-06-20
JP5439607B2 JP5439607B2 (ja) 2014-03-12

Family

ID=43734005

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012546280A Expired - Fee Related JP5439607B2 (ja) 2010-09-14 2010-09-14 サーバ装置及びサーバ装置の制御方法

Country Status (3)

Country Link
US (1) US8612395B2 (ja)
JP (1) JP5439607B2 (ja)
WO (1) WO2012035574A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016038700A1 (ja) * 2014-09-10 2016-03-17 株式会社日立製作所 ファイルサーバ装置、方法、及び、計算機システム

Families Citing this family (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9361243B2 (en) 1998-07-31 2016-06-07 Kom Networks Inc. Method and system for providing restricted access to a storage medium
US8768510B2 (en) * 2011-01-18 2014-07-01 Spectra Logic, Corporation System and method for directing a robotic storage system
US8577934B2 (en) * 2011-03-24 2013-11-05 Spectra Logic Corporation System and method for a storage system response with data migration
US20120254555A1 (en) * 2011-03-31 2012-10-04 Hitachi, Ltd. Computer system and data management method
US8423624B2 (en) * 2011-06-30 2013-04-16 International Business Machines Corporation Maintaining referential integrity
US10067940B2 (en) * 2012-03-02 2018-09-04 International Business Machines Corporation Enhanced storage quota management for cloud computing systems
US10146791B2 (en) * 2012-09-07 2018-12-04 Red Hat, Inc. Open file rebalance
US9092446B2 (en) * 2012-11-29 2015-07-28 Hitachi, Ltd. Storage system and file management method
US20140173499A1 (en) * 2012-12-14 2014-06-19 Chevron U.S.A. Inc. Systems and methods for integrating storage usage information
US10248670B1 (en) 2013-03-14 2019-04-02 Open Text Corporation Method and system for migrating content between enterprise content management systems
DE112013006414T5 (de) * 2013-05-15 2015-10-01 Hitachi, Ltd. Computersystem und Betriebsmittelmanagementverfahren
US20150004928A1 (en) * 2013-07-01 2015-01-01 Alcatel-Lucent Usa Inc. Group data plan quota allocation for mobile devices
US9507614B2 (en) * 2013-07-24 2016-11-29 Netapp, Inc. Method and system for presenting and managing storage shares
US10250579B2 (en) * 2013-08-13 2019-04-02 Alcatel Lucent Secure file transfers within network-based storage
US9798791B1 (en) * 2013-12-04 2017-10-24 Ca, Inc. System and method for filtering files during data replication
US10459892B2 (en) 2014-04-23 2019-10-29 Qumulo, Inc. Filesystem hierarchical aggregate metrics
US10095704B2 (en) 2014-08-26 2018-10-09 Ctera Networks, Ltd. Method and system for routing data flows in a cloud storage system
US9836480B2 (en) 2015-01-12 2017-12-05 Qumulo, Inc. Filesystem capacity and performance metrics and visualizations
US9563511B1 (en) * 2015-03-19 2017-02-07 EMC IP Holding Company LLC Performing input/output operations on a set of storage devices based on scalable input/output credits
US9881038B2 (en) 2015-04-20 2018-01-30 International Business Machines Corporation Archive migration system
US10776030B2 (en) 2016-01-29 2020-09-15 Hewlett Packard Enterprise Development Lp Quota arbitration of a distributed file system
US10095729B2 (en) * 2016-12-09 2018-10-09 Qumulo, Inc. Managing storage quotas in a shared storage system
US11461279B2 (en) * 2018-03-26 2022-10-04 Apple Inc. Share pools for sharing files via a storage service
CN112055849B (zh) * 2018-04-19 2024-01-16 村田机械株式会社 排他控制系统以及排他控制方法
US11360936B2 (en) 2018-06-08 2022-06-14 Qumulo, Inc. Managing per object snapshot coverage in filesystems
US10534758B1 (en) 2018-12-20 2020-01-14 Qumulo, Inc. File system cache tiers
US11151092B2 (en) 2019-01-30 2021-10-19 Qumulo, Inc. Data replication in distributed file systems
US10614033B1 (en) 2019-01-30 2020-04-07 Qumulo, Inc. Client aware pre-fetch policy scoring system
US11689475B2 (en) * 2019-08-09 2023-06-27 Oracle International Corporation System and method for tag based resource limits or quotas in a cloud infrastructure environment
US11646975B2 (en) 2019-08-09 2023-05-09 Oracle International Corporation System and method for compartment quotas in a cloud infrastructure environment
US10725977B1 (en) 2019-10-21 2020-07-28 Qumulo, Inc. Managing file system state during replication jobs
US10860372B1 (en) 2020-01-24 2020-12-08 Qumulo, Inc. Managing throughput fairness and quality of service in file systems
US10795796B1 (en) 2020-01-24 2020-10-06 Qumulo, Inc. Predictive performance analysis for file systems
US11151001B2 (en) 2020-01-28 2021-10-19 Qumulo, Inc. Recovery checkpoints for distributed file systems
US10860414B1 (en) 2020-01-31 2020-12-08 Qumulo, Inc. Change notification in distributed file systems
US10936538B1 (en) 2020-03-30 2021-03-02 Qumulo, Inc. Fair sampling of alternate data stream metrics for file systems
US10936551B1 (en) 2020-03-30 2021-03-02 Qumulo, Inc. Aggregating alternate data stream metrics for file systems
US11775481B2 (en) 2020-09-30 2023-10-03 Qumulo, Inc. User interfaces for managing distributed file systems
US11157458B1 (en) 2021-01-28 2021-10-26 Qumulo, Inc. Replicating files in distributed file systems using object-based data storage
US11461241B2 (en) 2021-03-03 2022-10-04 Qumulo, Inc. Storage tier management for file systems
US11567660B2 (en) 2021-03-16 2023-01-31 Qumulo, Inc. Managing cloud storage for distributed file systems
US11132126B1 (en) 2021-03-16 2021-09-28 Qumulo, Inc. Backup services for distributed file systems in cloud computing environments
US11669255B2 (en) 2021-06-30 2023-06-06 Qumulo, Inc. Distributed resource caching by reallocation of storage caching using tokens and agents with non-depleted cache allocations
US20230066835A1 (en) * 2021-08-27 2023-03-02 Keysight Technologies, Inc. Methods, systems and computer readable media for improving remote direct memory access performance
US11294604B1 (en) 2021-10-22 2022-04-05 Qumulo, Inc. Serverless disk drives based on cloud storage
US11354273B1 (en) 2021-11-18 2022-06-07 Qumulo, Inc. Managing usable storage space in distributed file systems
US11599508B1 (en) 2022-01-31 2023-03-07 Qumulo, Inc. Integrating distributed file systems with object stores
US11722150B1 (en) 2022-09-28 2023-08-08 Qumulo, Inc. Error resistant write-ahead log
US11729269B1 (en) 2022-10-26 2023-08-15 Qumulo, Inc. Bandwidth management in distributed file systems
US11934660B1 (en) 2023-11-07 2024-03-19 Qumulo, Inc. Tiered data storage with ephemeral and persistent tiers
US11921677B1 (en) 2023-11-07 2024-03-05 Qumulo, Inc. Sharing namespaces across file system clusters

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5313631A (en) * 1991-05-21 1994-05-17 Hewlett-Packard Company Dual threshold system for immediate or delayed scheduled migration of computer data files
US5946686A (en) * 1997-07-11 1999-08-31 International Business Machines Corporation Parallel file system and method with quota allocation
US6092163A (en) * 1998-12-04 2000-07-18 W. Quinn Associates, Inc. Pageable filter driver for prospective implementation of disk space quotas
JP4049525B2 (ja) * 2000-08-16 2008-02-20 富士通株式会社 分散処理システム
US6981005B1 (en) * 2000-08-24 2005-12-27 Microsoft Corporation Partial migration of an object to another storage location in a computer system
US20040039891A1 (en) * 2001-08-31 2004-02-26 Arkivio, Inc. Optimizing storage capacity utilization based upon data storage costs
AU2003262964A1 (en) 2002-08-30 2004-03-19 Arkivio, Inc. Optimizing storage capacity utilization based upon data storage costs
JP4400126B2 (ja) * 2003-08-08 2010-01-20 株式会社日立製作所 仮想一元化ネットワークストレージシステムにおける一元的なディスク使用量制御方法
JP4349301B2 (ja) * 2004-11-12 2009-10-21 日本電気株式会社 ストレージ管理システムと方法並びにプログラム
US7523286B2 (en) 2004-11-19 2009-04-21 Network Appliance, Inc. System and method for real-time balancing of user workload across multiple storage systems with shared back end storage
US7913053B1 (en) * 2005-02-15 2011-03-22 Symantec Operating Corporation System and method for archival of messages in size-limited containers and separate archival of attachments in content addressable storage
US8170985B2 (en) * 2006-01-31 2012-05-01 Emc Corporation Primary stub file retention and secondary retention coordination in a hierarchical storage system
US7552182B2 (en) * 2006-11-07 2009-06-23 International Business Machines Corporation Method, apparatus, and computer program product for lending e-mail space
WO2008126297A1 (ja) * 2007-03-30 2008-10-23 Fujitsu Limited バックアップ制御装置
US7783666B1 (en) * 2007-09-26 2010-08-24 Netapp, Inc. Controlling access to storage resources by using access pattern based quotas
US8170990B2 (en) 2008-05-30 2012-05-01 Hitachi, Ltd. Integrated remote replication in hierarchical storage systems
US8447942B2 (en) * 2008-06-09 2013-05-21 Microsoft Corporation Content storage using quotas
US7937453B1 (en) * 2008-09-24 2011-05-03 Emc Corporation Scalable global namespace through referral redirection at the mapping layer

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016038700A1 (ja) * 2014-09-10 2016-03-17 株式会社日立製作所 ファイルサーバ装置、方法、及び、計算機システム
JPWO2016038700A1 (ja) * 2014-09-10 2017-04-27 株式会社日立製作所 ファイルサーバ装置、方法、及び、計算機システム

Also Published As

Publication number Publication date
US20120066179A1 (en) 2012-03-15
WO2012035574A1 (en) 2012-03-22
US8612395B2 (en) 2013-12-17
JP5439607B2 (ja) 2014-03-12

Similar Documents

Publication Publication Date Title
JP5439607B2 (ja) サーバ装置及びサーバ装置の制御方法
JP5716099B2 (ja) 情報処理システム及び情報処理システムの制御方法
JP5706966B2 (ja) 情報処理システム、及び、それを用いたファイル復元方法
JP5452765B2 (ja) 情報処理システムにおける障害復旧方法、及び情報処理システム
US9319265B2 (en) Read ahead caching of data from cloud storage and method thereof
WO2013001581A1 (en) Server system and method for controlling information system
Beaver et al. Finding a needle in haystack: Facebook's photo storage
US8495331B2 (en) Storage apparatus and storage management method for storing entries in management tables
WO2011145137A1 (en) Storage apparatus and control method thereof for dynamic migration of small storage areas
US20130159648A1 (en) Data selection for movement from a source to a target
WO2012147124A1 (en) Server apparatus and method of controlling information system
US11720525B2 (en) Flexible tiering of snapshots to archival storage in remote object stores
Salunkhe et al. In search of a scalable file system state-of-the-art file systems review and map view of new Scalable File system
JP5681783B2 (ja) 情報処理システムにおける障害復旧方法、及び情報処理システム
Ananthanarayanan et al. Panache: a parallel WAN cache for clustered filesystems
Appuswamy et al. File-level, host-side flash caching with loris
Bletsch ECE590-03 Enterprise Storage Architecture Fall 2017
Ma et al. Experiences with hierarchical storage management support in blue whale file system
Simha Efficient Implementation Techniques for Block-Level Cloud Storage Systems
Sendir Optimizing NoSQL Databases Through Coherently Attached Flash
Liu-Chao et al. Research on Implement Snapshot of pNFS Distributed File System

Legal Events

Date Code Title Description
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: 20131203

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131216

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees