Virtualization of physical storage using size optimized hierarchical tables

[0001] The present invention relates generally to the field of computer storage subsystems and, in particular, to efficiently and dynamically allocating physical storage among emulated storage devices.

[0002] In a typical large-scale data processing system, physical storage devices (which may include individual storage disk units, RAID (“redundant array of independent disks”) arrays, or a combination) are attached through a controller. One or more host systems are also attached to the controller and may read from and write to attached storage. Physical storage may be “virtualized” whereby a host sends a command to access data on a “logical” volume on a virtual or “emulated” storage device and the controller maps the virtual address into the address of the physical storage space in which the desired data resides. Such an arrangement isolates the hosts from the storage devices, allowing an emulated device to include storage space in more than one physical device. An advantage of virtual storage architecture is that a variety of different types of storage devices may be used and may be physically separated from each other and from the hosts. Moreover, physical storage may be added, removed, relocated or otherwise reorganized by merely updating the address map. Emulated devices may be reorganized in the same manner. Due to command translations and address mapping in the controller, the physical storage is hidden from the hosts which only “see” emulated devices.

[0003] One method of virtualizing storage includes mapping each logical volume to a physical volume on a one-to-one basis. More flexible is a method in which the physical devices are divided into “segments” which are then allocated among the emulated devices. Under the latter method, several segments may be concatenated and assigned to a single emulated device. Tables maintain lists of identifiers of the segments assigned to each device. For example, assume a storage subsystem with D=32 K emulated devices and having physical storage space divided into S=1 M segments. For maximum flexibility, the controller should be able to allocate all of segments to a single emulated device and should also be able to allocate the segments among all of the emulated devices, in equal portions or otherwise. In order to meet the first qualification, each of D tables would require entry spaces and the total number of entries would be S*D=32G. If each segment ID is four bytes (which is S=1M=2³⁰ rounded to the next highest whole byte) the space required by all of the tables would total 128 GB. If all of the segments were allocated to a single emulated device, only one of the 32K tables would have any entries (it would be full) and the remaining 32K−1 tables would be empty. Thus, 128 GB−4M, or 99.997%, of table storage space in the controller would be empty.

[0004] It will be appreciated that such a technique is extremely inefficient. Consequently, there remains a need for storage subsystem in which emulated device tables are defined in such a manner as to minimize the controller space required to store the tables while maintaining the flexibility to allocate the segments among any or all of the devices in any desired fashion, including allocating all segments to a single device.

[0005] The present invention provides a method and system for a storage controller to manage the allocation of physical storage segments to emulated devices. The space within the emulated devices is identified by a logical address. The storage controller is in communication with at least one host system and at least one physical storage device. A plurality of tables, each having entry spaces to store segment identification or segment table and entry identification, is established in the storage controller. The tables define a tree structure by which a segment to be accessed is identified by mapping a logical address through the tables to a segment identification. The number of tables, the number of pages in each table, and the number of entries in each page are selected to optimize the amount of space in the storage controller required by the tables and to ensure that the segments may be allocated in any proportion among the emulated storage devices, including all of the segments being allocated to a single emulated device. Moreover, the allocation of segments to emulated storage space is dynamic by changing the contents of the tables.

[0013] FIG. 1 is a block diagram of a data processing system 100 in which the present invention may be implemented. The system 100 includes one or more host systems 102 and one or more physical storage devices 104, all attached to a storage controller 110. The physical storage devices 104 may include individual disk units, RAID array units, or a combination. The physical storage devices 104 may also include compatible devices, disparate devices, or a combination. The controller 110 includes one or more host interfaces 112, to which the hosts 102 are attached, and software which defines one or more emulated devices, identified collectively in FIG. 1 by reference numeral 114. Segment tables 116, stored in a memory 118 (which may be within the controller 110 or elsewhere), define the emulated devices and contain the address mapping necessary for a host 102 to access desired data on a physical device 104. A processing unit 120 is operable to execute instructions (which may be stored in the memory 118 or elsewhere) to map the emulated storage devices 114 to the physical storage devices 104.

[0014] As previously noted, one method by which physical storage space may be mapped to virtual or emulated storage space includes a one-to-one address mapping. FIG. 2 is a schematic diagram of a segment table structure in which one-to-one mapping is employed. An emulated device table 200, stored in memory of the controller, is divided into a plurality of sub-tables 202₀–202_D-1, such as sub-tables 202_X and 202_Z. The device table 200 includes one sub-table 202 for each of D emulated devices. Each sub-table includes enough space to store S entries in the event any single emulated device is allocated all S of the physical device segments. However, as also previously noted, the method illustrated in FIG. 1 is inefficient in that much of the memory space used by the table 200 may be wasted at any one time, particularly if a single emulated device is allocated all S of the physical device segments.

[0015] By contrast, a method of the present invention provides a more efficient storage architecture in which storage segments are dynamically allocated among the emulated devices in such a fashion as to minimize the controller space required to store the segment definition tables while maintaining the flexibility to allocate the segments among any or all of the devices in any desired fashion, including allocating all segments to a single device. FIG. 3 is a schematic illustration of segment table architecture 300 of the present invention. Physical storage space 302 includes N devices which are divided into S segments, such as a segment 304 of physical device N₁. Each segment is identified by the ID of the storage space (physical device or array) in which the segment is located and by a segment number within the storage space.

[0016] An emulated device table 306 includes D entries, one for each emulated device. As will be understood with reference to details set forth below, each entry points to a segment table and a segment table page within the segment table. The architecture further includes a plurality of segment tables having entries which point to other segment tables or to physical storage segments 302. A first segment table 310 stores segment IDs. The first segment table 310 is divided into D sub-tables or pages, such as page 312; each page has storage space for i=S/D entries. Thus, the first segment table 310 has one entry for each physical segment. If the physical segments are to be equally allocated among all of the emulated devices, each entry in the device table 306, such as entry 0000, points to a page in the first segment table, such as page 312, in a one-to-one mapping relationship. In this single segment table configuration, each emulated device may have up to i=S/D segments.

[0017] Additional segment tables may be included in the architecture 300 of the present invention to avoid the limitation imposed by a single segment table. A second segment table 320 stores the IDs of the first segment table pages. Because the second segment table 320 is not allocated to an emulated device until the device would require at least two pages in the first segment table 310, the second segment table is itself divided into S/(2i) pages of j entries each. By way of example, an emulated device 0001 points to a page 322 of the second segment table 320 which itself may point to between 2 and j first table segment pages, resulting in a capacity to allocate between i+1 and i*j segments to any single emulated device.

[0018] A third segment table 330 may be used to move beyond the i*j segment barrier of two segment tables. Because the third segment table 330 is not allocated to an emulated device until the device would require at least i*j+1 segments, the third segment table is itself divided into S/(i*j) pages of k entries each. By way of example, an emulated device 0023 points to a page 332 of the third segment table 330 and, through pointers in the second and first segment tables, may have a capacity to be allocated between i*j+1 and i*j*k segments of the physical storage 302.

[0019] Similarly, a fourth segment table 340 may be used to move beyond the i*j*k segment barrier of three segment tables. Because the fourth segment table 340 is not allocated to an emulated device until the device would require at least i*j*k+1 segments, the third segment table is itself divided into S/(i*j*k) pages of l entries each. By way of example, an emulated device 0042 points to a page 342 of the fourth segment table 340 and, through pointers in the third, second and first segment tables, may have a capacity to be allocated between i*j*k+1 and i*j*k*l segments of the physical storage 302. Additional segment tables may be employed to achieve even greater emulated device capacity but will not be discussed herein.

[0020] The size of the segment identifier is dependent upon the number of attached physical devices and the number of segments in each. Put another way, the segment identifier size determines the maximum number of segments S which are available for allocation to emulated devices and should be chosen such that it is always possible to assign a unique-identifier to every physical segment in the storage facility. For example, 16 physical devices can be identified with a 4-bit number (16=2⁴). If each device has no more than 64 K segments, each segment may be identified with a 16-bit number (64 K=2¹⁶). Thus, uniqueness of segment identifiers can be accomplished with 20 bits.

[0021] In order to fully take advantage of the hierarchical table “tree” configuration, the present invention provides for the determination of an optimum number of segment tables and the optimum size of the pages in each table (i.e., the number of entries in each page). Because the controller software traverses the table tree each time an I/O operation is executed, the resulting processing speed overhead is proportional to the number of segment table levels. On the other hand, an I/O operation may typically occur on the order of thousands of instruction cycles. Thus, the sensitivity to the number of table levels is less than it would be if I/O operations were more frequent and it may be desireable to increase the number of table levels in exchange for reduced memory required in the controller to store the tables.

[0022] Some assumptions or boundaries may be made to assist the optimization process. However, the assumptions stated herein are not meant to limit the present invention and it will be understood that other assumptions, or none at all, may be used. For purposes of the description herein, the assumptions are:

• • [0023] a) The size of each page table will be limited to an integral multiple of 2. The table identifier may be determined by a specific bit range within an logical block address;
  • [0024] b) The segment size X should be chosen to provide the level of storage allocation granularity desired for the emulated devices;
  • [0025] c) The number of emulated devices D which are to be supported in the storage subsystem is assumed to be known or may be determined within a reasonable range; and
  • [0026] d) As long as S≦4G and D≦64K, page IDs are assumed to be two bytes and segment IDS assumed to be four bytes. It will be appreciated that the choice of S and D determines the size of table entries and affects the amount of memory required for the tables, the sizes of which are to be optimized. Different values for S and D result in different table sizes and, therefore, different optimization values. However, the process required to determine the optimum table sizes remains unchanged.

[0027] A table may be generated and used to calculate the total memory space M required by the tables and thus select an appropriate number of table levels and table sizes. Table I is such a table and has been generated based upon a hypothetical system in which D=32K and S=1M. In the second column of the table, i_n equals the number of entries in each page of the n^th table level, with πi_n=S. Within the limits imposed by this later equation and the constant size of the pages in the first segment table (i₁=S/D=32 entries) regardless of level, each i_n, n>1, may be selected empirically.

[0028]

TABLE I
		Device	1st	2-Nth	Total
Levels	in′s	Table Space	Table Space	Table Space	Table Space
1	i1 = S = 1M	2D = 64 KB	4DS = 128 GB	—	128	GB
2	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 32K =	1.0	GB
	i2 = D = 32K			1 GB
3	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 64 +	6.6	MB
	i2 = 64			2 × 512 × 512 =
	i3 = 512			2.5 MB
4	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K*8 +	4.59	MB
	i2 = 8			2 × 4K*16 +
	i3 = 16			2 × 256 × 256 =
	i4 = 256			512 KB
5	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 4 +	4.37	MB
	i2 = 4			2 × 8K × 4 +
	i3 = 4			2 × 2K × 16 +
	i4 = 16			2 × 128 × 128 =
	i5 = 128			288 KB
6	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 2 +	4.28	MB
	i2 = 2			2 × 8K + 4 +
	i3 = 4			2 × 4K × 4 +
	i4 = 4			2 × 1K × 16 +
	i5 = 16			2 × 64 × 64 =
	i6 = 64			200 KB
7	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 2 +	4.25	MB
	i2 = 2			2 × 8K × 2 +
	i3 = 2			2 × 4K × 4 +
	i4 = 4			2 × 2K × 4 +
	i5 = 4			2 × 512 × 8 +
	i6 = 8			2 × 64 × 64 =
	i7 = 64			160 KB
8	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 2 +	4.23	MB
	i2 = 2			2 × 8K × 2 +
	i3 = 2			2 × 4K × 2 +
	i4 = 2			2 × 2K × 4 +
	i5 = 4			2 × 1K × 4 +
	i6 = 4			2 × 256 × 8 +
	i7 = 8			2 × 32 × 32 =
	i8 = 32			142 KB
9	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 2 +	4.22	MB
	i2 = 2			2 × 8K × 2 +
	i3 = 2			2 × 4K × 2 +
	i4 = 2			2 × 2K × 2 +
	i5 = 2			2 × 1K × 2 +
	i6 = 2			2 × 512 × 4 +
	i7 = 4			2 × 256 × 8 +
	i8 = 8			2 × 32 × 32 =
	i9 = 32			134 KB
10	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 2 +	4.22	MB
	i2 = 2			2 × 8K × 2 +
	i3 = 2			2 × 4K × 2 +
	i4 = 2			2 × 2K × 2 +
	i5 = 2			2 × 1K × 2 +
	i6 = 2			2 × 512 × 2 +
	i7 = 2			2 × 256 × 4 +
	i8 = 4			2 × 128 × 8 +
	i9 = 8			2 × 16 × 16 =
	i10 = 16			130.5 KB
11	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 2 +	4.22	MB
	i2 = 2			2 × 8K × 2 +
	i3 = 2			2 × 4K × 2 +
	i4 = 2			2 × 2K × 2 +
	i5 = 2			2 × 1K × 2 +
	i6 = 2			2 × 512 × 5 +
	i7 = 2			2 × 256 × 2 +
	i8 = 2			2 × 128 × 2 +
	i9 = 2			2 × 64 × 8 +
	i10 = 8			2 × 16 × 16 =
	i11 = 16			129 KB
12	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 2 +	4.22	MB
	i2 = 2			2 × 8K × 2 +
	i3 = 2			2 × 4K × 2 +
	i4 = 2			2 × 2K × 2 +
	i5 = 2			2 × 1K × 2 +
	i6 = 2			2 × 512 × 2 +
	i7 = 2			2 × 256 × 2 +
	i8 = 2			2 × 128 × 2 +
	i9 = 2			2 × 64 × 8 +
	i10 = 4			2 × 32 × 4 +
	i11 = 4			2 × 8 × 4 =
	i12 = 8			128.38 KB
13	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 2 +	4.22	MB
	i2 = 2			2 × 8K × 2 +
	i3 = 2			2 × 4K × 2 +
	i4 = 2			2 × 2K × 2 +
	i5 = 2			2 × 1K × 2 +
	i6 = 2			2 × 512 × 2 +
	i7 = 2			2 × 256 × 2 +
	i8 = 2			2 × 128 × 2 +
	i9 = 2			2 × 64 × 2 +
	i10 = 2			2 × 32 × 4 +
	i11 = 4			2 × 16 × 4 +
	i12 = 4			2 × 4 × 4 =
	i13 = 4			128.16 KB
14	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 2 +	4.22	MB
	i2 = 2			2 × 8K × 2 +
	i3 = 2			2 × 4K × 2 +
	i4 = 2			2 × 2K × 2 +
	i5 = 2			2 × 1K × 2 +
	i6 = 2			2 × 512 × 2 +
	i7 = 2			2 × 256 × 4 +
	i8 = 2			2 × 128 × 2 +
	i9 = 2			2 × 64 × 2 +
	i10 = 2			2 × 32 × 2 +
	i11 = 2			3 × 2 + × 3 +
	i12 = 2			2 × 8 × 4 +
	i13 = 4			2 × 4 × 4 =
	i14 = 4			128.03 KB
15	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 2 +	4.22	MB
	i2 = 2			2 × 8K × 2 +
	i3 = 2			2 × 4K × 2 +
	i4 = 2			2 × 2K × 2 +
	i5 = 2			2 × 1K × 2 +
	i6 = 2			2 × 512 × 5 +
	i7 = 2			2 × 256 × 2 +
	i8 = 2			2 × 128 × 2 +
	i9 = 2			2 × 64 × × 2 +
	i10 = 2			2 × 32 × 2 +
	i11 = 2			2 × 16 × 2 +
	i12 = 2			2 × 8 × 2 +
	i13 = 2			2 × 4 × 2 +
	i14 = 2			2 × 2 × 4 =
	i15 = 4			128 KB
16	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 2 +	4.22	MB
	i2 = 2			2 × 8K × 2 +
	i3 = 2			2 × 4K × 2 +
	i4 = 2			2 × 2K × 2 +
	i5 = 2			2 × 1K × 2 +
	i6 = 2			2 × 512 × 5 +
	i7 = 2			2 × 256 × 2 +
	i8 = 2			2 × 128 × 2 +
	i9 = 2			2 × 64 × × 2 +
	i10 = 2			2 × 32 × 2 +
	i11 = 2			2 × 16 × 2 +
	i12 = 2			2 × 8 × 2 +
	i13 = 2			2 × 4 × 2 +
	i14 = 2			2 × 2 × 2 =
	i15 = 2			127.99 KB
	i16 = 2
4 - Example	i1 = S/D = 32	3D = 96 KB	4S = 4 MB	2 × 16K × 32 +	5.15	MB
	i2 = 32			2 × 1K × 32 +
	i3 = 32			2 × 32 × 32 =
	i4 = 32			1.06 MB

[0029] In the third column, the amount of space required for the emulated device table is constant (above the use of just a single table). In the case of a single table level, the device table is not even required because the device number (D) can be used as the index to a subtable within the single table level. For any case with multiple table levels, each entry in the device table contains three bytes—one byte (2 bits in this example) to select which table level and two bytes to identify a subtable within the specified table. For D=32K, the device table is 3D bytes or 96K. Similarly in the fourth column, 4 bytes are the amount of space required for each of the S entries in the first segment table; thus, 4 MB are required to store all of the segment IDs in the first segment table. With respect to the fifth column, in each of the remaining segment tables, 2 bytes are required for each pointer entry; this is multiplied by the number of pages in the segment table and by the number of entries in each page.

[0030] Table I includes information for subsystems with up to 16 segment table levels and for a subsystem having 4 segment tables with 32 entries in each page of each table. Given that πi_n=S and given that the size of the pages in the first segment table is constant (i₁=S/D=32 entries), each i_n, n>1, may be selected to minimize the total table space. If desired, a computer may be programmed to calculate the numerous permutations and determine a minimum table size for each level. As is evident by Table I, the optimum table sizes are not necessarily achieved by allocating the same number of entries per page to all tables. For example, when a comparison is made of the last entry in Table I (where four table levels each have 32 entries 32 entries per page) to the prior entry in the table for four levels, 5.12 MBs vs. 4.59 MBs represents an 11% reduction in required table space.

[0031] The total table size M (sixth column) decreases as the number of segment table levels increases. However, because the number M in the sixth column of Table I has been rounded for convenience, an examination of the fifth column will highlight the decrease. It is very apparent that a significant amount of space may be saved when moving from a single table (128 GB) to two tables (1.0 GB) to three (6.6 MB) to four (4.59 MB), a reduction of about 99.9996%. FIG. 4 graphically illustrates the reduction in table space M versus segment table level. (Data points for the first two table levels has been omitted due to the resulting difficulty in scaling the plot.) However, as also illustrated in FIG. 4, the rate at which table size decreases itself decreases as the number of table levels increases, showing only nominal reductions beyond about ninth level (n=9), particularly relative to the fixed amount of space allocated to the first segment table. Consequently, a decision to limit the number of table levels to, for example, 9 might be an appropriate tradeoff between controller memory space and I/O operation speed as discussed above. That is, the savings of space above about nine levels may not be worth the associated extra operating overhead. It will be appreciated that different systems having different parameters will result in different tradeoffs.

[0032] It has been found that the most memory efficient configuration may be for each page in each segment table beyond the first to have two entries and include as many table levels as necessary to provide the desired emulated space (referring again to the πi_n=S boundary). In such a configuration, L=log₂(D), where L is the number of table levels beyond the first. This results in the minimum number of unused pointers in the tree when an emulated device does not align perfectly with the tree structure but also results in the maximum number of table levels. For example, if D=32K, then L=log₂(32K)=15 and fifteen tables beyond the first, having two entries in each, appears to provide the most memory efficient configuration.

[0033] The flow chart in FIG. 5 summarizes the method of configuring a storage subsystem of the present invention. N physical devices are attached to the subsystem (step 500) and are partitioned into S equal-size segments (step 502). An identifier is assigned to each segment (step 504) having a first portion identifying the physical device in which the segment is located and a second portion identifying the location of the segment within the physical device. D emulated devices are established (step 506) to be accessible by attached host devices.

[0034] A number n of segment tables are established within the storage controller memory (step 508). Each table is subdivided into a number of sub-tables or pages;

• • [0035] each page holds a number of entry spaces for storing pointers. As described above, the number of segment tables and the number of entries in each are chosen so that the physical segments may be allocated among all of the emulated devices in any proportion, including all to any single emulated device.

[0036] A first of the segment tables is established (step 510) with D pages, each page having i₁S/D entry spaces. Each entry space in the first segment table stores a segment number for pointing to the segment. A second of the segment tables may be established (step 512) with S/(2i) pages, each page having i₂=S/i entry spaces. Each entry space in the second segment table stores a first table (page and entry) identifier for pointing to an entry in the first segment table.

[0037] A Q^th table may be established with S/(πi) pages, where i equals the number of pages in any preceding page (that is, i ranges from 1 to Q-1) (step 514). Each entry space in the Q^th segment table has i_Q entry spaces, where πi_k=S for k=1 to n and n is the total number of segment tables in the configuration. Each entry space in the Q^th table stores an identifier for pointing to an entry in the preceding (Q-1)^th segment table. Additional segment tables are established as desired (step 516).

[0038] An emulated device table is established storing an identifier for each of the D emulated devices (step 516). Each identifier has a first portion identifying a segment table and a second portion identifying a page within the segment table.

[0039] FIG. 6 is a flow chart summarizing the operation of a storage subsystem of the present invention. After the subsystem has been configured, an I/O command is received by the controller from an attached host to access (read from or write to) data on an emulated device (step 600). Included with the I/O command is a logical block address (LBA) of the block of data to be accessed (step 602). The LBA points to an emulated logical block where the host “sees” the desired data, even though the data physically is stored in segments of one or more physical devices.

[0040] The controller translates or maps the LBA into the ID of the segment(s) where the data physically is stored (step 604). For example, assume again that D=32K emulated devices have been designated and that physical storage of up to 16 physical devices has been divided into S=1M segments of X=1 GB each, with logical blocks of B=512 bytes. Assume further that four segment tables have been established in the controller. The first segment table has D=32K pages with i₁=S/D=32 entries each. The second segment table has been selected to have S/2i₁=16K pages, also with i₂=32 entries each. The third segment table has been selected to have S/2i₁i₂=1K pages, also with i₃=32 entries each. Finally, the fourth segment table has been selected to have S/2i₁i₂i₃=32 pages, also with i₄=32 entries each.

[0041] As illustrated by FIG. 7, The LBA may be divided into ranges of bits, with the last range specifying the block offset within the selected segment, and each prior range specifying the offset into the selected subtable of a segment table. In the present example, an LBA is divided into five parts: one for the segment offset and one for each of the four segment tables. Because the pages in each of the four segment tables in the example contain the same number of entries (32), the number of bits of the LBA allocated to each table is log₂(32)=log₂(32)=5. Moreover, the number of bits required to find the logical block in the segment is log₂(segment size/logical block size), or log₂(X/B)=log₂(1 GB/512)=log₂(2²¹)=21 bits. Thus,

[0042] The selected emulated device provides the index into the device table in FIG. 3 that identifies a sub-table in one of the segment tables.

[0043] LBA Bits 36:40 provide an offset into a subtable of the fourth segment table (if such a subtable is identified by the device table; otherwise these bits must be zeroes). The pointer at this offset in the subtable identifies a third segment table subtable.

[0044] LBA Bits 31:35 provide an offset into a subtable of the third segment table (if such a subtable is identified by the device table or the prior segment table; otherwise, these bits must be zeroes). The pointer at this offset in the subtable identifies a second segment table subtable.

[0045] LBA Bits 26:30 provide an offset into a subtable of the second segment table (if such a subtable is identified by the device table or the prior segment table; otherwise, these bits must be zeroes). The pointer at this offset in the subtable identifies a first segment table subtable.

[0046] LBA Bits 21:25 provide an offset into a subtable of the first segment table (if such a subtable is identified by the device table or the prior segment table; otherwise, these bits must be zeroes). The segment ID at this offset in the subtable identifies segment associated with this access.

[0047] LBA Bits 0:20 identify the logical block within the selected 1 GB segment.

By following the path through the segment tables, the appropriate segment is found and the LBA offset in the segment allows the correct logical block to be located (step 606) and the requested I/O operation is performed (step 608).

[0048] It should be noted that the present invention is also applicable to CKD devices where the normal access is to a track rather than a block. Several tracks may be stored in each segment. To access a track, the track address is translated into a logical track address with the tracks associated with an emulated device being logical tracks 0 to T. The track address is divided by the number of tracks per segment to obtain the number of corresponding bits 21:40 of the LBA used to access the table structure. The remainder of the division provides the track offset within the segment.

[0049] The objects of the invention have been fully realized through the embodiments disclosed herein. Those skilled in the art will appreciate that the various aspects of the invention may be achieved through different embodiments without departing from the essential function of the invention. The particular embodiments are illustrative and not meant to limit the scope of the invention as set forth in the following claims.