Delegation of metadata management in a storage system by leasing of free file system blocks and i-nodes from a file system owner

Metadata management in a file server or storage network is delegated from a primary data processor to a secondary data processor in order to reduce data traffic between the primary data processor and the secondary data processor. The primary data processor retains responsibility for managing locks upon objects in the file system that it owns, and also retains responsibility for allocation of free blocks and inodes of the file system. By leasing free blocks and inodes to the secondary and granting locks to the secondary, the secondary can perform the other metadata management tasks such as appending blocks to a file, truncating a file, creating a file, and deleting a file.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to data storage systems, and more particularly to network file servers. The present invention specifically relates to a network file server in which file access is shared among a number of processors by granting file locks and distributing file metadata to the processors.

2. Description of the Related Art

Mainframe data processing, and more recently distributed computing, have required increasingly large amounts of data storage. This data storage is most economically provided by an array of low-cost disk drives integrated with a large semiconductor cache memory.

In a network environment, at least one data mover computer is used to interface the cached disk array to the network. The data mover computer performs file locking management and mapping of the network files to logical block addresses of storage in the cached disk array, and moves data between network clients and the storage in the cached disk array.

In relatively large networks, it is desirable to have multiple data mover computers that access one or more cached disk arrays. Each data mover computer provides at least one network port for servicing client requests. Each data mover computer is relatively inexpensive compared to a cached disk array. Therefore, multiple data movers can be added easily until the cached disk array becomes a bottleneck to data access.

Unfortunately, data consistency problems may arise if concurrent client access to a read/write file is permitted through more than one data mover. These data consistency problems can be solved in a number of ways. For example, as described in Vahalia et al., U.S. Pat. No. 5,893,140 issued Apr. 6, 1999, entitled “File Server Having a File System Cache and Protocol for Truly Safe Asynchronous Writes,” incorporated herein by reference, locking information can be stored in the cached disk array, or cached in the data mover computers if a cache coherency scheme is used to maintain consistent locking data in the caches of the data mover computers.

When a large number of clients are concurrently accessing shared read-write files, there may be considerable access delays due to contention for locks not only on the files but also on the file directories. One way of reducing this contention is to assign each file system to only one data mover assigned the task of managing the locks on the files and directories in the file system. This permits the data mover file manager to locally cache and manage the metadata for the files and directories of the file system. For example, as described in Xu et al., U.S. Pat. No. 6,324,581, issued Nov. 27, 2001, incorporated herein by reference, the data mover acting as the manager of a file grants a lock on the file and provides metadata of the file to another data mover servicing a client request for access to the file. Then the data mover servicing the client request uses the metadata to directly access the file data in the cached disk array. Moreover, in some network configurations, the clients can be trusted to access directly the data in the cached disk array. In such a configuration, a network client can send a request for a file lock and file metadata directly to the file manager. Upon being granted a lock on the file and receiving the file metadata, the trusted client can access directly the file data in the cached disk array.

SUMMARY OF THE INVENTION

It has been discovered that in a file server of the kind that uses a file manager to manage file locks and file metadata for an assigned file system, it is possible for the file manager to delegate certain metadata management tasks to another processor or to a trusted client. By delegating these metadata management tasks, there is a reduction in the amount of data traffic with the file manager when accessing the metadata of the assigned file system. This is especially advantageous for avoiding peak load conditions when the file manager might concurrently receive a large number of requests for locks and metadata.

In accordance with one aspect of the invention, there is provided a method of operating a primary data processor and a secondary data processor for access to a file system in data storage. The method includes the primary data processor managing locks upon files in the file system, and managing allocation of free blocks of the file system. The method further includes the secondary data processor appending new data to a file in the file system by obtaining an allocation of at least one free block from the primary data processor, writing the new data to the free block, obtaining a lock on the file from the primary data processor, and linking the free block to the file.

In accordance with another aspect, the invention provides a method of operating a primary data processor and a secondary data processor for access to a file system in data storage. The method includes the primary data processor managing locks upon objects in the file system, and managing allocation of free blocks and free inodes (i.e., index nodes) of the file system. The method further includes the secondary data processor creating a new file of the file system by the secondary data processor obtaining an allocation of a free inode and at least one free block from the primary data processor, the secondary data processor writing file attributes to the free inode and linking the free block to the free inode, the secondary data processor obtaining, from the primary data processor, a lock on a directory of the file system to contain an entry for the new file, and the secondary data processor inserting the entry for the new file into the directory.

In accordance with yet another aspect, the invention provides a method of operating a primary data processor and a secondary data processor for access to a file system in data storage. The method includes the primary data processor managing locks upon objects in the file system, and managing allocation of free blocks and free inodes of the file system. The method further includes the secondary data processor accessing objects of the file system by obtaining an allocation of free blocks and free inodes of the file system from the primary data processor, obtaining locks on the objects of the file system from the primary data processor, using the free blocks and free inodes to create new structure in the file system, and writing new metadata of the file system objects to storage over a data path that bypasses the primary data processor.

In accordance with still another aspect, the invention provides a storage system. The storage system includes data storage containing a file system, a primary data processor linked to the data storage for access to metadata of the file system for locking files of the file system and allocating free blocks in the file system, and a secondary data processor linked to the data storage for access to data and metadata of the file system over a data path that bypasses the primary data processor, and linked to the primary data processor for requesting and obtaining locks on the files in the file system and requesting and obtaining allocations of free blocks in the file system. The secondary processor is programmed for writing data to a specified file in the file system by obtaining an allocation of at least one free block from the primary data processor, writing data to the free block, obtaining a lock on the specified file from the primary data processor, and appending the free block to the specified file by writing new metadata for the specified file to the file system in the data storage over the data path that bypasses the primary data processor.

In accordance with yet still another aspect, the invention provides a file server including a cached disk array containing a plurality of file systems, and a plurality of data mover computers each linked to the cached disk array over a respective data path that bypasses the other data mover computers for accessing data and metadata of the file systems. Each of the data mover computers also has a port for connection to a data network for receiving file system access requests from clients in the data network. Locks upon files in each file system are exclusively managed by a respective one of the data movers that is primary with respect to the file system. The data mover that is primary is with respect to each file system also allocates free blocks of the file system. Each data mover computer that is secondary with respect to each file system is programmed to obtain an allocation of free blocks of the file system from the data mover computer that is primary with respect to the file system. Each data mover computer that is secondary with respect to each file system is programmed to respond to a client request for writing data to a specified file in the file system by appending the data to the specified file in the file system by requesting the data mover computer that is primary with respect to the file system to grant a lock upon the specified file to the data mover computer that is secondary with respect to the file system, writing the data to at least one free block of the file system allocated to the data mover computer that is secondary with respect to the file system, and once the data mover computer that is primary with respect to the file system grants the requested lock upon the specified file, the data mover computer that is secondary with respect to the file system appending the at least one free block of the file system to the specified file by writing new metadata for the specified file to the file system in the cached disk array over the respective data path that bypasses the data mover computer that is primary with respect to the file system.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown in the drawings and will be described in detail. It should be understood, however, that it is not intended to limit the invention to the particular forms shown, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the invention as defined by the appended claims.

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Referring toFIG. 1, there is shown a network file server architecture that uses distributed locking. In this example, a file server20includes a file manager21and data storage such as a file system22in a cached disk array23. The file manager21, for example, is a high-end commodity computer including a single-chip processor, a PCI or EISA bus, random access memory, a hard disk drive for nonvolatile program storage, and a floppy disk drive for loading programs. The cached disk array23, for example, is a Symmetrix 5500 (Trademark) cached disk array manufactured and sold by EMC Corporation, 35 Parkwood Drive, Hopkinton, Mass. 01748.

The file manager21manages locking information for the files in the file system22. The locking information is stored in the cached disk array23, and the file manager21maintains a cache memory of recently accessed locking information and other related metadata.

As shown inFIG. 1, the file manager21has at least one network port131connected through a data network30to a first client24and a second client25. The network port31is shared among requests from the clients24,25, although a separate respective network port could be provided for each of the clients24,25. Each client24,25also has a respective bypass data path26,27that bypasses the file manager21for reading data and metadata from and writing data and metadata to the file system22. The cached disk array23has one network port132for the bypass data path26, and another network port133for the bypass data path27. Alternatively, the two bypass data paths26,27could share one network port of the cached disk array23, although such sharing could limit the maximum data transfer rate to the data storage in the cached disk array for simultaneous data access by the clients24,25.

Before reading or writing to the file system22, a client first issues a request for a lock to the file manager21. The file manager21responds by placing a lock on the file to be accessed, and returning metadata including at least one pointer to where the data or additional metadata to be accessed is stored in the file system. The client uses the pointer to formulate a read or write request sent over the bypass data path to the file system22.

With reference toFIG. 2, there is shown a more complex network file server architecture that permits storage resources to be incrementally added to provide sufficient storage capacity for any desired number of file systems. In this example, a data network40includes a first file manager31, a second file manager32, a first cached disk array35, a second cached disk array36, a first client38, and a second client39. In this example, the data movers31,32and the cached disk arrays35,36could be spaced from each other, placed at various geographic locations, and interconnected by high-speed Fibre Channel data links. Alternatively, the cached disk arrays35,36and file managers31,32could be placed in the same geographic location. For example, if the cached disk arrays and file managers were placed in the same geographic location, they could be constructed and interconnected as shown in Vahalia et al. U.S. Pat. No. 5,893,140, issued Apr. 6, 1999, incorporated herein by reference.

InFIG. 2, the first file manager31manages the file locking information of a first file system33in the first cached disk array35, and the second file manager32manages the locking information of a second file system34in the second cached disk array36. In particular, the locking information for each file system33,34is managed exclusively by only one of the file managers31,32. This exclusive relationship will be referred to by saying each file system has a respective file manager that is the owner of the file system. Therefore, the first file manager31is the owner of the first file system33, and the second file manager32is the owner of the second file system34.

The first file manager31is connected to the first cached disk array35for the communication of metadata of the first file system33, and the second file manager32is connected to the second cached disk array36for the communication of metadata of the second file system34. The first file manager31is connected to the second file manager32for the communication of metadata and control information with respect to the first file system33and the second file system34. The first file manager31is linked to a first client38for the communication of metadata and control information with respect to the first file system33and the second file system34. The second file manager32is linked to a second client39for the communication of metadata and control information with respect to the first file system33and the second file system34.

The first client38has a bypass data path42to the first file system33for bypassing the first file manager31, and a bypass data path43to the second file system34for bypassing the first file manager31and also bypassing the second file manager32. The second client39has a bypass data path44to the first file system33for bypassing the first file manager31and the second file manager32, and a bypass data path45to the second file system34for bypassing the second file manager32.

The first client38accesses the first file system33in the fashion described above with respect toFIG. 1, by obtaining a lock from first file manager31and then accessing the first file system33over the bypass data path42. To access the second file system34, however, the first client issues a request for a lock to the first file manager31. The first file manager31recognizes that it is not the owner of the file system to be accessed, and therefore forwards the request to the second file manager32. The second file manager32responds by placing an appropriate lock on the file to be accessed, and returning metadata including at least one pointer to where the data or additional metadata to be accessed is stored in the second file system34. The first file manager31relays the pointer to the first client38. The first client uses the pointer to formulate a read or write request sent over the bypass data path43to the second file system34.

In a similar fashion, the second client39accesses the second file system34in the fashion described above with respect toFIG. 1, by obtaining a lock from the second file manager32and then accessing the second file system34over the bypass data path45. To access the first file system33, the second client39issues a request for a lock to the second file manager32. The second file manager32recognizes that it is not the owner of the file system to be accessed, and therefore forwards the request to the first file manager31. The first file manager31responds by placing a lock on the file to be accessed, and returning metadata including at least one pointer to where the data or additional metadata to be accessed is stored in the first file system33. The second file manager32relays the pointer to the second client38. The second client uses the pointer to formulate a read or write request sent over the bypass data path44to the first file system33.

In the storage network ofFIG. 2, the file managers may also access file data in the file systems33,34in the cached disk arrays35,36. For example, the first file manager31has a data path46to the first cached disk array35, and a data path47to the second cached disk array36that bypasses the second file manager32. The second file manager32has a data path48to the second cached disk array36, and a data path49to the first cached disk array that bypasses the first file manager31. If a file manager desires to access directly data of a file in a file system that is owned by another file manager, it must ask the owner for a lock on the file before accessing the file data.

The file system management method introduced inFIG. 2can also be used in a network file server having multiple processors for servicing client requests. With reference toFIG. 3, a network file server110has a plurality of data mover computers115,116,117, each of which manages a respective file system. Each data mover computer115,116,117has a respective port to a data network111having a number of clients including work stations112,113. The data network111may include any one or more network connection technologies, such as Ethernet, and communication protocols, such as TCP/IP or UDP. The work stations112,113, for example, are personal computers.

The preferred construction and operation of the network file server110is further described in Vahalia et al., U.S. Pat. No. 5,893,140 issued Apr. 6, 1999, incorporated herein by reference. The network file server110includes a cached disk array114. The network file server110is managed as a dedicated network appliance, integrated with popular network operating systems in a way, which, other than its superior performance, is transparent to the end user. The clustering of the data movers115,116,117as a front end to the cached disk array114provides parallelism and scalability. Each of the data movers115,116,117is a high-end commodity computer, providing the highest performance appropriate for a data mover at the lowest cost. The data movers may communicate with each other over a dedicated dual-redundant Ethernet connection118. The data mover computers115,116, and117may communicate with the other network devices using standard file access protocols such as the Network File System (NFS) or the Common Internet File System (CIFS) protocols, but the data mover computers do not necessarily employ standard operating systems. For example, the network file server110is programmed with a Unix-based file system that has been adapted for rapid file access and streaming of data between the cached disk array114and the data network111by any one of the data mover computers115,116,117. Therefore, each client112,113may access any of the file systems through any one of the data mover computers115,116,117, but if the data mover computer servicing the client does not own the file system to be accessed, then a lock on the file system to be accessed must be obtained from the data mover computer that owns the file system to be accessed.

In the data storage networks ofFIGS. 1,2or3, it is possible for a write operation to change the attributes of a file, for example, when the extent of a file is increased by appending data to a file. When a write operation will change the metadata of a file, the metadata must be managed in a consistent fashion, in order to avoid conflict between the file manager owning the file, and the client or file manager performing the write operation. For example, as described in the above-cited Xu et al., U.S. Pat. No. 6,324,581, when a write operation changes the metadata of a file, the new metadata is written to the file manager owning the file. This ensures that the file manager owning the file maintains consistent metadata in its cache.

It has been discovered that in a file server of the kind that uses a file manager to manage locks for an assigned file system, it is possible for the file manager to delegate certain metadata management tasks to another file manager or to a trusted client. By delegating these metadata management tasks, there is a reduction in the amount of data traffic with the file manager when accessing the file system owned by the file manager. This is especially advantageous for avoiding peak load conditions when the file manager might concurrently receive a large number of requests for locks.

With reference toFIG. 1, for example, the file manager21delegates metadata management tasks to the clients24,25so that the clients may read or write certain metadata directly to and from the file system22in the cached disk array23instead of reading or writing that metadata to and from the file manager21. This may increase the performance of the system inFIG. 1when the client access to the file manager is more limited than the client access to the cached disk array.

With reference toFIG. 2, the delegation of metadata management tasks to the clients38,39is useful for avoiding peak loading upon the file manager owner31or32when the clients38,39would happen to perform concurrent write operations to the same one of the file systems33or34. The delegation of metadata management tasks to the clients38,39also reduces data traffic between the file managers31,32.

With reference toFIG. 3, the data mover owning a particular file system will be referred to as the primary data mover for that file system, and the data movers that do not own that file system will be referred to as the secondary data movers for that file system. For example, inFIG. 3, the file system “B:”120is owned by the data mover116, so that the data mover116is the primary data mover for the file system “B:” and the data movers115and117are secondary data movers with respect to the file system “B:”,

In the network file server110ofFIG. 3, the delegation of metadata management tasks to the secondary data movers115,116,117is useful for avoiding peak loading upon the primary data movers115,116, or117when the client workstations112,113would happen to perform concurrent write operations to the same one of the file systems119,120,121, or122. The delegation of metadata management tasks to the secondary data movers115,116,117also reduces data traffic over the link118between the data movers.

In a preferred implementation, the file system owner delegates the task of metadata management in order to permit a client, secondary file manager or secondary data mover to modify metadata of a file or directory in the on-disk file system. For example, the metadata of a file may be changed during an append or truncation of a file, and the metadata of a directory may be changed during the creation or deletion of a file in the directory. In order to delegate these tasks, the file system owner not only grants locks upon the file or directory to a client, secondary file manager or secondary data mover, but also “leases” inodes and blocks of the file system to the client, secondary file manager or secondary data mover.

FIG. 4shows various inodes and blocks in a UNIX (Trademark) based file system, such as the System V file system (s5fs) and the Berkeley Fast File System (FFS), as described in chapter 9 of Uresh Vahalia,UNIX Internals: The New Frontier,Prentice-Hall, Inc., 1996, p. 261–289. In general, a file system includes a hierarchy of directories, and each directory can be an index for a number of subdirectories or files. For the particular file system shown inFIG. 4, the hierarchy of directories has a top-level root directory51, which is an index to a subdirectory52and a subdirectory53. The subdirectory53has been expanded to show that it is comprised of a directory inode54and a directory block57. The directory inode54includes attributes55of the subdirectory53(such as the file type, access permissions, owner information, and access history) and other metadata such as block numbers56, one of which points to the directory block57. The directory block57contains a table of inode numbers associated with respective file names of the subdirectories and files indexed by the subdirectory53. For example, the first inode number points to a file inode58containing attributes59of a file and block numbers60pointing to file blocks61and62containing data of the file. The file block62is a so-called indirect block, which contains a pointer to another file block63of the file.

FIG. 5shows the management of metadata by a primary data mover or file manager140that owns a file system143in storage of a cached disk array142, and a data mover or client141that is secondary with respect to the file system. The on-disk file system143includes free blocks144, free inodes145, allocated blocks146, and allocated inodes147. The allocated blocks146may contain valid file or directory data, and the allocated inodes147may contain valid file or directory attributes.

The primary data mover or file manager140manages leasing of the free blocks144and free inodes145to the secondary data mover or client141. In response to a lease request for free blocks or free inodes, the primary data mover or file manager140allocates a number of the free blocks144or free inodes145to the secondary data mover or client141, and returns to the secondary a list of pointers (block numbers or inode numbers) to the leased blocks and inodes. For lease management, the primary140maintains leasing information148including a pointer to a next free block144not yet leased or allocated, and a pointer to a next free inode146not yet leased or allocated. For recovering from a “crash” or failure of the secondary data mover or client141, the leasing information148may also include a log of the leased blocks and inodes and the lease holders.

The primary data mover or file manager140also manages the granting of locks on files and directories to the secondary data mover or client141. The primary data mover or file manager140maintains locking information149identifying the locked file system objects and lock holders. The locking information may also include, for each locked object, a list of outstanding requests for a conflicting lock.

In operation, the secondary data mover or client141maintains a list150of pointers to leased free blocks, and a list of pointers151to leased free inodes. When the list150or151is nearly empty, or when the secondary141needs more pointers to free blocks or inodes for the delegated metadata management, the secondary141sends a lease request to the primary data mover or client140to obtain more pointers.

When the secondary data mover or client141needs to read or write to a directory or file in the file system143owned by the primary data mover or file manager140, the secondary141first sends a lock request to the primary140. The lock request, for example, specifies the path name of the file or directory, and the type of access (read-only or read-write). The primary data mover or file manager140does a file system lookup on the path name of the directory or file in order to find the directory block entry (see57inFIG. 4) including the directory or file name and the file inode number associated with the directory or file name. The primary data mover or file manager140checks whether there is a read or write lock presently held on the associated directory or file inode, and checks whether any lock presently held conflicts with the requested lock. The primary data mover or file manager140may also check for conflict with any access permission attribute in the associated directory or file inode. If there is no conflict, then the primary data mover or file manager140returns a lock grant to the secondary data mover or client141, including the inode number of the associated directory or file inode. The secondary data mover or client141then uses the inode number to directly access the metadata in the directory or file inode in the on-disk file system143.

For certain write operations, the secondary data mover or client141may change the metadata in the directory or file inode in the on-disk file system143, without writing the new metadata to the primary data mover or file manager140. If the primary data mover or file manager140keeps a local cache of the directory or file inode, then the directory or file inode in that local cache should be invalidated when the primary140grants a write lock on the directory or file inode to the secondary data mover or client141. Therefore, if and when the primary data mover or client manager140would later need to access the directory or file inode, the primary140would first check that there is no conflicting lock on the directory or file inode, and then grant itself a lock on the directory or file inode, and then refresh its local cache by fetching the directory or file inode from the on-disk file system143. In this fashion, new metadata from the secondary data mover or client141is written to the cached disk array142and transferred to the primary data mover or file manager140. Because of the “fast write” capability of the cached disk array (i.e., data written to the cache of the cached disk array is considered to be in the on-disk file system143before the data is actually written to disk of the cached disk array), there can be a very rapid transfer of metadata through the cached disk array142from the secondary data mover or client141to the primary data mover or file manager140.

For certain write operations, the delegated metadata management alters the structure of the file system by adding blocks or inodes. For extending a directory or file, the secondary data mover or client141removes one of the pointers from the list150to obtain the block number of a free block to become the block appended to the directory or file. The secondary data mover or client141, for example, transfers the free block from the pool of free blocks144in the on-disk file system143and links it into the file system data structure of allocated inodes147. For creating a new directory or a new file, the secondary data mover or client141removes one of the pointers from the list151to obtain the inode number of a free inode to become the inode of the new directory or new file. The secondary data mover or client141, for example, transfers the free inode from the pool of free inodes145in the on-disk file system143and links it into the file system data structure of allocated inodes147in the on-disk file system.

FIGS. 6 and 7further show the delegation of metadata management from the primary data mover or file manager to the secondary data mover or file manager or client. In a first step161, the secondary asks the primary for a set of free blocks and free inodes of a file system owned by the primary. In step162, the primary receives the request, and allocates the set of free blocks and free inodes of the file system. For example, if the secondary asks for sixty-four free blocks, then the primary will advance its “pointer to next free block” by sixty-four blocks through the pool of free blocks (144inFIG. 5) of the on-disk file system, to obtain a set of sixty-four block numbers for the secondary. The pool of free blocks, for example, is maintained as a linked list of block numbers, so that the primary may keep a local cache of the linked list of block numbers, and refresh the linked list in its local cache from the linked list in the on-disk file system when its “pointer to next free block” nearly reaches the end of its local copy of the linked-list.

In step163, the secondary receives the block numbers and inode numbers of the leased set of free blocks and free inodes of the file system. Some time later, in step164, the secondary receives a request from a client or application program instance for access to an object (such as a directory or file) in the file system. Execution continues from step164to step165inFIG. 7.

In step165inFIG. 7, the secondary asks the primary for a lock upon the object in the file system. In step166, the primary receives the request, grants to the secondary a lock upon the object in the file system, and returns the inode number of the object to the secondary. In step167, the secondary receives the inode of the object, indicating that the requested lock has been granted. In step168, the secondary uses the inode number of the object and at least one of the block numbers of the free blocks or at least one inode number of the free inodes to perform an append, truncate, create, or delete operation upon the object without further assistance from the primary. In step169, the lock on the object is released from the secondary.

After step169, execution loops back to step161ofFIG. 6to replenish the secondary's set of leased free blocks and free inodes of the file system owned by the primary, at least if the number of the leased free blocks or the number of the leased free inodes has been depleted. In this fashion, the secondary's access of objects of the file system in steps164to169is not delayed in order to obtain free blocks and free inodes of the file system owned by the primary.

FIG. 8shows specific steps for performing an append operation in accordance with the method ofFIG. 7. In step171, the secondary asks the primary for a lock on the file. In step172, the secondary writes data to at least one of the free blocks indicated by the block numbers obtained from the primary. In step173, when the secondary receives the inode number indicating the grant of the requested lock on the file, the secondary appends the block(s) to the file by updating the file metadata in the on-disk file system. Finally, in step174, the secondary releases the lock on the file, for example, when requested by the primary.

FIG. 9shows specific steps for performing a truncation operation in accordance with the method ofFIG. 7. In step181, the secondary asks the primary for a lock on the file. In step182, when the secondary receives the inode number from the primary indicating the grant of the requested lock on the file, the secondary removes at least one block from the file by updating the file metadata in the on-disk file system. In step183, the secondary may use the freed block(s), and return any unused free block to the free buffer pool in the on-disk file system. Finally, in step184, the secondary releases the lock on the file, for example, when requested by the primary.

FIG. 10shows specific steps for performing a file creation operation in accordance with the method ofFIG. 7. In a first step191, the secondary asks the primary for a lock on the directory that will contain the file. In step192, the secondary uses one of the pointers to the leased free inodes and at least one of the pointers to the free blocks to put attributes of the new file into a free inode linked to at least one free block. In step193, when the secondary receives the inode number from the primary indicating the grant of the requested lock on the directory, the secondary inserts an entry for the file into the directory by updating the directory in storage. Finally, in step194, the secondary releases the lock on the directory, for example, when requested by the primary.

FIG. 11is a flow chart showing specific steps for performing a file deletion operation in accordance with the method ofFIG. 7. This particular file deletion operation can be performed on a file that is a directory so long as the directory is empty. In other words, before deleting a directory, all of the subdirectories and files in the directory should be deleted.

In a first step201ofFIG. 11, the secondary asks the primary for a lock on the file and a lock on the directory containing the file. In step202, when the secondary receives the file inode number and the directory inode number from primary indicating the grant of the requested locks, the secondary removes the file entry from the directory by updating the directory in storage. This not only deletes the file but also has the side-effect of releasing the lock on the file. In step203, the secondary may use the inode and blocks of the file, and return any unused inode and blocks of the file to the free inode pool and free block pool in the on-disk file system. Finally, in step204, the secondary releases the lock on the directory, for example, when requested by the primary.

In view of the above, there has been described a method of delegation of metadata management in a file server or storage network from a primary data processor to a secondary data processor in order to reduce data traffic between the primary data processor and the secondary data processor. The primary data processor retains responsibility for managing locks upon objects in the file system that it owns, and also retains responsibility for allocation of free blocks and inodes of the file system. By leasing free blocks and inodes to the secondary and granting locks to the secondary, the secondary can perform the other metadata management tasks such as appending blocks to a file, truncating a file, creating a file, and deleting a file.

It should be understood that the preferred embodiment as described above can be modified in various ways without departing from the scope of the invention as defined by the appended claims. For example, it is not necessary to delegate all of the metadata management functions described above to the secondary. Depending on the margin of loading of the primary to secondary data path relative to the margin of loading of the secondary to storage data path, some but not all of the metadata management functions may be delegated in order to balance the margin of loading of the data paths. For example, in a particular file server configuration, it may be desirable to delegate only the “append to a file” and “truncate a file” functions. This provides a modest decrease in loading of the primary to secondary data path, and a low level of implementation complexity, because the primary need not lease inodes.