WO2009144833A1 - 情報処理システム - Google Patents

情報処理システム Download PDF

Info

Publication number
WO2009144833A1
WO2009144833A1 PCT/JP2008/061315 JP2008061315W WO2009144833A1 WO 2009144833 A1 WO2009144833 A1 WO 2009144833A1 JP 2008061315 W JP2008061315 W JP 2008061315W WO 2009144833 A1 WO2009144833 A1 WO 2009144833A1
Authority
WO
WIPO (PCT)
Prior art keywords
driver
read
data
command
write
Prior art date
Application number
PCT/JP2008/061315
Other languages
English (en)
French (fr)
Inventor
浦圭希
山本潤
Original Assignee
株式会社メディアロジック
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社メディアロジック filed Critical 株式会社メディアロジック
Publication of WO2009144833A1 publication Critical patent/WO2009144833A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/382—Information transfer, e.g. on bus using universal interface adapter
    • G06F13/385—Information transfer, e.g. on bus using universal interface adapter for adaptation of a particular data processing system to different peripheral devices
    • 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/0613—Improving I/O performance in relation to throughput
    • 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/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • 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

Definitions

  • the present invention relates to an information processing system including a personal computer and its external peripheral devices, and more particularly, to an information processing system that speeds up data transfer.
  • OS operating system
  • PC personal computer
  • the standard device driver is not optimized for each peripheral device, and a peripheral device that operates at a higher speed than the transfer speed controlled by the device driver (for example, an external HDD that reads / writes at a high speed). Even if it exists, standard device drivers limit speed. The application may also limit the speed.
  • USB mass storage driver adds information such as a command and status to each divided data.
  • the time for processing information such as commands and statuses is long (several hundreds of microseconds), which causes a reduction in data transfer speed.
  • Fig. 1 shows a functional block diagram of various drivers installed on the OS.
  • an application 51 a general-purpose disk driver 52, a USB mass storage driver 53, and a USB host controller driver 54 are function units mounted on the OS.
  • the application 51 makes a read or write request to the USB mass storage device 55 (for example, an external HDD) via various drivers.
  • the application 51 makes a write request and transfers data.
  • the application 51 makes a write request to the general-purpose disk driver 52 and transfers data.
  • the general-purpose disk driver 52 transfers this data to the USB mass storage driver 53 on the lower side.
  • the general-purpose disk driver 52 divides the data every 64 kB.
  • the USB mass storage driver 53 gives a command and a status to the data divided every 64 kB, and sequentially transfers the data to the USB host controller driver 54.
  • the USB host controller driver 54 sequentially transfers the command, data, and status to the USB mass storage device 55 using the USB bulk transfer method.
  • FIG. 2 is a conceptual diagram showing a configuration of data (bulk-only protocol) transferred by the general-purpose disk driver 52 and the USB mass storage driver 53.
  • the general-purpose disk driver 52 divides the data into 64 kB
  • the USB mass storage driver 53 assigns commands and statuses to the respective data sections and sequentially transfers them to the USB host controller driver 54.
  • the USB host controller driver 54 sequentially transfers the command, the data divided into 64 kB, and the status to the USB mass storage device 55.
  • the application 51 writes to the USB mass storage device 55.
  • the time for the USB mass storage driver 53, the USB host controller driver 54, and the USB mass storage device 55 to process the command and status is about 500 ⁇ sec in the environment of the USB 2.0 standard. Then, every time 64 kB of data is transferred, a delay of about 500 ⁇ sec occurs together with the command and status processing time. If the total amount of data to be transferred is 64 kB or more, the data transfer speed decreases.
  • the upper limit of the data transfer size of the USB mass storage driver 53 is 64 kB.
  • the data is divided every time, and the USB mass storage driver 53 gives a command and a status to each data part and sequentially transfers them to the USB host controller driver 54.
  • the application side may divide the data every 64 kB (for example, Windows (registered trademark) standard Explorer).
  • the data transfer speed between the PC and the peripheral device can be improved by using the above method.
  • some peripheral devices may be optimized to read and write data of a certain size or less.
  • the apparatus of Patent Document 1 and the conventional method cannot execute reading and writing at an optimum speed on the peripheral device side.
  • an object of the present invention is to provide an information processing system capable of improving the read / write speed on the peripheral device side in an information processing system for transferring a large amount of data.
  • An information processing system is an information processing system including a personal computer and peripheral devices connected to the personal computer, and the personal computer uses a plurality of commands to read or write requests to the peripheral devices.
  • a general-purpose driver that divides and sequentially transmits; a lower-side driver that is arranged on a lower side of the general-purpose driver; a cache memory that caches data corresponding to the read or write request; and the lower-side driver that requests a write
  • a command end for each command is returned to the upper side in a pseudo manner, and data transferred from the upper side is sequentially cached in the cache memory, and the data transfer size per command divided by the general-purpose driver Data larger than the upper limit of Issue a send size command to transfer the cache memory data to the peripheral device, and when the lower-level driver receives a read request, the general-purpose driver divides the upper limit of the data transfer size per command.
  • a control unit that performs a prediction process of issuing a command having a larger data transfer size, reading data from the peripheral device, and caching the data in the cache memory, and the peripheral device includes a read or a transfer transferred from the personal computer Command division that divides the command into a plurality of commands so as to read or write data smaller than the predetermined size when the write command reads or writes data larger than the predetermined size It has the part.
  • a command for reading and writing data larger than a predetermined size for example, 1 MB
  • a predetermined size for example, 1 MB
  • a plurality of commands are read so that data less than the predetermined size is read and written.
  • data is read and written in response to each command.
  • An information processing system is an information processing system comprising a personal computer and peripheral devices connected to the personal computer, wherein the personal computer issues a plurality of read or write requests to the peripheral devices.
  • a general-purpose driver that is divided into commands and sequentially transmitted; a low-order driver that is arranged on the low-order side of the general-purpose driver; a high-order driver that is arranged on the high-order side of the general-purpose driver;
  • a read / write request receiving unit that directly transfers a request from the upper driver to the lower driver, and a read or write request corresponding to the read or write request transferred from the upper driver in the lower driver.
  • a controller that issues commands and transfers data And when the read or write command transferred from the personal computer reads or writes data larger than a predetermined size, the peripheral device receives the data less than or equal to the predetermined size.
  • a command dividing unit that divides a plurality of commands so as to be read or written is provided.
  • the command dividing unit can change the predetermined size according to the specifications of the peripheral device.
  • the command division unit sets the division size according to the capacity of the cache provided on the peripheral device side as the specification of the peripheral device. Further, information such as manufacturer name and model number may be acquired. In this case, a database in which the manufacturer name, model number, and the like are associated with the optimum size is prepared in advance, and the optimum division size is set by referring to this database.
  • the lower driver may acquire information indicating the specifications of the peripheral device, and instruct the command dividing unit to set the change of the division size according to the specifications.
  • the read / write speed on the peripheral device side can be improved.
  • FIG. 2 is a block diagram showing a PC and an external HDD connected by a USB interface.
  • FIG. It is the conceptual diagram which showed the structure of the bulk only protocol. It is a block diagram in the case of providing a dedicated driver on the lower side of a driver that divides a command. It is a block diagram of PC and external HDD in this embodiment.
  • 3 is a functional block diagram of various drivers installed on the OS 11.
  • FIG. 3 is a functional block diagram illustrating a detailed configuration of an upper driver 151 and a lower driver 152.
  • FIG. 3 is a functional block diagram of various drivers installed on the OS 11.
  • FIG. 3 is a flowchart showing the operation of the upper driver 151.
  • 5 is a flowchart showing the operation of a lower driver 152.
  • 5 is a flowchart showing the operation of a lower driver 152. It is a flowchart which shows the operation
  • 4 is a flowchart showing the operation of the controller 22 of the external HDD 2. It is a block diagram which shows the other example which implement
  • Windows registered trademark
  • PCs PC equipped with Windows (registered trademark) XP
  • the type of OS, the type of connected device, and the interface are not limited.
  • FIG. 4 is a block diagram of the PC and the external HDD in this embodiment.
  • the PC 1 and the external HDD 2 are connected by a USB interface (I / F).
  • the PC 1 includes an application 101 that performs various processes and a driver 102 that includes various drivers for operating peripheral devices on an OS 11 that manages the whole.
  • the application 101 reads (reads) data stored in the external HDD 2 via the driver 102, the USB controller 12, and the USB I / F 13, and writes data to the external HDD 2 (write).
  • the controller 22 receives a read or write request via the USB I / F 21, and reads data stored in the HDD 23 or writes data to the HDD 23 in response thereto.
  • the controller 22 divides the command transferred from the PC 1 side, and reads and writes data to the HDD 23 with small data having a predetermined size (for example, 1 MB) or less (the present invention). Equivalent to the command splitting part).
  • FIG. 5 is a functional block diagram of various drivers and the external HDD 2 installed on the OS 11.
  • an application 101 a general-purpose disk driver 502, a USB mass storage driver 503, a USB host controller driver 504, an upper driver 151, and a lower driver 152 are functional units mounted on the OS 11.
  • these functional units are realized as software installed in the OS 11.
  • the application 101 makes a read or write request to the external HDD 2 via various drivers included in the driver 102.
  • FIG. 2 shows an example in which the application 101 makes a write request and transfers data.
  • the application 101 makes a write request to the higher-level driver 151 and transfers data to be written to the HDD 23 of the external HDD 2.
  • the upper driver 151 transfers this write request and data to the lower-level general-purpose disk driver 502, and uses the information indicating the write request from the application 101 and the amount of data as access information as the lower driver 152. Send to.
  • the access information transferred from the upper driver 151 to the lower driver 152 will be described in detail later.
  • the general-purpose disk driver 502 transfers the data received from the upper driver 151 to the USB mass storage driver 503. At this time, since the upper limit of the data transfer size of the USB mass storage driver 503 is 64 kB, the general-purpose disk driver 502 transfers the data to the USB mass storage driver 503 by dividing it into 64 kB.
  • the USB mass storage driver 503 assigns a command and a status to the data divided into 64 kB in order to perform data transfer by the bulk-only protocol (see FIG. 2), and sequentially transfers the data to the lower driver 152.
  • the lower driver 152 caches the data transferred from the USB mass storage driver 503 and transfers it to the USB host controller driver 504 at a predetermined timing.
  • the USB host controller driver 504 transfers this data to the external HDD 2 via the USB host controller 12 and the USB I / F 13 shown in FIG. In FIG. 5, the USB host controller 12, the USB I / F 13, and the USB I / F 21 are omitted. Since the lower-level driver 152 caches the data transferred from the USB mass storage driver 503 and transfers it to the USB host controller driver 504 as a certain amount of data (64 kB or more), the command and status are issued 1 (Or less than every 64 kB). Therefore, the delay due to the command and status processing time can be minimized.
  • the data transferred from the general-purpose disk driver 502 to the lower-level driver 152 is given a command and status every 64 kB. Since this transfer is memory (RAM) transfer on the OS, the external HDD 2 It is very fast compared to the data transfer rate to (depending on the RAM transfer rate).
  • RAM memory
  • the application 101 may directly transfer data to the USB mass storage driver 503.
  • the application 101 since the upper limit of the data transfer size of the USB mass storage driver 503 is 64 kB, the application 101 has 64 kB.
  • the data is divided for each transfer, and the USB mass storage driver 503 transfers the data with the command and status.
  • the lower-level driver 152 caches the data and then transfers the data to the lower-level side, the delay due to the command and status processing time can be minimized.
  • the controller 22 of the external HDD 2 receives the transferred command via the USB I / F 21.
  • the controller 22 divides this command into a predetermined size (for example, 1 MB or less), and sequentially writes data transferred from the upper side to the HDD 23. That is, when receiving a write command, the controller 22 determines whether or not data larger than 1 MB is to be written, and if it is 1 MB or less, executes the write command as it is, and if larger than 1 MB, The command is divided into a plurality of commands so that data of 1 MB or less is written. For example, if the transferred command is for writing 3 MB of data, the command is divided into three for writing 1 MB of data.
  • the controller 22 divides the data into data of 1 MB or less and writes the data, so the write speed on the device side (external HDD 2 side) Can be improved.
  • the size to be divided is not limited to 1 MB, and may be divided every 64 kB as described above. In this case, it is possible to improve the write speed even in a peripheral device optimized to write data of 64 kBB or less assuming that the PC side divides the data into a plurality of commands.
  • the size to be divided by the controller 22 is defined (firmware is set) so that the optimum writing speed is obtained for each device at the time of factory shipment or the like.
  • the size to be divided may be changed in the controller 22 or the lower driver 152.
  • the lower-level driver 152 acquires information such as the manufacturer name and model number of the device, and sets an optimal division size.
  • the manufacturer name, model number, etc., and the optimum size are associated with each other in advance in a database.
  • the lower driver 152 reads information such as the manufacturer name and model number, refers to the database, reads the optimum division size, and sets it in the controller 22.
  • the division size may be set according to the capacity of the cache provided on the device side. In any case, an optimal division size setting method may be taken according to the specifications of the device.
  • FIG. 6 is a functional block diagram showing detailed configurations of the upper driver 151 and the lower driver 152.
  • the upper driver 151 includes a read / write request receiving unit 155.
  • the lower driver 152 includes a controller (control program) 156, a database 157, cache memories 158A to 158C, a timer 159, and a command queue 160.
  • the database 157, the cache memories 158A to 158C, and the command queue 160 are realized by a RAM mounted on the PC 1.
  • the read / write request receiving unit 155 and the controller 156 are realized by software.
  • the read / write request receiving unit 155 receives a read or write request from the application 101.
  • the read / write request receiving unit 155 transfers this request to the lower-level general-purpose disk driver 502 and transmits the content of the request to the lower-level driver 152 as access information.
  • the read or write request is transferred to the lower-level driver 152 via the general-purpose disk driver 502 and the USB mass storage driver 503.
  • the access information includes LBA (Logical Block Addressing: HDD sector designation number), number of transfer blocks, transfer direction, and the like.
  • the number of transfer blocks indicates the capacity of transfer data.
  • the transfer direction is information indicating whether the transfer is from the lower side to the upper side (read) or from the upper side to the lower side (write).
  • This access information is stored in the database 157 of the lower driver 152 as a prediction database.
  • the controller 156 of the lower driver 152 receives a read or write request from the USB mass storage driver 503, the controller 156 refers to the database 157.
  • the prediction database By referring to the prediction database, the transfer data capacity can be predicted.
  • the controller 156 stores the read or write request received from the USB mass storage driver 503 in the database 157 as a history database.
  • the history database is used when the controller 156 creates and corrects the prediction database. That is, when a read or write request is received from the USB mass storage driver 503, the past history database is referenced, and the LBA, the number of transfer blocks, and the transfer direction are the same or partially match (similar) are assumed as the expected database. copy. Also, if there is a matching history, the history related to this (for example, one that can be determined to have been continuously requested based on the LBA and the number of transfer blocks) is collected and stored as one command in the prediction database. You can also.
  • the history database is stored in the database 157 and temporarily stored in the RAM of the PC 1, but this is stored in the OS 11 (PC 1 HDD) of the PC 1 or the HDD 23 of the external HDD 2. You may remember it. Thereby, the past history can be referred to even when the external HDD 2 is reconnected or the PC 1 is restarted.
  • the controller 156 can predict the transfer data capacity by referring to the number of transfer blocks in the prediction database. At this time, when the upper driver 151 transmits access information to the lower driver 152 and is stored in the prediction database, the transfer data capacity (all data to be written) can be predicted. When the controller 156 predicts that data transfer of 64 kB or more will be performed, the controller 156 stores the data transferred from the host side in any of the cache memories 158A to 158C.
  • the cache memories 158A to 158C are areas virtually formed on the RAM, and the number and capacity thereof are set by the controller 156.
  • the number and capacity of the cache memories can be set as appropriate, but in the example shown in the figure, it is assumed that three cache memories are prepared and each has a capacity of 4 MB. It is also possible to change the number and capacity of cache memories during operation.
  • the number and capacity of the cache memories may be set manually by the user, or may be changed as appropriate according to the operating state as will be described later.
  • the controller 156 sequentially stores the data transferred from the upper side in any one of the cache memories 158A to 158C.
  • the cache memory storing the write data becomes the write cache memory.
  • the controller 156 pseudo-ends the command to the USB mass storage driver 503 every time 64 kB data is received. Reply to Thereby, commands can be sequentially received from the USB mass storage driver 503, and a plurality of commands can be integrated.
  • the controller 156 makes a write request to the lower USB host controller driver 504 at a predetermined timing, and transfers the data in the write cache memory.
  • This predetermined timing includes a timing when the capacity of the write cache memory is full, a timing when data less than 64 kB is transferred from the upper side, a timing when a command for instructing data writing such as the FLUSH CACHE command is received, etc. It is.
  • the timer 159 may be used and writing may be performed at a timing determined by the timer 159 interrupt processing.
  • the controller 156 operates the timer 159 when receiving a write request from the USB mass storage driver 503. If the timer is used, it is possible to detect a state where no command is issued for a certain period of time and write the contents of the write cache memory. For this reason, it is possible to prevent file destruction or the like at the time of abnormality (when the USB cable is disconnected or the PC 1 is hung up).
  • the controller 156 When other processing is performed on the lower side below the USB host controller driver 504, the controller 156 once registers a write request in the command queue 160, and then writes when the lower side processing is free. Make a request.
  • FIG. 7 shows an example in which the application 101 makes a read request and transfers data.
  • FIG. 7 is a functional block diagram of various drivers installed on the OS 11.
  • symbol is attached
  • the application 101 makes a read request to the higher-level driver 151.
  • the higher-level driver 151 transfers this request to the lower-level general-purpose disk driver 502 and transmits a read request (access information) from the application 101 to the lower-level driver 152.
  • the general-purpose disk driver 502 transfers the read request received from the upper driver 151 to the USB mass storage driver 503. At this time, since the upper limit of the data transfer size of the USB mass storage driver 503 is 64 kB, the general-purpose disk driver 502 divides the read request every 64 kB. The USB mass storage driver 503 transfers the read request divided every 64 kB to the lower driver 152.
  • the lower driver 152 When the lower driver 152 receives a read request divided every 64 kB from the USB mass storage driver 503, the lower driver 152 predicts that a read request will be made continuously thereafter, and transfers a certain amount of data (for example, 3 MB). In such a manner, a prediction read request is sent to the USB host controller driver 504. Based on the predicted read request, the USB host controller driver 504 transfers a read command to the external HDD 2 via the USB host controller 12 and the USB I / F 13 so as to read the data of the 3 MB capacity from the HDD 23 of the HDD 2. To do.
  • the controller 22 of the external HDD 2 receives the read command transferred from the USB host controller driver 504 via the USB I / F 21.
  • the controller 22 divides a read command for 3 MB into a predetermined size (for example, 1 MB or less), and then performs a process of reading from the HDD 23. That is, when receiving a read command and data, the controller 22 determines whether or not the data larger than 1 MB is to be read. In this case, the command is divided into a plurality of commands so as to read data of 1 MB or less. For example, in the case of reading 3 MB data, this is divided into three commands for reading 1 MB data. Then, each divided command is executed, and the read data is sequentially transferred to the USB host controller driver 504.
  • the controller 22 divides the command into commands of 1 MB or less and sequentially reads, so that the read speed on the device side is improved. Can do.
  • the size to be divided is not limited to 1 MB, and may be divided every 64 kB as described above. As with writing, it is possible to improve the reading speed even in a peripheral device that is optimized to read data of 64 kB or less on the assumption that the PC side divides it into a plurality of commands. Similarly to the write operation, for example, at the time of factory shipment, the size to be divided by the controller 22 is specified (firmware is set) so that the read speed is optimal for each device.
  • information such as the device manufacturer name and model number may be acquired and the size to be divided may be changed, or the division size may be set according to the capacity of the cache provided on the device side. It may be set.
  • the data read in this way is sequentially transferred to the lower driver 152 and cached.
  • the lower driver 152 sequentially transfers the cached data to the upper side in accordance with the read request received from the USB mass storage driver 503.
  • the certain amount of capacity is 3 MB in the above example.
  • the transfer speed becomes slow. That is, since the transfer of the data cached on the upper side cannot be started until the end of the transfer is waited and the status of the normal end of the transfer is confirmed, the transfer speed becomes slow. In addition, it is necessary to increase the capacity of the read cache memory.
  • the controller 156 when the controller 156 first receives a read request of 64 kB (or less, it may be 32 kB, etc.), the controller 156 reads data having a capacity of a predetermined multiple (for example, 128 kB that is four times 32 kB). It is desirable to cache. When all the cached data is transferred to the upper side as a result, data having a capacity of a predetermined multiple (for example, 512 kB which is four times 128 kB) is read. In this way, by sequentially increasing the capacity of the data to be cached, it is possible to set a suitable capacity of the read cache memory while suppressing the transfer time.
  • a predetermined multiple for example, 128 kB that is four times 32 kB
  • the lower-level driver 152 reads a certain amount of capacity from the external HDD 2 at a time and caches it, thereby issuing commands and statuses to the external HDD 2 at a time (or by giving every 64 kB). Less). Therefore, the delay due to the command and status processing time can be minimized.
  • the data transferred from the lower-level driver 152 to the general-purpose disk driver 502 is divided into 64 kB, but since this transfer is a memory (RAM) transfer on the OS, the data transfer rate from the external HDD 2 is increased. It is very fast compared (depends on the RAM transfer rate).
  • the read / write request receiving unit 155 receives a read request from the application 101.
  • the read / write request receiving unit 155 transfers this request to the lower-level general-purpose disk driver 502 and transmits the content of the request to the lower-level driver 152 as access information.
  • the read request is transferred to the lower driver 152 via the general-purpose disk driver 502 and the USB mass storage driver 503. Note that read requests transferred from the general-purpose disk driver 502 and the USB mass storage driver 503 are divided into read requests every 64 kB.
  • the access information transmitted by the upper driver 151 is stored in the database 157 of the lower driver 152 as a prediction database.
  • the controller 156 of the lower driver 152 receives a read request from the USB mass storage driver 503, the controller 156 refers to the database 157.
  • the transfer data capacity (all data to be read) can be predicted.
  • the read request received from the USB mass storage driver 503 is stored in the database 157 as a history database.
  • the history database is used when the controller 156 creates and corrects the prediction database. That is, when a read request is received from the USB mass storage driver 503, a past history database is referred to, and an LBA, the number of transfer blocks, and a transfer direction that are the same or similar are transferred as a prediction database. If there is a matching history, the history related to this (for example, it can be determined that there is a continuous request based on the LBA and the number of transfer blocks) can be collected and stored as one command in the prediction database. .
  • the controller 156 can predict the transfer data capacity (all data to be read) by referring to the number of transfer blocks in the prediction database.
  • the controller 156 predicts that data transfer of 64 kB or more will be performed, it makes a read request to the USB host controller driver 504 to transfer data of 64 kB or more described in the prediction database, and the transferred data is transferred to the cache memory.
  • the controller 156 predicts that data transfer of 64 kB or more will be performed, it makes a read request to the USB host controller driver 504 to transfer data of 64 kB or more described in the prediction database, and the transferred data is transferred to the cache memory.
  • the cache memory that stores this data becomes the read cache memory.
  • the controller 156 sequentially transfers the data in the read cache memory in response to the read request transferred from the USB mass storage driver 503.
  • the upper driver 151 transmits access information for all data to be read, all data can be accurately cached in the read cache memory, but the application 101 directly reads the USB mass storage driver 503.
  • the history database may be referred to as described above.
  • a read request of 64 kB (or less) is received for the first time, it is predicted that a predetermined amount of data will be read from the start LBA continuous with the read request.
  • the predicted capacity is read, and when all predicted data is read from the higher-level driver, the start that continues to the predicted read It is predicted that a predetermined amount of data is read from the LBA.
  • data is read from the application 101.
  • FIG. 8A is a flowchart showing the operation of the upper driver 151.
  • the upper driver 151 receives a read / write request from the application, the upper driver 151 transmits the content of the request to the lower driver 152 as access information (s1).
  • the upper driver 151 transfers a read / write request to the lower side (general-purpose disk driver 502) (s2).
  • the access information is stored as a prediction database in the database 157 of the lower driver 152.
  • FIG. 8B is a diagram showing another operation of the upper driver 151
  • FIG. 14 is a functional block diagram showing a detailed configuration of the upper driver 151 and the lower driver 152 when this operation is performed. is there.
  • symbol is attached
  • the upper driver 151 determines whether or not the data capacity to be transferred is a predetermined amount or more (for example, 64 kB or more) (s5). If the amount is not greater than the predetermined amount, the contents of the request are transferred as access information to the lower-level driver 152 (s6), and the read / write request is transferred to the general-purpose disk driver 502 (s7). If it is equal to or larger than the predetermined amount, the read / write request is directly transferred to the controller 156 of the lower driver 152 as shown in FIG. 14 (s8). In this case, no read / write request is transferred to the general-purpose disk driver 502.
  • a predetermined amount or more for example, 64 kB or more
  • the data By transferring the read / write request directly to the controller 156, the data can be transferred to 64 kB without being divided. Further, since the general-purpose disk driver 502 and the USB mass storage driver 503 are not used, the processing time can be shortened and higher speed can be expected. If the data capacity to be transferred is not a predetermined amount or more, the USB mass storage driver 503 can process the data at a time, so that it is transferred to the lower level (general-purpose disk driver 502).
  • the request may be determined whether or not the request is a read request instead of the process of s5. If it is a read request, it is directly transferred to the controller 156 of the lower driver 152.
  • the controller 156 performs prediction processing when a read / write request is received from the upper side (USB mass storage driver). In particular, when reading, a certain amount of data capacity is read from the device side based on the prediction result and cached. Since a reply is sent from the top to the top, there is a possibility that a delay will occur. Therefore, at the time of a read request, this request is directly transferred from the higher-level driver 151 to the controller 156, and the transfer time (time until the start of transfer) can be shortened without performing prediction processing or cache processing.
  • the determination as to whether or not the request is a read request and the determination at s5 may be performed. Other determination methods may be used. For example, when it is important to read data from the device side in advance and cache it (when the application repeatedly accesses the same data contents), the request is transferred directly to the controller 156 even at the time of a read request. Without transferring to the lower side. When the upper driver 151 transfers a read / write request directly to the controller 156 of the lower driver 152, data is not accumulated in the cache memory. Therefore, if the application accesses the same file, it may be transferred to the lower side so that the data is accumulated in the cache memory.
  • the data can be accumulated even when a direct read / write request is received.
  • the copy since the copy is on the RAM, the copy speed is high, and the processing speed is not significantly reduced.
  • FIG. 9 is a flowchart showing the operation of the lower driver 152. This operation is started when a read request, write request, or other request is received from the higher-level driver (USB mass storage driver 503 or application 101).
  • the higher-level driver USB mass storage driver 503 or application 101.
  • the lower driver 152 performs access prediction (s11). Access prediction is performed by referring to access information and a history database transmitted from the higher-level driver 151. Further, the access prediction may be performed accurately as follows.
  • This prediction method is a method for performing access prediction by analyzing the file system of the external HDD 2.
  • the HDD file system is, for example, the FAT file system format
  • the recording position (sector) and size of each file can be determined by referring to the file management area. Therefore, when there is a read request from an upper application or driver, it is predicted that there is access to the file data corresponding to the recording position indicated by the request. In addition, by predicting that reading exceeding the file size will not be performed, unnecessary processing time is reduced without excessive reading.
  • this file management area is an area that is accessed frequently, it may be read and held in the read cache memory. Even when the external HDD 2 is not accessed each time, the access prediction processing time can be reduced by accessing the file management area held in the read cache memory.
  • This prediction method is a method of performing access prediction based on the type of target device to be connected (HDD in the above embodiment) and the file configuration (content type) of data to be transferred. It is. For example, when the device to be connected is a DVD-ROM and a DVD-Video medium is inserted in this device, reading is sequentially performed and no write request is made. Therefore, a prediction database is created so that data is cached to the full capacity of the read cache memory. When all the data cached in the read cache memory is read, the read cache memory can be used efficiently if the cache is immediately discarded and new data is cached.
  • the number and capacity of the cache memory it can be changed based on the device type. For example, when a DVD-Video medium is inserted as described above, no write request is made, so the number of read cache memories is increased and the capacity thereof is also set large. Conversely, when an unwritten DVD-R medium is inserted, a write request is mainly made, so the number of write cache memories is increased and the capacity thereof is set large.
  • This prediction method is an application example of prediction based on the above device type and content type, and determines a data transfer rate trend according to the device type, and access prediction based on this It is a technique to do. For example, when a multi-layer DVD medium is connected, a random access exceeding the boundary line of each layer has a very low transfer rate. Therefore, the prediction database is created by caching so that the frequency of access across the boundary lines of each layer is low.
  • the cache memory when changing the number and capacity of the cache memory, it can be changed based on the tendency of the device type and data transfer speed. For example, if the data transfer speed with the target device is slow (for example, about 4 MB / s as in USB MO (magneto-optical disk)), even if the cache memory capacity is increased and a large amount of data is cached, In the first place, since the data transfer speed is slow, it is not possible to improve the transfer speed. For this reason, when the data transfer rate with the target device is slow, the cache memory capacity is set to be small, and the RAM consumption is suppressed.
  • the data transfer speed with the target device is slow (for example, about 4 MB / s as in USB MO (magneto-optical disk))
  • USB MO magnetic-optical disk
  • This prediction method is performed once from a target device based on the read request predicted by the methods (1) to (3) above at the time of a read request.
  • This is a method of correcting (dividing) the prediction database so that data is not transferred to the network.
  • the prediction database is modified so that data having a predetermined capacity (for example, four times) of the read request is first cached.
  • the prediction database is corrected so as to cache data of a predetermined multiple capacity. Sequentially increasing the capacity of the data to be cached can reduce the transfer time.
  • prediction database correction processing may be performed when actually reading (during the processing of s29 described later).
  • the access prediction is performed as described above. Note that the number and capacity of the cache memory can be manually set by the user. In addition, the number of reserved cache memories for write and read can be set by the user. If the user wants to give priority to reading, the number of read cache memories is increased. If the user wants to give priority to writing, the number of write cache memories is increased.
  • the lower driver 152 determines the content of the request transmitted from the upper side (s12). If the request is not a read / write request, it is determined whether the target device is performing another read / write process (s13). If the process is not available, the request is transferred to the lower side (s14). . If other processing is being performed, this request is registered in the command queue (s15). If it is registered in the command queue, it can be executed when the process becomes available later. When a command for instructing writing of data in the write cache memory, such as the FLUSH CACHE command, is received, the data cached in the write cache memory at this time is transferred to the lower side.
  • a command for instructing writing of data in the write cache memory such as the FLUSH CACHE command
  • the lower driver 152 when the lower driver 152 determines that the request is a read / write request, the lower driver 152 refers to the cache memory (s16). Here, if the request from the upper side is a read request and the corresponding data is cached in the read cache memory or the write cache memory, it is transferred to the upper side, and the command end is returned (s17).
  • the lower driver 152 when the lower driver 152 determines that the request from the upper side is a continuous write request, the lower driver 152 continuously writes data in the write cache memory and returns a command end (s18). Thereafter, it is determined whether the capacity of the write cache memory is full (s19). If the capacity is not full, a timer is started (s20), and the operation ends.
  • s19 if the capacity of the write cache memory is full, it is determined whether or not the target device is performing another read or write process (s21). If the process is free, the write request is sent to the lower side. And cached data is transferred (s22). If other processing is being performed, this write request is registered in the command queue (s23). If it is registered in the command queue, it can be executed when the process becomes available later.
  • the lower driver 152 when the lower driver 152 determines that there is no cache data corresponding to the request from the upper side, the lower driver 152 refers to the prediction database and compares the request from the upper side with the content of the prediction database (s24). If the request from the upper side does not match the contents of the prediction database (the LBA and the number of transfer blocks do not match), the request is transferred to the lower side as it is (s25). At this time, if the lower side is performing other processing, it may be registered in the command queue and executed later.
  • the write cache memory is secured (s26).
  • the cache memory is secured as a write cache memory, and when the cache memory is all used for writing or reading, the contents of the cache memory updated most recently are erased.
  • the data in the write cache memory can also be used as the data in the read cache memory.
  • the read side driver memory is secured (s28). Similarly to the above, if there is a free cache memory, this is used as a read cache memory, and if there is no free space, the contents of the cache memory updated most recently are erased to secure the read cache memory.
  • a read request for the expected amount is transmitted to the lower side, and the data is cached in the read cache memory (s29).
  • the data cache may be divided into a plurality of times. In this case, the remaining read requests are registered in the command queue. By dividing the read request into multiple parts, the cached data can be transferred to the higher-level driver, while the next continuous read data can be cached in parallel with it, and the USB bus usage rate can be expected to improve. .
  • FIG. 10 is a flowchart showing the operation when there is a command end interrupt from the lower side.
  • the lower driver 152 determines whether or not the command end received from the lower side is a command indicating that the data cached in the write cache memory has been written (s31).
  • the write cache memory is changed to a read cache memory (s32).
  • the timing for changing the write cache memory to the read cache memory is not limited to this timing. Of course, as described above, it is possible to use the data in the write cache memory as the data in the read cache memory.
  • the lower driver 152 determines whether or not the command requires a completion report (transfer) to the upper side (s33). If necessary, the command end is returned to the upper side (s34).
  • the lower-level driver 152 refers to the command queue 160 and determines whether there is a queued command (s35). If there is a queued command, it is transferred to the lower side (s36).
  • FIG. 11 is a flowchart showing operations at the time of timer interrupt, driver initialization, and driver termination.
  • FIG. 1A is a flowchart showing a timer interrupt operation.
  • the lower driver 152 starts this operation when the timer expires.
  • the lower driver 152 checks whether data is cached in the write cache memory (s41). If it is cached, a write request is transmitted to the lower side, the data cached in the write cache memory is transferred to the lower side (s42), and the operation ends. If no data is cached in the write cache memory, the operation ends.
  • (B) is a flowchart showing the operation at the end of the driver. This operation is started when the external HDD 2 is disconnected when the PC is shut down.
  • the lower driver 152 transfers the history database to the external HDD 2 or the OS 11 and saves it (s51).
  • (C) in the figure is a flowchart showing the operation at the time of driver initialization. This operation is started when the PC 1 is restarted or the external HDD 2 is reconnected.
  • the lower driver 152 reads the history database from the external HDD 2 or the OS 11 and expands it in the RAM to construct the database 157 (s61).
  • FIG. 12 is a flowchart showing the operation of the controller 22 of the external HDD 2.
  • the controller 22 starts this operation when receiving a command from the PC 1 side. First, the controller 22 determines whether the received command reads or writes data larger than a predetermined size (1 MB) (s71). If it is equal to or smaller than the predetermined size (1 MB), the data is directly written to or read from the HDD 23 (s73).
  • this command is divided into a predetermined size (1 MB or less) (s 72), and sequentially written to or read from the HDD 23. (S73).
  • FIG. 13 is a functional block diagram illustrating an example of replacing the USB mass storage driver with a dedicated driver.
  • symbol is attached
  • a USB host controller driver 504 a general-purpose disk driver 502, and a dedicated USB mass storage class driver 171 connected to the application 101 are provided.
  • the dedicated USB mass storage class driver 171 replaces the conventional standard USB mass storage driver (see FIG. 1).
  • This dedicated USB mass storage class driver 171 has a built-in cache memory, as in the above embodiment, and caches data in response to read / write requests received from the upper side.
  • the operation of the dedicated mass storage class driver 171 is the same as the operation of the lower side driver shown in FIGS.
  • the dedicated USB mass storage class driver 171 caches the data in the cache memory and transfers the data.
  • the dedicated USB mass storage class driver 171 does not have an upper limit of the data transfer size of 64 kB, and can process a read / write request having a size larger than 64 kB. Therefore, since the application 101 or the general-purpose disk driver 501 can issue a read / write request without dividing it into 64 kB units, the delay of command and status processing can be reduced, and data transfer can be performed at high speed. Can be.

Abstract

　まとまった容量のデータを転送する情報処理システムにおいて、デバイス側のリード、ライト速度を向上させることができる情報処理システム。 　情報処理システムは、パーソナルコンピュータと、パーソナルコンピュータに接続される周辺機器と、からなる。周辺機器は、パーソナルコンピュータから転送されたリードまたはライトのコマンドを複数のコマンドに分割するコマンド分割部を備える。コマンド分割部は、パーソナルコンピュータから転送されたリードまたはライトのコマンドが所定のサイズよりも大きいデータをリードまたはライトするものであった場合、当該コマンドを所定のサイズ以下のデータをリードまたはライトするものとなるように複数のコマンドに分割する。

Description

情報処理システム
　この発明は、パーソナルコンピュータおよびその外付周辺機器からなる情報処理システムに関し、特に、データ転送を高速化する情報処理システムに関する。
　パーソナルコンピュータ（以下、ＰＣと言う。）のオペレーティングシステム（以下、ＯＳと言う。）が周辺機器を正常に認識、制御するためにはデバイスドライバというソフトウェアが必要になる。
　近年のＰＣに搭載されるＯＳには、標準のデバイスドライバが多数組み込まれている。したがって、ＯＳは、標準的な周辺機器が接続された場合には、標準のデバイスドライバを自動的に割り当て、接続された周辺機器を認識、制御する。
　しかし、標準のデバイスドライバは、各周辺機器に対して最適化されておらず、デバイスドライバが制御する転送速度よりも高速に動作する周辺機器（例えば高速にリード／ライトする外付ＨＤＤ等）が存在した場合であっても、標準のデバイスドライバが速度を制限してしまう。また、アプリケーションが速度を制限する場合もある。
　特に、一般的なＯＳであるＷｉｎｄｏｗｓ（登録商標）の場合、ＵＳＢマスストレージデバイス（外付ＨＤＤ等）を接続してデータ転送を行なうと、Ｗｉｎｄｏｗｓ（登録商標）標準搭載のアプリケーションまたはデバイスドライバが６４ｋＢ毎にデータを区分し、ＵＳＢマスストレージドライバは区分したデータ毎にコマンド、ステータス等の情報を付加する。このコマンド、ステータス等の情報を処理する時間は長く（数百μｓｅｃ）、データ転送速度が低下する要因となっていた。
　図１に、ＯＳ上に搭載されている各種ドライバの機能ブロック図を示す。同図において、アプリケーション５１、汎用ディスクドライバ５２、ＵＳＢマスストレージドライバ５３、およびＵＳＢホストコントローラドライバ５４は、ＯＳ上に搭載されている機能部である。
　アプリケーション５１は、各種ドライバを介してＵＳＢマスストレージデバイス５５（例えば外付ＨＤＤ）にリードまたはライトの要求を行う。同図においては、アプリケーション５１がライトの要求を行い、データ転送する例を示す。アプリケーション５１は、汎用ディスクドライバ５２に、ライト要求を行い、データを転送する。汎用ディスクドライバ５２は、このデータを下位側であるＵＳＢマスストレージドライバ５３に転送する。このとき、ＵＳＢマスストレージドライバ５３のデータ転送サイズの上限が６４ｋＢのため、汎用ディスクドライバ５２は６４ｋＢ毎にデータを分割する。ＵＳＢマスストレージドライバ５３は、この６４ｋＢ毎に分割されたデータにコマンド、ステータスを付与して、順次、ＵＳＢホストコントローラドライバ５４に転送する。ＵＳＢホストコントローラドライバ５４は、このコマンド、データ、ステータスをＵＳＢバルク転送方式にて、順次、ＵＳＢマスストレージデバイス５５へ転送する。
　図２は、汎用ディスクドライバ５２、およびＵＳＢマスストレージドライバ５３が転送するデータ（バルクオンリープロトコル）の構成を示した概念図である。同図に示すように、汎用ディスクドライバ５２は、６４ｋＢにデータを分割し、ＵＳＢマスストレージドライバ５３は、各データ部にコマンド、ステータスを付与し、順次、ＵＳＢホストコントローラドライバ５４に転送する。さらに、ＵＳＢホストコントローラドライバ５４は、このコマンド、６４ｋＢに分割されたデータ、ならびにステータスを順次、ＵＳＢマスストレージデバイス５５にデータを転送する。これにより、アプリケーション５１はＵＳＢマスストレージデバイス５５にライトを行う。
　ＵＳＢマスストレージドライバ５３、ＵＳＢホストコントローラドライバ５４、およびＵＳＢマスストレージデバイス５５がコマンドおよびステータスを処理する時間は、ＵＳＢ２．０規格の環境下では５００μｓｅｃ程度である。すると、６４ｋＢのデータを転送する毎にコマンド、ステータスの処理時間あわせて５００μｓｅｃ程度の遅延が発生することになり、転送する総データ量が６４ｋＢ以上であると、データ転送速度が低下する。
　また、図１に示すように、アプリケーション５１が直接ＵＳＢマスストレージドライバ５３にデータを転送する場合であっても、ＵＳＢマスストレージドライバ５３のデータ転送サイズの上限が６４ｋＢのため、アプリケーション５１は、６４ｋＢ毎にデータを分割し、ＵＳＢマスストレージドライバ５３は、各データ部にコマンド、ステータスを付与し、順次、ＵＳＢホストコントローラドライバ５４に転送する。なお、ドライバ側に６４ｋＢのデータ転送サイズの上限が存在しない場合で、かつアプリケーション５１が６４ｋＢより大きいデータの転送を行なう場合であってもアプリケーション側で６４ｋＢ毎にデータを分割する場合もある（例えばＷｉｎｄｏｗｓ（登録商標）標準搭載のエクスプローラなど）。
　そのため、いずれにしても、転送する総データ量が所定量以上となると、転送速度が低下するという問題が発生していた。
　一方で、従来、ホスト装置と下位側の装置との転送速度を向上させる手法として、複数のホスト装置から受信したコマンドを統合し、受信したデータをキャッシュしてからまとめてデータを転送することで、レスポンス性能を向上させるものが提案されている（例えば特許文献１参照）。
　しかし、特許文献１に記載の手法では、上位側（汎用ディスクドライバ５２やＵＳＢマスストレージドライバ５３）から順次コマンドが送信されてくる場合、コマンドを統合する機会が得られなかった。すなわち、上位側のドライバでは、下位側からコマンド終了を示す旨を受信した後に次のコマンドを送信するため、特許文献１に記載の手法のように、単に下位側でデータをキャッシュして複数のコマンドを受信するまで待機していては、次のコマンドを受信することができず、コマンド統合の機会を得ることができなかった。
　そこで、図３に示すように、コマンドを分割するドライバの下位側に専用のドライバ（下位側ドライバ１５２）を設けることが考えられる。下位側ドライバ１５２は、６４ｋＢのデータを受信する度に上位側に対してコマンド終了を擬似的に返信し、データをキャッシュする。この場合、下位側ドライバ１５２が、上位側から順次コマンドを受信し、６４ｋＢ以上のデータをまとめて転送（コマンドを生成）することができる。
特開２００６－３０９５７９号公報
　上記の手法を用いることで、ＰＣと周辺機器とのデータ転送速度を向上させることができる。しかし、周辺機器によっては、あるサイズ以下のデータをリード、ライトするように最適化されている場合がある。この場合、特許文献１の装置や、従来の手法では、周辺機器側の最適な速度でリード、ライトを実行することができなかった。
　そこで、この発明は、まとまった容量のデータを転送する情報処理システムにおいて、周辺機器側のリード、ライト速度を向上させることができる情報処理システムを提供することを目的とする。
　この発明の情報処理システムは、パーソナルコンピュータと、パーソナルコンピュータに接続される周辺機器と、からなる情報処理システムであって、前記パーソナルコンピュータは、前記周辺機器に対するリードまたはライトの要求を複数のコマンドに分割して順次送信する汎用ドライバと、前記汎用ドライバの下位側に配置される下位側ドライバと、前記リードまたはライトの要求に対応するデータをキャッシュするキャッシュメモリと、前記下位側ドライバがライトの要求を受信したとき、各コマンドに対するコマンド終了を擬似的に上位側に返信するとともに、上位側から転送されるデータを順次前記キャッシュメモリにキャッシュし、前記汎用ドライバが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記キャッシュメモリのデータを前記周辺機器に転送し、前記下位側ドライバがリードの要求を受信したとき、前記汎用ドライバが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記周辺機器からデータを読み出して前記キャッシュメモリにキャッシュする予測処理を行う制御部と、を備え、前記周辺機器は、前記パーソナルコンピュータから転送されたリードまたはライトのコマンドが所定のサイズよりも大きいデータをリードまたはライトするものであった場合、当該コマンドを前記所定のサイズ以下のデータをリードまたはライトするものとなるように複数のコマンドに分割するコマンド分割部を備えたことを特徴とする。
　このように、周辺機器側において、所定のサイズ（例えば１ＭＢ）よりも大きいデータをリード、ライトするコマンドが転送された場合、所定のサイズ以下のデータをリード、ライトするように、複数のコマンドに分割する。そして、各コマンドに対応してデータをリード、ライトする。これにより、ＰＣのドライバで複数コマンドを統合してまとまった容量のデータを転送する場合において、周辺機器側のリード、ライト速度を向上させることができる。
　また、この発明の情報処理システムは、パーソナルコンピュータと、パーソナルコンピュータに接続される周辺機器と、からなる情報処理システムであって、前記パーソナルコンピュータは、前記周辺機器に対するリードまたはライトの要求を複数のコマンドに分割して順次送信する汎用ドライバと、前記汎用ドライバの下位側に配置される下位側ドライバと、前記汎用ドライバの上位側に配置される上位側ドライバと、前記周辺機器に対するリードまたはライトの要求を前記上位側ドライバから前記下位側ドライバに直接転送するリード、ライト要求受信部と、前記下位側ドライバにおいて、前記上位側ドライバから転送された前記リードまたはライトの要求に応じたリードまたはライトのコマンドを発行してデータ転送を行う制御部と、を備え、前記周辺機器は、前記パーソナルコンピュータから転送されたリードまたはライトのコマンドが所定のサイズよりも大きいデータをリードまたはライトするものであった場合、当該コマンドを前記所定のサイズ以下のデータをリードまたはライトするものとなるように複数のコマンドに分割するコマンド分割部を備えたことを特徴とする。
　このように、コマンドを分割する汎用ドライバを回避するように、上位側ドライバと下位側ドライバを設けた場合であっても、周辺機器側で所定のサイズ以下のデータをリード、ライトするように複数のコマンドに分割するため、周辺機器側のリード、ライト速度を向上させることができる。
　また、上記発明において、前記コマンド分割部は、その周辺機器の仕様に応じて、前記所定のサイズを変更することも可能である。
　コマンド分割部は、周辺機器の仕様として、例えば、周辺機器側に設けられているキャッシュの容量に応じて分割サイズを設定する。また、メーカ名や型番等の情報を取得するようにしてもよい。この場合、メーカ名や型番等と最適なサイズとを予め対応づけたデータベースを用意しておき、このデータベースを参照することにより、最適な分割サイズを設定する。
　なお、上記下位側ドライバが周辺機器の仕様を示す情報を取得し、その仕様に応じて、コマンド分割部に分割サイズの変更を設定指示するようにしてもよい。
　この発明によれば、ＰＣ側からまとまった容量のデータを転送するコマンドが周辺機器に送信された場合において、周辺機器側のリード、ライト速度を向上させることができる。
ＵＳＢインタフェースで接続されるＰＣと外付ＨＤＤを表したブロック図である。 バルクオンリープロトコルの構成を示した概念図である。 コマンドを分割するドライバの下位側に専用のドライバを設ける場合のブロック図である。 本実施形態におけるＰＣと外付ＨＤＤのブロック図である。 ＯＳ１１上に搭載されている各種ドライバの機能ブロック図である。 上位側ドライバ１５１および下位側ドライバ１５２の詳細な構成を示す機能ブロック図である。 ＯＳ１１上に搭載されている各種ドライバの機能ブロック図である。 上位側ドライバ１５１の動作を示すフローチャートである。 下位側ドライバ１５２の動作を示すフローチャートである。 下位側ドライバ１５２の動作を示すフローチャートである。 コマンド終了割り込み時の動作を示すフローチャートである。 タイマ割り込み、初期化時、ドライバ終了時の動作を示すフローチャートである。 外付ＨＤＤ２のコントローラ２２の動作を示すフローチャートである。 本発明のデバイスコントローラを実現する他の例を示すブロック図である。 上位側ドライバ１５１および下位側ドライバ１５２が別の動作を行う場合の構成を示す機能ブロック図である。
符号の説明
１－ＰＣ
２－外付ＨＤＤ
　ＰＣに搭載されるＯＳで一般的に普及しているものとしてＷｉｎｄｏｗｓ（登録商標）がある。本実施形態では、Ｗｉｎｄｏｗｓ（登録商標）ＸＰを搭載しているＰＣに、ＵＳＢインタフェースの外付ＨＤＤを接続する場合について、図を用いて説明する。なお、本発明においてＯＳの種別や接続デバイスの種別、インタフェースを限定するものではない。
　図４は、本実施形態におけるＰＣと外付ＨＤＤのブロック図である。ＰＣ１と外付ＨＤＤ２はＵＳＢインタフェース（Ｉ／Ｆ）で接続される。ＰＣ１は、全体を管理するＯＳ１１上に、種々の処理を行うアプリケーション１０１、および周辺機器を動作させるための各種ドライバが含まれるドライバ１０２を搭載している。アプリケーション１０１は、ドライバ１０２、ＵＳＢコントローラ１２、およびＵＳＢＩ／Ｆ１３を介して外付ＨＤＤ２に記憶されているデータを読み出し（リード）、外付ＨＤＤ２にデータを書き込む（ライト）。
　外付ＨＤＤ２は、コントローラ２２がＵＳＢＩ／Ｆ２１を介してリードまたはライトの要求を受信し、これに応じてＨＤＤ２３に記憶されているデータをリード、またはＨＤＤ２３にデータをライトする。また、本実施形態の外付ＨＤＤ２は、コントローラ２２が、ＰＣ１側から転送されたコマンドを分割し、ＨＤＤ２３に所定のサイズ（例えば１ＭＢ）以下の小さいデータでリード、ライトするものである（本発明のコマンド分割部に相当する）。
　図５は、ＯＳ１１上に搭載されている各種ドライバおよび外付ＨＤＤ２の機能ブロック図である。同図において、アプリケーション１０１、汎用ディスクドライバ５０２、ＵＳＢマスストレージドライバ５０３、ＵＳＢホストコントローラドライバ５０４、上位側ドライバ１５１、および下位側ドライバ１５２は、ＯＳ１１上に搭載されている機能部である。実際には、これらの機能部は、ＯＳ１１にインストールされるソフトウェアとして実現する。
　アプリケーション１０１は、ドライバ１０２に含まれる各種ドライバを介して外付ＨＤＤ２にリードまたはライトの要求を行う。同図においては、アプリケーション１０１がライトの要求を行い、データ転送する例を示す。
　アプリケーション１０１は、上位側ドライバ１５１に、ライト要求を行い、外付ＨＤＤ２のＨＤＤ２３に書き込むべきデータを転送する。上位側ドライバ１５１は、このライト要求およびデータを下位側である汎用ディスクドライバ５０２に転送するとともに、アプリケーション１０１からライト要求があった旨、およびそのデータ量を示す情報をアクセス情報として下位側ドライバ１５２に送信する。上位側ドライバ１５１が下位側ドライバ１５２に転送するアクセス情報については後に詳しく述べる。
　汎用ディスクドライバ５０２は、上位側ドライバ１５１から受信したデータをＵＳＢマスストレージドライバ５０３に転送する。このとき、ＵＳＢマスストレージドライバ５０３のデータ転送サイズの上限が６４ｋＢであるため、汎用ディスクドライバ５０２は、６４ｋＢ毎に分割してＵＳＢマスストレージドライバ５０３にデータを転送する。
　ＵＳＢマスストレージドライバ５０３は、バルクオンリープロトコル（図２参照）によりデータ転送を行うため、この６４ｋＢに分割されたデータにコマンド、ステータスを付与し、順次、下位側ドライバ１５２に転送する。
　下位側ドライバ１５２は、ＵＳＢマスストレージドライバ５０３から転送されたデータをキャッシュし、所定のタイミングでＵＳＢホストコントローラドライバ５０４に転送する。ＵＳＢホストコントローラドライバ５０４は、図４で示したＵＳＢホストコントローラ１２、ＵＳＢＩ／Ｆ１３を介して、このデータを外付ＨＤＤ２に転送する。なお、図５においてはＵＳＢホストコントローラ１２、ＵＳＢＩ／Ｆ１３、およびＵＳＢＩ／Ｆ２１を省略している。下位側ドライバ１５２が、ＵＳＢマスストレージドライバ５０３から転送されたデータをキャッシュし、ある程度の容量（６４ｋＢ以上）のデータとして、まとめてＵＳＢホストコントローラドライバ５０４に転送するため、コマンド、ステータスの発行が１度で（あるいは６４ｋＢ毎に付与するよりも少なくて）済む。したがって、コマンド、ステータスの処理時間による遅延が最小限で済む。なお、汎用ディスクドライバ５０２から下位側ドライバ１５２まで転送されるデータは、６４ｋＢ毎にコマンド、ステータスが付与されているが、この転送は、ＯＳ上のメモリ（ＲＡＭ）転送であるため、外付ＨＤＤ２へのデータ転送速度に比較して非常に高速である（ＲＡＭ転送速度に依存する）。
　また、この実施形態において、アプリケーション１０１が直接ＵＳＢマスストレージドライバ５０３にデータ転送する場合があるが、上記と同様、ＵＳＢマスストレージドライバ５０３のデータ転送サイズの上限が６４ｋＢであるため、アプリケーション１０１が６４ｋＢ毎に分割してデータを転送し、ＵＳＢマスストレージドライバ５０３がコマンド、ステータスを付与したデータを転送する。この場合においても、下位側ドライバ１５２がデータをキャッシュしてから下位側にデータ転送するため、コマンド、ステータスの処理時間による遅延が最小限で済む。
　外付ＨＤＤ２のコントローラ２２は、ＵＳＢＩ／Ｆ２１を介して、上記転送されたコマンドを受信する。ここで、コントローラ２２は、このコマンドを所定のサイズ（例えば１ＭＢ以下）に分割し、上位側から転送されるデータを順次、ＨＤＤ２３にライトする処理を行う。すなわち、コントローラ２２は、ライトのコマンドを受信したとき、１ＭＢよりも大きいデータをライトするものであるか否かを判断し、１ＭＢ以下であればそのままライトコマンドを実行し、１ＭＢよりも大きい場合、当該コマンドを１ＭＢ以下のデータをライトするものとなるように複数のコマンドに分割する。例えば転送されたコマンドが３ＭＢのデータをライトするものであった場合、これを１ＭＢのデータをライトするコマンドに３分割する。これにより、外付ＨＤＤ２が１ＭＢ以下のデータをライトするように最適化されている場合において、コントローラ２２が１ＭＢ以下のデータに分割してライトするため、デバイス側（外付ＨＤＤ２側）のライト速度を向上させることができる。
　なお、分割するサイズは１ＭＢに限らず、上記のように６４ｋＢ毎に分割してもよい。この場合、ＰＣ側が複数コマンドに分割することを想定して、６４ｋＢＢ以下のデータをライトするように最適化されている周辺機器においても、ライト速度を向上させることができる。例えば、工場出荷時等において、デバイス毎に最適なライト速度となるように、コントローラ２２が分割するサイズを規定する（ファームウェアを設定しておく）。
　また、上記コントローラ２２や下位側ドライバ１５２において、分割するサイズを変更するようにしてもよい。例えば、下位側ドライバ１５２が、そのデバイスのメーカ名や型番等の情報を取得し、最適な分割サイズを設定する。この場合、メーカ名や型番等と最適なサイズとを予め対応づけてデータベース化しておく。下位側ドライバ１５２は、メーカ名や型番等の情報を取得して当該データベースを参照することにより、最適な分割サイズを読み出し、これをコントローラ２２に設定する。
　また、デバイス側に設けられているキャッシュの容量に応じて分割サイズを設定してもよい。いずれにしても、デバイスの仕様に応じて、最適な分割サイズの設定方法をとればよい。
　次に、上位側ドライバ１５１および下位側ドライバ１５２の詳細な動作について説明する。図６は、上位側ドライバ１５１および下位側ドライバ１５２の詳細な構成を示す機能ブロック図である。なお、図５と共通する構成については同一の符号を付し、その説明を省略する。上位側ドライバ１５１は、リード、ライト要求受信部１５５を備えている。また、下位側ドライバ１５２は、コントローラ（制御プログラム）１５６、データベース１５７、キャッシュメモリ１５８Ａ～１５８Ｃ、タイマ１５９、およびコマンドキュー１６０を備えている。なお、データベース１５７やキャッシュメモリ１５８Ａ～１５８Ｃ、コマンドキュー１６０は、ＰＣ１に搭載されているＲＡＭにより実現される。また、リード、ライト要求受信部１５５やコントローラ１５６は、ソフトウェアにより実現される。
　リード、ライト要求受信部１５５は、アプリケーション１０１からリードまたはライトの要求を受信する。リード、ライト要求受信部１５５は、この要求を下位側の汎用ディスクドライバ５０２に転送するとともに、要求の内容をアクセス情報として下位側ドライバ１５２に送信する。リードまたはライトの要求は、汎用ディスクドライバ５０２、およびＵＳＢマスストレージドライバ５０３を介して下位側ドライバ１５２に転送される。
　アクセス情報には、ＬＢＡ（Logical Block Addressing：ＨＤＤのセクタ指定番号）、転送ブロック数、転送方向などが記載されている。転送ブロック数は転送データの容量を示す。転送方向は、下位側から上側への転送（リード）であるか、上位側から下位側への転送（ライト）であるかを示す情報である。
　このアクセス情報は、下位側ドライバ１５２のデータベース１５７に予想データベースとして記憶される。下位側ドライバ１５２のコントローラ１５６は、ＵＳＢマスストレージドライバ５０３からリードまたはライトの要求を受信したとき、データベース１５７を参照する。予想データベースを参照することで、転送データ容量を予測することができる。
　また、コントローラ１５６は、ＵＳＢマスストレージドライバ５０３から受信したリードまたはライトの要求を履歴データベースとしてデータベース１５７に記憶する。履歴データベースは、コントローラ１５６が予想データベースを作成、修正する場合に用いられる。すなわち、ＵＳＢマスストレージドライバ５０３からリードまたはライトの要求を受信したとき、過去の履歴データベースを参照し、ＬＢＡ、転送ブロック数、転送方向が同一または一部一致する（類似する）ものを予想データベースとして転記する。また、一致する履歴が存在した場合、これと関連する履歴（例えばＬＢＡと転送ブロック数に基づいて、連続して要求があったと判断できるもの）をまとめ、１つのコマンドとして予想データベースに記憶することもできる。なお、履歴データベースは、同図においてはデータベース１５７内に記憶され、ＰＣ１のＲＡＭ上に一時的に記憶されているが、これをＰＣ１のＯＳ１１（ＰＣ１のＨＤＤ）上、または外付ＨＤＤ２のＨＤＤ２３に記憶しておいてもよい。これにより、外付ＨＤＤ２を再接続したときやＰＣ１を再起動したときにおいても過去の履歴を参照することができる。
　コントローラ１５６は、ＵＳＢマスストレージドライバ５０３から転送された要求がライトの要求であれば、予想データベースの転送ブロック数を参照することで、転送データ容量を予測することができる。このとき、上位側ドライバ１５１が下位側ドライバ１５２に、アクセス情報を送信して予想データベースに記憶されている場合は、転送データ容量（ライトすべき全データ）を予測することができる。コントローラ１５６は、６４ｋＢ以上のデータ転送が行われると予測した場合、上位側から転送されたデータをキャッシュメモリ１５８Ａ～１５８Ｃのいずれかに格納する。
　キャッシュメモリ１５８Ａ～１５８Ｃは、ＲＡＭ上に仮想的に形成されたエリアであり、その数および容量はコントローラ１５６が設定する。キャッシュメモリの数および容量は、適宜設定し得るが、同図の例では、３つのキャッシュメモリを用意し、それぞれ４ＭＢの容量を設定しているものとする。なお、動作中にキャッシュメモリの数および容量を変化させることも可能である。キャッシュメモリの数および容量はユーザが手動で設定するようにしてもよいし、後述のように動作状態に応じて適宜変化させるようにしてもよい。
　上記のように、コントローラ１５６は、キャッシュメモリ１５８Ａ～１５８Ｃのうち、いずれか１つに上位側から転送されたデータを順次、格納する。このライト用のデータを格納したキャッシュメモリがライト用キャッシュメモリとなる。ただし、ＵＳＢマスストレージドライバ５０３から６４ｋＢ毎にコマンド、ステータスが付与されてデータ転送されるため、コントローラ１５６は、６４ｋＢのデータを受信する度に、ＵＳＢマスストレージドライバ５０３に対してコマンド終了を擬似的に返信する。これにより、ＵＳＢマスストレージドライバ５０３から順次コマンドを受信することができ、複数のコマンドを統合することができる。
　コントローラ１５６は、所定のタイミングで下位側のＵＳＢホストコントローラドライバ５０４に対し、ライト要求を行い、ライト用キャッシュメモリのデータを転送する。この所定のタイミングは、ライト用キャッシュメモリの容量が一杯になったタイミング、上位側から６４ｋＢ未満のデータが転送されたタイミング、ＦＬＵＳＨ　ＣＡＣＨＥコマンドのようなデータ書き込みを指示するコマンドを受信したタイミング、等である。
　また、タイマ１５９を使用し、タイマ１５９の割り込み処理により決定されるタイミングで書き込みを行ってもよい。この場合、コントローラ１５６は、ＵＳＢマスストレージドライバ５０３からライト要求を受信したときにタイマ１５９を作動させる。タイマを使用すれば、一定時間コマンド発行が無い状態を検出して、ライト用キャッシュメモリの内容を書き込みすることができる。そのため、異常時（ＵＳＢケーブルが切断されたり、ＰＣ１がハングアップした場合）のファイル破壊等を防止することができる。
　なお、ＵＳＢホストコントローラドライバ５０４以下の下位側において他の処理を行っている場合、コントローラ１５６は、一旦ライト要求をコマンドキュー１６０に登録しておき、後に下位側の処理が空いているときにライト要求を行う。
　以上のようにして、アプリケーション１０１からデータのライトが行われる。次に、図７において、アプリケーション１０１がリードの要求を行い、データ転送する例を示す。
　図７は、ＯＳ１１上に搭載されている各種ドライバの機能ブロック図である。なお、図５と共通する構成については同一の符号を付し、その説明を省略する。
　まず、アプリケーション１０１は、上位側ドライバ１５１に、リード要求を行う。上位側ドライバ１５１は、この要求を下位側である汎用ディスクドライバ５０２に転送するとともに、アプリケーション１０１からリード要求があった旨（アクセス情報）を下位側ドライバ１５２に送信する。
　汎用ディスクドライバ５０２は、上位側ドライバ１５１から受信したリード要求をＵＳＢマスストレージドライバ５０３に転送する。このとき、ＵＳＢマスストレージドライバ５０３のデータ転送サイズの上限が６４ｋＢであるため、汎用ディスクドライバ５０２は、６４ｋＢ毎にリード要求を分割する。ＵＳＢマスストレージドライバ５０３は、下位側ドライバ１５２に６４ｋＢ毎に分割されたリード要求を転送する。
　下位側ドライバ１５２は、ＵＳＢマスストレージドライバ５０３から６４ｋＢ毎に分割されたリード要求を受信した場合、この後連続してリード要求がされると予測し、ある程度の容量（例えば３ＭＢ）のデータを転送するように、ＵＳＢホストコントローラドライバ５０４に予測リード要求を行う。ＵＳＢホストコントローラドライバ５０４は、この予測リード要求に基づいて、上記３ＭＢの容量のデータをＨＤＤ２のＨＤＤ２３から読み出すように、ＵＳＢホストコントローラ１２、ＵＳＢＩ／Ｆ１３を介して外付ＨＤＤ２にリードのコマンドを転送する。
　外付ＨＤＤ２のコントローラ２２は、ＵＳＢＩ／Ｆ２１を介して、ＵＳＢホストコントローラドライバ５０４から転送されたリードのコマンドを受信する。ここで、コントローラ２２は、３ＭＢ分のリードのコマンドを所定のサイズ（例えば１ＭＢ以下）に分割してから、ＨＤＤ２３からリードする処理を行う。すなわち、コントローラ２２は、リードのコマンドおよびデータを受信したとき、１ＭＢよりも大きいデータをリードするものであるか否かを判断し、１ＭＢ以下であればそのままリードコマンドを実行し、１ＭＢよりも大きい場合、当該コマンドを１ＭＢ以下のデータをリードするものとなるように複数のコマンドに分割する。例えば３ＭＢのデータをリードするものであった場合、これを１ＭＢのデータをリードするコマンドに３分割する。そして、分割した各コマンドを実行し、上記ＵＳＢホストコントローラドライバ５０４に、リードしたデータを順次転送する。
　これにより、外付ＨＤＤ２が１ＭＢ以下のデータをリードするように最適化されている場合において、コントローラ２２が１ＭＢ以下のコマンドに分割して順次リードを行うため、デバイス側のリード速度を向上させることができる。
　なお、分割するサイズは１ＭＢに限らず、上記のように６４ｋＢ毎に分割してもよい。ライトと同様、ＰＣ側が複数コマンドに分割することを想定して、６４ｋＢ以下のデータをリードするように最適化されている周辺機器においても、リード速度を向上させることができる。また、ライトと同様、例えば工場出荷時等において、デバイス毎に最適なリード速度となるように、コントローラ２２が分割するサイズを規定する（ファームウェアを設定しておく）。
　また、前述のように、デバイスのメーカ名や型番等の情報を取得して、分割するサイズを変更するようにしてもよいし、デバイス側に設けられているキャッシュの容量に応じて分割サイズを設定してもよい。
　このようにしてリードされたデータが下位側ドライバ１５２に順次転送され、キャッシュされる。下位側ドライバ１５２は、ＵＳＢマスストレージドライバ５０３から受信したリード要求にしたがって、キャッシュしたデータを順次、上位側に転送する。ここで、ある程度の容量とは、上記の例では３ＭＢとしたが、転送容量が大きすぎる場合は、転送速度が遅くなる。すなわち、その転送の終了を待ち、その転送の正常終了のステータスを確認するまで、上位側にキャッシュしたデータの転送を開始できないため、転送速度が遅くなる原因となる。また、リード用キャッシュメモリの容量を大きくする必要がある。
　そのため、コントローラ１５６は、最初に６４ｋＢ（あるいはそれ以下、３２ｋＢ等であってもよい。）のリード要求を受信したとき、その所定倍（例えば３２ｋＢの４倍である１２８ｋＢ）の容量のデータを読み出してキャッシュすることが望ましい。このキャッシュしたデータが、結果的に全て上位側に転送される場合、さらに所定倍（例えば１２８ｋＢの４倍である５１２ｋＢ）の容量のデータを読み出す。このように、順次、キャッシュするデータの容量を大きくすることで、転送時間を抑えながら、好適なリード用キャッシュメモリの容量に設定することができる。
　このように、下位側ドライバ１５２が、外付ＨＤＤ２からある程度の容量を一度に読み出し、キャッシュしておくことで、外付ＨＤＤ２に対するコマンド、ステータスの発行が１度で（あるいは６４ｋＢ毎に付与するよりも少なくて）済む。したがって、コマンド、ステータスの処理時間による遅延が最小限で済む。なお、下位側ドライバ１５２から汎用ディスクドライバ５０２まで転送されるデータは、６４ｋＢに分割されるが、この転送は、ＯＳ上のメモリ（ＲＡＭ）転送であるため、外付ＨＤＤ２からのデータ転送速度に比較して非常に高速である（ＲＡＭ転送速度に依存する）。
　図６を参照して、上記リード要求発生時の上位側ドライバ１５１および下位側ドライバ１５２の詳細な動作について説明する。リード、ライト要求受信部１５５は、アプリケーション１０１からリードの要求を受信する。リード、ライト要求受信部１５５は、この要求を下位側の汎用ディスクドライバ５０２に転送するとともに、要求の内容をアクセス情報として下位側ドライバ１５２に送信する。リード要求は、汎用ディスクドライバ５０２、およびＵＳＢマスストレージドライバ５０３を介して下位側ドライバ１５２に転送される。なお、汎用ディスクドライバ５０２、およびＵＳＢマスストレージドライバ５０３から転送されるリード要求は６４ｋＢ毎のリード要求に分割されている。
　上位側ドライバ１５１が送信したアクセス情報は、下位側ドライバ１５２のデータベース１５７に予想データベースとして記憶される。下位側ドライバ１５２のコントローラ１５６は、ＵＳＢマスストレージドライバ５０３からリード要求を受信したとき、データベース１５７を参照する。予想データベースを参照することで、転送データ容量（リードすべき全データ）を予測することができる。
　また、ＵＳＢマスストレージドライバ５０３から受信したリード要求を履歴データベースとしてデータベース１５７に記憶する。履歴データベースは、コントローラ１５６が予想データベースを作成、修正する場合に用いられる。すなわち、ＵＳＢマスストレージドライバ５０３からリード要求を受信したとき、過去の履歴データベースを参照し、ＬＢＡ、転送ブロック数、転送方向が同一または類似するものを予想データベースとして転記する。一致する履歴が存在する場合、これと関連する履歴（例えばＬＢＡと転送ブロック数に基づいて、連続して要求があったと判断できるもの）をまとめ、１つのコマンドとして予想データベースに記憶することもできる。
　コントローラ１５６は、ＵＳＢマスストレージドライバ５０３からリード要求を受信したとき、予想データベースの転送ブロック数を参照することで、転送データ容量（リードすべき全データ）を予測することができる。コントローラ１５６は、６４ｋＢ以上のデータ転送が行われると予測した場合、ＵＳＢホストコントローラドライバ５０４に予想データベースに記載された６４ｋＢ以上のデータを転送するようにリード要求を行い、転送されたデータをキャッシュメモリ１５８Ａ～１５８Ｃのいずれかに格納する。
　このデータを格納したキャッシュメモリがリード用キャッシュメモリとなる。　コントローラ１５６は、ＵＳＢマスストレージドライバ５０３から転送されるリード要求に応じて、順次リード用キャッシュメモリのデータを転送する。なお、上位側ドライバ１５１が、リードすべき全データのアクセス情報を送信した場合は、リード用キャッシュメモリに正確に全データをキャッシュすることができるが、アプリケーション１０１が直接ＵＳＢマスストレージドライバ５０３にリード要求を行う場合や上位側ドライバ１５１がリードすべき全データのアクセス情報を送信しない場合は、コントローラ１５６が上位側からリード要求を受信したときに予想データベースを作成する必要がある。この場合、上記のように履歴データベースを参照すればよい。例えば、最初に６４ｋＢ（あるいはそれ以下）のリード要求を受信したとき、そのリード要求に連続した開始ＬＢＡから、所定倍の容量のデータがリードされるように予測する。この予測した開始ＬＢＡに対するリード要求を上位側のドライバから受信した場合、その予測容量分のリードを行い、予測したデータが全て上位側のドライバからリードされた場合、さらにその予測リードに連続する開始ＬＢＡから、さらに所定倍の容量のデータがリードされるように予測する。
　以上のようにして、アプリケーション１０１からデータのリードが行われる。
　次に、上位側ドライバ１５１、下位側ドライバ１５２、および外付ＨＤＤ２のコントローラ２２の動作をフローチャートを用いて説明する。図８（Ａ）は、上位側ドライバ１５１の動作を示すフローチャートである。上位側ドライバ１５１は、アプリケーションからリード、ライト要求を受信したとき、この要求の内容をアクセス情報として下位側ドライバ１５２に送信する（ｓ１）。また、上位側ドライバ１５１は、下位側（汎用ディスクドライバ５０２）にリード、ライト要求を転送する（ｓ２）。アクセス情報は、下位側ドライバ１５２のデータベース１５７に予想データベースとして記憶される。
　なお、上位側ドライバ１５１は、図８（Ｂ）および図１４に示すような動作を行うこともできる。図８（Ｂ）は、上位側ドライバ１５１の別の動作を示す図であり、図１４は、この動作を行う場合の上位側ドライバ１５１および下位側ドライバ１５２の詳細な構成を示す機能ブロック図である。なお、図６と共通する構成については、同一の符号を付し、その説明を省略する。
　図８（Ｂ）において、上位側ドライバ１５１は、アプリケーションからリード、ライト要求を受信したとき、転送されるデータ容量が所定量以上（例えば６４ｋＢ以上）であるか否かを判断する（ｓ５）。所定量以上でなければ要求の内容をアクセス情報として下位側ドライバ１５２に転送し（ｓ６）、汎用ディスクドライバ５０２にリード、ライト要求を転送する（ｓ７）。所定量以上であれば、図１４に示すように、リード、ライト要求を直接下位側ドライバ１５２のコントローラ１５６に転送する（ｓ８）。この場合、汎用ディスクドライバ５０２にはリード、ライト要求を転送しない。リード、ライト要求を直接コントローラ１５６に転送することで、６４ｋＢにデータが分割されることなく転送することができる。また、汎用ディスクドライバ５０２、およびＵＳＢマスストレージドライバ５０３を介さないため、処理時間を短縮することができ、より高速化を期待できる。転送されるデータ容量が所定量以上でなければ、ＵＳＢマスストレージドライバ５０３が一度にデータを処理することができるため、下位側（汎用ディスクドライバ５０２）に転送するようにしている。
　なお、ｓ５の処理に換えて、リード要求であるか否かの判断としてもよい。リード要求であれば直接下位側ドライバ１５２のコントローラ１５６に転送する。コントローラ１５６では、上位側（ＵＳＢマスストレージドライバ）からリード、ライト要求を受信したときに予測処理を行うため、特に、リード時には予測結果に基づいてある程度のデータ容量をデバイス側から読み出し、キャッシュしてから上位側に返信するため、その分の遅延が生じる可能性がある。そのため、リード要求時には上位側ドライバ１５１からコントローラ１５６に直接この要求を転送し、予測処理やキャッシュ処理を行わず、転送時間（転送開始までの時間）を短縮することができる。
　なお、リード要求であるか否かの判断とｓ５の判断とをいずれか１つ行うようにしてもよいし、両方行ってもよい。なお、その他の判断手法を用いてもよい。例えば、デバイス側から予めデータを読み出しておき、キャッシュしておくことを重視する場合（アプリケーションが同じデータ内容にアクセスすることを繰り返すような場合）、リード要求時においても直接コントローラ１５６に要求を転送せずに、下位側に転送する。上位側ドライバ１５１が下位側ドライバ１５２のコントローラ１５６に直接リード、ライト要求を転送する場合、キャッシュメモリにデータが蓄積されない。そのため、アプリケーションが同じファイルにアクセスするような場合であればキャッシュメモリにデータが蓄積されるように下位側に転送すればよい。ただし、下位側ドライバ１５２がデータを転送するとともに、このデータをキャッシュメモリにコピーすることで、直接リード、ライト要求を受信した場合であっても、データを蓄積することが可能である。この場合、ＲＡＭ上のコピーであるため、コピー速度は高速であり、処理速度が著しく低下することはない。
　図９は、下位側ドライバ１５２の動作を示すフローチャートである。上位側ドライバ（ＵＳＢマスストレージドライバ５０３またはアプリケーション１０１）からリード要求、ライト要求、またはその他の要求を受信するとこの動作を開始する。
　まず、下位側ドライバ１５２は、アクセス予測を行う（ｓ１１）。アクセス予測は、上位側ドライバ１５１から送信されたアクセス情報や履歴データベースを参照することで行う。また、以下のようにして、精密にアクセス予測を行ってもよい。
　（１）ファイルシステムに基づく予測
　この予測手法は、外付ＨＤＤ２のファイルシステムを解析することでアクセス予測を行う手法である。ＨＤＤのファイルシステムが、例えばＦＡＴファイルシステムフォーマットである場合、ファイル管理領域を参照することで、個々のファイルの記録位置（セクタ）やサイズを判断することができる。よって、上位側のアプリケーションやドライバからリード要求が有ったとき、その要求が示す記録位置に対応するファイルのデータにアクセスが有ると予測する。またファイルサイズ以上のリードを行わないように予測することで、必要以上のリードをせずに、無駄な処理時間を削減する。
　なお、このファイル管理領域は、頻繁にアクセスを行う領域であるため、リード用キャッシュメモリにリードし、保持しておいてもよい。都度、外付ＨＤＤ２にアクセスしなくとも、リード用キャッシュメモリに保持しているファイル管理領域にアクセスすることで、アクセス予測の処理時間を削減することができる。
　（２）デバイス種別、コンテンツ種別に基づく予測
　この予測手法は、接続される対象デバイスのタイプ（上記実施形態ではＨＤＤ）や転送すべきデータのファイル構成（コンテンツ種別）に基づいてアクセス予測を行う手法である。例えば、接続されるデバイスがＤＶＤ－ＲＯＭであり、このデバイスにＤＶＤ－Ｖｉｄｅｏメディアが挿入されている場合、順次リードがされ、ライト要求がされることがない。そのため、リード用キャッシュメモリの容量一杯までデータがキャッシュされるように予測データベースを作成する。なお、リード用キャッシュメモリにキャッシュしたデータが全てリードされた場合、即時このキャッシュを破棄し、新たなデータをキャッシュすれば、効率的にリード用キャッシュメモリを用いることができる。
　また、キャッシュメモリの数および容量を変化させる場合、デバイス種別に基づいて変化させることができる。例えば、上記のようにＤＶＤ－Ｖｉｄｅｏメディアが挿入されている場合、ライト要求されることがないため、リード用キャッシュメモリの数を増やし、その容量も大きく設定する。逆に未書き込みのＤＶＤ－Ｒメディアが挿入されている場合、主にライト要求がされるため、ライト用キャッシュメモリの数を増やし、その容量を大きく設定する。
　（３）転送速度の解析に基づく予測
　この予測手法は、上記デバイス種別、コンテンツ種別に基づく予測の応用例であり、デバイス種別に応じてデータ転送速度の傾向を判断し、これに基づいてアクセス予測を行う手法である。例えば、多層型ＤＶＤメディアが接続される場合、各層の境界線を越えるランダムアクセスは、転送速度が非常に遅くなる。そのため、各層の境界線をまたぐアクセスの頻度が低くなるようにキャッシュするようにして、予測データベースを作成する。
　また、キャッシュメモリの数および容量を変化させる場合には、このデバイス種別やデータ転送速度の傾向に基づいて変化させることもできる。例えば、対象デバイスとのデータ転送速度が遅い場合（例えばＵＳＢ　ＭＯ（光磁気ディスク）のように４ＭＢ／ｓ程度である場合）、キャッシュメモリの容量を大きくして大量にデータをキャッシュしても、そもそもデータ転送速度が遅いために転送速度の向上が望めない。そのため、対象デバイスとのデータ転送速度が遅い場合、キャッシュメモリの容量を小さく設定し、ＲＡＭの消費を抑える。
　（４）リード要求時に１度に転送するデータを徐々に増加させる手法
　この予測手法は、リード要求時に、上記（１）～（３）の手法で予測したリード要求に基づいて、対象デバイスから一度にデータ転送しないように、予測データベースを修正する（分割する）手法である。例えばリード要求の所定倍（例えば４倍）の容量のデータをまずキャッシュするように予測データベースを修正する。このキャッシュしたデータが、結果的に全て上位側に転送される場合、さらに所定倍の容量のデータをキャッシュするように予想データベースを修正する。順次、キャッシュするデータの容量を大きくすることで、転送時間を抑えることができる。また、実際の要求が予想データベースと異なり、その後リードが無かった場合に無駄となるデータ量を削減することができる。また、都度キャッシュメモリの容量を変化させることで、ＲＡＭの消費を抑えることもできる。なお、予想データベースの修正処理は、実際にリードを行うとき（後述のｓ２９の処理時）に行ってもよい。
　以上のようにして、アクセス予測を行う。なお、キャッシュメモリの数および容量はユーザが手動で設定することができる。また、ライト用キャッシュメモリ、リード用キャッシュメモリの確保数もユーザが設定することができる。ユーザがリードを優先したい場合はリード用キャッシュメモリの数を増やし、ライトを優先したい場合はライト用キャッシュメモリの数を増やす。
　次に、図９において、下位側ドライバ１５２は、上側から送信された要求の内容を判断する（ｓ１２）。リード、ライトの要求でなければ、対象デバイスが他のリード、ライト等の処理を行っているか否かを判断し（ｓ１３）、処理が空いていればこの要求を下位側に転送する（ｓ１４）。他の処理を行っていればこの要求をコマンドキューに登録する（ｓ１５）。コマンドキューに登録しておけば、後に処理が空いたときに実行することができる。また、ＦＬＵＳＨ　ＣＡＣＨＥコマンドのような、ライト用キャッシュメモリのデータを書き込み指示するようなコマンドを受領した場合、このときにライト用キャッシュメモリにキャッシュされているデータを下位側へ転送する。
　ｓ１２において、下位側ドライバ１５２は、リード、ライトの要求であると判断した場合、キャッシュメモリを参照する（ｓ１６）。ここで、上位側からの要求がリード要求であり、リード用キャッシュメモリまたはライト用キャッシュメモリに該当するデータがキャッシュされていれば、これを上側に転送し、コマンド終了を返信する（ｓ１７）。
　ｓ１２において、下位側ドライバ１５２は、上位側からの要求が連続したライト要求であると判断した場合、ライト用キャッシュメモリに連続してデータを書き込み、コマンド終了を返信する（ｓ１８）。その後、ライト用キャッシュメモリの容量が一杯であるかを判断し（ｓ１９）、容量が一杯でなければタイマを起動させ（ｓ２０）、動作を終える。
　ｓ１９において、ライト用キャッシュメモリの容量が一杯であれば、対象デバイスが他のリード、ライト等の処理を行っているか否かを判断し（ｓ２１）、処理が空いていればライト要求を下位側に送信し、キャッシュしたデータを転送する（ｓ２２）。他の処理を行っていればこのライト要求をコマンドキューに登録する（ｓ２３）。コマンドキューに登録しておけば、後に処理が空いたときに実行することができる。
　ｓ１６において、下位側ドライバ１５２は、上位側からの要求に該当するキャッシュデータがないと判断した場合、予想データベースを参照し、上位側からの要求と予想データベースの内容を比較する（ｓ２４）。上位側からの要求と予想データベースの内容が不一致（ＬＢＡや転送ブロック数が不一致）であれば、この要求をそのまま下位側に転送する（ｓ２５）。なお、このとき、下位側が他の処理を行っていればコマンドキューに登録し、後に実行するようにしてもよい。
　上位側からの要求がライト要求であり、予想データベースの内容と一致（ＬＢＡや転送ブロック数が一致）すれば、ライト用キャッシュメモリを確保する（ｓ２６）。ここで、空きキャッシュメモリが有れば、そのキャッシュメモリをライト用キャッシュメモリとして確保し、キャッシュメモリが全てライト用またはリード用に用いられていた場合、最も過去に更新したキャッシュメモリの内容を消去してライト用キャッシュメモリを確保する。なお、ライト用キャッシュメモリのデータは、リード用キャッシュメモリのデータとしても使用可能である。
　その後、確保したライト用キャッシュメモリに上位側から転送されるデータを保存し、コマンド終了を返信する（ｓ２７）。
　ｓ２４において、下位側ドライバ１５２は、上位側からの要求がリード要求であり、予想データベースの内容と一致（ＬＢＡや転送ブロック数が一致）すると判断した場合、リード用キャッシュメモリを確保する（ｓ２８）。上記と同様、空きキャッシュメモリが有ればこれをリード用キャッシュメモリとし、空きが無ければ最も過去に更新したキャッシュメモリの内容を消去してリード用キャッシュメモリを確保する。
　その後、予想データベースに基づいて、予想分のリード要求を下位側に送信し、リード用キャッシュメモリにデータをキャッシュする（ｓ２９）。このとき、一度に大量のデータをキャッシュするのではなく、複数回に分けてデータキャッシュしてもよい。この場合、残りのリード要求はコマンドキューに登録する。リード要求を複数に分割することで、キャッシュ済みデータを上位側のドライバへ転送しながら、それと並行して、次に連続するリードデータをキャッシュすることができ、ＵＳＢバスの使用率向上が期待できる。
　次に、図１０は、下位側からのコマンド終了割り込みがあった場合の動作を示すフローチャートである。
　まず、下位側ドライバ１５２は、下位側から受信したコマンド終了が、ライト用キャッシュメモリにキャッシュしておいたデータを書き終えた旨を示すコマンドであるか否かを判断する（ｓ３１）。ライト用キャッシュメモリのデータが書き終わった場合は、このライト用キャッシュメモリをリード用キャッシュメモリに変更する（ｓ３２）。なお、ライト用キャッシュメモリをリード用キャッシュメモリに変更するタイミングは、このタイミングに限るものではない。また、上述のように、ライト用キャッシュメモリのデータをリード用キャッシュメモリのデータとして用いることも無論可能である。
　その後、下位側ドライバ１５２は、上位側に対して終了報告（転送）が必要なコマンドであるか否かを判断する（ｓ３３）。必要であれば上位側にコマンド終了を返送する（ｓ３４）。
　さらに、下位側ドライバ１５２は、コマンドキュー１６０を参照し、キューイングされたコマンドが存在するか否かを判断する（ｓ３５）。キューイングされたコマンドが存在すれば、これを下位側に転送する（ｓ３６）。
　次に、図１１は、タイマ割り込み、ドライバ初期化時、ドライバ終了時の動作を示すフローチャートである。
　まず、同図（Ａ）は、タイマ割り込み動作を示すフローチャートである。下位側ドライバ１５２は、タイマがタイムアップするとこの動作を開始する。下位側ドライバ１５２は、ライト用キャッシュメモリにデータがキャッシュされているか否かを確認する（ｓ４１）。キャッシュされていれば、下位側にライト要求を送信し、ライト用キャッシュメモリにキャッシュされているデータを下位側に転送し（ｓ４２）、動作を終える。ライト用キャッシュメモリにデータがキャッシュされていなければ動作を終える。
　同図（Ｂ）は、ドライバ終了時の動作を示すフローチャートである。ＰＣのシャットダウン時、外付ＨＤＤ２の接続を解除する時にこの動作を開始する。下位側ドライバ１５２は、履歴データベースを外付ＨＤＤ２またはＯＳ１１に転記して保存する（ｓ５１）。
　同図（Ｃ）は、ドライバ初期化時の動作を示すフローチャートである。ＰＣ１を再起動したり、外付ＨＤＤ２を再接続した場合にこの動作を開始する。下位側ドライバ１５２は、履歴データベースを外付ＨＤＤ２またはＯＳ１１から読み出し、ＲＡＭに展開してデータベース１５７を構築する（ｓ６１）。
　次に、図１２は、外付ＨＤＤ２のコントローラ２２の動作を示すフローチャートである。コントローラ２２は、ＰＣ１側からコマンドを受信したときにこの動作を開始する。まず、コントローラ２２は、受信したコマンドが、所定のサイズ（１ＭＢ）よりも大きいデータをリード、ライトするものであるかを判断する（ｓ７１）。所定のサイズ（１ＭＢ）以下であればそのままＨＤＤ２３に書き込み、または読み出しを行う（ｓ７３）。
　一方、所定のサイズ（１ＭＢ）よりも大きいデータをリード、ライトするものであった場合、このコマンドを所定のサイズ（１ＭＢ以下）に分割し（ｓ７２）、順次、ＨＤＤ２３に書き込み、または読み出しを行う（ｓ７３）。
　なお、上記実施形態では、上位側ドライバ１５１、下位側ドライバ１５２を実現し、汎用ディスクドライバ５０２、またはＵＳＢマスストレージドライバ５０３に接続される例を示したが、ＵＳＢマスストレージドライバを専用ドライバに置き換える形でも、本発明のデバイスコントローラを実現することができる。図１３は、ＵＳＢマスストレージドライバを専用ドライバに置き換える場合の例を示す機能ブロック図である。なお、図５と共通する構成については同一の符号を付し、その説明を省略する。
　この例では、ＵＳＢホストコントローラドライバ５０４、汎用ディスクドライバ５０２、およびアプリケーション１０１に接続される専用ＵＳＢマスストレージクラスドライバ１７１を備えている。専用ＵＳＢマスストレージクラスドライバ１７１は、従来の標準のＵＳＢマスストレージドライバを置き換えるものである（図１を参照）。
　この専用ＵＳＢマスストレージクラスドライバ１７１は、上記実施形態と同様に、キャッシュメモリを内蔵しており、上位側から受信したリード、ライト要求に応じてデータをキャッシュする。専用マスストレージクラスドライバ１７１の動作は図９から図１１に示した下位側ドライバの動作と同様である。
　この例においても、アプリケーション１０１が６４ｋＢ毎にデータを分割して、リード／ライトの要求を発行する場合は、専用ＵＳＢマスストレージクラスドライバ１７１がキャッシュメモリにデータをキャッシュし、データ転送する。
　なお、この専用ＵＳＢマスストレージクラスドライバ１７１は、６４ｋＢのデータ転送サイズの上限を持たず、６４ｋＢより大きいサイズのリード／ライトの要求を処理可能なものである。したがって、アプリケーション１０１、または汎用ディスクドライバ５０１は、リード／ライトの要求を６４ｋＢ単位に分割することなく発行することが可能であるため、コマンド、ステータスの処理の遅延が少なくて済み、データ転送を高速にすることができる。

Claims (3)

  1. 　パーソナルコンピュータと、パーソナルコンピュータに接続される周辺機器と、からなる情報処理システムであって、
    　前記パーソナルコンピュータは、前記周辺機器に対するリードまたはライトの要求を複数のコマンドに分割して順次送信する汎用ドライバと、
    　前記汎用ドライバの下位側に配置される下位側ドライバと、
    　前記リードまたはライトの要求に対応するデータをキャッシュするキャッシュメモリと、
    　前記下位側ドライバがライトの要求を受信したとき、各コマンドに対するコマンド終了を擬似的に上位側に返信するとともに、上位側から転送されるデータを順次前記キャッシュメモリにキャッシュし、前記汎用ドライバが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記キャッシュメモリのデータを前記周辺機器に転送し、
    　前記下位側ドライバがリードの要求を受信したとき、前記汎用ドライバが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記周辺機器からデータを読み出して前記キャッシュメモリにキャッシュする予測処理を行う制御部と、
    　を備え、
    　前記周辺機器は、前記パーソナルコンピュータから転送されたリードまたはライトのコマンドを複数のコマンドに分割するコマンド分割部を備え、
    　前記コマンド分割部は、前記パーソナルコンピュータから転送されたリードまたはライトのコマンドが所定のサイズよりも大きいデータをリードまたはライトするものであった場合、当該コマンドを前記所定のサイズ以下のデータをリードまたはライトするものとなるように複数のコマンドに分割する情報処理システム。
  2. 　パーソナルコンピュータと、パーソナルコンピュータに接続される周辺機器と、からなる情報処理システムであって、
    　前記パーソナルコンピュータは、前記周辺機器に対するリードまたはライトの要求を複数のコマンドに分割して順次送信する汎用ドライバと、
    　前記汎用ドライバの下位側に配置される下位側ドライバと、
    　前記汎用ドライバの上位側に配置される上位側ドライバと、
    　前記周辺機器に対するリードまたはライトの要求を前記上位側ドライバから前記下位側ドライバに直接転送するリード、ライト要求受信部と、
    　前記下位側ドライバにおいて、前記上位側ドライバから転送された前記リードまたはライトの要求に応じたリードまたはライトのコマンドを発行してデータ転送を行う制御部と、
    　を備え、
    　前記周辺機器は、前記パーソナルコンピュータから転送されたリードまたはライトのコマンドを複数のコマンドに分割するコマンド分割部を備え、
    　前記コマンド分割部は、前記パーソナルコンピュータから転送されたリードまたはライトのコマンドが所定のサイズよりも大きいデータをリードまたはライトするものであった場合、当該コマンドを前記所定のサイズ以下のデータをリードまたはライトするものとなるように複数のコマンドに分割する情報処理システム。
  3. 　前記コマンド分割部は、その周辺機器の仕様に応じて、前記所定のサイズを変更する請求項１、または請求項２に記載の情報処理システム。
PCT/JP2008/061315 2008-05-29 2008-06-20 情報処理システム WO2009144833A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008-141686 2008-05-29
JP2008141686A JP4391569B2 (ja) 2008-05-29 2008-05-29 情報処理システム

Publications (1)

Publication Number Publication Date
WO2009144833A1 true WO2009144833A1 (ja) 2009-12-03

Family

ID=41376732

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2008/061315 WO2009144833A1 (ja) 2008-05-29 2008-06-20 情報処理システム

Country Status (2)

Country Link
JP (1) JP4391569B2 (ja)
WO (1) WO2009144833A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102387460B1 (ko) 2015-04-09 2022-04-15 삼성전자주식회사 데이터 저장 장치와 이의 작동 방법
WO2017056219A1 (ja) * 2015-09-30 2017-04-06 株式会社日立製作所 ストレージ装置およびストレージ装置の制御方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1040170A (ja) * 1996-07-26 1998-02-13 Toshiba Corp ディスクキャッシュシステム
JP2001109663A (ja) * 1999-10-06 2001-04-20 Alps Electric Co Ltd ディスク制御システムおよびその制御方法
JP2001125749A (ja) * 1999-10-29 2001-05-11 Toshiba Corp 外部記憶装置ドライバプログラムを記録した記録媒体、及び外部記憶装置アクセス機能を有する計算機
JP2001154811A (ja) * 1999-11-30 2001-06-08 Toshiba Corp 計算機システム
JP2001229113A (ja) * 2000-02-15 2001-08-24 Nec Eng Ltd 競合解消システム
JP2004318653A (ja) * 2003-04-18 2004-11-11 Sharp Corp Ｕｓｂ接続機器

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1040170A (ja) * 1996-07-26 1998-02-13 Toshiba Corp ディスクキャッシュシステム
JP2001109663A (ja) * 1999-10-06 2001-04-20 Alps Electric Co Ltd ディスク制御システムおよびその制御方法
JP2001125749A (ja) * 1999-10-29 2001-05-11 Toshiba Corp 外部記憶装置ドライバプログラムを記録した記録媒体、及び外部記憶装置アクセス機能を有する計算機
JP2001154811A (ja) * 1999-11-30 2001-06-08 Toshiba Corp 計算機システム
JP2001229113A (ja) * 2000-02-15 2001-08-24 Nec Eng Ltd 競合解消システム
JP2004318653A (ja) * 2003-04-18 2004-11-11 Sharp Corp Ｕｓｂ接続機器

Also Published As

Publication number Publication date
JP2009289085A (ja) 2009-12-10
JP4391569B2 (ja) 2009-12-24

Similar Documents

Publication Publication Date Title
JP4391548B2 (ja) デバイスドライバ
TWI438628B (zh) 資料儲存系統及資料儲存媒介
KR101086857B1 (ko) 데이터 머지를 수행하는 반도체 스토리지 시스템의 제어 방법
JP4788528B2 (ja) ディスク制御装置、ディスク制御方法、ディスク制御プログラム
WO2014102879A1 (en) Data storage apparatus and control method thereof
JP2007241927A (ja) データ記憶装置及び方法
CN107515827B (zh) Pcie ssd自定义日志的存储方法、装置及ssd
US7380090B2 (en) Storage device and control method for the same
JP5959958B2 (ja) 記憶装置及び記憶装置におけるデータ消去方法
JP2010211734A (ja) 不揮発性メモリを用いた記憶装置
JP2014010498A5 (ja)
KR20010050881A (ko) 캐시 메모리의 제어 방법, 컴퓨터 시스템, 하드 디스크드라이브 장치 및 하드 디스크 제어 장치
JP4391569B2 (ja) 情報処理システム
JP2020191055A (ja) 瞬断からの回復処理方法及び装置、並びにコンピュータ読み取り可能な記憶媒体
JP4959766B2 (ja) デバイスドライバ
JP2007102436A (ja) ストレージ制御装置およびストレージ制御方法
JP6767653B2 (ja) 記憶装置、情報処理システム、記憶装置の起動方法及びプログラム
JP5594647B2 (ja) ストレージ装置及びその制御方法
KR20100056400A (ko) 기록가능 메모리 장치
US20050240686A1 (en) Method for downloading firmware of peripheral equipment, and peripheral equipment
JP2007323377A (ja) 記録装置、管理データの書き込み方法および管理データの修復方法
JP4814983B2 (ja) データ格納制御装置、データ格納制御方法およびデータ格納制御プログラム
JP5216719B2 (ja) 情報処理装置および制御装置
US20090024786A1 (en) External storage device
JP5350077B2 (ja) 情報処理装置及びこれを備えた画像形成装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08777459

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08777459

Country of ref document: EP

Kind code of ref document: A1