US20020087786A1

Movatterモバイル変換

Info

Publication number: US20020087786A1
Application number: US09/754,772
Authority: US
Inventors: David Burton; Robert Morton
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2001-01-04
Filing date: 2001-01-04
Publication date: 2002-07-04
Also published as: US6748486B2

Abstract

Provided is a method, system, and program for superimposing a data record in a first data format onto a storage space in a second data format. A plurality of control blocks are built in memory indicating operations to perform to transfer components of the data record in the first data format to locations in memory in the second data format. A data transfer device is signaled to access the control blocks built in the memory. The data transfer device accesses the control blocks in the memory and then transfers components of the data record in the first data format to the memory to be stored in the second data format according to the operations indicated in the control blocks.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention[0001]

The present invention relates to a system, method, and program for superimposing data records in a first data format to memory in a second data format[0002]

2. Description of the Related Art[0003]

Data stored in a direct access storage device (DASD) may be arranged in a fixed block address (FBA) format or a count-key-data (CKD) format. The FBA format involves the storage of data in blocks of fixed size. These blocks are addressed by a block number relative to the beginning of the file. An FBA block is referred to as a sector, which is addressable by the host. The CKD format is a DASD data-recording format employing self-defining record formats in which each record is represented by a count area that identifies the record and specifies its format, an optional key area that may be used to identify the data area contents, and a data area that contains the user data for the record. The CKD format provides for variable format data records.[0004]

FIG. 1 illustrates a prior art structure for a single CKD track in a CKD device. An index point (IP) is a starting point, followed by a gap (G), which indicates a break between the fields. A home address (HA) follows the first gap (G) and identifies the location of the track in the DASD and its operational status. Following the home address (HA) are the records, R.sub.[0005]0 through R.sub.n. Record zero (R.sub.0) contains either system or user data. Each following record, R.sub.1 through R.sub.n, includes a count area that identifies the record and defines the lengths of the key and data areas. The key area of each record is optional and may be used by the programmer to identify the information in the data area record. The data area contains data. The number of records (R) that can be placed on a track depends on the length of the data areas of the records, whether the records contain a key area, and the size of the gaps. Records may be of equal or unequal lengths.

Host systems may need to write data in a CKD format to a DASD that stores data in FBA blocks because most storage devices, such as hard disk drives, use the FBA format to store data in fixed blocks. Host systems, such as the International Business Machines Corporation (IBM) Enterprise System Controller (ESCON) devices, continue to utilize the CKD format because CKD permits data records to be recorded as units of contiguous signals. Whereas, with FBA, data must be dissected and distributed into a group of fixed block-size sectors. Moreover, since the introduction of the IBM System/[0006]360 in 1964, nearly all IBM large and intermediate DASD devices employ the CKD data format. For these reasons, there is a need to store CKD records in FBA devices. In fact, the prior art provides techniques for emulating the CKD format on FBA devices and for converting CKD formatted records to the FBA format. Such CKD to FBA conversion techniques are taught in U.S. Pat. Nos. 5,535,372, 6,041,386, 5,535,372, and 5,664,144, which are all incorporated herein by reference in its entirety.

The transformation of a CKD record to FBA storage is typically implemented by the storage controller processor operating under the control of microcode. One disadvantage of using the primary storage controller processor to perform the CKD to FBA transformation is the significant burden placed on the storage controller processor. Dedicating storage processor cycles to CKD to FBA conversions can affect performance with respect to other Input/Output (I/O) operations handled by the storage controller processor. To address this problem, many high end storage controller systems, such as the IBM Enterprise Storage System (ESS), include a separate dedicated Application Specific Integrated Circuit (ASIC) to transform CKD records to a FBA format for storage in a FBA DASD. However, solutions that add a special-purpose ASIC to handle the CKD to FBA conversions increases the cost of the system.[0007]

For these reasons, there is a need in the art to provide alternative techniques for superimposing a CKD record onto FBA blocks of a DASD.[0008]

SUMMARY OF THE PREFERRED EMBODIMENTS

Provided is a method, system, and program for superimposing a data record in a first data format onto a storage space in a second data format. A plurality of control blocks are built in memory indicating operations to perform to transfer components of the data record in the first data format to locations in memory in the second data format. A data transfer device is signaled to access the control blocks built in the memory. The data transfer device accesses the control blocks in the memory and then transfers components of the data record in the first data format to the memory to be stored in the second data format according to the operations indicated in the control blocks.[0009]

In further embodiments, the control blocks further instruct the data transfer device to generate an error checking code from the data record and write the error checking code into the memory to store with the data record in the second data format.[0010]

Still further, a processor may build the control blocks in memory and signal the data transfer device with the pointer to the first control block in the memory.[0011]

Yet further, the first data format may comprise a count-key-data (CKD) data format and the second data format may comprise a Fixed Block Address (FBA) format.[0012]

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numbers represent corresponding parts throughout:[0013]

FIG. 1 illustrates an arrangement of a count-key-data (CKD) record in a manner known in the art;[0014]

FIG. 2 is a block diagram illustrating a computing environment in which preferred embodiments are implemented;[0015]

FIG. 3 illustrates how a CKD record received from a host channel is stored in memory in accordance with preferred embodiments of the present invention;[0016]

FIG. 4 illustrates fields in hardware control blocks (HCBs) to provide instructions on how to superimpose CKD records onto an FBA format in memory in accordance with preferred embodiments of the present invention;[0017]

FIG. 5 is a table showing the values in the fields of seventeen hardware control blocks (HCBs) to provide the instructions in memory in accordance with an implementation of the preferred embodiments of the present invention;[0018]

FIG. 6 provides an example of how a CKD record and various other data is stored in fixed blocks in cache in memory in accordance with preferred embodiments of the present invention;[0019]

FIGS. 7 and 8 illustrate logic implemented in a processor to build the hardware control blocks (HCBs) in memory in memory in accordance with preferred embodiments of the present invention; and[0020]

FIG. 9 illustrates logic implemented in a Direct Memory Access (DMA) controller to superimpose a CKD record onto an FBA format in memory according to the instructions provided in the hardware control blocks (HCBs) in memory in accordance with preferred embodiments of the present invention.[0021]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following description, reference is made to the accompanying drawings which form a part hereof and which illustrate several embodiments of the present invention. It is understood that other embodiments may be utilized and structural and operational changes may be made without departing from the scope of the present invention.[0022]

FIG. 2 illustrates a computing environment in which preferred embodiments are implemented. A[0023]

host

4 may comprise any computing device known in the art, including servers through which other client computers can access storage or clients. Thehost4 includes at least one adaptor (not shown), such as a Fibre Channel or Small Computer System Interface (SCSI) adaptor card or any other network adaptor card known in the art. The host adaptors allow the host to communicate with astorage device6 via astorage controller8. Thestorage device6 may comprise a DASD or any other non-volatile storage device and system known in the art, including hard disk drives, tape storage, optical disks, a Redundant Array of Independent Disks (RAID) array, etc. Thestorage controller8 may comprise any control unit, storage controller, etc. that manages the transfer of data between an I/O device, such asstorage device6, and one or more hosts.

In preferred embodiments, the[0024]

storage controller

8 includes amain processor10, amemory12, and an I/O manager14. In preferred embodiments, the I/O manager14 comprises one or more integrated circuit devices that manage the transfer of data between thestorage device6 andhost4. In preferred embodiments, data is transferred among thehost4,memory12, andstorage device6 via the I/O manager14 without requiring theprocessor10 to be involved in the data movement operations. This arrangement relieves themain processor10 from the otherwise substantially burdensome activity of directly controlling the transfer of data and performing conversions of CKD data records to FBA blocks, thereby improvingoverall storage controller8 performance.

The[0025]

processor

10 includes aprocessor memory16, which may comprise an onboard cache or local memory device used by theprocessor10. Theprocessor memory16 may be attached to theprocessor10 via a local processor bus. Thememory12 may comprise one or more volatile, e.g., DRAMs, SRAMs, etc., or non-volatile memory device used to cache and buffer data. Thememory12 includes at least two different sections, ahost channel buffer18 to buffer CKD records received from thehost4 to write to thestorage device6 and acache20, which provides cache storage for the I/O operations managed by thestorage controller8.

The I/[0026]

O manager

14 includes a host bus22 for interfacing withhost4 systems; astorage bus24 for interfacing with thestorage device6; amemory bus26 for interfacing with thememory12; aprocessor bus28 for interfacing with theprocessor10; and a Direct Memory Access (DMA) controller30 to manage DMA channels providing direct communication from thecache12 to thestorage device6 that entirely bypasses themain processor10 of thestorage controller8. The

busses

22,24,26, and28 may comprise a Peripheral Component Interconnect (PCI) bus, Industry Standard Architecture (ISA) bus or any other communication interface device known in the art.

A host adaptor[0027]32 provides for the data transfer protocol processing, such as SCSI or Fibre Channel protocol, to move data between the I/O manager14 andhost4. A storage adaptor32 provides for data transfer protocol processing between the I/O manager14 and thestorage device6. The host30 and storage34 adaptors would each include a DMA controller to transfer data along DMA channels between thehost4 andcache12 andcache12 andstorage6 without involving thestorage controller8

main processor

10.

In preferred embodiments, the[0028]

processor

10,cache12, I/O manager14, adaptors32,34, and DMA controller30 are all on the same controller card or board. In alternative embodiments, any one or more of these components may be on separate cards all within thestorage controller8. Further, although

multiple busses

22,24,26, and28 are described in the implementation of FIG. 1, fewer busses may be used to provide communication between the DMA controller30 and thehost4,processor10,memory12, andstorage device6.

In preferred embodiments, the[0029]

processor

10 builds hardware control blocks (HCBs) in thecache20 to instruct the DMA controller30 on how to convert a CKD record received from thehost4 into a format to store in the FBA blocks incache20. Once the CKD record is transferred to FBA blocks in thecache20, the CKD record may be destaged to thestorage device6 to store in the FBA format. Thehost4 transfers CKD records to the host adaptor32, which then buffers the CKD record in thehost channel buffer18. FIG. 3 illustrates a CKD record50 stored in thehost channel buffer18. Apointer58 to the CKD record in thehost channel buffer18 is returned to theprocessor10.

As discussed, the DMA controller[0030]30 processes hardware control blocks (HCBs) to transfer the CKD record 50 to 512 byte FBA blocks incache20. Theprocessor10 sets values in the hardware control blocks (HCBs) to instruct the DMA controller30 on how to transfer the data from thehost channel buffer18 to thecache20. In the described implementations, theprocessor10 would set values in seventeen hardware control blocks (HCBs), each comprised of 64 bytes in cache. Each of the hardware control blocks (HCBs) instruct the DMA controller30 to read data from thehost channel buffer18, XOR read data to generate a longitudinal redundancy check (LRC) check code, or write CKD or LRC data to the fixed block locations incache20. Each of the hardware control blocks (HCBs) include the fields shown in FIG. 4 and described below to inform and instruct the DMA controller30:

Memory Location Field[0031]60: includes a code indicating whether to perform the read/write operation with respect to a location in thememory12, including acache20 address orhost channel buffer18 address, or a location in theprocessor memory16. For instance, the code 0001 may indicate that thememory12 is the target of the read/write operation and the code 0101 may indicate that theprocessor memory16 is the target.

Direction Field[0032]62: includes a code indicating whether the operation is a read or write operation to the target location. For instance, a value of “0” in this field may indicate a write operation and a value of “1” may indicate a read.

Linkage Field[0033]64: In described implementations, the hardware control blocks (HCBs) are organized in a list, where each HCB, except the last HCB, includes a flag indicating whether the next HCB incache20 is to be included in the current DMA operation. Thelinkage field64 includes a code indicating whether the HCB is a middle HCB (e.g., “01”), a last HCB (e.g., “01”) or the first HCB (e.g., “10”).

Sector Mode Field[0034]66: includes a code indicating whether the address of the target location at which to perform the operation is a virtual address (e.g., “100”) or a real FBA address (e.g., “000”) directly corresponding to an address inmemory12. Addresses in thecache20 are virtual addresses, where a cache manager provides a cache directory associating virtual cache addresses with physical blocks in the cache. In this way, the DMA controller may view contiguous virtual addresses that the cache manager maps to non-contiguous blocks in thecache20. The addresses in thehost channel buffer18 are real addresses, meaning that the address of the target location corresponds directly to a fixed block in thebuffer18. Further, certain addresses in thecache20 may comprise real addresses.

Generate LRC Field[0035]68: includes code indicating whether to XOR data being written to generate an LRC check code.

IRQ Enable[0036]70: includes code indicating whether to instruct theprocessor10 that the DMA controller30 has completed superimposing the CKD record50 onto fixed block addresses in thecache20.

XOR Last Field[0037]72: In a DMA controller, when the XOR last mode is not enabled, then data is XORed without writing. XOR last mode indicates that the XOR operation on the data has completed and the DMA controller writes the XORed data. Thisfield72 includes a code indicating whether XOR last mode is enabled to instruct the DMA controller30 to write the XORed data.

Length Field[0038]74: includes a code indicating the number of bytes involved in the transfer.

Target Address Field[0039]76: Indicates a target address of the read/write DMA controller30 operation, which may comprise amicroprocessor memory16 ormemory12 address location.

Source Address Field[0040]78: Indicates a source address of the read/write DMA controller30 operation, which may comprise amicroprocessor memory16 ormemory12 address location.

LRC Partial Result Field[0041]80: Includes the partial LRC check code as the XOR operations on the data being read is calculated.

FIG. 5 provides a table including possible values in a suggested implementation for the above described fields for each of the seventeen hardware control blocks (HCBs),[0042]

HCB

1 toHCB17, used by the DMA controller30. FIG. 6 illustrates how thecount52, key54, anddata56 fields in the CKD record50 in thehost channel buffer18 are mapped to record header100, key104, anddata110a, b, clocations in 512 byte FBA blocks118,120, and122 in thecache20. The key54 anddata56 fields may have zero or more bytes. In certain implementations, theprocessor10 converts thecount field52 into a record header. The format of the record header100 is specific to the controller and is known in the art. Theprocessor10 builds the record header100 in theprocessor memory16. The record header100 is used by thestorage controller8 and may comprise a fixed number of bytes, such as 30 bytes. The DMA controller30, in response to executing the hardware control blocks (HCBs), would insert acount LRC102,key LRC108, anddata LRC114 providing LRC check codes for the count100, key104, anddata110a, b, cportions, respectively, of the CKD record50. In the example of FIG. 6, the data portion of the CKD record50 is mapped to threedata portions110a, b, c, that span three 512 byte fixed blocks (sectors)118,120, and122 incache20. The DMA controller30

further inserts pads

106 and112 betweenkey data104 and thekey LRC106, and thedata110cand thedata LRC114. The

pads

106 and112 ensure that the

LRC codes

108 and114 begin on the second half of a word, where a word comprises a four byte portion of the 512 byte sector. Further,pad116 fills the remainder of thesector122. In such implementations, each CKD record spans one or more CKD records, but no two different CKD records share the same 512 byte sector.

FIG. 7 illustrates logic implemented in the firmware or code of the[0043]

processor

10 to encode each of the hardware control block (HCB) fields based on the CKD record50 in thehost channel buffer18. Control begins atblock150 with theprocessor10 receiving a pointer58 (FIG. 3) from the host adaptor32 to a CKD record50 in thehost channel buffer18. In response, theprocessor10 requests (at block152) seventeen contiguous64 byte blocks incache20 from the cache manager for the seventeen hardware control blocks (HCBs) that will be built. Atblock154, theprocessor10 allocatessufficient cache20 memory to hold the CKD record.Cache memory20 is typically allocated in fixed sized cache pages. Each page contains a fixed number of 512 byte blocks. The cache pages used to store the CKD record are accessed using a virtual address space so that non-contiguous cache pages can be accessed as one contiguous address space. Thus, the DMA controller30 will superimpose the CKD records on the virtual address space incache20. In the described implementations, theprocessor10 accesses the fixed blocks incache20 for the HCBs using real addressing. Theprocessor10 uses (at block156) thepointer58 to access the CKD record50 and read thecount field52. Theprocessor10 builds the record header100 from thecount field52 data in theprocessor memory16. Fromblocks158 to200, theprocessor10 sets all the values in the seventeen hardware control blocks (HCBs) to instruct the DMA controller30 to transfer the CKD records to fixed block sectors incache20.

At[0044]

block

158, theprocessor10 sets the fields forHCB1 as shown in FIG. 5 to instruct the DMA controller30 to write (as indicated in the direction field62) the record header data from theprocessor memory16 location (as indicated in the source address78) intocache20 starting at the first allocated virtual address (indicated as the target address76) provided by the cache manager for the length of the record header100 (length field74), such as the 30 byte record header used in certain implementations discussed herein. Further,HCB1 is set to instruct the DMA controller30 to generate LRC data for the record header data (as indicated in the generate LRC field68) while writing the record header data tocache20. The LRC data is accumulated in the LRCpartial result field80. Atblock160, theprocessor10 sets the fields forHCB2 as shown in FIG. 5 to instruct the DMA controller30 to read (as indicated in the direction field62) the record header LRC value from the LRC partial result field80 (as indicated in the target address76), which is a real address in cache20 (as indicated by thememory location60 andsector mode66 fields). Atblock162, the processor sets the fields forHCB3 as shown in FIG. 5 to instruct the DMA controller30 to write (as indicated in the direction field62) the record header LRC value102 (FIG. 6) just read, into a cache virtual address (as indicated by thememory location60 andsector mode66 fields) location (the target address76), which is the immediate virtual address following the record header data100 (FIG. 6) (or following the length of the record header data100 in thelength field74 of HCB1).

At[0045]

block

164, theprocessor10 sets the fields forHCB4 as shown in FIG. 5 to instruct the DMA controller30 to read (as indicated in the direction field62) the entire key data (indicated in the length field74) from a real address (as indicated in the sector mode66) in ahost channel buffer18 location (the target address76). Atblock166, theprocessor10 sets the fields forHCB5 as shown in FIG. 5 to instruct the DMA controller30 to write (as indicated in the direction field62) the key data54 (FIG. 3) read, according toHCB4, intocache20 starting at the allocated virtual (as indicated in the sector mode66) address (indicated as the target address76), shown104 in FIG. 6, immediately following thecount LRC value102. Further,HCB5 is set to instruct the DMA controller30 to generate LRC data for key count data (as indicated in the generate LRC field68) while writing the key data tocache20 blocks.

At[0046]

block

168, theprocessor10 determines the number of bytes from the allocated virtual address immediately following the end of the key data to the beginning of the next second half of a word. A word comprises one of contiguous four byte pieces of a512 byte sector. The second half of a word comprises the last two bytes. Thus, atblock168, theprocessor10 determines the number of bytes from the end of the key data104 (FIG. 6) to the next last two bytes of a word, which may be in the current word if the key data ends in the first half of a word or in the next word if the key data ends in the second half of the current word. At block170, the processor setsHCB6 as shown in FIG. 5 to instruct the DMA controller30 to read a zero value (which is maintained at a real address indicated as the target address76) for the number of determined bytes (specified in the length field74). These read zeros are used to pad theblock106 from the end of thekey data104 to the beginning of the next second half of a word. Atblock172, theprocessor10 sets the fields forHCB7 as shown in FIG. 5 to instruct the DMA controller30 to write (as indicated in the direction field62) the pad of zeroes106 (FIG. 6) into a cache virtual address (as indicated by thememory location60 andsector mode66 fields) location (the target address76), which is the immediate virtual address following the key data106 (FIG. 6).

With respect to FIG. 8, at[0047]

block

176, theprocessor10 sets the fields forHCB8 as shown in FIG. 5 to instruct the DMA controller30 to read the key LRC value from the LRCpartial result field80 of HCB5 (as indicated in the target address76), which is a real address in cache20 (as indicated by thememory location60 andsector mode66 fields). Atblock178, theprocessor10 sets the fields forHCB9 as shown in FIG. 5 to instruct the DMA controller30 to write (as indicated in the direction field62) the just read key LRC value into a cache virtual address (as indicated by thememory location60 andsector mode66 fields) location (the target address76), which is the immediate virtual address shown aslocation108 following thepad106.

At[0048]

block

180, theprocessor10 sets the fields forHCB10 as shown in FIG. 5 to instruct the DMA controller30 to read (as indicated in the direction field62) the entire data56 (FIG. 3) (indicated in the length field74) from a real address (as indicated in the sector mode66) in ahost channel buffer18 location (the target address76). Atblock182, theprocessor10 sets the fields forHCB11 as shown in FIG. 5 to instruct the DMA controller30 to write (as indicated in the direction field62) the data56 (FIG. 3) read according toHCB10 intocache20 starting at the allocated virtual (as indicated in the sector mode66) address (indicated as the target address76) immediately following thekey LRC value108 atlocation110a. Further,HCB11 is set to instruct the DMA controller30 to generate LRC data for the data56 (as indicated in the generate LRC field68) while writing the data tocache20 blocks as shown as110a, b, cin FIG. 6.

At[0049]

block

184, theprocessor10 determines the number of bytes from the allocated virtual address immediately following the end of thedata110c(FIG. 6) to the beginning of the next second half of a word insector122. Atblock186, theprocessor10 sets HCB12 as shown in FIG. 5 to instruct the DMA controller30 to read a zero value (which is maintained at a real address indicated as the target address76) for the number of determined bytes at block184 (specified in the length field74). The zeros read are used to pad the block112 (FIG. 6) from the end of thedata110cto the beginning of the next second half of a word insector122. Atblock188, theprocessor10 sets the fields forHCB13 as shown in FIG. 5 to instruct the DMA controller30 to write (as indicated in the direction field62) thepad112 of zeroes (FIG. 6) into a cache virtual address (as indicated by thememory location60 andsector mode66 fields) location (the target address76), which is the immediatevirtual address location112 following thedata110c.

At[0050]

block

190, theprocessor10 sets the fields forHCB14 as shown in FIG. 5 to instruct the DMA controller30 to read the data LRC value from the LRC partial result field80 (as indicated in the target address76) set byHCB11, which is a real address in cache20 (as indicated by thememory location60 andsector mode66 fields). Atblock192, theprocessor10 sets the fields forHCB15 as shown in FIG. 5 to instruct the DMA controller30 to write (as indicated in the direction field62) the data LRC value just read into a cache virtual address (as indicated by thememory location60 andsector mode66 fields) starting at the location (the target address76) that is the immediate virtual address114 (FIG. 6) following the pad112 (or following the length of the pad indicated in thelength field74 ofHCBs12 and13).

At[0051]

block

194, theprocessor10 determines the number of bytes from the allocated virtual address immediately following the end of the data LRC114 (FIG. 6) to the end of thecurrent sector122. Atblock196, theprocessor10 sets HCB16 as shown in FIG. 5 to instruct the DMA controller30 to read a zero value (which is maintained at a real address indicated as the target address76) for the number of determined bytes at block194 (specified in the length field74). These read zeros are used to pad thesector122 from thedata LRC114 to the end of thecurrent sector122. Atblock198, theprocessor10 sets the fields forHCB17 as shown in FIG. 5 to instruct the DMA controller30 to write (as indicated in the direction field62) the pad of zeroes (FIG. 6) into a cache virtual address (as indicated by thememory location60 andsector mode66 fields) location (the target address76), which is the virtual address shown atblock116 in FIG. 6 immediately following thedata LRC114. Theprocessor10 would further set the IRQ enablefield70 atHCB17 to instruct the DMA controller30 to signal an interrupt to indicate to theprocessor10 that the CKD data in thehost channel buffer18 has been completely mapped to sectors in thecache20, including LRC data and pads, as shown by way of example in FIG. 6. FIG. 6 illustrates an example of how a CKD data record maps to FBA sector blocks incache20. However, different sized CKD records having different length count, key and data fields would map to thecache20 FBA sectors differently than shown in FIG. 6.

After building all the hardware control blocks (HCBs) into[0052]

cache

20, theprocessor10 returns (at block200) a pointer to the first hardware control block (HCB1) in thecache20 to the DMA controller30. FIG. 9 illustrates logic executed by the DMA controller30 to process the hardware control blocks generated intocache20. Control begins atblock250 with the DMA controller30 receiving an encoded address that contains an index to the first hardware control block (HCB1) incache20. In response, the DMA controller30 builds (at block252) a pointer to the first HCB using the index in the encoded address and then reads the 64 bytes from the pointer, which comprisesHCB1. The DMA controller30 performs (at block254) the actions specified in the fields of theread HCB1. In certain implementations, the DMA controller may read the entire64 bytes from cache before performing the action specified in the hardware control block (HCB). Alternatively, the DMA controller30 may read fields from the HCB and then perform the specified operation before reading and executing further instructions from the HCB. In addition, the DMA controller30 may choose to prefetch more than one 64 byte HCB if the linkage field indicates linked HCBs. After performing all actions specified in the hardware control block (HCB), if (at block256) the just executed hardware control block (HCB) is not the last HCB as indicated in thelinkage field64, then the DMA controller30 accesses (at block258) the next 64 bytes of memory following the previously executed HCB, i.e., the next HCB. In certain implementations, the HCBs are accessed using real addressing. Control then returns to block254 to perform the actions indicated in the fields of the next accessed hardware control block (HCB). If (at block256) the processed HCB is the last, then the DMA controller30 sends (at block260) an interrupt signal to theprocessor10 indicating that the CKD record has been superimposed onto theFBA cache20, as instructed by the value in the IRQ enablefield70.

While the DMA controller[0053]30 is processing control blocks, theprocessor10 may build additional sets of hardware control blocks incache20 for additional CKD records in thehost channel buffer18. Theprocessor10 would provide the DMA controller30 with an encoded address containing an index to the first hardware control block (HCB) in the additional set to continue transforming CKD records into thecache20 FBA fixed blocks.

Described embodiments provide a technique for instructing a DMA controller[0054]30 to superimpose CKD records onto FBA formatted storage blocks. In this way, all the CKD to FBA conversion operations are handled by the DMA controller30 and not the processor. Theprocessor10 only has to set-up the hardware control blocks (HCB). In this way,processor10 performance is substantially improved because the processor is not burdened with the substantial processing task of superimposing a CKD record onto a FBA blocks, including generating the LRC codes and pads to “fit” the CKD record into the FBA.

The following describes some additional implementations.[0055]

The preferred embodiments may be implemented as a method, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The term “article of manufacture” as used herein refers to code or logic implemented in hardware logic (e.g., an integrated circuit chip, Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), etc.) or a computer readable medium (e.g., magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, optical disks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, firmware, programmable logic, etc.). Code in the computer readable medium is accessed and executed by a processor. The code in which preferred embodiments are implemented may further be accessible through a transmission media or from a file server over a network. In such cases, the article of manufacture in which the code is implemented may comprise a transmission media, such as a network transmission line, wireless transmission media, signals propagating through space, radio waves, infrared signals, etc. Of course, those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope of the present invention, and that the article of manufacture may comprise any information bearing medium known in the art.[0056]

The preferred logic of FIGS.[0057]7-9 describe specific operations occurring in a particular order. In alternative embodiments, certain of the logic operations may be performed in a different order, modified or removed and still implement preferred embodiments of the present invention. Morever, steps may be added to the above described logic and still conform to the preferred embodiments. Further, operations described herein may occur sequentially or certain operations may be processed in parallel.

In preferred embodiments, data was transferred in sectors. In alternative embodiments, blocks of data may be transferred in storage units other than sectors.[0058]

In the described embodiments, the hardware control block had particular fields at particular bit and byte locations. In alternative embodiments, different fields may be included in the hardware control blocks and the[0059]

processor

10 may build a different number of hardware control blocks than those described herein to accomplish the conversion of CKD records to a FBA format.

As discussed, in certain implementations, the[0060]

storage device

6 may comprise a RAID device. In RAID implementations, thestorage controller8 can perform CKD mapping on fixed blocks in cache using only a RAID engine. With the described implementations, no specialized CKD hardware is need as the DMA controller30 maps the CKD records to the fixed blocks incache20. The RAID engine would then just destage the CKD records superimposed into the fixed blocks incache20 to theRAID storage device8 in a manner known in the art.

In the described implementations, a data record in a CKD format is superimposed onto a FBA formatted block(s). In additional implementations, the hardware control blocks may define the operations needed to superimpose a data record in a format other than CKD, e.g., SCSI, etc., onto storage sectors in a format other than FBA.[0061]

In described implementations, a DMA controller accesses the hardware control blocks generated by the processor to perform the operations to superimpose the CKD records into FBA blocks in cache memory. In alternative embodiments, data transfer devices other than a DMA controller may use the blocks to perform the operations to superimpose the CKD record into FBA blocks. Such data transfer devices may comprises a dedicated hardware integrated circuit, such as a FPGA, ASIC, etc., or a processor operating under program control.[0062]

In described implementations, the processor allocated and set the value in the hardware control blocks. In alternative implementations, a device other than the processor may build the hardware control blocks (HCBs) for the DMA controller to use.[0063]

In the described implementations, a[0064]

single memory device

12 was used to implement thehost channel buffer18 andcache20. Additionally, multiple memory devices may be used to implementbuffer18 andcache20. Further, thebuffer18 andcache20 may be implemented on the same memory device(s) or separate memory device(s).

The foregoing description of the preferred embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.[0065]

Claims

What is claimed is:

1. A method for superimposing a data record in a first data format in a second data format in memory, comprising:

building a plurality of control blocks in the memory indicating operations to perform to transfer components of the data record in the first data format to locations in memory in the second data format;

signaling a data transfer device to access the control blocks built in the memory;

accessing, with the data transfer device, the control blocks in the memory; and

transferring, with the data transfer device, components of the data record in the first data format to the memory to be stored in the second data format according to the operations indicated in the control blocks.

2. The method ofclaim 1, wherein signaling the data transfer device includes providing a pointer to a first control block of the plurality of control blocks, wherein the data transfer device uses the pointer to access the control blocks in the memory.

3. The method ofclaim 2, wherein a processor builds the control blocks in memory and signals the data transfer device with the pointer to the first control block in the memory.

4. The method ofclaim 1, wherein the control blocks further instruct the data transfer device to generate an error checking code from the data record and write the error checking code into the memory to store with the data record in the second data format.

5. The method ofclaim 1, wherein the second data format stores data in fixed blocks in the memory, wherein the control blocks further instruct the data transfer device to transfer the data record to fixed blocks in the memory such that the data record is stored in an integral number of fixed blocks in the second data format.

6. The method ofclaim 1, wherein the data record in the first data format comprises multiple component parts, and wherein the control blocks further instruct the data transfer device to generate an error checking code for each component part and store the error checking codes with the component parts in the second data format.

7. The method ofclaim 6, wherein the control blocks further instruct the data transfer device to write one component part to the memory, followed by writing the error checking code for the component part to the memory until all the component parts are written to the memory in the second data format.

8. The method ofclaim 7, wherein the control blocks further instruct the data transfer device to write a pad of values between at least one of the component parts and the error checking code for the component part to ensure that the error checking code is written to a particular location in the memory in the second data format.

9. The method ofclaim 6, wherein the first data format comprises a count-key-data (CKD) record format, and wherein the count portion, key portion, and data portion of the CKD record each comprise one component part of the data record to write to the memory in the second data format with the error checking codes for the count portion, key portion, and data portion.

10. The method ofclaim 1, wherein the memory comprises a volatile memory device, further comprising:

destaging the data record in the second format in the volatile memory device to a storage device as part of a destage operation, wherein the storage device stores data in the second data format.

11. The method ofclaim 1, wherein the first data format comprises a count-key-data (CKD) data format and the second data format comprises a Fixed Block Address (FBA) format.

12. A system for superimposing a data record in a first data format onto a second data format, comprising:

a first device;

a second device;

a memory accessible to the first and second devices;

logic implemented in the first device, wherein the logic causes the first device to perform:

(i) building a plurality of control blocks in the memory indicating operations to perform to transfer components of the data record in the first data format to locations in memory in the second data format;

(ii) for signaling a data transfer device to access the control blocks built in the memory;

logic implemented in the second device, wherein the logic causes the second device to perform:

(i) accessing the control blocks in the memory; and

(ii) transferring components of the data record in the first data format to the memory to be stored in the second data format according to the operations indicated in the control blocks.

13. The system ofclaim 12, wherein the logic for signaling the second device includes providing a pointer to a first control block of the plurality of control blocks, wherein the second device uses the pointer to access the control blocks in the memory.

14. The system ofclaim 13, wherein the first device comprises a processor.

15. The system ofclaim 12, wherein the control blocks further instruct the second device to generate an error checking code from the data record and write the error checking code into the memory to store with the data record in the second data format.

16. The system ofclaim 12, wherein the second data format stores data in fixed blocks in the memory, wherein the control blocks further instruct the second device to transfer the data record to fixed blocks in the memory such that the data record is stored in an integral number of fixed blocks in the second data format.

17. The system ofclaim 12, wherein the data record in the first data format comprises multiple component parts, and wherein the control blocks further instruct the data transfer device to generate an error checking code for each component part and store the error checking codes with the component parts in the second data format.

18. The system ofclaim 17, wherein the control blocks further instruct the second device to write one component part to the memory, followed by writing the error checking code for the component part to the memory until all the component parts are written to the memory in the second data format.

19. The system ofclaim 18, wherein the control blocks further instruct the second device to write a pad of values between at least one of the component parts and the error checking code for the component part to ensure that the error checking code is written to a particular location in the memory in the second data format.

20. The system ofclaim 17, wherein the first data format comprises a count-key-data (CKD) record format, and wherein the count portion, key portion, and data portion of the CKD record each comprise one component part of the data record to write to the memory in the second data format with the error checking codes for the count portion, key portion, and data portion.

21. An article of manufacture of for superimposing a data record in a first data format onto a second data format in memory, wherein the article of manufacture includes first device logic and second device logic to control a first and second devices, respectively, comprising:

building, with the first device logic, a plurality of control blocks in the memory indicating operations to perform to transfer components of the data record in the first data format to locations in memory in the second data format;

signaling, with the first device logic, the second device to access the control blocks built in the memory;

accessing, with the second device logic, the control blocks in the memory; and

transferring, with the second device logic, components of the data record in the first data format to the memory to be stored in the second data format according to the operations indicated in the control blocks.

22. The article of manufacture ofclaim 21, wherein signaling the second device includes providing a pointer to a first control block of the plurality of control blocks, wherein the second device logic uses the pointer to access the control blocks in the memory.

23. The article of manufacture ofclaim 21, wherein the first device comprises a processor.

24. The article of manufacture ofclaim 21, wherein the control blocks further instruct the second device logic to generate an error checking code from the data record and write the error checking code into the memory to store with the data record in the second data format.

25. The article of manufacture ofclaim 21, wherein the second data format stores data in fixed blocks in the memory, wherein the control blocks further instruct the data transfer device to transfer the data record to fixed blocks in the memory such that the data record is stored in an integral number of fixed blocks in the second data format.

26. The article of manufacture ofclaim 21, wherein the data record in the first data format comprises multiple component parts, and wherein the control blocks further instruct the data transfer device to generate an error checking code for each component part and store the error checking codes with the component parts in the second data format.

27. The article of manufacture ofclaim 26, wherein the control blocks further instruct the second device logic to write one component part to the memory, followed by writing the error checking code for the component part to the memory until all the component parts are written to the memory in the second data format.

28. The article of manufacture ofclaim 27, wherein the control blocks further instruct the second device logic to write a pad of values between at least one of the component parts and the error checking code for the component part to ensure that the error checking code is written to a particular location in the memory in the second data format.

29. The article of manufacture ofclaim 26, wherein the first data format comprises a count-key-data (CKD) record format, and wherein the count portion, key portion, and data portion of the CKD record each comprise one component part of the data record to write to the memory in the second data format with the error checking codes for the count portion, key portion, and data portion.

30. The article of manufacture ofclaim 21, wherein the memory comprises a volatile memory device, further comprising:

destaging, with the second device logic, the data record in the second format in the volatile memory device to a storage device as part of a destage operation, wherein the storage device stores data in the second data format.

31. The article of manufacture ofclaim 21, wherein the first data format comprises a count-key-data (CKD) data format and the second data format comprises a Fixed Block Address (FBA) format.