記録再生装置および記録再生方法
【課題】パフォーマンスを維持しながら、論理破壊を防ぎファイルを永続化する技術を提供することが可能な、新規かつ改良された技術を提供する。
【解決手段】記録再生装置は、リクエストを１または複数生成してミラーリクエストキュー１４１に登録し、登録し終わると、ミラーリング要求フラグに所定の値を設定するファイルシステム部１３０を備える。また、記録再生装置は、ミラーリクエストキュー１４１に登録されている１または複数のリクエストをリクエストキュー１５１に登録し、登録した１または複数のリクエストに対する処理がすべて完了したら、ミラーリング要求フラグを参照し、ミラーリング要求フラグに所定の値が設定されている場合には、ミラーリクエストキュー１４１に登録されている１または複数のリクエストをリクエストキュー１６１に登録するトランザクションミラーリングドライバ部１４０を備える。
【解決手段】記録再生装置は、リクエストを１または複数生成してミラーリクエストキュー１４１に登録し、登録し終わると、ミラーリング要求フラグに所定の値を設定するファイルシステム部１３０を備える。また、記録再生装置は、ミラーリクエストキュー１４１に登録されている１または複数のリクエストをリクエストキュー１５１に登録し、登録した１または複数のリクエストに対する処理がすべて完了したら、ミラーリング要求フラグを参照し、ミラーリング要求フラグに所定の値が設定されている場合には、ミラーリクエストキュー１４１に登録されている１または複数のリクエストをリクエストキュー１６１に登録するトランザクションミラーリングドライバ部１４０を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、記録再生装置および記録再生方法に関する。詳しくは、障害発生時のデータ修復を行うためのバックアップの技術に関する。
【背景技術】
【０００２】
従来、周期的書換えを必要とするファイルの永続化を行う技術には様々なものがある。例えば、ファイルを２重化する技術がある。この２重化の技術では、オリジナルファイルとバックアップファイルの２つを作成して、ファイル単位で各々をストレージに記録するものである。これによって、どちらかのファイルが破壊または消滅してもシステム的に破綻しないようにされている。
【０００３】
また、ボリュームの破壊耐性を高める技術としてＲＡＩＤがある（例えば、特許文献１参照）。この中で、ボリュームの複製を行う技術は、ＲＡＩＤ１（ミラーリング）である。これは、ストレージへのアクセス単位でファイルがミラーリングされ、ドライバレベルまたはハードウェアレベルで複製が実現されている。複製しない場合に比較して増加する処理については、上記したファイルの二重化の技術ほど大きくはならないというメリットがある。
【０００４】
【特許文献１】特開２００３−２９６０４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、ファイルの二重化の技術では、周期的／頻繁的に変更を伴うファイルを対象とする場合には、パフォーマンスの観点から実現が困難であるという問題があった。
【０００６】
また、上記した特許文献１に開示された技術によれば、パフォーマンスをある程度維持しながら２重化を行うことができるが、ファイルシステムの論理破壊の見地からはトランザクション中に発生した障害におけるファイルの永続は保証できないという問題があった。
【０００７】
現状ではパフォーマンスを維持しながら、論理破壊を防ぎファイルを永続化する技術が確立していない。
【０００８】
本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、パフォーマンスを維持しながら、論理破壊を防ぎファイルを永続化する技術を提供することが可能な、新規かつ改良された技術を提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、本発明のある観点によれば、記録再生装置は、システムコール部からトランザクションの入力を受け付け、トランザクションの処理において必要なリクエストを１または複数生成し、生成した１または複数のリクエストをミラーリクエストキューに登録し、登録し終わると、メモリに記憶されたミラーリング要求フラグに所定の値を設定するファイルシステム部を備える。
【００１０】
また、記録再生装置は、ミラーリクエストキューを有し、ミラーリクエストキューに登録されている１または複数のリクエストをオリジナルボリューム書き込み用リクエストキューに登録し、登録した１または複数のリクエストに対する処理がすべて完了したら、ミラーリング要求フラグを参照し、ミラーリング要求フラグに所定の値が設定されている場合には、ミラーリクエストキューに登録されている１または複数のリクエストをバックアップボリューム書き込み用リクエストキューに登録するトランザクションミラーリングドライバ部を備える。
【００１１】
また、記録再生装置は、オリジナルボリューム書き込み用リクエストキューを有し、リクエストキューから取り出したリクエストを出力するオリジナルボリュームインタフェースドライバ部を備える。
【００１２】
また、記録再生装置は、バックアップボリューム書き込み用リクエストキューを有し、リクエストキューから取り出したリクエストを出力するバックアップボリュームインタフェースドライバ部を備える。
【００１３】
また、記録再生装置は、オリジナルボリュームインタフェースドライバ部から出力されたリクエストに含まれるオリジナルデータをオリジナルボリュームに書き込む処理と、バックアップボリュームインタフェースドライバ部から出力されたリクエストに含まれるバックアップデータをバックアップボリュームに書き込む処理とを制御するストレージ制御部を備える。
【００１４】
かかる構成によれば、ファイルシステム部がリクエストをミラーリクエストキューに登録した後、バックアップの制御はトランザクションミラーリングドライバ部が行うことになる。したがって、ファイルシステム部がリクエストをミラーリクエストキューに登録した後において、ファイルシステム部によるバックアップの制御は不要となる。
【発明の効果】
【００１５】
本発明によれば、パフォーマンスを維持しながら、論理破壊を防ぎファイルを永続化する技術を提供することが可能となる。
【発明を実施するための最良の形態】
【００１６】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１７】
《本実施形態に適用可能な記録再生装置について》
破壊されるとシステムとして致命的損害を与えるファイルの永続的な保証方法としてはいくつかの方法が考えられる。例えば、ファイルの２重化（ファイルのオリジナルファイルとバックアップファイルの２重書込み）およびＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）（ボリュームのミラーリング）という方法である。これらの方法の概念図を図１に示す。
【００１８】
ファイルの２重化とはファイル単位でオリジナルとバックアップの２つを作成することであり、どちらかが破壊および消滅してもシステム的に破綻しない作りとするものである。ここではファイルの２重書込みを行うタイミング（バックアップを行うタイミング）をどうするかが問題となってくる。
【００１９】
設定用ファイルのように頻繁に変更が必要ないファイルであれば、設定を変更する前にバックアップを取っておく。そして、変更内容をストレージに反映させる途中で障害が起きた場合はバックアップ時（変更前）に戻すということで対処でき、変更前に戻したとしてもシステム的影響はない。また、ファイルの２重書込みによる処理の増加もシステム的には許容できるものが殆どである。
【００２０】
しかし、周期的に変更を要するファイルでさらに書込みに対するスループットが厳しい場合には、変更の度に２重書込みを行っていては必要となるスループットが満たせない状況に陥り、システム的に破綻する。２重書き込みを行うタイミングを間引いてしまうと、変更前に戻したときのシステム的影響がでる。
【００２１】
この周期的で且つスループットが必要となる代表例としては、ストリーム記録（放送録画）を行う場合である。ストリーム記録では、ストリームデータはあるレートでシステムに入力され、システムはそのデータをストレージに記録する。ストレージに記録するレートが入力レートより小さい場合はシステムが破綻してしまう。また、このストリーム記録では、記録したコンテンツを再生するために必要な再生用データを周期的にファイルに書き出す必要があり、このファイルが破壊または消滅した場合は再生が出来ないという影響が出る。この再生用データが書かれるファイルが永続的、周期的ファイルである。
【００２２】
ＲＡＩＤとは、ボリュームレベルで冗長を図り、ボリュームの破壊耐性を高める技術である。２重書込みと同じ結果をもたらすものはＲＡＩＤ１（ミラーリング）であり、ボリュームの複製を作成する。これはストレージ（ボリューム）へのアクセス単位でファイルはミラーリングされ、ドライバレベルまたはハードウェア（Ｈ／Ｗ）レベルで実現しており、必要となる処理の増加も２重書込みに比べると小さく、スループットが高い。
【００２３】
ここで、ストレージへの記録済みファイルが破壊および消滅してしまう原因について述べる。ストレージへの記録済みファイルが破壊される原因は、ストレージの物理的な破壊とファイルへのアクセスに必要な管理データが破壊することで起こる論理破壊の２つである。ＲＡＩＤは物理破壊によるファイルの喪失を防ぐものであり、論理破壊を防ぐものではない為、それだけではファイルの永続的な保証はできない。これはファイルシステムがトランザクションを基本として論理保証を行っており、ＲＡＩＤはこのファイルシステムのトランザクションに一切関知していない為である。
【００２４】
論理破壊への耐性としてはファイルシステムレベルでジャーナリングファイルシステム（代表的なものとしてＥＸＴ３、ＸＦＳ）ＬｏｇＢａｓｅファイルシステム（代表的なものとしてＮＩＬＦＳ）を用いるのが一般的である。これらファイルシステムの復旧の目的としてはファイルシステムの論理的整合性を保つことにあり、復旧時に整合性を阻害するデータおよびファイルなどは消去抹消される。よって、ファイルシステムの論理的破壊への耐性ではファイルの永続的保証はできない。
【００２５】
論理破壊の仕組みを代表的なジャーナリングファイルシステムであるＸＦＳで説明する。ＸＦＳのトランザクションについて図２に示す。
【００２６】
まず、書き込みオペレーションによって、トランザクションのアロケーションが実行される（ステップＳ９０１）。ここでは、トランザクション構造体と一意なトランザクション識別子を割り当てる。続いて、ログスペースが確保される（ステップＳ９０２）。ここでは、トランザクションに必要なログスペースがメモリ８１上に確保される。その後、リソース（修正するリソース８２）のロックを行う（ステップＳ９０３）。ここでは、リソース（バッファ、ｉノード、管理領域）の読み込みとロックを行う。
【００２７】
続いて、リソースの修正が行われる（ステップＳ９０４）。ここでは、修正するリソース８２の修正とトランザクションオペレーション構造体（オペレーション内容を記録するために使用する構造体）の作成が行われる。その後、コミットトランザクションが実行される（ステップＳ９０５）。ここでは、リソースの修正情報とトランザクションオペレーションをｉｎ−ｃｏｒｅログに記録する。ｉｎ−ｃｏｒｅログは、メモリ８１上のログ格納領域８３であり、書き出されていないログ８３１、ログスペース８３２、書き出されたログ８３３等により構成されている。
【００２８】
続いて、ｉｎ−ｃｏｒｅログがＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）８４に書き出される（ステップＳ９０６）。これによって、ｄｉｓｋ−ｏｎログ（ＨＤＤ８４に書き出されるログ）がＨＤＤ８４に書き出される。その後、修正されたリソースがフラッシュされる（ステップＳ９０７）。すなわち、修正されたリソースがＨＤＤ８４に書き出される。ログの領域は、メモリ８１上もＨＤＤ８４上もリング上となっている。また、領域８４１は、ＨＤＤ８４上のＸＦＳ ｐａｒｔｉｔｉｏｎである。
【００２９】
トランザクションからファイルおよびファイルシステムの破壊が発生するのはリソースのフラッシュの処理（ステップＳ９０７）中に障害が発生した場合である。それ以外はメモリ８１上での反映なので障害が起きてもストレージ上には変更前の整合が取れた状態でデータが存在している。
【００３０】
ＸＦＳのトランザクション中に変更が加わるリソースとストレージへの反映順序を図３に示す。
【００３１】
図３は、ファイル作成のトランザクション（Ｔｙｐｅ：ＸＦＳ＿ＴＲＡＮＳ＿クリエート）が入力された場合の様子を示している。このトランザクションによって変更されるリソースは５つである。すなわち、ＸＡＧＩ、ＩＡＢＴ、ＩＮＯＤＥ（作成されるファイルのｉｎｏｄｅ）、ｉｎｏｄｅ（ディレクトリのｉｎｏｄｅ）、ＳＢである。修正済みのリソースは、ログが書き戻されるまでメモリ８１上にロックされている。
【００３２】
ＨＤＤ８４には、ＨＤＤｗｒｉｔｅキャッシュ８４１１が存在し、メモリ８１上のリソースが、ＨＤＤｗｒｉｔｅキャッシュ８４１１に書き込まれる。この際、ＴＣＱ／ＮＣＱなどにより書き出し順序に変更があることが予想される。また、ＨＤＤ８４上のメディア８４１２に書き込まれる際にも、書き出し順序の入れ替えがあることが予想される。
【００３３】
このように、リソースのストレージへの反映順序は一意には決まらず、どのリソースが反映済みでどのリソースが反映前のデータか特定できない。
【００３４】
リソースのストレージへの格納位置と書込みリクエストについて図４に示す。図４には、１つのアロケーショングループが示されている。ＸＡＧＦを変更した場合、変更がないＸＦＳＢも書き戻される。同様に、ブロックの一部に対してデータ変更を加えた場合でも、実際にフラッシュされるのは、ブロック単位である。また、１つのｉｎｏｄｅを変更した場合、変更がない他のｉｎｏｄｅ１５個も書き戻される。同様に、１つのｉｎｏｄｅに対して変更を加えた場合でも、実際にフラッシュされるのは、ブロック単位である。
【００３５】
全てのリソースの反映は１つのリクエストでは収まらず複数のリクエストを発行する必要がある。
【００３６】
図５に、ファイルの既存の技術で２重化を行う場合のリクエストとストレージへのコマンド要求の発行の様子を示す。図５において、太矢印は、システムコールを示している。
【００３７】
図６に、ＲＡＩＤ１を使用してミラーを行った場合のリソースがストレージへ反映されている様子を示す。リソースの反映はオリジナル／バックアップ同時並行的に行われるために、書出し途中で障害が発生した場合はオリジナル／バックアップで同じ不整合が生じる。
【００３８】
《本実施形態に適用可能な記録再生装置の課題について》
まとめると、周期的書換えを必要とするファイルの永続化を行おうとすると、
１．ファイルを２重持ちとするのは常等手段ではあるが、周期的／頻繁的に変更を伴うファイルの２重化はパフォーマンスの観点から実現が困難である。
２．パフォーマンスをある程度維持しながら２重化を行う技術としてＲＡＩＤ１があるが、ファイルシステムの論理破壊の見地からはトランザクション中に発生した障害におけるファイルの永続は保証できない。
【００３９】
現状ではパフォーマンスを維持しながら、論理破壊を防ぎファイルを永続化する技術が確立していない。
【００４０】
《本実施形態の目的について》
本実施形態における目的は以下に示すものである。
１．頻繁に更新が必要となるファイルの永続保証を行う。
２．永続保証を行うために費やされる処理時間を最小限に抑える。
３．データ復旧処理時間を最小限に抑える。
４．ファイルシステムが管理しているトランザクションレベルでミラーリングを行う。
５．ファイルシステムが発行する転送要求リクエストにトランザクションタグを付加することにより、どのトランザクションに属しているリクエストかを判別する。
６．ファイルシステムが発行するリクエストにｓｔａｔｕｓを持たせることで転送前／転送終了待ち／転送完了／ミラー転送終了待ち／ミラー転送完了の状態を管理できるようにする。
７．ファイルシステムの管理データは全てトランザクションレベルで２重化対象とすることで、ファイルシステムの論理破壊は理論上ない。
【００４１】
《本実施形態に係る記録再生装置について》
本実施形態に係る記録再生装置の基本概念を図７に示す。これはミラーを行う単位／タイミングをファイルシステムのトランザクションに合わせたものである。
【００４２】
図６に示されている時点で障害が発生した場合は、各リソースは変更が反映される前のものと反映後のものが混在し不整合が生じている。不整合が生じている状態を修復しようとするならば、どのリソースに不整合が生じているかを調べる必要があり、瞬時に修復することはできない。また、その修復においてファイルが破棄されるおそれがある。
【００４３】
それと比較して図７では、図７に示されている時点で障害が発生しても、バックアップボリューム６９内のリソースは変更前の状態で整合がとれている。これにより、障害が発生した場合はバックアップボリューム６９内の情報でオリジナルボリューム６８の情報の修復を行うことにより、変更前の状態に瞬時にもどすことができる。
【００４４】
図８に、本実施形態に係る記録再生装置の機能構成図を示す。なお、記録再生装置における各キューは、メモリ等によって構成される。また、その他の各構成は、専用のハードウェアで構成されていてもよいし、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）で構成されていてもよい。ＣＰＵによって構成される場合には、ＣＰＵによってソフトウェアが実行されることによって、各構成の備える機能が実現される。
【００４５】
ストレージ（オリジナルボリューム１８１およびバックアップボリューム１８２）にデータを記録するプログラムは、システムコール（システムコール部１２０）を用いてファイルの作成を行う。
【００４６】
システムコールは、ファイルシステムのファイルクリエートオペレーション関数を呼び出す。
【００４７】
ファイルシステム（ファイルシステム部１３０）は、ファイルクリエートオペレーションの処理を行う（このファイルクリエートオペレーションの一連の処理をファイルクリエートトランザクションと定義する）。この処理の中ではファイルをクリエートするために必要となるリソースの変更を行い、リクエストを生成し、複製（ミラー）が必要なものに関してはミラーリクエストキュー１４１に登録する。必要なリソースの変更のリクエストを全て登録し終わった時点でミラーリクエストキュー１４１に対してミラーリング要求フラグを設定する。ミラーリクエストキュー１４１は１または複数用意されるものとする。
【００４８】
ファイルシステム部１３０は、システムコール部１２０からトランザクションの入力を受け付け、トランザクションの処理において必要なリクエストを１または複数生成し、生成した１または複数のリクエストをミラーリクエストキュー１４１に登録する。ファイルシステム部１３０は、登録し終わると、記録再生装置内の図示しないメモリに記憶されたミラーリング要求フラグに所定の値を設定する。所定の値とは、データを複製する要求を示す値であり、特に限定されるものではない。
【００４９】
トランザクションミラーリングドライバ部１４０は、ミラーリクエストキュー１４１を有し、ミラーリクエストキュー１４１に登録されている１または複数のリクエストをオリジナルボリューム書き込み用リクエストキュー（リクエストキュー１５１）に登録する。トランザクションミラーリングドライバ部１４０は、登録した１または複数のリクエストに対する処理がすべて完了したら、ミラーリング要求フラグを参照する。ミラーリング要求フラグに所定の値が設定されている場合には、ミラーリクエストキュー１４１に登録されている１または複数のリクエストをバックアップボリューム書き込み用リクエストキュー（リクエストキュー１６１）に登録する。
【００５０】
リクエスト制御部１４２は、ミラーリクエストキュー１４１に登録されているリクエストをオリジナルボリュームインタフェースドライバ部１５０がもつリクエストキュー１５１に登録する。リクエスト制御部１４２は、ミラーリクエストキュー１４１に登録されているミラーリクエストが全て完了で終了するのを監視しながら待つ。ミラーリクエストが全て完了で終了し且つミラーリクエストキュー１４１に対して（記録再生装置の図示しないメモリに記憶されている）ミラーリング要求フラグに所定の値が設定されていた場合、リクエストをバックアップボリュームインタフェースドライバ部１６０のリクエストキュー１６１に登録する。リクエスト制御部１４２は再度、ミラーリクエストが全て完了で終了するのを監視しながら待つ。終了した時点でファイルクリエートオペレーションに対してｒｅｔｕｒｎを返す。また、このときに、ファイルシステム部１３０は、ミラーリング要求フラグに設定されている所定の値をクリアする。
【００５１】
オリジナルボリュームインタフェースドライバ部１５０は、オリジナルボリューム書き込み用リクエストキュー（リクエストキュー１５１）を有し、リクエストキュー１５１から取り出したリクエストを出力する。
【００５２】
バックアップボリュームインタフェースドライバ部１６０は、バックアップボリューム書き込み用リクエストキュー（リクエストキュー１６１）を有し、リクエストキュー１６１から取り出したリクエストを出力する。
【００５３】
ストレージ制御部１７０Ａは、オリジナルボリュームインタフェースドライバ部１５０から出力されたリクエストに含まれるオリジナルデータをオリジナルボリューム１８１に書き込む処理を制御する。また、ストレージ制御部１７０Ａは、バックアップボリュームインタフェースドライバ部１６０から出力されたリクエストに含まれるバックアップデータをバックアップボリュームに書き込む処理を制御する。
【００５４】
図９に、ミラーリクエストキューとノーマルリクエストキュー両方をストレージインタフェースドライバ部内で制御する場合の実装形態を示す。
【００５５】
図１０に、Ｈ／Ｗ（ＩＦコントローラ／ストレージコントローラ）でコマンドをキューイングする場合の実装形態を示す。
【００５６】
《本実施形態に係る記録再生装置が実行する処理の流れについて》
本実施形態に係る記録再生装置が実行する処理の流れを図１１、図１２に示す。
【００５７】
図１１は、永続を必要とするファイルの書込み処理について示す。図１２は、永続化を必要としないファイルの書込み処理について示す。また、図１３には、図１２に示す永続を必要とするファイルの書込みを、ＲＡＩＤコントローラを用いてさらにストレージの破壊についての耐性を向上させた場合について示す。
【００５８】
図１１、図１２、図１３の３つの例において、ファイルを書き出す場合はＦＳ（Ｆｉｌｅ Ｓｙｓｔｅｍ）管理データ１３２１（各図における実線矢印）、ファイル管理データ１３２２（各図における破線矢印）とファイルの中身となるデータ（各図における太矢印）の書出しを必要とする。
【００５９】
図１１において、新たにファイルを作成する場合には、ファイルクリエートシステムコールによりファイル名とファイルの属性情報を付加する。永続化ファイルか通常ファイルかの区別はこの属性情報として与えられる。
【００６０】
ファイルシステム部１３０は、この属性情報およびシステムコールの種別によりトランザクションを決定し、そのトランザクション中でリソース管理部１３２に働きかけ変更が必要な場合はそのリソースを書き出す。この例のリソースはＦＳ管理データ１３２１とファイル管理データ１３２２がそれに相当する。
【００６１】
ファイルシステム部１３０は、永続化ファイルの属性情報によりリソース書出しリクエストを作成する。この際、リクエスト内のデータとしてどのトランザクションのリクエストかを判別するためのトランザクションタグを保持しているものとする。
【００６２】
リクエストは、ファイルシステム部１３０によってトランザクションミラーリングドライバ部１４０のミラーリクエストキュー１４１に繋がれるものとする。図１１では、実線矢印、破線矢印が、それぞれＦＳ管理データ１３２１、ファイル管理データ１３２２の書出しを示している。
【００６３】
トランザクションミラーリングドライバ部１４０は、ミラーリクエストキュー１４１につながれているリクエストを任意のタイミングでオリジナルボリュームインタフェースドライバ部１５０のリクエストキュー１５１に繋ぐ。トランザクションミラーリングドライバ部１４０のリクエスト制御部１４２は、オリジナルボリュームインタフェースドライバ部１５０からの転送終了を待つ。また、トランザクションミラーリングドライバ部１４０は、リクエストのｓｔａｔｕｓである転送前／転送終了待ち／転送完了／ミラー転送終了待ち／ミラー転送完了を管理する。
【００６４】
ファイルシステム部１３０は、トランザクション中に発行すべきリクエストを全てミラーリクエストキュー１４１に繋いだ時点で、ミラーリング実行イベントをトランザクションミラーリングドライバ部１４０に通知する。このときのイベントの情報としてトランザクションタグを通知する。
【００６５】
トランザクションミラーリングドライバ部１４０は、ミラーリング実行イベントに含まれているトランザクションタグと同じタグ情報のリクエストのステータスが全て転送完了するまで待ち、全てのリクエストが転送完了となった時点で全てのリクエストをバックアップボリュームインタフェースドライバ部１６０のリクエストキュー１６１に繋ぐ。トランザクションミラーリングドライバ部１４０は、再度全てのリクエストがミラー転送完了になるのを待ち、全て転送完了した時点でファイルシステム部１３０に転送終了を通知する。ファイルシステム部１３０は、転送終了をシステムコールの戻りとする。
【００６６】
図１２を用いて、永続化を必要としないファイルの書込み処理について説明する。通常ファイルの場合でもＦＳ管理データ１３２１、ファイル管理データ１３２２は、ミラーリングの対象となる。同一ＦＳ上にファイルを格納する場合は、永続化ファイルでも通常ファイルでも同一のデータを扱うため、特にＦＳ管理データ１３２１は、通常ファイルだからといってミラーリングを行わないとＦＳが破壊される恐れがある。よって、ＦＳ管理データ１３２１およびファイル管理データ１３２２は永続化ファイルの場合と同様にミラーリングが行われる。データの書出しだけミラーリングを行わない。
【００６７】
記録再生装置は、ファイルの中身となるデータ（通常ファイル）の書き込み先となるデータブロック１８３をさらに備える。
【００６８】
また、記録再生装置は、データブロックインタフェースドライバ部１６６をさらに備える。データブロックインタフェースドライバ部１６６は、データブロック書き込み用リクエストキュー（リクエストキュー１６７）を有し、リクエストキュー１６７から取り出したリクエストを出力する。
【００６９】
ファイルシステム部１３０は、ファイルの中身となるデータ（通常ファイル）を、リクエストキュー１６７に登録する。
【００７０】
ストレージ制御部１７０Ａは、データブロックインタフェースドライバ部１６６から出力されたリクエストに含まれるデータをデータブロック１８３に書き込む処理をさらに制御する。
【００７１】
図１３を用いて、図１２に示す永続を必要とするファイルの書込みを、ＲＡＩＤコントローラを用いてさらにストレージの破壊についての耐性を向上させた場合について説明する。図１３に示すように、ハードウェア側にストレージ制御部＋ＲＡＩＤ制御部１７０Ｃが存在する。このＲＡＩＤ制御の機能によって、２つのストレージのそれぞれに同一のデータが書き込まれる。これによって、ストレージに対する物理的な破壊からデータを保護することができる。したがって、ファイルシステムが破壊される場合、ファイルが消滅する場合のみならず、ハードディスクが物理的に破壊される場合に対してもデータを復旧することが可能となる。
【００７２】
《本実施形態が奏する効果について》
本実施形態によれば、以下のような効果を奏する。
【００７３】
１．障害発生時の修復が高速に行える。
２．ファイルシステムの修復時にファイルを破棄することなく、永続的に存在させることができる。
３．ファイルを２重に書き込むよりもパフォーマンスが向上する。
４．ミドルウェアは、通常のシステムコールを呼び出すだけでミラーを意識する作りにしなくてもよい。
５．ＲＡＩＤ１のミラーではファイルシステムの整合性を保証できないが、本実施形態では整合性を保証できる。
６．実装はＳ／Ｗ、Ｈ／Ｗ両方で可能である。
７．ミドルウェアはミラーを意図しない作りにすることができるが、ミラーが必要なデータおよびリソースか不必要かはミドルウェアがハンドリングすることができ、ファイルレベルでミラーを行うファイルとミラーを必要としないファイルを混在させることが可能である。
【００７４】
《本実施形態の変形例について》
上記では、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【図面の簡単な説明】
【００７５】
【図１】本実施形態に適用可能な記録再生装置の概念図である。
【図２】ＸＦＳのトランザクションについて示す図である。
【図３】ファイル作成のトランザクションが入力された場合の様子を示す図である。
【図４】１つのアロケーショングループを示す図である。
【図５】ファイルの既存の技術で２重化を行う場合のリクエストとストレージへのコマンド要求の発行の様子を示す図である。
【図６】ＲＡＩＤ１を使用してミラーを行った場合のリソースがストレージへ反映されている様子を示す図である。
【図７】本実施形態に係る記録再生装置の基本概念図である。
【図８】本実施形態に係る記録再生装置の機能構成図を示す図である。
【図９】ミラーリクエストキューとノーマルリクエストキュー両方をストレージインタフェースドライバ部内で制御する場合の実装形態を示す図である。
【図１０】Ｈ／Ｗ（ＩＦコントローラ／ストレージコントローラ）でコマンドをキューイングする場合の実装形態を示す図である。
【図１１】永続を必要とするファイルの書込み処理について示す図である。
【図１２】永続化を必要としないファイルの書込み処理について示す図である。
【図１３】永続を必要とするファイルの書込みを、ＲＡＩＤコントローラを用いてさらにストレージの破壊についての耐性を向上させた場合について示す図である。
【符号の説明】
【００７６】
６８ オリジナルボリューム
６９ バックアップボリューム
８１ メモリ
８２ リソース
８３ ログ格納領域
８４ ＨＤＤ
１２０ システムコール部
１３０ ファイルシステム部
１３２ リソース管理部
１４０ トランザクションミラーリングドライバ部
１４１ ミラーリクエストキュー
１４２ リクエスト制御部
１５０ オリジナルボリュームインタフェースドライバ部
１５１ リクエストキュー
１６０ バックアップボリュームインタフェースドライバ部
１６１ リクエストキュー
１７０Ｃ ＲＡＩＤ制御部
１８１ オリジナルボリューム
１８２ バックアップボリューム
１３２１ ＦＳ管理データ
１３２２ ファイル管理データ
８４１１ ＨＤＤｗｒｉｔｅキャッシュ
８４１２ メディア
【技術分野】
【０００１】
本発明は、記録再生装置および記録再生方法に関する。詳しくは、障害発生時のデータ修復を行うためのバックアップの技術に関する。
【背景技術】
【０００２】
従来、周期的書換えを必要とするファイルの永続化を行う技術には様々なものがある。例えば、ファイルを２重化する技術がある。この２重化の技術では、オリジナルファイルとバックアップファイルの２つを作成して、ファイル単位で各々をストレージに記録するものである。これによって、どちらかのファイルが破壊または消滅してもシステム的に破綻しないようにされている。
【０００３】
また、ボリュームの破壊耐性を高める技術としてＲＡＩＤがある（例えば、特許文献１参照）。この中で、ボリュームの複製を行う技術は、ＲＡＩＤ１（ミラーリング）である。これは、ストレージへのアクセス単位でファイルがミラーリングされ、ドライバレベルまたはハードウェアレベルで複製が実現されている。複製しない場合に比較して増加する処理については、上記したファイルの二重化の技術ほど大きくはならないというメリットがある。
【０００４】
【特許文献１】特開２００３−２９６０４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、ファイルの二重化の技術では、周期的／頻繁的に変更を伴うファイルを対象とする場合には、パフォーマンスの観点から実現が困難であるという問題があった。
【０００６】
また、上記した特許文献１に開示された技術によれば、パフォーマンスをある程度維持しながら２重化を行うことができるが、ファイルシステムの論理破壊の見地からはトランザクション中に発生した障害におけるファイルの永続は保証できないという問題があった。
【０００７】
現状ではパフォーマンスを維持しながら、論理破壊を防ぎファイルを永続化する技術が確立していない。
【０００８】
本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、パフォーマンスを維持しながら、論理破壊を防ぎファイルを永続化する技術を提供することが可能な、新規かつ改良された技術を提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、本発明のある観点によれば、記録再生装置は、システムコール部からトランザクションの入力を受け付け、トランザクションの処理において必要なリクエストを１または複数生成し、生成した１または複数のリクエストをミラーリクエストキューに登録し、登録し終わると、メモリに記憶されたミラーリング要求フラグに所定の値を設定するファイルシステム部を備える。
【００１０】
また、記録再生装置は、ミラーリクエストキューを有し、ミラーリクエストキューに登録されている１または複数のリクエストをオリジナルボリューム書き込み用リクエストキューに登録し、登録した１または複数のリクエストに対する処理がすべて完了したら、ミラーリング要求フラグを参照し、ミラーリング要求フラグに所定の値が設定されている場合には、ミラーリクエストキューに登録されている１または複数のリクエストをバックアップボリューム書き込み用リクエストキューに登録するトランザクションミラーリングドライバ部を備える。
【００１１】
また、記録再生装置は、オリジナルボリューム書き込み用リクエストキューを有し、リクエストキューから取り出したリクエストを出力するオリジナルボリュームインタフェースドライバ部を備える。
【００１２】
また、記録再生装置は、バックアップボリューム書き込み用リクエストキューを有し、リクエストキューから取り出したリクエストを出力するバックアップボリュームインタフェースドライバ部を備える。
【００１３】
また、記録再生装置は、オリジナルボリュームインタフェースドライバ部から出力されたリクエストに含まれるオリジナルデータをオリジナルボリュームに書き込む処理と、バックアップボリュームインタフェースドライバ部から出力されたリクエストに含まれるバックアップデータをバックアップボリュームに書き込む処理とを制御するストレージ制御部を備える。
【００１４】
かかる構成によれば、ファイルシステム部がリクエストをミラーリクエストキューに登録した後、バックアップの制御はトランザクションミラーリングドライバ部が行うことになる。したがって、ファイルシステム部がリクエストをミラーリクエストキューに登録した後において、ファイルシステム部によるバックアップの制御は不要となる。
【発明の効果】
【００１５】
本発明によれば、パフォーマンスを維持しながら、論理破壊を防ぎファイルを永続化する技術を提供することが可能となる。
【発明を実施するための最良の形態】
【００１６】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１７】
《本実施形態に適用可能な記録再生装置について》
破壊されるとシステムとして致命的損害を与えるファイルの永続的な保証方法としてはいくつかの方法が考えられる。例えば、ファイルの２重化（ファイルのオリジナルファイルとバックアップファイルの２重書込み）およびＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）（ボリュームのミラーリング）という方法である。これらの方法の概念図を図１に示す。
【００１８】
ファイルの２重化とはファイル単位でオリジナルとバックアップの２つを作成することであり、どちらかが破壊および消滅してもシステム的に破綻しない作りとするものである。ここではファイルの２重書込みを行うタイミング（バックアップを行うタイミング）をどうするかが問題となってくる。
【００１９】
設定用ファイルのように頻繁に変更が必要ないファイルであれば、設定を変更する前にバックアップを取っておく。そして、変更内容をストレージに反映させる途中で障害が起きた場合はバックアップ時（変更前）に戻すということで対処でき、変更前に戻したとしてもシステム的影響はない。また、ファイルの２重書込みによる処理の増加もシステム的には許容できるものが殆どである。
【００２０】
しかし、周期的に変更を要するファイルでさらに書込みに対するスループットが厳しい場合には、変更の度に２重書込みを行っていては必要となるスループットが満たせない状況に陥り、システム的に破綻する。２重書き込みを行うタイミングを間引いてしまうと、変更前に戻したときのシステム的影響がでる。
【００２１】
この周期的で且つスループットが必要となる代表例としては、ストリーム記録（放送録画）を行う場合である。ストリーム記録では、ストリームデータはあるレートでシステムに入力され、システムはそのデータをストレージに記録する。ストレージに記録するレートが入力レートより小さい場合はシステムが破綻してしまう。また、このストリーム記録では、記録したコンテンツを再生するために必要な再生用データを周期的にファイルに書き出す必要があり、このファイルが破壊または消滅した場合は再生が出来ないという影響が出る。この再生用データが書かれるファイルが永続的、周期的ファイルである。
【００２２】
ＲＡＩＤとは、ボリュームレベルで冗長を図り、ボリュームの破壊耐性を高める技術である。２重書込みと同じ結果をもたらすものはＲＡＩＤ１（ミラーリング）であり、ボリュームの複製を作成する。これはストレージ（ボリューム）へのアクセス単位でファイルはミラーリングされ、ドライバレベルまたはハードウェア（Ｈ／Ｗ）レベルで実現しており、必要となる処理の増加も２重書込みに比べると小さく、スループットが高い。
【００２３】
ここで、ストレージへの記録済みファイルが破壊および消滅してしまう原因について述べる。ストレージへの記録済みファイルが破壊される原因は、ストレージの物理的な破壊とファイルへのアクセスに必要な管理データが破壊することで起こる論理破壊の２つである。ＲＡＩＤは物理破壊によるファイルの喪失を防ぐものであり、論理破壊を防ぐものではない為、それだけではファイルの永続的な保証はできない。これはファイルシステムがトランザクションを基本として論理保証を行っており、ＲＡＩＤはこのファイルシステムのトランザクションに一切関知していない為である。
【００２４】
論理破壊への耐性としてはファイルシステムレベルでジャーナリングファイルシステム（代表的なものとしてＥＸＴ３、ＸＦＳ）ＬｏｇＢａｓｅファイルシステム（代表的なものとしてＮＩＬＦＳ）を用いるのが一般的である。これらファイルシステムの復旧の目的としてはファイルシステムの論理的整合性を保つことにあり、復旧時に整合性を阻害するデータおよびファイルなどは消去抹消される。よって、ファイルシステムの論理的破壊への耐性ではファイルの永続的保証はできない。
【００２５】
論理破壊の仕組みを代表的なジャーナリングファイルシステムであるＸＦＳで説明する。ＸＦＳのトランザクションについて図２に示す。
【００２６】
まず、書き込みオペレーションによって、トランザクションのアロケーションが実行される（ステップＳ９０１）。ここでは、トランザクション構造体と一意なトランザクション識別子を割り当てる。続いて、ログスペースが確保される（ステップＳ９０２）。ここでは、トランザクションに必要なログスペースがメモリ８１上に確保される。その後、リソース（修正するリソース８２）のロックを行う（ステップＳ９０３）。ここでは、リソース（バッファ、ｉノード、管理領域）の読み込みとロックを行う。
【００２７】
続いて、リソースの修正が行われる（ステップＳ９０４）。ここでは、修正するリソース８２の修正とトランザクションオペレーション構造体（オペレーション内容を記録するために使用する構造体）の作成が行われる。その後、コミットトランザクションが実行される（ステップＳ９０５）。ここでは、リソースの修正情報とトランザクションオペレーションをｉｎ−ｃｏｒｅログに記録する。ｉｎ−ｃｏｒｅログは、メモリ８１上のログ格納領域８３であり、書き出されていないログ８３１、ログスペース８３２、書き出されたログ８３３等により構成されている。
【００２８】
続いて、ｉｎ−ｃｏｒｅログがＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）８４に書き出される（ステップＳ９０６）。これによって、ｄｉｓｋ−ｏｎログ（ＨＤＤ８４に書き出されるログ）がＨＤＤ８４に書き出される。その後、修正されたリソースがフラッシュされる（ステップＳ９０７）。すなわち、修正されたリソースがＨＤＤ８４に書き出される。ログの領域は、メモリ８１上もＨＤＤ８４上もリング上となっている。また、領域８４１は、ＨＤＤ８４上のＸＦＳ ｐａｒｔｉｔｉｏｎである。
【００２９】
トランザクションからファイルおよびファイルシステムの破壊が発生するのはリソースのフラッシュの処理（ステップＳ９０７）中に障害が発生した場合である。それ以外はメモリ８１上での反映なので障害が起きてもストレージ上には変更前の整合が取れた状態でデータが存在している。
【００３０】
ＸＦＳのトランザクション中に変更が加わるリソースとストレージへの反映順序を図３に示す。
【００３１】
図３は、ファイル作成のトランザクション（Ｔｙｐｅ：ＸＦＳ＿ＴＲＡＮＳ＿クリエート）が入力された場合の様子を示している。このトランザクションによって変更されるリソースは５つである。すなわち、ＸＡＧＩ、ＩＡＢＴ、ＩＮＯＤＥ（作成されるファイルのｉｎｏｄｅ）、ｉｎｏｄｅ（ディレクトリのｉｎｏｄｅ）、ＳＢである。修正済みのリソースは、ログが書き戻されるまでメモリ８１上にロックされている。
【００３２】
ＨＤＤ８４には、ＨＤＤｗｒｉｔｅキャッシュ８４１１が存在し、メモリ８１上のリソースが、ＨＤＤｗｒｉｔｅキャッシュ８４１１に書き込まれる。この際、ＴＣＱ／ＮＣＱなどにより書き出し順序に変更があることが予想される。また、ＨＤＤ８４上のメディア８４１２に書き込まれる際にも、書き出し順序の入れ替えがあることが予想される。
【００３３】
このように、リソースのストレージへの反映順序は一意には決まらず、どのリソースが反映済みでどのリソースが反映前のデータか特定できない。
【００３４】
リソースのストレージへの格納位置と書込みリクエストについて図４に示す。図４には、１つのアロケーショングループが示されている。ＸＡＧＦを変更した場合、変更がないＸＦＳＢも書き戻される。同様に、ブロックの一部に対してデータ変更を加えた場合でも、実際にフラッシュされるのは、ブロック単位である。また、１つのｉｎｏｄｅを変更した場合、変更がない他のｉｎｏｄｅ１５個も書き戻される。同様に、１つのｉｎｏｄｅに対して変更を加えた場合でも、実際にフラッシュされるのは、ブロック単位である。
【００３５】
全てのリソースの反映は１つのリクエストでは収まらず複数のリクエストを発行する必要がある。
【００３６】
図５に、ファイルの既存の技術で２重化を行う場合のリクエストとストレージへのコマンド要求の発行の様子を示す。図５において、太矢印は、システムコールを示している。
【００３７】
図６に、ＲＡＩＤ１を使用してミラーを行った場合のリソースがストレージへ反映されている様子を示す。リソースの反映はオリジナル／バックアップ同時並行的に行われるために、書出し途中で障害が発生した場合はオリジナル／バックアップで同じ不整合が生じる。
【００３８】
《本実施形態に適用可能な記録再生装置の課題について》
まとめると、周期的書換えを必要とするファイルの永続化を行おうとすると、
１．ファイルを２重持ちとするのは常等手段ではあるが、周期的／頻繁的に変更を伴うファイルの２重化はパフォーマンスの観点から実現が困難である。
２．パフォーマンスをある程度維持しながら２重化を行う技術としてＲＡＩＤ１があるが、ファイルシステムの論理破壊の見地からはトランザクション中に発生した障害におけるファイルの永続は保証できない。
【００３９】
現状ではパフォーマンスを維持しながら、論理破壊を防ぎファイルを永続化する技術が確立していない。
【００４０】
《本実施形態の目的について》
本実施形態における目的は以下に示すものである。
１．頻繁に更新が必要となるファイルの永続保証を行う。
２．永続保証を行うために費やされる処理時間を最小限に抑える。
３．データ復旧処理時間を最小限に抑える。
４．ファイルシステムが管理しているトランザクションレベルでミラーリングを行う。
５．ファイルシステムが発行する転送要求リクエストにトランザクションタグを付加することにより、どのトランザクションに属しているリクエストかを判別する。
６．ファイルシステムが発行するリクエストにｓｔａｔｕｓを持たせることで転送前／転送終了待ち／転送完了／ミラー転送終了待ち／ミラー転送完了の状態を管理できるようにする。
７．ファイルシステムの管理データは全てトランザクションレベルで２重化対象とすることで、ファイルシステムの論理破壊は理論上ない。
【００４１】
《本実施形態に係る記録再生装置について》
本実施形態に係る記録再生装置の基本概念を図７に示す。これはミラーを行う単位／タイミングをファイルシステムのトランザクションに合わせたものである。
【００４２】
図６に示されている時点で障害が発生した場合は、各リソースは変更が反映される前のものと反映後のものが混在し不整合が生じている。不整合が生じている状態を修復しようとするならば、どのリソースに不整合が生じているかを調べる必要があり、瞬時に修復することはできない。また、その修復においてファイルが破棄されるおそれがある。
【００４３】
それと比較して図７では、図７に示されている時点で障害が発生しても、バックアップボリューム６９内のリソースは変更前の状態で整合がとれている。これにより、障害が発生した場合はバックアップボリューム６９内の情報でオリジナルボリューム６８の情報の修復を行うことにより、変更前の状態に瞬時にもどすことができる。
【００４４】
図８に、本実施形態に係る記録再生装置の機能構成図を示す。なお、記録再生装置における各キューは、メモリ等によって構成される。また、その他の各構成は、専用のハードウェアで構成されていてもよいし、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）で構成されていてもよい。ＣＰＵによって構成される場合には、ＣＰＵによってソフトウェアが実行されることによって、各構成の備える機能が実現される。
【００４５】
ストレージ（オリジナルボリューム１８１およびバックアップボリューム１８２）にデータを記録するプログラムは、システムコール（システムコール部１２０）を用いてファイルの作成を行う。
【００４６】
システムコールは、ファイルシステムのファイルクリエートオペレーション関数を呼び出す。
【００４７】
ファイルシステム（ファイルシステム部１３０）は、ファイルクリエートオペレーションの処理を行う（このファイルクリエートオペレーションの一連の処理をファイルクリエートトランザクションと定義する）。この処理の中ではファイルをクリエートするために必要となるリソースの変更を行い、リクエストを生成し、複製（ミラー）が必要なものに関してはミラーリクエストキュー１４１に登録する。必要なリソースの変更のリクエストを全て登録し終わった時点でミラーリクエストキュー１４１に対してミラーリング要求フラグを設定する。ミラーリクエストキュー１４１は１または複数用意されるものとする。
【００４８】
ファイルシステム部１３０は、システムコール部１２０からトランザクションの入力を受け付け、トランザクションの処理において必要なリクエストを１または複数生成し、生成した１または複数のリクエストをミラーリクエストキュー１４１に登録する。ファイルシステム部１３０は、登録し終わると、記録再生装置内の図示しないメモリに記憶されたミラーリング要求フラグに所定の値を設定する。所定の値とは、データを複製する要求を示す値であり、特に限定されるものではない。
【００４９】
トランザクションミラーリングドライバ部１４０は、ミラーリクエストキュー１４１を有し、ミラーリクエストキュー１４１に登録されている１または複数のリクエストをオリジナルボリューム書き込み用リクエストキュー（リクエストキュー１５１）に登録する。トランザクションミラーリングドライバ部１４０は、登録した１または複数のリクエストに対する処理がすべて完了したら、ミラーリング要求フラグを参照する。ミラーリング要求フラグに所定の値が設定されている場合には、ミラーリクエストキュー１４１に登録されている１または複数のリクエストをバックアップボリューム書き込み用リクエストキュー（リクエストキュー１６１）に登録する。
【００５０】
リクエスト制御部１４２は、ミラーリクエストキュー１４１に登録されているリクエストをオリジナルボリュームインタフェースドライバ部１５０がもつリクエストキュー１５１に登録する。リクエスト制御部１４２は、ミラーリクエストキュー１４１に登録されているミラーリクエストが全て完了で終了するのを監視しながら待つ。ミラーリクエストが全て完了で終了し且つミラーリクエストキュー１４１に対して（記録再生装置の図示しないメモリに記憶されている）ミラーリング要求フラグに所定の値が設定されていた場合、リクエストをバックアップボリュームインタフェースドライバ部１６０のリクエストキュー１６１に登録する。リクエスト制御部１４２は再度、ミラーリクエストが全て完了で終了するのを監視しながら待つ。終了した時点でファイルクリエートオペレーションに対してｒｅｔｕｒｎを返す。また、このときに、ファイルシステム部１３０は、ミラーリング要求フラグに設定されている所定の値をクリアする。
【００５１】
オリジナルボリュームインタフェースドライバ部１５０は、オリジナルボリューム書き込み用リクエストキュー（リクエストキュー１５１）を有し、リクエストキュー１５１から取り出したリクエストを出力する。
【００５２】
バックアップボリュームインタフェースドライバ部１６０は、バックアップボリューム書き込み用リクエストキュー（リクエストキュー１６１）を有し、リクエストキュー１６１から取り出したリクエストを出力する。
【００５３】
ストレージ制御部１７０Ａは、オリジナルボリュームインタフェースドライバ部１５０から出力されたリクエストに含まれるオリジナルデータをオリジナルボリューム１８１に書き込む処理を制御する。また、ストレージ制御部１７０Ａは、バックアップボリュームインタフェースドライバ部１６０から出力されたリクエストに含まれるバックアップデータをバックアップボリュームに書き込む処理を制御する。
【００５４】
図９に、ミラーリクエストキューとノーマルリクエストキュー両方をストレージインタフェースドライバ部内で制御する場合の実装形態を示す。
【００５５】
図１０に、Ｈ／Ｗ（ＩＦコントローラ／ストレージコントローラ）でコマンドをキューイングする場合の実装形態を示す。
【００５６】
《本実施形態に係る記録再生装置が実行する処理の流れについて》
本実施形態に係る記録再生装置が実行する処理の流れを図１１、図１２に示す。
【００５７】
図１１は、永続を必要とするファイルの書込み処理について示す。図１２は、永続化を必要としないファイルの書込み処理について示す。また、図１３には、図１２に示す永続を必要とするファイルの書込みを、ＲＡＩＤコントローラを用いてさらにストレージの破壊についての耐性を向上させた場合について示す。
【００５８】
図１１、図１２、図１３の３つの例において、ファイルを書き出す場合はＦＳ（Ｆｉｌｅ Ｓｙｓｔｅｍ）管理データ１３２１（各図における実線矢印）、ファイル管理データ１３２２（各図における破線矢印）とファイルの中身となるデータ（各図における太矢印）の書出しを必要とする。
【００５９】
図１１において、新たにファイルを作成する場合には、ファイルクリエートシステムコールによりファイル名とファイルの属性情報を付加する。永続化ファイルか通常ファイルかの区別はこの属性情報として与えられる。
【００６０】
ファイルシステム部１３０は、この属性情報およびシステムコールの種別によりトランザクションを決定し、そのトランザクション中でリソース管理部１３２に働きかけ変更が必要な場合はそのリソースを書き出す。この例のリソースはＦＳ管理データ１３２１とファイル管理データ１３２２がそれに相当する。
【００６１】
ファイルシステム部１３０は、永続化ファイルの属性情報によりリソース書出しリクエストを作成する。この際、リクエスト内のデータとしてどのトランザクションのリクエストかを判別するためのトランザクションタグを保持しているものとする。
【００６２】
リクエストは、ファイルシステム部１３０によってトランザクションミラーリングドライバ部１４０のミラーリクエストキュー１４１に繋がれるものとする。図１１では、実線矢印、破線矢印が、それぞれＦＳ管理データ１３２１、ファイル管理データ１３２２の書出しを示している。
【００６３】
トランザクションミラーリングドライバ部１４０は、ミラーリクエストキュー１４１につながれているリクエストを任意のタイミングでオリジナルボリュームインタフェースドライバ部１５０のリクエストキュー１５１に繋ぐ。トランザクションミラーリングドライバ部１４０のリクエスト制御部１４２は、オリジナルボリュームインタフェースドライバ部１５０からの転送終了を待つ。また、トランザクションミラーリングドライバ部１４０は、リクエストのｓｔａｔｕｓである転送前／転送終了待ち／転送完了／ミラー転送終了待ち／ミラー転送完了を管理する。
【００６４】
ファイルシステム部１３０は、トランザクション中に発行すべきリクエストを全てミラーリクエストキュー１４１に繋いだ時点で、ミラーリング実行イベントをトランザクションミラーリングドライバ部１４０に通知する。このときのイベントの情報としてトランザクションタグを通知する。
【００６５】
トランザクションミラーリングドライバ部１４０は、ミラーリング実行イベントに含まれているトランザクションタグと同じタグ情報のリクエストのステータスが全て転送完了するまで待ち、全てのリクエストが転送完了となった時点で全てのリクエストをバックアップボリュームインタフェースドライバ部１６０のリクエストキュー１６１に繋ぐ。トランザクションミラーリングドライバ部１４０は、再度全てのリクエストがミラー転送完了になるのを待ち、全て転送完了した時点でファイルシステム部１３０に転送終了を通知する。ファイルシステム部１３０は、転送終了をシステムコールの戻りとする。
【００６６】
図１２を用いて、永続化を必要としないファイルの書込み処理について説明する。通常ファイルの場合でもＦＳ管理データ１３２１、ファイル管理データ１３２２は、ミラーリングの対象となる。同一ＦＳ上にファイルを格納する場合は、永続化ファイルでも通常ファイルでも同一のデータを扱うため、特にＦＳ管理データ１３２１は、通常ファイルだからといってミラーリングを行わないとＦＳが破壊される恐れがある。よって、ＦＳ管理データ１３２１およびファイル管理データ１３２２は永続化ファイルの場合と同様にミラーリングが行われる。データの書出しだけミラーリングを行わない。
【００６７】
記録再生装置は、ファイルの中身となるデータ（通常ファイル）の書き込み先となるデータブロック１８３をさらに備える。
【００６８】
また、記録再生装置は、データブロックインタフェースドライバ部１６６をさらに備える。データブロックインタフェースドライバ部１６６は、データブロック書き込み用リクエストキュー（リクエストキュー１６７）を有し、リクエストキュー１６７から取り出したリクエストを出力する。
【００６９】
ファイルシステム部１３０は、ファイルの中身となるデータ（通常ファイル）を、リクエストキュー１６７に登録する。
【００７０】
ストレージ制御部１７０Ａは、データブロックインタフェースドライバ部１６６から出力されたリクエストに含まれるデータをデータブロック１８３に書き込む処理をさらに制御する。
【００７１】
図１３を用いて、図１２に示す永続を必要とするファイルの書込みを、ＲＡＩＤコントローラを用いてさらにストレージの破壊についての耐性を向上させた場合について説明する。図１３に示すように、ハードウェア側にストレージ制御部＋ＲＡＩＤ制御部１７０Ｃが存在する。このＲＡＩＤ制御の機能によって、２つのストレージのそれぞれに同一のデータが書き込まれる。これによって、ストレージに対する物理的な破壊からデータを保護することができる。したがって、ファイルシステムが破壊される場合、ファイルが消滅する場合のみならず、ハードディスクが物理的に破壊される場合に対してもデータを復旧することが可能となる。
【００７２】
《本実施形態が奏する効果について》
本実施形態によれば、以下のような効果を奏する。
【００７３】
１．障害発生時の修復が高速に行える。
２．ファイルシステムの修復時にファイルを破棄することなく、永続的に存在させることができる。
３．ファイルを２重に書き込むよりもパフォーマンスが向上する。
４．ミドルウェアは、通常のシステムコールを呼び出すだけでミラーを意識する作りにしなくてもよい。
５．ＲＡＩＤ１のミラーではファイルシステムの整合性を保証できないが、本実施形態では整合性を保証できる。
６．実装はＳ／Ｗ、Ｈ／Ｗ両方で可能である。
７．ミドルウェアはミラーを意図しない作りにすることができるが、ミラーが必要なデータおよびリソースか不必要かはミドルウェアがハンドリングすることができ、ファイルレベルでミラーを行うファイルとミラーを必要としないファイルを混在させることが可能である。
【００７４】
《本実施形態の変形例について》
上記では、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【図面の簡単な説明】
【００７５】
【図１】本実施形態に適用可能な記録再生装置の概念図である。
【図２】ＸＦＳのトランザクションについて示す図である。
【図３】ファイル作成のトランザクションが入力された場合の様子を示す図である。
【図４】１つのアロケーショングループを示す図である。
【図５】ファイルの既存の技術で２重化を行う場合のリクエストとストレージへのコマンド要求の発行の様子を示す図である。
【図６】ＲＡＩＤ１を使用してミラーを行った場合のリソースがストレージへ反映されている様子を示す図である。
【図７】本実施形態に係る記録再生装置の基本概念図である。
【図８】本実施形態に係る記録再生装置の機能構成図を示す図である。
【図９】ミラーリクエストキューとノーマルリクエストキュー両方をストレージインタフェースドライバ部内で制御する場合の実装形態を示す図である。
【図１０】Ｈ／Ｗ（ＩＦコントローラ／ストレージコントローラ）でコマンドをキューイングする場合の実装形態を示す図である。
【図１１】永続を必要とするファイルの書込み処理について示す図である。
【図１２】永続化を必要としないファイルの書込み処理について示す図である。
【図１３】永続を必要とするファイルの書込みを、ＲＡＩＤコントローラを用いてさらにストレージの破壊についての耐性を向上させた場合について示す図である。
【符号の説明】
【００７６】
６８ オリジナルボリューム
６９ バックアップボリューム
８１ メモリ
８２ リソース
８３ ログ格納領域
８４ ＨＤＤ
１２０ システムコール部
１３０ ファイルシステム部
１３２ リソース管理部
１４０ トランザクションミラーリングドライバ部
１４１ ミラーリクエストキュー
１４２ リクエスト制御部
１５０ オリジナルボリュームインタフェースドライバ部
１５１ リクエストキュー
１６０ バックアップボリュームインタフェースドライバ部
１６１ リクエストキュー
１７０Ｃ ＲＡＩＤ制御部
１８１ オリジナルボリューム
１８２ バックアップボリューム
１３２１ ＦＳ管理データ
１３２２ ファイル管理データ
８４１１ ＨＤＤｗｒｉｔｅキャッシュ
８４１２ メディア
【特許請求の範囲】
【請求項１】
システムコール部からトランザクションの入力を受け付け、当該トランザクションの処理において必要なリクエストを１または複数生成し、当該生成した１または複数のリクエストをミラーリクエストキューに登録し、登録し終わると、メモリに記憶されたミラーリング要求フラグに所定の値を設定するファイルシステム部と、
前記ミラーリクエストキューを有し、当該ミラーリクエストキューに登録されている１または複数のリクエストをオリジナルボリューム書き込み用リクエストキューに登録し、登録した当該１または複数のリクエストに対する処理がすべて完了したら、前記ミラーリング要求フラグを参照し、当該ミラーリング要求フラグに前記所定の値が設定されている場合には、前記ミラーリクエストキューに登録されている１または複数のリクエストをバックアップボリューム書き込み用リクエストキューに登録するトランザクションミラーリングドライバ部と、
前記オリジナルボリューム書き込み用リクエストキューを有し、当該リクエストキューから取り出したリクエストを出力するオリジナルボリュームインタフェースドライバ部と、
前記バックアップボリューム書き込み用リクエストキューを有し、当該リクエストキューから取り出したリクエストを出力するバックアップボリュームインタフェースドライバ部と、
前記オリジナルボリュームインタフェースドライバ部から出力されたリクエストに含まれるオリジナルデータをオリジナルボリュームに書き込む処理と、前記バックアップボリュームインタフェースドライバ部から出力されたリクエストに含まれるバックアップデータをバックアップボリュームに書き込む処理とを制御するストレージ制御部と、
を備える、記録再生装置。
【請求項２】
前記ファイルシステム部は、
前記バックアップボリューム書き込み用リクエストキューに登録した１または複数のリクエストに対する処理がすべて完了したら、前記ミラーリング要求フラグに設定されている所定の値をクリアする、
請求項１に記載の記録再生装置。
【請求項３】
前記ファイルシステム部は、
前記リクエストに対して、トランザクションを判別するためのタグを付与する、
請求項２に記載の記録再生装置。
【請求項４】
データブロック書き込み用リクエストキューを有し、当該リクエストキューから取り出したリクエストを出力するデータブロックインタフェースドライバ部
をさらに備え、
前記ファイルシステム部は、
前記ファイルの中身となるデータを、前記データブロック書き込み用リクエストキューに登録し、
前記ストレージ制御部は、
前記データブロックインタフェースドライバ部から出力されたリクエストに含まれるデータを、ファイルの中身となるデータの書き込み先となるデータブロックに書き込む処理をさらに制御する、
請求項３に記載の記録再生装置。
【請求項５】
ファイルシステム部が、システムコール部からトランザクションの入力を受け付け、当該トランザクションの処理において必要なリクエストを１または複数生成し、当該生成した１または複数のリクエストをミラーリクエストキューに登録し、登録し終わると、メモリに記憶されたミラーリング要求フラグに所定の値を設定するステップと、
トランザクションミラーリングドライバ部が、前記ミラーリクエストキューを有し、当該ミラーリクエストキューに登録されている１または複数のリクエストをオリジナルボリューム書き込み用リクエストキューに登録し、登録した当該１または複数のリクエストに対する処理がすべて完了したら、前記ミラーリング要求フラグを参照し、当該ミラーリング要求フラグに前記所定の値が設定されている場合には、前記ミラーリクエストキューに登録されている１または複数のリクエストをバックアップボリューム書き込み用リクエストキューに登録するステップと、
オリジナルボリュームインタフェースドライバ部が、前記オリジナルボリューム書き込み用リクエストキューを有し、当該リクエストキューから取り出したリクエストを出力するステップと、
バックアップボリュームインタフェースドライバ部が、前記バックアップボリューム書き込み用リクエストキューを有し、当該リクエストキューから取り出したリクエストを出力するステップと、
ストレージ制御部が、前記オリジナルボリュームインタフェースドライバ部から出力されたリクエストに含まれるオリジナルデータをオリジナルボリュームに書き込む処理と、前記バックアップボリュームインタフェースドライバ部から出力されたリクエストに含まれるバックアップデータをバックアップボリュームに書き込む処理とを制御するステップと、
を含む、記録再生方法。
【請求項１】
システムコール部からトランザクションの入力を受け付け、当該トランザクションの処理において必要なリクエストを１または複数生成し、当該生成した１または複数のリクエストをミラーリクエストキューに登録し、登録し終わると、メモリに記憶されたミラーリング要求フラグに所定の値を設定するファイルシステム部と、
前記ミラーリクエストキューを有し、当該ミラーリクエストキューに登録されている１または複数のリクエストをオリジナルボリューム書き込み用リクエストキューに登録し、登録した当該１または複数のリクエストに対する処理がすべて完了したら、前記ミラーリング要求フラグを参照し、当該ミラーリング要求フラグに前記所定の値が設定されている場合には、前記ミラーリクエストキューに登録されている１または複数のリクエストをバックアップボリューム書き込み用リクエストキューに登録するトランザクションミラーリングドライバ部と、
前記オリジナルボリューム書き込み用リクエストキューを有し、当該リクエストキューから取り出したリクエストを出力するオリジナルボリュームインタフェースドライバ部と、
前記バックアップボリューム書き込み用リクエストキューを有し、当該リクエストキューから取り出したリクエストを出力するバックアップボリュームインタフェースドライバ部と、
前記オリジナルボリュームインタフェースドライバ部から出力されたリクエストに含まれるオリジナルデータをオリジナルボリュームに書き込む処理と、前記バックアップボリュームインタフェースドライバ部から出力されたリクエストに含まれるバックアップデータをバックアップボリュームに書き込む処理とを制御するストレージ制御部と、
を備える、記録再生装置。
【請求項２】
前記ファイルシステム部は、
前記バックアップボリューム書き込み用リクエストキューに登録した１または複数のリクエストに対する処理がすべて完了したら、前記ミラーリング要求フラグに設定されている所定の値をクリアする、
請求項１に記載の記録再生装置。
【請求項３】
前記ファイルシステム部は、
前記リクエストに対して、トランザクションを判別するためのタグを付与する、
請求項２に記載の記録再生装置。
【請求項４】
データブロック書き込み用リクエストキューを有し、当該リクエストキューから取り出したリクエストを出力するデータブロックインタフェースドライバ部
をさらに備え、
前記ファイルシステム部は、
前記ファイルの中身となるデータを、前記データブロック書き込み用リクエストキューに登録し、
前記ストレージ制御部は、
前記データブロックインタフェースドライバ部から出力されたリクエストに含まれるデータを、ファイルの中身となるデータの書き込み先となるデータブロックに書き込む処理をさらに制御する、
請求項３に記載の記録再生装置。
【請求項５】
ファイルシステム部が、システムコール部からトランザクションの入力を受け付け、当該トランザクションの処理において必要なリクエストを１または複数生成し、当該生成した１または複数のリクエストをミラーリクエストキューに登録し、登録し終わると、メモリに記憶されたミラーリング要求フラグに所定の値を設定するステップと、
トランザクションミラーリングドライバ部が、前記ミラーリクエストキューを有し、当該ミラーリクエストキューに登録されている１または複数のリクエストをオリジナルボリューム書き込み用リクエストキューに登録し、登録した当該１または複数のリクエストに対する処理がすべて完了したら、前記ミラーリング要求フラグを参照し、当該ミラーリング要求フラグに前記所定の値が設定されている場合には、前記ミラーリクエストキューに登録されている１または複数のリクエストをバックアップボリューム書き込み用リクエストキューに登録するステップと、
オリジナルボリュームインタフェースドライバ部が、前記オリジナルボリューム書き込み用リクエストキューを有し、当該リクエストキューから取り出したリクエストを出力するステップと、
バックアップボリュームインタフェースドライバ部が、前記バックアップボリューム書き込み用リクエストキューを有し、当該リクエストキューから取り出したリクエストを出力するステップと、
ストレージ制御部が、前記オリジナルボリュームインタフェースドライバ部から出力されたリクエストに含まれるオリジナルデータをオリジナルボリュームに書き込む処理と、前記バックアップボリュームインタフェースドライバ部から出力されたリクエストに含まれるバックアップデータをバックアップボリュームに書き込む処理とを制御するステップと、
を含む、記録再生方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１０−１５２５３（Ｐ２０１０−１５２５３Ａ）
【公開日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願番号】特願２００８−１７２５９５（Ｐ２００８−１７２５９５）
【出願日】平成２０年７月１日（２００８．７．１）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願日】平成２０年７月１日（２００８．７．１）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]