JP5394394B2

JP5394394B2 - ファイルシステムにおけるファイル管理・編集方法及び装置

Info

Publication number: JP5394394B2
Application number: JP2010540087A
Authority: JP
Inventors: フー，ジアン・チアン; ジャン，シャオ・ロン
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2007-12-27
Filing date: 2008-11-19
Publication date: 2014-01-22
Anticipated expiration: 2028-11-19
Also published as: EP2075796A1; EP2225757A1; KR20100099216A; WO2009083337A1; US8825723B2; CN101911198A; CN101911198B; JP2011508326A; KR101531733B1; US20100287218A1

Description

本発明はパーソナルビデオレコーダ（ＰＶＲ）などのファイル記憶装置の分野に関する。より具体的には、本発明はファイルシステムにおけるファイル管理・編集方法及び装置に関する。

近年、セットトップボックスのパーソナルビデオレコーダ（ＰＶＲ）アプリケーションが広く使われている。ユーザはビデオ記録物（video records）を編集しなければならない場合がある。例えば、ファイルを削除してコマーシャルを除去する必要がある。しかし、コマーシャルはビデオ記録物のどこにあるか分からず、ユーザはビデオ記録ファイル（video record files）のどこかからデータを削除する必要が生じる。すなわち、ユーザはビデオ記録ファイルの始め、途中、または終わりからコマーシャルを除去する必要がある。

図１は、ＦＡＴ３２やＥＸＴ２などの従来のファイルシステムの一例である。このファイルシステムでは、ファイルは複数のブロックに格納される。図１では、１０ブロックを用いてファイルを格納している。１ブロックは最小のアロケーション単位（allocation unit）であり、１６セクタを含む。１セクタは５１２バイトであり、通常、ブロックの大きさは８Ｋバイトである。シーケンシャルファイルでは、全てのブロックはファイル管理システムでリンクされている。各ブロックにおいて、リンク情報は、カレントブロックの前のブロックのナンバなどの前インデックス（previous index）と、カレントブロックの後のブロックのナンバなどの後インデックス（next index）とを含む。通常、ファイル管理システムは、ファイルが始め、すなわち始めのブロックのナンバと、ファイルが占める記憶空間（space）の長さ、すなわちいくつのブロックを用いてこのファイルを格納しているかとを知っている。ファイルの実際の長さは、そのファイルが占める記憶空間の長さより短くてもよい。

この従来のファイルシステムでは、ファイルの終わりからデータを削除し、例えばコマーシャルを除去するのは容易である。ファイルの終わりで削除すると、削除されたデータは直接解放される。しかし、ファイルの途中からデータを削除するのは困難であり、特に複数のブロックからその一部を削除するのは困難である。ブロックの一部からデータを削除するとき、そのブロックは完全なブロックではなくなる（不完全）。すなわちそのブロックのデータは８Ｋ未満となる。この状態では、従来の方法では、後続のブロックのデータをシフトして、不完全ブロックにデータを入れる（fill）。その理由は、従来のファイルシステムでは、始めのブロックのナンバとファイルの長さ（すなわち、ブロックをいくつ用いてファイルを格納するか）とのみを登録するだけだからである。そのため、ブロックからデータを除去しただけでも、そのブロックのその部分を読み出すのに時間がかかってしまう。しかし、後続のブロックをシフトして不完全ブロックにデータを入れるには処理時間がかかり、特に大きなファイルの場合は処理時間がかかる。

従来のファイルシステムにある問題を解決するため、特許文献１には、ビデオ／オーディオデータの編集において、媒体に対する読み出し／書き込みアクセスに伴うコピー動作を低減して、高速編集を実現する情報編集コントローラが開示されている。

特開２００３−０５２００６号公報

一態様では、ファイルシステムにおけるファイルのデータ管理方法を提供する。該ファイルシステムでは、ファイルのデータを格納する記憶スペースが、サイズが同じで順次に付番された複数のブロックに分割される。前記ブロックは順次に付番されたチャンクにより構成され、各チャンクは少なくとも１つのブロックを有する。前記方法は、１つのチャンクに対して、前記ファイル中のデータを削除する段階の後に、第１の管理データと第２の管理データとを用いて、各チャンクの前記最初のブロックの先頭部分と、前記最後のブロックの終わり部分とにある、データにより占有されていないスペースのサイズを記録する段階を有する。前記スペースのサイズは前記ブロックのサイズより小さい。

一実施形態では、前記チャンクの先頭部分または終わりの部分からデータを削除する段階を有する。

詳細な一実施形態では、ファイルのデータを有する複数のチャンクがリンクされ、リンク情報がファイルシステム管理データに記録される。

さらに、１つのチャンクが完全に削除されたとき、削除されたチャンクの記憶スペースを解放し、削除されたチャンクの前と後のチャンクをリンクする。

第２の態様では、ファイルシステムにおけるファイルのデータ管理方法を提供する。該ファイルシステムでは、ファイルのデータを格納する記憶スペースが、サイズが同じで順次に付番された複数のブロックに分割される。前記ブロックは順次に付番されたチャンクにより構成され、各チャンクは少なくとも１つのブロックを有する。前記方法は、１つのチャンクに対して、前記ファイル中のデータを削除する段階の後に、第１の管理データと第２の管理データとを用いて、各チャンクの前記最初のブロックの先頭部分と、前記最後のブロックの終わり部分とにある、データにより占有されていないスペースのサイズを記録する段階を有する。前記スペースのサイズは前記ブロックのサイズより小さい。前記ファイルの一部が削除され、その削除の開始位置と終了位置とが同一ブロックではないが同一チャンク中にあるとき、前記チャンクを新しい第１のチャンクと新しい第２のチャンクとに分割する。この場合、第３の管理データと第４の管理データとを用いて、前記新しい第２のチャンクの最初のブロックの先頭部分と最後のブロックの終わりの部分との空のスペースのサイズを記録し、前記新しい第１のチャンクと新しい第２のチャンクとをリンクして前記ファイルの連続性を保つ。

一実施形態では、前記新しい第１のチャンクは削除前の最初のチャンクの番号を用いて付番され、前記新しい第２のチャンクは前記ファイルシステムの元の最後のチャンクに続く付番をされる。

他の一実施形態では、１つのブロックのデータを完全に削除したとき、前記ブロックのスペースを解放する。

第３の態様では、ファイルシステムにおけるファイルのデータ管理方法を提供する。該ファイルシステムでは、ファイルのデータを格納する記憶スペースが、サイズが同じで順次に付番された複数のブロックに分割される。前記ブロックは順次に付番されたチャンクにより構成され、各チャンクは少なくとも１つのブロックを有する。前記方法は、１つのチャンクに対して、前記ファイル中のデータを削除する段階の後に、第１の管理データと第２の管理データとを用いて、各チャンクの前記最初のブロックの先頭部分と、前記最後のブロックの終わり部分とにある、データにより占有されていないスペースのサイズを記録する段階を有する。前記スペースのサイズは前記ブロックのサイズより小さい。前記ファイルのデータの一部を１つのチャンクの１つのブロックの途中から削除したとき、前記ブロックの削除されたデータに続くデータの残っている後半を前記ブロックのデータの前半の直後の位置に移動し、前記チャンク中の削除をしたブロックとその前のブロックとを新しい第１のチャンクとして再構成し、削除をしたブロックの後にブロックがあれば、そのブロックを新しい第２のチャンクとして再構成し、第３の管理データと第４の管理データとを用いて、前記新しい第２のチャンク中の最初のブロックの先頭部分と、最後のブロックの終わりの部分との空きスペースのサイズをそれぞれ記録し、前記新しい第１のチャンクと新しい第２のチャンクとをリンクする。

他の一実施形態では、ファイルシステム管理データに前記チャンクのリンク情報を記録する。

第４の態様では、ファイルシステムを説明する。該ファイルシステムでは、ファイルのデータを格納する記憶スペースが、サイズが同じで順次に付番された複数のブロックに分割される。前記ブロックは順次に付番されたチャンクにより構成され、各チャンクは少なくとも１つのブロックを有する。前記ファイルシステムは、各チャンクの先頭部分及び／または終わり部分の空き記憶スペースのサイズを示す、そのチャンクの管理データであって、前記空き記憶スペースはブロックのサイズより小さい管理データを有する。

一実施形態では、前記チャンクの最初のブロックの先頭部分と最後のブロックの終わり部分のスペースのサイズを、第１の管理データと第２の管理データにより記録する。

他の一実施形態では、ファイルの全チャンクがリンクされて前記ファイルの連続性を保ち、リンク情報をファイルシステム管理データに記録する。

第５の態様では、上記のファイルシステムを含む記憶装置を説明する。

従来のファイルシステムを示す図である。本ファイルシステムの一実施形態を示す図である。本ファイルシステムの他の一実施形態を示す図である。本実施形態によるファイルシステムを用いた読み出し動作の実行時に、チャンク中の実際のデータサイズをいかに計算するか示すフローチャートである。本ファイルシステムからの読み出し動作例を示すフローチャートである。本ファイルシステムからの書き込み動作の実行時に、チャンク中の実際のデータサイズをいかに計算するか示すフローチャートである。本ファイルシステムへの書き込み動作例を示すフローチャートである。本ファイルシステムにおけるデータ除去動作例を示すフローチャートである。チャンクの始めからデータを切り取るデータ除去動作例を示す図である。チャンクの終わりからデータを切り取るデータ除去動作例を示す図である。チャンクの途中からデータを切り取るデータ除去動作を示すフローチャートである。チャンクの始めからデータを切り取るデータ除去動作例を示す図である。

発明の実施するための形態

ここに説明する例は本発明の好ましい実施形態を説明するものであり、かかる例が本発明の範囲を限定するものと解してはならない。

一実施形態では、図２に示したように、ファイルは８ブロックよりなり、各ブロックは８Ｋバイトのデータを含む。ファイル管理システムでは、ファイルに属するブロックはチャンクとして管理される。チャンクはブロック（少なくとも１つのブロック）のグループよりなる。図２において、チャンク０はブロック０−２よりなり、チャンク１はブロック１０−１１よりなり、チャンク２はブロック１２−１４よりなる。本実施形態では、すべてのチャンクのブロック数は異なるが、実施形態によっては同じでもよい。本実施形態では、６つの記述子を用いて各チャンクを記述する。６つの記述子とは、StartBlockNumber、TotalBlockNumber、PreviousChunkNumber、NextChunkNumber、UnusedSizeInFirstBlock、UnusedSizeInLastBlockである。StartBlockNumberはチャンクの始めのブロックのナンバを示す。TotalBlockNumberはチャンクの総ブロック数を示す。PreviousChunkNumberはカレントチャンクの前のチャンクのナンバを示す。NextChunkNumberはカレントチャンクの後のチャンクのナンバを示す。UnusedSizeInFirstBlockはチャンクの最初のブロックの未使用記憶空間量（データが占めていない記憶空間のバイト数）を示す。UnusedSizeInLastBlockはチャンクの最後のブロックの未使用記憶空間量（データが占めていない記憶空間のバイト数）を示す。最後の２つの記述子を使う理由は、チャンクを途中で削除すると、最後のブロックの未使用記憶空間がそのブロックにおいて削除を始めるところとして現れ、最初のブロックの未使用記憶空間がそのブロックにおいて削除を終えるところとして現れるからである。

図２を参照するに、チャンク０−２はそれぞれ（０，３，−１，１，０，０）、（１０，２，０，２，０，０）、（１２，３，１，−１，０，０）と記述されている。第１のチャンクの記述子は（０，３，−１，１，０，０）である。第１の記述子「０」は、カレントチャンクがブロック０から始まることを示す。第２の記述子「３」は、カレントチャンクにはブロックが３つあることを意味する。第３の記述子「−１」は、（カレントチャンクがファイルの最初のチャンクなので、）カレントチャンクの前のチャンクがＮＵＬＬであることを示す。第４の記述子「１」は、カレントチャンクに続くチャンクがチャンク１であることを意味する。第５の記述子「０」と第６の記述子「０」とは、カレントチャンクの最初のブロックの未使用スペースが０バイトであり、カレントチャンクの最後のブロックの未使用スペースが０バイトであることを示し、これはチャンク０のすべてのブロックが８Ｋバイトのデータを含むことを意味する。チャンク１とチャンク２の記述子はチャンク０の記述子と同様である。本実施形態では、「ＮＵＬＬ」を用いて、カレントチャンクと比較して前または次のチャンクのインデックスが無効であることを示し、これはカレントチャンクがファイルの最初のチャンクか最後のチャンクのいずれかであることを意味する。例えば、チャンク０の前のチャンクのインデックスは「ＮＵＬＬ」であり、チャンク２の次のチャンクのインデックスも「ＮＵＬＬ」である。

図３に示した他の例では、ファイルにはチャンク０、チャンク１、チャンク２の３つのチャンクがあり、それぞれ（１０，２，−１，１，１０２４，２０４８）、（２０，４，０，２，０，０）、（２８，６，１，−１，０，０）と記述される。これら３つのチャンクの記述子から分かることは、チャンク０がブロック１０から始まり、その長さが２ブロックで、各ブロックは８Ｋ（８×１０２４）バイトであり、チャンク０の最初のブロックの未使用スペースの大きさは１Ｋ（１０２４）バイトであり、チャンク０の最後のブロックの未使用スペースの大きさは２Ｋ（２０４８）バイトであることである。第２のチャンクはブロック２０から始まり、その長さは４ブロックで、各ブロックは８Ｋ（８×１０２４）バイトであり、カレントチャンク１の最初と最後のブロックの未使用スペースの大きさは０で、これはチャンク１にはデータが詰まっていることを意味する。第３のチャンクはブロック２８から始まり、その長さは６ブロックで、各ブロックは８Ｋ（８×１０２４）バイトであり、カレントチャンク２の最初と最後のブロックの未使用スペースの数は０である。

図４と図５は、本実施形態による読み出し動作プロセスを詳細に示す。

図４は、チャンク中のデータの実際の長さまたは大きさの計算プロセスを示すフローチャートである。本プロセスはステップ４１０から始まる。ステップ４２０において、チャンク中の実際のデータの長さChunkLengthを計算する。ChunkLength＝TotalBlockNumber＊BlockSize−UnusedSizeInFirstBlock−UnusedSizeInLastBlock、ここでTotalBlockNumberはカレントチャンク中のブロックの総数である。TotalBlockNumberに各ブロックの大きさBlockSize（バイト）をかけると、カレントチャンクが占める総バイト数が得られる。一方、カレントチャンクが占める総バイト数からUnusedSizeInLastBlockとUnusedSizeInFirstBlockとを除く必要がある。これらのスペースは実際には空だからである。よって、ステップ４３０でカレントチャンクが決定され、それがファイルの最後のチャンクでなければ、カレントチャンク中の実際のデータの長さが求まる。本プロセスはステップ４６０で終わる。例えば、チャンク０のChunkLengthは２×８Ｋ−１Ｋ−２Ｋ＝１３Ｋバイトである。

しかし、ステップ４３０の判断がＹＥＳであれば、プロセスはステップ４４０に進み、さらに、カレントチャンクを占めるカレントファイルの実際のデータの長さを決定する。このステップを用いて最後のチャンク中の予約スペースを排除する。ファイルシステムにデータが書き込まれると、そのデータを収容するためにより大きなスペースが割り当てられる。カレントデータの後に同じファイルにさらに別のデータが書き込まれたとき、スペースの再割り当てはされない。予約サイズを削除するためにステップ４４０が必要である。ステップ４４０では、ChunkLengthがFileLengthとChunkStartPositionの差より大きいか判断する。FileLengthはカレントファイルに何バイトのデータがあるか示すパラメータであり、ChunkStartPositionはカレントチャンクがどこから始まるか、またはカレントチャンクの前に何バイトのデータがあるかを示す。図３のチャンク２を例に取る。チャンクの長さは６×８Ｋ＝４８Ｋである。FileLengthは（４＋６＋２）×８Ｋ−３Ｋ＝９３Ｋである。チャンク２の始めの位置ChunkStartPositionは２×８Ｋ＋４×８Ｋ−１Ｋ−２Ｋ＝４５Ｋバイトである。すなわち、ファイルのチャンク２に格納された部分は、そのファイルの始めから４５Ｋだけオフセットされて始まる。ステップ４４０における判断がＹＥＳの場合、すなわちChunkLengthがFileLengthとChunkStartPositionとの差より大きい場合、ChunkLength分のデータを読み出し、残りのデータはここでは考慮しない。

図５は読み出しプロセスの例を説明するフローチャートである。

読み出しプロセスはステップ５１０において始まり、ステップ５１１において、読み出すデータの長さが０より大きいか判断する。これは妥当性チェックである。判断結果がＮＯであれば、これは読み出すデータが無いことを意味する。次に、フローチャートはステップ５１２に進み、終了する。読み出すデータがあれば、プロセスはステップ５１３に進み、ファイルを読み出す準備としてパラメータを計算する。ステップ５１３において、OffsetInChunkを最初に計算する。これはカレントチャンクにおける読み出し動作のオフセットを示すポインタである。例えば、チャンク中のデータの第１のバイトのオフセットは「０」バイトであり、チャンク中のデータの第２のバイトのオフセットは「１」バイトであり、以下同様である。OffsetInChunk＝FilePosition−ChunkStartPositionである。FilePositionはファイルにおけるオフセットである。例えば、ファイル中のデータの第１のバイトのオフセットは「０」バイトであり、ファイル中のデータの第２のバイトのオフセットは「１」バイトであり、以下同様である。また、図３のチャンク０を例に取る。ファイルがチャンク０のデータの第１のバイトから読み出される。チャンク０のデータの第１のバイトはファイルのデータの第１のバイトでもあるので、FilePositionは０、ChunkStartPositionは０、そのためOffsetInChunkも０である。ファイルをデータの第５のバイトから読み出すとき、FilePositionは５バイトであり、ChunkStartPositionは０バイトである。そのためOffsetInChunkは５バイトである。次に、チャンク１のデータの第１のバイトの物理的位置を計算する。これは、ReadOffset＝ChunkStartAddressInHardDisk＋OffsetInChunk＋UnusedSizeInFirstBlockである。ChunkStartAddressInHardDiskはハードディスク上のカレントチャンクのアドレスである。よって、チャンク１の場合、UnusedSizeInFirstBlockは１Ｋバイトであり、ReadOffsetはChunkStartAddressInHardDisk＋１Ｋバイトである。すなわち、アプリケーションはチャンク１の物理的位置を求め、１Ｋバイトオフセットして、読み出すデータの実際の位置を求める。また、カレントチャンクからどれだけのデータを読み出せるか判断する：AvailableSizeInChunk＝ChunkLength−OffsetInChunk。チャンク１では、AvailableSizeInChunkは１３Ｋバイトである。

さらにステップ５１４において、読み出すデータ量Length_to_Readがカレントチャンク中のデータAvailableSizeInChunkより大きいか判断する。このステップを用いてカレントチャンクから読み出せば十分か判断する。さらにデータを読み出さねばならない場合、すなわちステップ５１４においてＹＥＳの場合、まずカレントチャンク中のデータをすべて読み出さねばならない。ステップ５１５において、ReadSizeInChunk＝AvailableSizeInChunkと設定する。ステップ５１４における判断がＮＯであれば、読み出すデータが、カレントチャンク中のデータ量より小さいことになり、フローチャートはステップ５１６に進み、Length_to_ReadをReadSizeInChunkに設定する。ステップ５１５と５１６の後、プロセスはステップ５１７に進み、読み出し動作を行い、ReadOffsetの位置からデータのReadSizeInChunkを読み出す。読み出し動作後、プロセスはステップ５１８に進み、パラメータLength_to_ReadとFilePositionとを更新する。データのReadSizeInChunkは上記のプロセスごとに読み出されるので、Length_to_ReadはLength_to_Read−ReadSizeInChunkに更新される。FilePosition＝FilePosition＋ReadSizeInChunkである。

さらに、ステップ５１９において、ファイルのデータがすべて読み出されたか判断する。判断結果がＹＥＳであれば、すなわち更新したLength_to_Readが０より大きければ、読み出されていないデータがまだある。ステップ５２０と５２１において、アプリケーションは次のチャンクに行き、その後の読み出しプロセスを実行する。また、ステップ５２１において、ChunkStartPositionが前のChunkStartPositionプラス前のChunkLengthに更新される。これは次のチャンクのChunkStartPositionである。ステップ５１９の判断結果がＮＯであれば、カレントファイルのデータはすべて読み出されているので、ステップ５２２においてプロセスが終了する。

図６と図７を参照して、書き込み動作の例を説明する。図４と図５で用いた記号、ラベル、識別子はこれ以上説明しない。

図６は、チャンクにデータを書き込むときに使える空きスペースの量の計算を示すフローチャートである。本プロセスはステップ６０１から始まる。ステップ６０２において、カレントチャンク中の実際のデータの長さを決定する。このステップは図４の読み出しプロセスにおける動作と同様であり、ここでは説明を省略する。次に、ステップ６０３において、カレントチャンクがファイルの最後のチャンクか判断する。判断結果がＮＯであれば、プロセスはステップ６０５に進み、終了する。判断結果がＹＥＳであれば、プロセスはステップ６０４に進み、カレントチャンク中の空きスペースはステップ６０２で求めた値にファイルの最後のチャンクのUnusedSizeInLastBlockの値を足したものである。

図７には書き込みプロセスの詳細を示した。

書き込みプロセスはステップ７１０から始まり、次にステップ７１２に進み、書き込むデータの長さが有効であるか判断する。判断結果がＮＯであれば、プロセスはステップ７１２に進み、終了する。ＹＥＳであれば、プロセスはステップ７１３に進み、カレントチャンクにおける書き込み位置と、ハードディスクにマッピングした位置と、カレントチャンクに何バイトのデータを書き込めるかとを計算する。これらの３つの値をOffsetInChunk、WriteOffset、AvailableWriteSizeInChunkで表す。ここでのOffsetInChunkの計算は読み出しプロセスにおけるものと同じである。しかし、ここでのOffsetInChunkは、カレントチャンクにおいて書き込みプロセスが始まる位置の計算に用いられる。WriteOffsetはカレントファイルを書き込む実際の物理的位置を示し、その計算プロセスは図４の読み出しプロセスにおけるReadOffsetと同様である。AvailableWriteSizeInChunkはカレントチャンクに書き込めるサイズを示す。これの計算プロセスは、ChunkLengthを図６のプロセスを用いて計算すること以外は、読み出しプロセスにおけるAvailableSizeInChunkと同様である。ステップ７１４において、データを書き込めるスペースがカレントチャンクにあるか、すなわちAvailableWriteSizeInChunkが０より大きいか判断する。ＮＯであれば、プロセスはステップ７２０に進み、次のチャンクを使えるか検討する。ステップ７１４における判断がＹＥＳなら、次にステップ７１５において、書き込むデータの長さLength_to_Writeが、書き込み動作に使えるサイズAvailableWriteSizeInChunkより大きいか判断する。ステップ７１５における判断がＹＥＳであり、すなわちカレントチャンクに書き込めるサイズが書き込むデータに対して足りなければ、他のチャンクが必要となる。プロセスはステップ７１６に進み、サイズがAvailableWriteSizeInChunkのデータを、ステップ７１８の書き込み動作で用いるWriteSizeInChunkに設定する。判断結果がＮＯであれば、カレントチャンクに書き込むデータに対し十分なスペースがあることになる。ステップ７１７において、Length_to_WriteをWriteSizeInChunkに設定し、プロセスはステップ７１８に進み、WriteSizeInChunkのサイズのデータをWriteOffsetの位置から書き込む。

順次、元のFilePositionは、元のFilePosition＋WriteSizeInChunkによって決まる位置に動く。ファイルの残りの書き込みデータのサイズは、元のLength_to_Writeから（すでにチャンクに書き込まれた）WriteSizeInChunkを引いたものに変更される。

ステップ７１５の判断結果によって後続の書き込みプロセスでチャンクがもっと必要となり得るので、ステップ７２０において、書き込むデータがまだあるか判断する。答えがＹＥＳであれば、ステップ７２１と７２２に示したように、次のチャンクに移って書き込みプロセスを実行する。ステップ７２４において、UnusedSizeInFirstBlockとUnusedSizeInLastBlockを０に初期化して次のチャンクに移る。書き込み動作が始まる位置をChunkStartPosition＝ChunkStartPosition＋ChunkLengthに変更する。

もう一つ重要なプロセスがある。それはファイルシステムからのデータの削除である。この重要なプロセスを図８乃至図１１に示した。

図８は削除プロセスの例を示すフローチャートである。このプロセスはステップ８０１から始まる。ステップ８０２において、削除を開始する位置を見つける判断をする。このステップは妥当性チェックプロセスである。その後、削除するデータの長さが有効な値であるか判断する（ステップ８０３）。ＮＯであれば、プロセスは８０５に進み、終了する。ＹＥＳであれば、ステップ８０４において、削除を始める位置OffsetInChunkと、カレントチャンクから削除するデータの長さとを決定する。OffsetInChunkを式OffsetInChunk＝FilePosition−ChunkStartPositionを用いて計算し、AvailableDeleteSizeを式AvailableDeleteSize＝ChunkLength−OffsetInChunkを用いて計算する。次に、プロセスはステップ８０６に進み、削除するデータの長さLength_to_Deleteが可憐とチャンク中のデータのサイズより小さくないか判断する。ステップ８０６における判断結果がＮＯであれば、カレントチャンクには削除するのに十分なデータがあることになる。次に、プロセスはステップ８１３−８１６に進み、削除動作を実行する。

ステップ８１３において、OffsetInChunkが０であるか判断する。このステップは、削除プロセスがチャンクのデータの最初のバイトから始まるか判断するものである。判断結果がＮＯである場合、すなわちカレントチャンクの削除動作がカレントチャンクの途中から始まる場合、プロセスはステップ８１５に進み、OffsetInChunkが示す位置からカレントチャンクのデータを削除する。同時に、ステップ８０６の判断結果がＮＯなので、カレントチャンクには削除が必要なデータより長いデータがあり、データの一部が残る。この場合、ステップ８１５においてカレントチャンクの中心部のみを削除し、プロセスはステップ８１６で終了する。ステップ８１３の判断結果がＹＥＳであれば、削除動作がカレントチャンクの始めから始まる。ステップ８０６の判断結果は否定なので、削除するデータ量よりも多いデータがあり、図テップ８１４においてカレントチャンクの先頭部分が削除される。削除動作をカレントチャンクの先頭部分から行うとき、残りのカレントブロック中の最初のブロックの先頭部分が部分的に削除され得る。このブロックはデータが部分的に入ったブロックになる。言い換えると、このブロックはそろっていない（not aligned）。新しいUnusedSizeInFirstBlockは、カレントチャンクに残っている最初のブロックの、使用されていない先頭部分のサイズを表す。新しいUnusedSizeInFirstBlockは次の関数を用いて計算する：UnusedSizeInFirstBlock＝（Length_to_Delete＋UnusedSizeInFirstBlock）％BlockSize。（Length_to_Delete＋UnusedSizeInFirstBlock）は解放されるエリアの長さを示す。演算「％」は割り算の余りを求めるものである。余りが０でなければ、削除後に残ったチャンクの最初のブロックの先頭部分に、データで占められていないスペースがあることになる。図９に例を示した。

図９において、カレントチャンクには５つのブロック１〜５がある。ブロック１の先頭に３Ｋバイトの不使用スペースがあり、ブロック５の終わりに２Ｋバイトの不使用スペースがある。すなわち、カレントチャンクのUnusedSizeInFirstBlockは３Ｋバイトであり、カレントチャンクのUnusedSizeInLastBlockは２Ｋバイトである。削除はブロック１の最初のデータから始まり、１８Ｋバイトのデータが削除される。Length_to_Deleteは１８Ｋバイトである。削除後、ブロック１−２は完全に削除されるので解放され、削除後のチャンクのUnusedSizeInLastBlockは削除前の元のチャンクのUnusedSizeInLastBlockと同じであり、UnusedSizeInFirstBlockは（Length_to_Delete＋UnusedSizeInFirstBlock）％BlockSize＝（１８＋３）％８＝５Ｋバイトに変わる。

ステップ８０６の判断結果が肯定であれば、カレントチャンクを全部削除しても足りない。この場合、プロセスはステップ８０７に進み、カレントチャンクの削除を始めからするか、途中からするか判断する。判断結果が否定であれば、削除動作はカレントチャンクのどこか途中から行われ、プロセスはステップ８０８に進み、チャンクのOffsetInChunkの位置からスペースの削除を行う。ステップ８０６の判断結果はＹＥＳであり、カレントOffsetInChunkからのデータを削除すること、及びチャンクの始めのデータは一部が残っていることを示しているので、カレントチャンクのUnusedSizeInFirstBlockとデータのサイズOffsetInChunkの総数がブロック全体（８Ｋバイト）でない場合、カレントチャンクの終わりに不使用スペースがあるはずである。そこで、ステップ８０８において、次の関数UnusedSizeInLastBlock＝BlockSize−（OffsetInChunk＋UnusedSizeInFirstBlock）％BlockSizeを用いてカレントチャンクの新しいUnusedSizeInLastBlockを計算する。ここで、OffsetInChunk＋UnusedSizeInFirstBlockはチャンクにデータが残っていることを意味する。演算「％」は割り算のあまりを求めるものである。演算「％」の後、新しい最終ブロックのデータの残り量を求める。それをBlockSizeから差し引き、最終ブロックの不使用サイズを求める。図１０はこのプロセスを示す例である。

図１０において、カレントチャンクには５つのブロック１〜５がある。ブロック１の先頭部分には不使用スペースが５Ｋバイトあり、ブロック５の終わり部分には不使用スペースが３Ｋバイトある。UnusedSizeInFirstBlockは５Ｋバイトであり、UnusedSizeInLastBlockは３Ｋバイトである。削除はブロック３の６Ｋバイトのところから始まり、１５Ｋバイトのデータが削除される。OffsetInChunkは１７Ｋバイトである。削除後、ブロック４−５は解放され、カレントチャンクのUnusedSizeInFirstBlockは変わらず、UnusedSizeInLastBlockの値は新しくなる。この新しい値はBlockSize−（OffsetInChunk＋UnusedSizeInFirstBlock）％BlockSize＝８Ｋ−（（１７＋５）％８）Ｋ＝８Ｋ−６Ｋ＝２Ｋバイトである。

しかし、ステップ８０７の判断結果が肯定であれば、削除動作がカレントチャンクの始めから始まる。ステップ８０６からステップ８０７に進むのはＹＥＳの場合なので、ステップ８０９においてチャンク全体が削除される。この動作の後、プロセスは次のチャンクに進み、ステップ８０３に戻る。

図８の削除がチャンクの中央部分の削除、すなわちステップ８１５のプロセスである場合、チャンクは２つのチャンクに分かれる。図１１はこの条件を処理する動作を示す。本プロセスはステップ１１１１から始まる。ステップ１１１２において、Offset＝OffsetInChunk＋UnusedSizeInChunkにより記述子「Offset」を計算する。次に、ステップ１１１３において、チャンクの同じブロックに対して削除を実行するか、すなわちブロックの中央部分を削除するか判断する。判断方法は、（Offset／BlockSize）＝（Offset＋Length_to_Delete）／BlockSizeであるか判断するものである。ここで、「／」は結果の整数部を求める演算である。ステップ１１１３の判断がＮＯであれば、チャンクのブロックがいくつか全体としてカレントチャンクの中央部分から削除されることになり、カレントチャンクは２つのチャンクに分かれる。ステップ１１１３の判断が肯定であれば、削除動作はブロックの中央部分で起こる。プロセスはステップ１１１４に進み、ブロックの後の部分をコピーして、削除するコンテンツを上書きするのに用いられる。Offsetの値は、元のOffsetの値に（BlockSize−（Offset＋Length_to_Delete）％BlockSize）を加えた値で更新される。ステップ１１１５の後、ステップ１１１６とステップ１１１７において一部の識別子の値を更新する。

新しいチャンクの記述子を設定し、元のチャンクの記述子の一部をステップ１１１６とステップ１１１７において変更する。

ステップ１１１６と１１１７のプロセスを図１２を参照してさらに説明する。図１２において、カレントチャンク、例えばチャンク５には、６つのブロックがある。StartBlockNumerはブロック１０であり、TotalBlockNumberは６ブロックであり、PreviousChunkNumberはチャンク４であり、NextChunkNumberはチャンク６であり、UnusedSizeInFirstBlockは３Ｋバイトであり、UnusedSizeInLastBlockは４Ｋバイトである。

削除動作を実行するとき、OffsetInChunkは１５Ｋバイトであり、Length_to_Deleteは２１Ｋバイトである。これは１５Ｋバイトより後の位置から２１Ｋバイトのデータが削除されることを意味する。そのため、OffsetはOffsetInChunk＋UnusedSizeInFirstBlock＝１５Ｋ＋３Ｋ＝１８Ｋバイトである。ステップ１１１３によると、（Offset／Block）＝（１８Ｋ／８Ｋ）≠（（Offset）＋Length_to_Delete）＝（（１８Ｋ＋２１Ｋ）／８Ｋ）なので、削除は単一のチャンクでは起こらない。削除後、元のファイルシステムに７つのチャンクがある場合、元のチャンク５は新しいチャンク５ともう一つのチャンク、例えばチャンク８に変わる。新しいチャンク５ではStartBlockNumberは変わらない。ステップ１１１６において、（Offset％BlockSize）＝（１８Ｋ％８Ｋ）＝２≠０なので、（（Offset／BlockSize）＋１）は新しいチャンク５のTotalBlockNumberであり、これは３ブロックに変わる。新しいチャンク５のPreviousChunkNumberは元のチャンク５のそれと同じである。NextChunkNumberはチャンク８に変わる。新しいチャンク５のPreviousChunkNumberは元のチャンク５のそれと同じである。新しいチャンク５のUnusedSizeInLastBlockはBlockSize−（Offset％BlockSize）＝８Ｋ−（１８％８）Ｋ＝８Ｋ−２Ｋ＝６Ｋバイトである。

チャンク８について、StartBlockNumberは、新しいチャンク５のStartBlockNumberに（Offset＋Length_to_Delete）／BlockSizeを加えたものであり、これは１０＋（１８Ｋ＋２１Ｋ）／８Ｋ＝１０＋４＝１４であり、すなわちブロック１４である。TotalBlockNumberは元のチャンク５のTotalBlockNumberから（Offset＋Length_to_Delete）／BlockSizeを差し引いたものである。すなわち、６−４＝２であり、チャンク８には２ブロックがある。チャンク８のPreviousChunkNumberはチャンク５であり、NextChunkNumberはチャンク６である。チャンク８のUnusedSizeInFirstBlockは（Offset＋Length_to_Delete）％BlockSize＝（１８＋２１）％８＝７Ｋバイトであり、UnusedSizeInLastBlockは元のチャンク５と同じサイズであり、４Ｋバイトである。ブロック１３はファイルシステムから完全に削除されるので、このスペースは解放される。

上記のファイルシステムは、セットトップボックスその他の装置のＰＶＲファイルシステムであってもよい。

実施形態を説明した。しかし、言うまでもなく様々な修正を行うことができる。また、当業者には言うまでもないが、開示した構成やプロセスを他の構成やプロセスで置き換えてもよく、その結果の実施形態が少なくとも実質的に同じ機能を果たし、少なくとも実質的に同じように、開示した実施形態と実質的に同じ結果を達成する。したがって、これらの実施形態やその他の実施形態が本出願では想定されており、特許請求の範囲に入る。

Claims

ファイルシステムにおけるファイルのデータ管理方法であって、前記ファイルのデータを格納する記憶スペースはサイズが同じで順次に付番された複数のブロックに分割され、
前記複数のブロックは順次に付番された複数のチャンクを構成し、各チャンクは少なくとも１つのブロックを有し、
前記方法は、
前記ファイル中のデータを削除するステップの後に、第１の管理データと第２の管理データとを用いて、各チャンクの最初のブロックの先頭部分と、最後のブロックの終わり部分とにある、データにより占有されていないスペースのサイズを記録するステップを有し、前記スペースのサイズは前記ブロックのサイズより小さいことを特徴とする、方法。
前記削除するステップは、前記チャンクの先頭部分または終わり部分からデータを削除するステップを有する、請求項１に記載の方法。
ファイルのデータを有する複数のチャンクがリンクされ、リンク情報がファイルシステム管理データに記録される、請求項１または２に記載の方法。
１つのチャンクが完全に削除されたとき、削除されたチャンクの記憶スペースを解放し、削除されたチャンクの前と後のチャンクをリンクする、請求項１ないし３いずれか一項に記載の方法。
前記ファイルの一部が削除され、その削除の開始位置と終了位置とが同一ブロックではないが同一チャンク中にあるとき、前記チャンクを新しい第１のチャンクと新しい第２のチャンクとに分割し、
第３の管理データと第４の管理データとを用いて、前記新しい第２のチャンクの最初のブロックの先頭部分と最後のブロックの終わり部分との空のスペースのサイズをそれぞれ記録するステップと、
前記新しい第１のチャンクと新しい第２のチャンクとをリンクして前記ファイルの連続性を保つステップとをさらに有する、
請求項１に記載の方法。
前記新しい第１のチャンクは削除前の最初のチャンクの番号を用いて付番され、前記新しい第２のチャンクは前記ファイルシステムの元の最後のチャンクに続く付番をされる、請求項５に記載の方法。
１つのブロックのデータを完全に削除したとき、前記ブロックのスペースを解放する、請求項５または６に記載の方法。
前記ファイルのデータの一部を１つのチャンクの１つのブロックの途中から削除したとき、
前記ブロックの削除されたデータに続くデータの残っている後半を前記ブロックのデータの前半の直後の位置に移動するステップと、
前記チャンク中の削除をしたブロックとその前のブロックとを新しい第１のチャンクとして再構成し、削除をしたブロックの後にブロックがあれば、そのブロックを新しい第２のチャンクとして再構成するステップと、
第３の管理データと第４の管理データとを用いて、前記新しい第２のチャンク中の最初のブロックの先頭部分と、最後のブロックの終わり部分との空きスペースのサイズをそれぞれ記録するステップと、
前記新しい第１のチャンクと新しい第２のチャンクとをリンクするステップとを有する、請求項１に記載の方法。
前記新しい第１のチャンクは削除前の最初のチャンクの番号を用いて付番され、前記新しい第２のチャンクは前記ファイルシステムの元の最後のチャンクに続く付番をされる、請求項８に記載の方法。
ファイルシステム管理データに前記チャンクのリンク情報を記録する、請求項８または９に記載の方法。
ファイルのデータを格納する記憶スペースが、サイズが同じで順次に付番された複数のブロックに分割されたファイルシステムであって、
前記複数のブロックは順次に付番されたチャンクを構成し、各チャンクは少なくとも１つのブロックを有し、
前記ファイルシステムは、各チャンクの先頭部分及び／または終わり部分の空き記憶スペースのサイズを示す、そのチャンクの管理データを有し、前記空き記憶スペースのサイズはブロックのサイズより小さいことを特徴とする、ファイルシステム。
前記チャンクの最初のブロックの先頭部分と最後のブロックの終わり部分のスペースのサイズを、第１の管理データと第２の管理データにより記録する、請求項１１に記載のファイルシステム。
ファイルの全チャンクがリンクされて前記ファイルの連続性を保ち、リンク情報がファイルシステム管理データに記録される、請求項１２に記載のファイルシステム。
請求項１１乃至１３に記載のいずれかのファイルシステムを含む記憶装置。