JP2010015253A - Recording/reproducing device and recording/reproducing method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a new and improved technique which can provide a technique of preventing logic destruction and perpetuating a file while maintaining performance. <P>SOLUTION: A recording/reproducing device has a file system section 130 which generates one or a plurality of requests and registers them in a mirror request queue 141 and sets a predetermined value in a mirroring request flag when finishes the registration. The recording/reproducing device has a transaction mirroring driver section 140 which registers one or a plurality of requests which are registered in a mirror request queue 141 into a request queue 151, refers to a mirroring request flag when all processes to one or a plurality of registered requests are completed, and registers one or a plurality of requests registered in the mirror request queue 141 to a request queue 161 if a predetermined value is set in the mirroring request flag. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a recording / reproducing apparatus and a recording / reproducing method. More specifically, the present invention relates to a backup technology for performing data recovery when a failure occurs.

  Conventionally, there are various techniques for persisting files that require periodic rewriting. For example, there is a technique for duplicating files. In this duplex technology, two files, an original file and a backup file, are created and each is recorded in storage in units of files. This prevents system failure even if one of the files is destroyed or disappeared.

  Moreover, there is RAID as a technique for increasing the volume destruction resistance (see, for example, Patent Document 1). Among these, a technique for replicating a volume is RAID 1 (mirroring). In this case, the file is mirrored in units of access to the storage, and replication is realized at the driver level or the hardware level. The processing that increases as compared with the case of not duplicating has the merit that it is not as large as the file duplication technique described above.

JP 2003-296047 A

  However, the file duplication technique has a problem that it is difficult to realize from the viewpoint of performance when a file that is periodically / frequently changed is targeted.

  In addition, according to the technique disclosed in Patent Document 1 described above, duplication can be performed while maintaining performance to some extent, but from the viewpoint of logical destruction of the file system, the file in the failure that occurred during the transaction There was a problem that permanence cannot be guaranteed.

  Currently, no technology has been established to maintain the performance while preventing logical corruption and making the file permanent.

  The present invention has been made in view of the above problems, and the object of the present invention is to provide a novel and permanent technology that can prevent logic corruption and maintain a file while maintaining performance. It is to provide improved technology.

  In order to achieve the above object, according to an aspect of the present invention, a recording / reproducing apparatus receives an input of a transaction from a system call unit, generates one or a plurality of requests necessary for transaction processing, A file system unit is provided that registers a plurality of requests in a mirror request queue and sets a predetermined value in a mirroring request flag stored in a memory when registration is completed.

  The recording / playback device also has a mirror request queue, registers one or more requests registered in the mirror request queue in the original volume write request queue, and completes the processing for the registered one or more requests. Then, refer to the mirroring request flag, and when a predetermined value is set in the mirroring request flag, transaction mirroring that registers one or more requests registered in the mirror request queue in the backup volume write request queue A driver part is provided.

  The recording / reproducing apparatus includes an original volume interface driver unit that has an original volume write request queue and outputs a request fetched from the request queue.

  The recording / reproducing apparatus also has a backup volume write request queue, and includes a backup volume interface driver unit that outputs a request fetched from the request queue.

  In addition, the recording / reproducing apparatus writes the original data included in the request output from the original volume interface driver unit to the original volume, and writes the backup data included in the request output from the backup volume interface driver unit to the backup volume. A storage control unit for controlling processing is provided.

  According to this configuration, after the file system unit registers the request in the mirror request queue, the transaction mirroring driver unit controls the backup. Therefore, after the file system unit registers the request in the mirror request queue, the backup control by the file system unit becomes unnecessary.

  According to the present invention, it is possible to provide a technique for preventing logical destruction and making a file permanent while maintaining performance.

  Exemplary embodiments of the present invention will be described below in detail with reference to the accompanying drawings. In the present specification and drawings, components having substantially the same functional configuration are denoted by the same reference numerals, and redundant description is omitted.

<< Recording / reproducing apparatus applicable to this embodiment >>
There are several ways to guarantee a file that will permanently damage the system if it is destroyed. For example, file duplication (duplicate writing of original file and backup file) and RAID (Redundant Arrays of Independent Disks) (volume mirroring). A conceptual diagram of these methods is shown in FIG.

  Duplicating files is to create two files, original and backup, on a file-by-file basis, so that even if one of them is destroyed or disappeared, it will not fail systematically. Here, the problem is how to perform the double writing of the file (the timing of performing the backup).

  If it is a file that does not require frequent changes, such as a settings file, back it up before changing the settings. If a failure occurs while reflecting the change contents in the storage, it can be dealt with by returning to the backup time (before the change), and even if it is returned before the change, there is no system impact. Most of the increase in processing due to double writing of files is also acceptable in the system.

  However, in the case of a file that needs to be changed periodically, if the throughput for writing is severer, if double writing is performed every time the change is made, the required throughput cannot be satisfied, and the system fails. If the timing for performing the double writing is thinned out, a systemic effect will be caused when it is restored before the change.

  A typical example in which this periodic and throughput is required is when performing stream recording (broadcast recording). In stream recording, stream data is input to the system at a certain rate, and the system records the data in storage. If the recording rate is lower than the input rate, the system will fail. Further, in this stream recording, it is necessary to periodically write reproduction data necessary for reproducing the recorded content to a file, and if this file is destroyed or lost, there is an effect that reproduction cannot be performed. The file in which the reproduction data is written is a permanent or periodic file.

  RAID is a technology that increases redundancy at the volume level and increases the destruction resistance of the volume. RAID 1 (mirroring) produces the same result as a double write and creates a replica of the volume. This is because the files are mirrored in units of access to the storage (volume) and realized at the driver level or hardware (H / W) level, and the increase in processing required is small compared to double writing, and throughput is reduced. high.

  Here, the cause of the destruction and disappearance of the recorded file in the storage will be described. There are two reasons why a recorded file in the storage is destroyed: physical destruction of the storage and logical destruction caused by destruction of management data necessary for accessing the file. RAID prevents loss of a file due to physical destruction and does not prevent logical destruction. Therefore, the file cannot be permanently guaranteed by itself. This is because the file system performs logical guarantees based on transactions, and RAID has no knowledge of the file system transactions.

  As a resistance against logical destruction, it is common to use a journaling file system (typically EXT3, XFS) and a LogBase file system (typically NILFS) at the file system level. The purpose of recovery of these file systems is to maintain the logical consistency of the file system, and data and files that impair the consistency at the time of recovery are erased. Thus, the file system cannot be guaranteed with durability against logical destruction of the file system.

  The mechanism of logical destruction will be described with XFS, which is a typical journaling file system. The XFS transaction is shown in FIG.

  First, transaction allocation is executed by a write operation (step S901). Here, a transaction structure and a unique transaction identifier are assigned. Subsequently, a log space is secured (step S902). Here, a log space necessary for the transaction is secured on the memory 81. Thereafter, the resource (the resource 82 to be corrected) is locked (step S903). Here, resources (buffers, i-nodes, management areas) are read and locked.

  Subsequently, the resource is corrected (step S904). Here, modification of the resource 82 to be modified and creation of a transaction operation structure (structure used for recording operation contents) are performed. Thereafter, a commit transaction is executed (step S905). Here, the resource modification information and the transaction operation are recorded in the in-core log. The in-core log is a log storage area 83 on the memory 81, and includes a log 831 that has not been written, a log space 832, a log 833 that has been written, and the like.

  Subsequently, the in-core log is written to an HDD (Hard Disk Drive) 84 (step S906). As a result, the disk-on log (log written to the HDD 84) is written to the HDD 84. Thereafter, the corrected resource is flushed (step S907). That is, the corrected resource is written to the HDD 84. The log area is on the ring on both the memory 81 and the HDD 84. An area 841 is an XFS partition on the HDD 84.

  A file and a file system are destroyed from a transaction when a failure occurs during the resource flush process (step S907). Other than that, since it is reflected on the memory 81, even if a failure occurs, the data exists on the storage in a state in which the pre-change consistency is achieved.

  FIG. 3 shows the resources to be changed during the XFS transaction and the reflection order to the storage.

  FIG. 3 shows a state where a file creation transaction (Type: XFS_TRANS_create) is input. Five resources are changed by this transaction. That is, XAGI, IABT, INODE (inode of a file to be created), inode (directory inode), and SB. The corrected resource is locked on the memory 81 until the log is written back.

  The HDD 84 has an HDD write cache 8411, and resources on the memory 81 are written into the HDD write cache 8411. At this time, it is expected that the writing order is changed due to TCQ / NCQ or the like. Also, when writing to the medium 8412 on the HDD 84, it is expected that the writing order will be changed.

  As described above, the reflection order of the resources to the storage is not uniquely determined, and it is not possible to identify which resource has been reflected and which resource has not been reflected.

  FIG. 4 shows the storage position of the resource in the storage and the write request. FIG. 4 shows one allocation group. When XAGF is changed, XFSB without change is also written back. Similarly, even when a data change is made to a part of a block, what is actually flushed is a block unit. When one inode is changed, the other 15 inodes that are not changed are also written back. Similarly, even when a change is made to one inode, what is actually flushed is a block unit.

  Reflecting all resources does not fit in a single request, and multiple requests need to be issued.

  FIG. 5 shows how a request and a command request to the storage are issued when duplication is performed using existing file technology. In FIG. 5, thick arrows indicate system calls.

  FIG. 6 shows a state in which resources when mirroring is performed using RAID 1 are reflected in the storage. Since reflection of resources is performed in parallel with the original / backup, the same inconsistency occurs between the original / backup when a failure occurs during writing.

<< Problems of recording / reproducing apparatus applicable to this embodiment >>
In summary, if you try to persist a file that requires periodic rewriting,
1. Although it is an ordinary means to make a file doubly held, it is difficult to realize duplication of a file with periodic / frequent change from the viewpoint of performance.
2. RAID1 is a technique for performing duplication while maintaining performance to some extent, but from the viewpoint of logical destruction of the file system, it is not possible to guarantee the persistence of a file in the event of a failure occurring during a transaction.

  Currently, no technology has been established to maintain the performance while preventing logical corruption and making the file permanent.

<< Purpose of this embodiment >>
The purpose of this embodiment is as follows.
1. Make a permanent guarantee for files that require frequent updates.
2. Minimize the processing time spent performing permanent guarantees.
3. Minimize data recovery processing time.
4). Mirroring is performed at the transaction level managed by the file system.
5). By adding a transaction tag to the transfer request issued by the file system, it is determined which transaction belongs to which transaction.
6). By giving status to the request issued by the file system, it is possible to manage the status before transfer / waiting for transfer end / transfer completion / mirror transfer end wait / mirror transfer completion.
7). Since all file system management data is subject to duplication at the transaction level, there is no theoretical logical destruction of the file system.

<< Recording / reproducing apparatus according to this embodiment >>
A basic concept of the recording / reproducing apparatus according to the present embodiment is shown in FIG. In this case, the unit / timing for mirroring is matched with the file system transaction.

  When a failure occurs at the time shown in FIG. 6, the resources before and after the change are reflected are mixed and inconsistency occurs. If it is attempted to repair a state in which inconsistency occurs, it is necessary to check which resource has inconsistency, and it cannot be repaired instantaneously. In addition, the file may be destroyed during the repair.

  In contrast, in FIG. 7, even if a failure occurs at the time shown in FIG. 7, the resources in the backup volume 69 are consistent in the state before the change. Thus, when a failure occurs, the information in the original volume 68 is restored with the information in the backup volume 69, so that the state before the change can be instantaneously restored.

  FIG. 8 shows a functional configuration diagram of the recording / reproducing apparatus according to the present embodiment. Each queue in the recording / reproducing apparatus is configured by a memory or the like. In addition, each of the other components may be configured by dedicated hardware, or may be configured by a CPU (Central Processing Unit). In the case of being configured by a CPU, functions provided by each configuration are realized by executing software by the CPU.

  A program for recording data in the storage (original volume 181 and backup volume 182) creates a file using a system call (system call unit 120).

  The system call calls a file create operation function of the file system.

  The file system (file system unit 130) performs file create operation processing (a series of processing of this file create operation is defined as a file create transaction). In this process, a resource necessary for creating a file is changed, a request is generated, and a request for replication (mirror) is registered in the mirror request queue 141. When all necessary resource change requests are registered, a mirroring request flag is set for the mirror request queue 141. One or a plurality of mirror request queues 141 are prepared.

  The file system unit 130 receives a transaction input from the system call unit 120, generates one or more requests necessary for transaction processing, and registers the generated one or more requests in the mirror request queue 141. When registration is completed, the file system unit 130 sets a predetermined value for a mirroring request flag stored in a memory (not shown) in the recording / reproducing apparatus. The predetermined value is a value indicating a request for copying data, and is not particularly limited.

  The transaction mirroring driver unit 140 has a mirror request queue 141 and registers one or a plurality of requests registered in the mirror request queue 141 in the original volume write request queue (request queue 151). The transaction mirroring driver unit 140 refers to the mirroring request flag when the processing for one or more registered requests is completed. When a predetermined value is set in the mirroring request flag, one or more requests registered in the mirror request queue 141 are registered in the backup volume write request queue (request queue 161).

  The request control unit 142 registers the request registered in the mirror request queue 141 in the request queue 151 included in the original volume interface driver unit 150. The request control unit 142 waits while monitoring that all mirror requests registered in the mirror request queue 141 are completed. When all mirror requests are completed and a predetermined value is set in the mirroring request flag (stored in a memory (not shown) of the recording / reproducing apparatus) for the mirror request queue 141, the request is transferred to the backup volume interface driver. Registered in the request queue 161 of the unit 160. The request control unit 142 again waits while monitoring that all mirror requests are completed and completed. When the processing is completed, return is returned to the file creation operation. At this time, the file system unit 130 clears a predetermined value set in the mirroring request flag.

  The original volume interface driver unit 150 has an original volume write request queue (request queue 151), and outputs a request fetched from the request queue 151.

  The backup volume interface driver unit 160 has a backup volume write request queue (request queue 161), and outputs a request fetched from the request queue 161.

  The storage control unit 170A controls the process of writing the original data included in the request output from the original volume interface driver unit 150 into the original volume 181. In addition, the storage control unit 170A controls a process of writing backup data included in the request output from the backup volume interface driver unit 160 to the backup volume.

  FIG. 9 shows an implementation when both the mirror request queue and the normal request queue are controlled within the storage interface driver unit.

  FIG. 10 shows an implementation in the case of queuing commands with H / W (IF controller / storage controller).

<< Flow of processing executed by recording / reproducing apparatus according to this embodiment >>
The flow of processing executed by the recording / reproducing apparatus according to the present embodiment is shown in FIGS.

  FIG. 11 shows a process for writing a file that requires persistence. FIG. 12 shows a file write process that does not require persistence. FIG. 13 shows a case where the writing of the file that requires persistence shown in FIG. 12 is further improved with respect to the destruction of the storage by using the RAID controller.

  11, 12, and 13, when writing a file, FS (File System) management data 1321 (solid arrow in each figure), file management data 1322 (broken arrow in each figure) and the contents of the file It is necessary to write out the data (thick arrow in each figure).

  In FIG. 11, when a new file is created, a file name and file attribute information are added by a file create system call. The distinction between persistent files and regular files is given as this attribute information.

  The file system unit 130 determines a transaction based on the attribute information and the type of the system call, and if the resource management unit 132 needs to be changed during the transaction, the file system unit 130 writes the resource. The resources in this example correspond to the FS management data 1321 and the file management data 1322.

  The file system unit 130 creates a resource write request based on the attribute information of the permanent file. At this time, it is assumed that a transaction tag for determining which transaction is requested as data in the request.

  It is assumed that the request is connected to the mirror request queue 141 of the transaction mirroring driver unit 140 by the file system unit 130. In FIG. 11, a solid line arrow and a broken line arrow indicate the writing of FS management data 1321 and file management data 1322, respectively.

  The transaction mirroring driver unit 140 connects a request connected to the mirror request queue 141 to the request queue 151 of the original volume interface driver unit 150 at an arbitrary timing. The request control unit 142 of the transaction mirroring driver unit 140 waits for the transfer from the original volume interface driver unit 150 to end. Further, the transaction mirroring driver unit 140 manages the status of the request, that is, before transfer / waiting for transfer completion / transfer completion / waiting for mirror transfer completion / mirror transfer completion.

  The file system unit 130 notifies the mirroring execution event to the transaction mirroring driver unit 140 when all requests to be issued during the transaction are connected to the mirror request queue 141. A transaction tag is notified as event information at this time.

  The transaction mirroring driver unit 140 waits until the status of all requests with the same tag information as the transaction tag included in the mirroring execution event has been transferred, and when all requests have been transferred, the backup volume The request is connected to the request queue 161 of the interface driver unit 160. The transaction mirroring driver unit 140 again waits for all requests to complete the mirror transfer, and notifies the file system unit 130 of the completion of transfer when all the transfers are completed. The file system unit 130 sets the end of transfer as the return of the system call.

  A file writing process that does not require perpetuation will be described with reference to FIG. Even in the case of a normal file, the FS management data 1321 and the file management data 1322 are to be mirrored. When storing files on the same FS, since the same data is handled in both the permanent file and the normal file, the FS management data 1321 may be destroyed if the mirroring is not performed just because the FS management data 1321 is a normal file. Therefore, the FS management data 1321 and the file management data 1322 are mirrored as in the case of the permanent file. Do not mirror data only.

  The recording / reproducing apparatus further includes a data block 183 as a write destination of data (normal file) that is the contents of the file.

  The recording / reproducing apparatus further includes a data block interface driver unit 166. The data block interface driver unit 166 has a data queue write request queue (request queue 167), and outputs a request fetched from the request queue 167.

  The file system unit 130 registers data (normal file) that is the contents of the file in the request queue 167.

  The storage control unit 170A further controls processing for writing data included in the request output from the data block interface driver unit 166 into the data block 183.

  Referring to FIG. 13, description will be given of a case where the writing of a file requiring persistence shown in FIG. 12 is further improved with respect to storage destruction using a RAID controller. As shown in FIG. 13, there is a storage control unit + RAID control unit 170C on the hardware side. By the RAID control function, the same data is written in each of the two storages. This protects the data from physical destruction to the storage. Therefore, when the file system is destroyed, data can be recovered not only when the file disappears but also when the hard disk is physically destroyed.

<< Effects of this embodiment >>
According to this embodiment, there are the following effects.

1. Fast recovery when a failure occurs.
2. It can exist permanently without destroying the file when repairing the file system.
3. Better performance than writing a file twice.
4). The middleware does not need to be made aware of the mirror by simply calling a normal system call.
5). A RAID 1 mirror cannot guarantee file system consistency, but this embodiment can guarantee consistency.
6). Mounting is possible with both S / W and H / W.
7). The middleware can make a mirror unintentionally, but the middleware can handle whether the data and resources that need a mirror are unnecessary. It is possible to make it.

<< Variation of this embodiment >>
In the above, preferred embodiments of the present invention have been described with reference to the accompanying drawings. However, it goes without saying that the present invention is not limited to such examples. It will be apparent to those skilled in the art that various changes and modifications can be made within the scope of the claims, and these are naturally within the technical scope of the present invention. Understood.

It is a conceptual diagram of the recording / reproducing apparatus applicable to this embodiment. It is a figure shown about the transaction of XFS. It is a figure which shows a mode when the transaction of file creation is input. It is a figure which shows one allocation group. It is a figure which shows the mode of issuing the request in the case of duplicating with the existing technique of a file, and the command request to a storage. It is a figure which shows a mode that the resource at the time of mirroring using RAID1 is reflected in the storage. 1 is a basic conceptual diagram of a recording / reproducing apparatus according to an embodiment. It is a figure which shows the function block diagram of the recording / reproducing apparatus which concerns on this embodiment. It is a figure which shows the implementation form in the case of controlling both a mirror request queue and a normal request queue within a storage interface driver part. It is a figure which shows the mounting form in the case of queuing a command by H / W (IF controller / storage controller). It is a figure shown about the write-in process of the file which needs perpetuation. It is a figure which shows about the write-in process of the file which does not require perpetuation. It is a figure which shows about the case where the tolerance with respect to destruction of a storage is further improved using the RAID controller about writing of the file which needs perpetuity.

Explanation of symbols

68 Original volume 69 Backup volume 81 Memory 82 Resource 83 Log storage area 84 HDD
DESCRIPTION OF SYMBOLS 120 System call part 130 File system part 132 Resource management part 140 Transaction mirroring driver part 141 Mirror request queue 142 Request control part 150 Original volume interface driver part 151 Request queue 160 Backup volume interface driver part 161 Request queue 170C RAID control part 181 Original volume 182 Backup volume 1321 FS management data 1322 File management data 8411 HDD write cache 8412 Media

Claims (5)

Accepts transaction input from the system call part, generates one or more requests necessary for the transaction processing, registers the generated one or more requests in the mirror request queue, and stores them in the memory after registration A file system unit for setting a predetermined value in the mirroring request flag,
When the mirror request queue is registered, one or more requests registered in the mirror request queue are registered in the original volume write request queue, and the processing for the registered one or more requests is completed, the mirroring is completed. Transaction mirroring that refers to the request flag and registers one or more requests registered in the mirror request queue in the backup volume write request queue when the predetermined value is set in the mirroring request flag A driver section;
An original volume interface driver unit that has the original volume write request queue and outputs a request taken out of the request queue;
A backup volume interface driver unit that has the backup volume write request queue and outputs a request taken out of the request queue;
Controls processing for writing original data included in the request output from the original volume interface driver unit to the original volume and processing for writing backup data included in the request output from the backup volume interface driver unit to the backup volume. A storage controller;
A recording / reproducing apparatus. The file system unit is
When all the processing for one or more requests registered in the backup volume write request queue is completed, a predetermined value set in the mirroring request flag is cleared.
The recording / reproducing apparatus according to claim 1. The file system unit is
A tag for determining a transaction is given to the request.
The recording / reproducing apparatus according to claim 2. A data block interface driver unit that has a data queue write request queue and outputs a request fetched from the request queue.
The file system unit is
Register the data that is the contents of the file in the data block write request queue,
The storage control unit
Further controlling the process of writing the data included in the request output from the data block interface driver unit to the data block to which the data that is the contents of the file is written;
The recording / reproducing apparatus according to claim 3. When the file system unit receives an input of a transaction from the system call unit, generates one or more requests necessary for processing the transaction, registers the generated one or more requests in the mirror request queue, and finishes registration Setting a predetermined value in the mirroring request flag stored in the memory;
The transaction mirroring driver unit has the mirror request queue, registers one or more requests registered in the mirror request queue in the original volume write request queue, and performs processing for the registered one or more requests. When all are completed, the mirroring request flag is referred to, and when the predetermined value is set in the mirroring request flag, one or more requests registered in the mirror request queue are requested as backup volume write requests. A step to queue,
An original volume interface driver unit having the original volume write request queue and outputting a request fetched from the request queue;
A backup volume interface driver unit having the request queue for writing the backup volume, and outputting a request fetched from the request queue;
The storage control unit writes the original data included in the request output from the original volume interface driver unit to the original volume, and writes the backup data included in the request output from the backup volume interface driver unit to the backup volume. Controlling the processing;
Including a recording / reproducing method.

Images