JP2008269623A - Remote disk controller, remote disk control method, and remote disk control system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To format each track of a storage disk device in a short time. <P>SOLUTION: This disk controller 1 has a cache memory 14 for storing one part of data, a control table 20 for indicating whether a track of the storage disk device 2 is initialized to a prescribed track format or not, and control units 10, 12 for preparing a track format pattern with respect to an input/output request from a host 3, while referring to the control table 20. A track control table is provided in the controller, a flag is provided to indicate a factory deliver time format, the factory deliver time format flag of the control table is set to "1" in a factory format time, and only the control table is transferred to a disk. A quick factory format gets possible by this technique. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a remote disk control device, a remote disk control method, and a remote disk control system that control a disk drive having a storage disk.

  A disk file system such as a RAID system is used as a mass data storage system in a computer center. FIG. 27 is an explanatory diagram of the prior art, FIG. 28 is an explanatory diagram of the CKD format, and FIG. 29 is an explanatory diagram of the magnetic disk.

  As shown in FIG. 27, a disk control device (hereinafter referred to as FCU: File Control Unit) 200 is connected to the host computer 100. A magnetic disk drive 210 is connected to the FCU 200. The RAID system replaces an expensive disk for a large machine with a small capacity disk for a plurality of small machines, and is excellent in data maintenance and redundancy.

  The FCU 200 has several functional units each having an MPU, such as a CA (Channel Adapter) 220, a CM (Centralized Module) 230, a DA (Device Adapter) 250, a magnetic disk 210, and data used for function control. And a cache memory 240, and a bus 260 connecting them.

  Since the FCU 200 holds data on the connected magnetic disk 210, when there is an input / output request from the host 100, the data is expanded (staging operation) from the magnetic disk 210 to the cache memory 240, and the input / output processing is performed. All this is done via the cache memory 240. However, when the target data already exists in the cache memory 240 at the time of the input / output request from the host 100 (cache hit), the data on the cache memory 240 is read / written, and the end of the process is notified to the host 100.

  FCU200 is used for mission-critical work (DB processing where data update corresponds to account / logistics) and information-related work (information retrieval and processing), and because it requires the delivery of a large amount of data, it is faster and faster. Large capacity is required.

  In such a large capacity system, each track of the magnetic disk 210 connected to the FCU 200 adopts the CKD track format as shown in FIG. As shown in FIG. 29, one disk 280 of the magnetic disk 210 has a plurality of concentric tracks. For example, it has about 10,000 tracks.

  All tracks start with an index mark and end with an index mark. Each track is composed of HA (home address), R0 (record 0), and user data records Rn (records R1 to Rn).

  HA is the first block information of each track, and indicates the state of the track (normal, defective, change, etc.) and the physical position of the track. Records R0 and Rn are composed of a Count part (8 bytes), a Key part (0 to 255 bytes), and a Data part (0 to 47476 bytes). In the Count part, the length of the Key part, the length of the Data part, and the like are stored. The Key part and Data part store user data. The record R0 includes a count part and a data part, and a replacement track address or the like is stored in the data part (see, for example, Patent Document 1).

  Conventionally, the magnetic disk 210 is formatted in an initial state where no user data exists when the FCU 200 is shipped or when the magnetic disk 210 is added, and then used for actual operation. That is, as shown in FIG. 27, this is realized by connecting a maintenance terminal (PC or the like) 300 at the factory or the user and issuing an initialization instruction to the magnetic disk control device 200 from the terminal 300. In response to this initialization instruction, the magnetic disk control device 200 creates only the HA and standard R0 (R0 consisting of an 8-byte Count portion and a Data portion in which all 8 bytes are 0) on each track.

  A conventional initialization (factory) formatting procedure will be described with reference to FIG.

The maintenance terminal (PC or the like) 300 issues a command to the CM 230 and instructs the factory format of the magnetic disk 210 ((1)). The CM 230 receives an instruction from the maintenance terminal (PC or the like) 300, schedules a factory format task, and instructs the DA 250 to execute the factory format ((2)). The DA 250 receives an instruction from the CM 230, and generates a factory-shipped format including an HA / standard R0 data pattern in the DA 250 internal buffer ((3)). The DA 250 writes the data pattern generated in (3) to the magnetic disk 210 ((4)). The DA 250 repeats steps (3) to (4) to perform factory formatting on all tracks on the magnetic disk 210, and notifies the CM 230 of completion upon completion ((5)). The CM 230 notifies the maintenance terminal (PC or the like) 300 of completion.
Japanese Patent Laid-Open No. 11-143646

  As described above, in the conventional factory format, the format data at the time of shipment from the factory is directly written to each track of the magnetic disk 210. Therefore, a large amount of data needs to be transferred to the magnetic disk 210, and formatting takes time. . Since the magnetic disk drive positions the head on each track of the magnetic disk and writes the format to each track, all the tracks (for example, 10,000 tracks) of one magnetic disk take time.

  For example, if the factory format of the mainframe magnetic disk device F6427H (manufactured by Fujitsu) is performed, it takes 95 [seconds] per unit number (one disk drive). Furthermore, in a normal RAID system, since a large number of disk drives 210 are connected to 1 FCU 200, if a 64th magnetic disk is connected to 1 FCU 200, it takes 101 [minutes]. For ordinary users, considering the connection of 64, 128, and 256 magnetic disks, it takes several hours at the factory or at the user site, and there is a problem that costs such as labor costs are required. .

  In order to achieve this object, in accordance with an input / output request from the main host of the present invention, the data input / output control of the storage disk device is performed, and in the remote disk control device connected to the disk control device of the secondary center, A cache memory for storing a part of the data of the storage disk device, a management table for storing initialization information indicating whether or not a track of the storage disk device has been initialized to a predetermined track format, and from the host In response to an input / output request, referring to the management table, a control unit that creates a track format pattern indicating a track attribute for a track that has not been initialized, and a copy instruction from the main host, The initialization information of the management table is connected to the sub center host and the sub center host To input-output requests from the bets, and a remote unit to transfer the reference to the management table, the disk controller for creating a track format pattern indicating a track attributes for track uninitialized.

  In the present invention, a track management table is provided in the control device, and a flag indicating a factory shipment format is provided. The factory format is realized by setting the factory format flag of this management table to “1” and transferring only the management table to the disk. This method enables high-speed factory formatting.

  In response to a copy instruction from the host, a remote unit is provided to transfer the initialization information of the management table to the disk control device of the secondary center, so copy processing at the secondary center is executed using factory format information. it can.

  In the present invention, the control unit sets a flag indicating whether the initialization has been completed in the management table in accordance with an instruction from the outside, and initializes the track format of the track of the storage disk device. Thus, the initialization process can be easily performed.

  Further, according to the present invention, in response to a write request from the host, the control unit develops the write data in the cache memory, and then writes the data together with the track format to the actual format on the disk. Can be formed.

  Further, in the present invention, the control unit refers to the management table in response to a read request from the host, creates the track format, and responds to the host. Can respond.

  Furthermore, in the present invention, a list table for storing a plurality of track format patterns is provided, and the control unit refers to the management table in response to an input / output request from the host, and specifies a track specified in the list table. By creating the format, the user can format the factory in any format.

  In the present invention, the remote unit can reduce the transfer amount by transferring the information on the uninitialized track.

  Furthermore, in the present invention, the remote unit can further reduce the transfer amount by transferring the uninitialized track range.

  Furthermore, in the present invention, the remote unit creates a track format for the non-initialized track, and transfers the created track format so that the sub-center can copy without being aware of the factory format. Processing can be executed.

  Hereinafter, embodiments of the present invention will be described with reference to a magnetic disk control system, factory format processing, read / write processing, remote magnetic disk control system, first volume copy processing, second volume copy processing, and third volume copy processing. These will be described in the order of other embodiments.

[Magnetic disk control system]
FIG. 1 is a configuration diagram of a disk control system according to an embodiment of the present invention, and shows a RAID system using a magnetic disk. As shown in FIG. 1, a magnetic disk control device (hereinafter referred to as FCU) 1 is a system that can read and write a large amount of data from a computer center (host) 3 to a RAID disk drive (hereinafter referred to as disk) 2 at high speed and randomly. It is.

  The FCU 1 includes three function modules CA10 / CM12 / DA16. These three function modules are assigned roles for performing actions inside the FCU 1, reducing the burden caused by the extreme concentration of processing. In addition, the communication interface between modules communicates the processing contents and the status of each module using a message or ACB.

  An outline of the role sharing of each function module 10, 12, 16 will be described below. The CA (Channel Adapter) 10 is a module that controls the host interface connecting the FCU 1 and the HOST 3. When the CA 10 receives a data write / read operation request from the HOST 3, the CA 10 notifies the CM 12 of the processing request, or directly accesses the cache memory 14 on the CM 12 to transfer data between the HOST 3.

  The CM (Centralized Module) 12 includes resource management (performs resource management of each module and effective control management), cache memory management (performs management of memory area allocation and overall control), and service processing (using a maintenance tool). Is a function that provides various services). In addition, the CM 12 has a built-in Cache Memory (several gigabytes) 14 for storing data read from the RAID Disk 2.

  The DA (Device Adapter) 16 is a module that controls the device interface between the FCU 1 and the device (magnetic disk) 2, and performs processing to the device 2 in accordance with an instruction from the CM 12.

  This RAID (Redundant Array of Inexpensive Disk) is a disk system that guarantees data integrity and redundancy by replacing expensive disks for large machines with small capacity and inexpensive disks for multiple small machines.

  A TFT (Track Format Table) 20, which will be described later, is 8-byte information indicating the format state on the disk 2, and this table 20 exists in the cache memory 14 of the CM 12. There is one TFT per track, and the TFT stores the number of records present in the track, the data length of the Data portion, and Flag (used for multiple purposes). The CA 10 can recognize the track format by using the TFT 20 without checking the actual track on the cache 12. The TFT 20 is rewritten by the CA 10 when the track format is changed by Write I / O from the host 3.

  Next, Factory Format will be described. Traditionally, mainframe disks were CKD logical format (created only for HA / standard R0) at the factory and then used in actual operation. However, formatting the disk physically requires time and cost for formatting. Therefore, in order to reduce the time and cost, CKD logical formatting is performed on the TFT 20 without performing physical formatting. Specifically, this is realized by providing a flag “Factory Format” for the TFT 20 and setting this flag to “1” for the TFT 20 of all tracks.

  Therefore, Factory Format indicates the CKD logical format at the time of shipment from the factory, but there is no valid data on the actual disk 2. For I / O from host 3 to this track, CA 10 must behave as if HA / standard R0 is on disk 2.

[Factory format processing]
2 is an explanatory diagram of format processing according to an embodiment of the present invention, FIG. 3 is a configuration diagram of the track management table of FIG. 2, FIG. 4 is a format diagram of the track management table of FIG. 3, and FIG. 2 is a configuration diagram of the format list table in FIG. 2, FIG. 6 is an explanatory diagram of the storage area of the magnetic disk in FIG. 2, FIG. 7 is a format processing flow diagram of the management terminal in FIG. 2, and FIG. FIG. 9 is a format processing flowchart of the DA of FIG. 2.

  2 that are the same as those shown in FIG. 1 are denoted by the same symbols. As shown in FIG. 2, in the factory format process, the FCU 1 has a track management table (hereinafter referred to as TFT: Track Format Table) 20. As shown in FIG. 3, the TFT 20 includes a table having management information of 8 bytes for each track of each machine number.

  As shown in FIG. 4, the TFT management information of each track includes a track address CCHH (0 to 2 bytes), a 1-byte flag, the number of records in the track, a record number, and a record length. This flag is composed of a flag indicating a factory default format and flags # 1 to #N indicating a track format pattern. That is, a flag indicating the factory shipment format is provided in the track table TFT 20 managed in the FCU 1.

  The factory formatting method is realized by setting the factory format flag of the TFT 20 to “1” and transferring only the TFT 20 to the magnetic disk 2. As shown in FIG. 6, this TFT 20 is stored in a part of the TFT area of the management area other than the user data area of each machine number. Since the TFT area is within 10 tracks of the magnetic disk, it is not necessary to write to each track of the conventional magnetic disk, so that a high-speed factory format is possible.

  Also, as shown in FIG. 2, a factory format list table (hereinafter referred to as FFLT: Factory Format List Table) 22 is provided in the FCU 1 to enable factory formatting in any format desired by the user. As shown in FIG. 5, the FFLT 22 can store a plurality of factory-shipped track format patterns, and the user can set a plurality of arbitrary patterns from the maintenance terminal (PC or the like) 4.

  Further, the TFT 20 has a plurality of flags indicating the track format, so that a track format pattern arbitrarily set by the user is stored in the flag. The factory format by the user arbitrary format is realized by setting a flag corresponding to the track format pattern designated by the user of the TFT 22 to “1” and transferring only the TFT 22 to the magnetic disk.

The factory format is performed by executing each microprogram of the maintenance terminal (PC etc.) 4 / CM12 / DA16 of FIG. The processing flow of the maintenance terminal (PC, etc.) 4 / CM12 / DA16 is shown in FIGS. 7, 8, and 9, respectively.
The factory format is performed by executing each microprogram of the maintenance terminal (PC etc.) 4 / CM12 / DA16 of FIG. The processing flow of the maintenance terminal (PC, etc.) 4 / CM12 / DA16 is shown in FIGS. 7, 8, and 9, respectively.

  Hereinafter, the factory formatting process of the magnetic disk according to the present invention will be described with reference to FIGS. 2 and 7 to 9.

  (1) As shown in FIG. 7, a factory format execution instruction is issued from the maintenance terminal (PC or the like) 4 to the CM 12. At this time, the factory format in the range desired by the user is performed by designating the target machine number of the factory format and the target range (track range). For example, when a magnetic disk system is shared by a plurality of computer systems, it is possible to factory format only the user area. In this factory format instruction, the following parameter settings are possible.

All or specified machine number All or specified track
(2) As shown in FIG. 8, the CM 12 sets the factory format flag of the target machine number TFT 20 to “1” in accordance with an instruction from the maintenance terminal (PC or the like) 4.

  (3) The CM 12 instructs the DA 16 to write the TFT 20 updated in (2) to the magnetic disk 2.

  (4) As shown in FIG. 9, the DA 16 receives the instruction from the CM 12 and writes the TFT 20 to the magnetic disk 2.

  (5) The DA 16 writes the TFT 20 in the instructed range to the magnetic disk 2, and when complete, notifies the CM 12 of completion.

  (6) The CM 12 notifies the maintenance terminal (PC, etc.) 4 of the completion of the factory format.

  (3) to (6) are performed asynchronously with (1) to (2).

[Read / write processing after factory formatting]
As described above, in the present invention, the factory format is realized by holding the state of the factory format flag “1” in the TFT 20, so that there is no valid data in the track on the actual magnetic disk 2. not exist. Therefore, in response to an I / O request (read / write) from the host for this track, the FCU 1 must perform processing so that the HA and standard R0 data exist on the magnetic disk 2. This process is performed by the micro program of CA10.

  First, the processing of the FCU 1 in response to a read request from the HOST 3 after factory formatting will be described with reference to FIG.

  (S10) The HOST 3 issues a read command to the factory formatted track.

  (S11) Upon receiving the command from the HOST 3, the CA 10 transmits information such as the track designated by the HOST 3 to the CM 12 and makes a read request.

  (S12) The CM 12 requested to read from the CA 10 refers to the TFT 20 and checks the flag of the factory shipment format of the corresponding track.

  (S13) Upon recognizing that the factory shipment format flag of the corresponding track is not on, the CM 12 allocates the cache memory 14 and, if the target track is not in the cache 14, the CM 12 stores the cache data 14 from the magnetic disk 2 of the target data. Staging to.

  (S14) The CA 10 refers to the TFT 20, recognizes that the factory shipment format flag is on, and checks whether the read command from the HOST 3 is for the HA / standard R0. If the read command is HA / standard R0, the HA / standard R0, which is data in the factory default format, is created (created) in the internal buffer.

  (S15) The CA 10 transfers the data on the cache 14 or the internal buffer to the HOST 3. The CA 10 notifies the read processing completion to the HOST 3.

  (S16) If the read command is not HA / standard R0 in step S14, the actual format is not formed in the track in the factory format, so the HOST 3 is notified that there is no data, and the process ends.

  Next, the write processing immediately after the factory format will be described with reference to FIG.

  (S20) The HOST 3 issues a write command to the factory formatted track.

  (S21) Upon receiving the command, the CA 10 transmits information such as the track designated by the HOST 3 to the CM 12 and makes a write request.

  (S22) The CM 12 requested to write from the CA 10 refers to the TFT 20 and checks whether the factory shipment format flag is on.

  (S23) If the factory format flag is not ON, the corresponding track of the magnetic disk has already been formatted, and therefore the CM 12 allocates the cache memory 14 and if the target track is not in the cache 14, the magnetic disk of the target data 2 to the cache memory 14 is performed. Then, the CA 10 writes the data received from the HOST 3 to the cache 14 and proceeds to step S27.

  (S24) On the other hand, when recognizing that the factory format flag is on, the CM 12 performs only the allocation of the cache memory 14 and instructs the CA 10 to start processing.

  (S25) CA10 writes the HA / R0 data from HOST3 onto the cache memory 14 when the target record is HA / R0. On the other hand, when the target record is not HA / R0, the HA / standard R0 data is prepared on the internal buffer, the transfer data is written on the cache memory 14, and the original track data is completed on the cache memory 14.

  (S26) When the data writing to the cache memory 14 is completed, the CA 10 turns off the factory shipment format flag of the TFT 20 of the track and updates it to the normal track state.

  (S27) The CA 10 sends a write processing completion notification to the HOST 3.

  As is well known, the CM 12 writes the data in the cache memory 14 back to the magnetic disk 2 via the DA 16 asynchronously with the I / O from the HOST 3. As a result, the corresponding track of the magnetic disk is actually formatted, and the original track data is completed.

  Furthermore, in this embodiment of the present invention, a new FFLT 22 is provided, and the user can specify a factory format consisting of an arbitrary data pattern. FIG. 12 is an explanatory diagram of the FFLT registration process. The process for registering the factory format in the FFLT 22 will be described below.

  On the maintenance terminal (PC etc.) 4, set the data pattern in the factory default format ((1)). The maintenance terminal (PC or the like) 4 instructs the CM 12 to register the registered factory format data pattern in the FFLT 22 ((2)). The CM 12 receives an instruction from the maintenance terminal (PC or the like) 4 and registers the data pattern in the factory default format in the FFLT 22 ((3)). The CM 12 notifies the maintenance terminal (PC or the like) 4 that the factory format registration to the FFLT 22 is completed ((4)).

Next, in the factory format execution process using the FFLT 22, a process for designating the track format pattern registered in the FF LT 22 from the maintenance terminal (PC, etc.) 4 is added to the process described with reference to FIGS. .

  In the read processing using the FFLT 22, a data pattern designated by the FFLT 22 is created in the internal buffer. Further, in the write processing using the FFLT 22, the data pattern designated by the FFLT 22 is created on the internal buffer, written on the cache memory, and the original track data is completed on the magnetic disk.

  As described above, according to the present invention, the factory format is realized by the factory format flag of the TFT 20 instead of the conventional method with access to the magnetic disk. Factory formatting can be performed in the processing time, and the processing time can be greatly shortened and the associated costs can be reduced.

  In the present invention, since a factory format composed of an arbitrary data pattern can be registered in the FFLT 22, a user can easily change to an arbitrary factory format in a short time.

[Remote magnetic disk controller (RFCF)]
FIG. 13 is a block diagram of a remote magnetic disk control device (hereinafter referred to as RFCF) using the magnetic disk control device of FIG. The remote magnetic disk control device is an FCU 1 that retains a data backup function to a remote location.

  A large-scale disaster can occur when the computer center (hereinafter referred to as the “primary center”) 3 mirrors the data of the primary center 1 on another FCU (hereinafter referred to as the “secondary center”) 1-1 provided in a remote location in parallel with normal operations. Regardless of which center occurs, data remains in the center that did not match the disaster.

  As shown in FIG. 13, RFCF1 has a configuration in which a module responsible for communication control called RA19 is added to FCU1. The RA (Remote Adapter) 19 is an adapter that serves as an interface between the communication control device (RT; router) 5 and the FCU. The RA 19 is connected to the RA 19-1 of the sub FCU 1-1 of the sub center via the RT 5, the dedicated line 6, and the RT 5. The sub FCU 1-1 also has the same configuration as the main FCU (RFCF) 1 and includes CA 10-1, CM 12-1, DA 16-1, magnetic disk 2-1, and RA 19-1.

  The FCU 1 uses an internal instruction called ACB. A series of processing contents (for example, read) requested by a command from the host is called an “operation”, and individual internal processes necessary for performing this operation (such as a process of extracting data from a magnetic disk to a memory). Is called an action. In the FCU 1, ACB is used as an instruction sheet for notifying each module of actions necessary for performing an operation.

  In RFCF1, a real-time transfer method is executed. In real-time transfer, when a write operation (write I / O) is performed from the primary host 3 to the primary FCU 1, the primary FCU 1 simultaneously writes data to its own RAID DISK (cache 14, magnetic disk 2). This is a function for transferring the same data to the sub-center FCU 3-1.

  The RFCF 1 has a Volume Pair Copy function for copying data in the primary disk 2 to the secondary disk 2-1 and performing mirroring. When the primary host 3 instructs the primary FCU 1 to perform a copy device and a copy range (start CCHH to end CCHH), all tracks in the corresponding range are copied from the primary FCU 1 to the secondary FCU 1-1. For example, Volume Pair Copy is used when the secondary FCU 1-1 is provided in order to change to the remote copy system after operating the primary FCU 1 in an existing system.

  Further, as shown in FIG. 14, data is transferred in packets from the primary RA 19 to the secondary RA 19-1. One packet is 4352 bytes (256 + 4096). If one track is 46 Kbytes, one track is composed of 12 packets. As shown in FIG. 15, the first 256 bytes is called RA Header 60, and is used for communication between the primary RA 19 and the secondary RA 19-1. RAHeader stores the target device number, cylinder, and head value. User data 61 is stored in the latter half 4096 bytes of the packet.

  Next, Volume Pair Copy processing will be described.

[Copy processing of the first embodiment]
In RFCF1, in Volume Pair Copy, when the track is in a factory-shipped format (hereinafter referred to as Factory Format), RA 19 of primary center FCU 1 creates the HA / R0 part and transfers it to sub-center 1-1. As a result, Volume Pair Copy can be realized even if Factory Format is used.

  The contents of copy processing according to the first embodiment will be described with reference to FIG.

  (S30) The primary FCU 1 receives a Volume Pair Copy operation notification from the primary HOST 3.

  (S31) The CM 12 determines from the TFT 20 whether or not the corresponding track is a Factory Format. If the corresponding track is not a Factory Format, the primary CM 12 reads the corresponding Track from the disk 2 (actually performed by the DA). Expands on the Cache Memory 14. In addition, when the TFT 20 of the corresponding track is Factory Format, the CM 12 does not perform this operation.

  (S32) The primary CM 12 notifies the primary RA 19 to perform Volume Pair Copy from the primary FCU 1 side to the secondary FCU 1-1 side. At this time, the primary CM 12 notifies the primary RA 19 of the volume number, cylinder address, and head address to be subjected to Volume Pair Copy via the ACB. Also, specify instructions for transferring HA / R0.

  (S33) The primary RA 19 reads the TFT 20, and determines whether or not the corresponding track is Factory Format.

  (S34) If the target track for remote transfer is Factory Format, the primary RA 19 creates (makes) HA / R0 data and transfers it to the sub-center 1-1.

  (S35) If the format is not Factory Format, the corresponding track is read from the cache 14 (1 track), and the track is transferred to the sub center 1-1. After the transfer is completed, the primary RA waits for a response from the secondary RA. The secondary RA 19-1 writes the transmitted data to the cache memory 14-1 on the secondary CM 12-1. The secondary RA 19-1 returns a response packet for the remote transfer of the track to the primary RA 19.

  (S36) When the primary RA 19 receives the response from the secondary RA 19-1, the primary RA 19 notifies the primary CM 12 that the transfer is complete (only 1 track).

  (S37) The primary FCU 1 checks whether or not the range of Volume Pair Copy has ended, and if it has not ended, returns to step S31 and repeats the operations of S31 to S36 until it ends.

  FIG. 17 is an operation explanatory diagram when the factory format tracks of tracks 4 to 7 exist in the volume pair copy range tracks 1 to 15 in the first embodiment, from the primary RA 19 to the secondary RA 19-1. 136 packets are transferred.

[Copy processing of the second embodiment]
In the first embodiment, when there are n Factory Format Tracks, transfer is performed n times. In the second embodiment, this is done only once.

  For this reason, the primary CM 12 checks the presence of the Factory Format within the Volume Pair Copy range, and if it exists, notifies the primary RA 19 of the CCHH (single or multiple cases) existing via the ACB. As shown in FIG. 19, the primary RA 19 that has received the notification records the fact that it is Factory Format X in the RA Header 60 and the range of the Factory Format Track (start CCHH, end CCHH), and notifies the secondary RA 19-1 of the fact. That is, unlike the first embodiment, the primary RA 19 does not imitate HA / R0. The secondary RA 19-1 recognizes that a factory format of a plurality of tracks is created by the RA header 60, and creates a plurality of tracks of only HA / R0 on the secondary cache 14-1.

  The copy processing according to the second embodiment will be described with reference to FIG.

  (S40) The primary FCU 1 receives a Volume Pair Copy operation notification from the HOST 3.

  (S41) The primary CM 12 determines whether the corresponding track is Factory Format by the TFT 20.

  (S42) If the track is not Factory Format, the primary CM 12 reads the track from the disk 2 and develops it on its own Cache. The primary CM 12 instructs the primary RA 19 to copy the corresponding track. The primary RA 19 reads the track data from the cache 14 and transmits a packet to the secondary RA 19-1. The primary CM 12 updates the corresponding track CCHH to (CCHH + 1). Proceed to step S45.

  (S43) When the primary CM 12 recognizes that the corresponding track is in Factory Format by the TFT 20, it determines whether the next track is in Factory Format.

  (S44) If the next track is not Factory Format, the primary CM 12 sets the factory format machine number and range (start CCHH, end CCHH) in the ACB, and notifies the primary RA 19 to copy. The primary RA 19 recognizes that the factory format track is transferred from the ACB. The primary RA 19 sets a value as shown in FIG. 19 in the RA Header 60 of the packet and transfers it to the secondary RA 19-1. The secondary RA 19-1 recognizes that the factory format track is transferred by the RA Header 60, and imitates HA / R0 for the track range indicated by the RA Header 60, and writes it on the Cache 14-2.

(S45) The secondary RA 19-1 transmits a response packet to the primary RA 19.
When the primary RA 19 receives the response packet from the secondary RA 19-1, the primary RA 19 notifies the primary CM 12 that the copying of the corresponding track has been completed.

  (S46) The primary FCU 1 checks whether the range of Volume Pair Copy has ended, and if it has not ended, returns to step S41 and repeats the operations of S42 to S45 until it ends.

  FIG. 20 is an operation explanatory diagram when the factory format tracks of tracks 4 to 7 exist in the volume pair copy range tracks 1 to 15 in the second embodiment, from the primary RA 19 to the secondary RA 19-1. 133 packets are transferred. In the first embodiment, when there are n Track Factory Format Tracks within the range of Volume Pair Copy, transfer from the primary RA to the secondary RA is performed n times. In this embodiment, this can be done by one transfer, and the total processing time of I / O can be reduced.

  FIG. 21 shows an example in which even when Factory Format Tracks are dispersed in one device. It is an operation explanatory diagram when the factory format tracks of tracks 4 to 7 and the factory format tracks of tracks 9 to 10 are dispersed in the range pairs 1 to 15 of the volume pair copy, and 110 packets are sufficient.

  When the primary CM 12 recognizes from the TFT 20 that the corresponding track is a Factory Format Track, it notes this CCHH in the internal memory. The primary CM 12 continues to check the next track. As a result of the check, since it is not a Factory Format Track, the track previously noted is set in the ACB, and the main RA 19 is notified to perform Volume Pair Copy of the Factory Format Track. The primary RA 19 recognizes that the factory format track is transferred from the ACB. The primary RA 19 sets a value as shown in FIG. 19 in the RA Header 60 of the packet and transfers it to the secondary RA 19-1. The sub RA 19-1 recognizes that the factory format track is transferred by the RA Header 60. The secondary RA 19-1 imitates HA / R0 for the track indicated in the RA Header 60 and writes it on the Cache.

  In the first embodiment, when n Track Factory Format Tracks exist discretely within the range of Volume Pair Copy, the Factory Format Track is transferred n times from the primary RA to the secondary RA. In this form, this can be done with a single transfer. Therefore, the total processing time of I / O can be significantly reduced.

[Copy processing of the third embodiment]
In this embodiment, if the factory format track range is from the end of the user data area of the device to the end of the device, the end of the user data transferred by the secondary RA is written to the cache memory. As a result, the Deputy RA voluntarily performs the HA / R0 fabrication process for Factory Format tracks to the end of the device.

  Hereinafter, the operation process flow chart of CM in FIGS. 22 and 23 to the operation process flow chart of RA in FIG.

  (S50) When the primary FCU 1 receives the Volume Pair Copy notification from the HOST 3, the CM 12 initializes the memo table 62 of the internal buffer in FIG. 25 for the maximum transfer amount. The first CCHH within the transfer range instructed by the host is set as the transfer CCHH.

  (S51) The primary CM 12 determines whether the corresponding track (transfer CCHH) is Factory Format by the TFT 20.

  (S52) If the track is not Factory Format, the primary CM 12 reads the track from the disk 2 and develops it on its own Cache. The primary CM 12 creates an ACB for the primary RA 19 and instructs remote transfer. The primary CM 12 updates the transfer track CCHH to (CCHH + 1) by waiting for a response from the primary RA 19 and receiving a response packet from the primary RA 19.

  (S53) The primary CM 12 checks whether or not the range of Volume Pair Copy has ended. If it has not ended, the process returns to step S51, and if it has ended, it ends.

  (S54) When the primary CM 12 recognizes that the corresponding track is Factory Format by the TFT 20, it sets the start and end of the factory format track in the memo table 62 of the corresponding volume.

  (S55) It is determined whether the memo table 62 exceeds the maximum transfer amount. When the memo table 62 exceeds the maximum transfer amount, the contents of the memo table 62 are copied to the ACB, and the remote transfer is notified to the RA 19. The primary CM 12 updates the transfer track CCHH to (CCHH + 1) by initializing the memo table 62, waiting for a response from the primary RA 19, and receiving a response packet from the primary RA 19.

  (S56) The primary CM 12 checks whether or not the range of Volume Pair Copy has ended. If it has not ended, the process returns to step S51. If it has ended, the process proceeds to step S57 in FIG.

  (S57) It is determined whether the memo table 62 exceeds the maximum transfer amount.

  (S58) When the memo table 62 exceeds the maximum transfer amount, the contents of the memo table 62 are copied to the ACB and the RA 19 is notified of the remote transfer. The memo table 62 is initialized, the response from the primary RA 19 is awaited, and when the response packet from the primary RA 19 is received, the primary CM 12 ends the processing.

  (S59) If the memo table 62 does not exceed the maximum transfer amount, it is checked whether valid data (Factory Format Track CCHH) exists in the memo table 62 of another volume. If not, the process proceeds to step S58. The data (via CCHH, end CCHH) is copied to the free area of the memo table of the transfer target volume, the memo table of another volume is initialized, and the process returns to step S57.

  On the other hand, in RA, the process of FIG. 24 is performed.

  (S60) The RA 19 determines whether a packet is received from the sub-RA 19-1.

  (S61) The primary RA 19 checks whether it is Factory Format Track transfer from the ACB, and if the Factory Format Track flag is set, places the ACB on the RA Header 60 of the packet. If the Factory Format Track flag is not set, the track is read from the cache 14.

  (S62) Then, remote transfer is performed to the sub RA 19-1. The secondary RA 19-1 recognizes that the factory format track is transferred by the RA header 60, and imitates the HA / R0 for the track range indicated by the RA header 60 and writes it on the cache 14-2.

  (S63) The secondary RA 19-1 checks whether or not Volume Pair Copy has been received. If not, the secondary RA 19-1 checks whether it is a response packet. If it is a response packet, the secondary RA 19-1 notifies the primary CM 12 that the corresponding track has been copied.

  (S64) and subsequent steps are sub-RA processing, in which data in a packet transferred from the primary RA is written to the memory in the sub-FCU. If the flag is set in the RA HEADER of the transferred packet, the secondary RA performs the HA / R0 forgery of the factory format track when the write action to the cache memory of the user data is completed. Repeat until the end of the device.

  The secondary RA understands the factory format track from the factory format track range (start CCHH to end CCHH) in the RA HEADER, and creates HA / R0 for the corresponding track on the RAID disk on the secondary center side. After completing the process on the left, the secondary RA writes a track other than Factory Format of the user data to be volume pair copied to the cache memory of the secondary center. After completing the process of writing the user data to the cache memory, the secondary RA transfers a response packet to notify the primary center side that the Volume Pair Copy operation has been completed normally.

  FIG. 26 is a diagram for explaining the operation of the third embodiment. This is limited to the case where Factory Format continues to the last track of the device after a plurality of tracks. The transfer efficiency can be further increased as compared with the first and second embodiments.

  In this way, the primary RA records the information related to the Factory Format Track (factory format and the range of the Factory Format Track (start CCHH, end CCHH)) in the RA header. A remote magnetic disk control device that can create a Factory Format Track for the Track can be realized.

  In addition, when Factory Format Tracks are distributed in multiple tracks, the primary RA picks up the track that is the factory format, and records the information related to the factory format track in the RA header. A remote magnetic disk control device that can create Factory Format Track with a single remote transfer process can be realized.

  If all continuous tracks from the end of user data to the end of the device are Factory Format Tracks, all tracks from the end of user data to the end of the device are stored in the RA Header in the remote transfer packet. It is possible to realize a remote magnetic disk control device in which the secondary RA can spontaneously create a Factory Format Track.

[Other embodiments]
In the above embodiment, the disk is described as a magnetic disk, but it can also be applied to an optical disk and a magneto-optical disk. Although described in the CKD format, it can also be applied to other track formats.

  As mentioned above, although this invention was demonstrated by embodiment, a various deformation | transformation is possible within the range of the meaning of this invention, and these are not excluded from the technical scope of this invention.

  Since the factory format was realized with the factory format flag of the TFT20 instead of the conventional method with access to the magnetic disk, it became possible to perform the factory format in about 1/100 processing time compared to the conventional method. The processing time can be greatly shortened and the costs associated therewith can be reduced.

  In the present invention, since a factory format composed of an arbitrary data pattern can be registered in the FFLT 22, a user can easily change to an arbitrary factory format in a short time.

FIG. 1 is an overall configuration diagram of a file control system according to an embodiment of the present invention. FIG. 2 is an explanatory diagram of the format processing according to the embodiment of this invention. FIG. 3 is a configuration diagram of the track management table of FIG. FIG. 4 is a format diagram of the track management table of FIG. FIG. 5 is a configuration diagram of the format list table of FIG. FIG. 6 is an explanatory diagram of the storage area of the magnetic disk of FIG. FIG. 7 is a format processing flowchart of the management terminal of FIG. FIG. 8 is a flowchart of the format process of the CM shown in FIG. FIG. 9 is a format processing flowchart of the DA of FIG. FIG. 10 is a read processing flowchart of the configuration of FIG. FIG. 11 is a write processing flowchart of the configuration of FIG. FIG. 12 is an explanatory diagram of the registration process of the format list table of FIG. FIG. 13 is a configuration diagram of a remote file control system according to another embodiment of the present invention. FIG. 14 is an explanatory diagram of the packet transfer of FIG. FIG. 15 is an explanatory diagram of the transfer packet of FIG. FIG. 16 is a copy processing flow diagram of the first embodiment of FIG. FIG. 17 is an explanatory diagram of the remote transfer operation of FIG. FIG. 18 is a copy processing flow diagram of the second embodiment of FIG. FIG. 19 is an explanatory diagram of the transfer packet of FIG. FIG. 20 is an explanatory diagram of the remote transfer operation of FIG. FIG. 21 is an explanatory diagram of another remote transfer operation of FIG. FIG. 22 is a flowchart of copy processing of the CM according to the third embodiment of FIG. 13 (part 1). FIG. 23 is a second flowchart of the CM copy process according to the third embodiment of FIG. FIG. 24 is a flowchart of RA copy processing according to the third embodiment of FIG. FIG. 25 is an explanatory diagram of the memo table of FIG. FIG. 26 is an explanatory diagram of the remote transfer operation of FIGS. FIG. 27 is an explanatory diagram of a conventional format initialization process. FIG. 28 is an explanatory diagram of the CKD format of the magnetic disk. FIG. 29 is an explanatory diagram of a magnetic disk.

Explanation of symbols

1 File control unit (FCU)
2 Magnetic disk 3 Host 4 Maintenance terminal 10 Channel adapter (CA)
12 Control unit (CM)
14 Cache memory 16 Device adapter (DA)
20 Track management table (TFT)
22 Factory format list table (FFLT)

Claims (9)

In response to an input / output request from the main host, performs data input / output control of the storage disk device, and in the remote disk control device connected to the disk control device of the secondary center,
A cache memory for storing a part of the data of the storage disk device;
A management table for storing initialization information indicating whether or not the tracks of the storage disk device have been initialized to a predetermined track format;
In response to an input / output request from the host, with reference to the management table, a control unit that creates a track format pattern indicating a track attribute for a track that has not been initialized, and
In response to a copy instruction from the primary host, the initialization information of the management table is connected to the secondary center host, and an input / output request from the secondary center host is referred to the management table to initialize A remote disk control device comprising: a remote unit for transferring to the disk control device for creating a track format pattern indicating a track attribute for a track that has not been converted to a track. The remote disk control device according to claim 1, wherein the remote unit transfers information on the uninitialized track. The remote disk control device according to claim 1, wherein the remote unit transfers the range of the uninitialized track. The remote disk control device according to claim 1, wherein the remote unit creates a track format pattern for the non-initialized track and transfers the created track format pattern. In a remote disk control method for performing data input / output control of a storage disk device in response to an input / output request from a host,
In the management table, setting information indicating whether or not the track of the storage disk device has been initialized to a predetermined track format, and initializing;
A control step for creating the track format with reference to the management table in response to an input / output request from the host;
In response to a copy instruction from the host, the management table initialization information is transferred to a disk control device that performs data input / output control of the storage disk device in response to an input / output request from the sub-center host. And a remote disk control method. 6. The remote disk control method according to claim 5, wherein the remote step transfers information on the uninitialized track. 6. The remote disk control method according to claim 5, wherein the remote step transfers the range of the uninitialized track. 6. The remote disk control method according to claim 5, wherein the remote step creates a track format for the non-initialized track and transfers the created track format. A first remote disk control device for performing data input / output control of the storage disk device in response to an input / output request from the main host;
A second remote disk control device for performing input / output control of data of the storage disk device in response to an input / output request from the secondary host;
The first and second remote disk control devices are:
A cache memory for storing a part of the data of the storage disk device;
A management table for storing initialization information indicating whether or not the tracks of the storage disk device have been initialized to a predetermined track format;
In response to an input / output request from the host, with reference to the management table, a control unit that creates a track format pattern indicating a track attribute for a track that has not been initialized, and
A remote unit for performing communication between the first and second remote disk control devices;
The remote unit of the first remote disk control device transfers initialization information of the management table to the second remote disk control device in response to a copy instruction from the main host. Disk control system.

Images