ストレージデバイス及びファイルシステムの記録方法
【課題】効率よくトランザクションベースでファイルシステムのメタデータ及びアプリケーションの管理データを書き込む方法、そして電源断が発生した場合にトランザクション単位で自動的に修復を行うことができるストレージデバイスを提供する。
【解決手段】一時的な記録領域とメインの記録領域を有し、電源断からデータを修復する機能を有するストレージデバイスであって、ホストから書き込まれたデータを前記一時的な記録領域に格納する手段１と、前記ホストからコミット要求を受けると、前記一時的な記録領域にあるデータを前記メインの記録領域に書き込む手段２と、前記コミット要求を受ける前に電源断が発生した場合に電源投入時に前記一時的な記録領域にあるデータを破棄し、前記コミット要求を受けてから電源断が発生した場合に電源投入時に前記一時的な記録領域にあるデータをメインの記録領域に書き込む手段３とを備え、トランザクションベースでデータを修復する。
【解決手段】一時的な記録領域とメインの記録領域を有し、電源断からデータを修復する機能を有するストレージデバイスであって、ホストから書き込まれたデータを前記一時的な記録領域に格納する手段１と、前記ホストからコミット要求を受けると、前記一時的な記録領域にあるデータを前記メインの記録領域に書き込む手段２と、前記コミット要求を受ける前に電源断が発生した場合に電源投入時に前記一時的な記録領域にあるデータを破棄し、前記コミット要求を受けてから電源断が発生した場合に電源投入時に前記一時的な記録領域にあるデータをメインの記録領域に書き込む手段３とを備え、トランザクションベースでデータを修復する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージデバイス及びファイルシステムの記録方法に係り、特に、アプリケーション、ファイルシステム及びストレージデバイスが全て整合性のある状態で、電源断やシステムクラッシュから障害回復を行うことが可能となる方法に関する。
【背景技術】
【０００２】
電源断やシステムクラッシュに対するファイルシステムの信頼性を確保するために、トランザクション単位で更新されたメタデータをまずジャーナルログに記録してから、目的のメタデータを上書きする手段が取られている。このジャーナル機能を持ったファイルシステムは、一般的にジャーナルファイルシステムと呼ぶ。ジャーナルログを記録することによって、電源断やシステムクラッシュが発生した場合、ジャーナルログによる高速な修復が可能となる。
しかし、一方では、ジャーナルログの記録による性能劣化が発生するという欠点がある。この性能劣化を最小限に抑えるために、更新されたメタデータブロック全体ではなく、アプリケーションからのファイル操作種別と操作対象のファイル、すなわち更新内容をジャーナルログに記録する方法が知られている。（下記、特許文献１参照）
また、例えば、ＤＶＤ−ＲＡＭ（Digital Versatile Disc-Random Access Memory）やＢＤ−ＲＥ（Blu-ray Disc，Rewritable）といった光ディスクにＡＶ（Audio Visual）データをリアルタイムに記録する装置では、書き込み性能を維持するために、ジャーナルログを別の高速な不揮発のフラッシュメモリに記録する手段が取られている。
【０００３】
近年では、安価で大容量のストレージデバイス、そして比較的高価で小容量の高速なストレージデバイスが数多く開発されている。前記大容量のストレージデバイスの例として、フロッピディスク、ハードディスク、光ディスクそしてテープがある。
前記高速なストレージデバイスの例として、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＰＲＯＭ（Programmable Read Only Memory）、ＥＰＲＯＭ（Erasable Programable Read Only Memory）、そしてフラッシュメモリがある。
例えば、ハードディスクの内部や光ディスクを記録するドライブ装置には、高速なＲＡＭタイプのメモリがバッファキャッシュとして使用され、読み込み/書き込み性能を向上させる働きをする。
また、標準規格のＡＴＡ−8で規格化されているハイブリッド型ハードディスクでは、ＲＡＭタイプのメモリと同様に不揮発のフラッシュメモリがバッファキャッシュとして使用される。
不揮発のフラッシュメモリはＮＶ−Ｃａｃｈｅ（non-volatile cache）と呼ばれ、ハードディスク上のどの範囲のブロックアドレスをこのＮＶ−Ｃａｃｈｅにマッピングするかは専用のＡＴＡコマンドで指定可能である。
ＮＶ−Ｃａｃｈｅを用いることによって、電源断が発生してもデータロストが発生しない。さらに、ＯＳを起動するための情報が記録される領域をＮＶ−Ｃａｃｈｅにマッピングすることによって、ＯＳの起動が高速になると言ったメリットがある。
【０００４】
前述したように、比較的高速で小容量のメモリと大容量のストレージデバイスを組み合わせて、それぞれの特徴を生かせることによって、信頼性や性能の向上が期待できる。
以下にいくつかの既知の方法を列挙する。
（１）性能と容量の異なる二つの不揮発のメディアを用いて、この二つのメディアが連続したひとつのアドレス空間を構成するハイブリッド型のストレージシステム。（下記、特許文献２、特許文献３参照）
（２）不揮発のメモリを使ったライトキャッシュを備えるディスクストレージであって、電源断が発生してもライトキャッシュにあるデータがロストしない。また、電源投入時、ライトキャッシュにある未書き込みデータを読み込みディスクに書き込む。（下記、特許文献４参照）
（３）通常の揮発メモリをライトキャッシュに使用し、電源断を検出したときにスピンドルモータにて生成されたＥＭＦ（Electro Motive Force）からの電源を用いて、ライトキャッシュにあるデータを不揮発メモリに書く。また、電源投入時、不揮発メモリにあるデータを読み込みディスクに書き込む。（下記、特許文献５参照）
（４）ディスクストレージのバッファキャッシュとして、不揮発のＭＲＡＭ（Magnetoresistive Random Access Memory）を使用することによって、電源断が発生してもデータがロストしない。（下記、特許文献６参照）
（５）比較的高速で小容量の不揮発メディアと大容量の不揮発メディアを組み合わせたストレージシステムであって、前記高速で小容量の不揮発メディアが使用不可の場合、大容量のメディアのみで運用する。（下記、特許文献７参照）
（６）それぞれ少なくともひとつ以上の揮発メモリと不揮発メモリを備えるディスク制御装置であって、不揮発メモリは揮発メモリにあるライトキャッシュデータをバックアップするために使用する。（下記、特許文献８参照）
【０００５】
なお、本願発明に関連する先行技術文献としては以下のものがある。
【特許文献１】特開２００４−７８４６１号公報
【特許文献２】米国特許第７，３０８，５３１号明細書
【特許文献３】米国特許第６，７８５，７６７号明細書
【特許文献４】米国特許第６，５１６，４２６号明細書
【特許文献５】米国特許第６，２９５，５７７号明細書
【特許文献６】米国特許第６，７９８，５９９号明細書
【特許文献７】米国特許第７，３０２、５３４号明細書
【特許文献８】米国特許第５，５８６，２９１号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００６】
前述したように、電源断やシステムクラッシュに対応するための方法として、ファイルシステムはジャーナルログを記録する。このジャーナルログの記録による性能劣化を最小限にするために、ジャーナルログをより高速な不揮発のメモリに記録する方法では、不揮発メモリ及びそれを制御するハードウェアやソフトエアが必要になり、システムが高価になるという欠点がある。
また、メタデータの更新内容をジャーナルログに記録する方法では、修復処理がファイルシステムのフォーマットやファイルシステムがサポートするファイル操作に依存するため、処理が複雑という問題点がある。
同様にストレージデバイスは、電源断に対応するために不揮発のメモリを用いてデータの修復を行っている。しかし、ストレージデバイスで行っている修復処理はあくまでもホストから書き込まれた全てのデータを修復するものである。そのデータは、中途半端なファイルシステムのメタデータあるいは中途半端なアプリケーションの管理データの場合があり、逆に修復しない方が良いケースもある。
本発明は、前記従来技術の問題点を解決するためになされたものであり、本発明の目的は、効率よくトランザクションベースでファイルシステムのメタデータ及びアプリケーションの管理データを書き込む方法、そして電源断が発生した場合にトランザクション単位で自動的に修復を行うことができるストレージデバイスを提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
【課題を解決するための手段】
【０００７】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、下記の通りである。
前述の目的を達成するために、本発明においては、比較的高速で小容量の不揮発ストレージメディアと大容量のストレージメディアを組み合わせ、大容量のストレージメディアはメインのデータ記録領域として、高速なストレージメディアは一時的な記録領域として使用する。大容量のストレージメディアの一部のブロック（セクタ）アドレス空間は一時的な記録領域にマッピングし、マッピングするブロックアドレス空間を設定するコマンドを用意し、前記コマンドによってマッピングされたブロックアドレス空間に書き込まれたデータは一時的な記録領域に先ず格納する。一時的な記録領域に書き込んだデータをコミットするためのコマンドを用意し、前記コミットコマンドを受けると、一時的な記録領域に格納されたデータをメインのデータ記録領域に書き込み、前記コミットコマンドを受ける前に電源断が発生する場合、電源投入時に一時的な記録領域に格納されたデータを破棄し（ロールバック）、前記コミットコマンドを受け取ってから電源断が発生する場合、電源投入時に一時的な記録領域に格納されたデータを前記メインのデータ記録領域に書き込み（ロールフオーワード）、トランザクションベースでデータの修復を自動的に行うことを特徴とするストレージデバイスである。
【０００８】
前記トランザクションベースでデータ修復機能を備えたストレージデバイスを用いたファイルシステムでは、ファイルシステムのメタデータ及び特定のファイルデータの格納位置を一時的な記録領域にマッピングされたブロックアドレス空間から割り当て、前記特定のファイルはファイルの属性、ファイルのサイズまたはファイルの名称を用いて判定する。前記特定のファイルデータをコミットするためのインタフェースを用意し、例えば、アプリケーションが「ファイル１」にデータを追記してから、「ファイル２」のデータを更新するという一連のファイル操作を行った後、前記ファイルシステムのコミットインタフェースを用いてコミット要求を発行し、前記ファイルシステムは前記コミット要求を受けると、まだ書き込んでいないメタデータ及び前記ファイル１及びファイル２のデータがあれば、全部前記ストレージデバイスに書き込んでからコミットコマンドを発行する。
例えば、アプリケーションが「ファイル１」にデータを追記してから、「ファイル２」のデータを更新中に電源断が発生する場合、アプリケーションがコミット要求を発行していないため、電源投入時に本発明のストレージデバイスが自動的にロールバック処理を行い、アプリケーションのファイルデータおよびファイルシステムのメタデータが元の処理前の状態に戻る。
また、アプリケーションがコミット要求を発行し、ファイルシステムが更新されたメタデータ及びファイルデータを書き込んで、前記ストレージデバイスにコミットコマンドを発行してから電源断が発生する場合、電源投入時に本発明のストレージデバイスが自動的にロールフォーワード処理を行い、アプリケーションがファイル操作を行った後の状態にする。
【０００９】
ＡＶデータを記録再生する装置において、例えば、ファイルシステムのフォーマットとしてＵＤＦ（Universal Disc Format）を用いた場合、ＡＶデータをリアルタイム属性のファイルのメインデータストリームに記録する。
前記ＵＤＦはＮＴＦＳ（New Technology File System）と同様に複数のデータストリーム（multiple data stream）をサポートしており、ひとつのファイルには、通常のアプリケーションから見えるメインデータストリームと複数の名前付きストリーム（named stream）を記録することが可能である。
前記名前付きストリームには、例えば、アイコン情報、ＡＶファイルであればプレイバック情報（playback info）やサムネール情報（thumbnail info）を記録することが可能である。
ＡＶデータは容量が大きいため、通常、ライトキャッシュを用いず直接ストレージメディアに書き込む（Direct I/0）ことが多い。本発明のデータ記録方法でも、ＡＶデータはトランザクションベースの修復対象にしない方が望ましい。
前記ＵＤＦファイルシステムを用いた場合は、前記リアルタイム属性を用いて、ＡＶデータを他のファイルデータと区別することが可能である。
【００１０】
前記ＡＶデータ記録再生する装置のような場合、ストレージデバイスには大容量のＡＶデータを書き込み、ファイルシステムのメタデータ及びＡＶアプリケーションの管理データが比較的小容量になるため、前述したような本発明のストレージデバイス及び記録方法で十分に運用が可能である。
しかしながら、例えば、データベースシステムやファイルサーバなどでは、テンポラリファイルなどを除いて基本的に全てのファイルデータをトランザクションベースの修復対象にしなければならない。この場合には、以下のようなストレージデバイス及び記録方法が望ましい。
前記一時的な記録領域を前記メインのデータ記録領域にマッピングするのではなく、トランザクションデータ用のライトコマンドを別途用意し、前記コマンドで書き込まれたデータを全て一時的な記録領域に書き込み、ホストからコミットコマンドを受けると前記一時的な記録領域に格納されたデータを「コミット済み」状態と登録してから、前記データを前記メインのデータ記録領域に書き込み、前記コミットコマンドを受ける前に電源断が発生する場合、電源投入時に前記一時的な記録領域に格納されたデータを破棄し（ロールバック）、前記コミットコマンドを受け取ってから電源断が発生する場合、電源投入時に前記一時的な記録領域に格納されたデータを前記メインのデータ記録領域に書き込み（ロールフォーワード）、トランザクションベースでデータの修復を自動的に行う。
【００１１】
また、前述の特許文献５に記載されているような技術を応用し、一時的な記録領域として、通常の揮発メモリを使用し、電源断を検出したときに、トランザクションデータ用のライトコマンドで書き込まれたデータで、なおかつ、既にコミットされたものを不揮発のメモリにバックアップし、電源投入時に前記不揮発メモリにバックアップされたデータをメインのデータ記録領域に書き込み（ロールフォーワード）、トランザクションベースでデータの修復を自動的に行う。
なお、ファイルシステムは、前記トランザクションデータ用のライトコマンドを用いてメタデータ及び特定のファイルデータを書き込み、アプリケーションからのコミット要求を受けると、まだ書き込んでいないメタデータ及びファイルデータがあれば、全部前記ストレージデバイスに書き込んでからコミットコマンドを発行する。また、例えばテンポラリファイルのデータの書き込みでは、通常の非トランザクションデータ用のライトコマンドを用いても構わない。
【発明の効果】
【００１２】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、下記の通りである。
本発明によれば、非常に単純で簡単な方法で、アプリケーション、ファイルシステムとストレージデバイスが連携し、効率よくトランザクションベースでファイルシステムのメタデータ及びアプリケーションの管理データを書き込むことができ、電源断が発生した場合にストレージデバイスがトランザクションベースで自動的に修復を行うことが可能となる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して本発明の実施例を詳細に説明する。
なお、実施例を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
［実施例１］
先ず、図１は、ＡＶデータ記録再生装置またはパーソナルコンピュータのソフトウェア／ハードウェアの概略図である。
図１において、１０１はＡＶデータ記録再生装置またはパーソナルコンピュータ、１０２はアプリケーション、１０３はファイルシステムドライバ、１０４はデバイスドライバ、１０５はストレージデバイスである。
アプリケーション１０２の具体例としては、例えば、ＡＶデータを扱うアプリケーションまたはデータベースファイルを管理するデータベースアプリケーションがある。
ファイルシステムドライバ１０３は、ファイルシステムのフォーマット（例えば、ＵＤＦ）に基づき、ファイル／ディレクトリを管理するソフトウェアモジュールであり、これにより前記アプリケーション１０２がファイル／ディレクトリの作成、ファイルデータの読み書き、ディレクトリの閲覧などを行うことが可能となる。
デバイスドライバ１０４は、ストレージデバイス１０５を認識し、アプリケーション１０２やファイルシステムドライバ１０３にストレージデバイス１０５ヘのブロック（セクタ）データの読み書き、そしてデバイス情報の取得やフラッシュキャッシュなど特定のコマンドを発行するインタフェースを提供している。
【００１４】
図２は、本発明の実施例１のＡＶデータ記録再生装置におけるトランザクションベースストレージデバイス及びその記録方法を説明する図である。
図２において、２０１はファイルシステムのボリュームレイアウト、２０２はファイルシステムのメタデータ領域、２０３はＡＶアプリケーションの管理データ領域、２０４はＡＶデータ領域を示す。
また、２０５は本実施例のストレージデバイス、２０６は不揮発のメディアを使用した一時的な記録領域、２０７は管理情報領域、２０８はマッピング領域、２０９は予備領域、２１０は揮発のメディア（メモリ）を使用したバッファキャッシュ、２１１は不揮発のメディアを使用したメインデータ記録領域を示す。
本実施例では、ファイルシステムのメタデータ及びＡＶアプリケーションの管理データをトランザクションデータとして扱い、これらのデータは一時的な記録領域２０６にマッビングされるアドレス空間に格納される。なお、アドレス空間のマッピング方法として、メインデータ記録領域の先頭から一定サイズの領域を予めマッピングする固定式マッピング方法と、専用のコマンドでマッビングする領域を指定する可変式マッピング方法がある。どちらの方式の場合でも、本実施例のストレージデバイス２０５は、どのアドレス空間が一時的な記録領域にマッピングされるかを取得するコマンドを用意することが望ましい。
【００１５】
前記コマンドを用いて、ファイルシステムドライバ１０３がトランザクション対象の領域を知ることができ、ファイルシステムのメタデータ及びＡＶアプリケーションの管理データを前記トランザクション対象の領域に記録することが可能となる。
なお、本実施例、あるいは、後述する実施例２において、トランザクション対象あるいはトランザクション非対象の領域にファイルデータを書き込むか否かは、当該ファイルが記録される親ディレクトリ、または、当該ファイル自身のファイル属性、または、当該ファイル自身の名称の一部あるいは全部、あるいは、当該ファイルのサイズを用いて判断する。また、なお、図２においては、例として、トランザクション対象の領域がセクタ番号０からＡまでの領域となっている。
一時的な記録領域２０６は、不揮発のメディアを使用しており、実際にメインデータ記録領域２１１の特定のアドレス空間のマッピング領域２０８以外に、前記不揮発メディアの寿命や欠陥セクタを考慮し、交替処理用の予備領域２０９を設けることが望ましい。なお、管理情報領域２０７には、一時的な記録領域２０６のアドレス空間対メインデータ記録領域２１１のアドレス空間のマッピングテーブル、各アドレスに記録されているデータの状態（更新なし／更新あり／コミット済み）、交替セクタ情報を記録する。
【００１６】
次に、図３から図５を用いて、本実施例１におけるストレージデバイス２０５の書き込み処理、コミット処理及び修復処理を説明する。
図３は、本実施例におけるストレージデバイス２０５のデータ書き込み処理を示すフローチャートである。
本実施例において、トランザクションデータであるファイルシステムのメタデータ及びＡＶアプリケーションの管理データ、そして非トランザクションデータであるＡＶデータは、全て同じインタフェースを用いて書き込むことが可能である。
ストレージデバイス２０５は、書き込み対象のアドレスが一時的な記録領域２０６にマッピングされているかを確認する（ステップ３０１）。
書き込み対象のアドレスが一時的な記録領域２０６にマッピングされていない場合は、通常のバッファキャッシュ２１０にデータを書き込む（ステップ３０２）。
書き込み対象のアドレスが一時的な記録領域２０６にマッピングされている場合、書き込み対象アドレスを「更新あり」状態と管理情報領域２０７に登録し（ステップ３０３）、マッピング領域２０８にデータを書き込む（ステップ３０４）。
【００１７】
図４は、本実施例におけるストレージデバイス２０５のコミット処理を示すフローチャートである。
先ず、「更新あり」のデータが一時的な記録領域２０６に存在するかを確認する（ステップ４０１）。ステップ４０１において、「更新あり」のデータが存在しない場合は、コミット処理を終了する。
ステップ４０１において、「更新あり」のデータが存在する場合は、前記データを「コミット済み」状態と管理情報領域２０７に登録し（ステップ４０２）、前記更新されたデータを読み込み、メインデータ記録領域２１１に書き込む（ステップ４０３）。
最後に、前記データを「更新なし」状態と管理情報領域２０７に登録する（ステップ４０４）。
前記コミット処理は、アプリケーション１０２またはファイルシステムドライバ１０３からコミット要求を受けるときに実行される。
ファイルシステムドライバ１０３は、ひとつのトランザクションごとにメタデータを更新してからコミット要求を発行するか、複数のトランザクション分のメタデータを更新してからコミット要求を発行することが可能である。
なお、ＡＶアプリケーションの管理データの書き込みが伴う場合は、アプリケーション１０２からのコミット要求を受けてから、コミット処理を行うことで、ファイルシステムのメタデータとＡＶアプリケーションの管理データが整合性のある状態で修復が可能となる。
【００１８】
図５は、本実施例におけるストレージデバイス２０５の修復処理を示すフローチャートである。
修復処理は、ストレージデバイス２０５の電源投入時に実行される。先ず、管理情報領域２０７を読み込み（ステップ５０１）、管理情報領域を基に、未書き込みデータがあるかを判定する（ステップ５０２）。ステップ５０２において、未書き込みデータがない（即ち、全データが「更新なし」という状態にある）場合は、修復処理を終了し、通常の電源投入時の処理に移る。
ステップ５０２において、未書き込みデータがある場合は、前記未書き込みデータがコミットされたかどうかを判定する（ステップ５０３）。
ステップ５０３において、前記未書き込みデータがコミット済みの場合は、前記コミット済みデータをメインデータ記録領域２１１に書き込むロールフォワード処理を行い（ステップ５０５）、前記データを「更新なし」状態と管理情報領域２０７に登録することで、前記データの状態を「コミット済み」から「更新なし」状態に変更する（ステップ５０７）。
ステップ５０３において、前記データがコミットされていない（「更新あり」状態）場合は、メインデータ記録領域２１１にある更新前データを読み込み一時的な記録領域２０６にある更新後データに上書きするロールバック処理を行い（ステップ５０４）、前記データを「更新なし」状態と管理情報領域２０７に登録することで、前記データの状態を「更新あり」から「更新なし」状態に変更する（ステップ５０６）。
【００１９】
前述したように、前記一時的な記録領域２０６にマッピングされたデータが「更新なし」、「更新あり」および「コミット済み」の状態にあるかを管理することで、アプリケーション１０２あるいはファイルシステムドライバ１０３が意図するポイント（状態）にロールバックあるいはロールフォワード処理を行うことが可能となる。
なお、前記書き込み処理で行う「更新あり」状態に変更するステップ３０３、前記コミット処理で行う「更新あり」から「コミット済み」状態に変更するステップ４０２と「コミット済み」から「更新なし」状態に変更するステップ４０４、そして前記修復処理で行う「更新あり」から「更新なし」状態に変更するステップ５０６と、「コミット済み」から「更新なし」状態に変更するステップ５０７は、中途半端な状態が許されない。
そのためには、管理情報領域２０７に各々の状態を登録する処理ではリングバッファ方式を用いて、直前の状態を表すデータを上書きせず、次の領域に新しい状態を表すデータを格納するとともに、チェックサムを用いて変更処理が完全に完了したかどうかを判断する。
【００２０】
［実施例２］
図６は、本発明の実施例２であるデータベースシステムにおけるトランザクションベスストレージデバイス及びその記録方法を示す図である。
図６において、６０１はファイルシステムのボリュームレイアウト、６０２はファイルシステムのメタデータ、６０３はデータベースファイルのデータ、６０４はファイルシステムのメタデータ、６０５はテンポラリファイルのデータ、６０６はその他データを示す。 また、６０７は本実施例のストレージデバイス、６０８は揮発のメディアを使用した一時的な記録領域、６０９は管理情報領域、６１０はバッファキャッシュ領域、６１１は不揮発のメディアを使用したバックアップメディア、６１２は管理情報、６１３はバックアップ領域、６１４は不揮発のメディアを使用したメインデータ記録領域を示す。
本実施例２では、ファイルシステムのメタデータに加え、全データベースファイルのデータをトランザクションデータとして扱うことが望ましい。なお、テンポラリファイルなどのデータは非トランザクションデータとして扱っても構わない。
【００２１】
データベースファイルのデータが大量で頻繁に更新されるため、データベースシステムに適した本実施例では、一時的な記録領域６０８として寿命がより長く、性能の良い揮発メディアを使用した方が望ましい。すなわち、通常のバッファキャッシュをトランザクションデータの一時的な記録領域と兼用する。
その代わり、メインデータ記録領域６１４のメディアより消費電力の少ない不揮発のメディアを用いたバックアップメディア６１１を用意し、電源断を検出する際に、コミットされたトランザクションデータを前記バックアップメディア６１１にバックアップする。
なお、トランザクションデータあるいは非トランザクションデータかを区別するためには、前記ストレージデバイス６０７が専用のトランザクションデータ用書き込みコマンドを用意する。
同様に、ファイルシステムドライバ１０３も専用のトランザクションデータ用書き込みインタフェースをアプリケーション１０２に提供する。
【００２２】
次に、図７から図１０を用いて、本実施例におけるストレージデバイス６０７の書き込み処理、コミット処理、バックアッブ処理及び修復処理を説明する。
図７は、本実施例におけるストレージデバイス６０７のデータ書き込み処理を示すフローチャートである。
ストレージデバイス６０７は、最初にバッファキャッシュ６１０に空きがあるかを確認し（ステップ７０１）、ステップ７０１において、バッファキャッシュ６１０に空きがない場合は、バッファキャッシュ６１０にある未書き込みデータをメインデータ記録領域６１４に吐き出す遅延書き込み処理を行う（ステップ７０２）。
前記遅延書き込み処理は、バッファキャッシュを備えるストレージデバイスにおいて一般的に使用されるものである。なお、前記遅延書き込み処理で吐き出すデータは非トランザクションデータのみとする。
ステップ７０１において、バッファキャッシュ６１０に空きがある場合は、バッファキャッシュ６１０にデータを書き込み（ステップ７０３）、前記データがトランザクションデータかを判定する（ステップ７０４）。
ステップ７０４での判定結果が、前記データが非トランザクションデータの場合は、管理情報領域６０９に前記データが未書き込みの非トランザクションデータであると記録する（ステップ７０５）。
ステップ７０４での判定結果が、前記データがトランザクションデータの場合は、管理情報領域６０９に前記データが未書き込みのトランザクションデータであると記録する（ステップ７０６）。
【００２３】
図８は、本実施例におけるストレージデバイス６０７のコミット処理を示すフローチャートである。
ストレージデバイス６０７は、最初に未書き込みのトランザクションデータがあるかを判定し（ステップ８０１）、ステップ８０１において、未書き込みのトランザクションデータが存在しない場合は、コミット処理を終了する。
ステップ８０１において、未書き込みのトランザクションデータが存在する場合は、管理情報領域６０９に「コミット済み」状態を記録し（ステップ８０２）、コミットされた前記トランザクションデータをメインデータ記録領域６１４に書き込む（ステップ８０３）。
最後に管理情報領域６０９に「更新なし」状態を記録する（ステップ８０４）。なお、非トランザクションデータは、このコミット処理でトランザクションデータと一緒にメインデータ記録領域６１４に吐き出しても良い。
【００２４】
図９は、本実施例におけるストレージデバイス６０７のバックアップ処理示すフローチャートである。
ストレージデバイス６０７は、電源断を検出する際に、例えば、前述の特許文献５に記載されている方法を用いて、必要なデータのバックアッブ処理を行うための電源を供給する。
前記バックアップ処理では、最初に未書き込みのトランザクションデータがコミットされたかどうかを判定し（ステップ９０１）、ステップ９０１において、コミットされていない場合は、バックアップ処理を終了する。
ステップ９０１において、コミットされている場合は、該当するデータをバックアップメディア６１１のバックアップ領域６１３に書き込み（ステップ９０２）、前記バックアッブしたデータの情報（セクタ番号、セクタ数）をバックアップメディア６１１の管理情報６１２に書き込む（ステップ９０３）。
【００２５】
図１０は、本実施例におけるストレージデバイス６０７の修復処理を示すフローチャートである。
修復処理は前記ストレージデバイスの電源投入時に実行される。先ず、管理情報６１２を読み込み（ステップ１００１）、前記管理情報を基に、バックアッブデータがあるかを判定する（ステップ１００２）。
ステップ１００２において、バックアップデータが存在しない場合は、修復処理を終了し、通常の電源投入時の処理に移る。
ステップ１００２において、バックアップデータが存在する場合は、前記バックアップデータを読み込み、メインデータ記録領域６１４に書き込むロールフォワード処理を行い（ステップ１００３）、管理情報６１２をクリアする（ステップ１００４）。
前述したように、一時的な記録領域６０８に格納されたトランザクションデータがコミットされた状態の場合、電源断を検出するときに、トランザクションデータをバックアップメディア６１１にバックアップすることで、電源投入時の修復処理でロールフォワード処理を行うことが可能となる。なお、前記一時的な記録領域６０８は揮発のメディアを用いるため、次の電源投入時には全データが無効となり、コミットされていないデータのロールバック処理を行う必要がない。
【００２６】
図１１は、本実施例１または実施例２における、アプリケーション及びファイルシステムドライバがストレージデバイスと連携し、トランザクションベースで処理する例を示す処理シーケンスである。
図１１において、１１０１はアプリケーション、１１０２はファイルシステムドライバ、１１０３はトランザクションベースストレージデバイスを示す。また、図１１において、アプリケーションが２つのファイルである「ファイル１」と「ファイル２」を開き、「ファイル１」にデータを追記書き込み、「ファイル２」のデータを一部上書きする一連の処理をひとつのトランザクションである例を示す。
以下に、順番にアプリケーション１１０１の各ステップについて説明する。
先ず、アプリケーション１１０１は、「ファイル１」を開く（ステップ１１０４）。これに対して、ファイルシステムドライバ１１０２は、「ファイル１」を検索し、メモリ上で管理オブジェクトを作成する（ステップ１１０５）。
ファイルシステムドライバ１１０２は、通常オープンされた各々のファイル／ディレクトリに対して、ファイル／ディレクトリのメタデータなどを格納するための管理オプジェクトを作成する。例えば、ＯＳがＷｉｎｄｏｗｓの場合ではファイルオブジェクト、ＯＳがＬｉｎｕｘの場合ではｉｎｏｄｅという管理オプジェクトを作成する。
次に、アプリケーション１１０１は、「ファイル２」を開く（ステップ１１０６）。これに対して、ファイルシステムドライバ１１０２は、「ファイル２」を検索し、メモリ上で管理オブジェクトを作成する（ステップ１１０７）。
【００２７】
次に、アプリケーション１１０１が、「ファイル１」にデータを追記書き込む（ステップ１１０８）。これに対して、ファイルシステムドライバ１１０２が、追加データ用領域を確保し、ファイルシステムのメタデータを更新する（ステップ１１０９）。
ファイルシステムメタデータは、例えば、各ブロックの使用状態を表すスペースビットアップ、「ファイル１」のデータの位置を表すエクステントテーブル、「ファイル１」のサイズ情報、「ファイル１」の更新日時情報を指す。そして、ファイルシステムドライバ１１０２が前記追加データを前記エクステントテーブルの位置情報に基づいて、ストレージデバイス１１０３に書き込む（ステップ１１１０）。
次に、アプリケーション１１０１が「ファイル２」のデータを一部上書きする（ステップ１１１１）。これに対して、ファイルシステムドライバ１１０２が、データを「ファイル２」のエクステントテーブルの位置情報に基づいて、ストレージデバイス１１０３に書き込み（ステップ１１１２）、「ファイル２」のメタデータ（更新日時情報）を更新する（ステップ１１１３）。
次に、ひとつのトランザクションのデータ更新が全て完了したため、アプリケーション１１０１がファイルシステムドライバ１１０２にコミット要求を発行する（ステップ１１１４）。これに対して、ファイルシステムドライバ１１０２が、未書き込みのメタデータ及びファイルデータをストレージデバイス１１０３に書き込み（ステップ１１１５）、コミット要求をストレージデバイス１１０３に発行する（ステップ１１１６）。
ファイルシステムドライバ１１０２は、性能向上を目的に、頻繁に更新されるデータを一時的にライトキャッシュに格納することが望ましい。そのため、アプリケーション１１０１からコミット要求を受けるときに、未書き込みのメタデータ及びファイルデータが存在する場合がある。
【００２８】
図１１に示すアプリケーション１１０１、ファイルシステムドライバ１１０２及びストレージデバイス１１０３の連携処理は、前述の実施例１と実施例２の両方の場合に適用できる。
実施例１の場合は、全てのデータを同じインタフェース／コマンドで書き込む。それに対して、実施例２の場合は、アプリケーション１１０１がトランザクションデータを専用のインタフェースで書き込み、またファイルシステムドライバ１１０２が書き込み時に使用したインタフェースによって各ファイルデータがトランザクションデータかどうかを管理し、専用のコマンドでストレージデバイス１１０３にトランザクションデータを書き込む。なお、実施例２において、全てのデータをトランザクションデータとし、全てのデータを同じインタフェース／コマンドで書き込むことが可能である。
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本
発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【図面の簡単な説明】
【００２９】
【図１】ＡＶデータ記録再生装置またはパーソナルコンピュータの概略図である。
【図２】本発明の実施例１のＡＶデータ用ストレージデバイス及びその記録方法を示す概略図である。
【図３】本発明の実施例１のＡＶデータ用ストレージデバイスにおけるデータの書き込み処理の流れの一例を示すフローチャートである。
【図４】本発明の実施例１のＡＶデータ用ストレーンデバイスにおけるコミット処理の流れの一例を示すフローチャートである。
【図５】本発明の実施例１のＡＶデータ用ストレージデバイスにおけるデータの修復処理の流れの一例を示すフローチャートである。
【図６】本発明の実施例２のデータベース用ストレージデバイス及びその記録方法を示す概略図である。
【図７】本発明の実施例２のデータベース用ストレージデバイスにおけるデータの書き込み処理の流れの一例を示すフローチャートである。
【図８】本発明の実施例２のデータベース用ストレージデバイスにおけるコミット処理の流れの一例を示すフローチャートである。
【図９】本発明の実施例２のデータベース用ストレーンデバイスにおけるバックアップ処理の流れの一例を示すフローチャートである。
【図１０】本発明の実施例２のデータベース用ストレージデバイスにおける修復処理の流れの一例を示すフローチャートである。
【図１１】アプリケーション、ファイルシステムドライバ及ゲストレーンデバイスの連携処理の流れの一例を示す処理シーケンスである。
【符号の説明】
【００３０】
１０１ ＡＶデータ記録再生装置またはパーソナルコンピュータ
１０２，１１０１ アプリケーション
１０３，１１０２ ファイルシステムドライバ
１０４ デバイスドライバ
１０５ ストレージデバイス
２０１，６０１ ファイルシステムのボリュームレイアウト
２０２，６０２，６０４ ファイルシステムのメタデータ領域
２０３ ＡＶアプリケーションの管理データ領域
２０４ ＡＶデータ領域
２０５，６０７，１１０３ ストレージデバイス
２０６ 不揮発のメディアを使用した一時的な記録領域
２０７ 管理情報領域
２０８ マッピング領域
２０９ 予備領域
２１０ 揮発のメディア（メモリ）を使用したバッファキャッシュ
２１１ 不揮発のメディアを使用したメインデータ記録領域
６０３ データベースファイルのデータ
６０５ テンポラリファイルのデータ
６０６ その他データ
６０８ 揮発のメディアを使用した一時的な記録領域
６０９ 管理情報領域
６１０ バッファキャッシュ領域
６１１ 不揮発のメディアを使用したバックアップメディア
６１２ 管理情報
６１３ バックアップ領域
６１４ 不揮発のメディアを使用したメインデータ記録領域
【技術分野】
【０００１】
本発明は、ストレージデバイス及びファイルシステムの記録方法に係り、特に、アプリケーション、ファイルシステム及びストレージデバイスが全て整合性のある状態で、電源断やシステムクラッシュから障害回復を行うことが可能となる方法に関する。
【背景技術】
【０００２】
電源断やシステムクラッシュに対するファイルシステムの信頼性を確保するために、トランザクション単位で更新されたメタデータをまずジャーナルログに記録してから、目的のメタデータを上書きする手段が取られている。このジャーナル機能を持ったファイルシステムは、一般的にジャーナルファイルシステムと呼ぶ。ジャーナルログを記録することによって、電源断やシステムクラッシュが発生した場合、ジャーナルログによる高速な修復が可能となる。
しかし、一方では、ジャーナルログの記録による性能劣化が発生するという欠点がある。この性能劣化を最小限に抑えるために、更新されたメタデータブロック全体ではなく、アプリケーションからのファイル操作種別と操作対象のファイル、すなわち更新内容をジャーナルログに記録する方法が知られている。（下記、特許文献１参照）
また、例えば、ＤＶＤ−ＲＡＭ（Digital Versatile Disc-Random Access Memory）やＢＤ−ＲＥ（Blu-ray Disc，Rewritable）といった光ディスクにＡＶ（Audio Visual）データをリアルタイムに記録する装置では、書き込み性能を維持するために、ジャーナルログを別の高速な不揮発のフラッシュメモリに記録する手段が取られている。
【０００３】
近年では、安価で大容量のストレージデバイス、そして比較的高価で小容量の高速なストレージデバイスが数多く開発されている。前記大容量のストレージデバイスの例として、フロッピディスク、ハードディスク、光ディスクそしてテープがある。
前記高速なストレージデバイスの例として、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＰＲＯＭ（Programmable Read Only Memory）、ＥＰＲＯＭ（Erasable Programable Read Only Memory）、そしてフラッシュメモリがある。
例えば、ハードディスクの内部や光ディスクを記録するドライブ装置には、高速なＲＡＭタイプのメモリがバッファキャッシュとして使用され、読み込み/書き込み性能を向上させる働きをする。
また、標準規格のＡＴＡ−8で規格化されているハイブリッド型ハードディスクでは、ＲＡＭタイプのメモリと同様に不揮発のフラッシュメモリがバッファキャッシュとして使用される。
不揮発のフラッシュメモリはＮＶ−Ｃａｃｈｅ（non-volatile cache）と呼ばれ、ハードディスク上のどの範囲のブロックアドレスをこのＮＶ−Ｃａｃｈｅにマッピングするかは専用のＡＴＡコマンドで指定可能である。
ＮＶ−Ｃａｃｈｅを用いることによって、電源断が発生してもデータロストが発生しない。さらに、ＯＳを起動するための情報が記録される領域をＮＶ−Ｃａｃｈｅにマッピングすることによって、ＯＳの起動が高速になると言ったメリットがある。
【０００４】
前述したように、比較的高速で小容量のメモリと大容量のストレージデバイスを組み合わせて、それぞれの特徴を生かせることによって、信頼性や性能の向上が期待できる。
以下にいくつかの既知の方法を列挙する。
（１）性能と容量の異なる二つの不揮発のメディアを用いて、この二つのメディアが連続したひとつのアドレス空間を構成するハイブリッド型のストレージシステム。（下記、特許文献２、特許文献３参照）
（２）不揮発のメモリを使ったライトキャッシュを備えるディスクストレージであって、電源断が発生してもライトキャッシュにあるデータがロストしない。また、電源投入時、ライトキャッシュにある未書き込みデータを読み込みディスクに書き込む。（下記、特許文献４参照）
（３）通常の揮発メモリをライトキャッシュに使用し、電源断を検出したときにスピンドルモータにて生成されたＥＭＦ（Electro Motive Force）からの電源を用いて、ライトキャッシュにあるデータを不揮発メモリに書く。また、電源投入時、不揮発メモリにあるデータを読み込みディスクに書き込む。（下記、特許文献５参照）
（４）ディスクストレージのバッファキャッシュとして、不揮発のＭＲＡＭ（Magnetoresistive Random Access Memory）を使用することによって、電源断が発生してもデータがロストしない。（下記、特許文献６参照）
（５）比較的高速で小容量の不揮発メディアと大容量の不揮発メディアを組み合わせたストレージシステムであって、前記高速で小容量の不揮発メディアが使用不可の場合、大容量のメディアのみで運用する。（下記、特許文献７参照）
（６）それぞれ少なくともひとつ以上の揮発メモリと不揮発メモリを備えるディスク制御装置であって、不揮発メモリは揮発メモリにあるライトキャッシュデータをバックアップするために使用する。（下記、特許文献８参照）
【０００５】
なお、本願発明に関連する先行技術文献としては以下のものがある。
【特許文献１】特開２００４−７８４６１号公報
【特許文献２】米国特許第７，３０８，５３１号明細書
【特許文献３】米国特許第６，７８５，７６７号明細書
【特許文献４】米国特許第６，５１６，４２６号明細書
【特許文献５】米国特許第６，２９５，５７７号明細書
【特許文献６】米国特許第６，７９８，５９９号明細書
【特許文献７】米国特許第７，３０２、５３４号明細書
【特許文献８】米国特許第５，５８６，２９１号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００６】
前述したように、電源断やシステムクラッシュに対応するための方法として、ファイルシステムはジャーナルログを記録する。このジャーナルログの記録による性能劣化を最小限にするために、ジャーナルログをより高速な不揮発のメモリに記録する方法では、不揮発メモリ及びそれを制御するハードウェアやソフトエアが必要になり、システムが高価になるという欠点がある。
また、メタデータの更新内容をジャーナルログに記録する方法では、修復処理がファイルシステムのフォーマットやファイルシステムがサポートするファイル操作に依存するため、処理が複雑という問題点がある。
同様にストレージデバイスは、電源断に対応するために不揮発のメモリを用いてデータの修復を行っている。しかし、ストレージデバイスで行っている修復処理はあくまでもホストから書き込まれた全てのデータを修復するものである。そのデータは、中途半端なファイルシステムのメタデータあるいは中途半端なアプリケーションの管理データの場合があり、逆に修復しない方が良いケースもある。
本発明は、前記従来技術の問題点を解決するためになされたものであり、本発明の目的は、効率よくトランザクションベースでファイルシステムのメタデータ及びアプリケーションの管理データを書き込む方法、そして電源断が発生した場合にトランザクション単位で自動的に修復を行うことができるストレージデバイスを提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
【課題を解決するための手段】
【０００７】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、下記の通りである。
前述の目的を達成するために、本発明においては、比較的高速で小容量の不揮発ストレージメディアと大容量のストレージメディアを組み合わせ、大容量のストレージメディアはメインのデータ記録領域として、高速なストレージメディアは一時的な記録領域として使用する。大容量のストレージメディアの一部のブロック（セクタ）アドレス空間は一時的な記録領域にマッピングし、マッピングするブロックアドレス空間を設定するコマンドを用意し、前記コマンドによってマッピングされたブロックアドレス空間に書き込まれたデータは一時的な記録領域に先ず格納する。一時的な記録領域に書き込んだデータをコミットするためのコマンドを用意し、前記コミットコマンドを受けると、一時的な記録領域に格納されたデータをメインのデータ記録領域に書き込み、前記コミットコマンドを受ける前に電源断が発生する場合、電源投入時に一時的な記録領域に格納されたデータを破棄し（ロールバック）、前記コミットコマンドを受け取ってから電源断が発生する場合、電源投入時に一時的な記録領域に格納されたデータを前記メインのデータ記録領域に書き込み（ロールフオーワード）、トランザクションベースでデータの修復を自動的に行うことを特徴とするストレージデバイスである。
【０００８】
前記トランザクションベースでデータ修復機能を備えたストレージデバイスを用いたファイルシステムでは、ファイルシステムのメタデータ及び特定のファイルデータの格納位置を一時的な記録領域にマッピングされたブロックアドレス空間から割り当て、前記特定のファイルはファイルの属性、ファイルのサイズまたはファイルの名称を用いて判定する。前記特定のファイルデータをコミットするためのインタフェースを用意し、例えば、アプリケーションが「ファイル１」にデータを追記してから、「ファイル２」のデータを更新するという一連のファイル操作を行った後、前記ファイルシステムのコミットインタフェースを用いてコミット要求を発行し、前記ファイルシステムは前記コミット要求を受けると、まだ書き込んでいないメタデータ及び前記ファイル１及びファイル２のデータがあれば、全部前記ストレージデバイスに書き込んでからコミットコマンドを発行する。
例えば、アプリケーションが「ファイル１」にデータを追記してから、「ファイル２」のデータを更新中に電源断が発生する場合、アプリケーションがコミット要求を発行していないため、電源投入時に本発明のストレージデバイスが自動的にロールバック処理を行い、アプリケーションのファイルデータおよびファイルシステムのメタデータが元の処理前の状態に戻る。
また、アプリケーションがコミット要求を発行し、ファイルシステムが更新されたメタデータ及びファイルデータを書き込んで、前記ストレージデバイスにコミットコマンドを発行してから電源断が発生する場合、電源投入時に本発明のストレージデバイスが自動的にロールフォーワード処理を行い、アプリケーションがファイル操作を行った後の状態にする。
【０００９】
ＡＶデータを記録再生する装置において、例えば、ファイルシステムのフォーマットとしてＵＤＦ（Universal Disc Format）を用いた場合、ＡＶデータをリアルタイム属性のファイルのメインデータストリームに記録する。
前記ＵＤＦはＮＴＦＳ（New Technology File System）と同様に複数のデータストリーム（multiple data stream）をサポートしており、ひとつのファイルには、通常のアプリケーションから見えるメインデータストリームと複数の名前付きストリーム（named stream）を記録することが可能である。
前記名前付きストリームには、例えば、アイコン情報、ＡＶファイルであればプレイバック情報（playback info）やサムネール情報（thumbnail info）を記録することが可能である。
ＡＶデータは容量が大きいため、通常、ライトキャッシュを用いず直接ストレージメディアに書き込む（Direct I/0）ことが多い。本発明のデータ記録方法でも、ＡＶデータはトランザクションベースの修復対象にしない方が望ましい。
前記ＵＤＦファイルシステムを用いた場合は、前記リアルタイム属性を用いて、ＡＶデータを他のファイルデータと区別することが可能である。
【００１０】
前記ＡＶデータ記録再生する装置のような場合、ストレージデバイスには大容量のＡＶデータを書き込み、ファイルシステムのメタデータ及びＡＶアプリケーションの管理データが比較的小容量になるため、前述したような本発明のストレージデバイス及び記録方法で十分に運用が可能である。
しかしながら、例えば、データベースシステムやファイルサーバなどでは、テンポラリファイルなどを除いて基本的に全てのファイルデータをトランザクションベースの修復対象にしなければならない。この場合には、以下のようなストレージデバイス及び記録方法が望ましい。
前記一時的な記録領域を前記メインのデータ記録領域にマッピングするのではなく、トランザクションデータ用のライトコマンドを別途用意し、前記コマンドで書き込まれたデータを全て一時的な記録領域に書き込み、ホストからコミットコマンドを受けると前記一時的な記録領域に格納されたデータを「コミット済み」状態と登録してから、前記データを前記メインのデータ記録領域に書き込み、前記コミットコマンドを受ける前に電源断が発生する場合、電源投入時に前記一時的な記録領域に格納されたデータを破棄し（ロールバック）、前記コミットコマンドを受け取ってから電源断が発生する場合、電源投入時に前記一時的な記録領域に格納されたデータを前記メインのデータ記録領域に書き込み（ロールフォーワード）、トランザクションベースでデータの修復を自動的に行う。
【００１１】
また、前述の特許文献５に記載されているような技術を応用し、一時的な記録領域として、通常の揮発メモリを使用し、電源断を検出したときに、トランザクションデータ用のライトコマンドで書き込まれたデータで、なおかつ、既にコミットされたものを不揮発のメモリにバックアップし、電源投入時に前記不揮発メモリにバックアップされたデータをメインのデータ記録領域に書き込み（ロールフォーワード）、トランザクションベースでデータの修復を自動的に行う。
なお、ファイルシステムは、前記トランザクションデータ用のライトコマンドを用いてメタデータ及び特定のファイルデータを書き込み、アプリケーションからのコミット要求を受けると、まだ書き込んでいないメタデータ及びファイルデータがあれば、全部前記ストレージデバイスに書き込んでからコミットコマンドを発行する。また、例えばテンポラリファイルのデータの書き込みでは、通常の非トランザクションデータ用のライトコマンドを用いても構わない。
【発明の効果】
【００１２】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、下記の通りである。
本発明によれば、非常に単純で簡単な方法で、アプリケーション、ファイルシステムとストレージデバイスが連携し、効率よくトランザクションベースでファイルシステムのメタデータ及びアプリケーションの管理データを書き込むことができ、電源断が発生した場合にストレージデバイスがトランザクションベースで自動的に修復を行うことが可能となる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して本発明の実施例を詳細に説明する。
なお、実施例を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
［実施例１］
先ず、図１は、ＡＶデータ記録再生装置またはパーソナルコンピュータのソフトウェア／ハードウェアの概略図である。
図１において、１０１はＡＶデータ記録再生装置またはパーソナルコンピュータ、１０２はアプリケーション、１０３はファイルシステムドライバ、１０４はデバイスドライバ、１０５はストレージデバイスである。
アプリケーション１０２の具体例としては、例えば、ＡＶデータを扱うアプリケーションまたはデータベースファイルを管理するデータベースアプリケーションがある。
ファイルシステムドライバ１０３は、ファイルシステムのフォーマット（例えば、ＵＤＦ）に基づき、ファイル／ディレクトリを管理するソフトウェアモジュールであり、これにより前記アプリケーション１０２がファイル／ディレクトリの作成、ファイルデータの読み書き、ディレクトリの閲覧などを行うことが可能となる。
デバイスドライバ１０４は、ストレージデバイス１０５を認識し、アプリケーション１０２やファイルシステムドライバ１０３にストレージデバイス１０５ヘのブロック（セクタ）データの読み書き、そしてデバイス情報の取得やフラッシュキャッシュなど特定のコマンドを発行するインタフェースを提供している。
【００１４】
図２は、本発明の実施例１のＡＶデータ記録再生装置におけるトランザクションベースストレージデバイス及びその記録方法を説明する図である。
図２において、２０１はファイルシステムのボリュームレイアウト、２０２はファイルシステムのメタデータ領域、２０３はＡＶアプリケーションの管理データ領域、２０４はＡＶデータ領域を示す。
また、２０５は本実施例のストレージデバイス、２０６は不揮発のメディアを使用した一時的な記録領域、２０７は管理情報領域、２０８はマッピング領域、２０９は予備領域、２１０は揮発のメディア（メモリ）を使用したバッファキャッシュ、２１１は不揮発のメディアを使用したメインデータ記録領域を示す。
本実施例では、ファイルシステムのメタデータ及びＡＶアプリケーションの管理データをトランザクションデータとして扱い、これらのデータは一時的な記録領域２０６にマッビングされるアドレス空間に格納される。なお、アドレス空間のマッピング方法として、メインデータ記録領域の先頭から一定サイズの領域を予めマッピングする固定式マッピング方法と、専用のコマンドでマッビングする領域を指定する可変式マッピング方法がある。どちらの方式の場合でも、本実施例のストレージデバイス２０５は、どのアドレス空間が一時的な記録領域にマッピングされるかを取得するコマンドを用意することが望ましい。
【００１５】
前記コマンドを用いて、ファイルシステムドライバ１０３がトランザクション対象の領域を知ることができ、ファイルシステムのメタデータ及びＡＶアプリケーションの管理データを前記トランザクション対象の領域に記録することが可能となる。
なお、本実施例、あるいは、後述する実施例２において、トランザクション対象あるいはトランザクション非対象の領域にファイルデータを書き込むか否かは、当該ファイルが記録される親ディレクトリ、または、当該ファイル自身のファイル属性、または、当該ファイル自身の名称の一部あるいは全部、あるいは、当該ファイルのサイズを用いて判断する。また、なお、図２においては、例として、トランザクション対象の領域がセクタ番号０からＡまでの領域となっている。
一時的な記録領域２０６は、不揮発のメディアを使用しており、実際にメインデータ記録領域２１１の特定のアドレス空間のマッピング領域２０８以外に、前記不揮発メディアの寿命や欠陥セクタを考慮し、交替処理用の予備領域２０９を設けることが望ましい。なお、管理情報領域２０７には、一時的な記録領域２０６のアドレス空間対メインデータ記録領域２１１のアドレス空間のマッピングテーブル、各アドレスに記録されているデータの状態（更新なし／更新あり／コミット済み）、交替セクタ情報を記録する。
【００１６】
次に、図３から図５を用いて、本実施例１におけるストレージデバイス２０５の書き込み処理、コミット処理及び修復処理を説明する。
図３は、本実施例におけるストレージデバイス２０５のデータ書き込み処理を示すフローチャートである。
本実施例において、トランザクションデータであるファイルシステムのメタデータ及びＡＶアプリケーションの管理データ、そして非トランザクションデータであるＡＶデータは、全て同じインタフェースを用いて書き込むことが可能である。
ストレージデバイス２０５は、書き込み対象のアドレスが一時的な記録領域２０６にマッピングされているかを確認する（ステップ３０１）。
書き込み対象のアドレスが一時的な記録領域２０６にマッピングされていない場合は、通常のバッファキャッシュ２１０にデータを書き込む（ステップ３０２）。
書き込み対象のアドレスが一時的な記録領域２０６にマッピングされている場合、書き込み対象アドレスを「更新あり」状態と管理情報領域２０７に登録し（ステップ３０３）、マッピング領域２０８にデータを書き込む（ステップ３０４）。
【００１７】
図４は、本実施例におけるストレージデバイス２０５のコミット処理を示すフローチャートである。
先ず、「更新あり」のデータが一時的な記録領域２０６に存在するかを確認する（ステップ４０１）。ステップ４０１において、「更新あり」のデータが存在しない場合は、コミット処理を終了する。
ステップ４０１において、「更新あり」のデータが存在する場合は、前記データを「コミット済み」状態と管理情報領域２０７に登録し（ステップ４０２）、前記更新されたデータを読み込み、メインデータ記録領域２１１に書き込む（ステップ４０３）。
最後に、前記データを「更新なし」状態と管理情報領域２０７に登録する（ステップ４０４）。
前記コミット処理は、アプリケーション１０２またはファイルシステムドライバ１０３からコミット要求を受けるときに実行される。
ファイルシステムドライバ１０３は、ひとつのトランザクションごとにメタデータを更新してからコミット要求を発行するか、複数のトランザクション分のメタデータを更新してからコミット要求を発行することが可能である。
なお、ＡＶアプリケーションの管理データの書き込みが伴う場合は、アプリケーション１０２からのコミット要求を受けてから、コミット処理を行うことで、ファイルシステムのメタデータとＡＶアプリケーションの管理データが整合性のある状態で修復が可能となる。
【００１８】
図５は、本実施例におけるストレージデバイス２０５の修復処理を示すフローチャートである。
修復処理は、ストレージデバイス２０５の電源投入時に実行される。先ず、管理情報領域２０７を読み込み（ステップ５０１）、管理情報領域を基に、未書き込みデータがあるかを判定する（ステップ５０２）。ステップ５０２において、未書き込みデータがない（即ち、全データが「更新なし」という状態にある）場合は、修復処理を終了し、通常の電源投入時の処理に移る。
ステップ５０２において、未書き込みデータがある場合は、前記未書き込みデータがコミットされたかどうかを判定する（ステップ５０３）。
ステップ５０３において、前記未書き込みデータがコミット済みの場合は、前記コミット済みデータをメインデータ記録領域２１１に書き込むロールフォワード処理を行い（ステップ５０５）、前記データを「更新なし」状態と管理情報領域２０７に登録することで、前記データの状態を「コミット済み」から「更新なし」状態に変更する（ステップ５０７）。
ステップ５０３において、前記データがコミットされていない（「更新あり」状態）場合は、メインデータ記録領域２１１にある更新前データを読み込み一時的な記録領域２０６にある更新後データに上書きするロールバック処理を行い（ステップ５０４）、前記データを「更新なし」状態と管理情報領域２０７に登録することで、前記データの状態を「更新あり」から「更新なし」状態に変更する（ステップ５０６）。
【００１９】
前述したように、前記一時的な記録領域２０６にマッピングされたデータが「更新なし」、「更新あり」および「コミット済み」の状態にあるかを管理することで、アプリケーション１０２あるいはファイルシステムドライバ１０３が意図するポイント（状態）にロールバックあるいはロールフォワード処理を行うことが可能となる。
なお、前記書き込み処理で行う「更新あり」状態に変更するステップ３０３、前記コミット処理で行う「更新あり」から「コミット済み」状態に変更するステップ４０２と「コミット済み」から「更新なし」状態に変更するステップ４０４、そして前記修復処理で行う「更新あり」から「更新なし」状態に変更するステップ５０６と、「コミット済み」から「更新なし」状態に変更するステップ５０７は、中途半端な状態が許されない。
そのためには、管理情報領域２０７に各々の状態を登録する処理ではリングバッファ方式を用いて、直前の状態を表すデータを上書きせず、次の領域に新しい状態を表すデータを格納するとともに、チェックサムを用いて変更処理が完全に完了したかどうかを判断する。
【００２０】
［実施例２］
図６は、本発明の実施例２であるデータベースシステムにおけるトランザクションベスストレージデバイス及びその記録方法を示す図である。
図６において、６０１はファイルシステムのボリュームレイアウト、６０２はファイルシステムのメタデータ、６０３はデータベースファイルのデータ、６０４はファイルシステムのメタデータ、６０５はテンポラリファイルのデータ、６０６はその他データを示す。 また、６０７は本実施例のストレージデバイス、６０８は揮発のメディアを使用した一時的な記録領域、６０９は管理情報領域、６１０はバッファキャッシュ領域、６１１は不揮発のメディアを使用したバックアップメディア、６１２は管理情報、６１３はバックアップ領域、６１４は不揮発のメディアを使用したメインデータ記録領域を示す。
本実施例２では、ファイルシステムのメタデータに加え、全データベースファイルのデータをトランザクションデータとして扱うことが望ましい。なお、テンポラリファイルなどのデータは非トランザクションデータとして扱っても構わない。
【００２１】
データベースファイルのデータが大量で頻繁に更新されるため、データベースシステムに適した本実施例では、一時的な記録領域６０８として寿命がより長く、性能の良い揮発メディアを使用した方が望ましい。すなわち、通常のバッファキャッシュをトランザクションデータの一時的な記録領域と兼用する。
その代わり、メインデータ記録領域６１４のメディアより消費電力の少ない不揮発のメディアを用いたバックアップメディア６１１を用意し、電源断を検出する際に、コミットされたトランザクションデータを前記バックアップメディア６１１にバックアップする。
なお、トランザクションデータあるいは非トランザクションデータかを区別するためには、前記ストレージデバイス６０７が専用のトランザクションデータ用書き込みコマンドを用意する。
同様に、ファイルシステムドライバ１０３も専用のトランザクションデータ用書き込みインタフェースをアプリケーション１０２に提供する。
【００２２】
次に、図７から図１０を用いて、本実施例におけるストレージデバイス６０７の書き込み処理、コミット処理、バックアッブ処理及び修復処理を説明する。
図７は、本実施例におけるストレージデバイス６０７のデータ書き込み処理を示すフローチャートである。
ストレージデバイス６０７は、最初にバッファキャッシュ６１０に空きがあるかを確認し（ステップ７０１）、ステップ７０１において、バッファキャッシュ６１０に空きがない場合は、バッファキャッシュ６１０にある未書き込みデータをメインデータ記録領域６１４に吐き出す遅延書き込み処理を行う（ステップ７０２）。
前記遅延書き込み処理は、バッファキャッシュを備えるストレージデバイスにおいて一般的に使用されるものである。なお、前記遅延書き込み処理で吐き出すデータは非トランザクションデータのみとする。
ステップ７０１において、バッファキャッシュ６１０に空きがある場合は、バッファキャッシュ６１０にデータを書き込み（ステップ７０３）、前記データがトランザクションデータかを判定する（ステップ７０４）。
ステップ７０４での判定結果が、前記データが非トランザクションデータの場合は、管理情報領域６０９に前記データが未書き込みの非トランザクションデータであると記録する（ステップ７０５）。
ステップ７０４での判定結果が、前記データがトランザクションデータの場合は、管理情報領域６０９に前記データが未書き込みのトランザクションデータであると記録する（ステップ７０６）。
【００２３】
図８は、本実施例におけるストレージデバイス６０７のコミット処理を示すフローチャートである。
ストレージデバイス６０７は、最初に未書き込みのトランザクションデータがあるかを判定し（ステップ８０１）、ステップ８０１において、未書き込みのトランザクションデータが存在しない場合は、コミット処理を終了する。
ステップ８０１において、未書き込みのトランザクションデータが存在する場合は、管理情報領域６０９に「コミット済み」状態を記録し（ステップ８０２）、コミットされた前記トランザクションデータをメインデータ記録領域６１４に書き込む（ステップ８０３）。
最後に管理情報領域６０９に「更新なし」状態を記録する（ステップ８０４）。なお、非トランザクションデータは、このコミット処理でトランザクションデータと一緒にメインデータ記録領域６１４に吐き出しても良い。
【００２４】
図９は、本実施例におけるストレージデバイス６０７のバックアップ処理示すフローチャートである。
ストレージデバイス６０７は、電源断を検出する際に、例えば、前述の特許文献５に記載されている方法を用いて、必要なデータのバックアッブ処理を行うための電源を供給する。
前記バックアップ処理では、最初に未書き込みのトランザクションデータがコミットされたかどうかを判定し（ステップ９０１）、ステップ９０１において、コミットされていない場合は、バックアップ処理を終了する。
ステップ９０１において、コミットされている場合は、該当するデータをバックアップメディア６１１のバックアップ領域６１３に書き込み（ステップ９０２）、前記バックアッブしたデータの情報（セクタ番号、セクタ数）をバックアップメディア６１１の管理情報６１２に書き込む（ステップ９０３）。
【００２５】
図１０は、本実施例におけるストレージデバイス６０７の修復処理を示すフローチャートである。
修復処理は前記ストレージデバイスの電源投入時に実行される。先ず、管理情報６１２を読み込み（ステップ１００１）、前記管理情報を基に、バックアッブデータがあるかを判定する（ステップ１００２）。
ステップ１００２において、バックアップデータが存在しない場合は、修復処理を終了し、通常の電源投入時の処理に移る。
ステップ１００２において、バックアップデータが存在する場合は、前記バックアップデータを読み込み、メインデータ記録領域６１４に書き込むロールフォワード処理を行い（ステップ１００３）、管理情報６１２をクリアする（ステップ１００４）。
前述したように、一時的な記録領域６０８に格納されたトランザクションデータがコミットされた状態の場合、電源断を検出するときに、トランザクションデータをバックアップメディア６１１にバックアップすることで、電源投入時の修復処理でロールフォワード処理を行うことが可能となる。なお、前記一時的な記録領域６０８は揮発のメディアを用いるため、次の電源投入時には全データが無効となり、コミットされていないデータのロールバック処理を行う必要がない。
【００２６】
図１１は、本実施例１または実施例２における、アプリケーション及びファイルシステムドライバがストレージデバイスと連携し、トランザクションベースで処理する例を示す処理シーケンスである。
図１１において、１１０１はアプリケーション、１１０２はファイルシステムドライバ、１１０３はトランザクションベースストレージデバイスを示す。また、図１１において、アプリケーションが２つのファイルである「ファイル１」と「ファイル２」を開き、「ファイル１」にデータを追記書き込み、「ファイル２」のデータを一部上書きする一連の処理をひとつのトランザクションである例を示す。
以下に、順番にアプリケーション１１０１の各ステップについて説明する。
先ず、アプリケーション１１０１は、「ファイル１」を開く（ステップ１１０４）。これに対して、ファイルシステムドライバ１１０２は、「ファイル１」を検索し、メモリ上で管理オブジェクトを作成する（ステップ１１０５）。
ファイルシステムドライバ１１０２は、通常オープンされた各々のファイル／ディレクトリに対して、ファイル／ディレクトリのメタデータなどを格納するための管理オプジェクトを作成する。例えば、ＯＳがＷｉｎｄｏｗｓの場合ではファイルオブジェクト、ＯＳがＬｉｎｕｘの場合ではｉｎｏｄｅという管理オプジェクトを作成する。
次に、アプリケーション１１０１は、「ファイル２」を開く（ステップ１１０６）。これに対して、ファイルシステムドライバ１１０２は、「ファイル２」を検索し、メモリ上で管理オブジェクトを作成する（ステップ１１０７）。
【００２７】
次に、アプリケーション１１０１が、「ファイル１」にデータを追記書き込む（ステップ１１０８）。これに対して、ファイルシステムドライバ１１０２が、追加データ用領域を確保し、ファイルシステムのメタデータを更新する（ステップ１１０９）。
ファイルシステムメタデータは、例えば、各ブロックの使用状態を表すスペースビットアップ、「ファイル１」のデータの位置を表すエクステントテーブル、「ファイル１」のサイズ情報、「ファイル１」の更新日時情報を指す。そして、ファイルシステムドライバ１１０２が前記追加データを前記エクステントテーブルの位置情報に基づいて、ストレージデバイス１１０３に書き込む（ステップ１１１０）。
次に、アプリケーション１１０１が「ファイル２」のデータを一部上書きする（ステップ１１１１）。これに対して、ファイルシステムドライバ１１０２が、データを「ファイル２」のエクステントテーブルの位置情報に基づいて、ストレージデバイス１１０３に書き込み（ステップ１１１２）、「ファイル２」のメタデータ（更新日時情報）を更新する（ステップ１１１３）。
次に、ひとつのトランザクションのデータ更新が全て完了したため、アプリケーション１１０１がファイルシステムドライバ１１０２にコミット要求を発行する（ステップ１１１４）。これに対して、ファイルシステムドライバ１１０２が、未書き込みのメタデータ及びファイルデータをストレージデバイス１１０３に書き込み（ステップ１１１５）、コミット要求をストレージデバイス１１０３に発行する（ステップ１１１６）。
ファイルシステムドライバ１１０２は、性能向上を目的に、頻繁に更新されるデータを一時的にライトキャッシュに格納することが望ましい。そのため、アプリケーション１１０１からコミット要求を受けるときに、未書き込みのメタデータ及びファイルデータが存在する場合がある。
【００２８】
図１１に示すアプリケーション１１０１、ファイルシステムドライバ１１０２及びストレージデバイス１１０３の連携処理は、前述の実施例１と実施例２の両方の場合に適用できる。
実施例１の場合は、全てのデータを同じインタフェース／コマンドで書き込む。それに対して、実施例２の場合は、アプリケーション１１０１がトランザクションデータを専用のインタフェースで書き込み、またファイルシステムドライバ１１０２が書き込み時に使用したインタフェースによって各ファイルデータがトランザクションデータかどうかを管理し、専用のコマンドでストレージデバイス１１０３にトランザクションデータを書き込む。なお、実施例２において、全てのデータをトランザクションデータとし、全てのデータを同じインタフェース／コマンドで書き込むことが可能である。
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本
発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【図面の簡単な説明】
【００２９】
【図１】ＡＶデータ記録再生装置またはパーソナルコンピュータの概略図である。
【図２】本発明の実施例１のＡＶデータ用ストレージデバイス及びその記録方法を示す概略図である。
【図３】本発明の実施例１のＡＶデータ用ストレージデバイスにおけるデータの書き込み処理の流れの一例を示すフローチャートである。
【図４】本発明の実施例１のＡＶデータ用ストレーンデバイスにおけるコミット処理の流れの一例を示すフローチャートである。
【図５】本発明の実施例１のＡＶデータ用ストレージデバイスにおけるデータの修復処理の流れの一例を示すフローチャートである。
【図６】本発明の実施例２のデータベース用ストレージデバイス及びその記録方法を示す概略図である。
【図７】本発明の実施例２のデータベース用ストレージデバイスにおけるデータの書き込み処理の流れの一例を示すフローチャートである。
【図８】本発明の実施例２のデータベース用ストレージデバイスにおけるコミット処理の流れの一例を示すフローチャートである。
【図９】本発明の実施例２のデータベース用ストレーンデバイスにおけるバックアップ処理の流れの一例を示すフローチャートである。
【図１０】本発明の実施例２のデータベース用ストレージデバイスにおける修復処理の流れの一例を示すフローチャートである。
【図１１】アプリケーション、ファイルシステムドライバ及ゲストレーンデバイスの連携処理の流れの一例を示す処理シーケンスである。
【符号の説明】
【００３０】
１０１ ＡＶデータ記録再生装置またはパーソナルコンピュータ
１０２，１１０１ アプリケーション
１０３，１１０２ ファイルシステムドライバ
１０４ デバイスドライバ
１０５ ストレージデバイス
２０１，６０１ ファイルシステムのボリュームレイアウト
２０２，６０２，６０４ ファイルシステムのメタデータ領域
２０３ ＡＶアプリケーションの管理データ領域
２０４ ＡＶデータ領域
２０５，６０７，１１０３ ストレージデバイス
２０６ 不揮発のメディアを使用した一時的な記録領域
２０７ 管理情報領域
２０８ マッピング領域
２０９ 予備領域
２１０ 揮発のメディア（メモリ）を使用したバッファキャッシュ
２１１ 不揮発のメディアを使用したメインデータ記録領域
６０３ データベースファイルのデータ
６０５ テンポラリファイルのデータ
６０６ その他データ
６０８ 揮発のメディアを使用した一時的な記録領域
６０９ 管理情報領域
６１０ バッファキャッシュ領域
６１１ 不揮発のメディアを使用したバックアップメディア
６１２ 管理情報
６１３ バックアップ領域
６１４ 不揮発のメディアを使用したメインデータ記録領域
【特許請求の範囲】
【請求項１】
一時的な記録領域とメインの記録領域を有し、電源断からデータを修復する機能を有するストレージデバイスであって、
ホストから書き込まれたデータを前記一時的な記録領域に格納する手段１と、
前記ホストからコミット要求を受けると、前記一時的な記録領域にあるデータを前記メインの記録領域に書き込む手段２と、
前記コミット要求を受ける前に電源断が発生した場合に電源投入時に前記一時的な記録領域にあるデータを破棄し、前記コミット要求を受けてから電源断が発生した場合に電源投入時に前記一時的な記録領域にあるデータをメインの記録領域に書き込む手段３とを備え、トランザクションベースでデータを修復することを特徴とするストレージデバイス。
【請求項２】
前記一時的な記録領域として、比較的高速で小容量の不揮発メモリを用いることを特徴とする請求項１に記載のストレージデバイス。
【請求項３】
前記一時的な記録領域と前記メインの記録領域は、同じ不揮発のストレージメディアに割り当てることを特徴とする請求項１に記載のストレージデバイス。
【請求項４】
前記一時的な記録領域として、フラッシュメモリを用い、
前記メインの記録領域として、ハードディスクを用いることを特徴とする請求項１に記載のストレージデバイス。
【請求項５】
通常のライトキャッシュ用の揮発メディアと、
バックアップ用の不揮発メディアとを備え、
前記一時的な記録領域として、前記ライトキャッシュ用の揮発メディアを使用し、
前記手段３は、電源断を検出する際に、前記コミットされたデータを前記不揮発のメディアにバックアップし、電源投入時に前記不揮発メディアにあるバックアップデータを前記メインの記録領域に書き込むことを特徴とする請求項１に記載のストレージデバイス。
【請求項６】
前記一時的な記録領域をメインデータ領域の先頭のアドレス空間にマッピングして、先頭アドレスから一時的な記録領域のサイズまでのアドレス空間をトランザクション対象領域とし、
前記トランザクション対象領域のデータのみを修復することを特徴とする請求項１ないし請求項５のいずれか１項に記載のストレージデバイス。
【請求項７】
トランザクション対象領域のセクタ／ブロックアドレス空間は、前記ホストから指定でき、
前記指定されたトランザクション対象領域のデータのみを修復することを特徴とする請求項１ないし請求項５のいずれか１項に記載のストレージデバイス。
【請求項８】
非トランザクションデータ用のライトコマンドと、トランザクションデータ用のライトコマンドを両方用意し、
前記トランザクションデータ用のライトコマンドで書き込まれたデータをトランザクション対象とし、電源断発生時にトランザクションベースでデータの修復を行うことを特徴とする請求項１ないし請求項５のいずれか１項に記載のストレージデバイス。
【請求項９】
請求項６または請求項７に記載のストレージデバイスを用いるファイルシステムの記録方法であって、
前記ファイルシステムのメタデータをトランザクション対象の領域に配置し、トランザクション単位でメタデータを前記ストレージデバイスに書き込んでからコミットコマンドを発行することを特徴とするファイルシステムの記録方法。
【請求項１０】
請求項６または請求項７に記載のストレージデバイスを用いるファイルシステムの記録方法であって、
前記ファイルシステムのメタデータ及び特定のファイルデータをトランザクション対象の領域に配置し、アプリケーションからのコミット要求を受けると、前記ストレージデバイスにコミットコマンドを発行し、ファイルシステムのメタデータとアプリケーションのファイルデータをトランザクション単位で更新することを特徴とするファイルシステムの記録方法。
【請求項１１】
請求項８に記載のストレージデバイスを用いるファイルシステムの記録方法であって、
トランザクションデータ用のライトコマンドを用いてファイルシステムのメタデータを書き込み、トランザクション単位で前記メタデータを前記ストレージデバイスに書き込んでからコミットコマンドを発行することを特徴とするファイルシステムの記録方法。
【請求項１２】
請求項８に記載のストレージデバイスを用いるファイルシステムの記録方法であって、 トランザクションデータ用のライトコマンドを用いてファイルシステムのメタデータ及び特定のファイルデータを書き込み、アプリケーションからのコミット要求を受けると、前記ストレージデバイスにコミットコマンドを発行し、ファイルシステムのメタデータとアプリケーションのファイルデータをトランザクションベースで更新することを特徴とするファイルシステムの記録方法。
【請求項１３】
トランザクション対象あるいはトランザクション非対象の領域にファイルデータを書き込むかを判定するために、当該ファイルが記録される親ディレクトリ、あるいは当該ファイル自身のファイル属性を用いることを特徴とする請求項１０または請求項１２に記載のファイルシステムの記録方法。
【請求項１４】
トランザクション対象あるいはトランザクション非対象の領域にファイルデータを書き込むかを判定するために、当該ファイルが記録される親ディレクトリ、あるいは当該ファイル自身の名称の一部あるいは全部を用いることを特徴とする請求項１０または請求項１２に記載のファイルシステムの記録方法。
【請求項１５】
トランザクション対象あるいはトランザクション非対象の領域にファイルデータを書き込むかを判定するために、当該ファイルのサイズを用いることを特徴とする請求項１０または請求項１２に記載のファイルシステムの記録方法。
【請求項１６】
ファイルシステムフォーマットとしてＵＤＦを用いて、属性がリアルタイムのファイルのメインデータストリームをトランザクション非対象の領域に書き込み、それ以外のファイルデータ及びファイルシステムのメタデータをトランザクション対象の領域に書き込むことを特徴とする請求項１０に記載のファイルシステムの記録方法。
【請求項１７】
ファイルシステムフォーマットとしてＵＤＦを用いて、属性がリアルタイムのファイルのメインデータストリームを書き込む際に、非トランザクションデータ用のライトコマンドを用い、それ以外のファイルデータ及びファイルシステムのメタデータを書き込む際に、トランザクションデータ用のライトコマンドを用いることを特徴とする請求項１２に記載のファイルシステムの記録方法。
【請求項１】
一時的な記録領域とメインの記録領域を有し、電源断からデータを修復する機能を有するストレージデバイスであって、
ホストから書き込まれたデータを前記一時的な記録領域に格納する手段１と、
前記ホストからコミット要求を受けると、前記一時的な記録領域にあるデータを前記メインの記録領域に書き込む手段２と、
前記コミット要求を受ける前に電源断が発生した場合に電源投入時に前記一時的な記録領域にあるデータを破棄し、前記コミット要求を受けてから電源断が発生した場合に電源投入時に前記一時的な記録領域にあるデータをメインの記録領域に書き込む手段３とを備え、トランザクションベースでデータを修復することを特徴とするストレージデバイス。
【請求項２】
前記一時的な記録領域として、比較的高速で小容量の不揮発メモリを用いることを特徴とする請求項１に記載のストレージデバイス。
【請求項３】
前記一時的な記録領域と前記メインの記録領域は、同じ不揮発のストレージメディアに割り当てることを特徴とする請求項１に記載のストレージデバイス。
【請求項４】
前記一時的な記録領域として、フラッシュメモリを用い、
前記メインの記録領域として、ハードディスクを用いることを特徴とする請求項１に記載のストレージデバイス。
【請求項５】
通常のライトキャッシュ用の揮発メディアと、
バックアップ用の不揮発メディアとを備え、
前記一時的な記録領域として、前記ライトキャッシュ用の揮発メディアを使用し、
前記手段３は、電源断を検出する際に、前記コミットされたデータを前記不揮発のメディアにバックアップし、電源投入時に前記不揮発メディアにあるバックアップデータを前記メインの記録領域に書き込むことを特徴とする請求項１に記載のストレージデバイス。
【請求項６】
前記一時的な記録領域をメインデータ領域の先頭のアドレス空間にマッピングして、先頭アドレスから一時的な記録領域のサイズまでのアドレス空間をトランザクション対象領域とし、
前記トランザクション対象領域のデータのみを修復することを特徴とする請求項１ないし請求項５のいずれか１項に記載のストレージデバイス。
【請求項７】
トランザクション対象領域のセクタ／ブロックアドレス空間は、前記ホストから指定でき、
前記指定されたトランザクション対象領域のデータのみを修復することを特徴とする請求項１ないし請求項５のいずれか１項に記載のストレージデバイス。
【請求項８】
非トランザクションデータ用のライトコマンドと、トランザクションデータ用のライトコマンドを両方用意し、
前記トランザクションデータ用のライトコマンドで書き込まれたデータをトランザクション対象とし、電源断発生時にトランザクションベースでデータの修復を行うことを特徴とする請求項１ないし請求項５のいずれか１項に記載のストレージデバイス。
【請求項９】
請求項６または請求項７に記載のストレージデバイスを用いるファイルシステムの記録方法であって、
前記ファイルシステムのメタデータをトランザクション対象の領域に配置し、トランザクション単位でメタデータを前記ストレージデバイスに書き込んでからコミットコマンドを発行することを特徴とするファイルシステムの記録方法。
【請求項１０】
請求項６または請求項７に記載のストレージデバイスを用いるファイルシステムの記録方法であって、
前記ファイルシステムのメタデータ及び特定のファイルデータをトランザクション対象の領域に配置し、アプリケーションからのコミット要求を受けると、前記ストレージデバイスにコミットコマンドを発行し、ファイルシステムのメタデータとアプリケーションのファイルデータをトランザクション単位で更新することを特徴とするファイルシステムの記録方法。
【請求項１１】
請求項８に記載のストレージデバイスを用いるファイルシステムの記録方法であって、
トランザクションデータ用のライトコマンドを用いてファイルシステムのメタデータを書き込み、トランザクション単位で前記メタデータを前記ストレージデバイスに書き込んでからコミットコマンドを発行することを特徴とするファイルシステムの記録方法。
【請求項１２】
請求項８に記載のストレージデバイスを用いるファイルシステムの記録方法であって、 トランザクションデータ用のライトコマンドを用いてファイルシステムのメタデータ及び特定のファイルデータを書き込み、アプリケーションからのコミット要求を受けると、前記ストレージデバイスにコミットコマンドを発行し、ファイルシステムのメタデータとアプリケーションのファイルデータをトランザクションベースで更新することを特徴とするファイルシステムの記録方法。
【請求項１３】
トランザクション対象あるいはトランザクション非対象の領域にファイルデータを書き込むかを判定するために、当該ファイルが記録される親ディレクトリ、あるいは当該ファイル自身のファイル属性を用いることを特徴とする請求項１０または請求項１２に記載のファイルシステムの記録方法。
【請求項１４】
トランザクション対象あるいはトランザクション非対象の領域にファイルデータを書き込むかを判定するために、当該ファイルが記録される親ディレクトリ、あるいは当該ファイル自身の名称の一部あるいは全部を用いることを特徴とする請求項１０または請求項１２に記載のファイルシステムの記録方法。
【請求項１５】
トランザクション対象あるいはトランザクション非対象の領域にファイルデータを書き込むかを判定するために、当該ファイルのサイズを用いることを特徴とする請求項１０または請求項１２に記載のファイルシステムの記録方法。
【請求項１６】
ファイルシステムフォーマットとしてＵＤＦを用いて、属性がリアルタイムのファイルのメインデータストリームをトランザクション非対象の領域に書き込み、それ以外のファイルデータ及びファイルシステムのメタデータをトランザクション対象の領域に書き込むことを特徴とする請求項１０に記載のファイルシステムの記録方法。
【請求項１７】
ファイルシステムフォーマットとしてＵＤＦを用いて、属性がリアルタイムのファイルのメインデータストリームを書き込む際に、非トランザクションデータ用のライトコマンドを用い、それ以外のファイルデータ及びファイルシステムのメタデータを書き込む際に、トランザクションデータ用のライトコマンドを用いることを特徴とする請求項１２に記載のファイルシステムの記録方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００９−２８２７５２（Ｐ２００９−２８２７５２Ａ）
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【出願番号】特願２００８−１３４１２９（Ｐ２００８−１３４１２９）
【出願日】平成２０年５月２２日（２００８．５．２２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
２．Ｌｉｎｕｘ
【出願人】（３９１００２４０９）株式会社 日立システムアンドサービス (205)
【Ｆターム（参考）】
【公開日】平成２１年１２月３日（２００９．１２．３）
【国際特許分類】
【出願日】平成２０年５月２２日（２００８．５．２２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＩＮＤＯＷＳ
２．Ｌｉｎｕｘ
【出願人】（３９１００２４０９）株式会社 日立システムアンドサービス (205)
【Ｆターム（参考）】
[ Back to top ]