JP2004265110A - メタデータ配置方法、プログラムおよびディスク装置 - Google Patents
メタデータ配置方法、プログラムおよびディスク装置 Download PDFInfo
- Publication number
- JP2004265110A JP2004265110A JP2003054397A JP2003054397A JP2004265110A JP 2004265110 A JP2004265110 A JP 2004265110A JP 2003054397 A JP2003054397 A JP 2003054397A JP 2003054397 A JP2003054397 A JP 2003054397A JP 2004265110 A JP2004265110 A JP 2004265110A
- Authority
- JP
- Japan
- Prior art keywords
- logical
- physical
- metadata
- secondary storage
- storage devices
- 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
Links
Images
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/0629—Configuration or reconfiguration of storage systems
- G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
-
- 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/0604—Improving or facilitating administration, e.g. storage management
- G06F3/0605—Improving or facilitating administration, e.g. storage management by facilitating the interaction with a user or administrator
-
- 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/0671—In-line storage system
- G06F3/0683—Plurality of storage devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
-
- 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
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)
- Library & Information Science (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】メタデータの読み出しを高速化し、共有論理ボリュームの切り換えを高速化する。
【解決手段】論理ボリュームを共有するホスト１０１，１０２が、障害時にホスト切り換えを行うことによって高信頼性化を図っている計算機システムであって、物理ボリューム１０４上に存在する、論理ボリュームを構成するために必要なメタデータを、物理ボリュームの数よりも少ない数の物理ボリュームに一括化して配置する。それにより、メタデータの読み出しを高速化し、共有論理ボリュームの切り換えを高速化することができる。
【選択図】 図１
【解決手段】論理ボリュームを共有するホスト１０１，１０２が、障害時にホスト切り換えを行うことによって高信頼性化を図っている計算機システムであって、物理ボリューム１０４上に存在する、論理ボリュームを構成するために必要なメタデータを、物理ボリュームの数よりも少ない数の物理ボリュームに一括化して配置する。それにより、メタデータの読み出しを高速化し、共有論理ボリュームの切り換えを高速化することができる。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、論理ボリュームによるボリューム管理に関し、特に、論理ボリュームを使用可能にするための時間の短縮に適用して有効な技術に関するものである。
【０００２】
【従来の技術】
多くのオペレーティング・システムにおいて、論理ボリュームによるボリューム管理が主流となっている。論理ボリュームは、１つ以上の物理ボリュームの集合（ボリューム・グループ）から、新たに定義される仮想的なボリュームである。
【０００３】
論理ボリュームにより、ファイルシステムとして使用するボリュームを抽象化し、物理的なボリュームとは切り離された仮想的なストレージを管理することができる。
【０００４】
論理ボリュームを使用することによって、計算機システムでの柔軟なボリューム管理が可能となる。たとえば、論理ボリュームでは、複数のディスク装置を統合して単一のボリュームとして使用できる。その逆に、１つの大きなボリュームを複数の小さなボリュームとして使用できる。
【０００５】
また、ファイルシステムに空きが無くなった場合、ボリューム・グループに物理ボリュームを追加して、論理ボリュームの容量を増やすようなこともできる。
【０００６】
このような論理ボリュームを実現するために、オペレーティング・システムは、論理ボリュームを管理するための情報として、ボリューム・グループ管理用メタデータを物理ボリュームに格納する。
【０００７】
ボリューム・グループ管理用メタデータは、論理―物理のマッピングをはじめ、ボリューム・グループや論理ボリュームの構成に関する情報である。このようなメタデータは、ボリューム・グループや論理ボリュームの構成が変更される場合などに更新されることが主であるため、メタデータ更新の頻度は比較的少ない。
【０００８】
一般に、メタデータと通常データは、同じボリューム（ソフトウェアの階層により「物理」の場合も「論理」の場合もありうる）内の離れた場所に配置される。このため、たとえばメタデータが頻繁に更新される場合などでは、メタデータの入出力の影響を受けて通常データの入出力性能が劣化することがある。
【０００９】
Ｔｅｃｈｎｉｃａｌ Ｏｖｅｒｖｉｅｗ Ｓｕｎ ＱＦＳ（サン・マイクロシステムズ社、２００１年８月）に開示されているサン・マイクロシステムズ社のＱＦＳでは、ファイルシステムのメタデータ（ｉノードなど）と通常データを分離して異なるデバイス（ボリューム）に配置することを可能にしている。
【００１０】
一方、メタデータに限らず、２次記憶装置の特性を活かしてデータの最適な配置を実現する方法がある（たとえば、特許文献１参照）。
【００１１】
この場合では、新規にデータを格納する領域を割り当てる場合、２次記憶装置において割り当てるブロックを決定し、それをホストに通知する手段を用意している。
【００１２】
２次記憶装置側でデータの最適配置を行うことが可能であるため、これをメタデータの配置の決定に使用すれば、メタデータを通常データのアクセスに影響を及ぼしにくくなる場所へ配置することも可能である。
【００１３】
【特許文献１】
特開２００１−２７３１７６号公報
【００１４】
【発明が解決しようとする課題】
ところが、上記のような論理ボリュームによるボリューム管理技術では、次のような問題点があることが本発明者により見い出された。
【００１５】
計算機システムにおいて、論理ボリュームを使用する場合、オペレーティング・システムは、ボリューム・グループ管理用メタデータを読み出し、その情報に基づき、論理ボリュームを使用可能にするための処理（ボリューム・グループ有効化処理）を実施する。
【００１６】
ボリューム・グループ管理用メタデータは、各物理ボリュームに格納されているため、物理ボリュームの数が多いほど、論理ボリュームが使用可能になるまでの時間が増える。複数のホストでディスク装置を共有した高信頼化システムを構成している場合、前記の増加はシステム切り換え時間の増加につながる。このため、ボリューム・グループ管理用メタデータの読み出しを高速化することが課題となる。
【００１７】
ファイルシステムのメタデータと通常データとを分離して異なるデバイスに配置する場合、１つのファイルシステムに対して、メタデータ専用のボリュームと、通常データ専用のボリュームを用いる構成が可能である。
【００１８】
そのような構成をとることにより、通常データの入出力においてメタデータ更新の影響を受けないようにしている。この方法では、それぞれのボリュームは、メタデータまたは通常データの専用ボリュームであり、障害などによりどちらかのボリュームに対するアクセスが不能になった場合に、ファイルシステム上のデータの一部のみならず全部の読み出しが困難になることが課題である。
【００１９】
また、２次記憶装置の特性を活かしてデータの最適な配置を実現する場合には、２次記憶装置側でボリューム上のデータを配置する場所を決定している。この方法をメタデータに対して適用する場合の課題は、格納場所を決定しようとしているデータが、メタデータか否かを２次記憶装置側に通知する必要がある点である。
【００２０】
本発明の目的は、メタデータを、物理ボリュームの数よりも少ない数の物理ボリュームに一括化して配置することにより、メタデータの読み出しを高速化し、ホスト切り換えに伴う共有論理ボリュームの切り換えを高速化することのできるメタデータ配置方法、プログラムおよびディスク装置を提供することにある。
【００２１】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【００２２】
【課題を解決するための手段】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
（１）１つ以上の計算機と、複数の物理的または論理的な２次記憶装置とからなり、該計算機のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）は、複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムによるメタデータ配置方法であって、該論理的な記憶装置として管理するメタデータの複製を、第１の領域を有する物理的、または論理的な２次記憶装置の数よりも少ない数の物理的、または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置するステップを有するものである。
【００２３】
また、本願のその他の発明の概要を簡単に示す。
（２）複数の計算機と、複数の物理的または論理的な２次記憶装置とからなり、該計算機のＯＳは、複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムによるメタデータ配置方法であって、論理的な記憶装置として管理するためのメタデータの複製を、第１の領域を有する物理的または論理的な２次記憶装置の数よりも少ない数の物理的または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置するステップを有し、複数の計算機は複数の物理的または論理的な２次記憶装置を共有し、複数の計算機のうち、第１の計算機が不正な状態になると第２の計算機が第１の計算機の処理を引き継ぐ際に、第２の領域に配置されたメタデータの複製を読み出すものである。
（３）１つ以上の計算機と複数の物理的または論理的な２次記憶装置からなり、該計算機のＯＳは、複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の領域に配置する機能とを有する計算機システムによるメタデータ配置方法であって、該領域が２次記憶装置のキャッシュメモリに常駐化するよう設定されているものである。
（４）計算機システムに実行させるプログラムであり、該計算機システムは、１つ以上の計算機と、複数の物理的または論理的な２次記憶装置とからなり、該計算機のＯＳは、複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムに、論理的な記憶装置として管理するメタデータの複製を、第１の領域を有する物理的、または論理的な２次記憶装置の数よりも少ない数の物理的、または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置する手順を実行させるものである。
（５）計算機システムに実行させるプログラムであり、該計算機システムは、複数の計算機と、複数の物理的または論理的な２次記憶装置とからなり、該計算機のＯＳは、複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムに、論理的な記憶装置として管理するためのメタデータの複製を、第１の領域を有する物理的または論理的な２次記憶装置の数よりも少ない数の物理的または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置する手順を実行させ、複数の計算機は複数の物理的または論理的な２次記憶装置を共有し、複数の計算機のうち、第１の計算機が不正な状態になると第２の計算機が第１の計算機の処理を引き継ぐ際に、第２の領域に配置されたメタデータの複製を読み出すものである。
（６）１つ以上の物理的な２次記憶装置からなるディスク装置であって、物理的な２次記憶装置を統合して１つ以上の論理的な２次記憶装置を提供する機能を有し、１つ以上の論理的な２次記憶装置の所定の領域を常駐させるキャッシュメモリを備えたものである。
【００２４】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。
【００２５】
（実施の形態１）
図１は、本発明の実施の形態１による計算システムの構成図、図２は、図１の計算システムにおける物理ボリュームに存在する論理ボリューム管理用のメタデータの一例を示した説明図、図３は、図１の計算システムにおけるボリューム・グループ構成管理テーブルの構成例を示した図、図４は、図１の計算システムにおける一括化メタデータ領域管理テーブルの一例を示す構成図、図５は、計算システムにおける一括化メタデータ配置の概要を示した説明図、図６は、図１の計算機システムにおけるボリューム・グループ有効化処理のフローチャート、図７は、図１の計算機システムにおける一括化メタデータ読み出し機構のフローチャート、図８は、図１の計算機システムによる一括化メタデータ書き込み機構のフローチャートである。
【００２６】
本実施の形態において、計算機システムは、図１に示すように、ホスト（計算機）１０１，１０２から構成されている。これらホスト１０１，１０２は、ネットワーク１０３により相互に接続されており、物理ボリューム１０４を共有している。
【００２７】
ここで述べる物理ボリュームは、ホスト１０１，１０２から見て「物理ボリューム」として見えるものである。それが単体ディスク装置か、ディスクアレイ装置かは問題ではない。また、ディスク装置側で論理的にディスク装置として見せているものでも構わない。
【００２８】
ホスト１０１，１０２では、様々なアプリケーション１０５やオペレーティング・システム（ＯＳ）などシステムソフトウェアの一部として論理ボリューム・マネージャ１０６が動作している。論理ボリューム・マネージャ１０６は、アプリケーション１０５などからの論理ボリュームに対するアクセスを物理ボリュームへのアクセスに変換している。
【００２９】
また、ホスト１０１，１０２は、ネットワーク１０３を使って相互で通信し、ホットスタンバイ構成をとり、現用ホスト１０１に障害が発生すると、もう一方の待機ホスト１０２に切り換えて、アプリケーションの処理などを継続することができる。
【００３０】
本実施の形態では、論理ボリューム・マネージャ１０６に、ボリューム・グループ有効化機能１１１と一括化メタデータ読み出し機構１１２、一括化メタデータ書き込み機能１１３、ボリューム・グループ構成管理テーブル１１４、および一括化メタデータ領域管理テーブル１１５を追加することにより、ホスト切り換えに伴う、論理ボリューム切り換えを高速化する機能を有している。
【００３１】
図２は、物理ボリュームに存在する論理ボリューム管理用のメタデータ２０１の例を示した説明図である。
【００３２】
メタデータ２０１は、物理ボリュームの先頭から物理ボリューム管理用領域２０２、ボリューム・グループ・ステータス領域２０３、ボリューム・グループ・ディスクリプタ領域２０４などに区別される。
【００３３】
物理ボリューム管理用領域２０２には、物理ボリュームの識別子や不良セクタの情報など、物理ボリュームに閉じた情報を保持する。ボリューム・グループ・ステータス領域２０３は、ボリューム・グループを構成する全物理ボリュームの領域の状態を保持する。また、ボリューム・グループ・ディスクリプタ領域２０４は、ボリューム・グループの識別子や論理−物理のマッピングの情報を保持する。
【００３４】
なお、物理ボリューム管理用領域２０２の物理ボリュームの識別子は、ＯＳが物理ボリュームを一意に識別し、物理ボリュームの物理的あるいは論理的な接続場所を特定（構成認識）するために用いる。接続場所が特定された物理ボリュームは、ＯＳの管理する構成テーブルに登録され、ＯＳがその物理ボリュームに正しくアクセスすることが可能になる。もちろん、物理ボリュームを識別する手段は、その物理ボリュームが一意に識別できればどのような手段でも構わない。
【００３５】
通常、この構成認識処理はシステム起動時に行われるが、システム起動時でなくてもよく、少なくともホスト計算機の切り替えが発生する前に実行されていればよい。ホスト計算機または物理ボリュームなどに不揮発メモリが搭載され、それにテーブルが保持されていれば、計算機のリブートごとに構成認識処理を実行する必要もない。
【００３６】
構成認識処理の概要は次のようになる。
【００３７】
ホスト計算機１０１および１０２は、接続されている各物理ボリューム１０４の物理ボリューム識別子を物理ボリューム１０４から読み出し、その物理ボリュームの論理的または物理的な接続場所を関連付け、ＯＳが管理する構成テーブルに登録する。ただし、システム運用中に、装置の電源投入や装置接続場所の変更などにより、起動当初の構成と変更が生じた場合は、構成認識処理を再度実行し、ＯＳの管理する構成テーブルを更新する必要がある。
【００３８】
図３は、ボリューム・グループ構成管理テーブル１１４の構成例を示した図である。
【００３９】
このボリューム・グループ構成管理テーブル１１４では、ボリューム・グループを構成する物理ボリュームにおいて、一括化メタデータが有効か無効かを表している。
【００４０】
ボリューム・グループ名３０１のカラムには、本計算機システムにおいて定義されるボリューム・グループ名が示されている。カラム３０２にはそのボリューム・グループを構成する物理ボリューム名が示されている。
【００４１】
そのボリューム・グループにおいて一括化メタデータが有効になっているか、無効になっているかをカラム３０３に示している。たとえばボリューム・グループＶＧ１は、物理ボリューム１および２から構成され、一括化メタデータが有効であり、メタデータの一括化が行われていることが示されている。
【００４２】
図４は、一括化メタデータ領域管理テーブル１１５の構成例を示す図である。
【００４３】
この一括化メタデータ領域管理テーブル１１５には、図３のボリューム・グループ構成管理テーブルにおいて、一括化メタデータが有効であると表示されている物理ボリュームの、一括化メタデータが格納されている場所を示している。
【００４４】
カラム４０１は物理ボリューム名を表し、その物理ボリュームの一括化メタデータがどの物理ボリュームに格納されているかをカラム４０２で表している。カラム４０３は、一括化メタデータの格納場所の開始セクタ番号を保持し、カラム４０４はそのメタデータのサイズ（セクタ数）を保持している。これにより、一括化メタデータが有効になっている物理ボリュームにおいて、その一括化メタデータの格納場所を明らかにすることができる。
【００４５】
図５は、本方式における一括化メタデータ配置の概要を示した図である。ホスト１０２に他のホストと共有される、ｎ＋１台の物理ボリューム１０４が接続されている例である。
【００４６】
いずれの共有物理ボリューム１０４も、それぞれの記憶領域（第１の領域）５１１〜５１４の先頭に論理ボリュームを管理するためのメタデータ１〜ｎを保持している。このとき、一括化メタデータ領域管理テーブル１１５において、物理ボリューム１〜ｎがいずれも一括化メタデータが有効になっており、一括化メタデータの保存先が物理ボリューム０である例を図示している。一括化メタデータの記憶領域（第２の領域）５１５の保存位置は任意の位置でもかまわないが、読み出しの効率を考えると、連続領域に配置することが有利である。
【００４７】
図に示すように一括化メタデータが有効になっている場合、一括化メタデータとしては、元の物理ボリュームの先頭に配置されているメタデータ１〜ｎの複製を使用する。これにより、たとえ物理ボリューム０に障害が発生し、一括化メタデータの読み出しが不可能になった場合でも、各物理ボリュームの先頭のメタデータ１〜ｎを読み込むことによって、ボリューム・グループの有効化処理を続行することが可能になる。
【００４８】
図６はボリューム・グループ有効化処理のフローチャートである。図示していないが、本処理はホットスタンバイ構成をとっているホスト計算機を制御するソフトウェアあるいはハードウェアにより、現用ホスト計算機で障害が発生し、待機ホスト計算機への切り替えが必要と判断された場合に、実行される処理である。
【００４９】
まず、ホスト切り替えに伴い、待機側において有効化すべきボリューム・グループを評価する（ステップＳ６０１）。この評価自体は、システム切り替えを司るアプリケーションなどが行う処理である。
【００５０】
評価後、論理ボリューム・マネージャが、有効化すべきボリューム・グループの情報を受け取り、実際のボリューム・グループ有効化処理を実施する。
【００５１】
このとき、そのボリューム・グループの一括化メタデータが有効になっているか否かを、ボリューム・グループ構成管理テーブル１１４で調査する（ステップＳ６０２）。
【００５２】
一括化メタデータ有効であった場合は、一括化メタデータ読み出し処理を実行する（ステップＳ６０３）。また、ステップＳ６０２の処理において、無効であれば、各物理ボリュームの先頭から物理ボリューム・メタデータの読み出しを行う。
【００５３】
図７は、一括化メタデータ読み出し機構のフローチャートである。
【００５４】
一括化メタデータ領域管理テーブル１１５を参照し、一括化メタデータを保持する物理ボリュームを特定し、読み出すべきセクタを決定し（ステップＳ７０１）、実際の一括化メタデータの読み出しを行う（ステップＳ７０２）。
【００５５】
その後、読み出した一括化メタデータを利用し、ボリューム・グループの有効化が可能かどうかを評価する（ステップＳ７０３）。評価自体は従来通りの基準に基づいて行ったり、その物理ボリュームがレディ状態かどうかを検査することで行えばよい。また、読み出した一括化メタデータの物理ボリューム識別子を使って、あらかじめ構成認識時に作成している、物理ボリュームとその論理的または物理的な接続場所を関連付けを記した構成テーブルに基づき、読み出した一括化メタデータに対応する物理ボリュームの論理的あるいは物理的な接続場所を特定する処理も行う。ここで可能と判断されれば、ボリューム・グループを有効化し（ステップ７０４）、判断できなければそのまま処理を終える。
【００５６】
図８は、一括化メタデータ書き込み機構のフローチャートである。
【００５７】
メタデータを更新する場合、通常通り、物理ボリューム先頭のメタデータの更新を行う（ステップＳ８０１）。
【００５８】
そして、そのボリューム・グループの一括化メタデータが有効になっているか否かを、ボリューム・グループ構成管理テーブル１１４で調査する（ステップＳ８０２）。一括化メタデータ有効であった場合は、一括化メタデータの更新処理を実行する（ステップＳ８０３）。無効であれば、そのまま処理を終える。
【００５９】
それにより、本実施の形態によれば、ホスト切り替え時の論理ボリューム１０４を使用可能にするための処理（ボリューム・グループ有効化処理）において必要な、各物理ボリュームのメタデータ読み出しを、一括化メタデータから行うことによって高速化することができる。
【００６０】
また、一括化メタデータを利用するケースでも、各物理ボリューム１０４に配置されているメタデータも使えるようにするため、一括化メタデータの読み出しが不可能になった場合でも、特別な処理を行うことなくボリューム・グループ有効化処理を可能にすることができる。
【００６１】
（実施の形態２）
図９は、本発明の実施の形態２による計算システムにおける一括化メタデータ配置の概要を示した説明図、図１０は、図９の計算システムにおけるキャッシュ常駐化登録機構のフローチャートである。
【００６２】
本実施の形態２において、図９は計算機システム、および一括化メタデータ配置の概要を示した図である。前記実施の形態１の図５との違いは、ディスク・キャッシュ９０１を明記している点と、論理ボリューム内にディスク・キャッシュ常駐化登録機構９０２がある点である。
【００６３】
ディスク・キャッシュ９０１は、ホスト１０２からその存在は意識されずに、ホスト１０２からの物理ボリュームに対する入出力の際、物理ボリューム１０４を構成する物理的なメディアに対する入出力が効率よく行われる目的で使用される。
【００６４】
この物理ボリューム１０４は、物理ボリューム１０４の任意のセクタをディスク・キャッシュ９０１内に常駐化させることが可能なインタフェースをホスト１０２に提供しているものとする。
【００６５】
ディスク・キャッシュ９０１に常駐化されるように設定されたセクタに対する入出力要求は、一旦ディスク・キャッシュ９０１内にデータが格納されれば、以降はディスク・キャッシュ９０１への入出力で処理が完結する。
【００６６】
本実施の形態２では、一括化メタデータを有効にするまでの処理は、前記実施の形態１と同様である。異なる点は、物理ボリューム０の、一括化メタデータを格納している領域を、ディスク・キャッシュ常駐化登録機構９０２により、常駐化設定する点である。
【００６７】
一括化メタデータを格納する領域が常駐化設定されることにより、ホットスタンバイ構成の論理ボリューム引き継ぎにおけるメタデータの読み出しが、より一層高速に処理でき、それによって高速な引き継ぎが可能になる。
【００６８】
図１０は、キャッシュ常駐化登録機構９０２のフローチャートである。
【００６９】
まず、ディスク・キャッシュ常駐化登録が可能か否かを評価する（ステップＳ１００１）。この評価は、常駐化登録されたエントリ数や領域のサイズが、制限を越えていないことを確認するためのものである。
【００７０】
登録不可能であればそのまま処理を中止する。また、登録可能であれば、一括化メタデータ領域管理テーブル１１５に基づき、一括化メタデータを保持する領域のディスク・キャッシュ常駐化登録を行う（ステップＳ１００１）。
【００７１】
それにより、本実施の形態２においては、前記実施の形態１においてメタデータを一括化した効果に加え、ホスト１０２が決めた一括化メタデータの格納場所をディスク・キャッシュ９０１に常駐化させることにより、より高速なメタデータ読み出しを可能にし、ホスト切り替え時の論理ボリュームを使用可能にするための処理をより高速化することができる。
【００７２】
また、ホスト１０２側は、本実施の形態２のようなケースでは、メタデータを高速に読み出すことが有効であることを知っているため、その目的でディスク・キャッシュ９０１を効率的に使用できるという効果もある。
【００７３】
（実施の形態３）
図１１は、本発明の実施の形態３による計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【００７４】
本実施の形態３において、図１１は計算機システム、および一括化メタデータ配置の概要を示した図である。前記実施の形態２の図９との違いは、各物理ボリューム１０４で、図９におけるディスク・キャッシュ９０１と同様のディスク・キャッシュ１１０１を明記している点と、論理ボリューム・マネージャ１０６で一括化メタデータ領域管理テーブルを持たない点、それに伴って一括化メタデータも持たない点である。
【００７５】
本実施の形態３では、ホスト１０２側で物理ボリューム０〜ｎの先頭にあるメタデータ領域０からｎを、それぞれディスク・キャッシュ１１０１に常駐化登録することによって、一括化メタデータを用いること無しに、メタデータ読み出の高速化、およびホスト切り替え時の論理ボリュームを使用可能にする処理の高速化を実現できる。
【００７６】
このとき論理ボリューム・マネージャ１０６におけるディスク・キャッシュ常駐化登録機構１１０２は、図１０のステップＳ１００２で、一括化メタデータ領域管理テーブルに基づき、ディスク・キャッシュ常駐化登録をする代わりに、各物理ボリュームにおけるメタデータ０〜ｎの記憶領域５１１〜５１４をディスク・キャッシュ１１０１に登録する。
【００７７】
それにより、本実施の形態３では、一括化メタデータを使用せずとも、各物理ボリューム１０４のメタデータ領域をディスク・キャッシュ１１０１に常駐化させることにより、一括化メタデータを用いずに、より高速なメタデータ読み出しを可能にし、ホスト切り替え時の論理ボリュームを使用可能にするための処理をより高速化することができる。
【００７８】
（実施の形態４）
図１２は、本発明の実施の形態４による計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【００７９】
本実施の形態４において、図１２は計算機システム、および一括化メタデータ配置の概要を示した図である。ホスト１０２に接続されているディスク装置は、ディスク・コントローラ１２３２、ディスク・キャッシュ１２３３、スイッチ１２３４、真に物理的なストレージからなる。
【００８０】
本ディスク装置では、ディスク・コントローラ１２３２が、ホストに対して、真に物理的なストレージを論理的に再構成した形で、物理ボリューム１２０１として見せている。
【００８１】
論理ボリュームを実現するために使用されるメタデータは、物理ボリュームの先頭部分に配置されることが多い。そのため、本実施例では、ディスク・コントローラに、物理ボリュームにおける先頭領域のキャッシュ常駐化機構１２３５を用意して、各物理ボリュームにおける先頭領域１２１１をあらかじめ、ディスク・キャッシュ１２３３に常駐するように設定しておく。
【００８２】
それにより、本実施の形態４においては、ホスト１０２側からキャッシュ常駐領域を指示せずとも、ディスク装置側で各物理ボリューム１２０１の先頭領域１２１１をディスク・キャッシュ１２３３に常駐化させることにより、より高速なメタデータ読み出しを可能にし、ホスト切り替え時の論理ボリュームを使用可能にするための処理をより高速化することができる。
【００８３】
以上、本発明者によってなされた発明を発明の実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【００８４】
【発明の効果】
本願によって開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば、以下のとおりである。
【００８５】
（１）論理ボリュームを使用するために必要なメタデータの読み出しを高速化することができる。
【００８６】
（２）また、上記（１）により、複数の計算機を利用したホットスタンバイ構成において、システム切り替えを高速化することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態１による計算システムの構成図である。
【図２】図１の計算システムにおける物理ボリュームに存在する論理ボリューム管理用のメタデータの一例を示した説明図である。
【図３】図１の計算システムにおけるボリューム・グループ構成管理テーブルの構成例を示した図である。
【図４】図１の計算システムにおける一括化メタデータ領域管理テーブルの一例を示す構成図である。
【図５】計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【図６】図１の計算機システムにおけるボリューム・グループ有効化処理のフローチャートである。
【図７】図１の計算機システムにおける一括化メタデータ読み出し機構のフローチャートである。
【図８】図１の計算機システムによる一括化メタデータ書き込み機構のフローチャートである。
【図９】本発明の実施の形態２による計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【図１０】図９の計算システムにおけるキャッシュ常駐化登録機構のフローチャートである。
【図１１】本発明の実施の形態３による計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【図１２】本発明の実施の形態４による計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【符号の説明】
１０１ ホスト（計算機）
１０２ ホスト（計算機）
１０３ ネットワーク
１０４ 物理ボリューム
１０５ アプリケーション
１０６ 論理ボリューム・マネージャ
１１１ ボリューム・グループ有効化機能
１１２ 一括化メタデータ読み出し機構
１１３ 一括化メタデータ書き込み機能
１１４ ボリューム・グループ構成管理テーブル
１１５ 一括化メタデータ領域管理テーブル
２０１ メタデータ
２０２ 物理ボリューム管理用領域
２０３ ボリューム・グループ・ステータス領域
２０４ ボリューム・グループ・ディスクリプタ領域
２０５ ボリューム・グループ構成管理テーブル
３０１ ボリューム・グループ名
３０２，３０３ カラム
４０１〜４０４ カラム
５１１〜５１４ 記憶領域（第１の領域）
５１５ 記憶領域（第２の領域）
９０１ ディスク・キャッシュ
９０２ ディスク・キャッシュ常駐化登録機構
１１０１ ディスク・キャッシュ
１２３２ ディスク・コントローラ
１２３３ ディスク・キャッシュ
１２３４ スイッチ
１２３５ キャッシュ常駐化機構
ＶＧ１ ボリューム・グループ
【発明の属する技術分野】
本発明は、論理ボリュームによるボリューム管理に関し、特に、論理ボリュームを使用可能にするための時間の短縮に適用して有効な技術に関するものである。
【０００２】
【従来の技術】
多くのオペレーティング・システムにおいて、論理ボリュームによるボリューム管理が主流となっている。論理ボリュームは、１つ以上の物理ボリュームの集合（ボリューム・グループ）から、新たに定義される仮想的なボリュームである。
【０００３】
論理ボリュームにより、ファイルシステムとして使用するボリュームを抽象化し、物理的なボリュームとは切り離された仮想的なストレージを管理することができる。
【０００４】
論理ボリュームを使用することによって、計算機システムでの柔軟なボリューム管理が可能となる。たとえば、論理ボリュームでは、複数のディスク装置を統合して単一のボリュームとして使用できる。その逆に、１つの大きなボリュームを複数の小さなボリュームとして使用できる。
【０００５】
また、ファイルシステムに空きが無くなった場合、ボリューム・グループに物理ボリュームを追加して、論理ボリュームの容量を増やすようなこともできる。
【０００６】
このような論理ボリュームを実現するために、オペレーティング・システムは、論理ボリュームを管理するための情報として、ボリューム・グループ管理用メタデータを物理ボリュームに格納する。
【０００７】
ボリューム・グループ管理用メタデータは、論理―物理のマッピングをはじめ、ボリューム・グループや論理ボリュームの構成に関する情報である。このようなメタデータは、ボリューム・グループや論理ボリュームの構成が変更される場合などに更新されることが主であるため、メタデータ更新の頻度は比較的少ない。
【０００８】
一般に、メタデータと通常データは、同じボリューム（ソフトウェアの階層により「物理」の場合も「論理」の場合もありうる）内の離れた場所に配置される。このため、たとえばメタデータが頻繁に更新される場合などでは、メタデータの入出力の影響を受けて通常データの入出力性能が劣化することがある。
【０００９】
Ｔｅｃｈｎｉｃａｌ Ｏｖｅｒｖｉｅｗ Ｓｕｎ ＱＦＳ（サン・マイクロシステムズ社、２００１年８月）に開示されているサン・マイクロシステムズ社のＱＦＳでは、ファイルシステムのメタデータ（ｉノードなど）と通常データを分離して異なるデバイス（ボリューム）に配置することを可能にしている。
【００１０】
一方、メタデータに限らず、２次記憶装置の特性を活かしてデータの最適な配置を実現する方法がある（たとえば、特許文献１参照）。
【００１１】
この場合では、新規にデータを格納する領域を割り当てる場合、２次記憶装置において割り当てるブロックを決定し、それをホストに通知する手段を用意している。
【００１２】
２次記憶装置側でデータの最適配置を行うことが可能であるため、これをメタデータの配置の決定に使用すれば、メタデータを通常データのアクセスに影響を及ぼしにくくなる場所へ配置することも可能である。
【００１３】
【特許文献１】
特開２００１−２７３１７６号公報
【００１４】
【発明が解決しようとする課題】
ところが、上記のような論理ボリュームによるボリューム管理技術では、次のような問題点があることが本発明者により見い出された。
【００１５】
計算機システムにおいて、論理ボリュームを使用する場合、オペレーティング・システムは、ボリューム・グループ管理用メタデータを読み出し、その情報に基づき、論理ボリュームを使用可能にするための処理（ボリューム・グループ有効化処理）を実施する。
【００１６】
ボリューム・グループ管理用メタデータは、各物理ボリュームに格納されているため、物理ボリュームの数が多いほど、論理ボリュームが使用可能になるまでの時間が増える。複数のホストでディスク装置を共有した高信頼化システムを構成している場合、前記の増加はシステム切り換え時間の増加につながる。このため、ボリューム・グループ管理用メタデータの読み出しを高速化することが課題となる。
【００１７】
ファイルシステムのメタデータと通常データとを分離して異なるデバイスに配置する場合、１つのファイルシステムに対して、メタデータ専用のボリュームと、通常データ専用のボリュームを用いる構成が可能である。
【００１８】
そのような構成をとることにより、通常データの入出力においてメタデータ更新の影響を受けないようにしている。この方法では、それぞれのボリュームは、メタデータまたは通常データの専用ボリュームであり、障害などによりどちらかのボリュームに対するアクセスが不能になった場合に、ファイルシステム上のデータの一部のみならず全部の読み出しが困難になることが課題である。
【００１９】
また、２次記憶装置の特性を活かしてデータの最適な配置を実現する場合には、２次記憶装置側でボリューム上のデータを配置する場所を決定している。この方法をメタデータに対して適用する場合の課題は、格納場所を決定しようとしているデータが、メタデータか否かを２次記憶装置側に通知する必要がある点である。
【００２０】
本発明の目的は、メタデータを、物理ボリュームの数よりも少ない数の物理ボリュームに一括化して配置することにより、メタデータの読み出しを高速化し、ホスト切り換えに伴う共有論理ボリュームの切り換えを高速化することのできるメタデータ配置方法、プログラムおよびディスク装置を提供することにある。
【００２１】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【００２２】
【課題を解決するための手段】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
（１）１つ以上の計算機と、複数の物理的または論理的な２次記憶装置とからなり、該計算機のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）は、複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムによるメタデータ配置方法であって、該論理的な記憶装置として管理するメタデータの複製を、第１の領域を有する物理的、または論理的な２次記憶装置の数よりも少ない数の物理的、または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置するステップを有するものである。
【００２３】
また、本願のその他の発明の概要を簡単に示す。
（２）複数の計算機と、複数の物理的または論理的な２次記憶装置とからなり、該計算機のＯＳは、複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムによるメタデータ配置方法であって、論理的な記憶装置として管理するためのメタデータの複製を、第１の領域を有する物理的または論理的な２次記憶装置の数よりも少ない数の物理的または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置するステップを有し、複数の計算機は複数の物理的または論理的な２次記憶装置を共有し、複数の計算機のうち、第１の計算機が不正な状態になると第２の計算機が第１の計算機の処理を引き継ぐ際に、第２の領域に配置されたメタデータの複製を読み出すものである。
（３）１つ以上の計算機と複数の物理的または論理的な２次記憶装置からなり、該計算機のＯＳは、複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の領域に配置する機能とを有する計算機システムによるメタデータ配置方法であって、該領域が２次記憶装置のキャッシュメモリに常駐化するよう設定されているものである。
（４）計算機システムに実行させるプログラムであり、該計算機システムは、１つ以上の計算機と、複数の物理的または論理的な２次記憶装置とからなり、該計算機のＯＳは、複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムに、論理的な記憶装置として管理するメタデータの複製を、第１の領域を有する物理的、または論理的な２次記憶装置の数よりも少ない数の物理的、または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置する手順を実行させるものである。
（５）計算機システムに実行させるプログラムであり、該計算機システムは、複数の計算機と、複数の物理的または論理的な２次記憶装置とからなり、該計算機のＯＳは、複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムに、論理的な記憶装置として管理するためのメタデータの複製を、第１の領域を有する物理的または論理的な２次記憶装置の数よりも少ない数の物理的または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置する手順を実行させ、複数の計算機は複数の物理的または論理的な２次記憶装置を共有し、複数の計算機のうち、第１の計算機が不正な状態になると第２の計算機が第１の計算機の処理を引き継ぐ際に、第２の領域に配置されたメタデータの複製を読み出すものである。
（６）１つ以上の物理的な２次記憶装置からなるディスク装置であって、物理的な２次記憶装置を統合して１つ以上の論理的な２次記憶装置を提供する機能を有し、１つ以上の論理的な２次記憶装置の所定の領域を常駐させるキャッシュメモリを備えたものである。
【００２４】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。
【００２５】
（実施の形態１）
図１は、本発明の実施の形態１による計算システムの構成図、図２は、図１の計算システムにおける物理ボリュームに存在する論理ボリューム管理用のメタデータの一例を示した説明図、図３は、図１の計算システムにおけるボリューム・グループ構成管理テーブルの構成例を示した図、図４は、図１の計算システムにおける一括化メタデータ領域管理テーブルの一例を示す構成図、図５は、計算システムにおける一括化メタデータ配置の概要を示した説明図、図６は、図１の計算機システムにおけるボリューム・グループ有効化処理のフローチャート、図７は、図１の計算機システムにおける一括化メタデータ読み出し機構のフローチャート、図８は、図１の計算機システムによる一括化メタデータ書き込み機構のフローチャートである。
【００２６】
本実施の形態において、計算機システムは、図１に示すように、ホスト（計算機）１０１，１０２から構成されている。これらホスト１０１，１０２は、ネットワーク１０３により相互に接続されており、物理ボリューム１０４を共有している。
【００２７】
ここで述べる物理ボリュームは、ホスト１０１，１０２から見て「物理ボリューム」として見えるものである。それが単体ディスク装置か、ディスクアレイ装置かは問題ではない。また、ディスク装置側で論理的にディスク装置として見せているものでも構わない。
【００２８】
ホスト１０１，１０２では、様々なアプリケーション１０５やオペレーティング・システム（ＯＳ）などシステムソフトウェアの一部として論理ボリューム・マネージャ１０６が動作している。論理ボリューム・マネージャ１０６は、アプリケーション１０５などからの論理ボリュームに対するアクセスを物理ボリュームへのアクセスに変換している。
【００２９】
また、ホスト１０１，１０２は、ネットワーク１０３を使って相互で通信し、ホットスタンバイ構成をとり、現用ホスト１０１に障害が発生すると、もう一方の待機ホスト１０２に切り換えて、アプリケーションの処理などを継続することができる。
【００３０】
本実施の形態では、論理ボリューム・マネージャ１０６に、ボリューム・グループ有効化機能１１１と一括化メタデータ読み出し機構１１２、一括化メタデータ書き込み機能１１３、ボリューム・グループ構成管理テーブル１１４、および一括化メタデータ領域管理テーブル１１５を追加することにより、ホスト切り換えに伴う、論理ボリューム切り換えを高速化する機能を有している。
【００３１】
図２は、物理ボリュームに存在する論理ボリューム管理用のメタデータ２０１の例を示した説明図である。
【００３２】
メタデータ２０１は、物理ボリュームの先頭から物理ボリューム管理用領域２０２、ボリューム・グループ・ステータス領域２０３、ボリューム・グループ・ディスクリプタ領域２０４などに区別される。
【００３３】
物理ボリューム管理用領域２０２には、物理ボリュームの識別子や不良セクタの情報など、物理ボリュームに閉じた情報を保持する。ボリューム・グループ・ステータス領域２０３は、ボリューム・グループを構成する全物理ボリュームの領域の状態を保持する。また、ボリューム・グループ・ディスクリプタ領域２０４は、ボリューム・グループの識別子や論理−物理のマッピングの情報を保持する。
【００３４】
なお、物理ボリューム管理用領域２０２の物理ボリュームの識別子は、ＯＳが物理ボリュームを一意に識別し、物理ボリュームの物理的あるいは論理的な接続場所を特定（構成認識）するために用いる。接続場所が特定された物理ボリュームは、ＯＳの管理する構成テーブルに登録され、ＯＳがその物理ボリュームに正しくアクセスすることが可能になる。もちろん、物理ボリュームを識別する手段は、その物理ボリュームが一意に識別できればどのような手段でも構わない。
【００３５】
通常、この構成認識処理はシステム起動時に行われるが、システム起動時でなくてもよく、少なくともホスト計算機の切り替えが発生する前に実行されていればよい。ホスト計算機または物理ボリュームなどに不揮発メモリが搭載され、それにテーブルが保持されていれば、計算機のリブートごとに構成認識処理を実行する必要もない。
【００３６】
構成認識処理の概要は次のようになる。
【００３７】
ホスト計算機１０１および１０２は、接続されている各物理ボリューム１０４の物理ボリューム識別子を物理ボリューム１０４から読み出し、その物理ボリュームの論理的または物理的な接続場所を関連付け、ＯＳが管理する構成テーブルに登録する。ただし、システム運用中に、装置の電源投入や装置接続場所の変更などにより、起動当初の構成と変更が生じた場合は、構成認識処理を再度実行し、ＯＳの管理する構成テーブルを更新する必要がある。
【００３８】
図３は、ボリューム・グループ構成管理テーブル１１４の構成例を示した図である。
【００３９】
このボリューム・グループ構成管理テーブル１１４では、ボリューム・グループを構成する物理ボリュームにおいて、一括化メタデータが有効か無効かを表している。
【００４０】
ボリューム・グループ名３０１のカラムには、本計算機システムにおいて定義されるボリューム・グループ名が示されている。カラム３０２にはそのボリューム・グループを構成する物理ボリューム名が示されている。
【００４１】
そのボリューム・グループにおいて一括化メタデータが有効になっているか、無効になっているかをカラム３０３に示している。たとえばボリューム・グループＶＧ１は、物理ボリューム１および２から構成され、一括化メタデータが有効であり、メタデータの一括化が行われていることが示されている。
【００４２】
図４は、一括化メタデータ領域管理テーブル１１５の構成例を示す図である。
【００４３】
この一括化メタデータ領域管理テーブル１１５には、図３のボリューム・グループ構成管理テーブルにおいて、一括化メタデータが有効であると表示されている物理ボリュームの、一括化メタデータが格納されている場所を示している。
【００４４】
カラム４０１は物理ボリューム名を表し、その物理ボリュームの一括化メタデータがどの物理ボリュームに格納されているかをカラム４０２で表している。カラム４０３は、一括化メタデータの格納場所の開始セクタ番号を保持し、カラム４０４はそのメタデータのサイズ（セクタ数）を保持している。これにより、一括化メタデータが有効になっている物理ボリュームにおいて、その一括化メタデータの格納場所を明らかにすることができる。
【００４５】
図５は、本方式における一括化メタデータ配置の概要を示した図である。ホスト１０２に他のホストと共有される、ｎ＋１台の物理ボリューム１０４が接続されている例である。
【００４６】
いずれの共有物理ボリューム１０４も、それぞれの記憶領域（第１の領域）５１１〜５１４の先頭に論理ボリュームを管理するためのメタデータ１〜ｎを保持している。このとき、一括化メタデータ領域管理テーブル１１５において、物理ボリューム１〜ｎがいずれも一括化メタデータが有効になっており、一括化メタデータの保存先が物理ボリューム０である例を図示している。一括化メタデータの記憶領域（第２の領域）５１５の保存位置は任意の位置でもかまわないが、読み出しの効率を考えると、連続領域に配置することが有利である。
【００４７】
図に示すように一括化メタデータが有効になっている場合、一括化メタデータとしては、元の物理ボリュームの先頭に配置されているメタデータ１〜ｎの複製を使用する。これにより、たとえ物理ボリューム０に障害が発生し、一括化メタデータの読み出しが不可能になった場合でも、各物理ボリュームの先頭のメタデータ１〜ｎを読み込むことによって、ボリューム・グループの有効化処理を続行することが可能になる。
【００４８】
図６はボリューム・グループ有効化処理のフローチャートである。図示していないが、本処理はホットスタンバイ構成をとっているホスト計算機を制御するソフトウェアあるいはハードウェアにより、現用ホスト計算機で障害が発生し、待機ホスト計算機への切り替えが必要と判断された場合に、実行される処理である。
【００４９】
まず、ホスト切り替えに伴い、待機側において有効化すべきボリューム・グループを評価する（ステップＳ６０１）。この評価自体は、システム切り替えを司るアプリケーションなどが行う処理である。
【００５０】
評価後、論理ボリューム・マネージャが、有効化すべきボリューム・グループの情報を受け取り、実際のボリューム・グループ有効化処理を実施する。
【００５１】
このとき、そのボリューム・グループの一括化メタデータが有効になっているか否かを、ボリューム・グループ構成管理テーブル１１４で調査する（ステップＳ６０２）。
【００５２】
一括化メタデータ有効であった場合は、一括化メタデータ読み出し処理を実行する（ステップＳ６０３）。また、ステップＳ６０２の処理において、無効であれば、各物理ボリュームの先頭から物理ボリューム・メタデータの読み出しを行う。
【００５３】
図７は、一括化メタデータ読み出し機構のフローチャートである。
【００５４】
一括化メタデータ領域管理テーブル１１５を参照し、一括化メタデータを保持する物理ボリュームを特定し、読み出すべきセクタを決定し（ステップＳ７０１）、実際の一括化メタデータの読み出しを行う（ステップＳ７０２）。
【００５５】
その後、読み出した一括化メタデータを利用し、ボリューム・グループの有効化が可能かどうかを評価する（ステップＳ７０３）。評価自体は従来通りの基準に基づいて行ったり、その物理ボリュームがレディ状態かどうかを検査することで行えばよい。また、読み出した一括化メタデータの物理ボリューム識別子を使って、あらかじめ構成認識時に作成している、物理ボリュームとその論理的または物理的な接続場所を関連付けを記した構成テーブルに基づき、読み出した一括化メタデータに対応する物理ボリュームの論理的あるいは物理的な接続場所を特定する処理も行う。ここで可能と判断されれば、ボリューム・グループを有効化し（ステップ７０４）、判断できなければそのまま処理を終える。
【００５６】
図８は、一括化メタデータ書き込み機構のフローチャートである。
【００５７】
メタデータを更新する場合、通常通り、物理ボリューム先頭のメタデータの更新を行う（ステップＳ８０１）。
【００５８】
そして、そのボリューム・グループの一括化メタデータが有効になっているか否かを、ボリューム・グループ構成管理テーブル１１４で調査する（ステップＳ８０２）。一括化メタデータ有効であった場合は、一括化メタデータの更新処理を実行する（ステップＳ８０３）。無効であれば、そのまま処理を終える。
【００５９】
それにより、本実施の形態によれば、ホスト切り替え時の論理ボリューム１０４を使用可能にするための処理（ボリューム・グループ有効化処理）において必要な、各物理ボリュームのメタデータ読み出しを、一括化メタデータから行うことによって高速化することができる。
【００６０】
また、一括化メタデータを利用するケースでも、各物理ボリューム１０４に配置されているメタデータも使えるようにするため、一括化メタデータの読み出しが不可能になった場合でも、特別な処理を行うことなくボリューム・グループ有効化処理を可能にすることができる。
【００６１】
（実施の形態２）
図９は、本発明の実施の形態２による計算システムにおける一括化メタデータ配置の概要を示した説明図、図１０は、図９の計算システムにおけるキャッシュ常駐化登録機構のフローチャートである。
【００６２】
本実施の形態２において、図９は計算機システム、および一括化メタデータ配置の概要を示した図である。前記実施の形態１の図５との違いは、ディスク・キャッシュ９０１を明記している点と、論理ボリューム内にディスク・キャッシュ常駐化登録機構９０２がある点である。
【００６３】
ディスク・キャッシュ９０１は、ホスト１０２からその存在は意識されずに、ホスト１０２からの物理ボリュームに対する入出力の際、物理ボリューム１０４を構成する物理的なメディアに対する入出力が効率よく行われる目的で使用される。
【００６４】
この物理ボリューム１０４は、物理ボリューム１０４の任意のセクタをディスク・キャッシュ９０１内に常駐化させることが可能なインタフェースをホスト１０２に提供しているものとする。
【００６５】
ディスク・キャッシュ９０１に常駐化されるように設定されたセクタに対する入出力要求は、一旦ディスク・キャッシュ９０１内にデータが格納されれば、以降はディスク・キャッシュ９０１への入出力で処理が完結する。
【００６６】
本実施の形態２では、一括化メタデータを有効にするまでの処理は、前記実施の形態１と同様である。異なる点は、物理ボリューム０の、一括化メタデータを格納している領域を、ディスク・キャッシュ常駐化登録機構９０２により、常駐化設定する点である。
【００６７】
一括化メタデータを格納する領域が常駐化設定されることにより、ホットスタンバイ構成の論理ボリューム引き継ぎにおけるメタデータの読み出しが、より一層高速に処理でき、それによって高速な引き継ぎが可能になる。
【００６８】
図１０は、キャッシュ常駐化登録機構９０２のフローチャートである。
【００６９】
まず、ディスク・キャッシュ常駐化登録が可能か否かを評価する（ステップＳ１００１）。この評価は、常駐化登録されたエントリ数や領域のサイズが、制限を越えていないことを確認するためのものである。
【００７０】
登録不可能であればそのまま処理を中止する。また、登録可能であれば、一括化メタデータ領域管理テーブル１１５に基づき、一括化メタデータを保持する領域のディスク・キャッシュ常駐化登録を行う（ステップＳ１００１）。
【００７１】
それにより、本実施の形態２においては、前記実施の形態１においてメタデータを一括化した効果に加え、ホスト１０２が決めた一括化メタデータの格納場所をディスク・キャッシュ９０１に常駐化させることにより、より高速なメタデータ読み出しを可能にし、ホスト切り替え時の論理ボリュームを使用可能にするための処理をより高速化することができる。
【００７２】
また、ホスト１０２側は、本実施の形態２のようなケースでは、メタデータを高速に読み出すことが有効であることを知っているため、その目的でディスク・キャッシュ９０１を効率的に使用できるという効果もある。
【００７３】
（実施の形態３）
図１１は、本発明の実施の形態３による計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【００７４】
本実施の形態３において、図１１は計算機システム、および一括化メタデータ配置の概要を示した図である。前記実施の形態２の図９との違いは、各物理ボリューム１０４で、図９におけるディスク・キャッシュ９０１と同様のディスク・キャッシュ１１０１を明記している点と、論理ボリューム・マネージャ１０６で一括化メタデータ領域管理テーブルを持たない点、それに伴って一括化メタデータも持たない点である。
【００７５】
本実施の形態３では、ホスト１０２側で物理ボリューム０〜ｎの先頭にあるメタデータ領域０からｎを、それぞれディスク・キャッシュ１１０１に常駐化登録することによって、一括化メタデータを用いること無しに、メタデータ読み出の高速化、およびホスト切り替え時の論理ボリュームを使用可能にする処理の高速化を実現できる。
【００７６】
このとき論理ボリューム・マネージャ１０６におけるディスク・キャッシュ常駐化登録機構１１０２は、図１０のステップＳ１００２で、一括化メタデータ領域管理テーブルに基づき、ディスク・キャッシュ常駐化登録をする代わりに、各物理ボリュームにおけるメタデータ０〜ｎの記憶領域５１１〜５１４をディスク・キャッシュ１１０１に登録する。
【００７７】
それにより、本実施の形態３では、一括化メタデータを使用せずとも、各物理ボリューム１０４のメタデータ領域をディスク・キャッシュ１１０１に常駐化させることにより、一括化メタデータを用いずに、より高速なメタデータ読み出しを可能にし、ホスト切り替え時の論理ボリュームを使用可能にするための処理をより高速化することができる。
【００７８】
（実施の形態４）
図１２は、本発明の実施の形態４による計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【００７９】
本実施の形態４において、図１２は計算機システム、および一括化メタデータ配置の概要を示した図である。ホスト１０２に接続されているディスク装置は、ディスク・コントローラ１２３２、ディスク・キャッシュ１２３３、スイッチ１２３４、真に物理的なストレージからなる。
【００８０】
本ディスク装置では、ディスク・コントローラ１２３２が、ホストに対して、真に物理的なストレージを論理的に再構成した形で、物理ボリューム１２０１として見せている。
【００８１】
論理ボリュームを実現するために使用されるメタデータは、物理ボリュームの先頭部分に配置されることが多い。そのため、本実施例では、ディスク・コントローラに、物理ボリュームにおける先頭領域のキャッシュ常駐化機構１２３５を用意して、各物理ボリュームにおける先頭領域１２１１をあらかじめ、ディスク・キャッシュ１２３３に常駐するように設定しておく。
【００８２】
それにより、本実施の形態４においては、ホスト１０２側からキャッシュ常駐領域を指示せずとも、ディスク装置側で各物理ボリューム１２０１の先頭領域１２１１をディスク・キャッシュ１２３３に常駐化させることにより、より高速なメタデータ読み出しを可能にし、ホスト切り替え時の論理ボリュームを使用可能にするための処理をより高速化することができる。
【００８３】
以上、本発明者によってなされた発明を発明の実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【００８４】
【発明の効果】
本願によって開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば、以下のとおりである。
【００８５】
（１）論理ボリュームを使用するために必要なメタデータの読み出しを高速化することができる。
【００８６】
（２）また、上記（１）により、複数の計算機を利用したホットスタンバイ構成において、システム切り替えを高速化することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態１による計算システムの構成図である。
【図２】図１の計算システムにおける物理ボリュームに存在する論理ボリューム管理用のメタデータの一例を示した説明図である。
【図３】図１の計算システムにおけるボリューム・グループ構成管理テーブルの構成例を示した図である。
【図４】図１の計算システムにおける一括化メタデータ領域管理テーブルの一例を示す構成図である。
【図５】計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【図６】図１の計算機システムにおけるボリューム・グループ有効化処理のフローチャートである。
【図７】図１の計算機システムにおける一括化メタデータ読み出し機構のフローチャートである。
【図８】図１の計算機システムによる一括化メタデータ書き込み機構のフローチャートである。
【図９】本発明の実施の形態２による計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【図１０】図９の計算システムにおけるキャッシュ常駐化登録機構のフローチャートである。
【図１１】本発明の実施の形態３による計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【図１２】本発明の実施の形態４による計算システムにおける一括化メタデータ配置の概要を示した説明図である。
【符号の説明】
１０１ ホスト（計算機）
１０２ ホスト（計算機）
１０３ ネットワーク
１０４ 物理ボリューム
１０５ アプリケーション
１０６ 論理ボリューム・マネージャ
１１１ ボリューム・グループ有効化機能
１１２ 一括化メタデータ読み出し機構
１１３ 一括化メタデータ書き込み機能
１１４ ボリューム・グループ構成管理テーブル
１１５ 一括化メタデータ領域管理テーブル
２０１ メタデータ
２０２ 物理ボリューム管理用領域
２０３ ボリューム・グループ・ステータス領域
２０４ ボリューム・グループ・ディスクリプタ領域
２０５ ボリューム・グループ構成管理テーブル
３０１ ボリューム・グループ名
３０２，３０３ カラム
４０１〜４０４ カラム
５１１〜５１４ 記憶領域（第１の領域）
５１５ 記憶領域（第２の領域）
９０１ ディスク・キャッシュ
９０２ ディスク・キャッシュ常駐化登録機構
１１０１ ディスク・キャッシュ
１２３２ ディスク・コントローラ
１２３３ ディスク・キャッシュ
１２３４ スイッチ
１２３５ キャッシュ常駐化機構
ＶＧ１ ボリューム・グループ
Claims (8)
- １つ以上の計算機と、複数の物理的または論理的な２次記憶装置とからなり、前記計算機のＯＳは、前記複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、前記論理的な記憶装置として管理するためにメタデータを前記複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムによるメタデータ配置方法であって、
前記論理的な記憶装置として管理するメタデータの複製を、第１の領域を有する物理的、または論理的な２次記憶装置の数よりも少ない数の物理的、または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置するステップを有することを特徴とするメタデータ配置方法。 - 請求項１記載のメタデータ配置方法において、
前記所定の条件が、前記２次記憶装置において、複数のメタデータの複製が隣り合うように配置する条件であることを特徴とするメタデータ配置方法。 - 請求項１または２記載のメタデータ配置方法において、
前記所定の条件が、前記２次記憶装置のキャッシュメモリに常駐化するよう設定されている条件であることを特徴とするメタデータ配置方法。 - 複数の計算機と、複数の物理的または論理的な２次記憶装置とからなり、前記計算機のＯＳは、前記複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、前記論理的な記憶装置として管理するためにメタデータを前記複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムによるメタデータ配置方法であって、
前記論理的な記憶装置として管理するためのメタデータの複製を、第１の領域を有する物理的または論理的な２次記憶装置の数よりも少ない数の物理的または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置するステップを有し、
前記複数の計算機は前記複数の物理的または論理的な２次記憶装置を共有し、前記複数の計算機のうち、第１の計算機が不正な状態になると第２の計算機が前記第１の計算機の処理を引き継ぐ際に、前記第２の領域に配置されたメタデータの複製を読み出すことを特徴とするメタデータ配置方法。 - １つ以上の計算機と複数の物理的または論理的な２次記憶装置からなり、前記計算機のＯＳは、前記複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、前記論理的な記憶装置として管理するためにメタデータを前記複数の物理的または論理的な２次記憶装置上の領域に配置する機能とを有する計算機システムによるメタデータ配置方法であって、
前記領域が前記２次記憶装置のキャッシュメモリに常駐化するよう設定されていることを特徴とするメタデータ配置方法。 - １つ以上の計算機と、複数の物理的または論理的な２次記憶装置とからなり、前記計算機のＯＳは、前記複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、前記論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムに、前記論理的な記憶装置として管理するメタデータの複製を、前記第１の領域を有する物理的、または論理的な２次記憶装置の数よりも少ない数の物理的、または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置する手順を実行させることを特徴とするプログラム。
- 複数の計算機と、複数の物理的または論理的な２次記憶装置とからなり、前記計算機のＯＳは、前記複数の物理的または論理的な２次記憶装置を統合して論理的な記憶装置として管理する機能と、前記論理的な記憶装置として管理するためにメタデータを複数の物理的または論理的な２次記憶装置上の第１の領域に配置する機能とを有する計算機システムに、
前記論理的な記憶装置として管理するためのメタデータの複製を、第１の領域を有する物理的または論理的な２次記憶装置の数よりも少ない数の物理的または論理的な２次記憶装置上の所定の条件を満たす第２の領域に配置する手順を実行させ、
前記複数の計算機は前記複数の物理的または論理的な２次記憶装置を共有し、前記複数の計算機のうち、第１の計算機が不正な状態になると第２の計算機が前記第１の計算機の処理を引き継ぐ際に、前記第２の領域に配置されたメタデータの複製を読み出すことを特徴とするプログラム。 - １つ以上の物理的な２次記憶装置からなるディスク装置であって、前記物理的な２次記憶装置を統合して１つ以上の論理的な２次記憶装置を提供する機能を有し、前記１つ以上の論理的な２次記憶装置の所定の領域を常駐させるキャッシュメモリを備えたことを特徴とするディスク装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003054397A JP2004265110A (ja) | 2003-02-28 | 2003-02-28 | メタデータ配置方法、プログラムおよびディスク装置 |
| US10/641,069 US20040172501A1 (en) | 2003-02-28 | 2003-08-15 | Metadata allocation method in a storage system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003054397A JP2004265110A (ja) | 2003-02-28 | 2003-02-28 | メタデータ配置方法、プログラムおよびディスク装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004265110A true JP2004265110A (ja) | 2004-09-24 |
Family
ID=32905804
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003054397A Pending JP2004265110A (ja) | 2003-02-28 | 2003-02-28 | メタデータ配置方法、プログラムおよびディスク装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20040172501A1 (ja) |
| JP (1) | JP2004265110A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007257317A (ja) * | 2006-03-23 | 2007-10-04 | Hitachi Ltd | 記憶システム及び記憶領域解放方法並びにストレージシステム |
| JP2007305013A (ja) * | 2006-05-15 | 2007-11-22 | Fujitsu Ltd | Ｈｓｍ制御プログラム、ｈｓｍ制御装置、ｈｓｍ制御方法 |
| JP2008084053A (ja) * | 2006-09-28 | 2008-04-10 | Hitachi Ltd | 仮想化システム及び領域割当て制御方法 |
| JP2010186284A (ja) * | 2009-02-12 | 2010-08-26 | Hitachi Ltd | ファイル入出力方法 |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050138011A1 (en) * | 2003-12-23 | 2005-06-23 | Royer Robert J.Jr. | Meta-data storage and access techniques |
| US7617321B2 (en) * | 2004-05-07 | 2009-11-10 | International Business Machines Corporation | File system architecture requiring no direct access to user data from a metadata manager |
| US7444360B2 (en) * | 2004-11-17 | 2008-10-28 | International Business Machines Corporation | Method, system, and program for storing and using metadata in multiple storage locations |
| TW200627277A (en) * | 2005-01-24 | 2006-08-01 | Lite On Technology Corp | OS selection method and computer system utilizing same |
| US20060242380A1 (en) * | 2005-04-20 | 2006-10-26 | Anuja Korgaonkar | Virtually unlimited storage |
| JP4704161B2 (ja) * | 2005-09-13 | 2011-06-15 | 株式会社日立製作所 | ファイルシステムの構築方法 |
| JP4884041B2 (ja) * | 2006-03-15 | 2012-02-22 | 株式会社日立製作所 | 自動拡張可能なボリュームに対して最適なｉ／ｏコマンドを発行するストレージシステム及びその制御方法 |
| US8074020B2 (en) * | 2008-02-13 | 2011-12-06 | International Business Machines Corporation | On-line volume coalesce operation to enable on-line storage subsystem volume consolidation |
| WO2012106923A1 (zh) * | 2011-07-25 | 2012-08-16 | 华为技术有限公司 | 对象调整方法、迁移控制设备、节点设备及存储系统 |
| US9069468B2 (en) | 2011-09-11 | 2015-06-30 | Microsoft Technology Licensing, Llc | Pooled partition layout and representation |
| US9811456B2 (en) * | 2014-11-26 | 2017-11-07 | Advanced Micro Devices, Inc. | Reliable wear-leveling for non-volatile memory and method therefor |
| CN109885551B (zh) * | 2019-01-04 | 2024-03-12 | 平安科技（深圳）有限公司 | 电子装置、元数据处理方法和计算机可读存储介质 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5129088A (en) * | 1987-11-30 | 1992-07-07 | International Business Machines Corporation | Data processing method to create virtual disks from non-contiguous groups of logically contiguous addressable blocks of direct access storage device |
| JP2773424B2 (ja) * | 1990-11-20 | 1998-07-09 | 株式会社日立製作所 | ネットワークシステムおよび接続コンピュータ切替え方法 |
| US5619690A (en) * | 1993-06-21 | 1997-04-08 | Hitachi, Ltd. | Computer system including a computer which requests an access to a logical address in a secondary storage system with specification of a local address in the secondary storage system |
| US5504858A (en) * | 1993-06-29 | 1996-04-02 | Digital Equipment Corporation | Method and apparatus for preserving data integrity in a multiple disk raid organized storage system |
| US5710907A (en) * | 1995-12-22 | 1998-01-20 | Sun Microsystems, Inc. | Hybrid NUMA COMA caching system and methods for selecting between the caching modes |
| US5884098A (en) * | 1996-04-18 | 1999-03-16 | Emc Corporation | RAID controller system utilizing front end and back end caching systems including communication path connecting two caching systems and synchronizing allocation of blocks in caching systems |
| US5897661A (en) * | 1997-02-25 | 1999-04-27 | International Business Machines Corporation | Logical volume manager and method having enhanced update capability with dynamic allocation of storage and minimal storage of metadata information |
| US6487547B1 (en) * | 1999-01-29 | 2002-11-26 | Oracle Corporation | Database appliance comprising hardware and software bundle configured for specific database applications |
| US6438661B1 (en) * | 1999-03-03 | 2002-08-20 | International Business Machines Corporation | Method, system, and program for managing meta data in a storage system and rebuilding lost meta data in cache |
| JP3763992B2 (ja) * | 1999-03-30 | 2006-04-05 | 富士通株式会社 | データ処理装置及び記録媒体 |
| US6553511B1 (en) * | 2000-05-17 | 2003-04-22 | Lsi Logic Corporation | Mass storage data integrity-assuring technique utilizing sequence and revision number metadata |
| US6606629B1 (en) * | 2000-05-17 | 2003-08-12 | Lsi Logic Corporation | Data structures containing sequence and revision number metadata used in mass storage data integrity-assuring technique |
| US6834281B1 (en) * | 2002-03-26 | 2004-12-21 | Veritas Operating Corporation | Method and apparatus to support multi-node direct access to file system data |
| US7032125B2 (en) * | 2002-04-25 | 2006-04-18 | Lsi Logic Corporation | Method for loosely coupling metadata and data in a storage array |
| US7051155B2 (en) * | 2002-08-05 | 2006-05-23 | Sun Microsystems, Inc. | Method and system for striping data to accommodate integrity metadata |
| US7010645B2 (en) * | 2002-12-27 | 2006-03-07 | International Business Machines Corporation | System and method for sequentially staging received data to a write cache in advance of storing the received data |
-
2003
- 2003-02-28 JP JP2003054397A patent/JP2004265110A/ja active Pending
- 2003-08-15 US US10/641,069 patent/US20040172501A1/en not_active Abandoned
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007257317A (ja) * | 2006-03-23 | 2007-10-04 | Hitachi Ltd | 記憶システム及び記憶領域解放方法並びにストレージシステム |
| JP2007305013A (ja) * | 2006-05-15 | 2007-11-22 | Fujitsu Ltd | Ｈｓｍ制御プログラム、ｈｓｍ制御装置、ｈｓｍ制御方法 |
| JP2008084053A (ja) * | 2006-09-28 | 2008-04-10 | Hitachi Ltd | 仮想化システム及び領域割当て制御方法 |
| US8356157B2 (en) | 2006-09-28 | 2013-01-15 | Hitachi, Ltd. | Virtualization system and area allocation control method |
| JP2010186284A (ja) * | 2009-02-12 | 2010-08-26 | Hitachi Ltd | ファイル入出力方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20040172501A1 (en) | 2004-09-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3764237B1 (en) | System startup method and apparatus, electronic device and storage medium | |
| JP6708929B2 (ja) | ストレージ制御装置、ストレージシステムおよびストレージ制御プログラム | |
| JP4464378B2 (ja) | 同一データを纏める事で格納領域を節約する計算機システム、ストレージシステム及びそれらの制御方法 | |
| US7689803B2 (en) | System and method for communication using emulated LUN blocks in storage virtualization environments | |
| JP4199993B2 (ja) | スナップショット取得方法 | |
| US8239648B2 (en) | Reclamation of thin provisioned disk storage | |
| US8204858B2 (en) | Snapshot reset method and apparatus | |
| US20190339896A1 (en) | System for migrating virtual tape volumes between filesystems | |
| JP2004265110A (ja) | メタデータ配置方法、プログラムおよびディスク装置 | |
| US20060047926A1 (en) | Managing multiple snapshot copies of data | |
| JP5207367B2 (ja) | ストレージシステムの消費電力を削減する計算機システム及びその制御方法 | |
| US20060271754A1 (en) | Storage system | |
| US20070061540A1 (en) | Data storage system using segmentable virtual volumes | |
| JP2004110218A (ja) | Ｄｂｍｓ向け仮想ボリューム作成・管理方法 | |
| JP2010211681A (ja) | ストレージ装置及び仮想化装置 | |
| JP2006268534A (ja) | 記憶装置システムの制御技術 | |
| WO2011079787A1 (zh) | 磁盘阵列的实现方法和数据读写方法及装置 | |
| JP2006268139A (ja) | データ複製装置、方法及びプログラム並びに記憶システム | |
| US8140886B2 (en) | Apparatus, system, and method for virtual storage access method volume data set recovery | |
| WO2018076633A1 (zh) | 一种远程数据复制方法、存储设备及存储系统 | |
| JP6197816B2 (ja) | ストレージシステム、ストレージの管理方法、及び、コンピュータ・プログラム | |
| US8566541B2 (en) | Storage system storing electronic modules applied to electronic objects common to several computers, and storage control method for the same | |
| US20080005745A1 (en) | Management server and server system | |
| JP5355603B2 (ja) | ディスクアレイ装置及び論理ボリュームアクセス方法 | |
| JP4390618B2 (ja) | データベース再編成プログラム、データベース再編成方法、及びデータベース再編成装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20040712 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060113 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081216 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090519 |