KR101888781B1 - Persistent dynamic random access memory storage using non-volatile ram and operating method therefof - Google Patents

Abstract

Hybrid block based persistent DRAM storage using nonvolatile memory and DRAM and method of operation are disclosed. In a computing device having a non-volatile memory, a third storage device having a lower input / output performance than a DRAM and a DRAM, a log manager managed by a kernel of the DRAM storage is changed in the DRAM according to an input / output request for block data Storing the log for the block in the nonvolatile memory, and backing up the block data corresponding to the log to the third storage device via an arbitrary thread, in addition to the data processing for the input / output request.

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention [0001] The present invention relates to a non-volatile memory, and more particularly,

Embodiments of the present invention relate to persistent dynamic random access memory (" DRAM ") storage, and more particularly, to hybrid block based persistent DRAM storage using non-volatile memory and DRAM and methods of operation thereof.

Linux RAM disks based on conventional dynamic random access memory (DRAM) provide high-speed I / O performance, but all data is lost when a system failure occurs. In some cases, a method for stably maintaining data in a system failure by combining a DRAM and a hard disk has been proposed, but the input / output performance is considerably lower than that of the RAM disk.

Due to the volatility of DRAM, nonvolatile memory has been actively developed to prevent data loss caused by power failure. Typical examples are the next-generation memory technologies, such as PCM (Phase Change Memory), STT-MRAM (Non-Volatile Spin-Transfer Torque RAM), and RRAM (Resistive RAM).

On the other hand, there is a technology for maintaining data by supplying power to a conventional DRAM using a battery such as a non-volatile dual in-line memory module (NVDIMM). In particular, NVDIMM (hereinafter referred to as NVRAM) was established as a standard by JEDEC JC-45.

In addition, existing DRAM block storage also adopts an approach of combining hard disks to solve the data loss problem caused by the volatility of the DRAM. However, this approach has a disadvantage in that the input / output performance becomes closer to the hard disk according to the degree of change operation since the modified data is backed up to the hard disk in real time in the DRAM.

As described above, in the DRAM block storage field, there is a need to improve the input / output performance of the hard disk in order to solve the data loss problem.

In order to solve the above problems, it is an object of the present invention to provide a high-speed reliable hybrid block-based DRAM storage that combines a non-volatile memory (NVRAM), a dynamic random access memory (DRAM)

It is another object of the present invention to provide a DRAM storage capable of stably storing data while matching the input / output performance of a DRAM by combining a DRAM, an NVRAM and a hard disk.

According to an aspect of the present invention, there is provided a method of storing data in a DRAM in a hybrid block storage of non-volatile random access memory (NVRAM) and dynamic random access memory (DRAM) DRAM storage is provided. The DRAM storage may be referred to as a hybrid block storage including a hard disk drive (HDD).

In one embodiment, since there is a limitation on the capacity of the NVRAM, only the changed area of the block to which the DRAM is changed in order to use the space effectively can be stored.

In one embodiment, the mapping between logical block storage space and physical space (NVRAM, DRAM, hard disk) can be utilized.

According to another aspect of the present invention, there is provided a computer system having a DRAM storage including a nonvolatile memory, a dynamic random access memory (DRAM), and a third storage device having a lower input / output capability than the DRAM, CLAIMS 1. A method of operating a DRAM storage, comprising: storing in a non-volatile memory a log of a block that is changed in a DRAM by a log manager (non-volatile memory log manager) managed by a kernel of the DRAM storage in response to an input / output request for block data; And backing up the block data corresponding to the log to the third storage device via an arbitrary thread separately from the data processing for the input / output request.

According to still another aspect of the present invention, there is provided a method of operating a computing device having a DRAM storage including a nonvolatile memory, a dynamic random access memory (DRAM), and a third storage device having a lower input / output capability than the DRAM Wherein the third storage device is configured to process the input / output request in accordance with a record of how many blocks of the third storage device are loaded with data when an input / output request for block data is requested, ; Storing a log of blocks changed in the DRAM in the nonvolatile memory; And backing up a block corresponding to the log from the non-volatile memory to the third storage device.

In one embodiment, the storing step may store, in the NVRAM, only a log of the changed area of the block to which the DRAM is changed.

In one embodiment, a method of operating a DRAM storage further comprises, prior to the storing, mapping a mapping between physical spaces, including the non-volatile memory, the DRAM, and the third storage, And recording the log in the log.

In one embodiment, the storing step may divide the log into a plurality of logs according to a storage unit of the third storage device, and store the log in the NVRAM.

In one embodiment, the input / output request may originate from the application program when an application running on the computing device loads data into the DRAM, which is main memory.

In one embodiment, the input / output request may be transferred to the device driver of the hybrid block storage of the kernel through a virtual file system (VFS) connected to the application program.

In one embodiment, the device driver (block device driver) secures a part of the DRAM and uses the DRAM as a DRAM storage, and converts the input / output request into memory read / write on a DRAM as a main memory.

In one embodiment, the device driver writes a changed block in a corresponding area on the DRAM to an input request, writes the changed block to the NVRAM, and then terminates. The change recorded in the NVRAM is sequentially May be recorded in the corresponding block of the third storage device.

In one embodiment, the method of operating the DRAM storage further comprises, after the step of backing up, loading the block of the third storage device into the DRAM when the computing device is restarted, The blocks being processed in the DRAM and the blocks of the third storage device not yet loaded may be processed in the third storage device.

In one embodiment, the method of operating a DRAM storage further comprises: after the processing, input / output in the DRAM, input / output in the third storage device, loading from the third storage device to the DRAM in the kernel of the computing device, Mapping the space of the logical block storage and the physical space of the DRAM to the DRAM to perform the operation consistently.

In one embodiment, a mapping table that maps the block ID corresponding to the space of the logical block storage and the physical location of the physical space is no longer retained when all data of the third storage device is loaded into the DRAM Or deleted.

In one embodiment, the third storage device may comprise a hard disk.

In accordance with another aspect of the present invention, there is provided a computer program product comprising: a block device driver managed by a kernel of a computing device; A non-volatile memory log manager managed by the kernel; And a mapping table managed by the block device driver and the log manager, the block device driver including a dynamic random access memory (DRAM), a nonvolatile memory, and a block for a third storage device having a lower input / Wherein the nonvolatile memory log manager manages the input / output of the block data according to an input / output request of data, and the nonvolatile memory log manager stores a log of blocks changed in the DRAM in the nonvolatile memory according to the input / output request, And the driver backs up the block data corresponding to the log to the third storage device separately from the data processing for the input / output request.

In one embodiment, the mapping table may map the block ID corresponding to the space of the logical block storage and the physical location of the physical space.

According to still another aspect of the present invention, there is provided a method for controlling a boot device, the method comprising: a block device driver controlled by a virtual file system (VFS) of a kernel of a computing device; A non-volatile random access memory (NVRAM) log manager and a load manager connected to the block device driver; And a third storage device having a dynamic random access memory (DRAM), a nonvolatile memory (NVRAM), and a third input / output capability lower than the DRAM, which are driven by the block device driver. Here, the I / O requests of the user level application may be converted into a block IO request through the VFS and transferred to the block device driver. If the block IO is a write operation, the block IO can be converted to a log record by the NVRAM log manager and stored in the NVRAM. When the log record of the block IO is stored in the NVRAM, the NVRAM log manager can reflect the block IO in the DRAM and notify the completion of the processing of the block IO in the VFS. The VFS can notify the application that requested the block IO that the processing of the block IO is completed. The synchronization manager connected between the NVRAM and the third storage device reads the log record recorded in the NVRAM by the NVRAM log manager and converts the read log record into a block IO for writing to the third storage device. The converted Block IO can be written to the third storage device at the same position as the block position recorded in the DRAM.

In one embodiment, the load manager loads the blocks of the third storage device sequentially into the DRAM at the restart of the computing device or system, and manages whether each block is in the third storage device or loaded into the DRAM during loading , It is determined whether the corresponding block is in the third storage device or in the DRAM for the Block IO transmitted from the VFS, and the Block IO can be transmitted to the corresponding medium.

In one embodiment, the load manager can use a mapping table to manage the actual location of each block.

In one embodiment, the load manager may record only the number (and / or location) of the most recently loaded block into the DRAM in the third storage device to manage the actual location of each block.

In one embodiment, the third storage device includes one or a plurality of hard disks, and the external size of one hard disk may correspond to the external size of one DRAM.

According to the embodiments of the present invention as described above, it is possible to provide high-speed and high-reliability DRAM block storage capable of stably storing data while being close to the input / output performance of the DRAM.

In addition, it is possible to provide a block storage input / output function / service quickly in case of a restart due to a system failure or a normal restart.

1 is a block diagram of dynamic random access memory (DRAM) storage in accordance with one embodiment of the present invention.
2 is a diagram illustrating a structure of a mapping table that can be employed in the DRAM storage of FIG.
3 is a block diagram illustrating the operation principle of the log manager and the synchronization manager employed in the DRAM storage of FIG.
FIGS. 4 to 7 are views for explaining the operation principle of the DRAM storage of FIG.
8 is a view for explaining the operation principle of the DRAM storage according to another embodiment of the present invention.
9 is a view for explaining an embodiment of a DRAM storage according to another embodiment of the present invention.
10 is a view for explaining another embodiment of persistent DRAM storage according to another embodiment of the present invention.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It is to be understood, however, that the invention is not to be limited to the specific embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention. Like reference numerals are used for like elements in describing each drawing.

The terms first, second, A, B, etc. may be used to describe various elements, but the elements should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component. And / or < / RTI > includes any combination of a plurality of related listed items or any of a plurality of related listed items.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise. In this specification, terms related to "comprising "," having ", and the like are intended to specify the presence of stated features, integers, steps, operations, elements, parts, or combinations thereof, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

Moving data stored in a disk to a memory during a block I / O operation in this specification is referred to as read, and transferring data stored in a memory to a disk may be referred to as write.

Unless otherwise defined herein, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in commonly used dictionaries should be interpreted in a manner consistent with the contextual meaning of the related art, and are not to be construed as ideal or overly formal, unless explicitly defined herein.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram illustrating a computing device including dynamic random access memory (DRAM) storage in accordance with one embodiment of the present invention.

Referring to FIG. 1, a computing device according to the present embodiment may include a processor and a memory. The processor can execute a program stored in the memory to perform a series of procedures. A set of procedures can be divided into a user area (10) and a kernel area (20).

The processor may comprise at least one central processing unit and the central processing unit (CPU) may be a system on chip (SOC) in which a micro control unit (MCU) and peripheral devices (integrated circuits for external expansion devices) But is not limited thereto. The core includes a register for storing an instruction to be processed, an arithmetic logical unit (ALU) for performing comparison, determination, and operation, a controller for internally controlling the CPU for interpreting and executing the instruction, a control unit, and an internal bus for connecting them.

A processor may also include, but is not limited to, one or more data processors, image processors, or CODECs. The processor may have a peripheral interface and a memory interface. The peripheral interface connects the processor with the input / output system and several other peripherals, and the memory interface can couple the processor to the memory.

Further, the processor can execute data processing by executing various software programs. The processor may execute a specific software module (instruction set) stored in the memory to perform a specific function corresponding to the module. That is, the processor may provide data input / output services at the computing device by software modules stored in memory.

In this embodiment, the memory may include persistent DRAM storage (hereinafter simply referred to as " DRAM storage "). The DRAM storage includes a DRAM, a non-volatile random access memory (NVRAM), and a hard disk drive (HDD) . The memory may further include at least one selected from an optical storage device, a flash memory, and the like. Such memories may store software, an operating system, a program, a set of instructions or a combination thereof, and may store schedule operating policies or program codes.

The components of the software may include an operating system module, a graphics module, a user interface module, a moving picture experts group (MPEG) module, a communication module, a camera module, an application module, and the like. A module is a set of instructions that can be represented as an instruction set or program.

The operating system can include embedded operating systems such as MS WINDOWS, LINUX, Darwin, RTXC, UNIX, OS X, iOS, MacOS, VxWorks, Google OS, Android, Sea (Samsung OS) have. The operating system may also have a function of performing communication between various hardware (devices) and software components (modules).

A nonvolatile memory (NVRAM) 40 used in the DRAM storage of the present embodiment can use a backup battery to maintain power, thereby preventing unexpected power loss, a system crash, or a normal system shutdown The data of the NVRAM 40 can be retained even when the power is cut off from the NVRAM 40. [ At least one of the NVDIMM-N, NVDIMM-F, and NVDIMM-P may be used as the non-volatile memory. According to this configuration, the hybrid block based persistent DRAM storage according to the present embodiment uses the NVRAM 40 as log devices to store all of the data in the HDD (hard disk drive) 50 when the computer system or the processor is rebooted The blocks may be accessed before being loaded into the DRAM. DRAM 30 may be referred to as DRAM storage in a narrow sense.

The aforementioned user area 10 may be referred to as a user mode or a user mode operating system and the kernel area 20 may be referred to as a kernel mode or kernel mode operating system.

Kernel mode 20 is a program mode that is privileged to the kernel and can refer to all system memory and process execution modes that are allowed access to all CPU instructions. That is, the processor can be designed so that a user application or the like which causes a malfunction by giving a higher authority to the kernel mode 20 than the user mode 10 does not hurt the system stability. On the other hand, the user mode 10 is usually set to a lower privilege than the kernel mode 20, and the malfunction of the application may impair the stability of the computing system.

The user mode 10 and the kernel mode 20 may have different ranges of accessible virtual memory. Each process has its own separate memory space, but the kernel mode operating system and device driver code can share a single virtual address space. Each page in the virtual memory may indicate what mode of access the processor should have to read and write pages, and pages of system space may only be accessible in kernel mode (20).

The application 60 (hereinafter referred to as a user application) can be switched from the user mode 10 to the kernel mode 20 when calling the system service. For example, the Windows ReadFile function requires a call to an internal window routine to handle the ability to actually read data from a file. This routine must be executed in kernel mode 20 because it accesses the system data structure and the conversion from user mode 10 to kernel mode 20 is to use special processor instructions to cause the processor to switch to kernel mode 20 Can be implemented.

In the computing device according to the present embodiment, the operating system includes a PBestIO Block Device Driver (hereinafter, simply referred to as a block device driver) for the persistent best input / output through a virtual file system (VFS) 62 in the user application 60 The device driver 22 can operate, manage, or control DRAM storage. The DRAM storage includes a DRAM 30, a NVRAM 40 and an HDD 50 in a broad sense, and in a broader sense, a nonvolatile memory log manager (hereinafter abbreviated as NVRAM Log Manager 24) A Load Manager 25, and a Sync Manager 27. The load manager 25 may include a load manager 25 and a synchronization manager 27. [

The operating system recognizes that the system service is requested through the above instruction and can execute an internal function after verifying the argument passed to the system function by the thread. The processor can be switched back to user mode before returning control back to the user thread. In this way, the operating system itself and data can be protected from being viewed or altered by user processes. In this way, after receiving the authority to access the kernel mode 20 in the user mode 10, the user can use the system resources and return to the user mode 10 thereafter. In that case, the right to return to the user mode 10 can be implemented by a function called a system service call.

The user mode 10 may include a command line interface (CLI), a shared library, and an input / output control interface (IOCTL interface), depending on the implementation. A command interface can be referred to as a command line interface, and refers to the way a user interacts with a computer through a text terminal. That is, a work instruction can be input by a user in the form of a string through a computer keyboard or the like, and the output from a computer can also be given in a string form. A shared library is a type of library that can exist in object code form, which is a precompiled form that can be linked together as one or more subroutines or a collection of functions that exist to link with other programs. When compiling with a shared library, the linker can mark the executable file as "load this library first when it is executed". This approach results in a smaller file size than the static library, and since the kernel shares one copy of the shared memory with multiple programs, it takes up less memory and is deleted from memory after use It is efficient for memory use. And the I / O control interface may be part of the interface between the computer user of the underlying operating system and the kernel. The input / output control interface is operable to allow code in the user space to communicate with a hardware device, a kernel component. The basic operating system can be divided into two layers: a user area 10 and a kernel area 20.

In the user area 10, operations such as storage creation and deletion, and monitoring operations such as performance and failure can be performed. In the kernel area 20, a virtual block device driver (corresponding to a block device driver connected to the VFS) is executed, log management is performed on the NVRAM 40, or an initial It is possible to allow the connection between the DRAM 30 and the HDD 50 during data loading.

The kernel area 20 includes a VFS 62, a block device driver 22, a log manager 24, a load manager 25, a synchronization manager 27, a DRAM 30, an NVRAM 40, . ≪ / RTI >

Referring back to FIG. 1, the overall structure of the block's persistent best input / output (PBestIO) will be described as follows. PBestIO can act as a block device driver for the Linux system kernel and can refer to this driver. 1, the PBestIO block device driver 22 is the PBestIO block device driver.

The I / O requests of the user level application or application programs 60 are converted into Block IO requests through the kernel level VFS 62 and transferred to the PBestIO block device driver 22. When the Block IO transferred to the PBestIO block device driver 22 is a write operation, it is converted into a log record by the NVRAM Log Manager 24 and stored in the NVRAM 40.

Next, when the log record of the corresponding block IO is stored in the NVRAM 40, the block IO is reflected to the DRAM storage 30, and the VFS 62 is notified that the processing of the block IO is completed. The VFS 62 informs the application 60 requesting the block IO that the processing of the block IO is completed. The synchronization manager 27 reads the log record recorded in the NVRAM log manager 24 and converts it into a block IO to be written to the HDD 50. The converted Block IO is written to the hard disk 50 at the same position as the block position recorded in the DRAM storage 30. [

The Load Manager (25) can be run at system restart. The loading manager 25 can sequentially load the blocks of the HDD 50 into the DRAM 30 when the system is restarted. It is possible to manage whether each block is loaded in the HDD 50 or in the DRAM 30 while being loaded. In addition, the stack manager 25 can determine whether the block is in the HDD 50 or not in the block IO transmitted from the VFS 62, and transmit the Block IO to the corresponding medium to process the block IO. The loading manager 25 may take a mapping table method and / or a method of recording only the number of the last loaded block in order to manage the actual position of each block.

The stack manager 25 uses both the hard disk 50 and the DRAM 30 while the PBestIO 22 loads all the data stored in the hard disk 50 into the DRAM 30 when the system is restarted, Lt; / RTI > When the system is restarted, the block mounted on the DRAM 30 is processed in the DRAM 30 in accordance with the input / output request of the VFS 62 while the block of the hard disk 50 is loaded into the DRAM 30, May be processed in the form of processing in the hard disk 50. At this time, in order for the input / output in the DRAM 30, the input / output in the hard disk 50, and the loading operation in the DRAM 30 to be performed simultaneously from the hard disk 50, A mapping table for mapping the space of the hard disk 50 and the DRAM 30 can be maintained.

FIG. 2 shows a structure of a mapping table that can be employed in the DRAM storage of FIG.

As shown in FIG. 2, a mapping table 26 according to the present embodiment maps a logical block ID (logical block ID) and a physical location of a logical block storage.

On the other hand, in FIG. 2, only the mapping table 26 manages both the blocks of the DRAM (M) and the hard disk (H) for each block ID. The mapping table is no longer retained when all the data on the hard disk is loaded into the DRAM. The problem with this configuration (existing configuration) is that when the size of the storage is very large and the size of the block is small, the size of the mapping table becomes very large, which increases the management cost.

Accordingly, in this embodiment, as a new method, it is recorded how many blocks of the hard disk are loaded through one variable, and a method of determining whether to process the IO request (IO request) in the hard disk or DRAM is used. In this case, the write operation for a block that has not yet been loaded may be processed in the DRAM but it may not be processed. However, since this phenomenon occurs only during the load, the overall performance is not greatly affected, There is an advantage that the performance can be improved while solving the problems of the existing configuration.

3 is a block diagram for explaining the operation principle of a log manager and a synchronization manager that can be employed in a DRAM storage according to another embodiment of the present invention.

3, both the log manager (NVRAM Log Manager) 24 and the synchronization manager (Sync Manager) 27 operate as a separate thread and can be switched to a sleep mode immediately after a thread is created have. The PBestIO block device driver can receive Block IO from the VFS and wake up the log manager thread accordingly.

The log manager 24 can input the transmitted Block IO to the log generator 242 to generate a log. The generated log record is transferred to a log writer 244 and the log writer 244 can write log records to the NVRAM 40 through the NVRAM IO Manager 246. [ The log manager 24 may log the NVRAM 40 and then wake up the synchronization manager 27. [

The synchronization manager 27 can be switched from the sleep mode to the active mode by the log manager 24. [ The synchronization manager 27 first checks whether there is a log to be read and processed by the NVRAM log manager 24, and if there is a log to be processed, the synchronization manager 27 sequentially reads the log to be processed and stores it in the hard disk 50 through a log parser 272 Block IO format. The converted Block IO can be recorded in the hard disk 50 by a block writer (Block Writer) If there is a log to be processed in the NVRAM log device, the synchronization manager 27 repeats the above process, and if not, the synchronization manager 27 can switch to the sleep mode again.

FIGS. 4 to 7 are views for explaining the operation principle of the DRAM storage according to another embodiment of the present invention.

Referring to FIG. 4, an NVRAM log manager (hereinafter simply referred to as a log manager) according to the present embodiment records log records of blocks changed in the DRAM when an input / output request (IO Request) Can be stored in the HDD 50 in block units.

As shown in the one-dot chain line E1, the operation of the DRAM storage 22 according to the control by the log manager is performed by inputting and outputting an I / O request (IO Request ), The log manager can first recognize or check the arguments of the bio structure contained in the function (e.g., submit_bio ()) which is the starting point of the block I / O.

The function may take a bio structure including a type of an I / O operation (for example, read or wirte) and a bio structure including all information about the operation. The bio structure can basically contain information of a disk area to perform I / O and information of a memory area to store data to perform I / O.

 Next, the log manager may store log records in the NVRAM 40 including information on blocks (for example, block1, block2) that are changed in the DRAM 30. At this time, the log records corresponding to data stored in different storage areas of the DRAM 30 can be sequentially recorded in a predetermined area of the memory for recording log records. The memory for recording log records may be some storage space in the DRAM 30, but is not limited thereto.

Next, referring to FIG. 5, the log manager according to the present embodiment can acquire a log record for a block (block 4) to be changed in the DRAM 30 when there is an input / output request. The log record can be recorded together with the previous log records (block1 and block2) as indicated in the one-dot chain line E2. The log record may be stored in a predetermined area in the DRAM 30, and may be initialized according to a predetermined event on the system, the size of the log record, or the like while accumulating the log record. The log record may be stored in the NVRAM 40 in the form of a cumulative log record containing the current log record. The log recording is divided into a plurality of log records (for example, two block 4) corresponding to a predetermined size unit according to a storage unit (for example, a sector) of the HDD 50, a data processing capacity unit, Lt; / RTI >

Next, referring to FIG. 6, the log manager according to the present embodiment uses the information of the mapping table corresponding to the log record stored in the NVRAM 40, as indicated by the one-dot chain line E3, to the DRAM 30 Stored blocks of data may be stored in the HDD 50. [ The data blocks corresponding to the log records stored in the NVRAM 40 may be mapped by the mapping table so as to correspond to different storage areas of the HDD 50. [

Referring to FIG. 7, the load manager according to the present embodiment stores the information in the mapping table stored in the DRAM 30 using the information of the mapping table corresponding to the log record stored in the NVRAM 40, as shown in the one-dot chain line E4. Data blocks corresponding to a plurality of log records stored in the NVRAM 40 may be stored in the same storage area of the HDD 50 in succession when blocks of data are stored in the HDD 50. [

As described above, the load manager writes a block in the DRAM 30 in a first block when a block-level write request is input to the DRAM storage 22, and logs only the changed contents in the written block (log record) The asynchronously operating thread can continuously read the log of the NVRAM 40 and write the block to the HDD 50. [

According to the present embodiment, it is possible to provide a persistent DRAM storage that processes a write request without writing to a hard disk when a write request is received using a nonvolatile memory as a log device.

8 is a block diagram illustrating the operation principle of a DRAM storage according to another embodiment of the present invention.

The logical structure of the nonvolatile memory 40 (NVDIMM or NVRAM) and the hybrid storage (corresponding to the DRAM storage) of the DRAM 30 according to the present embodiment is as shown in FIG.

8, when an application program 60 of the computing apparatus according to the present embodiment loads data into the DRAM 30 as a main memory, an input / output request from the application program 60 is input to a virtual file system virtual file system 62 to the hybrid block storage device driver 22 of the kernel. The hybrid block storage device driver 22 may be referred to as a memory disk block device driver (hereinafter, simply referred to as a " block device driver ").

The block device driver 22 can secure a partial area of the DRAM 30 and use it as block storage. The block input / output request by the block device driver 22 can be converted and read into a memory read / write on the DRAM 30 as a main memory.

When the block device driver 22 converts the output request into the read operation in the DRAM 30 and processes it, the block device driver 22 immediately ends the process. However, the block device driver 22 writes the changed block in the corresponding area on the DRAM 30, Information or log record) in the NVRAM 40 and then terminate the process. The change recorded in the NVRAM 40 is recorded in the corresponding block of the hard disk 50 again. That is, although the output request to the block storage driver 22 is processed by the read operation of the DRAM 30, the input request can be processed by the write operation of the DRAM 30 and the write operation of the NVDIMM. In the case of the input operation, the conventional DRAM block storage is processed by the write operation to the DRAM and the input operation to the hard disk, so that the input performance of the hybrid block storage according to the present embodiment is much better.

In the computing apparatus according to the present embodiment, the hybrid block storage uses both the hard disk 50 and the DRAM 30 while loading all the data stored in the hard disk 50 into the DRAM 30 when the system is restarted I / O can be processed.

When a system (computing device) is restarted in the present embodiment, when a block of the hard disk 50 is loaded into the DRAM 30 and an input / output request is transmitted from the VFS 62, the block loaded in the DRAM 30 is transferred to the DRAM 30, And blocks not yet loaded may be processed in the form of processing in the hard disk 50. [ At this time, in order to consistently perform input / output in the DRAM 30, input / output in the hard disk 50, and loading operation in the DRAM 30 from the hard disk 50, A mapping table 26 for mapping the space of the disk 50 and the DRAM 30 can be maintained.

The mapping table 26 may map a block ID (a logical block ID) and a physical location of a logical block storage. The mapping table 26 may not be held any longer when all the data of the hard disk 50 is loaded into the DRAM 30. [

9 is a view for explaining an embodiment of a DRAM storage according to another embodiment of the present invention.

As shown in FIG. 9, a PBestIO device (see 22 in FIG. 1) is generated, receives bio from the VFS, records the log in the NVRAM, and flushes it to the HDD. Herein, the flush means that contents stored in the current buffer are transmitted to the destination and the buffer is empty. In this embodiment, the contents stored in the NVRAM are transmitted to the HDD and the log records stored in the NVRAM are erased . ≪ / RTI > And the super block may be referred to as a block that can be later divided into a plurality of blocks stored in different areas.

The pdramstors_make_request function 91 is a function that receives bio from the VFS (see 62 in FIG. 1). When the bio is received from the VFS, it wakes up the bestio_thread_fun function (92) and can go to sleep mode.

The bestio_thread_fun function 92 executes the clone_pmem_bio function 93 to record the log in the NVRAM and can wake up the pdramstors_make_request function 91 when the log recording is completed.

The pdramstors_make_request function 91 writes the requested bio into the DRAM and terminates the corresponding operation.

The backup_thread_fun function 94 can check whether there is a log recorded in the NVRAM and call the chain function 95 if the log is recorded. The called chain function 95 reads header information of the log through a predetermined function, for example, is_full_manager function and readbuffer2manager function, records the header information in the HDD, and then transmits log information to the HDD through another predetermined function such as readbuffer2disk Can be recorded.

10 is a view for explaining another embodiment of the DRAM storage according to another embodiment of the present invention. FIG. 10 shows a function calling relationship of the process of creating and removing the PBestIO device (see 22 in FIG. 1).

10, when the PBestIO device is created, the self initialization function 97, for example, the My_init function is called first and the NVRAM (i. E., IsMetaEmtpy You can check if the magic code is written in. Magic code is a value that checks whether there is a log recorded in the NVRAM before the system is booted. If the magic code is left, the NVRAM log is transferred to the HDD and then the recovery_thread of the recovery function (for example, recovery_thread function) The data of the HDD can be backed up to the DRAM.

When the PBestIO device is removed, the My_exit function 99 is called to flush all the data in the NVRAM to the HDD, and the corresponding process can be terminated with the corresponding function.

According to the above-described embodiments, NVRAM (NVRAM) capable of stably maintaining data while using DRAM as block storage by using NVRAM (NVDIMM) which stably maintains data using a battery in a DRAM, hybrid block storage or NVRAM And hybrid block storage of DRAM and HDD.

Although the embodiments have been described with reference to a DRAM as a volatile memory, the present invention is not limited to such a configuration, and may include all volatile memories that can be used in place of a DRAM in accordance with development of a memory technology. The hybrid block storage of the present invention is not limited to a configuration including a DRAM, a nonvolatile memory, and a hard disk drive. The hybrid block storage of the present invention has a lower input / output performance than a DRAM, but has a certain advantage It is needless to say that another storage device (third storage device) replacing the hard disk drive may be used.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the present invention as defined by the following claims It can be understood that

Claims (17)

A method of operating a DRAM storage in a computing device comprising a non-volatile memory, a dynamic random access memory (DRAM), and a DRAM storage including a third storage device having a lower input / output capability than the DRAM,
Determining whether to process the input / output request in the third storage device or in the DRAM according to a record of how many blocks of the third storage device are loaded when the input / output request for the block data is requested;
Storing a log of blocks changed in the DRAM in the nonvolatile memory;
Backing up a block corresponding to the log from the non-volatile memory to the third storage device. The method according to claim 1,
Wherein the storing step stores in the non-volatile memory only the log of the changed area of the block that has been changed in the DRAM. The method according to claim 1,
Further comprising the step of recording the log in a mapping table mapping between physical spaces including the non-volatile memory, the DRAM and the third storage device and a space of logical block storage before the storing, How DRAM storage works. The method according to claim 1,
Wherein the storing step divides the log into a plurality of logs according to a storage unit of the third storage device and stores the log in the nonvolatile memory. The method according to claim 1,
Wherein the input / output request is generated from the application program when the application program running on the computing device loads data into the DRAM which is main memory. The method of claim 5,
Wherein the input / output request is transferred to a block device driver of a kernel through a virtual file system (VFS) connected to the application program. The method of claim 6,
Wherein the block device driver acquires a partial area of the DRAM and uses the DRAM as a DRAM storage, and converts the input / output request into memory read / write on a DRAM, which is a main memory, and processes the DRAM storage. The method of claim 6,
Wherein the block device driver writes a changed block to a corresponding area on the DRAM and then writes the changed block to the nonvolatile memory and terminates after the changed block is written to the nonvolatile memory, To the corresponding block of the third storage device. The method of claim 6,
After the backup step, when the computing device is restarted, blocks of the third storage device are loaded into the DRAM, and when an input / output request is transferred from the VFS, the blocks loaded in the DRAM are processed in the DRAM and are not yet loaded Further comprising: processing the blocks of the third storage device in the third storage device. The method of claim 9,
After the processing, the kernel of the computing device performs a logical block storage operation such that input / output in the DRAM, input / output in the third storage device, and loading operation from the third storage device to the DRAM are consistently performed. And mapping the physical space of the DRAM to the third storage device. The method of claim 10,
A mapping table for mapping a block ID corresponding to a space of the logical block storage and a physical location of the physical space is stored in the DRAM so that all data of the third storage device is not held or deleted, How storage works. The method according to claim 1,
Wherein the third storage device comprises a hard disk. A block device driver controlled by a virtual file system (VFS) of the kernel of the computing device;
A non-volatile random access memory (NVRAM) log manager and a load manager driven by the block device driver; And
A dynamic random access memory (DRAM) driven by the block device driver, a nonvolatile memory (NVRAM), and a third storage device having a lower input / output performance than the DRAM,
Here, IO requests of a user level application are converted into a block IO request through the VFS and transferred to the block device driver,
When the Block IO is a write operation, the Block IO is converted into a log record by the NVRAM log manager and stored in the NVRAM,
The NVRAM log manager reflects the Block IO to the DRAM when the log record of the Block IO is stored in the NVRAM, notifies the VFS that the processing of the Block IO is completed,
The VFS informs that the application of the Block IO has completed the processing of the Block IO,
The synchronization manager connected between the NVRAM and the third storage device reads the log record recorded in the NVRAM by the NVRAM log manager and converts the log record into a Block IO for writing to the third storage device, IO is used for the third storage device at the same location as the block location recorded in the DRAM. 14. The method of claim 13,
Wherein the loading manager loads the blocks of the third storage device sequentially into the DRAM at the restart of the computing device or system and controls whether each block is in the third storage device and loaded in the DRAM during loading And determines whether the corresponding block is in the third storage device or in the DRAM with respect to the Block IO transmitted from the VFS, and transfers the Block IO to the corresponding medium. 15. The method of claim 14,
Wherein the load manager uses a mapping table to manage the actual location of each block. 15. The method of claim 14,
Wherein the stack manager records only the number of the most recently loaded block from the third storage device to the DRAM to manage the actual location of each block. 14. The method of claim 13,
Wherein the third storage device comprises one or more hard disks and the size of one hard disk corresponds to the size of one DRAM.

Images