JPH1031599A - データ記憶システム - Google Patents
データ記憶システムInfo
- Publication number
- JPH1031599A JPH1031599A JP8184383A JP18438396A JPH1031599A JP H1031599 A JPH1031599 A JP H1031599A JP 8184383 A JP8184383 A JP 8184383A JP 18438396 A JP18438396 A JP 18438396A JP H1031599 A JPH1031599 A JP H1031599A
- Authority
- JP
- Japan
- Prior art keywords
- data
- file
- data pool
- pool
- application software
- 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.)
- Withdrawn
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【課題】 ネットワーク上で他のホストのハードディス
ク上にあるファイルにアクセスして、ファイル容量の制
限を超えるような大量のデータを扱うアプリケーション
・ソフトウェアの作成を容易にするとともに、ハードデ
ィスクの容量を超えるような大量のデータを扱うアプリ
ケーション・ソフトウェアにおける取扱いを容易にす
る。 【解決手段】 複数のホスト上にデータプールアクセス
サーバを設け、アプリケーション・ソフトウェアは、こ
のデータプールアクセスサーバを介してそれぞれのデー
タプールアクセスサーバが管理するデータプール上の論
理ファイルにアクセスする。アプリケーション・ソフト
ウェアは、論理ファイルを単位として書き込み又は読み
出しを行う。アプリケーション・ソフトウェアから見た
場合には、論理ファイルがいわば仮想的なファイルとし
て認識される。
ク上にあるファイルにアクセスして、ファイル容量の制
限を超えるような大量のデータを扱うアプリケーション
・ソフトウェアの作成を容易にするとともに、ハードデ
ィスクの容量を超えるような大量のデータを扱うアプリ
ケーション・ソフトウェアにおける取扱いを容易にす
る。 【解決手段】 複数のホスト上にデータプールアクセス
サーバを設け、アプリケーション・ソフトウェアは、こ
のデータプールアクセスサーバを介してそれぞれのデー
タプールアクセスサーバが管理するデータプール上の論
理ファイルにアクセスする。アプリケーション・ソフト
ウェアは、論理ファイルを単位として書き込み又は読み
出しを行う。アプリケーション・ソフトウェアから見た
場合には、論理ファイルがいわば仮想的なファイルとし
て認識される。
Description
【０００１】
【発明の属する技術分野】本発明は、主としてネットワ
ーク上の他のホストの記憶装置に対してデータの書き込
み及び読み出しをする場合に利用されるデータ記憶シス
テムに関する。
ーク上の他のホストの記憶装置に対してデータの書き込
み及び読み出しをする場合に利用されるデータ記憶シス
テムに関する。
【０００２】
【従来の技術】ワークステーション用のオペレーティン
グシステムとして最も代表的なＵＮＩＸでは、一つの物
理ファイルの容量が２ＧＢを超えることができないとい
う制限があり、扱うデータの容量がこの制限を超える場
合には、データを複数のファイルに分割するなどの特別
な処理を行わなければ、このような大きな容量のデータ
を扱うことはできない。大量のデータを処理するアプリ
ケーション・ソフトウェア（以下、「プロセス」ともい
う）をＵＮＩＸ上で動作させるためには、そのアプリケ
ーション・ソフトウェアを作成する際に、データの容量
が２ＧＢを超える場合にどのような処置を施すかという
手続きをプログラム中に記述しておく必要がある。
グシステムとして最も代表的なＵＮＩＸでは、一つの物
理ファイルの容量が２ＧＢを超えることができないとい
う制限があり、扱うデータの容量がこの制限を超える場
合には、データを複数のファイルに分割するなどの特別
な処理を行わなければ、このような大きな容量のデータ
を扱うことはできない。大量のデータを処理するアプリ
ケーション・ソフトウェア（以下、「プロセス」ともい
う）をＵＮＩＸ上で動作させるためには、そのアプリケ
ーション・ソフトウェアを作成する際に、データの容量
が２ＧＢを超える場合にどのような処置を施すかという
手続きをプログラム中に記述しておく必要がある。
【０００３】
【発明が解決しようとする課題】しかしながら、多様な
アプリケーション・ソフトウェアを作成するそのたびご
とに、データの容量がファイル容量の制限を超える場合
にどのような取扱いとするかという複雑な処理を一々プ
ログラミングするのは、プログラマにとって大きな負担
となる。
アプリケーション・ソフトウェアを作成するそのたびご
とに、データの容量がファイル容量の制限を超える場合
にどのような取扱いとするかという複雑な処理を一々プ
ログラミングするのは、プログラマにとって大きな負担
となる。
【０００４】また、複数のホストが接続されたネットワ
ーク上では、通常ＮＦＳ（NetworkFile System ）が利
用されることが多いが、これを用いてあるホストから別
のホストのハードディスクに存在するファイルにアクセ
スする場合には、マウント／アンマウント操作を行う必
要があり、その際、ホスト名、ファイルの所在場所（デ
ィレクトリ名）、ファイル名を意識して使用しなければ
ならない。したがって、アプリケーション・ソフトウェ
アを作成する場合には、これらの点を考慮してプログラ
ミングする必要があり、プログラミング作業が複雑化す
る。
ーク上では、通常ＮＦＳ（NetworkFile System ）が利
用されることが多いが、これを用いてあるホストから別
のホストのハードディスクに存在するファイルにアクセ
スする場合には、マウント／アンマウント操作を行う必
要があり、その際、ホスト名、ファイルの所在場所（デ
ィレクトリ名）、ファイル名を意識して使用しなければ
ならない。したがって、アプリケーション・ソフトウェ
アを作成する場合には、これらの点を考慮してプログラ
ミングする必要があり、プログラミング作業が複雑化す
る。
【０００５】更に、ハードディスクの容量を超えるよう
な大きなデータを扱う場合には、アプリケーション・ソ
フトウェアにおいて、サイクリックファイル等の特別な
機能を設ける必要がある。この場合、一つのファイルに
対して複数のアプリケーション・ソフトウェアがアクセ
スする場合には、そのファイルにアクセスするすべての
プロセスについてこのような機能を取り入れる必要があ
り、各プロセスをプログラミングする際にいわゆる排他
制御等が複雑となる。
な大きなデータを扱う場合には、アプリケーション・ソ
フトウェアにおいて、サイクリックファイル等の特別な
機能を設ける必要がある。この場合、一つのファイルに
対して複数のアプリケーション・ソフトウェアがアクセ
スする場合には、そのファイルにアクセスするすべての
プロセスについてこのような機能を取り入れる必要があ
り、各プロセスをプログラミングする際にいわゆる排他
制御等が複雑となる。
【０００６】本発明は、上記事情に基づいてなされたも
のであり、特に、ネットワーク上で他のホストのハード
ディスク上にあるファイルにアクセスして、ファイル容
量の制限を超えるような大量のデータを扱うアプリケー
ション・ソフトウェアの作成を容易にするとともに、ハ
ードディスクの容量を超えるような大量のデータを扱う
アプリケーション・ソフトウェアにおける取扱いを容易
にするデータ記憶システムを提供することを目的とす
る。
のであり、特に、ネットワーク上で他のホストのハード
ディスク上にあるファイルにアクセスして、ファイル容
量の制限を超えるような大量のデータを扱うアプリケー
ション・ソフトウェアの作成を容易にするとともに、ハ
ードディスクの容量を超えるような大量のデータを扱う
アプリケーション・ソフトウェアにおける取扱いを容易
にするデータ記憶システムを提供することを目的とす
る。
【０００７】
【課題を解決するための手段】上記の課題を解決するた
めの本発明は、データの読み出し及び書き込みを可能と
する記憶媒体と、前記記憶媒体に対し物理ファイルを単
位としてデータの読み出し及び書き込みの動作を制御す
るオペレーティングシステムと、データの格納場所であ
るデータプールを、それが存在するディレクトリ上の位
置、それを構成する前記物理ファイルの容量及びそのデ
ータプールの容量によって定義するデータプール構成フ
ァイルと、アプリケーション・ソフトウェアからの要求
に従って、一つのデータプール内で、前記論理ファイル
を単位として、前記オペレーティングシステムに前記記
録媒体に対するデータの記録及び読み出しを行わせるデ
ータプールアクセスサーバとを具備することを特徴とす
る。
めの本発明は、データの読み出し及び書き込みを可能と
する記憶媒体と、前記記憶媒体に対し物理ファイルを単
位としてデータの読み出し及び書き込みの動作を制御す
るオペレーティングシステムと、データの格納場所であ
るデータプールを、それが存在するディレクトリ上の位
置、それを構成する前記物理ファイルの容量及びそのデ
ータプールの容量によって定義するデータプール構成フ
ァイルと、アプリケーション・ソフトウェアからの要求
に従って、一つのデータプール内で、前記論理ファイル
を単位として、前記オペレーティングシステムに前記記
録媒体に対するデータの記録及び読み出しを行わせるデ
ータプールアクセスサーバとを具備することを特徴とす
る。
【０００８】本発明は、上記より、記憶媒体に書き込み
を行うデータが、そのオペレーティングシステムの物理
ファイルの最大容量（ＵＮＩＸであれば、２ＧＢ）を超
えるものであっても、アプリケーション・ソフトウェア
の側では、論理ファイルを単位としてデータの書き込み
及び読み出しを行うことができるので、例えば２ＧＢご
とにデータの分割等の作業を行う必要がない。
を行うデータが、そのオペレーティングシステムの物理
ファイルの最大容量（ＵＮＩＸであれば、２ＧＢ）を超
えるものであっても、アプリケーション・ソフトウェア
の側では、論理ファイルを単位としてデータの書き込み
及び読み出しを行うことができるので、例えば２ＧＢご
とにデータの分割等の作業を行う必要がない。
【０００９】
【発明の実施の形態】以下に図面を参照して、本発明の
一実施形態について説明する。図１は、従来のデータ記
憶システムと本実施形態のデータ記憶システムの概念を
比較して示した図であり、同図（ａ）が従来のデータ記
憶システム、同図（ｂ）が本実施形態のデータ記憶シス
テムに対応する。
一実施形態について説明する。図１は、従来のデータ記
憶システムと本実施形態のデータ記憶システムの概念を
比較して示した図であり、同図（ａ）が従来のデータ記
憶システム、同図（ｂ）が本実施形態のデータ記憶シス
テムに対応する。
【００１０】従来のデータ記憶システムでは、図１
（ａ）に示すように、あるホスト上のアプリケーション
・ソフトウェアが他のホスト上のファイル（例えばＵＮ
ＩＸのファイルで、物理ファイルという。）にアクセス
する場合は、そのアプリケーション・ソフトウェアがあ
るホストをクライアント、当該ファイルがあるホストを
サーバとして、アプリケーション・ソフトウェアから通
信ネットワークを介して他のホスト上のファイルにアク
セスしていた。また、あるホストのディスク上にあるフ
ァイルにアクセスするために、そのディスクのマウント
操作を行うと、以後、特別にアンマウント操作を行うま
では、そのディスクはマウントされた状態が続く。
（ａ）に示すように、あるホスト上のアプリケーション
・ソフトウェアが他のホスト上のファイル（例えばＵＮ
ＩＸのファイルで、物理ファイルという。）にアクセス
する場合は、そのアプリケーション・ソフトウェアがあ
るホストをクライアント、当該ファイルがあるホストを
サーバとして、アプリケーション・ソフトウェアから通
信ネットワークを介して他のホスト上のファイルにアク
セスしていた。また、あるホストのディスク上にあるフ
ァイルにアクセスするために、そのディスクのマウント
操作を行うと、以後、特別にアンマウント操作を行うま
では、そのディスクはマウントされた状態が続く。
【００１１】これに対して、本実施形態のデータ記憶シ
ステムでは、図１（ｂ）に示すように複数のホスト上に
ソフトウェアであるデータプールアクセスサーバを設
け、アプリケーション・ソフトウェアは、このデータプ
ールアクセスサーバを介してそれぞれのデータプールア
クセスサーバが管理するデータプール上の論理ファイル
にアクセスする。データプールアクセスサーバは、一つ
のデータプールを管理する。データプールアクセスサー
バは、アプリケーション・ソフトウェアからサービスの
オープン要求があったときに起動し、一度起動すると、
サービスのクローズ要求があるまで常駐する。また、デ
ータプールアクセスサーバは、クライアントのアプリケ
ーション・ソフトウェアからサービスのオープン要求が
あったときのみ関連するディスクをマウントし、サービ
スのクローズ要求があるとそのディスクのアンマウント
操作を行う。このため、不要なときまでマウント状態が
持続することが回避され、コンピュータにかかる負荷が
軽減される。
ステムでは、図１（ｂ）に示すように複数のホスト上に
ソフトウェアであるデータプールアクセスサーバを設
け、アプリケーション・ソフトウェアは、このデータプ
ールアクセスサーバを介してそれぞれのデータプールア
クセスサーバが管理するデータプール上の論理ファイル
にアクセスする。データプールアクセスサーバは、一つ
のデータプールを管理する。データプールアクセスサー
バは、アプリケーション・ソフトウェアからサービスの
オープン要求があったときに起動し、一度起動すると、
サービスのクローズ要求があるまで常駐する。また、デ
ータプールアクセスサーバは、クライアントのアプリケ
ーション・ソフトウェアからサービスのオープン要求が
あったときのみ関連するディスクをマウントし、サービ
スのクローズ要求があるとそのディスクのアンマウント
操作を行う。このため、不要なときまでマウント状態が
持続することが回避され、コンピュータにかかる負荷が
軽減される。
【００１２】図１（ｂ）において、物理ファイルは、オ
ペレーティングシステムが管理する一つ一つのファイル
であり、ＵＮＩＸの場合であれば、その容量は最大で２
ＧＢである。従来は、この最大２ＧＢのファイルを単位
として、マウントした他のホストのディスク上にデータ
の書き込み又は読み出しを行う必要があった。すなわ
ち、クライアント側のアプリケーション・ソフトウェア
は、それ自身でアクセスを希望するファイルのオープ
ン、クローズの作業を行なわなければならず、また、デ
ータの書き込みを行っている途中に２ＧＢを超えること
となった場合には、アプリケーション・ソフトウェア自
身がそのデータを適当な容量に分割し、別の新しいファ
イルを作って残りのデータを書き込むという作業を行う
必要があった。したがって、アプリケーション・ソフト
ウェアをプログラミングする際には、これらの点を考慮
してプログラムを作成する必要があった。
ペレーティングシステムが管理する一つ一つのファイル
であり、ＵＮＩＸの場合であれば、その容量は最大で２
ＧＢである。従来は、この最大２ＧＢのファイルを単位
として、マウントした他のホストのディスク上にデータ
の書き込み又は読み出しを行う必要があった。すなわ
ち、クライアント側のアプリケーション・ソフトウェア
は、それ自身でアクセスを希望するファイルのオープ
ン、クローズの作業を行なわなければならず、また、デ
ータの書き込みを行っている途中に２ＧＢを超えること
となった場合には、アプリケーション・ソフトウェア自
身がそのデータを適当な容量に分割し、別の新しいファ
イルを作って残りのデータを書き込むという作業を行う
必要があった。したがって、アプリケーション・ソフト
ウェアをプログラミングする際には、これらの点を考慮
してプログラムを作成する必要があった。
【００１３】これに対し本実施形態では、アプリケーシ
ョン・ソフトウェアは、論理ファイルを単位として他の
ホストのハードディスクに対して書き込み又は読み出し
を行う。ここで、論理ファイルとは、一つ又は複数の物
理ファイルの集合であり、その容量は、１物理ファイル
の容量を単位として、それが属するデータプール全体の
容量まで変化することができる。データプールアクセス
サーバは個々の物理ファイルを管理しており、他のホス
トのアプリケーション・ソフトウェアからそのデータプ
ールアクセスサーバが管理する論理ファイルへのアクセ
スを依頼された場合には、その論理ファイルを構成する
個々の物理ファイルに対する書き込み・読み出しを実行
する。
ョン・ソフトウェアは、論理ファイルを単位として他の
ホストのハードディスクに対して書き込み又は読み出し
を行う。ここで、論理ファイルとは、一つ又は複数の物
理ファイルの集合であり、その容量は、１物理ファイル
の容量を単位として、それが属するデータプール全体の
容量まで変化することができる。データプールアクセス
サーバは個々の物理ファイルを管理しており、他のホス
トのアプリケーション・ソフトウェアからそのデータプ
ールアクセスサーバが管理する論理ファイルへのアクセ
スを依頼された場合には、その論理ファイルを構成する
個々の物理ファイルに対する書き込み・読み出しを実行
する。
【００１４】したがって、アプリケーション・ソフトウ
ェアから見た場合には、論理ファイルがいわば仮想的な
ファイルとして認識される。これにより、容量が２ＧＢ
を超えるデータであっても、その場合のデータの分割等
の処理はデータプールアクセスサーバが自動的にオペレ
ーティングシステムを介して行ってくれるので、アプリ
ケーション・ソフトウェアの側ではそのことを意識する
必要がなく、アプリケーション・ソフトウェアが行わな
ければならない作業が簡素化される。このため、アプリ
ケーション・ソフトウェアのプログラミング作業が簡単
になり、プログラマの負担が軽減され、ひいてはアプリ
ケーション・ソフトウェアの開発コストが低減する。
ェアから見た場合には、論理ファイルがいわば仮想的な
ファイルとして認識される。これにより、容量が２ＧＢ
を超えるデータであっても、その場合のデータの分割等
の処理はデータプールアクセスサーバが自動的にオペレ
ーティングシステムを介して行ってくれるので、アプリ
ケーション・ソフトウェアの側ではそのことを意識する
必要がなく、アプリケーション・ソフトウェアが行わな
ければならない作業が簡素化される。このため、アプリ
ケーション・ソフトウェアのプログラミング作業が簡単
になり、プログラマの負担が軽減され、ひいてはアプリ
ケーション・ソフトウェアの開発コストが低減する。
【００１５】論理ファイルには、「空」、「書き込み
中」、「書き込み済」、「読み出し中」、「読み出し
済」という五つのステータスを与える。「空」は、その
論理ファイルにデータが含まれていない状態を示す。
「書き込み中」は、その論理ファイルがディスク上にデ
ータを書き込んでいる最中であることを示す。「書き込
み済」は、ディスク上でその論理ファイルにデータの書
き込みが終了したことを示す。「読み出し中」は、その
論理ファイルがデータの読み出し中であることを示す。
そして「読み出し済」は、その論理ファイルから既にデ
ータの読み出しが終了していることを示す。このような
ステータスを与えることによって、同一の論理ファイル
に対して複数のアプリケーション・ソフトウェアからア
クセスされる際の排他制御が可能となり、また、そのデ
ータが既に読み出されて別の形態で他の場所に送られて
いるかどうかなどを確認することができる。
中」、「書き込み済」、「読み出し中」、「読み出し
済」という五つのステータスを与える。「空」は、その
論理ファイルにデータが含まれていない状態を示す。
「書き込み中」は、その論理ファイルがディスク上にデ
ータを書き込んでいる最中であることを示す。「書き込
み済」は、ディスク上でその論理ファイルにデータの書
き込みが終了したことを示す。「読み出し中」は、その
論理ファイルがデータの読み出し中であることを示す。
そして「読み出し済」は、その論理ファイルから既にデ
ータの読み出しが終了していることを示す。このような
ステータスを与えることによって、同一の論理ファイル
に対して複数のアプリケーション・ソフトウェアからア
クセスされる際の排他制御が可能となり、また、そのデ
ータが既に読み出されて別の形態で他の場所に送られて
いるかどうかなどを確認することができる。
【００１６】図２は、本実施形態のネットワーク接続さ
れたデータ記憶システムの構成を示す図である。同図で
は３台のホストＡ，Ｂ，Ｃがネットワークに接続されて
いる例を示す。このうち、ホストＢがクライアントマシ
ン、ホストＡ及びＣがサーバマシンである。各ホストに
は、ソケット通信を行うための通信ソフトウェア１０
ａ，１０ｂ，１０ｃが設けられている。サーバーマシン
であるホストＡには、データプールアクセスサーバ１１
ａ1 ，１１ａ2 が搭載されており、同じくサーバマシン
であるホストＣには、データプールアクセスサーバ１１
ｃが搭載されている。それぞれのデータプールアクセス
サーバは、一つのデータプールを管理している。一つの
データプールには、複数の論理ファイルを書き込むこと
ができる。また、各ホストは、それぞれにハードディス
ク１２ａ1 ，１２ａ2 ，１２b ，１２c 1 ，１２c 2 を
有している。図２では、サーバーマシンであるホストＡ
のデータプールアクセスサーバ１１ａ1 はハードディス
ク１２ａ1 をデータプールとして使用し、データプール
アクセスサーバ１１ａ2 はハードディスク１２ａ2 をデ
ータプールとして使用する。また、同じくサーバーマシ
ンであるホストＣのデータプールアクセスサーバ１１ａ
1 はハードディスク１２c 1 及び１２c 2 をデータプー
ルとして使用する。
れたデータ記憶システムの構成を示す図である。同図で
は３台のホストＡ，Ｂ，Ｃがネットワークに接続されて
いる例を示す。このうち、ホストＢがクライアントマシ
ン、ホストＡ及びＣがサーバマシンである。各ホストに
は、ソケット通信を行うための通信ソフトウェア１０
ａ，１０ｂ，１０ｃが設けられている。サーバーマシン
であるホストＡには、データプールアクセスサーバ１１
ａ1 ，１１ａ2 が搭載されており、同じくサーバマシン
であるホストＣには、データプールアクセスサーバ１１
ｃが搭載されている。それぞれのデータプールアクセス
サーバは、一つのデータプールを管理している。一つの
データプールには、複数の論理ファイルを書き込むこと
ができる。また、各ホストは、それぞれにハードディス
ク１２ａ1 ，１２ａ2 ，１２b ，１２c 1 ，１２c 2 を
有している。図２では、サーバーマシンであるホストＡ
のデータプールアクセスサーバ１１ａ1 はハードディス
ク１２ａ1 をデータプールとして使用し、データプール
アクセスサーバ１１ａ2 はハードディスク１２ａ2 をデ
ータプールとして使用する。また、同じくサーバーマシ
ンであるホストＣのデータプールアクセスサーバ１１ａ
1 はハードディスク１２c 1 及び１２c 2 をデータプー
ルとして使用する。
【００１７】一方、クライアントマシンであるホストＢ
には、現在ホストＢ上で稼働しているアプリケーション
・ソフトウェア１３が搭載されている。なお、ホストＢ
の中に「ＡＰＩ」として示したものは、必要に応じてア
プリケーションプログラムの中に記載し、アプリケーシ
ョンプログラムの実行時に呼び出されるライブラリ関数
を概念的に示したものである（以下「ＡＰＩ関数」とい
う）。アプリケーション・ソフトウェアは、このＡＰＩ
関数を介して、本実施形態のデータ記憶システムの種々
の機能を利用する。このＡＰＩ関数には、サービスの利
用開始を宣言する関数、サービスの利用終了を宣言する
関数、論理ファイルをオープンしてデータの入出力を可
能にする関数、論理ファイルをクローズしてデータの入
出力を終了させる関数などが含まれる。
には、現在ホストＢ上で稼働しているアプリケーション
・ソフトウェア１３が搭載されている。なお、ホストＢ
の中に「ＡＰＩ」として示したものは、必要に応じてア
プリケーションプログラムの中に記載し、アプリケーシ
ョンプログラムの実行時に呼び出されるライブラリ関数
を概念的に示したものである（以下「ＡＰＩ関数」とい
う）。アプリケーション・ソフトウェアは、このＡＰＩ
関数を介して、本実施形態のデータ記憶システムの種々
の機能を利用する。このＡＰＩ関数には、サービスの利
用開始を宣言する関数、サービスの利用終了を宣言する
関数、論理ファイルをオープンしてデータの入出力を可
能にする関数、論理ファイルをクローズしてデータの入
出力を終了させる関数などが含まれる。
【００１８】尚、図２において、点線の矢印は、アプリ
ケーション・ソフトウェアによるサーバーのハードディ
スク１２ａ1 ，１２ａ2 ，１２c 1 ，１２c 2 に対する
マウント／アンマウント操作を示す。次に、本発明のデ
ータプール構成ファイルであるコンフィギュレーション
・ファイルについて説明する。データプールの所在、容
量等の管理情報は、このコンフィギュレーション・ファ
イルに記述される。図３は、このコンフィギュレーショ
ン・ファイルの一例を示した図である。同図において、
「Ｎａｍｅ」の欄にはデータプールの識別名を記述し、
「Ｈｏｓｔ」の欄にはデータプールが存在するホストの
ホスト名を記述し、「Ｄｉｒｅｃｔｏｒｙ」の欄にはデ
ータプールが存在するディレクトリを記述し、「Ｆｉｌ
ｅ Ｓｉｚｅ」の欄には１物理ファイルの容量をバイト
単位で記述し、「Ｐｏｏｌ Ｓｉｚｅ」の欄には一つの
データプールの容量をキロバイト単位で記述する。この
ファイルは、予めユーザーが記述して、各ホストに分配
しておく。
ケーション・ソフトウェアによるサーバーのハードディ
スク１２ａ1 ，１２ａ2 ，１２c 1 ，１２c 2 に対する
マウント／アンマウント操作を示す。次に、本発明のデ
ータプール構成ファイルであるコンフィギュレーション
・ファイルについて説明する。データプールの所在、容
量等の管理情報は、このコンフィギュレーション・ファ
イルに記述される。図３は、このコンフィギュレーショ
ン・ファイルの一例を示した図である。同図において、
「Ｎａｍｅ」の欄にはデータプールの識別名を記述し、
「Ｈｏｓｔ」の欄にはデータプールが存在するホストの
ホスト名を記述し、「Ｄｉｒｅｃｔｏｒｙ」の欄にはデ
ータプールが存在するディレクトリを記述し、「Ｆｉｌ
ｅ Ｓｉｚｅ」の欄には１物理ファイルの容量をバイト
単位で記述し、「Ｐｏｏｌ Ｓｉｚｅ」の欄には一つの
データプールの容量をキロバイト単位で記述する。この
ファイルは、予めユーザーが記述して、各ホストに分配
しておく。
【００１９】図３に示したコンフィギュレーション・フ
ァイルでは、ｐｏｏｌ１、ｐｏｏｌ２、ｐｏｏｌ３とい
う三つのデータプールが定義されている。図３のコンフ
ィギュレーション・ファイルによれば、「ｐｏｏｌ１」
というデータプールは、「ｈｏｓｔＡ」というホストに
存在し、その容量は２ＧＢで、これを構成するそれぞれ
の物理ファイルの大きさは２０ＭＢである。また、「ｐ
ｏｏｌ２」というデータプールは、「ｈｏｓｔＡ」とい
うホストに存在し、その容量は１０ＧＢで、これを構成
するそれぞれの物理ファイルの大きさは１０ＭＢであ
る。更に、「ｐｏｏｌ３」というデータプールは、「ｈ
ｏｓｔＣ」というホストに存在し、その容量は４ＧＢ
で、これを構成するそれぞれの物理ファイルのの大きさ
は１０ＭＢである。
ァイルでは、ｐｏｏｌ１、ｐｏｏｌ２、ｐｏｏｌ３とい
う三つのデータプールが定義されている。図３のコンフ
ィギュレーション・ファイルによれば、「ｐｏｏｌ１」
というデータプールは、「ｈｏｓｔＡ」というホストに
存在し、その容量は２ＧＢで、これを構成するそれぞれ
の物理ファイルの大きさは２０ＭＢである。また、「ｐ
ｏｏｌ２」というデータプールは、「ｈｏｓｔＡ」とい
うホストに存在し、その容量は１０ＧＢで、これを構成
するそれぞれの物理ファイルの大きさは１０ＭＢであ
る。更に、「ｐｏｏｌ３」というデータプールは、「ｈ
ｏｓｔＣ」というホストに存在し、その容量は４ＧＢ
で、これを構成するそれぞれの物理ファイルのの大きさ
は１０ＭＢである。
【００２０】本実施形態のデータ記憶システムは、この
コンフィギュレーション・ファイルに従ってデータプー
ルのファイル構成を定義する。アプリケーション・ソフ
トウェアは、コンフィギュレーション・ファイルに記述
されたデータプールの識別名のみを認識し、ＡＰＩ関数
を呼び出すだけで、ネットワークでつながれているホス
ト上にあるデータプール内の任意の論理ファイルを操作
することが可能となる。このとき、アプリケーション・
ソフトウェアは、その論理ファイルを構成する個々の物
理ファイル、すなわちＯＳが扱うファイルを意識する必
要はない。
コンフィギュレーション・ファイルに従ってデータプー
ルのファイル構成を定義する。アプリケーション・ソフ
トウェアは、コンフィギュレーション・ファイルに記述
されたデータプールの識別名のみを認識し、ＡＰＩ関数
を呼び出すだけで、ネットワークでつながれているホス
ト上にあるデータプール内の任意の論理ファイルを操作
することが可能となる。このとき、アプリケーション・
ソフトウェアは、その論理ファイルを構成する個々の物
理ファイル、すなわちＯＳが扱うファイルを意識する必
要はない。
【００２１】論理ファイルをデータプールに書き込む場
合、その論理ファイルには必ずキーワードを与える。こ
のキーワードが、そのデータプール内でその論理ファイ
ルを特定する手段となる。アプリケーション・ソフトウ
ェアは、データプール識別名とキーワードを与えること
によって、所望の論理ファイルを獲得し、以後、この論
理ファイルに対して書き込み及び読み出しを行うことが
できる。同一のデータプール内に複数の論理ファイルを
書き込む場合には、このキーワードによって各論理ファ
イルを識別することができる。また、このようなキーワ
ードを付けることにより、データを読み出すときに、キ
ーワードによって論理ファイルの検索を行うことができ
る。このとき、キーワードとしてその論理ファイルを作
成した日付に基づいた数字列を用いる場合を考え、
「＞」、「＜」、「＝」といった数学記号を用いた検索
を可能とする。
合、その論理ファイルには必ずキーワードを与える。こ
のキーワードが、そのデータプール内でその論理ファイ
ルを特定する手段となる。アプリケーション・ソフトウ
ェアは、データプール識別名とキーワードを与えること
によって、所望の論理ファイルを獲得し、以後、この論
理ファイルに対して書き込み及び読み出しを行うことが
できる。同一のデータプール内に複数の論理ファイルを
書き込む場合には、このキーワードによって各論理ファ
イルを識別することができる。また、このようなキーワ
ードを付けることにより、データを読み出すときに、キ
ーワードによって論理ファイルの検索を行うことができ
る。このとき、キーワードとしてその論理ファイルを作
成した日付に基づいた数字列を用いる場合を考え、
「＞」、「＜」、「＝」といった数学記号を用いた検索
を可能とする。
【００２２】データプールに対してある論理ファイルの
データを書き込んでいる途中にそのデータプールの容量
が一杯となり、更にその論理ファイルの残りのデータを
書き込む必要がある場合には、そのデータプールに既に
書き込まれているすべての論理ファイルのステータスを
見て、既に読み込み済となっている論理ファイルのうち
で最も古いものを削除して新たなデータスペースを確保
し、そこにデータを書き込む。このとき、仮に、読み込
み済のものがない場合には、 １．読み込む済の論理ファイルができるまで待機する ２．ファイルを獲得できない旨のリターンコードを即リ
ターンする のいずれかの動作をするように、アプリケーション・ソ
フトウェアの側で選択できるようにする。
データを書き込んでいる途中にそのデータプールの容量
が一杯となり、更にその論理ファイルの残りのデータを
書き込む必要がある場合には、そのデータプールに既に
書き込まれているすべての論理ファイルのステータスを
見て、既に読み込み済となっている論理ファイルのうち
で最も古いものを削除して新たなデータスペースを確保
し、そこにデータを書き込む。このとき、仮に、読み込
み済のものがない場合には、 １．読み込む済の論理ファイルができるまで待機する ２．ファイルを獲得できない旨のリターンコードを即リ
ターンする のいずれかの動作をするように、アプリケーション・ソ
フトウェアの側で選択できるようにする。
【００２３】尚、本発明は、上記実施形態に限定される
ものではなく、その要旨の範囲内で種々の変更が可能で
ある。例えば、上記実施形態では、論理ファイルに５種
類のステータスを与えたが、この中の「読み込み済」の
ステータスについて、何回読み込みが行われたかをカウ
ントし、一定回数の読み込みが終了したら、古い順から
削除可能とするような構成とすることもできる。また、
上記実施形態では、ネットワークに接続されたクライア
ント側のアプリケーション・ソフトウェアが、サーバ上
のディスクに論理ファイルの書き込みや読み出しを行う
場合について説明したが、本発明は、例えばＵＮＩＸを
搭載した１台のコンピュータ上でも動作させることが可
能である。
ものではなく、その要旨の範囲内で種々の変更が可能で
ある。例えば、上記実施形態では、論理ファイルに５種
類のステータスを与えたが、この中の「読み込み済」の
ステータスについて、何回読み込みが行われたかをカウ
ントし、一定回数の読み込みが終了したら、古い順から
削除可能とするような構成とすることもできる。また、
上記実施形態では、ネットワークに接続されたクライア
ント側のアプリケーション・ソフトウェアが、サーバ上
のディスクに論理ファイルの書き込みや読み出しを行う
場合について説明したが、本発明は、例えばＵＮＩＸを
搭載した１台のコンピュータ上でも動作させることが可
能である。
【００２４】
【発明の効果】以上説明したように、本発明によれば、
データの容量が、そのオペレーティングシステムの物理
ファイルの最大容量を超える場合であっても、データの
分割等の処理はデータプールアクセスサーバが自動的に
オペレーティングシステムを介して行ってるくれるの
で、アプリケーション・ソフトウェアの側ではそのこと
を意識する必要がなく、単に論理ファイルだけを認識し
てデータの書き込み及び読み出しを行えばよいので、ア
プリケーション・ソフトウェアが行わなければならない
作業が簡素化され、アプリケーション・ソフトウェアを
開発する際のプログラミング作業が簡素化されてプログ
ラマの負担が軽減され、ひいてはアプリケーション・ソ
フトウェアの開発コストが低減するデータ記憶システム
を提供することができる。
データの容量が、そのオペレーティングシステムの物理
ファイルの最大容量を超える場合であっても、データの
分割等の処理はデータプールアクセスサーバが自動的に
オペレーティングシステムを介して行ってるくれるの
で、アプリケーション・ソフトウェアの側ではそのこと
を意識する必要がなく、単に論理ファイルだけを認識し
てデータの書き込み及び読み出しを行えばよいので、ア
プリケーション・ソフトウェアが行わなければならない
作業が簡素化され、アプリケーション・ソフトウェアを
開発する際のプログラミング作業が簡素化されてプログ
ラマの負担が軽減され、ひいてはアプリケーション・ソ
フトウェアの開発コストが低減するデータ記憶システム
を提供することができる。
【図１】従来のデータ記憶システムと本実施形態のデー
タ記憶システムの概念を比較して示した図である。
タ記憶システムの概念を比較して示した図である。
【図２】本実施形態のネットワーク接続されたデータ記
憶システムの構成を示す図である。
憶システムの構成を示す図である。
【図３】コンフィギュレーション・ファイルの一例を示
した図である。
した図である。
１０ａ，１０ｂ，１０ｃ 通信ソフトウェア １１ａ1 ，１１ａ2 ，１１ｃ データプールアクセス
サーバ １２ａ1 ，１２ａ2 ，１２ｂ，１２ｃ1 ，１２ｃ2
ハードディスク １３ アプリケーション・ソフトウェア
サーバ １２ａ1 ，１２ａ2 ，１２ｂ，１２ｃ1 ，１２ｃ2
ハードディスク １３ アプリケーション・ソフトウェア
Claims (4)
- 【請求項１】 データの読み出し及び書き込みを可能と
する記憶媒体と、 前記記憶媒体に対し物理ファイルを単位としてデータの
読み出し及び書き込みの動作を制御するオペレーティン
グシステムと、 データの格納場所であるデータプールを、それが存在す
るディレクトリ、それを構成する前記物理ファイルの容
量及びそのデータプールの容量によって定義するデータ
プール構成ファイルと、 アプリケーション・ソフトウェアからの要求に従って、
一つのデータプール内で、前記論理ファイルを単位とし
て、前記オペレーティングシステムに前記記録媒体に対
するデータの記録及び読み出しを行わせるデータプール
アクセスサーバと、 を具備することを特徴とするデータ記憶システム。 - 【請求項２】 前記データプールアクセスサーバは、デ
ータの容量が前記物理ファイルの容量を超える場合に、
前記データを分割して複数の物理ファイルとして前記デ
ータプールに書き込むものである請求項１記載のデータ
記憶システム。 - 【請求項３】 前記データプールアクセスサーバは、デ
ータプールにデータの書き込みを行っているときに、そ
のデータプールの空き容量がなくなったときは、そのデ
ータプール内の論理ファイルのステータスを参照し、既
に読み出しが済んだものがあれば、それをを削除してデ
ータ書き込み領域を確保する機能を有する請求項１又は
２記載のデータ記憶システム。 - 【請求項４】 前記オペレーティングシステムはＵＮＩ
Ｘであり、前記記憶媒体はハードディスクであることを
特徴とする請求項１，２又は３記載のデータ記憶システ
ム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP8184383A JPH1031599A (ja) | 1996-07-15 | 1996-07-15 | データ記憶システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP8184383A JPH1031599A (ja) | 1996-07-15 | 1996-07-15 | データ記憶システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH1031599A true JPH1031599A (ja) | 1998-02-03 |
Family
ID=16152234
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP8184383A Withdrawn JPH1031599A (ja) | 1996-07-15 | 1996-07-15 | データ記憶システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JPH1031599A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006302253A (ja) * | 2005-03-25 | 2006-11-02 | Hitachi Ltd | ストレージシステム |
-
1996
- 1996-07-15 JP JP8184383A patent/JPH1031599A/ja not_active Withdrawn
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006302253A (ja) * | 2005-03-25 | 2006-11-02 | Hitachi Ltd | ストレージシステム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4799936B2 (ja) | 条件別スナップショット取得方法及びシステム | |
| US5239647A (en) | Data storage hierarchy with shared storage level | |
| US9513810B2 (en) | Fast accessible compressed thin provisioning volume | |
| US6275910B1 (en) | Storage device and method for data sharing | |
| US5317728A (en) | Storage management of a first file system using a second file system containing surrogate files and catalog management information | |
| US20180018099A1 (en) | Systems and methods for performing storage operations using network attached storage | |
| US6061770A (en) | System and method for real-time data backup using snapshot copying with selective compaction of backup data | |
| US20070078914A1 (en) | Method, apparatus and program storage device for providing a centralized policy based preallocation in a distributed file system | |
| JPH07104808B2 (ja) | 設置可能なファイルシステムにおいてダイナミックボリュームトラッキングを行う方法及び装置 | |
| JP2005501317A (ja) | 外部データ記憶装置管理システムおよび方法 | |
| EP1209556A2 (en) | Method and system for transparently extending non-volatile storage | |
| JP4279452B2 (ja) | １つの記憶媒体の名称空間を別の記憶媒体の名称空間に移植する場合に既定のアクションを実行するシステムおよび方法 | |
| US20090193207A1 (en) | Computer system, remote copy method and first computer | |
| KR20070024573A (ko) | 최적의 성능을 위한 파일 관리 방법 | |
| US20080270698A1 (en) | Data migration including operation environment information of a host computer | |
| JPH1031612A (ja) | 高度ファイル・サーバ | |
| US6370545B1 (en) | Method of accessing removable storage media | |
| US20030037019A1 (en) | Data storage and retrieval apparatus and method of the same | |
| CN114398187A (zh) | 一种数据存储方法和装置 | |
| JPH0622015B2 (ja) | データ処理システムの制御方法 | |
| US7451279B2 (en) | Storage system comprising a shared memory to access exclusively managed data | |
| JP2001154895A (ja) | 記憶されたレコードについてのフォーマット情報を効率的に提供するためのディレクトリを含むデジタル・データ記憶サブシステム | |
| JPH1185576A (ja) | データ移行方法および情報処理システム | |
| JP4390618B2 (ja) | データベース再編成プログラム、データベース再編成方法、及びデータベース再編成装置 | |
| JPH1031599A (ja) | データ記憶システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20031007 |