Method and program product for managing data access routes in a data storage system providing multiple access routes

CROSS-REFERENCE TO RELATED APPLICATION

P-0001[0001] This application is related to U.S. patent application Ser. No. 09/819,265, filed Mar. 27, 2001, and entitled “METHOD AND APPARATUS FOR PROVIDING FILE SYSTEM ACCESS TO A DISK ARRAY.” The entire content of this prior application is hereby incorporated by this reference. The Applicant claims priority from this prior application under 35 U.S.C. §120.

FIELD OF THE INVENTION

[0002] This invention relates to data storage systems used with computers and computer networks. In particular, the invention relates to a method and program product for managing and switching data access routes to a data storage arrangement such as a disk array.

BACKGROUND OF THE INVENTION

[0003] File systems and disk arrays utilize two different methods for accessing data stored on a data storage medium. The two methods are distinguished by a number of characteristics. In a file system for example, files are accessed using a file abstraction. That is, data is represented by a file which may be opened, closed, created, deleted, read, and written. Data is managed in a file system through a hierarchy of files and directories. This hierarchical data management is commonly seen as a significant advantage over other data management schemes. File systems also support both data sharing and data storage device sharing. Security within data storage devices is based on file and directory level access control lists standardized as part of the file system protocols. Another advantage of file systems is that client/server compatibility is based on a small number of well-supported protocols. However, file system performance is reduced by data storage disk-resident file mapping arrangements which are required to map data for a file to physical or virtual locations of the storage media associated with a data storage device.

[0004] A disk array is a storage system that employs a number of separate storage devices or disks and manages data across all of the separate devices. These disk array storage systems are popular for implementing data storage redundancy schemes to guard against individual storage device failures. In contrast to a file system, data is accessed in a disk array using a block storage abstraction. That is, data is mapped to large contiguous storage spaces or logical units and is accessed as blocks contained in these logical units. Each block in a logical unit represents a certain amount of data storage space, commonly 512 bytes of storage space. The stored data in a disk array is managed as physical and virtual data storage devices represented by volumes and/or logical units. Although the block storage abstraction may improve the speed at which large amounts of data may be written and retrieved from the storage devices, there are a number of drawbacks associated with disk arrays as compared to file systems. One drawback is that client/server compatibility for disk arrays is subject to a variety of constraints that vary across clients and servers. Also, disk arrays support only device sharing but not data sharing. Furthermore, security within devices is based on vendor unique features.

[0005] Prior related U.S. patent application Ser. No. 09/819,265 discloses a data storage system that provides multiple access routes to a data storage device or array of data storage devices. In particular, application Ser. No. 09/819,265 is directed to an arrangement that maintains file abstractions for all data stored in a disk array, while providing for both regular file system access to the disk array and alternatively direct block access. Access routes are preferably specified in the system according to certain route determinant characteristics associated with the respective files. Regardless of how the access routes are selected for particular data, the system disclosed in this prior related application provides multiple routes while maintaining the desirable file system hierarchy. Where file size is selected as the route determinant characteristic, the system disclosed in application Ser. No. 09/819,265 allows large file access to be accelerated by direct array controller access, while allowing small file access in the normal way through both the file system processes and the array controller processes.

SUMMARY OF THE INVENTION

[0006] The present invention is directed to the management of access routes in a data storage system that provides multiple alternative data access routes such as the system disclosed in prior related application Ser. No. 09/819,265. In such systems the particular access route for a given set of related data or data set is generally determined by some characteristic or group of characteristics associated with the data set. For the purposes of this disclosure and the following claims, such characteristic or group of characteristics will be referred to as the “route determinant characteristic” for the respective data set. The present invention includes the step of detecting a data set having a route determinant characteristic that does not match, that is, is inconsistent with, the access route for the respective data set. Once such a mismatched data set is detected, the method includes specifying a different access route for the respective data set. This different access route matches or is consistent with the route determinant characteristic for the data set so that the data set will be accessed by the proper access route.

[0007] The preferred form of the invention is employed in a data storage system that utilizes a block access storage device or system for physically storing data, but maintains a file system with file abstractions for the respective data sets stored by the system so that each data set is represented by a “file.” The data storage system provides alternatively a file system access route to the block access storage device or a direct block access route to the block access storage device and specifies which of these access routes are to be used for each respective file. In this preferred form of the invention, the access management method includes first detecting a file having a route determinant characteristic that is inconsistent with the respective access route, either the file system access route or the direct block access route, specified for the file. Once the mismatched file is detected, the method includes specifying a different access route for the file so that the access route specified for the file will be consistent with the route determinant characteristic for the file.

[0008] The invention further includes a program product for managing data access routes in a data storage system providing alternate data access routes to the system storage device or devices. The program product includes mismatch detection program code for detecting a data set having a route determinant characteristic that does not match the access route specified for the data set. Access route altering program code specifies a different access route for the data set so that the access route for the data set is consistent with the set's respective route determinant characteristic.

[0009] These and other advantages and features of the invention will be apparent from the following description of the preferred embodiments, considered along with the accompanying drawings.

DESCRIPTION OF THE DRAWINGS

P-0010[0010]FIG. 1 is a diagrammatic representation of a data storage system providing alternate data access routes which may be managed according to the present invention.

P-0011[0011]FIG. 2 is a diagrammatic representation showing groupings of various software processes which operate in the data storage system shown in FIG. 1.

P-0012[0012]FIG. 3 is a diagrammatic representation showing the interactions between the various software processes shown in FIG. 2.

P-0013[0013]FIG. 4 is a flowchart showing the process steps performed according to a preferred form of the invention.

P-0014[0014]FIG. 5 is a representation of an entry in the file system data management arrangement embodying the principles of the invention.

P-0015[0015]FIG. 6 is a representation of an entry in an array controller data management arrangement embodying the principles of the invention.

P-0016[0016]FIG. 7 is a diagrammatic representation of the wedge file system data structures employed in a preferred form of the invention.

P-0017[0017]FIG. 8 is a flow chart showing process steps according to one preferred form of the invention.

P-0018[0018]FIG. 9 is a flow chart showing an alternative process according to the invention.

P-0019[0019]FIG. 10 is a flow chart showing process steps for specifying a different access route according to one form of the invention.

P-0020[0020]FIG. 11 is a flow chart showing one preferred process for transferring data for a file pursuant to a change in access route.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

P-0021[0021]FIGS. 1 through 7 are referenced here to describe the structure and operation of a data storage system <b>100</b> that provides multiple data access routes. This example data storage system <b>100</b> utilizes block access storage devices <b>103</b> to actually store data, but maintains file abstractions for the stored data or data sets, and thus retains the important benefits associated with file systems. Data storage system <b>100</b> provides two alternative access routes for stored data sets or files, a file system access route and a direct block access route. File system operation access requests that invoke the direct block access route may be referred to as “divertible operations,” whereas file system operation access requests that invoke the file system access route may be referred to as “non divertible operations.” The dual access routes in data storage system <b>100</b> may be managed according to methods embodying the principles of the present invention. This route management process will be described with reference to FIGS. 8 through 11.

P-0022[0022] The following disclosure will refer for convenience to the particular data storage system <b>100</b> illustrated through FIGS. 1 through 7. Thus, the access route management method according to the invention will be described with reference to two alternate data access routes and specifically to a file system access route and a direct block access route. Also, the data sets stored in the system will be referred to as “files.” However, it should be borne in mind that the invention is not limited to use with the specific data storage system <b>100</b> shown in the figures or to data storage systems that maintain file abstractions. The invention is also not limited to data storage systems which provide only two different access routes.

P-0023[0023] Referring to FIG. 1, data storage system <b>100</b> includes a data processing arrangement <b>101</b> and an array <b>102</b> of separate storage devices <b>103</b>. In the form of the invention shown in FIG. 1, data processing arrangement <b>101</b> includes two separate processors, an array controller processor <b>105</b> and a file system processor <b>106</b>. A system bus <b>104</b> interconnects the two processors <b>105</b> and <b>106</b>, a storage device adapter <b>107</b>, and an input/output port <b>108</b>. The separate adapter <b>107</b> shown in FIG. 1 provides an interface to the storage device bus <b>109</b>. Also, a hardware protocol stack <b>110</b> is associated with the input/output port <b>108</b> for providing network communication services which allow system <b>100</b> to communicate with a computer network <b>111</b>. Computer network <b>111</b> includes one or more file system clients <b>112</b> that have file system access to data storage system <b>100</b>. These file system clients <b>112</b> represent separate computing devices such as personal computers or workstations on network <b>111</b>.

P-0024[0024] Individual storage devices <b>103</b> shown in FIG. 1 preferably comprise disk drives or other suitable mass storage devices. Although not shown in FIG. 1, it will be appreciated that these storage devices <b>103</b> each include an interface connector and a drive controller. The interface connector allows the respective device to be connected to storage device bus <b>109</b>, and the drive controller comprises a processing element for executing program code to control the operation of the particular storage device.

P-0025[0025] The illustrated storage system <b>100</b> may be housed in an enclosure (not shown) housing data processing arrangement <b>101</b>, input/output port <b>108</b> and protocol stack hardware <b>110</b>, storage device interface adapter <b>107</b>, and one or more storage devices <b>103</b>. The illustrated storage device bus <b>109</b> includes an external connector <b>113</b> for connecting additional storage devices external to the system enclosure.

P-0026[0026] The particular structure of the storage system <b>100</b> illustrated in FIG. 1 is shown only as one preferred form of a multiple access route data storage system in which access routes may be managed according to the present invention. Many variations on the structure are possible within the scope of the invention. For example, although two separate data processing devices <b>105</b> and <b>106</b> are shown in FIG. 1, it will be appreciated that all of the data processing functions required in a multiple access route data storage system may be performed on a single data processing device or may be divided between more than two data processing devices. Also, the functions provided by storage device interface adapter <b>107</b> shown in FIG. 1 may be performed by a processing device included in processing arrangement <b>101</b>. The functions provided by protocol stack <b>110</b> shown in FIG. 1 may likewise be performed by some other processing arrangement in the system. Furthermore, although one external storage device <b>103</b> and four internal storage devices <b>103</b> are shown for purposes of example in FIG. 1, the invention may be employed with data storage systems including any number of storage devices. Storage devices <b>103</b> may, for example, comprise SCSI devices in which case bus <b>109</b> would comprise a SCSI bus, and adapter <b>107</b> would comprise a SCSI adapter. System bus <b>104</b> may comprise any suitable bus standard such as PCI for example.

P-0027[0027] Those skilled in the art will also appreciate that it is possible to implement a multiple access route data storage system equivalent to that shown in FIG. 1 in connection with a host computer rather than as the illustrated stand alone network unit. In this alternate implementation, the array controller processor and storage device adapter may be implemented on an add-on card such as a PCI card to be connected on the PCI bus of a host computer and the storage devices could all be external to the host computer. The processes performed by the file system processor <b>106</b> in FIG. 1 would be performed by a processor of the host computer in this alternate form of data storage system, and the host computer's input/output port and protocol stack could be employed for network communications.

P-0028[0028]FIG. 2 shows further detail of the program processes performed by data processing arrangement <b>101</b> under the control of computer program code according to the invention. Array controller processor <b>105</b> performs or executes a number of program processes each indicated in a separate box included in the box <b>200</b> in FIG. 2. These array controller program processes are implemented through array controller program code and are referred to in this disclosure collectively as array controller processes <b>200</b>. In the illustrated form of the invention, array controller processes <b>200</b> include an array command interpreter <b>201</b>, virtual array mapping component <b>202</b>, and RAID management component <b>203</b>. These elements each represent computer program code executed by the array controller processor <b>105</b> to perform various array controller functions. FIG. 2 also shows an array cache <b>204</b> associated with array controller processor <b>105</b>. This array cache may comprise random access memory associated with the array controller processor or may comprise battery-backed random access memory. The memory is used to cache data being transferred to and from the storage devices under control of array controller processes <b>200</b>.

P-0029[0029] Array command interpreter <b>201</b> shown in FIG. 2 is responsible for receiving a data storage device-related command and converting the command to instructions or calls for the other array controller processes. In the preferred form of the invention, array command interpreter <b>201</b> also includes byte access conversion program code for converting the byte offset access instruction resulting from a divertible operation to a block access instruction, as will be discussed further below. Virtual array mapping component <b>202</b> provides an array data management arrangement which relates data stored on the storage devices to logical units and to blocks of storage space. An entry in this array data management arrangement is shown in FIG. 6 described below. Virtual mapping component <b>202</b> is also preferably responsible for creating and assigning logical units for the data to be stored across the device array <b>102</b>. RAID management component <b>203</b> is responsible for managing the storage device array <b>102</b> and for communications with the virtual array mapping component. RAID component <b>203</b> also implements any data storage redundancy schemes or RAID schemes supported by data storage system <b>100</b>. Array controller processes are well known in the art of disk arrays and RAID systems and will not be described further here so as not to obscure the present invention in unnecessary detail.

P-0030[0030] File system processor <b>106</b> shown in FIGS. 1 and 2 performs or executes a number of program processes, each implemented through computer program code. Each process is indicated in a separate box included in box <b>106</b> shown in FIG. 2. In addition to the file system processes or file system <b>208</b> implemented through file system program code, file system processor <b>106</b> executes a disk driver component <b>209</b>, a wedge file system component <b>210</b>, and a byte mode driver component <b>211</b>. Each of these components represents program processes implemented by computer program code executed by file system processor <b>106</b>. FIG. 2 also shows a file system cache <b>212</b> which comprises random access memory associated with file system processor <b>106</b>. File system cache <b>212</b> provides storage space for caching file data being communicated ultimately to and from data storage devices <b>103</b> shown in FIG. 1.

P-0031[0031] It will be appreciated that the file system processes shown at block <b>208</b> in FIG. 2 include all program processes required for implementing the desired file system. In particular, file system processes <b>208</b> provide a file system data management arrangement. The file system data management arrangement includes one or more data tables which relate each file in the file system to various file attributes. Also, as will be discussed further below with particular reference to FIG. 5, the file system data management tables relate each file to either storage device allocation information or a reference to a logical unit created and managed by array controller processes <b>200</b>. For communications to the array controller processes <b>200</b>, file system processes <b>208</b> rely on disk driver component <b>209</b>. This disk driver component <b>209</b> includes computer program code for communicating file system data access commands from the file system processes <b>208</b> to the array controller processes <b>200</b> to access certain file system data stored at the data storage devices <b>103</b>. In particular, disk driver component <b>209</b> provides any necessary encoding of instructions and data communicated between the file system processes <b>208</b> and the array controller processes. It will be appreciated that the disk driver component may be considered as being included in the file system processes <b>208</b>, but is shown separately in this disclosure to better describe its particular function.

P-0032[0032] As with most of the array controller processes <b>200</b>, the specific implementations and operation of file system processes <b>208</b> and disk driver component <b>209</b> are within the ordinary skill in the art. Therefore, implementation and operational details will be described in this disclosure only as necessary to clearly and completely disclose the data storage system which may be managed according to the present invention.

P-0033[0033] Wedge file system component <b>210</b> implements special file system processes interposed between file system clients (<b>112</b> in FIG. 1) and file system processes <b>208</b>. As will be described in further detail with reference to FIGS. 3 and 4, wedge file system component <b>210</b> receives file system access operation requests from file system clients and determines whether the request includes a divertible operation. The determination is performed by operation detection program code included in the wedge file system. Wedge file system component <b>210</b> passes non divertible operations to file system processes <b>208</b>. This processing of non divertible operations through file system processes <b>208</b> occurs just as in a prior art file system and represents the file system access route to the data storage devices <b>103</b> shown in FIG. 1. However, when wedge file system component <b>210</b> detects a divertible operation, it blocks the operation from reaching file system processes <b>208</b>, and instead diverts the divertible operation to be processed by the array controller processes <b>200</b> executed at array controller processor <b>105</b>. This direct execution of the divertible operation by array controller processes <b>200</b> facilitates direct block access to the storage devices <b>103</b> and represents an alternative data access route. Further details of the operation of wedge file system component <b>210</b> will be described below with reference to FIGS. 3 and 4.

P-0034[0034] Utilizing the wedge file system component <b>210</b> as shown in FIG. 2 to intercept file system access operation requests has the advantage that the operation detection function may be implemented without making changes to the program code implementing file system processes <b>208</b>. However, it will be appreciated that the divertible operation detection function described above with reference to wedge file system component <b>210</b> may alternatively be provided by modifying file system processes <b>208</b>. In this alternate implementation, divertible operations would reach file system processes <b>208</b> but would not be processed and instead be diverted to the alternate, direct block access route through array controller processes <b>200</b>. This alternate implementation is to be considered an equivalent to the wedge file system component implementation set out in detail in this disclosure.

P-0035[0035] Byte mode driver component <b>211</b> comprises program code for conveying commands for a divertible access operation to array controller processes <b>200</b>, and particularly to array command interpreter component <b>201</b>. The conveyance functions performed by byte mode driver component <b>211</b> for divertible operations are analogous to the functions provided by disk driver component <b>209</b> with respect to non divertible operations.

P-0036[0036] As indicated in FIG. 2, the program processes performed at array controller processor <b>105</b> and file system processor <b>106</b> communicate with each other and also both communicate with file system client applications <b>214</b> comprising software executed at file system clients <b>112</b> in FIG. 1. Array controller processor <b>105</b> also communicates with disk controller processes <b>216</b>. Disk controller processes <b>216</b> comprise program code executed at the controller (not shown) associated with each data storage device <b>103</b> in FIG. 1.

P-0037[0037] The method of providing multiple alternate access routes to stored data employed in data storage system <b>100</b> in FIG. 1 and the operation of the various program processes shown in FIG. 2 may be described with reference to FIGS. 3 and 4. As shown at process block <b>401</b> in FIG. 4, the method includes receiving a file system access operation request. This file system access operation request is received from a file system client <b>112</b> in FIGS. 1 and 3, through communications facilities provided by protocol stack <b>110</b> also shown in those figures. The access operation request is received by the wedge file system component <b>210</b> in the preferred form of the invention. As mentioned above, this wedge file system component <b>210</b> is interposed between the file system processes <b>208</b> and file system clients <b>112</b>. A component referred to as a virtual file system interface may be used in certain file systems to insert file system modifications ahead of the file system components or to insert an additional or alternative file system. Thus, the file system processes <b>208</b> (FIGS. 2 and 3) employed according to the preferred form of the invention illustrated in the figures must support a virtual file system interface or other method for inserting wedge file system component <b>210</b>. It will be appreciated that the virtual file system interface support is not required where the functions of the wedge file system are integrated with the file system itself.

P-0038[0038] The method next includes the step of determining whether the file system access operation request includes a divertible operation. This step is shown at decision block <b>402</b> in FIG. 4 and is performed by the wedge file system component <b>210</b> in the illustrated form of the invention. It will be assumed for purposes of this disclosure that file system access operations are generally defined as divertible or non divertible based on the size of the file (amount of data making up the file) which is the subject of the access operation request. That is, the route determinant characteristic associated with each file will be assumed for the purposes of this disclosure to be the size of the file. This diversion or specification of data access route based on file size has the effect of causing all files over the predetermined threshold size to be handled or processed directly by array controller processes <b>200</b> (the direct block access route) and causing all files below the threshold size to be handled or processed normally through file system processes <b>208</b> (the file system access route). The preferred form of the data storage device also includes a mechanism for overriding the normal rules for determining if an operation is a divertible operation. Again, although the invention is described here for purposes of example as using file size as the route determinant characteristic, other file attributes and other standards or combinations of attributes and standards may be used as route determinant characteristics within the scope of the accompanying claims.

P-0039[0039] Any suitable method may be used for making the determination at decision block <b>402</b>. In the example that the determination is based on the size of the file which is the subject of the received operation, wedge file system component <b>210</b> may obtain file size information from the file system data management arrangement associated with file system processes <b>208</b>. In a preferred form of the invention, when a file is opened the wedge file system obtains file size information for the file from the file system and stores that information in a suitable data structure associated with the wedge file system. Thus, the decision step at block <b>402</b> may include reading file size information from the wedge file system data structure. Alternatively, the decision step at block <b>402</b> may include sending a request for the necessary file size information from wedge file system component <b>210</b> to the file system processes <b>208</b>. In some situations, however, it may be preferable or necessary for the wedge file system to obtain the necessary file size information from the incoming file access operation request, in which case the decision step at block <b>402</b> would include reading file size information from the incoming operation request. If file size information is not available for the file which is the subject of the incoming file access operation request, it may be necessary for wedge file system component <b>210</b> to be programmed to make an assumption as to the size of the file. It may alternatively be possible for wedge file system component <b>210</b> to obtain file size information from the file system client <b>112</b> issuing the request, although current file systems do not support such a function.

P-0040[0040] In the preferred data storage system described with reference to FIGS. 1 through 4, a special “access route” attribute may be associated with each file. In the present example in which the subject file size is used as the route determinant characteristic, the access route attribute may comprise a “file state” which may be set as either “large” or “small.” This file state attribute may be stored in the file system data management arrangement implemented by file system processes <b>208</b> as described below with reference to FIG. 5. The step of determining if the operation is a divertible operation then comprises simply reading the file state attribute stored at the file system data management arrangement for the file which is the subject of the access operation.

P-0041[0041] If the operation is determined to be a divertible operation, wedge file system <b>210</b> diverts the operation to array controller processes <b>200</b> as shown at process block <b>403</b> in FIG. 4. In the preferred form of the invention, the method also includes converting the diverted file system operation from a byte offset definition to a block access definition. This conversion step is shown at process block <b>404</b> in FIG. 4, and is preferably performed by program code included in or associated with array command interpreter <b>201</b> using memory available at array controller processor <b>105</b>. It will be noted that a similar conversion is part of the normal operation of the file system processes <b>208</b>. In each case, the conversion includes dividing byte offset and length data by the number of bytes in each block of storage space defined for storage devices <b>103</b>. Blocks are commonly defined as 512 byte storage spaces, although the invention is not limited to this block size.

P-0042[0042] Once the diverted file system operation is converted to a block access form at array command interpreter <b>201</b>, the operation is performed as shown at step <b>405</b> in FIG. 4. Performing the requested operation includes generally the normal steps in an array access. In particular, array command interpreter <b>201</b> takes the code or instruction representing the diverted operation and issues calls or commands to the associated processes depending upon the nature of the operation. For a read operation, the array mapping component <b>202</b> determines the block allocations associated with the pre-existing file to be read. The RAID management component <b>203</b> then issues an appropriate command to the device or devices <b>103</b> to read the data stored at the identified blocks. In a write operation, mapping component <b>202</b> maps the file data to blocks within the logical unit assigned to the file. RAID management component <b>203</b> then issues a command to the storage device or devices <b>103</b> to write the received data to the mapped blocks.

P-0043[0043]FIG. 3 shows three separate paths to array command interpreter <b>201</b>. Path <b>301</b> runs from protocol stack <b>110</b> to interpreter <b>201</b>. This path <b>301</b> is representative of the direct block access route in data storage system <b>100</b> and is shown to indicate that the file data associated with a divertible operation completely bypasses file system processes either passing to or from the storage devices <b>103</b>. Path <b>302</b> shows a path between wedge file system component <b>210</b> and interpreter <b>201</b> to indicate that commands and receipts associated with divertible operations pass between these two processes. Path <b>303</b> between disk driver component <b>209</b> and array command interpreter <b>201</b> is representative of the alternate file system data access route in data storage system <b>100</b> and is shown in FIG. 3 to indicate that commands, receipts, and file data associated with a non divertible file system access operation pass between disk driver <b>209</b> and array command interpreter <b>201</b> as will be discussed further below.

P-0044[0044] As shown at process block <b>406</b> in FIG. 4, the method employed by the multiple access route data storage system <b>100</b> also includes the step of updating the file system data management arrangement with information about the results of the executed divertible access operation. Since the invention maintains the desired file hierarchy through the file system data management arrangement, the tables making up the arrangement must be updated in order to maintain the correct information regarding the file which is the subject of a divertible access operation executed directly through array controller processes <b>200</b>. Array controller processes <b>200</b> facilitate this update of the file system data management arrangement by communicating operation result information to the file system processes <b>208</b>. The nature of the operation result information depends upon the nature of the divertible access operation which has been performed. For a create operation diverted to and performed by array controller processes <b>200</b>, the result information includes a reference to a logical unit assigned for the file by the array controller processes, particularly the array mapping component <b>202</b>. For a divertible read or write operation, the operation result information may comprise a receipt or message indicating the completion of the particular operation. In any event, the operation result information may be communicated directly back to file system processes <b>208</b> or communicated through wedge file system component <b>210</b>.

P-0045[0045] Returning to decision block <b>402</b>, if the access operation request is determined to include an operation which is not a divertible operation, wedge file system component <b>210</b> passes the operation directly to file system processes <b>208</b> as indicated at process block <b>408</b>. File system processes <b>208</b> then perform the operation at block <b>409</b> as in traditional file systems.

P-0046[0046] It will be noted that according to the preferred form of the invention, a single logical unit of the disk array implementation is devoted for storing small files which are processed or accessed through file system processes <b>208</b> in the normal fashion. However, all large files (in this example where file size determines the class of divertible operations) are processed or accessed directly through array controller processes as indicated by path <b>301</b> in FIG. 3 and are preferably each allocated their logical unit by array controller processes <b>200</b>. This difference between large file storage and small file storage means that the available storage space in array <b>103</b> is divided into space for large files and space for small files. The space available for larger files may be referred to as one route accessible space while the space available for small files may be referred to as a separate route accessible space. Thus, where the access route changes for a particular data set, the data set must necessarily be relocated from one route accessible space to another.

P-0047[0047]FIGS. 5 and 6 illustrate portions of the data management arrangements used by the file system processes <b>208</b> and array controller processes <b>200</b>, respectively. Referring first to FIG. 5, a file system data management entry is shown at <b>501</b>. In this preferred form of the invention, each entry includes a file name field <b>503</b>, a group <b>504</b> of file attribute fields, and a field <b>505</b> containing information regarding file system storage space allocation. Within group <b>504</b>, attribute field <b>506</b> stores a file state attribute. This file state attribute defines the file as either small, large, shrinking, or growing. Attribute field <b>507</b> provides a location for storing a reference to a logical unit to which the subject file is stored. Attribute group <b>504</b> further includes file type override field <b>508</b>, a moving range offset field <b>509</b>, and a moving range length field <b>510</b>. File type override field <b>508</b> is preferably included in entry <b>501</b> to facilitate forcing treatment of the subject file as either large or small file, that is, forcing a particular data access route for the file, regardless of the actual route determinant characteristic for the file. Attribute fields <b>509</b> and <b>510</b> are used in the preferred form of the present invention in physically moving data for purposes of changing data access routes as will be discussed further below.

P-0048[0048] It will be appreciated that for small files (or files treated as small files as dictated by a value in field <b>508</b>) there is no value in logical unit attribute field <b>507</b> because array controller processes <b>200</b> do not directly manage small files and do not assign small files their own logical unit. Rather, small files are handled by file system processes <b>208</b>. File system processes <b>208</b> allocate storage space for the file within a single logical unit assigned for the file system by array controller processes <b>200</b>. This allocation information is stored in field <b>505</b> for a small file. In contrast, file system space allocation field <b>505</b> is preferably left blank in a large file entry, while logical unit reference attribute field <b>507</b> stores the reference to the logical unit at which the large file is stored through the array controller processes <b>200</b>. Space allocation field <b>505</b> may be left blank for a large file because storage space is allocated for the file and managed by the array controller processes <b>200</b>.

P-0049[0049] It will be noted that the attributes in group <b>504</b> are each comprised of externally defined attributes and are not attributes normally defined in a file system. Thus, the file system must support externally defined file attributes in order to implement this preferred form of the invention. Most modern file systems do support such externally defined file attributes.

P-0050[0050] Referring to FIG. 6, the data management arrangement for array controller processes <b>200</b> includes an entry <b>601</b> for each file which is handled directly by the array controller processes according to the invention. In other words, an entry <b>601</b> is created for each file subject to a divertible operation and for which the direct block access route is specified. Each entry <b>601</b> includes a logical unit reference field <b>602</b> and a file name field <b>603</b>. Logical unit reference field <b>602</b> stores a reference to a logical unit at which the particular file is stored. File name field <b>603</b> stores the file name associated with the file for which the entry <b>601</b> is made. Entry <b>601</b> further includes field <b>605</b> containing storage space or block allocation information indicating the blocks of storage space allocated for the respective file.

P-0051[0051]FIG. 7 illustrates a data structure <b>701</b> implemented in the preferred wedge file system <b>210</b>. This preferred data structure includes movement buffers <b>702</b>, a migration in progress field <b>703</b>, and an open large file structure. Movement buffers <b>702</b> represent buffer storage space used in transferring data in order to specify a different data access route for a file or data set according to one form of the present invention. Migration in progress field <b>703</b> comprises a field for storing a value indicating that data is in the process of being transferred to specify a different data access route for the data. Both the movement buffers <b>702</b> and field <b>703</b> will be discussed further below with reference to the transfer of data occasioned by a change in the data access routes for particular data.

P-0052[0052] Open large file structure <b>704</b> is created by program code included in wedge file system <b>210</b> and comprises a temporary data structure for files that may be the subject of divertible operations, and thus accessed through the direct block access route. This wedge file system temporary file structure helps accelerate the processing of a divertible operation for a specified file by having required access information for the specified file readily available at the time the divertible operation is received. The structure is analogous to a similar temporary data structure commonly utilized in file systems. Each record in open large file structure <b>704</b> preferably includes a file handle, the file name, and a logical unit identifier. The logical unit identifier comprises an identifier for the logical unit to which the respective file has been stored according to a divertible operation, accessed by direct block access.

P-0053[0053] The method and program product for managing access routes according to the present invention will now be described with reference to FIGS. 8 through 11. The method will be described as applied to the exemplary multiple data access route data storage system <b>100</b> described with reference to FIGS. 1 through 7. Thus, the following description will continue with the terminology of the exemplary system which maintains file abstractions for the stored data and provides alternatively a file system access route and a direct block access route to data storage devices.

P-0054[0054] The route determinant characteristics for a file may change over time so that the access route for a particular file is inconsistent with the route determinant characteristics for the file. For example, where the route determinant characteristic comprises file size, a file that once qualified as a small file might have sufficient data added to qualify as a large file. Conversely, data may be deleted from a large file to the extent that the resulting file qualifies as a small file. In these instances there is a mismatch between the route determinant characteristics for the file and the earlier access route specified for the file. That is, the once small file may still be accessed through the small file access route even though the file currently qualifies as a large file which should be accessed through the large file access route. Similarly, a once large file may still be accessed through the large file access route even though the file is currently a small file and should be accessed through that access route. These incorrect access routes may defeat the purpose for the multiple access route arrangement and reduce system performance.

P-0055[0055]FIGS. 8 and 9 show two alternative processes for effecting a change in data access routes in a data storage system providing multiple data access routes. In each case, the method involves generally detecting a file having a route determinant characteristic that is inconsistent with the data access route specified for the file. Once the mismatch between the route determinant characteristic and specified access route for the file is detected, the method includes specifying a different access route for the file to eliminate the mismatch. In the preferred form of the invention, the step of specifying a different access route for a particular file includes actually transferring data from one route accessible space within the data storage system to another, as will be discussed in detail below. This process of transferring data to accommodate an access route change may be referred to as migration.

P-0056[0056] Referring to FIG. 8, one preferred form of the invention includes scanning one or more files periodically to detect access route mismatches. The scanning steps are performed generally by mismatch detection program code which may be included in the wedge file system <b>210</b>. The scan for mismatched files may be started as shown at process block <b>801</b> periodically at fixed time intervals or according to any other periodic trigger. Regardless of how the periodic scan is triggered, the process includes first determining if a migration is in progress as indicated at decision block <b>802</b>. This determination may be made by checking the migration in progress flag <b>703</b> in the wedge file system data structure (FIG. 7). If a migration is in progress, the scanning process may simply end as indicated at block <b>803</b>. If multiple migrations are supported or if no migration is in progress, the process then includes determining if the specified access route for a selected file matches or is consistent with the route determinant characteristic for that file as shown at process block <b>804</b>. The step at process block <b>804</b> is performed by comparison program code which is one part of the mismatch detection program code. This comparison may be performed in a two step process in the example arrangement in which file size comprises the route determinant characteristic. The first step comprises comparing actual file size of the file to a threshold file size above which a file is considered a large file. The second step comprises comparing what the file state should be as indicated by the result of the first step with the file state attribute (<b>506</b> in FIG. 5) currently stored for the file.

P-0057[0057] If no mismatch is detected as indicated at decision block <b>805</b> in FIG. 8, the process proceeds to decision block <b>806</b> to determine if there are other files to scan for a mismatch. If there are other files to scan for a mismatch, the process returns to process block <b>804</b> to perform the comparison on the next file available for scanning. Otherwise, if no more files are available for scanning, the scanning process ends as shown at process block <b>807</b>. If a mismatch for a file is detected at decision block <b>805</b>, the process proceeds to the step of specifying a different access route for the file and relocating or migrating data for the file from one route accessible space to another. This step is shown at process block <b>808</b> in FIG. 8 and is performed by access route altering program code preferably part of the wedge file system <b>210</b>. One preferred form of this access route altering step will be discussed below with reference to FIG. 10. After the access route altering step is started or completed, the process returns to process block <b>804</b> if further files are available for scanning or terminates if no further files are available for scanning.

P-0058[0058] It should be noted that the invention encompasses different arrangements for situations in which mismatches are found for multiple files. In one form of the invention, once the process of data migration is in progress, no additional access route alteration/data migration procedures may be initiated until the earlier initiated migration is complete. Alternatively, access route alteration/data migration for different files may be performed simultaneously where there is sufficient buffer space available to accommodate the data transfers.

P-0059[0059] In the alternate process shown in FIG. 9, mismatch detection performed by the mismatch detection program code is triggered only for a particular file in response to an access request for the file at process block <b>901</b>. This is in contrast to the periodic scanning of one or more files described with reference to FIG. 8. In response to the access request for the file, the method includes comparing the route determinant characteristic for the subject file with the route currently specified for the file as shown at process block <b>902</b>. This comparison may be performed as described with reference to process block <b>804</b> in FIG. 8 with a similar program code component. If no mismatch is indicated, the file is simply accessed in the normal fashion as indicated at process block <b>905</b>. However, if the comparison detects a mismatch as indicated at decision block <b>903</b>, the process proceeds to the step of specifying a different access route for the file as shown at block <b>904</b>, performed by access route altering program code. Once the different access route has been specified for the file and the data for the file has been migrated to the different route accessible space, the file is accessed as shown at process block <b>905</b>. It should be noted that the process may alternatively include accessing the specified file prior to changing the access route has opposed to the sequence shown for purposes of example in FIG. 9.

P-0060[0060]FIGS. 10 and 11 illustrate a process for changing the access route for a file as required at process block <b>808</b> in FIG. 8 and <b>904</b> in FIG. 9. Referring to FIG. 10, the process includes first setting the migration in progress flag in the wedge file system data structure (<b>703</b> in FIG. 7). This step of setting the migration in progress flag is shown at process block <b>1001</b> in FIG. 10.

P-0061[0061] In the form of the invention in which the data access route for a file is determined by the size of the file, a change in access route will occur in only two situations. One situation is where the file is treated as a small file but has had sufficient data added to fall under the definition of a large file. In this situation the file may be referred to as “growing” in the sense that it has grown from a small to large file. The only other situation warranting a change in data access route in this example based on file size is where a large file has had sufficient data deleted to qualify as a small file for data access purposes. A file in this situation may be referred to as “shrinking” in the sense that it has been reduced from a large file to a small file. If a file is undergoing a change in data access routes in this example, it will either be a growing file or a shrinking file.

P-0062[0062] The determination of whether the file is growing or shrinking is made at block <b>1002</b> which encompasses blocks <b>1002</b><i>a </i>and <b>1002</b><i>b. </i>At block <b>1002</b><i>a </i>the file size is compared to the threshold size that marks the boundary between different access routes for files in this example. This step determines whether the actual file size is greater than or less than the threshold size and thus whether the file should be treated as a large file or a small file. At block <b>1002</b><i>b </i>the result of the comparison at <b>1002</b><i>a </i>(the file is actually a large/small file) is compared with the current file state attribute. There are three possible outcomes of the comparison at block <b>1002</b><i>b. </i>One possibility is that the file is a large file but the file state attribute for the file indicates that the file is currently treated as a small file. In this case, the process in FIG. 10 proceeds to process block <b>1003</b>. Another possibility is that the file is a small file as indicated at <b>1002</b><i>a, </i>but the file state attribute for the file indicates that the file is currently treated as a large file. In this case, the process goes to block <b>1009</b>. The third possibility is that the manner in which the file should be treated as indicated at block <b>1002</b><i>a </i>is now consistent with the treatment indicated by the current file state attribute for the file. If this is the case, the process branches to block <b>1014</b> in FIG. 10.

P-0063[0063] If the file for which the access route is being changed is growing as indicated by the comparisons at block <b>1002</b>, the illustrated method includes registering a handle for the file in the open large file structure shown at <b>704</b> in FIG. 7. This step is shown at process block <b>1003</b> in FIG. 10. The process also includes setting the moving range offset to zero in field <b>509</b> shown in FIG. 5, and setting the moving range size to the buffer size as indicated at process block <b>1004</b>. The buffer size referred to here is the buffer size of the movement buffers <b>702</b> included in the wedge file system structure illustrated in FIG. 7. These steps reflect the fact that the file being transferred must be transferred in segments no larger than the available buffer size as will be discussed further below.

P-0064[0064] Since the file is growing from small file treatment to large file treatment, several steps must be taken by the array controller processes <b>200</b> and file system processes <b>208</b> shown in FIG. 2 in order to accommodate the change. These steps are grouped together and shown at process block <b>1005</b> in FIG. 10. The array controller processes must create LUN for the growing file along with an entry in the data management arrangement for the array controller processes (entry <b>601</b> in FIG. 6). Creating the entry requires setting the file name at field <b>603</b> in FIG. 6, and setting the LUN reference in field <b>602</b> and in field <b>507</b> for the file system entry <b>501</b> for the file shown in FIG. 5. The array controller processes <b>200</b> also set the block allocation information for the entry (field <b>605</b> in FIG. 6) while the file system processes modify the file system entry for the file by setting the file state attribute (in field <b>506</b> in FIG. 5) to growing.

P-0065[0065] The data for the file is actually transferred or migrated at process block <b>1006</b> in FIG. 10. This data transfer step will be described further with reference to FIG. 11 and is performed by data transfer program code included in the route altering program code. Once the data for the growing file is transferred, the process includes setting the file state to large in the appropriate field in both the file system entry for the file (<b>501</b> in FIG. 5) and the array controller entry for the file (<b>601</b> in FIG. 6). This step is shown at process block <b>1007</b> in FIG. 10 along with the step of truncating the file system allocation information. It will be noted that the steps shown at process block <b>1007</b> are the same as those that occur when a large file is initially stored in data storage system <b>100</b>.

P-0066[0066] Referring back to block <b>1002</b>, if the file is shrinking, that is, moving from a large file status to small file status, the preferred data transfer process includes setting the moving range offset and moving range size as shown at process block <b>1009</b>. These steps are similar to the steps performed at process block <b>1004</b> in connection with the changing access route for a growing file. As shown at process block <b>1010</b>, the method for a shrinking file also includes setting the file state to “shrinking.” The file system processes (<b>208</b> in FIG. 2) perform this step by setting the field <b>506</b> for the file system entry <b>501</b> for the respective file. The data making up the file is then transferred as shown at process block <b>1011</b> similarly to the transfer at process block <b>1006</b> for a growing file. As indicated at process block <b>1012</b> in FIG. 10, once the data for the file is transferred, the array controller processes <b>200</b> delete the LUN formerly assigned to the formerly large file, while the wedge file system unregisters the handle for the file in the open large file structure (<b>704</b> in FIG. 7). Also, the file system processes set the file state for the file to indicate the file is now a small file. This file state is recorded at field <b>506</b> in the file system entry <b>501</b> for the file as illustrated in FIG. 5.

P-0067[0067] Regardless of whether the transfer of data is for a growing or shrinking file, the transfer process ends with clearing the migration in progress flag, which was set at the beginning of the route changing process as shown at process block <b>1001</b>. With the migration in progress flag cleared, the system is once again available for changing the access route associated with a file in the system.

P-0068[0068]FIG. 11 illustrates the preferred process for transferring data for a file for the purpose of changing the data access route for the file. The process includes reading the source moving range set for the file as shown at process block <b>1101</b> and writing the destination moving range at process block <b>1102</b>. The source moving range refers to the source or current location of the data to be moved. This location will be within one route accessible space in the array <b>102</b>. The data at this source location is first read from the source location and buffered in the buffer memory (<b>702</b> in FIG. 7) and then written to the destination location comprising the location at which the file may be accessed through the new access route. This new location will be in a different route accessible space associated with the new access route for the data. It will be recalled that the moving range offset has previously been set to zero as indicated at process block <b>1004</b> or <b>1009</b> in FIG. 10. This causes the read operation at block <b>1101</b> in FIG. 11 to read the first segment of data for the file in the initial read at block <b>1101</b>. It will also be noted that the moving range size has similarly been preset to the buffer size, that is, the size of the movement buffer <b>702</b> shown in FIG. 7. Thus, the read operation indicated at process block <b>1101</b> reads as much of the file as is possible considering the movement buffer limitation. At this point, the process includes releasing any waiting file access requests which have been delayed while the data was being transferred. This releasing step is shown at process block <b>1104</b> in FIG. 11. In the preferred form of the invention, a file access operation request that collides with a moving range is delayed using access delaying program code and not executed until the collision and condition has cleared. The system checks for collisions with a moving range in connection with each access request from a file system client (<b>112</b> in FIG. 1) and holds the request in a queue until released as indicated at <b>1104</b>.

P-0069[0069] Depending upon the amount of data to be moved and the movement buffer size associated with the wedge file system structure <b>701</b> shown in FIG. 7, it may be necessary to repeat the steps at process blocks <b>1101</b> and <b>1102</b> two or more times. If all of the data for the file has not been moved as indicated by the outcome at decision block <b>1103</b>, the process moves to process block <b>1105</b>. At this step, the moving range offset is set equal to the current moving range offset plus the moving range size which has just been moved. This modification to the moving range offset has the effect of moving over to the next segment of data after the segment which has just been moved. The process then returns to process blocks <b>1101</b> and <b>1102</b>, at which point this next segment of data for the file is read from the source location and is written to the destination location.

P-0070[0070] It will be noted that it is possible for there to be a file access in tight sequence with a migration of data for a file from one route accessible space to another. In order to ensure that file accesses and migrations handle the correct data, the order of commands issued from wedge file system <b>210</b> in FIG. 2 must be retained in all processes downstream from the wedge file system, that is, below the wedge file system as shown in FIG. 2.

P-0071[0071] It should also be noted that the option to override the normal route determinant characteristic of a file may also require a transfer of data depending upon when the override option is allowed. If the override attribute shown at field <b>508</b> in FIG. 5 may be set after the file is created, specifying the override attribute oppositely to the current file state attribute trigger a change in the access route for the respective file. For example, if a given file is classified as a small file and then the override attribute is set as a large file, the data access route will be changed from the file system access route to the direct block access route. This change may be accomplished by the same process steps described in FIGS. 10 and 11.

P-0072[0072] It will be appreciated that the arrangement for managing date access routes according to the present invention will also preferably account for the possibility of interruptions in the migration of data from one route accessible space to another. Such an interruption might occur where power to the system fails for a period of time. The preferred manner of accommodating such an interruption is to simply abort any migration that was in progress at the time of the interruption and was therefore unable to complete due to the interruption. Other accommodations for process interruptions might maintain migration state information in order to resume migration at the appropriate point once the interruption has passed.

P-0073[0073] The above described preferred embodiments are intended to illustrate the principles of the invention, but not to limit the scope of the invention. Various other embodiments and modifications to these preferred embodiments may be made by those skilled in the art without departing from the scope of the following claims. In particular, the various program processes may be distributed across processing devices in any suitable fashion to perform the desired functions within the scope of the invention and the following claims. Also, the various software components shown in the figures are shown and described only for purposes of example and are divided generally in a fashion which most clearly describes the invention. However, the various software functions may be performed by differently named and arranged software components. These different software arrangements are to be considered equivalent to the arrangement set out in the present disclosure and the accompanying claims.