Patent Publication Number: US-6658417-B1

Title: Term-based methods and apparatus for access to files on shared storage devices

Description:
This application is a continuation-in-part U.S. patent application Ser. No. 09/309,453, filed on May 11, 1999 now U.S. Pat. No. 6,161,104, which is a continuation of U.S. patent application Ser. No. 09/002,266, filed on Dec. 31, 1997, which issued on Sep. 7, 1999, as U.S. Pat. No. 5,950,203, the teachings of all of which are incorporated herein by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     The invention pertains to digital data processing and, more particularly, to the sharing of disk drives and other storage devices on a networked digital data processing system. The invention has application, for example, in the processing of video, graphics, database and other files by multiple users or processes on a networked computer system. 
     In early computer systems, long-term data storage was typically provided by dedicated storage devices, such as tape and disk drives, connected to a central computer. Requests to read and write data generated by applications programs were processed by special-purpose input/output routines resident in the computer operating system. With the advent of “time sharing” and other early multiprocessing techniques, multiple users could simultaneously store and access data—albeit only through the central storage devices. 
     With the rise of the personal computer and PC-based workstations in the 1980&#39;s, demand by business users led to development of interconnection mechanisms that permitted otherwise independent computers to access one another&#39;s storage devices. Though computer “networks” had been known prior to this, they typically permitted only communications, not storage sharing. 
     Increased power of personal computers and workstations is now opening ever more avenues for their use. Video editing applications, for example, have until recently demanded specialized video production systems. Now, however, such applications can be run on high-end personal computers. By coupling these into a network, multiple users can share and edit a single video work. Reservation systems and a host of other applications also commonly provide for simultaneous access to large files by multiple parties or processes. Still other tasks may require myriad small files to be accessed by multiple different parties or processes in relatively short or overlapping time frames. 
     Network infrastructures have not fully kept pace with the computers that they interconnect. Though small data files can be transferred and shared quite effectively over conventional network interconnects, such as Ethernet, these do not lend themselves, for example, to sharing of large files. Thus, although users are accustomed to seemingly instantaneous file access over a network, it can take over an hour to transfer a sixty second video file that is 1.2 GBytes in length. 
     Some interconnects permit high-speed transfers to storage devices. The so-called fiber channel, for example, affords transfers at rates of up to 100 MBytes/sec—more than two orders of magnitude faster than conventional network interconnects. Although a single storage device may support multiple fiber channel interfaces, the industry has only recently set to developing systems to permit those workstations to share such files on a storage device. Moreover, when a file is to be accessed by multiple users, the overhead of server intervention can result in loss of speed advantages and efficiencies otherwise gained from the high-speed interface. In this regard, techniques such as locking, maintaining ghost files, monitoring file changes and underking multi-step access, check-in or housekeeping operations may be unworkable when multi-user access to many small files must be provided quickly. 
     In many situations, and for many specific types of networks, the coherence and security of a centralized shared access system are desirable, but the nature of their storage transactions may be ill-suited to permitting shared access due for example, to the burden imposed by file management protocols for tracking files, versions, and file size changes, and so forth. 
     In view of the foregoing, an object of the invention is to provide improved digital data processing systems and, particularly, improved methods and apparatus of high-speed access to data in storage devices on a networked computer system. 
     A related aspect of the invention is to provide such systems that achieve fast operation with files of diverse sizes. 
     A related aspect of the invention is to provide such systems as can be implemented with minimum cost and maximum reliability. 
     Yet another object of the invention is to provide such systems as can be readily adapted to pre-existing data processing and data storage systems. 
     Yet still another object of the invention is to provide such systems as can be readily integrated with conventional operating system software and, particularly, conventional file systems and other input/output subsystems. 
     SUMMARY OF THE INVENTION 
     One or more of the foregoing and other desirable objects are attained by the invention, which provides novel term- or lease-based methods and apparatus for accessing shared storage on a networked digital data processing system. 
     A system according to one aspect of the invention includes a plurality of digital data processing nodes and a storage device, e.g., a disk drive, a “jukebox,” other mass storage device or other mapped device (collectively referred to herein after as “disk drive,” “storage device” or “peripheral device”). First and second ones of the nodes, which may be a client and a server node, respectively, are coupled for communication over a LAN, network or other communications pathway. Both the first and the second nodes are in communications with the storage device. This can be over the same or different respective logical or physical communications pathways. 
     By way of non-limiting example, the first node and the second node can be a client and a server, respectively, networked by Ethernet or other communications media, e.g., in a wide area network, local area network, the Internet interconnect, or other network arrangement. The server and/or client can be connected to the storage device via a SCSI channel, other conventional peripheral device channel, such as a fibre channel, “firewire” (i.e., IEEE 1394 bus), serial storage architecture (SSA) bus, high-speed Ethernet bus, high performance parallel interface (HPPI) bus or other high-speed peripheral device bus. 
     A file system or other functionality in the second (server) node receives and responds to at least selected requests—e.g., file OPEN requests—from the first (client) node for access to a file on the storage device, by generating a “lease”. The lease includes a block map or other administrative data (referred to elsewhere herein as “meta data”) for the requested file, as well as an expiry time indicating how long the administrative data is valid. 
     Upon grant of the lease, the client node accesses the storage device using the block map or other administrative data supplied with the lease. The server node assures that this administrative data remains valid for the period of the lease, e.g., such that list and order of blocks comprising the file does not change—e.g., shrink, disappear or become reassigned to other files, during the client&#39;s use of the file. Correspondingly, the client node ceases utilization of the administrative data (and, presumably, ceases at least direct access of the file) after lease expiry. 
     Related aspects of the invention provide a system as described above in which lease expiry is keyed to the time of the initial client request. Hence, both the client and server nodes can accurately determine lease expiry time by reference to their own clocks; network time synchronization is therefore not necessary for effective operation of the system. 
     Further aspects of the system provide a system as described above in which the client issues a request for read-only or a read/write access to the file, and in which the server node grants a corresponding lease. For read/write leases, the server effects defragmentation, clean-up or other administration of the file once the lease has expired, e.g., via the server file system or via a file management system or controller on the storage device. The server node can also monitor activity by read/write “leaseholders,” e.g., for rapid notification of meta data changes upon expiry of the lease. 
     Typically, no such administration is required at termination of a read-only lease, since the leaseholder makes no changes to the file. Thus, for read-only access requests that may often constitute the vast preponderance of file requests, only the initial request and lease grant messages are necessary to allow quick and unhindered file access. 
     Still further aspects of the invention provide a system as described above in which the leases are self-expiring. Client node leaseholders in such a system need not report back to the server when a lease is expired and/or the file is closed. This reduces the number messages required to be communicated over the network between nodes, while providing direct access to file storage and continuing file security and coherence. 
     In an alternate aspect of the invention, the client node tracks lease expiry time and assures that all file writes are completed and changes in end-of file pointers are reported to the server node before lease expiry. Thus, only in this circumstance is a second or further communication over the network between the client and server required. The client node file application also assures that the leased data map is not referenced after lease expiry, and may, for example cleanse its cache of stale data. 
     Yet other aspects of the invention provide systems as described above in which the server node employs a decision table to set lease intervals, based, for example on whether the request for file access is a read-only or read/write request, as well as on current average network transaction times, requested file size, number or types of outstanding unexpired leases for the requested file, and the like. For example a request to read a file under 50 kbytes may be automatically granted a ten-second, or a two-minute, lease, while large file read/write requests may be granted leases on the order of minutes or hours. 
     Yet other aspects of the invention provide a system as described above in which the server node locks and unlocks data blocks in order to assure compliance with leases by the client node and other nodes. According to these aspects of the invention, when a lease is granted for a set of data blocks, they are locked; when the lease expires, those data blocks are unlocked. 
     Monitoring of lease activity is facilitated, in related aspects of the invention, by the server node&#39;s maintenance of a list of outstanding (or unexpired) leases. The server uses this, for example, to track and control any file size changes. When all leases have expired for at least a given set of blocks, the server can issue an unlock message to the file management system for those blocks and permit them to be defragmented or otherwise administered to. 
     Still further aspects of the invention provide systems as described above in which the client ode accesses leased files directly, without intervention by the server node. In this regard, the latter unctions as an “authorizer” (i.e., insofar as it grants leases which effectively authorize access to a file) and not as a “server” per se (though, of course, it can function in the latter role as well). In related aspects, the server may be implemented as a layer over a native file management system in the storage device, interfacing with a native file system meta data controller (FSMDC). 
     Further aspects of the invention provide a system as described above operating with a shared storage file management system, for example, as described in the aforesaid United States patent, or with other conventional network file server system. The allows the client nodes to access the file system without extraneous network communications for most file access tasks while it may employ the network file server system to require access through a server or file management system for a limited number of file requests for large files, files with outstanding leases, and in situations where security, coherence or file integrity concerns are primary. 
     Further aspects of the invention provide systems as described above including multiple “client” nodes, one or more “server nodes” and one or more storage devices, all operating as described above. 
     Still further aspects of the invention provide methods of operating digital data processing systems paralleling the operations described above. 
    
    
     These and other aspects of the invention are evident in the drawings and in the description that follows. 
     BRIEF DESCRIPTION OF THE ILLUSTRATED EMBODIMENT 
     A more complete understanding of the invention may be attained by reference to the drawings, in which 
     FIG. 1 depicts a storage area network of the type with which the invention may be practiced; 
     FIG. 2 depicts a software architecture of exemplary nodes in a system according to FIG. 1; 
     FIG. 3 depicts the issuance of a lease to a node in a system according to the invention; and 
     FIG. 4 depicts an interaction between a file manage system and a node in a system according to the invention. 
    
    
     DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT 
     FIG. 1 depicts a scaleable networked digital data processing system of the type used to practice the invention. The system  10  includes a plurality of nodes  12 - 24 , including two server nodes  18 ,  20  coupled via network pathways  26 ,  28  to client nodes  12 - 16  and  22 - 24 , as shown. Server nodes  18 ,  20  are additionally coupled to one another via network pathway  27 . 
     In the illustrated embodiment, nodes  12 - 24  represent digital data processing apparatus or other devices capable of being coupled to one another in a network and, more particularly, by way of example, in a client-server configuration. Illustrated server nodes  18 ,  20  represent mainframe computers, workstations, personal computers, or other digital data processing apparatus capable of providing server functions in such networks and, particularly, of controlling access to shared peripheral devices, such as storage device  36 . Nodes  12 - 16  and  22 - 24  likewise represent workstations, personal computers, dedicated devices, or other digital data processing apparatus that generate requests for access to such shared peripheral devices. 
     The network pathways  26 - 28  represent wire cable interconnects, wireless interconnects, point-to-point interconnects, Internet interconnects or other digital communications interconnects of the type known in the art Those pathways can be configured in any configuration that permits a node  12 - 16 ,  20 - 24  requesting access to a shared peripheral device  36  to communicate that request to a node  18  controlling access thereto. For purposes hereof and unless otherwise evident from context, such a requesting node is referred to as a “client” regardless of its role (i.e., as a client or server) in the conventional network defined by nodes  12 - 18  and pathway  26 , or nodes  20 - 24  and pathway  28 . Thus, for example, node  18  could be a “client” to node  16  for purposes of sharing peripheral device  34 , presuming an auxiliary connection (e.g., fiber channel) were provided between node  18  and that peripheral device. 
     In the illustrated embodiment, nodes  12 - 24  operate under the Microsoft Windows NT operating system, though those skilled in the art will appreciate that the nodes  12 - 24  may utilize other client and server operating systems, as well. Moreover, it will be appreciated that nodes need not utilize the same operating systems. Thus, for example, server  18  may operate as a Windows NT-based server, while server  20  operates as a UNIX-based server. The invention is therefore seen to have the advantage of permitting multiple nodes of different pedigrees, or operating system types, to access files on a common peripheral device. 
     With further reference to FIG. 1, the nodes  12 - 24  are coupled to respective dedicated storage devices  30 - 42 , as shown. Such couplings are provided by SCSI channels or other device interconnects suitable for permitting the nodes to transfer information with such devices. In addition to being coupled to their own dedicated storage devices  34 ,  38 , nodes  16 ,  20  are coupled to the storage device  36  that is controlled by node  18 . In the parlance of the invention, nodes  16 ,  20  are referred to as “clients” and node  18  is referred to as a “server.” Coupling between the clients  16 ,  20  and the shared peripheral device  36  can be provided by any conventional peripheral device interconnect, though, preferably, it is provided by high-speed interconnects such as fibre channel, “firewire” (i.e., IEEE 1394 bus), serial storage architecture (SSA) bus, high-speed Ethernet bus, high performance parallel interface (HPPI) bus or other high-speed peripheral device bus. 
     FIG. 2 depicts further detail of the hardware and software architecture permitting access to files on a shared peripheral device  36  by nodes  16 ,  20  in a system according to the invention. Though the discussion that follows is directed to access among these devices, those skilled in the art will appreciate that the teachings can be applied equally to file access on any of storage devices  30 - 32  by any of the nodes  12 - 24  to which they are directly or indirectly coupled. 
     Referring to the drawing, nodes  16 ,  18  are coupled to one another via communications pathway  26  and to peripheral device  36  via pathways  44 ,  46 , respectively. As noted above, pathway  44  (coupling device  18  to peripheral  36 ) can be a SCSI channel or other conventional peripheral device interconnects. Likewise, as noted above, pathway  46  (coupling device  16  to peripheral  36 ) can be a conventional peripheral device interconnect, though, preferably, is a high-speed interconnect such as fibre channel, “firewire” (i.e., IEEE 1394 bus), serial storage architecture (SSA) bus, high-speed Ethernet bus, high performance parallel interface (HPPI) bus or other high-speed peripheral device bus. 
     Executing on node  16  are one or more applications programs  48  (e.g., including video editing programs, image analysis programs, and so forth) that generate requests for access to local and networked peripheral devices, including shared device  36 . Those applications programs execute in the conventional manner under the control of an operating system, e.g., Windows NT, which includes a file system that services those access requests. 
     In the illustration, that file system is represented by elements  50 - 54 , including “upper” file system  50 , representing the Windows NT I/O Subsystem Manager and other components responsible for interfacing with applications programs  48  and for routing peripheral device access requests to the file system; “lower” file system  52 , representing the Windows NT File system drivers and intermediate drivers and other components responsible for local, disk-based file systems, SCSI drivers and the like providing generic functionality to a common set of devices; and drivers  54 , representing software (and hardware) components for transferring information to and from attached peripheral devices  34 ,  36 . 
     Because node  16  is a client vis-a-vis the Windows NT network, the drivers also include a network redirector, such as the Windows NT LANManRedirector, that transfers access requests to and from the shared peripheral device  36  via server node  18  and pathways  26  and  44 . The node  18 , which includes network server component  56 , handles such requests in the conventional manner of a server of a networked digital data processing system. As illustrated, node  18  also includes a file system, comprising elements  58 - 64 , whose operations parallel those of components  50 - 54  on the node  16 . 
     Though the illustrated architecture for node  16  is in accord with that dictated by Windows NT, those skilled in the art will appreciate that the invention may be embodied in devices running under other operating systems, as well. 
     Systems constructed and operated according to the invention allow multiple “client” nodes to access files on a shared peripheral device with minimal coordination of a “server” node for that device. A server node is used in this approach to store physical file mappings and other administrative information—and to otherwise administer—the shared device. A direct connection, or “directly attached disk connect,” is also be provided however between each node and the shared device to permit certain operations, e.g., bulk reads and writes, to be accomplished directly between the nodes and the peripheral device. The illustrated embodiments provide this capability through communications pathways such as pathway  46  and through filter drivers  66 ,  68  incorporated into the file systems. The direct connection may be physically separate from the network connection provided between the nodes or it may be logically separate, e.g., carried by the same physical conductor set as the network connection via high-speed switches and/or pathways. 
     In the discussion that follows, unless otherwise evident from context, the term “file system” refers in this context to the combined operation of the nodes&#39; native file systems (e.g., comprising elements  50 - 54  and  56 - 64 ) and of the network server, e.g.,  56 ., and file system, e.g.,  56 - 64 , of the node to which the shared peripheral device is assigned and of the file system, e.g.,  50 - 54  of the node that shares that device. 
     FIG. 3 shows the basic structure of a file management system in accordance with the present invention. As illustrated, a meta data controller (MDC) or “server”  120  is associated with a storage device  110 , and connected in a network  150  such as a LAN with a plurality of client nodes or workstations  130   a ,  130   b , . . . Those skilled in the art will readily appreciate that server  120  corresponds, for example, to server  18  of FIG. 1; storage device  110 , to peripheral device  36 ; network  150  to networks  26 - 28 ; and nodes  130   a ,  103   b , . . . to client nodes  12 - 24 . 
     The storage device  110  stores data, e.g., files, records, data structures, or other ordered data, any of which shall generically be referred to herein as a “file”. One file  115  is illustrated schematically in device  110 , occupying a number of blocks which, as shown, may be non-contiguous. In general, the file  115  will be denoted on the network  150  by a file name and certain identifying data that indicates how to retrieve it, e.g., a data path including the device, a directory, subdirectory etc. The actual storage location on the device  110  will be different, device-specific, and will vary as the file expands or contracts, is re-written, and then de-fragmented and reallocated to different storage locations within storage  110  during continuing operation, use and storage device housekeeping. 
     The MDC/server maintains the meta data for accessing the files on the storage device. As shown in FIG. 3, the server  120  responds to a request for a file transmitted over the network from a client  130   a , by providing meta data, e.g., a file map, to the client  130   a . The client uses this to accesses the storage device  110  directly. 
     In the illustrated embodiment, the file map is time-limited; a time is specified during which the client may rely on the meta data to use and access the file. Thus, the server passes a lease L(t) including a map and specifying a time t for which the map will be valid. The client  130  may accesses the file in storage without requiring further network communications to server  120  or coordination with other nodes on the network. File access may be effected over the network, which may for example have a direct switching connection to the storage device  110 , or via a separate high speed bus or fiber line to the storage device  110 . 
     The server, correspondingly, assures that the lease map remains valid for the lease term; i.e., that the block addresses in storage remain valid. Thus, the MDC  120  is a “server” in a limited sense; it provides meta data for accessing files, and sets the lease terms, thus affecting traffic, but it need not engage in exchanging multiple messages to either provide file contents or coordinate file changes and conflicting access requests. 
     FIG. 4 illustrates one implementation of a system of the present invention. Illustratively, the server  120  of FIG. 3 is implemented with a file sharing system  180  running on a host computer connected to the file storage unit  110 , which may, by way of example be a Sun Microsystems Solaris data storage system, a Hewlett Packard storage system, or other data storage apparatus, and which may operate with a native or proprietary file system meta data controller, denoted FSMDC in the figure. 
     Typically, the FSMDC maintains suitable file size, block or other address information, and other meta data for the files stored therein, and interfaces with the networked system to handle data requests and transctions, which, as noted above will be identified by typically different data path and other address designations and file names in the network. The client nodes  130  communicate via LAN or other network with the host system to access data from the storage device, and the file sharing system  180 , denoted SPMDC in the Figure, runs on the host and interfaces with the native FSMDC, to effect the necessary communications for shared access while maintaining file coherence and integrity. 
     In general terms, file sharing system  180  implements a messaging protocol for messages between the SPMDC and client nodes, and effects an interface with the native FSMDC; it encompasses the functions for providing maps for accessing client-requested data, keeping track of versions of data and of messages, monitoring file size, and generally performing the functions necessary to be a meta data controller when multiple clients may be accessing overlapping data stores, so that the native FSMDC may simply respond to client node data requests. In the embodiment of FIG. 4, these functions may include inhibiting FSMDC from changing file block addresses during the pendency of outstanding leases for the file. 
     Thus, as shown in FIG. 4, the embodiment  100  of the present invention employs a layer  180  that issues leases that include a map to the requested file and a lease duration, and assures accuracy of the map during the lease period. The client nodes  130 , e.g., user workstations or terminals, of which one is illustrated, communicate over a LAN with the file sharing system  180  to obtain a lease for a desired file, and advantageously may then independently communicate over the LAN and/or a separate data line with the storage unit  110 . 
     In a conventional network shared-access system, the host machine is the only machine that hard-mounts (read-write) the volume and lays down a file system and manages that file system with respect to authentication, security, administration, and allocation. Systems such as the IBM storage area network management system distributed under their “SANergy” trademark exploit existing operating system platforms and their file systems by interfacing with the existing file system proprietary FSMDC so that a number of simple network communications protocols allow the SPMDC to make them work correctly in a networked access data sharing world. In one respect, the SPMDC is somewhat like a file-server for a volume; other machines use conventional networking to access the volume and thus are authenticated and controlled in the traditional networking model. However, only meta data (file open, security, allocation information, etc.) take place in the SANergy approach; the actual file payload (data) is transferred directly between the storage elements and the accessing computers. 
     Thus, in such a system, the client nodes use ordinary networking to mount the volumes and open files, resulting in very fast transaction times. The SANergy code on the Client intercepts reads and writes and issues those directly to the disk elements. It does this by coordinating with the SPMDC (regarding caching) and asking the SPMDC for the list of physical blocks (i.e., a map) for the desired file. The SPMDC further effects necessary operations to maintain file coherence and provide accurate maps when there have been intervening file changes. 
     In order for clients to access a file&#39;s data by reading and writing directly to physical storage, the client must be told the exact physical information regarding the file. This is preferably done in a two-tier hierarchy: a physical description of the physical disks that comprise a logical volume and then the description of the file blocks relative to that volume information. The leases L(t) place a limitation on how long such transmitted description information is valid. The SPMDC may also take further steps to protect the overall “system” integrity of the data (i.e. caches). 
     In general, the SPMDC simplifies the overall task of allowing multiple computers to share physical storage directly, but it will be appreciated that this will in general involve rigorous adherence to rules and responsibilities of a properly coded MDC, such as proper updating and maintenance of MDC caches. File systems in general have always had an ability to “flush” dirty data to storage, but in the context of this SPMDC, this maintenance may also include “purging”, meaning removing pages from the MDC memory system because those corresponding pages on disk might have been written by another machine. This permits 100% safe, reliable, coherent, and recoverable byte-level data sharing between multiply attached hosts. 
     In general, this implementation may require that the functions, parameters, and codes necessary for interface between a native commercial FSMDC and the SPMDC layer  180  be provided by the file system manufacturer, because these functions are very file system specific. Preferably, these are then wrapped-up into a single shared-object library which can be dynamically loaded by the higher level SPMDC code at run time. On a single MDC there may be more than one file system present and thus more than one of these libraries. Thus, the layers above the FSMDC are preferably configured so that they exhaustively load all detected FSMDC modules (shared libraries). This way new file system support will occur independently of the particular release of the SPMDC layer. 
     To address the dynamically changing file sizes, names etc, the implementation of a shared access system employs very specific ways of identifying data. To accomplish this in a preferred embodiment, the FSMDC layer interface employs a concept of a “file system specific and unique identifier” called cookies. A cookie is used for referencing both Files and Volumes. It is possible for a file while in use to have its name changed or even deleted. It is also possible for multiple separate files to share a common name. The use of cookies avoids any confusion. 
     Before the SPMDC application  180  can manipulate a file (extend the map, set a file size, etc.), it must first ask for a Cookie for that file (by name). All subsequent operations on a given “session” of a file will use that cookie and never the name again. Any and all reports from the FSMDC layer regarding a file (such as the allocation map) will also report back the associated volume cookie. Volumes can also change in definition while the file system is up and ruing (e.g. a volume can be extended, striping changed, or other physical disk members added). Any change to a volume results in a different cookie for the volume; this allows the SPMDC to dynamically detect any material changes to the file system and files, even while files are in-use. Attached hereto as Appendix A is a document setting forth suitable function requirements and structure for implementing an interface between a native FSMDC and the file sharing layer of this invention. 
     As illustrated in FIG. 4, in accordance with a principal aspect of the present invention, the filing sharing layer  180  is implemented such that when a client  130  requests a file, the client specifies a time interval during which access is required. Thus, for example it may request a specific file for two seconds, or ten minutes or an hour. The SPMDC  180  responds by granting a “lease”, containing a “map” to the requested data on the storage unit  110  and having a term or duration which is set by the SPMDC  180 . Thus, when the FSMDC layer delivers file-map information (the physical description of all the blocks that comprise a given file), this information has a life span associated with it (“lease”). The SPMDC layer decides how long a map is considered useable and reports back that information along with the map to the caller. The lease duration may be referenced to the message time of the original request. At the client end, a file access application assures that the caller (client) is obligated to not reference any part of the map or the blocks it represents beyond the lease duration, i.e., to neither read nor write after the lease term. 
     While a lease is active the file&#39;s allocated blocks are considered “locked”. The FSMDC guarantees that there will be no removal or reclamation of any of those blocks of the file. In this regard, it is important to note that the current file-size is a separate concept and somewhat unrelated to whether blocks associated with a file are still associated with the file. An “unlock” function may be provided to allow the higher layers to inform the FSMDC layer that the file map is no longer being referenced and thus the FSMDC layer is now free to reclaim any blocks or completely reorganize a file (for example, defragging). However, unlike a conventional system, the SPMDC  180  need not receive specific client communications closing out of a file. In this regard, if the lease on the file expires it is exactly as if the call to “unlock” was made. The FSMDC need not keep counters to track how many times a particular file was locked. A single “unlock” will unlock the file. Instead, the higher levels of software in the SPNDC track how many parties are active on a file and issue or defer issuing the unlock call. The SPMDC  180  may, for example, issue the unlock call when no leases are in effect and no file changes have occurred. 
     As described above, the client  130  will provide a desired lease value to the SPMDC layer, and typically client nodes may ask for very short leases (i.e. 5 seconds) for files opened for read-only access. Files opened for read-write access are likely to have requests for much longer leases. Once a lease has been granted, the clients may typically let the lease expire rather than specifically “closing” the session, particularly for a read-only file access; this save much overhead in network communication. For read/write file accesses the client may report (or the SPMDC may monitor the FSMDC to detect) the end-of-file pointer when file size changes. 
     Thus, the FSMDC layer concerns itself with delivering file maps and considers the allocated blocks of a file “locked” until the unlock function is called. The SPC layer implements the concept of leases, and manages calling the unlock finction as needed. The SPMDC needs two file size values: the current reported file length (File Size) and the allocation size. For efficiency, when creating or extending a file, SPMDC application may ask that the file grow by a very large amount (100 MB for instance). It is assumed that the cost of allocating a small amount of space is about the same (overall) as allocating a larger amount, and thus to over-allocate minimizes the number of times a file will need to be extended, an extremely important feature for LAN transmissions, network burden and related issues. Further, it is contemplated that a file&#39;s size may be changed at any time to any value by the local FSMDC or any client  130 . 
     The allocation size, however, is only allowed to grow, until there are no locked-maps active. That is, if the SPMDC provides a locked-map to a requester, it is obligated to never reclaim and reassign those blocks until the file is unlocked (regardless if the request comes from a local process on the FSMDC or a client  130 . Further, the SPMDC should report “file size” to any inquiring application, and not the allocation size. The file sharing application  180  employs a GetMap function to allow the SPMDC to report both values. Similarly, there are functions provided by the FSMDC layer to allow SPMDC layer to change either or both values. 
     A more detailed understanding of the one implementation of a shared access file management system  180  and the how the client-to-SPMDC communications are effected based on the above described layered control structure may be had from Appendix B attached hereto, which describes a communications and interface protocol for effecting such shared access, maintaining suitable versions and allocations, and interfacing with the different equipment and system layers to carry out MDC functions for the multiply-accessed data blocks. 
     Applicant has identified this file system enhancement by the acronym MOTEL, denoting method of terminating enhanced leases, and has described above a simple implementation that removes the need for multiple extra network communications to coordinate file status and changes by simply issuing leases and effecting or allowing storage changes when leases are expired. The sharing protocol, rather than placing a bottleneck in front of all file request transactions, allows relatively direct file access and carries out storage housekeeping in the relatively few instances where it is needed by delaying or shifting file management tasks to not interfere with outstanding access grants, thus allowing relatively unencumbered direct storage sharing for routine file accesses. In general, it will be very efficient for the client to resort to a server-mediated access protocol such as the SANergy system, for interfacing with the storage device. It may also be advantageous, for certain classes of files, to maintain and provide “ghost” copies of file data from the server to the client, in a procedure as described in the above-referenced United States Patent. 
     When used in conjunction with a shared access file system as described in the aforesaid U.S. patent, the file manager may include a bypass mechanism, which executes on at least the client node, to intercede in the response to at least selected input/output, or access, requests generated by that node, and transfer data designated by such requests directly between the client node and the storage device, in lieu of transferring that data via the server. Such transfers by the bypass are made using the administrative information maintained by the file system relating to storage of such data on the peripheral device. The bypass can intercede in response to requests by the applications programs executing on the client node to read or write data on the peripheral device. Rather than permitting the file system to transfer that data via the server node and network, the bypass transfers it directly to the peripheral device. A further understanding of these and other aspects of this aspect of the system may be attained by reference to the aforesaid patent, the teachings of which (as noted above) are incorporated herein by reference. 
     Described herein are methods and apparatus meeting the objects set forth above. Those skilled in the art will appreciate that the illustrated embodiment is shown and described merely by way of example and that other embodiments incorporating changes therein fall within the scope of the invention. Thus, by way of non-limiting example, it will be appreciated that the invention has application in digital data processing systems other than storage area networks of the type illustrated in FIG. 1 and, indeed, may be applied in a variety of network and/or shared access environment. By way of further example, it will be appreciated that although the illustrated embodiment provides for leases among nodes that share storage devices, the teachings are equally applicable to the provision of leases client threads or processes which shall be understood to fall within the meaning of “nodes” as used in this regard herein. In view of the foregoing,