WO2011105023A1 - 処理装置および書込方法 - Google Patents
処理装置および書込方法 Download PDFInfo
- Publication number
- WO2011105023A1 WO2011105023A1 PCT/JP2011/000847 JP2011000847W WO2011105023A1 WO 2011105023 A1 WO2011105023 A1 WO 2011105023A1 JP 2011000847 W JP2011000847 W JP 2011000847W WO 2011105023 A1 WO2011105023 A1 WO 2011105023A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- block
- address
- file
- size
- blocks
- Prior art date
Links
- 238000012545 processing Methods 0.000 title claims abstract description 55
- 238000000034 method Methods 0.000 title claims description 58
- 239000000284 extract Substances 0.000 claims abstract description 16
- 238000003860 storage Methods 0.000 claims description 39
- 230000004931 aggregating effect Effects 0.000 claims description 7
- 230000000717 retained effect Effects 0.000 abstract 1
- 238000007726 management method Methods 0.000 description 20
- 238000004519 manufacturing process Methods 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000009825 accumulation Methods 0.000 description 3
- 238000000605 extraction Methods 0.000 description 3
- 238000011084 recovery Methods 0.000 description 3
- 238000004904 shortening Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000005192 partition Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000007430 reference method Methods 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/0643—Management of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/04—Addressing variable-length words or parts of words
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/061—Improving I/O performance
- G06F3/0611—Improving I/O performance in relation to response time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0673—Single storage device
- G06F3/0674—Disk device
- G06F3/0676—Magnetic disk device
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/54—Link editing before load time
Definitions
- the present invention relates to a writing technique, and relates to a processing apparatus and a writing method for writing a file to a storage medium.
- BIOS Basic Input Output System
- HDD hard disk drive
- Firmware can also be stored in the HDD. For example, firmware downloaded via a tuner or network, or firmware copied from a removable storage medium is temporarily stored in the HDD.
- the firmware is updated by writing the firmware stored in the HDD into a nonvolatile memory such as a FLASH ROM.
- the firmware can be stored in the HDD and the firmware can be written in the nonvolatile memory by an application program. However, regarding the writing to the nonvolatile memory, if a power outage or power supply disconnection in the middle of processing occurs, it becomes impossible to start the application next time.
- a boot loader that does not support the file system must directly read the firmware by specifying a block address. More specifically, the boot loader analyzes file system information. In the case of ext2, the file system information corresponds to a super block, a file descriptor, and the like. Following this, the boot loader searches the directory entry, extracts the start address of the firmware, and then reads the contents of a necessary file or a part thereof.
- the block addresses of the file contents are continuous.
- the block address is not continuous in the contents of the file, and i-nodes are included irregularly between the data. Therefore, a boot loader that does not use a file system reads out a file by extracting an address indicated by an i-node for each block. Each time an i-node is read, an overload of seek access occurs, and processing takes time. Such a problem exists not only at the time of reading but also at the time of writing.
- the block address of the created file will change every time the file created according to the file system rules is updated. For this reason, the block address to be read / written is not fixed, and eventually, it is necessary to incorporate processing equivalent to the file system in the boot loader. As a result, the code amount of the boot loader increases. This is undesirable for embedded devices with limited resources. As a workaround for this, there is a method of operating without using the file system, but conversely, not only can the file not be read / written by the application program, but other files cannot be stored.
- the present invention has been made in view of such a situation, and an object thereof is to provide a technique for shortening a processing delay in reading and writing a file by a boot loader.
- a processing device acquires management information indicating addresses of blocks constituting a file from a storage device capable of storing the file by dividing the file into a plurality of blocks.
- the address of each block is extracted from the acquisition unit to be acquired and the management information acquired in the acquisition unit, and the start address and the size for each continuous region are indicated by aggregating blocks having consecutive addresses as a continuous region
- the reading unit that reads the data stored in the non-volatile memory, and the table that is generated in the generation unit, the data spans from the start address to the end address determined by the size.
- the data is divided into continuous areas, and the divided data is assigned to the addresses of the blocks that make up the file indicated in the management information. And a writing unit that writes to the storage device so as to maintain.
- the table showing the start address and size corresponding to the continuous area is created from the storage device, and the file is written to the storage device according to the table, so the writing time can be shortened.
- the acquisition unit re-acquires management information indicating the address of each block from the storage device in which the file is divided and stored, and the generation unit re-acquires each management information re-acquired by the acquisition unit.
- a table showing the start address and size for each continuous area is regenerated, and the reading unit reproduces it in the generation unit
- the data of each block constituting the file divided and stored in the storage device is read and written
- the data of each block read by the reading unit may be written in the nonvolatile memory.
- the update time can be shortened.
- the writing unit may update at least one of the attribute, the file name, and the update date / time among the file information stored in the storage device when writing the divided data to the storage device. In this case, since at least one of the attribute, the file name, and the update date / time is updated, evidence of the update completion can be left.
- This device includes an acquisition unit that acquires management information indicating the address of each block from a storage device in which the first firmware program is divided and stored in a plurality of blocks, and management information acquired by the acquisition unit.
- the address of each block is extracted, and the generation unit that generates a table showing the start address and the size for each continuous region by collecting the blocks having consecutive addresses as a continuous region, and the generation unit Based on the table, for each continuous area from the start address to the end address determined by the size, a read unit for reading the first firmware program divided and stored in the storage device, and reading by the read unit
- the second firmware stored in the non-volatile memory by the first firmware program And a writing section for updating the air program.
- a table showing the start address and size corresponding to the continuous area in the first firmware program stored in the storage device is created, and the read process is executed according to the table. Can be shortened.
- the reading unit When a part of the first firmware program is to be read, the reading unit reads only the block corresponding to the reading target based on the table generated by the generating unit. In this case, since only the block corresponding to the read target is read out from the continuous area, it is possible to cope with the case where a part of the first firmware program is set as the read target.
- the generation unit may omit the generation of the table by reusing the already generated table. In this case, since the already generated table is reused, the processing period can be shortened.
- Still another aspect of the present invention is a writing method.
- This method includes a step of acquiring management information indicating addresses of blocks constituting a file from a storage device capable of storing the file by dividing the file into a plurality of blocks, and an address of each block from the acquired management information.
- Still another embodiment of the present invention is also a writing method.
- This method includes a step of acquiring management information indicating the address of each block from a storage device in which a first firmware program is divided and stored into a plurality of blocks, and from the acquired management information, Extracting addresses and aggregating blocks with consecutive addresses as continuous areas, generating a table showing the start address and size for each continuous area, and starting addresses based on the generated table And reading the first firmware program stored in the storage device separately for each continuous area from the end address to the end address determined by the size, and the nonvolatile memory by the read first firmware program Updating the second firmware program stored in Equipped with a.
- FIG. 8 is a conceptual diagram of adjustment of a start address and a size by a start end and a termination end in the reading unit in FIG. 7. It is a flowchart which shows the write-in procedure by the boot loader of FIG. It is a flowchart which shows the preparation procedure of the table in the production
- An embodiment of the present invention relates to a boot loader for updating a firmware program stored in a nonvolatile memory by a firmware program stored in an HDD (Hard Disk Drive).
- HDD Hard Disk Drive
- the file system used for the HDD is ext2.
- the firmware program is divided into a plurality of blocks and stored. A plurality of blocks are not always continuous.
- the boot loader since the boot loader does not recognize the block address of the firmware program stored in the HDD in advance, it must acquire the i-node indicated by the block address. Since these i-nodes are distributed and stored in the HDD, when reading the firmware program while obtaining the block address from the i-node, it is difficult to read the continuous blocks at once. This makes it difficult to increase the reading speed. In order to cope with this, the boot loader according to the embodiment executes the following processing.
- the boot loader obtains a block address from the i-node and reads a table regarding continuous blocks (hereinafter referred to as “continuous area”) before reading the firmware program.
- This table shows the start address and size of each continuous area.
- the boot loader reads the continuous blocks at a time while referring to the table, thereby speeding up the reading of the firmware program from the HDD.
- FIG. 1 shows a configuration of a processing apparatus 100 according to Embodiment 1 of the present invention.
- the processing device 100 includes a processor 102, an HDD 104, a volatile memory 106, a nonvolatile memory 108, a removable memory 110, and a tuner 112.
- the processor 102 includes a CPU (central processing unit) 114 and a boot loader 116. Further, the processing apparatus 100 is connected to the server 120 via the network 118.
- CPU central processing unit
- the processor 102 is realized by an integrated circuit or the like.
- the processor 102 integrates various drivers and dedicated processing modules in addition to the CPU 114 and the boot loader 116.
- the processor 102 can access various devices and media.
- the nonvolatile memory 108 is a FLASH ROM, an EEPROM, or the like, and stores a program to be processed by the CPU 114.
- the nonvolatile memory 108 stores a firmware program.
- the volatile memory 106 is an actual processing memory composed of SDRAM or the like.
- the boot loader 116 reads the program from the nonvolatile memory 108 into the volatile memory 106 and starts it, so that the CPU 114 can process the program. Note that the processing of the boot loader 116 can be divided in stages, so that a part of the processing may be included in the program.
- the tuner 112 is a module capable of receiving BS / CS / terrestrial digital / terrestrial analog, etc., and outputs received data under the control of the processor 102.
- the HDD 104 stores various programs, data received by the tuner 112, and the like.
- the HDD 104 stores a firmware program of a newer version than the firmware program stored in the nonvolatile memory 108.
- the processor 102 includes a driver for the removable memory 110, and data can be read from and written to the removable memory 110.
- the processor 102 has a driver for communication, and communicates with a server 120 at a remote location via a network 118 such as the Internet or an intranet.
- the nonvolatile memory 108 is generally written with a program such as a firmware program at the time of factory shipment.
- a program such as a firmware program at the time of factory shipment.
- the program is updated in the user's usage environment after shipment.
- An example of the program update is update by on-air download using satellite broadcasting.
- the program update data is downloaded by the tuner 112, and the program is updated after the data is accumulated, as in the program guide.
- program update data may be downloaded from the remote location server 120 via the network 118, and the program update may be performed after accumulating the data.
- the data stored in the removable memory 110 may be copied, and the program may be updated after the data is accumulated.
- the process for updating the firmware program includes a process for acquiring and storing update data (hereinafter referred to as “storage process”), a process for reading the stored update data and writing it into the nonvolatile memory 108 (hereinafter referred to as “document”). Are classified as “combined processing”).
- the update data is stored in the HDD 104. Since the accumulation process is performed during the operation of the application program such as on-air download or download via the network 118, the accumulation process itself is also performed by the application program. Data copying from the detachable memory 110 is also suitable for accumulation processing by an application program because it is only necessary to copy a file if the application program is in operation.
- the writing process can be realized by an application program, but the application program is included in the update data. For this reason, if a power failure or a user pulls out the power during writing, the OS (Operating System) or application program may not start normally next time. As a result, it becomes impossible to retry writing, and it will never return. Therefore, it is desirable that the process of reading the accumulated update data and writing it in the nonvolatile memory 108 is performed by the boot loader 116 that does not depend on the OS or application.
- the boot loader 116 performs the writing process, a reboot process is involved in the process of acquiring and accumulating the update data, which is a pre-process, and the data storage location is non-volatile and for updating. A capacity capable of storing software programs is required. Therefore, the HDD 104 is suitable as a storage location for the software program for update.
- FIG. 2 shows an outline of the ext2 file system in the HDD 104.
- ext2 is often used as the block file system.
- ext2 is developed based on Fast File System and is based on the “block management algorithm” traditionally used in UNIX (registered trademark).
- a block unit is composed of any one of 1024, 2048, and 4096 bytes, and a plurality of blocks are managed together in a “block group”.
- FIG. 2 the structure of the block group is shown.
- the left side of FIG. 2 shows the partitions formed in the HDD 104 of FIG. 1, and the center of FIG. 2 shows the layout of the ext2 partition.
- the right side of FIG. 2 shows further details of the layout within the block group.
- the super block is management information related to the file system
- the group descriptor is information in the group
- the data block bitmap is information on the data block.
- the i-node table stores i-nodes that hold information on files / directories, and the data block holds actual data.
- the boot loader 116 shown in FIG. 1 obtains file system information from super block and group descriptor information, and then searches the directory entry to obtain inode table information corresponding to the target file. By obtaining the memory address of the data block based on the i-node table, actual data in the file can be read.
- the size of the data block is one of 1024, 2048, and 4096 bytes that is the same as the other blocks.
- 100 data blocks are required to refer to a file having a data block size of 2048 bytes and a file size of 200 Kbytes. However, if 100 addresses are held for 100 data blocks, the amount of information increases, so in ext2, an indirect block is created in order to use the address range efficiently and is referenced by an indirect pointer. I can do it.
- FIG. 3 shows an overview of the i-node table and block address in the HDD 104.
- the inode has 15 arrays for data block references, and in ext2, 12 of them are “direct reference”, and the remaining three are “single-stage indirect reference”, “two-stage indirect reference”, and “three-stage indirect reference”, respectively. Used for.
- ext2 efficiently handles a large file that requires a plurality of data blocks.
- the file size that can be expressed by each reference method is calculated as follows.
- the calculation formula for direct reference is “block size ⁇ 12”. When the block size is 1024 bytes, 2048 bytes, and 4096 bytes, the file sizes are 12 Kbytes, 24 Kbytes, and 48 Kbytes, respectively.
- block size ⁇ 4 can be used for indirect reference. This corresponds to the size [byte] of the block pointer. Therefore, when converted to the file size, “block size ⁇ 4 * block size” is obtained. When the block size is 1024 bytes, 2048 bytes, and 4096 bytes, the respective file sizes are 256 Kbytes, 1 Mbytes, and 4 Mbytes. In the two-stage indirect reference, when converted to a file size, “((block size ⁇ 4) 2 ) ⁇ block size” is obtained. Therefore, when the block size is 1024 bytes, 2048 bytes, and 4096 bytes, the respective file sizes are 64 Mbytes, 512 Mbytes, and 4 Gbytes. When the file size of the update program to be written in the nonvolatile memory 108 in FIG. 1 is several tens to several hundreds Mbytes, it is desirable to use two-stage indirect reference.
- FIG. 4 shows the relationship between the file on the block address in the HDD 104 and the i-node.
- the i-node itself is not stored in a collective area in the HDD 104 but is formed in a data block. Therefore, when indirect reference is used, the original file data is not continuous. This is because the kernel tries to allocate the i-node in the same group as the data block in order to reduce the seek of the disk head when reading the i-node and the corresponding data block.
- the address expression is 4 bytes, the number of addresses that can be stored in one block is “block size ⁇ 4”. That is, for calculation, all addresses cannot be expressed unless an i-node is included in the data once in “block size ⁇ 4”.
- FIG. 5 shows the configuration of the HDD 104.
- an area called a sector 152 is formed as a unit for reading and writing data.
- the magnetic head 146 is moved on the disk 140 by the swing arm 144, and data is accessed. This operation is called seek, and the required time is called seek time. Since there is no seek time within the same cylinder 148, only the rotation waiting time is provided, but when seeking is involved, the seek time must be taken into consideration.
- the data read time of the HDD 104 is calculated by “(average seek time + average rotation wait time + data transfer time) ⁇ (seek repetition count)”.
- the relationship of data transfer time ⁇ (average seek time + average rotation waiting time) is established.
- FIG. 6 shows the relationship between the number of read unit blocks of the HDD 104 and the read time. This is a result of measuring the read time of 128 Mbytes data while changing the access unit. With respect to reading in units of one block, as the number of reading unit blocks is increased, the reading time is greatly reduced and saturated near 128 Mbytes.
- FIG. 7 shows the configuration of the boot loader 116.
- the boot loader 116 includes an acquisition unit 130, a generation unit 132, a reading unit 134, a dividing unit 136, and a writing unit 138.
- the acquisition unit 130 analyzes a super block configured on the ext2 file system in the HDD 104 of FIG. 1 and acquires necessary information such as a block size.
- the acquisition unit 130 analyzes the group descriptor and acquires necessary information such as an i-node table ID.
- the acquisition unit 130 searches the directory entry and acquires the i-node information of the update file.
- the generation unit 132 acquires management information indicating the address of each block from the HDD 104 in which the update firmware program is divided and stored in a plurality of blocks.
- the generation unit 132 extracts a block address corresponding to each block in the file using the acquired management information, that is, the information of the i-node table and indirect reference.
- the generation unit 132 aggregates blocks having consecutive block addresses as a continuous area.
- FIG. 8 shows an outline of continuous regions generated by the generation unit 132. Here, the relationship between the block address, the table indicating the start address and size of the continuous area will be supplemented.
- FIG. 8 shows all the blocks in the file as an array and shows the correspondence with each block address.
- Block addresses are also continuous from Block [0] to Block [11], which are direct references, but one block address is shifted from Block [12]. This is because 0x00001C0C is missing because it is used for indirect reference of inodes.
- the generation unit 132 generates a table indicating the start address and size for each continuous area.
- the table may be configured as an array on the volatile memory 106 of FIG. 1 or may be stored in the HDD 104 or the nonvolatile memory 108.
- FIG. 9 shows a table generated by the generation unit 132.
- the first continuous area is in the range from Block [0] to Block [11] in FIG. 8, and the corresponding start address and size are the values shown in the first line of FIG. The same applies to the second and subsequent continuous areas.
- a table as shown in FIG. 9 is generated.
- the size of the table in FIG. 9 is much smaller than the size of the table in FIG.
- the reading unit 134 reads out the firmware program for update stored in the HDD 104 for each continuous area from the start address to the size based on the table generated by the generating unit 132. In other words, the reading unit 134 reads a plurality of blocks included in the continuous area together.
- the reading unit 134 temporarily stores the read firmware program in the volatile memory 106. At this time, when a part of the firmware program for update is cut out, the start end and the end of the part to be cut out are not necessarily separated by a continuous area. At that time, the reading unit 134 detects in advance which continuous region includes the start and end and adjusts the start address and size.
- the reading unit 134 reads only the block corresponding to the read target based on the table generated by the generation unit 132.
- the writing unit 138 reads the update firmware program from the volatile memory 106 and writes it to the nonvolatile memory 108. That is, the writing unit 138 updates the previous firmware program stored in the nonvolatile memory 108 with the update firmware program read by the reading unit 134. Note that the dividing unit 136 does not operate in the first embodiment.
- FIG. 10 is a conceptual diagram of the adjustment of the start address and size by the start and end in the reading unit 134.
- the continuous areas are connected in order to create virtual addresses (in practice, in between) Since i-node is entered, it is different from the real address).
- This configuration can be realized in terms of hardware by a CPU, memory, or other LSI of any computer, and in terms of software, it can be realized by a program loaded in the memory, but here it is realized by their cooperation.
- Draw functional blocks Accordingly, those skilled in the art will understand that these functional blocks can be realized in various forms by hardware only, software only, or a combination thereof.
- FIG. 11 is a flowchart showing a writing procedure by the boot loader 116.
- the acquisition unit 130 analyzes a super block configured on the ext2 file system (S10), and acquires necessary information such as a block size.
- the acquisition unit 130 analyzes the group descriptor (S12) and acquires necessary information such as an i-node table ID.
- the acquisition unit 130 searches the directory entry and acquires the i-node information of the update file (S14).
- the generating unit 132 extracts the block address corresponding to each block in the file using the inode table information and indirect reference, and creates a table indicating the start address and size of the continuous area (S16).
- the reading unit 134 reads the update firmware from the HDD 104 for each continuous area, and temporarily stores it in the volatile memory 106 (S18).
- the writing unit 138 reads the update firmware from the volatile memory 106 and writes it into the nonvolatile memory 108 (S20).
- FIG. 12 is a flowchart showing a table creation procedure in the generation unit 132.
- the generation unit 132 extracts a head block address located at the head of the file (S40).
- the generation unit 132 inserts the extracted first block address value into the start address of the continuous area (S42).
- the generation unit 132 initializes parameters (continuous area number, continuous area size, block number counter) (S44). If the block counter m does not exceed the block size (Y in S46), the generation unit 132 extracts a block address (S48).
- the generation unit 132 checks whether the block address is continuous with the block address of the previous data, and if it is continuous (Y in S50), increments only the size (S54). If not continuous (N in S50), the generation unit 132 increments the continuous area number, updates the start address with the current block address, and initializes the size (1) (S52). . The generation unit 132 increments the block number counter (S56), and then returns to Step 46. If the block number counter m exceeds the block size (N in S46), the process ends.
- FIG. 13 is a flowchart showing a block address extraction procedure in the generation unit 132. This corresponds to the block address extraction in steps 40 and 48 of FIG. 11 can be extracted from the i-node table shown in FIG. 3 based on the i-node information obtained in step 14 in FIG. 11, but reference is made to this in order to clarify the explanation.
- the information extracted is set to i_node [i] 0 ⁇ i ⁇ 15 (S70). If i ⁇ 12 (Y in S72), the generation unit 132 performs direct reference and extracts a block address (S74).
- the table indicating the start address and the size corresponding to the continuous area in the update firmware program stored in the HDD is created, and the reading process is executed according to the table.
- Firmware program update time can be shortened.
- the update time can be shortened even when a boot loader having no file system updates the firmware program stored in the nonvolatile memory.
- the read size from the HDD is close to “block size ⁇ 4”, reading can be performed at high speed.
- even when a file is rearranged on the file system it can flexibly follow, so that the influence on performance can be reduced.
- the information amount of the table in the continuous area is smaller than the information amount of the table for the block address, the processing efficiency can be improved.
- the second embodiment of the present invention relates to a boot loader for writing a firmware program.
- the second embodiment corresponds to a case where the firmware program stored in the nonvolatile memory is temporarily stored in the HDD.
- the temporary storage in the HDD is performed for the purpose of backing up the firmware program. That is, in the second embodiment and the first embodiment, the storage medium from which the firmware program is read is opposite to the storage medium into which the firmware program is written.
- the processing apparatus 100 according to the second embodiment is the same type as that in FIG. 1, and the boot loader 116 according to the second embodiment is the same type as that in FIG. Here, it demonstrates centering on the difference with Example 1.
- the HDD 104 stores a backup firmware program or a file having the same size as the firmware program to be backed up by an application program or the like on the file system.
- the acquisition unit 130 analyzes the super block and the group descriptor for the HDD 104 in FIG. Further, the acquisition unit 130 searches the directory entry and acquires the i-node information of the file already stored in the HDD 104.
- the generation unit 132 acquires management information indicating the address of each block from the HDD 104 that can store a file such as backup firmware in a plurality of blocks.
- the generation unit 132 extracts a block address corresponding to each block in the file using the information of the i-node table and indirect reference.
- the generation unit 132 aggregates blocks having consecutive block addresses as a continuous area.
- the generation unit 132 generates a table indicating the start address and size for each continuous area.
- the reading unit 134 reads the firmware program stored in the nonvolatile memory 108 and temporarily stores it in the volatile memory 106.
- the read firmware program is a firmware program to be backed up.
- the dividing unit 136 divides the firmware program stored in the volatile memory 106. Further, the dividing unit 136 aggregates the plurality of divided blocks so as to match the continuous area aggregated in the generating unit 132. By such processing, the firmware program is divided into a plurality of parts so as to correspond to each continuous area generated in the generation unit 132.
- the writing unit 138 writes the firmware program divided by the dividing unit 136 into the HDD 104 for each continuous area from the start address to the size based on the table generated by the generating unit 132. That is, the firmware program divided into a plurality of parts is written in the HDD 104 so as not to change the address of the continuous area. As a result, the block address indicated in the management information such as the i-node table is not changed. Writing the firmware program to the HDD 104 is equivalent to backing up the firmware program.
- FIG. 14 is a flowchart showing a writing procedure by the boot loader 116 according to the second embodiment of the present invention.
- the acquisition unit 130 analyzes a super block configured on the ext2 file system (S100), and acquires necessary information such as a block size.
- the acquisition unit 130 analyzes the group descriptor (S102) and acquires necessary information such as an i-node table ID.
- the acquisition unit 130 searches the directory entry and acquires the i-node information of the backup file (S104).
- the generation unit 132 extracts the block address corresponding to each block in the file using the inode table information and indirect reference, and creates a table indicating the start address and size of the continuous area (S106).
- the reading unit 134 reads the firmware from the nonvolatile memory 108 to the volatile memory 106 (S108).
- the writing unit 138 reads the backup firmware from the volatile memory 106 and writes it to the backup file in the HDD 104 for each continuous area (S110).
- a table showing a start address and a size corresponding to a continuous area is created for a file of the same size generated in advance by an application program or the like, and a writing process is executed according to the table. So backup time can be shortened.
- the writing process since the writing process is executed according to the table, the writing process can be performed at a high speed even when the backup data is stored in the HDD.
- the writing process since the writing process is executed according to the table, it can coexist with the process of the application program using the file system. Although it is difficult to write a file with a boot loader that does not have a file system, it is written using the block address of a file of the same size that was placed earlier. Coexistence can be realized.
- the third embodiment of the present invention corresponds to the case where the operation of the first embodiment is executed following the operation of the second embodiment.
- the third embodiment corresponds to a case where the backup file stored in the HDD by the operation of the second embodiment is used to update the firmware program in the nonvolatile memory.
- Such updating of the firmware program can be said to be a recovery of the firmware program.
- the processing apparatus 100 according to the third embodiment is the same type as that shown in FIG. 1, and the boot loader 116 according to the third embodiment is the same type as that shown in FIG.
- it demonstrates centering on the difference with the previous Example.
- a firmware program for backup is stored on the file system by the processing in the second embodiment.
- the acquisition unit 130 analyzes super blocks and group descriptors configured on the ext2 file system in the HDD 104 of FIG.
- the acquisition unit 130 searches the directory entry and re-acquires the i-node information of the backup file. That is, the acquisition unit 130 re-acquires management information indicating the address of each block from the HDD 104 in which the backup firmware program is divided and stored in a plurality of blocks.
- the generation unit 132 extracts the block address corresponding to each block in the backup firmware program using the management information acquired by the acquisition unit 130, that is, the information of the i-node table and indirect reference.
- the generation unit 132 aggregates blocks having consecutive block addresses as a continuous area.
- the generation unit 132 regenerates a table indicating the start address and size for each continuous area.
- the reading unit 134 reads the backup firmware program that is divided and stored in the HDD 104 for each continuous area from the start address to the size.
- the reading unit 134 temporarily stores the read firmware program in the volatile memory 106.
- the writing unit 138 reads a backup firmware program from the volatile memory 106 and writes it in the nonvolatile memory 108. That is, the writing unit 138 recovers the previous firmware program stored in the non-volatile memory 108 using the backup firmware program read by the reading unit 134. Note that the dividing unit 136 does not operate in the third embodiment.
- FIG. 15 is a flowchart showing a writing procedure by the boot loader 116 according to the third embodiment of the present invention.
- the acquisition unit 130 analyzes a super block configured on the ext2 file system (S130), and acquires necessary information such as a block size.
- the acquisition unit 130 analyzes the group descriptor (S132), and acquires necessary information such as an i-node table ID.
- the acquisition unit 130 searches the directory entry and acquires the i-node information of the update file (S134).
- the generation unit 132 extracts the block address corresponding to each block in the file using the inode table information and indirect reference, and creates a table indicating the start address and size of the continuous area (S136).
- the reading unit 134 reads the backup firmware from the HDD 104 for each continuous area and temporarily stores it in the volatile memory 106 (S138).
- the writing unit 138 reads the backup firmware from the volatile memory 106 and writes it in the nonvolatile memory 108 (S140).
- the table indicating the start address and the size corresponding to the continuous area in the update firmware program stored in the HDD is created, and the reading process is executed according to the table.
- Firmware program recovery time can be shortened. Further, since the table is created, the recovery time can be shortened even when a boot loader without a file system updates the firmware program stored in the nonvolatile memory.
- Example 4 As in the second embodiment, the fourth embodiment of the present invention corresponds to the case where the firmware program stored in the nonvolatile memory is temporarily stored in the HDD. In the fourth embodiment, the file information is also updated when the firmware program is stored in the HDD.
- the processing apparatus 100 according to the fourth embodiment is the same type as that shown in FIG. 1, and the boot loader 116 according to the fourth embodiment is the same type as that shown in FIG. Here, it demonstrates centering on the difference with the previous Example.
- the writing unit 138 writes the firmware program divided by the dividing unit 136 to the HDD 104 for each continuous area from the start address to the size based on the table generated by the generating unit 132. . At that time, the writing unit 138 updates at least one of the attribute, the file name, and the update date / time among the file information about the firmware program to be written to the HDD 104.
- FIG. 16 is a flowchart showing a writing procedure by the boot loader 116 according to the fourth embodiment of the present invention. Steps 160 to 170 in FIG. 16 are the same as steps 100 to 110 in FIG.
- the writing unit 138 updates at least one of the attribute, the file name, and the update date / time in the file information (S172).
- the data on the file system is updated by updating at least one of the attribute, the file name, and the update date / time in the file information, so that the update can be confirmed from the application program.
- the fifth embodiment of the present invention corresponds to the case where the table used in the second embodiment and the table used in the third embodiment are shared. That is, in the fifth embodiment, the firmware program stored in the nonvolatile memory is temporarily stored as a backup file in the HDD, and the firmware program stored in the nonvolatile memory by using the backup file temporarily stored in the HDD. It is related with making a table common in the case of updating. Such processing makes it possible to reduce the time for creating the table.
- the processing apparatus 100 according to the fifth embodiment is the same type as that shown in FIG. 1, and the boot loader 116 according to the fifth embodiment is the same type as that shown in FIG. Here, it demonstrates centering on the difference with the previous Example.
- the acquisition unit 130 checks whether the generated table is stored in the HDD 104 or the nonvolatile memory 108. . If the table is not stored, the acquisition unit 130 and the generation unit 132 generate a table by executing the same processing as in the second embodiment. On the other hand, if the table is stored, the acquisition unit 130 and the generation unit 132 omit the processing in the second embodiment, and the reading unit 134 reads the firmware program stored in the non-volatile memory 108 and is volatile. Temporarily stored in the memory 106.
- the acquisition unit 130 stores the already generated table in the HDD 104 or the nonvolatile memory 108. Make sure that Here, if the table is generated in the past when the firmware program stored in the nonvolatile memory 108 is stored in the HDD 104 or when the firmware program stored in the HDD 104 is stored in the nonvolatile memory 108, Good. If the table is not stored, the acquisition unit 130 and the generation unit 132 generate a table by executing the same processing as in the third embodiment.
- the acquisition unit 130 and the generation unit 132 omit the processing in the third embodiment, and the reading unit 134 changes the size from the start address to the size based on the stored table. For each continuous area, the firmware program for backup stored separately in the HDD 104 is read. In this way, the generation unit 132 omits the table generation process by reusing the already generated table.
- FIG. 17 is a flowchart showing a writing procedure by the boot loader 116 according to the fifth embodiment of the present invention. If there is an existing table (Y in S190), the reading unit 134 reads the table (S192). If there is no existing table (N in S190), the acquisition unit 130 analyzes the super block (S194). Steps 194 to 206 are the same as steps 100 to 110 in FIG.
- FIG. 18 is a flowchart showing a writing procedure by the boot loader 116 following FIG. If there is an existing table (Y in S220), the reading unit 134 reads the table (S222). If there is no existing table (N in S220), the acquisition unit 130 analyzes the super block (S224). Steps 224 to 236 are the same as steps 130 to 140 in FIG.
- the update processing time of backup data can be shortened and the recovery processing time using the backup data can be shortened.
- the time for creating the table can be reduced.
- the processing amount can be reduced.
- Example 6 The sixth embodiment of the present invention corresponds to the case where the table already generated is used without generating a new table when the table is already generated in the first embodiment.
- the processing apparatus 100 according to the sixth embodiment is the same type as that shown in FIG. 1, and the boot loader 116 according to the sixth embodiment is the same type as that shown in FIG. Here, it demonstrates centering on the difference with the previous Example.
- the acquisition unit 130 stores the already generated table in the HDD 104 or the nonvolatile memory 108. Confirm. If the table is not stored, the acquisition unit 130 and the generation unit 132 generate a table by executing the same processing as in the first embodiment. On the other hand, if the table is stored, the acquisition unit 130 and the generation unit 132 omit the process in the first embodiment, and the reading unit 134 changes the size from the start address to the size based on the stored table. For each continuous area, the firmware program for update stored separately in the HDD 104 is read.
- the acquisition unit 130 checks the creation date and time of the table, and if the table is created before a predetermined period, the acquisition unit 130 and the generation unit 132 The same processing as in the first embodiment may be executed. That is, the table only needs to be used when the table is newer than the predetermined period.
- FIG. 19 is a flowchart showing a writing procedure by the boot loader 116 according to the sixth embodiment of the present invention. If there is an existing table (Y in S250), the reading unit 134 reads the table (S252). If there is no existing table (N in S250), the acquisition unit 130 analyzes the super block (S254). Steps 254 to 266 are the same as steps 10 to 20 in FIG.
- the time for creating the table can be reduced.
- the update time of the firmware program can be shortened.
- the processing period can be shortened when it is desired to retry the processing using the same firmware program for updating or when writing in advance at the time of production.
- the boot loader 116 uses a firmware program as a processing target.
- the present invention is not limited to this.
- the boot loader 116 may target a file other than the firmware program.
- the present invention can be applied to various types of file reading and writing processes.
- the ext2 file system is the object of description as the file system in the HDD 104.
- the present invention is not limited thereto, and for example, a file system other than ext2, ext3, may be used as a file system in the HDD 104. According to this modification, the present invention can be applied to various types of file systems.
- processing unit 102 processor, 104 HDD, 106 volatile memory, 108 non-volatile memory, 110 removable memory, 112 tuner, 114 CPU, 116 boot loader, 118 network, 120 server, 130 acquisition unit, 132 generation unit, 134 read Part, 136 division part, 138 writing part.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
本発明を具体的に説明する前に、まず概要を述べる。本発明の実施例は、HDD(Hard Disk Drive)に記憶されたファームウエアプログラムによって、不揮発性メモリに記憶されたファームウエアプログラムを更新するためのブートローダに関する。ここでは、一例として、HDDに使用されるファイルシステムが、ext2であるとする。ext2において、ファームウエアプログラムは、複数のブロックに分割されて記憶される。なお、複数のブロックが連続しているとは限らない。詳細は後述するが、HDDからのファームウエアプログラムの読出し期間を短くするためには、シークの繰り返し回数を少なくし、連続したブロックを一度に読み出すことが有効である。
本発明の実施例2は、実施例1と同様に、ファームウエアプログラムを書き込むためのブートローダに関する。一方、実施例2は、実施例1と異なり、不揮発性メモリに記憶されたファームウエアプログラムをHDDに一時格納する場合に相当する。ここで、HDDへの一時格納は、ファームウエアプログラムのバックアップを目的としてなされる。つまり、実施例2と実施例1では、ファームウエアプログラムを読み出すべき記憶媒体と、ファームウエアプログラムを書き込むべき記憶媒体とが反対になる。実施例2に係る処理装置100は、図1と同様のタイプであり、実施例2に係るブートローダ116は、図7と同様のタイプである。ここでは、実施例1との差異を中心に説明する。
本発明の実施例3は、実施例2の動作につづいて、実施例1の動作を実行する場合に相当する。つまり、実施例3は、実施例2の動作によってHDDに記憶されたバックアップファイルを利用し、不揮発性メモリのファームウエアプログラムを更新する場合に相当する。このようなファームウエアプログラムの更新は、ファームウエアプログラムのリカバリーともいえる。実施例3に係る処理装置100は、図1と同様のタイプであり、実施例3に係るブートローダ116は、図7と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。
本発明の実施例4は、実施例2と同様に、不揮発性メモリに記憶されたファームウエアプログラムをHDDに一時格納する場合に相当する。実施例4では、ファームウエアプログラムをHDDに格納する際に、ファイル情報も更新される。実施例4に係る処理装置100は、図1と同様のタイプであり、実施例4に係るブートローダ116は、図7と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。
本発明の実施例5は、実施例2において使用したテーブルと、実施例3において使用したテーブルを共通化する場合に相当する。つまり、実施例5は、不揮発性メモリに記憶したファームウエアプログラムをHDDにバックアップファイルとして一時格納させる場合と、HDDに一時格納したバックアップファイルを利用することによって、不揮発性メモリに記憶したファームウエアプログラムを更新する場合とにおいてテーブルを共通化することに関する。このような処理によって、テーブル作成のための時間を削減することが可能になる。実施例5に係る処理装置100は、図1と同様のタイプであり、実施例5に係るブートローダ116は、図7と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。
本発明の実施例6は、実施例1においてテーブルを既に生成している場合、テーブルを新たに生成せずに、既に生成したテーブルを利用する場合に相当する。実施例6に係る処理装置100は、図1と同様のタイプであり、実施例6に係るブートローダ116は、図7と同様のタイプである。ここでは、これまでの実施例との差異を中心に説明する。
Claims (11)
- ファイルを複数のブロックに分割して記憶可能な記憶装置から、前記ファイルを構成する各ブロックのアドレスが示された管理情報を取得する取得部と、
前記取得部において取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成する生成部と、
不揮発性メモリに記憶されたデータを読み出す読出部と、
前記生成部において生成したテーブルをもとに、前記データを、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに分割し、分割したデータを、管理情報に示された前記ファイルを構成する各ブロックのアドレスを維持させるように前記記憶装置に書き込む書込部と、
を備えることを特徴とする処理装置。 - 前記取得部は、ファイルが複数のブロックに分割して記憶された前記記憶装置から、各ブロックのアドレスが示された管理情報を再取得し、
前記生成部は、前記取得部において再取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として再集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを再生成し、
前記読出部は、前記生成部において再生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、前記記憶装置に分割して記憶された前記ファイルを構成する各ブロックのデータを読み出し、
前記書込部は、前記読出部において読み出した前記各ブロックのデータを前記不揮発性メモリに書き込むことを特徴とする請求項1に記載の処理装置。 - 前記書込部は、分割したデータを前記記憶装置に書き込む際に、前記記憶装置に記憶されたファイル情報のうち、属性、ファイル名、更新日時の少なくともひとつを更新することを特徴とする請求項1に記載の処理装置。
- 第1のファームウエアプログラムが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を取得する取得部と、
前記取得部において取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成する生成部と、
前記生成部において生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、前記記憶装置に分割して記憶された第1のファームウエアプログラムを読み出す読出部と、
前記読出部において読み出した第1のファームウエアプログラムによって、不揮発性メモリに記憶された第2のファームウエアプログラムを更新する書込部と、
を備えることを特徴とする処理装置。 - 前記読出部は、第1のファームウエアプログラムの一部を読み出し対象とする場合、前記生成部において生成したテーブルをもとに、読み出し対象に対応したブロックだけ読み出すことを特徴とする請求項4に記載の処理装置。
- 前記読出部は、連続領域を順番につなげていくことによって仮想のアドレスを作成するとともに、読み出し対象の一部のデータの始端と終端が、どの連続領域の仮想アドレス内に存在するかを検出してから、開始アドレスとサイズを調整することを特徴とする請求項5に記載の処理装置。
- 前記生成部は、既に生成したテーブルを再利用することによって、テーブルの生成を省略することを特徴とする請求項1から6のいずれかに記載の処理装置。
- ファイルを複数のブロックに分割して記憶可能な記憶装置から、前記ファイルを構成する各ブロックのアドレスが示された管理情報を取得するステップと、
取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、
不揮発性メモリに記憶されたデータを読み出すステップと、
生成したテーブルをもとに、前記データを、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに分割し、分割したデータを、管理情報に示された前記ファイルを構成する各ブロックのアドレスを維持させるように前記記憶装置に書き込むステップと、
を備えることを特徴とする書込方法。 - 第1のファームウエアプログラムが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を取得するステップと、
取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、
生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、前記記憶装置に分割して記憶された第1のファームウエアプログラムを読み出すステップと、
読み出した第1のファームウエアプログラムによって、不揮発性メモリに記憶された第2のファームウエアプログラムを更新するステップと、
を備えることを特徴とする書込方法。 - ファイルを複数のブロックに分割して記憶可能な記憶装置から、前記ファイルを構成する各ブロックのアドレスが示された管理情報を取得するステップと、
取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、
不揮発性メモリに記憶されたデータを読み出すステップと、
生成したテーブルをもとに、前記データを、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに分割し、分割したデータを、管理情報に示された前記ファイルを構成する各ブロックのアドレスを維持させるように前記記憶装置に書き込むステップと、
をコンピュータに実行させるためのプログラム。 - 第1のファームウエアプログラムが複数のブロックに分割して記憶された記憶装置から、各ブロックのアドレスが示された管理情報を取得するステップと、
取得した管理情報から、各ブロックのアドレスを抽出するとともに、アドレスが連続したブロックを連続領域として集約することによって、各連続領域に対する開始アドレスとサイズとが示されたテーブルを生成するステップと、
生成したテーブルをもとに、開始アドレスからサイズで決定される終了アドレスまでにわたった連続領域ごとに、前記記憶装置に分割して記憶された第1のファームウエアプログラムを読み出すステップと、
読み出した第1のファームウエアプログラムによって、不揮発性メモリに記憶された第2のファームウエアプログラムを更新するステップと、
をコンピュータに実行させるためのプログラム。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020127025277A KR101421364B1 (ko) | 2010-02-26 | 2011-02-16 | 처리 장치 및 기입 방법 |
CN201180011299.5A CN102792283B (zh) | 2010-02-26 | 2011-02-16 | 处理装置和写入方法 |
EP11746996.5A EP2541421A4 (en) | 2010-02-26 | 2011-02-16 | PROCESSING DEVICE AND WRITING PROCESS |
US13/594,087 US20120317349A1 (en) | 2010-02-26 | 2012-08-24 | Processing device and writing method for writing a file to a storage medium |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010-043428 | 2010-02-26 | ||
JP2010043428 | 2010-02-26 | ||
JP2011022605A JP5728982B2 (ja) | 2010-02-26 | 2011-02-04 | 処理装置および書込方法 |
JP2011-022605 | 2011-02-04 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/594,087 Continuation US20120317349A1 (en) | 2010-02-26 | 2012-08-24 | Processing device and writing method for writing a file to a storage medium |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2011105023A1 true WO2011105023A1 (ja) | 2011-09-01 |
Family
ID=44506458
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2011/000847 WO2011105023A1 (ja) | 2010-02-26 | 2011-02-16 | 処理装置および書込方法 |
Country Status (6)
Country | Link |
---|---|
US (1) | US20120317349A1 (ja) |
EP (1) | EP2541421A4 (ja) |
JP (1) | JP5728982B2 (ja) |
KR (1) | KR101421364B1 (ja) |
CN (1) | CN102792283B (ja) |
WO (1) | WO2011105023A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109241012A (zh) * | 2018-10-12 | 2019-01-18 | 平安科技(深圳)有限公司 | 样本录入方法、装置、计算机设备及存储介质 |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013075338A1 (zh) * | 2011-11-25 | 2013-05-30 | 华为技术有限公司 | 一种机顶盒中呈现自定义内容的方法和机顶盒 |
JP2014194672A (ja) * | 2013-03-28 | 2014-10-09 | Fujitsu Ltd | メモリ制御装置、及びメモリ制御方法 |
US9372643B2 (en) | 2013-04-12 | 2016-06-21 | International Business Machines Corporation | Data set management |
US9274900B2 (en) * | 2013-12-03 | 2016-03-01 | Samsung Electronics Co., Ltd. | Method and apparatus for updating firmware |
US20160306623A1 (en) * | 2015-04-16 | 2016-10-20 | Aic Inc. | Control module of node and firmware updating method for the control module |
CN105740134B (zh) * | 2016-01-29 | 2018-03-20 | 浪潮(北京)电子信息产业有限公司 | 一种基于文件的测试方法及装置 |
CN106933970B (zh) * | 2017-02-10 | 2019-11-22 | 福州瑞芯微电子股份有限公司 | 一种快速烧录数据至ext分区的方法和装置 |
KR20190083051A (ko) | 2018-01-03 | 2019-07-11 | 에스케이하이닉스 주식회사 | 컨트롤러 및 그것의 동작방법 |
JP7367359B2 (ja) * | 2018-08-10 | 2023-10-24 | 株式会社デンソー | 車両用電子制御システム、ファイルの転送制御方法、ファイルの転送制御プログラム及び装置 |
KR20200116373A (ko) * | 2019-04-01 | 2020-10-12 | 에스케이하이닉스 주식회사 | 메모리 시스템, 메모리 컨트롤러 및 그 동작 방법 |
CN110874285B (zh) * | 2019-11-19 | 2022-06-21 | 厦门市美亚柏科信息股份有限公司 | 一种实现ext文件***的可还原写操作的方法 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004246787A (ja) | 2003-02-17 | 2004-09-02 | Seiko Epson Corp | 情報処理装置およびプログラム制御方法 |
JP2005235007A (ja) * | 2004-02-20 | 2005-09-02 | Sony Corp | データ記憶装置及び方法 |
JP2007193505A (ja) * | 2006-01-18 | 2007-08-02 | Nec Infrontia Corp | パーティション・サイズ可変ファームウェア組込装置とそのファームウェア更新方法 |
JP2007199985A (ja) * | 2006-01-26 | 2007-08-09 | Fuji Xerox Co Ltd | 不揮発性メモリの書き換え装置及び書き換え方法 |
JP2007226557A (ja) * | 2006-02-23 | 2007-09-06 | Hitachi Ltd | 計算機システム及び管理計算機とストレージシステム並びに記憶領域割当量制御方法 |
JP2007310533A (ja) * | 2006-05-17 | 2007-11-29 | Matsushita Electric Ind Co Ltd | 不揮発性記憶システム、不揮発性記憶装置、及びファイルデータ書き込み方法 |
JP2008146514A (ja) * | 2006-12-13 | 2008-06-26 | Canon Inc | 情報処理装置、情報処理装置の制御方法、および情報処理装置の制御プログラム |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5740435A (en) * | 1994-10-31 | 1998-04-14 | Sony Corporation | Data management apparatus and method for managing data of variable lengths recorded on a record medium |
JPH1185580A (ja) * | 1997-09-11 | 1999-03-30 | Matsushita Electric Ind Co Ltd | ファイル管理システム及びファイル管理方法 |
JP2914360B2 (ja) * | 1997-09-30 | 1999-06-28 | ソニー株式会社 | 外部記憶装置及びデータ処理方法 |
US7046805B2 (en) * | 2001-03-20 | 2006-05-16 | Digeo, Inc. | System and method for efficiently storing and processing multimedia content |
DE602004025556D1 (de) * | 2004-06-08 | 2010-04-01 | Freescale Semiconductor Inc | Aufrechterhaltung der Cachespeicherkoherenz zum direkten Zugriff (DMA), Abschluss einer Aufgabe, zur Synchronisierung |
US20070143559A1 (en) * | 2005-12-20 | 2007-06-21 | Yuichi Yagawa | Apparatus, system and method incorporating virtualization for data storage |
TW200809610A (en) * | 2006-08-03 | 2008-02-16 | Realtek Semiconductor Corp | Firmware update circuit of display device and the method thereof |
JPWO2009096180A1 (ja) * | 2008-01-30 | 2011-05-26 | パナソニック株式会社 | メモリコントローラ、不揮発性記憶装置、及び、不揮発性記憶システム |
US9678879B2 (en) * | 2008-05-29 | 2017-06-13 | Red Hat, Inc. | Set partitioning for encoding file system allocation metadata |
JP5364340B2 (ja) * | 2008-11-07 | 2013-12-11 | 株式会社ケーヒン | バックアップ方法及び装置並びに車両用電子制御装置 |
US7900090B2 (en) * | 2009-02-13 | 2011-03-01 | Oracle America, Inc. | Systems and methods for memory retention across resets |
US8665897B2 (en) * | 2009-10-26 | 2014-03-04 | Adc Dsl Systems, Inc. | Systems and methods for high-speed digital subscriber line software download |
WO2011083507A1 (en) * | 2010-01-05 | 2011-07-14 | Hitachi,Ltd. | Replication system and its control method |
US9003110B2 (en) * | 2010-01-13 | 2015-04-07 | International Business Machines Corporation | Dividing incoming data into multiple data streams and transforming the data for storage in a logical data object |
-
2011
- 2011-02-04 JP JP2011022605A patent/JP5728982B2/ja active Active
- 2011-02-16 EP EP11746996.5A patent/EP2541421A4/en not_active Withdrawn
- 2011-02-16 WO PCT/JP2011/000847 patent/WO2011105023A1/ja active Application Filing
- 2011-02-16 CN CN201180011299.5A patent/CN102792283B/zh active Active
- 2011-02-16 KR KR1020127025277A patent/KR101421364B1/ko active IP Right Grant
-
2012
- 2012-08-24 US US13/594,087 patent/US20120317349A1/en not_active Abandoned
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004246787A (ja) | 2003-02-17 | 2004-09-02 | Seiko Epson Corp | 情報処理装置およびプログラム制御方法 |
JP2005235007A (ja) * | 2004-02-20 | 2005-09-02 | Sony Corp | データ記憶装置及び方法 |
JP2007193505A (ja) * | 2006-01-18 | 2007-08-02 | Nec Infrontia Corp | パーティション・サイズ可変ファームウェア組込装置とそのファームウェア更新方法 |
JP2007199985A (ja) * | 2006-01-26 | 2007-08-09 | Fuji Xerox Co Ltd | 不揮発性メモリの書き換え装置及び書き換え方法 |
JP2007226557A (ja) * | 2006-02-23 | 2007-09-06 | Hitachi Ltd | 計算機システム及び管理計算機とストレージシステム並びに記憶領域割当量制御方法 |
JP2007310533A (ja) * | 2006-05-17 | 2007-11-29 | Matsushita Electric Ind Co Ltd | 不揮発性記憶システム、不揮発性記憶装置、及びファイルデータ書き込み方法 |
JP2008146514A (ja) * | 2006-12-13 | 2008-06-26 | Canon Inc | 情報処理装置、情報処理装置の制御方法、および情報処理装置の制御プログラム |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109241012A (zh) * | 2018-10-12 | 2019-01-18 | 平安科技(深圳)有限公司 | 样本录入方法、装置、计算机设备及存储介质 |
CN109241012B (zh) * | 2018-10-12 | 2024-02-02 | 平安科技(深圳)有限公司 | 样本录入方法、装置、计算机设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
US20120317349A1 (en) | 2012-12-13 |
EP2541421A1 (en) | 2013-01-02 |
CN102792283B (zh) | 2015-06-10 |
EP2541421A4 (en) | 2013-11-20 |
KR101421364B1 (ko) | 2014-07-18 |
JP2011198357A (ja) | 2011-10-06 |
JP5728982B2 (ja) | 2015-06-03 |
CN102792283A (zh) | 2012-11-21 |
KR20130000400A (ko) | 2013-01-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5728982B2 (ja) | 処理装置および書込方法 | |
US9128940B1 (en) | Method and apparatus for performing file-level restoration from a block-based backup file stored on a sequential storage device | |
JP5342302B2 (ja) | ファームウェア更新システム、ファームウェア配信サーバ、及びプログラム | |
US9946603B1 (en) | Mountable container for incremental file backups | |
US8856469B2 (en) | Apparatus and method for logging optimization using non-volatile memory | |
US9996429B1 (en) | Mountable container backups for files | |
JP4261800B2 (ja) | クライアントサーバー環境における差分バックアップシステムの管理方法 | |
US20180004606A1 (en) | Data backup using metadata mapping | |
US10078555B1 (en) | Synthetic full backups for incremental file backups | |
US8977802B2 (en) | Access device, information recording device, controller, real time information recording system, access method, and program | |
WO2011076577A1 (en) | Restore of full system backup and incremental backups using multiple simultaneous device streams | |
CN111221678B (zh) | Hbase数据备份/恢复***、方法、装置及电子设备 | |
US8862844B2 (en) | Backup apparatus, backup method and computer-readable recording medium in or on which backup program is recorded | |
US20220237089A1 (en) | Virtual machine backup method and apparatus based on cloud platform data center | |
CN113254394B (zh) | 一种快照处理方法、***、设备及存储介质 | |
CN114116023B (zh) | 操作***启动方法、设备、存储介质及计算机程序产品 | |
JP2005050024A (ja) | 計算機システムおよびプログラム | |
CN106709014B (zh) | 一种文件***转换方法及装置 | |
CN109213504B (zh) | 一种堆叠式文件***及其加载方法和升级方法 | |
US20050262033A1 (en) | Data recording apparatus, data recording method, program for implementing the method, and program recording medium | |
US20120151005A1 (en) | Image file download method | |
CN115576743B (zh) | 操作***恢复方法、装置、计算机设备和存储介质 | |
JP3896077B2 (ja) | 計算機システムおよびファイル管理方法 | |
CN115586872A (zh) | 一种容器镜像管理方法、装置、设备及存储介质 | |
US10860533B1 (en) | File size as an indicator of file properties |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 201180011299.5 Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11746996 Country of ref document: EP Kind code of ref document: A1 |
|
DPE1 | Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101) | ||
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2011746996 Country of ref document: EP |
|
ENP | Entry into the national phase |
Ref document number: 20127025277 Country of ref document: KR Kind code of ref document: A |