JP2005050383A - File data storage control method, file data storage device, program for executing process for storing file data, and storage medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently execute storage of real-time file data having large capacity while restraining fragmentation generated by repeating storage and erasure of file data having small capacity. <P>SOLUTION: A unit is composed of a plurality of continuous blocks other than blocks depending on a physical storage unit. The unit is set at capacity with real-time processing assured. Real-time file data such as image data are stored by unit. Data are stored by block for data processed in non-real time. A unit control table for controlling a unit is arranged, and whether the unit is usable or not in recording it is determined based on the unit management table. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a file data storage management method, a file data storage device, a program for executing processing for storing file data, and a storage medium, and in particular, can efficiently store real-time file data and non-real-time file data. It is.

  When data constituting one file (hereinafter referred to as file data) is stored in a storage medium, a method of assigning file data to a block obtained by dividing the storage area of the storage medium into a predetermined same capacity is employed. In this file storage method, use / unuse of each block is managed by a block management table.

File data is stored by searching for unused blocks with reference to this block management table and allocating a plurality of unused blocks for data storage in accordance with the capacity of the file data. At this time, a file configuration table indicating which block is used to store the file information is created. As this file configuration table, for example, a FAT (File Allocation Table) is used. FAT defines the physical connection of blocks constituting a file. Specifically, using a unique block number assigned to a block, a table is created that associates the block number with the number of a logically succeeding block for every block in the storage area. .
JP 2001-265628 A JP-A-8-101783

When storing file data having a capacity larger than the block length, for example, data having a large storage capacity such as video and audio, the file data is stored across a plurality of blocks. Here, if data is stored in a physically discontinuous area on the storage medium, when the data is read out in real time, it can be accessed smoothly depending on the movement time of the drive head. Cannot be performed, and continuous data processing may become difficult. Therefore, in consideration of storage of such a large amount of data to be processed in real time, it is desirable to set a large capacity for one block so as to secure a physically continuous area as much as possible.

  On the other hand, the data capacity of a file varies depending on the type of file, and there is a file with a very small data capacity such as a very small document file.

  However, in the current file storage method, since file data is stored in units of blocks, two or more file data cannot be stored in one block. Therefore, if the block capacity is too large, there will be an increase in free space in each block where actual data is not stored but data of other files cannot be stored. There arises a problem that the efficiency of use of the region is significantly reduced.

  On the other hand, if the block capacity is too small, the number of linked blocks becomes very large when recording a large amount of file data, and there is a concern that the access performance when reading these data will deteriorate. The

  In addition, when data is repeatedly stored and erased by frequently inputting and outputting data, it becomes difficult to secure a physically continuous free space, and so-called fragmentation occurs. obtain.

  FIG. 14 shows an example of file data allocation to a storage medium, and a block management table and a usage state of each block at that time. In the block management table of FIG. 1, 1 indicates that the block is used, and 0 indicates that the block is not used. In the figure, hatched portions 30x are used blocks, and plain portions 30y are unused empty blocks. In FIG. 14, empty blocks are scattered and fragmentation occurs.

  On the other hand, as shown in FIG. 15, for example, the management table can be configured so that four blocks are regarded as one block. Thus, by increasing the data capacity handled in the block management table, the above-mentioned fragmentation problem can be solved to some extent. However, in this case, as described above, the use efficiency of the storage area is significantly reduced.

  Accordingly, the present invention solves such a problem and efficiently stores even small file data by suppressing the occurrence of fragmentation while allocating file data suitable for storage and reproduction of real-time files. An object of the present invention is to provide a reproducible data storage method.

  In the present invention, a unit is composed of a plurality of continuous blocks, and attributes of the unit are managed by a unit attribute table. This unit attribute table includes information defining the usage status of each unit and information defining whether real-time data can be stored.

  When the stored file data is real-time data, the unit attribute table is referenced to search for an unused unit capable of storing real-time data, and this file data is stored in the block included in the searched unit. Is done. If the stored file data is non-real time data, the unit attribute table is referred to search for a unit in which the non-real time data is already stored in some blocks in the unit. An unused block included in the acquired unit is searched with reference to the block management table, and the file data is stored in the block acquired by this search.

  In this way, the number of unused units can be increased by changing the recording process depending on whether the stored file data is real-time data or non-real-time data, so that real-time data can be efficiently stored. Will be able to do.

  One aspect of the present invention is, for example, a block management table for managing whether or not data is stored in a block, a unit attribute table for managing attributes of a unit composed of a plurality of consecutive blocks, and the unit It can be understood as a file data storage method including data storage processing for storing file data based on the attribute table.

  Here, the unit attribute table includes information defining the usage status of each unit and information defining whether real-time data can be stored. In the data storage process, when the stored file data is real-time data, the unit attribute table is referenced to search for an unused unit that can store real-time data, and the unit included in the searched unit When this file data is stored in a block, and the stored file data is non-real time data, the unit attribute table is referred to and the non-real time data is already stored in some blocks in the unit And searching for unused blocks included in the unit acquired by this search with reference to the block management table, and storing the file data in the block acquired by this search.

  Another aspect of the present invention is, for example, a unit for generating a block management table for managing whether or not data is stored in a block, and a unit for managing attributes of a unit composed of a plurality of consecutive blocks It can be understood as a file data storage device including means for generating an attribute table and means for executing processing for storing file data based on the unit attribute table.

  Still another aspect of the present invention provides, for example, a process of generating a block management table for managing whether or not data is stored in a block, a unit composed of a plurality of consecutive blocks, and each unit It can also be grasped as a program for executing processing including processing for generating a unit attribute table for managing attributes and data storage processing for storing file data based on the unit attribute table.

  Still another aspect of the present invention is, for example, in addition to main data, at least a block management table for managing whether or not data is stored in the block, and an attribute of a unit composed of a plurality of consecutive blocks Can be grasped as a storage medium storing a unit attribute table for managing

  The above and other objects and novel features of the present invention will become more fully apparent when the following description of the embodiments is read in conjunction with the accompanying drawings.

The “block” in the claims of the present invention corresponds to the “block” in the embodiment. Further, “unit” in the claims of the present invention corresponds to “unit” in the embodiment. The “block management table” in the claims of the present invention corresponds to the “block management table 210” in the embodiment. The “unit attribute table” in the claims of the present invention corresponds to the “unit management table 211” in the embodiment. The “storage medium” in the claims of the present invention is “hard disk drive 118” in the embodiment.
(Hard disk built in it).

  However, the following embodiment is merely one embodiment of the present invention, and the meaning of the term of the present invention or each constituent element is not limited to that described in the following embodiment. Absent.

  According to the file recording management method of the present invention, file allocation suitable for reproduction of a real-time file can be performed, and occurrence of fragmentation of the storage area due to small-sized data can be suppressed, and the use efficiency of the storage area is improved. Can be made.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a block diagram showing the overall configuration of a digital recording / reproducing apparatus according to an embodiment of the present invention. In FIG. 1, signal lines indicated by bold lines are signal lines representing the flow of video and / or audio data, and signal lines indicated by thin lines are signal lines representing the flow of control signals.

The digital recording / reproducing apparatus includes an antenna 100, an external input terminal 101, tuners 102 and 103, a selector 104, A / D converters 105 and 106, MPEG2 video encoders 107 and 108, audio encoders 109 and 110, a multiplexer / demultiplexer 111, and MPEG2. Video decoder 112, audio decoder 113, D / A converter 114, buffer memories 115 and 116, hard disk drive controller module 117, hard disk drive 118, system controller 119, memory 120, user interface 121, graphic controller 122, television monitor 123, Real-time clock module 124, digital input 125, digital input And a Toputto 126, LED 127.

  Referring to FIG. 1, for example, a television broadcast signal wave received by antenna 100 is simultaneously applied to tuners 102 and 103.

  The tuner 102 selects the signal radio wave of one channel designated by the user from the signal radio wave received by the antenna 100, demodulates it into an analog television signal composed of a video signal and an audio signal, and inputs one of the selectors 104. To give. The other input of the selector 104 is connected to an external input terminal 101 to which various external television signal sources such as a video tape recorder (VTR) and a camcorder can be connected.

  The selector 104 selects either the output from the tuner 102 or the input from the external input terminal 101 and supplies it to the A / D converter 105 and also supplies it to one input of the graphic controller 122. Generally, the selector 104 selects an input from the external input terminal 101 when any external signal source is connected to the external input terminal 101, and selects an output of the tuner 102 when not connected.

  The A / D converter 105 converts the video signal and audio signal of the analog television signal output from the selector 104 into digital signals, respectively, and supplies the digital video signal to the MPEG2 video encoder 107, and also converts the digital audio signal into an audio encoder. 109.

  The MPEG2 video encoder 107 compresses the supplied digital video signal and supplies it to the multiplexer / demultiplexer 111, and the audio encoder 109 compresses the supplied digital audio signal and supplies it to the multiplexer / demultiplexer 111. The multiplexer / demultiplexer 111 multiplexes the supplied video signal stream and audio signal stream, and converts them into an MPEG2 system stream.

  On the other hand, the tuner 103 selects the signal radio wave of one channel designated by the user from the signal radio wave received by the antenna 100, demodulates it to an analog television signal composed of a video signal and an audio signal, and performs A / D. It is provided to the converter 106 and to the other input of the graphic controller 122.

  The A / D converter 106 converts a video signal and an audio signal of an analog television signal output from the tuner 103 into digital signals, respectively, and supplies the digital video signal to the MPEG2 video encoder 108, and also converts the digital audio signal into an audio encoder. 110.

  The MPEG2 video encoder 108 compresses the supplied digital video signal and applies it to the multiplexer / demultiplexer 111, and the audio encoder 110 compresses the supplied digital audio signal and supplies it to the multiplexer / demultiplexer 111. The multiplexer / demultiplexer 111 multiplexes the supplied video signal stream and audio signal stream, and converts them into an MPEG2 system stream.

  A hard disk drive (hereinafter referred to as HDD) 118 having a built-in hard disk as an example of a randomly accessible storage medium is detachably mounted on the digital recording / reproducing apparatus. In the following description, this single HDD 118 itself is regarded as a writable / readable storage medium for convenience. The writing of data to the HDD 118 and the reading of data from the HDD 118 are executed by the HDD controller module 117 as described later.

  Between the above-described multiplexer / demultiplexer 111 and the HDD controller module 117, there are a first data bus that includes the buffer memory 115 and a second data bus that includes the buffer memory 116. A system data channel is provided.

  Further, digital data from other devices externally connected via the digital input 125 can be input to the buffer memory 115, while the digital data in the buffer memory 116 can be externally connected via the digital output 126. Can be output to other devices.

  Therefore, as described later, MPEG2 system stream data is exchanged between the multiplexer / demultiplexer 111, the HDD controller module 117, the digital input 125, and the digital output 126 via the buffer memories 115 and 116. Will be done.

  The multiplexer / demultiplexer 111 demultiplexes the MPEG2 system stream received from the buffer memories 115 and 116 into a video signal stream and an audio signal stream, the former being the MPEG2 video decoder 112 and the latter being the audio decoder 113. To give.

  The MPEG2 video decoder 112 decodes the supplied video signal stream and supplies it to the D / A converter 114, and the audio decoder 113 decodes the supplied audio signal stream and supplies it to the D / A converter 114. The D / A converter 114 converts the applied signals into analog signals, and provides an analog television signal composed of a video signal and an audio signal to yet another input of the graphic controller 122.

  The graphic controller 122 selects any one of analog television signals given from the selector 104, the tuner 103, and the D / A converter 114, and is connected to the outside of the digital recording / reproducing apparatus. 123.

  The operations of the multiplexer / demultiplexer 111 and the graphic controller 122 are controlled by a control signal supplied from the system controller 120.

  When this digital recording / reproducing apparatus is connected to another external device via the digital input 125 and the digital output 126, the control signal from the system controller 119 is sent to the other via the digital input 125 (thin line). A control signal from the system controller (not shown) of the apparatus is supplied to the system controller 119 of the digital recording / reproducing apparatus via a digital output 126 (thin line).

  A user interface 121, a memory 120, and a real time clock module 124 are connected to the system controller 119.

  The basic operation principles such as storage, reproduction, and erasure of the digital recording / reproducing apparatus according to the present invention shown in FIG. 1 will be described in detail later in relation to the file storage method for the hard disk drive 118.

  Next, information stored in the hard disk, which is a storage medium in the present embodiment, will be described.

  As shown in FIG. 2, when data is stored as a file on a hard disk as a storage medium, data itself (hereinafter referred to as main data 20) to be stored, such as video and audio, and main data 20 are configured as files. Management information (hereinafter referred to as metadata 21) necessary for this is stored in the hard disk.

  The metadata 21 includes three pieces of information, that is, a block management table 210, a unit management table 211, and file management information 212. The metadata 21 is generated at the time of initial setting of a storage medium in the digital recording / reproducing apparatus, and is recorded or deleted every time data is recorded. Updated to

  Hereinafter, each management information will be described with reference to FIG.

  FIG. 3 is a diagram schematically illustrating a recording method using the unit management table.

<Block management table>
The block management table 210 manages the usage status of each block. The entries 210a, 210b, 210c, 210d,... Constituting the block management table 210 correspond to the blocks of the storage areas 30a, 30b, 30c, 30d,. "1" for the case, and "0" for the unused block.

<Unit management table>
The unit management table 211 manages the usage status of each unit when the storage area of the HDD 118 is regarded as an address space for each unit and unit numbers are assigned in order.

  The unit includes entries 211a, 211b,..., For example, the entry 211a is an entry of a unit corresponding to the entries 210a, 210b, 210c, and 210d on the block management table 210. The unit management table 211 shows unit status information indicating whether or not a real-time file can be stored for the unit, and unit usage status information indicating the usage status of the unit.

  Here, whether or not the real-time file can be stored in the unit is determined by monitoring the storage / reproduction operation by a special command for executing read / write, for example, in the same way as the determination in the embodiment 2 described later. This is done by determining whether storage / reproduction is guaranteed.

  Unit status information and unit usage status information of each unit are divided as shown in FIG. In the unit usage status information, “unused” refers to a state in which all the blocks constituting the unit can be stored. Further, “RT all used” means a state where all the blocks constituting the unit are continuously used for storing the real-time file. “NRT partial use” refers to a state in which a part of the blocks constituting the unit is used for storing a non-real-time file. “NRT full use” refers to a state in which all the blocks constituting the unit are used for storing non-real time files.

  Since the unit is a size necessary for real-time processing, there is no state in which the unit is partially used by the real-time file. Also, there is no real-time file and non-real-time file in the unit. Therefore, when the unit is “partially using NRT”, only the non-real time file can be stored in the remaining blocks.

<File management information>
Returning to FIG. 2, the file management information 212 is management information for recognizing the main data 20 as a file.

  In the file management information 212 of the file corresponding to the main data 20, link information of the blocks constituting the main data 20 is recorded. Specifically, attribute information (not shown in the figure) related to the main data 20 and block start address information are stored in the order of reference.

  The attribute information includes information indicating whether the main data 20 is data processed in real time.

  In the real-time file 201 (see FIG. 3), main data 20 processed in real time, such as an MPEG2 system stream created by the multiplexer / demultiplexer 111, is stored as the unit data described above.

  Therefore, the entire capacity of the real-time file 201 is always an integer multiple of the unit unit capacity. Also in the HDD 118 that records in block units, the start address of the real-time file 201 must be an address that corresponds to the boundary of the units. This is because the unit management table 211 regards the storage space as an address space for each unit.

  The file management information 212 indicating the file structure of the real-time file 201 stores link information of a block corresponding to the unit to which the real-time file 201 is allocated.

  In the case of the non-real-time file 202, the main data 20 that does not need to be processed in real time is stored as block-unit data. Therefore, the entire capacity of the non-real-time file 201 is an integral multiple of the block-unit capacity.

  Further, the file management information 212 indicating the file configuration of the non-real-time file 202 stores the link information of the block to which the non-real-time file 202 is allocated, as with the real-time file.

<Unit capacity>
Next, the capacity of a unit necessary for simultaneously handling a plurality of stream data in real time in the digital recording / reproducing apparatus will be described.

  First, the capacity C of the buffer memories 115 and 116, the unit block length L for writing / reading, the worst-case data transfer rate Bhdd between the HDD controller module 117 and the HDD 118, the rate Bsys of the MPEG2 system stream, and the HDD 118 The relationship between the seek time and the worst value Tw will be described.

  However, the worst value Tw of the seek time is not just the time required for only the head seek, but the seek time, rotation waiting time, and head switching time required from the start of the seek until the actual writing / reading of data starts. , Time required for error correction such as ECC / EDC, and the like, taking into account all worst group delay values.

  If the number of streams to be processed simultaneously is N, the following formula must be satisfied in order to maintain the real-time property of all streams.

Bhdd × Ts> N × (Tw + Ts) × Bsys (1)
However, Ts is the time required to write / read the unit block length L for writing / reading to / from the HDD 118, and is represented by Ts = L / Bhdd.

  In the above equation (1), in the case of data reading, the amount of data read in a unit block in a certain stream is N times of seek time and N times of data writing required to process N streams. This means that it is necessary to design so that it will not be consumed within the sum of the readout time.

  Further, in the case of data writing, the amount of data stored in the buffer memories 115 and 116 during the time required to process N streams is N × (Tw + Ts) × Bsys in the worst case. Means.

  Therefore, the capacity C of the buffer memories 115 and 116 needs to satisfy the following expression.

C> N × (Tw + Ts) × Bsys (2)
By designing so as to satisfy the above equations (1) and (2), N streams can be simultaneously processed in real time. However, N must be set within a range satisfying Bhdd> N × Bsys.

  When transferring real-time file data from the HDD 118 to the buffer memories 115 and 116, the data can be most efficiently processed when read in units. At this time, the unit capacity Usize can be expressed by the following equation.

Use size = L (3)
Here, since Ts = L / Bhdd as described above, the following expression can be obtained as a conditional expression for the Usize capacity by substituting this relational expression and the expression (3) into the above expression (1).

Usize> N × (Tw + (Usize / Bhdd)) × Bsys (4)
Video data and audio data for a certain period of time are stored in this capacity unit. In the apparatus of this embodiment, video data (Group of Pictures: hereinafter referred to as GOP) encoded by MPEG2 and audio data corresponding thereto are multiplexed by a multiplexer / demultiplexer 111 to form a system stream.

  If the number of pictures in 1 GOP is 15, the playback time of 1 unit is as follows.

5 * (15/30) = 2.5 seconds Here, with respect to these parameters, it is verified whether or not reproduction in units is guaranteed.

From the above definition, if the unit length of writing / reading is L = 2752512 bytes, the rate Bsys of the MPEG2 system stream is
Bsys = L / 2.5 = 11101004 bytes / second.

In this digital recording / reproducing apparatus, when the number of streams is N = 2, the worst value of seek time is Tw = 50 ms, and the worst case data transfer rate between the HDD controller module 118 and the HDD 119 is Bhdd = 5 MB / second. ,
Ts = L / Bhdd = 550 ms
Holds. Therefore, the left side Bhdd * Ts of equation (1) is
Bhdd * Ts = 5 × 10 ⁶ * 550 × 10 ⁻³ = 2.7 × 10 ⁶
The right side N * (Tw + Ts) * Bsys of the equation (1) is
N * (Tw + Ts) * Bsys = 2 * (50 + 550) × 10 ⁻³ * 1101004 = 1.32 × 10 ⁶
Thus, the above equation (1) is satisfied. Therefore, reproduction of data in units is guaranteed in these defined parameters.

  Next, file read (read) and write (write) operations will be described using a flowchart.

  FIG. 4 is a flowchart for explaining a file data read operation.

  First, when a file is opened by an application (step S1), the file management information of the file is read and the link information in the file management information is referred to. As described above, the link information defines the start address of each block storing the file information in the order of reference. The file information is read by referring to the link information in order from the beginning, obtaining the start address of each block, and reading the data in order from the block on the storage area indicated by the obtained start address. Here, the reference position of the link information is managed by a pointer.

  First, a pointer is set at the head of this link information (step S2), and the start address of the first block storing file information is acquired. Then, data is read from the block on the storage area indicated by the start address (step S3).

  Next, it is determined whether or not this block is the last logical block constituting the file (step S4). If it is the last, the file is closed (step S5), and the read operation is terminated. On the other hand, if there is a block following the logical block constituting the file, not the last block, the pointer indicating the link information reference position is advanced by one (step S2), and the next block storing the file information The start address of is obtained. Then, data is read from the block on the storage area indicated by the block start address (step S3).

  The above data reading is repeated until it is determined in step S4 that the block indicated by the pointer is the last block. Thereby, all the file information is read from the storage medium.

  FIG. 5 is a flowchart for explaining a real-time file write operation.

  When the application opens a real-time file (step S11), first, an unused unit is searched with reference to the unit management table 211 (step S12).

  The unused unit obtained as a result of the search is assigned to a unit for storing a new file, and main data 20 to be stored is sequentially stored in a series of blocks corresponding to the unit. At this time, the unit usage status information in the unit management table 211 corresponding to the unit used for storage is changed from “unused” to “RT all used”. Further, the block management table 211 is updated so that the flag of the block used for storage is changed to “1”. Further, link information of each block used for recording is added to the file management information 212 (step S13).

  Next, it is determined whether or not data to be stored remains (step S14). If there is no data to be stored, the file is closed (step S15), and the process is terminated. On the other hand, if there remains data to be stored, an unused unit is further searched (step S12). Data is stored in the unit obtained by the search (step S13). The above data storage process is repeated until it is determined in step S14 that there is no data to be stored.

  FIG. 6 is a flowchart for explaining a non-real-time file write operation.

  When the application opens the non-real-time file (step S21), first, it is searched with reference to the unit management table 211 whether an NRT partial use unit exists (step S22). As a result of the search, if there is no NRT partially used unit, the unused unit is searched with reference to the unit management table 211 again (step S24). Then, a block corresponding to the obtained unused unit is assigned as a block for storing the main data 20.

  Further, the unit usage status information of the unit management table 211 corresponding to the unit used for storage is changed from “unused” to “NRT partially used” (step S25).

  On the other hand, if there is an NRT partial use unit as a result of the search in step S22, an unused block in the obtained NRT partial use unit is assigned as a block for storing the main data 20 (step S23). . Here, when all unused blocks in the NRT partial use unit are used by storage, the unit usage status information of this unit is changed from “NRT partial use” to “NRT full use”.

  Then, the main data 20 is stored in the unused block assigned in step S23 or S24, and the block management table 210 is updated so that the flag of the block used for storage is changed to “1”. Further, the link information of the block used for storage is added to the file management information 212 (step S26).

  Next, it is determined whether or not data to be stored remains (step S27). If there is no data to be stored, the file is closed (step S28), and the process is terminated. On the other hand, when data to be stored remains, unused units and unused blocks are searched, and the process of storing data in the blocks obtained by the search (steps S22 to S26) is repeated.

  FIG. 7 is a flowchart for explaining a real-time file deletion operation.

  When the application selects a real-time file to be deleted (step S31), the first block among the blocks storing the selected real-time file is acquired with reference to the link information of the file management information 212. Further, the unit corresponding to the block is calculated from the unit size information in the unit management table 211 (step S32). Then, the data stored in this block is sequentially erased.

  When the data stored in the block is erased in this way, the block management table 210 indicating the use status of this block changes from “1” indicating that the block is in use to “0” indicating that it is not used. Changed to Further, when the data is erased for all the blocks in one unit, the unit usage status information in the unit management table 211 indicating the usage status of this unit is changed from “RT all used” to “not used” (step). S33).

  Then, it is determined whether or not data to be deleted remains (step S34). If there is no data to be deleted, the management information of this file is deleted from the file management information 212 (step S35), and the processing is performed. Is terminated.

  On the other hand, when there is data to be deleted, the pointer pointing to the link information of the file management information 212 is advanced by one, the next block is acquired, and the block corresponding to the block is obtained from the unit size information in the unit management table 211. A unit is calculated (step S32). Then, similarly to the above, the block management table 210 and the unit management table 211 are updated (step S33). This update process (steps S32 and S33) is repeated until it is determined in step S34 that there is no data to be deleted.

  FIG. 8 is a flowchart for explaining a non-real-time file deletion operation.

  When the application selects a non-real-time file to be deleted (step S41), the first block among the blocks storing the selected non-real-time file is acquired with reference to the link information of the file management information 212.

  Next, the block management table 210 indicating the use status of this block is changed from “1” indicating that it is in use to “0” indicating that it is not used (step S43). Further, the usage status of other blocks included in the unit corresponding to this block is checked (step S44), and when all the blocks constituting the unit are unused, unit management indicating the usage status of this unit. The unit usage status information in the table 211 is changed to “unused” (step S46).

  When a part of the blocks constituting the unit is used, the unit usage status information of the unit management table 211 indicating the usage status of this unit is changed to “NRT partial usage”. (Step S45).

  Next, it is determined whether or not there is data to be deleted (step S47). If there is no data to be deleted as a result of the determination, the management information of this file is deleted from the file management information 212 ( Step S48), the process is terminated. On the other hand, if there remains data to be deleted, the pointer pointing to the link information of the file management information 212 is advanced by 1, and the next block is acquired (step S42). Then, similarly to the above, the block management table 210 and the unit management table 211 are updated (steps S43 to S46). This update process (steps S42 to S46) is repeated until it is determined in step S47 that there is no data to be deleted.

  FIG. 9 is a flowchart for explaining the initialization operation of the storage medium.

  When the storage medium is used for the first time in this apparatus, the management data used for managing the storage area, specifically, the block management table 210 in the metadata 21 and the unit so that the storage medium can be used in this apparatus A management table 211 is generated and initialized.

  The unit capacity and the number of units are defined by the application, and the unit management table 211 is initialized according to this (step S51).

  In the block management table 210, “0”, which is not used for all blocks, is set (step S52).

  In the unit management table 211, “RT usable unit” indicating that a real-time file can be stored is set as the status information for all units, and all the blocks constituting the unit are used as the unit usage status. Is set to “unused” indicating that it can be stored (step S52).

  As described above, in this embodiment, when managing the storage location of the main data storage medium, in addition to the blocks depending on the physical storage unit used in the conventional file storage method, it is processed in real time. A unit which is a recording unit suitable for storing data to be stored is used.

  This unit is set to a capacity that guarantees real-time processing and is composed of a plurality of continuous blocks. Units and blocks are uniquely associated by calculation using unit size information in the unit management table. Even when real-time files such as video data stored in the above are stored in units, it is possible to read out file data in units of blocks using only the block management table 210 without requiring the unit management table 211.

  In addition, for data processed in non-real time, data is stored in units of blocks as in the past, but the unit management table is also updated in accordance with the block usage status at this time.

  As described above, by changing the storage unit according to the data attribute, the storage medium can be used efficiently, and the occurrence of fragmentation of the storage area can also be suppressed.

  Incidentally, in the above embodiment, the unit management table defines only two types of units, “RT usable unit” and “RT unusable unit”, depending on whether the unit is used or not used. . However, as data recording / erasing is repeated, defective areas that cannot be compensated by error correction occur. As a result, even if the unit is unused, there may occur a case where the unit cannot be used for storage / reproduction of the real-time file.

  That is, in a storage medium such as a hard disk, an alternative area is usually prepared in order to cope with the occurrence of a defective area. When a defective area occurs, data is assigned to the alternative area.

  However, the alternative area is usually physically separated from the series of storage areas. Therefore, when data is stored in the alternative area, extra time such as seek or rotation is required during storage and reproduction. Therefore, even if the unit is not in use, if there is a defective area in the unit, the writing / reading rate necessary for storing / reproducing the real-time file may not be guaranteed. For this reason, even if the unit is not used, if a defective area occurs, the unit may not be used as an RT usable unit as it is.

  On the other hand, in digital broadcasting, for example, the bit rate for HD (High Definition) broadcasting is about 24 Mbps, and the bit rate for SD (Standard Definition) broadcasting is about 8 Mbps. Therefore, when a defective area occurs in a predetermined unit, it may be possible to use the unit for SD broadcasting at a lower rate even if the unit cannot be used for HD broadcasting. For this reason, even if the writing / reading rate of a unit decreases due to the occurrence of a defective area, it is not appropriate to make the unit “RT unusable” uniformly.

  Therefore, in the present embodiment, the rank division of the write / read rate is assigned to each unit, and this rank division is included in the unit management table. When writing a real-time file, the rank classification is referred to and a unit that can guarantee the transfer rate of the file is selected as the target unit.

  In the initial state, each unit is set to the rank category of the highest rate. Then, at the time of subsequent writing / reading, it is determined whether or not the real-time file transfer rate can be guaranteed. If the real-time file transfer rate cannot be guaranteed, the rank classification is changed to a rank lower than the file transfer rate.

  Whether or not the transfer rate of the real-time file can be guaranteed is determined using, for example, a special command used when an HDD (hard disk drive) is used for AV data storage. This command is a command that emphasizes real-time characteristics, and is a command that executes read and write with time restrictions.

<Read / write command with time limit>
The definition of the time here is that the HDD always returns a response to the host side within the specified time. When these commands are used, the processing priority on the HDD side is as follows.

  1. Notifies the host after completing the data input / output normally within the specified time.

2. When an error occurs in the middle and retry or alternative processing is required;
If it can be processed within the specified time, it is executed. If the specified time is exceeded, the error is ignored, the input / output processing for the specified number of sectors is terminated within the specified time, and the host is notified. In this case, the host is notified in the form of “an error has occurred but I / O has been completed”, and the error information is left in the log.

3. I / O processing is not completed even if the error that occurred is ignored;
The processing is interrupted within the specified time and notified to the host in the form of a “timeout error”. Originally, it is assumed that a response is returned within the specified time. However, as an exception, at least one read / write is performed, and no response is made within the specified time only when the specified time has already been exceeded. Be good. However, it is necessary to inform the host that the specified time is over.

  As described above, when there is a defect in the unit on the HDD medium as a storage medium, the real-time property in the data access of that part is lowered. Therefore, if the unit status information for each unit is provided with a rank classification of the bit rate that can be guaranteed by the unit, by referring to this, the data of various bit rates are allocated to each appropriate unit, so that the real time And storage using the storage medium effectively can be realized.

  Hereinafter, a more specific configuration and control of the embodiment will be described.

<Media alternative>
When there is a defect on the HDD medium as a storage medium, a substitute block is usually assigned.

  In the case of an optical disk or the like, the position and number of alternative blocks are determined as standards, but in the case of an HDD, only the command interface is defined, and the internal structure differs for each drive vendor. Therefore, an alternative processing sequence, an alternative block position, an overhead time for reading and writing an alternative block, etc. are not defined. This is a problem when performing real-time processing, and will be described below.

<Relationship between physical address and logical address and fragmentation>
FIG. 13 shows the relationship between the physical address, logical address, and defective block management list on the medium. Hereinafter, the processing procedure of the defective block and the fragmentation associated therewith will be described.

  Taking a hard disk as an example, normally, at the start of use, the continuity of logical addresses accessed from the host may be considered to be the continuity of physical addresses on the medium. Originally, defective sectors already existing at the time of product shipment are replaced at the time of shipment, but are omitted here for simplicity.

  An alternative block for a later defective block is prepared on the disk. In the case of a hard disk, the number and physical position are not defined, and for example, alternative block areas are arranged collectively on the innermost periphery of the disk. Of course, there is no mapping to logical addresses for this area.

  As shown in FIG. 13, for example, when the logical block A is determined to be a defective block, the drive remaps the physical block A corresponding to the logical block A to the alternative block B + 1. The information is registered in the defect list.

  As described above, when the replacement process of the defective block is performed, in the unit corresponding to the block for which the replacement process has been performed, although the logical addresses are continuous, the logical block A is actually not physically continuous. A state occurs and a seek occurs before and after the block. This is a cause that becomes fatal to real-time processing.

<Correlation between AV stream real-time guarantee and alternative processing>
The following is an example of real-time processing of an AV stream.

If the worst case transfer rate a (MB / s), worst case (seek time + rotation waiting time) b (sec), unit size c (MB), and AV stream bit rate d (MB / s),
The access (read / write) time to the worst case unit is
y = c / a (sec),
The playback time of AV stream in units is
z = c / d (sec)
It becomes.
The relationship in real time processing of one AV stream is as follows.

y + b <z i.e. y <z-b
The relationship in real time processing of two AV streams is as follows.

2 * (y + b) <z That is, y <z / 2−b
The relationship in real-time processing when n locations of units are arranged in an alternative block in one AV stream is as follows.

y + (n + 1) b <z That is, y <z- (n + 1) b
In units that are alternately accessed by two AV streams, the relationship in real-time processing in the case where a total of n locations are arranged in alternative blocks in any two units that are accessed successively is as follows.

2y + (n + 2) b <z That is, y <z / 2− (n + 2) b / 2
Thus, the more alternative processing, the longer the unit access time. And if a certain threshold is exceeded, real-time property will break down.

  Therefore, it becomes necessary to disable the unit at a point where the number of alternative blocks increases.

<Unit management table>
The unit management table 211 manages the usage status of each unit when the storage area of the HDD 118 is regarded as an address space for each unit and unit numbers are assigned in order.

  As shown in FIG. 3, the unit is composed of entries 211a, 211b,..., For example, the entry 211a is an entry of a unit corresponding to the entries 210a, 210b, 210c, 210d on the block management table 210. The unit management table 211 defines unit status information indicating whether or not a real-time file can be stored for the unit and unit usage status information indicating the usage status of the unit.

Unit state information and unit usage status information of each unit are divided as shown in FIG.

  The unit usage status information indicates four statuses of “RT full use”, “Not used”, “NRT partial use”, and “NRT full use”, as in the first embodiment.

  The unit status information indicates either “RT usable unit” or “RT unavailable unit”. Here, “RT usable unit” refers to a state in which real-time information can be recorded. The “RT unusable unit” refers to a state where real-time information cannot be recorded.

  The above-mentioned “RT usable unit” further depends on the bit rate of the real-time stream, for example, “unit usable with RT stream up to 30 Mbps”, “unit usable with RT stream up to 15 Mbps”, and “RT stream up to 5 Mbps”. It is divided into three stages of “usable units”.

  As described above, for example, in digital broadcasting, the bit rate for HD broadcasting is about 24 Mbps, and the bit rate for SD broadcasting is about 8 Mbps. In this case, even a unit that can no longer be used for storing HD broadcast programs may be usable for storing SD broadcast programs. When recording an analog broadcast, for example, three different bit rates are assumed: a high-quality recording mode of 10 Mbps, a standard recording mode of 6 Mbps, and a long-time recording mode of 3 Mbps. Also in this case, a unit that cannot be used in the high-quality recording mode may be usable in the standard recording mode or the long-time recording mode.

  The unit is an area that can be continuously recorded on the physical medium, but when a defective block is found, the block is reassigned to the replacement area. In this case, logically, even if it is continuous, a boundary is generated there and a seek and rotation waiting time are required. This can be fatal to real-time processing in some cases.

  Therefore, in the initial state, the unit can be used at the highest bit rate rank as real-time processing, but the bit rate that can be supported by the unit changes as the unit continues to be used. If it is determined that it cannot be used, it is necessary to make it impossible to record real-time information.

  This check on the system side can be executed, for example, by performing a unit-unit read or write using the time-limited command with the time limit described above. The time limit parameter is a limit time at which real-time processing does not fail depending on the bit rate.

  By using this command, the unit that has exceeded the time limit cannot be used at that bit rate, so that the bit rate rank is lower than the command bit rate.

  Here, the bit rate of the command is obtained by dividing the data size to be read and written by the command by the time limit. A unit that cannot be used even at the lowest bit rate is a unit that cannot record real-time information.

  FIG. 11 is a flowchart for explaining a file read operation according to the second embodiment.

  First, when a file is opened by an application (step S61), the link information stored in the file management information 212 of the file is referred to. At this time, the reference position of the link information is managed using the pointer. A block start address is obtained from the link information at the position pointed to by the pointer, and data is read from the block in the storage area indicated by the block start address by an AV command with time limit (step S62).

  Next, it is determined whether or not “specified time over” has occurred by the read command with time limit (step S63). As a result, when a “specified time over” error occurs, the bit rate rank that can be supported in the unit status information of the unit management table 211 corresponding to the used unit is changed to a rank lower than the bit rate of this command. (Step S64).

  Then, it is determined whether or not the block being read is the last logical block constituting the file (step S65). If it is the last, the file is closed (step S66), and the read operation is terminated.

  If there is a block that is not the last of the logical blocks that make up the file, the block that is being read advances the pointer that indicates the link information reference position, and the block start address is obtained from the next link information. Data is read from the block on the storage area indicated by the block start address (step S62). This reading process (steps S62 to S64) is repeated until it is determined in step S65 that the block being read is the last.

  FIG. 12 is a flowchart for explaining a real-time file write operation according to the second embodiment.

  When the application opens the real-time file (step S71), first, referring to the unit management table 211, an unused unit and a usable unit at the write bit rate are searched. (Step S72).

  The unit obtained as a result of the search is assigned to a unit for storing a new file, and the main data 20 to be stored is stored in a series of blocks corresponding to the unit by a time-limited write command. At this time, the unit usage status information of the unit management table 211 corresponding to the unit used for storage is changed from “unused” to “RT all used”. Further, the block management table 211 is updated so that the flag of the block used for storage is changed to “1”. Further, link information of each block used for recording is added to the file management information 212 (step S73).

  Next, it is determined whether or not “specified time over” has occurred by the time-limited write command in step S73 (step S74). As a result, when the “specified time over” error occurs, the bit rate rank that can be supported in the unit status information of the unit management table 211 corresponding to the used unit is changed to a rank lower than the bit rate of the command ( Step S75).

  Next, it is determined whether or not data to be stored remains (step S76). If there is no data to be stored, the file is closed (step S77), and the process ends. On the other hand, when data to be stored remains, the processing from step S72 is further repeated.

  Assuming that there are no read and write errors in the read and write operations, if a “specified time over” error occurs in a command with a time limit, it may be determined that the block is already in a fragmented state. it can. Therefore, in this case, the bit rate rank that can be handled in the unit state information is set to a rank lower than the bit rate of the command.

  Note that the initialization operation of the storage medium according to the second embodiment is the same as the initialization operation (FIG. 9) of the storage medium according to the first embodiment. Here, in step S52, “RT usable unit (up to bit rate a Mbps)” indicating that the real-time file having the highest bit rate can be stored is further set as the state information.

  As described above, according to the present embodiment, in addition to the merit that the write processing of the real-time file and the non-real-time file can be performed smoothly and efficiently as in the first embodiment, it is further required. Various real-time file data having different bit rates can be efficiently distributed and recorded on the same HDD, and thus the use efficiency of the HDD can be further improved.

  Needless to say, the present invention is not limited to the above embodiment. In the above embodiment, the digital recording / reproducing apparatus for recording / reproducing MPEG data has been described as an example. However, the digital recording / reproducing apparatus for recording / reproducing only audio data, and the data obtained via the Internet are recorded / reproduced. It can be widely used for recording / reproducing apparatuses.

  2 and 10 and the programs for executing the processes shown in FIGS. 4 to 9, 11, and 12 are preinstalled in the HDD control module 117. It can also be realized by downloading from a storage medium such as a CD-ROM, or downloading from an application server via the Internet.

  In addition, metadata update timing, metadata file configuration timing, and the like can be changed as appropriate.

1 is a diagram illustrating the overall configuration of a recording / reproducing apparatus according to a first embodiment. The figure which shows the structure of the recording information which concerns on the form of Example 1 The figure which shows typically the recording method which concerns on the form of Example 1. FIG. Flowchart of read operation according to embodiment 1 Flowchart of write operation according to embodiment 1 Flowchart of write operation according to embodiment 1 Flowchart of deletion operation according to embodiment 1 Flowchart of deletion operation according to embodiment 1 Flow chart of initialization operation of storage medium according to embodiment 1 The figure which shows the structure of the recording information which concerns on the form of Example 2. Flowchart of read operation according to embodiment 2 Flowchart of write operation according to embodiment 2 Diagram showing the relationship between physical address and logical address on media and defective sector list The figure which shows the structure of the file in the conventional file recording method The figure which shows the structure of the file in the conventional file recording method

Explanation of symbols

30, 30a-30d Block 201 Real-time file 1
202 Non-real-time file 2
210 Block management table 210a to 210d Block management table entry 211 Unit management table 211a, 211b Unit management table entry

Claims (17)

A file data storage management method for storing file data in a storage area divided into a plurality of blocks,
Processing for setting a block management table for managing whether data is stored in the block;
A process for setting a unit attribute table for managing attributes of units composed of a plurality of consecutive blocks;
Storing file data based on the unit attribute table,
The unit attribute table includes information defining the usage status of each unit and information defining whether real-time data can be stored,
The data storage process includes:
When the file data to be stored is real-time data, the unit attribute table is referenced to search for an unused unit capable of storing real-time data, and the file data is stored in the block included in the searched unit. Including processing to
And a file data storage management method. A file data storage management method for storing file data in a storage area divided into a plurality of blocks,
Processing for setting a block management table for managing whether data is stored in the block;
A process for setting a unit attribute table for managing attributes of units composed of a plurality of consecutive blocks;
Storing file data based on the unit attribute table,
The unit attribute table includes information defining the usage status of each unit and information defining whether real-time data can be stored,
The data storage process includes:
If the stored file data is non-real-time data, the unit attribute table is referenced to search for a unit in which non-real-time data is already stored in some blocks in the unit. A process of searching for an unused block included in each unit with reference to the block management table and storing the file data in the block acquired by the search.
And a file data storage management method. In claim 2,
When the file data to be stored is non-real-time data, the data storage process cannot acquire a unit in which non-real-time data is already stored in some blocks in the unit with reference to the unit attribute table A file data storage management including a process of searching for an unused unit with reference to the unit attribute table and storing the file data in the block included in the unit obtained by the search Method. In any one of Claim 1 to 3,
A file data storage management method, further comprising a link table that defines a link of blocks used for storing file data for each file data. In any one of Claims 1-4,
The capacity Usize of the unit is
Usize> N × (Tw + (Usize / Bhdd)) × Bsys,
(However, the minimum data transfer rate Bhdd with the storage unit, the bit rate Bsys of the data stream, the worst value Tw of the seek time in the storage unit, and the number of streams to be processed simultaneously is N). File data storage management method. A file data storage device for storing file data in a storage area divided into a plurality of blocks,
Means for generating a block management table for managing whether or not data is stored in the block;
Means for generating a unit attribute table for managing attributes of units composed of a plurality of consecutive blocks;
Means for storing file data based on the unit attribute table;
The unit attribute table includes information defining the usage status of each unit and information defining whether real-time data can be stored,
Means for storing the data are:
When the file data to be stored is real-time data, the unit attribute table is referenced to search for an unused unit capable of storing real-time data, and the file data is stored in the block included in the searched unit. A file data storage device. A file data storage device for storing file data in a storage area divided into a plurality of blocks,
Means for generating a block management table for managing whether or not data is stored in the block;
Means for generating a unit attribute table for managing attributes of units composed of a plurality of consecutive blocks;
Means for storing file data based on the unit attribute table;
The unit attribute table includes information defining the usage status of each unit and information defining whether real-time data can be stored,
Means for storing the data are:
If the stored file data is non-real-time data, the unit attribute table is referenced to search for a unit in which non-real-time data is already stored in some blocks in the unit. A file data storage device for storing the file data in an unused block included in the unit. In claim 7,
When the file data to be stored is non-real time data, the means for storing the data refers to the unit attribute table, and the non-real time data is already stored in some blocks in the unit. When a unit cannot be acquired, an unused unit is searched with reference to the unit attribute table, and the block included in the unit acquired by this search is searched with reference to the block management table. A file data storage device for storing the file data in an acquired block. In any of claims 6 to 8,
A file data storage device further comprising means for generating a link table for defining a link of blocks used for storing file data for each file data. In any of claims 6 to 9,
The capacity Usize of the unit is
Usize> N × (Tw + (Usize / Bhdd)) × Bsys,
(However, the minimum data transfer rate Bhdd with the storage unit, the bit rate Bsys of the data stream, the worst value Tw of the seek time in the storage unit, and the number of streams to be processed simultaneously is N). File data storage device. A program for executing processing for storing file data in a storage area divided into a plurality of blocks,
Constructing a unit from a plurality of consecutive blocks, and generating a unit attribute table for managing attributes of each unit;
A data storage step for storing file data based on the unit attribute table;
Generating a block management table for managing whether or not data is stored in the block,
The unit attribute table includes information defining the usage status of each unit and information defining whether real-time data can be stored,
The data storing step includes
When the file data to be stored is real-time data, the unit attribute table is referenced to search for an unused unit capable of storing real-time data, and the file data is stored in the block included in the searched unit. A program comprising the steps of: A program for executing processing for storing file data in a storage area divided into a plurality of blocks,
Constructing a unit from a plurality of consecutive blocks, and generating a unit attribute table for managing attributes of each unit;
A data storage step for storing file data based on the unit attribute table;
Generating a block management table for managing whether or not data is stored in the block,
The unit attribute table includes information defining the usage status of each unit and information defining whether real-time data can be stored,
If the stored file data is non-real-time data, the unit attribute table is referenced to search for a unit in which non-real-time data is already stored in some blocks in the unit. And storing the file data in an unused block included in the unit. In claim 12,
In the data storage step, when the file data to be stored is non-real-time data, the unit attribute table is referred to and a unit in which non-real-time data is already stored in some blocks in the unit cannot be acquired. The unit attribute table is referenced to search for an unused unit, the block included in the unit acquired by this search is searched for by referring to the block management table, and the block acquired by this search A program for storing the file data. In any of claims 11 to 13,
A program further comprising a step of generating a link table that defines, for each file data, a link of blocks used for storing file data. In any of claims 11 to 14,
The capacity Usize of the unit is
Usize> N × (Tw + (Usize / Bhdd)) × Bsys,
(However, the minimum data transfer rate Bhdd with the storage unit, the bit rate Bsys of the data stream, the worst value Tw of the seek time in the storage unit, and the number of streams to be processed simultaneously is N). Program to do. A storage medium in which file data is stored in a storage area divided into a plurality of blocks,
A block management table for managing whether or not data is stored in the block;
A unit attribute table for managing attributes of a unit composed of a plurality of consecutive blocks is stored;
The unit attribute table includes information defining usage status of each unit and information defining whether real-time data can be stored. In claim 16,
The storage medium further stores a link table for defining a link of blocks used for storing file data for each file data.

Images