System for repeated unmount attempts of distributed file systems

The present invention provides a computer implemented method and apparatus for unmounting file systems from a plurality of file servers. The method comprises of issuing an unmount command targeting a file system of a first server among the plurality of file servers. The timeout period is then expired without receiving an unmount acknowledgement associated with the unmount command. Thus, the timeout period is associated with an allowable time for the file system to acknowledge unmounting. In response to expiring the timeout period, a ping is transmitted to the first server among the plurality of file servers. The ping timeout then expires based on a failure to receive a ping acknowledgment corresponding to the ping. This action marks the first server for a later retry of unmounting to form a marked set based on the first server.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to a computer implemented method, data processing system, and computer program product for robust unmounting of file systems from a client data processing system. More specifically, the present invention relates to recurring unmounts of a file system, prior to forcing a file system to unmount, if necessary.

2. Description of the Related Art

Architects of modern data centers have found a way to build flexible storage for data that permits scaling addressable storage. One way to build such a data center is to implement network file systems, for example, Network File System (NFS). A file system is an apparatus for organizing files and associated metadata to enable access of such files and metadata within non-volatile storage, such as, for example, hard disk drives. Such systems may be based on Request For Comments (RFC) 1094, RFC 1813, RFC 3010, RFC 3530, for example. Among the benefits established for such systems is the ability to present disk stores located on a network to a client machine in a manner as though such disk stores were locally attached to the client machine.

Typically, when a client data processing system boots up, the client mounts disk stores in accordance with a file systems table or fstab (also known as file structure table). In complex systems, the client may have over a hundred disk stores so mounted. These disk stores, as well as other permanent storage, can be written to, but at a slower rate than memory local to the client data processing system. Accordingly, disk stores, and the file systems that they support, can respond sluggishly, particularly when disk writes are finalized prior to shutting down.

Among the tasks assigned to administrators of a system, is the task to perform routine maintenance, repair and upgrades. Accordingly, the client system may require rebooting or even shutting down. Delays in shutting down can occur because of complex associations with remote file systems using a Network File System (NFS). For example, a server that hosts one or more file systems for a client may be down for repairs or otherwise unreachable over a network. A server is a data processing system that processes data in response to requests by other data processing systems or clients. A client, in this example, is a data processing system that makes requests to process data to a server.

NFS clients rely on block storage devices implemented as file systems. A block storage device can be a hard drive or other storage device. Such computers rely on a system of performing preliminary writes of data to long-latency storage by buffering one or more write results to memory, and then triggering a complete transfer of the data from memory to the storage in a single action. This method accomplishes some efficiency, but can leave data susceptible to data corruption if the storage is disconnected or unavailable from the memory. System architects use a mechanism to obtain a consistent state between disk writes and disk reads buffered in a system's volatile memory and the host block device. One such mechanism is the flush command. A flush command instructs a data processing system to write completely any data of a read/write buffer to disk or other storage. Accordingly, a client computer can shutdown or otherwise disconnect at such that the state of the client computer matches the state of a supporting, but remote file system.

Prior art shutdown techniques of a client involved unmounting each file system in sequence, always waiting for a previously commanded unmount to be acknowledged by a server prior to issuing a further unmount command to the server. Even in cases where an acknowledgement was not received within a reasonable timeout period, the client would repeat unmount commands for a subsequent file system hosted on a server that previously was unresponsive. Often repeated conventional unmount commands are unproductive, and can prolong the shutdown of a client.

Accordingly, it can be helpful for a client to discover and avoid an unresponsive server.

SUMMARY OF THE INVENTION

The present invention provides a computer implemented method and apparatus for unmounting file systems from a plurality of file servers. The method comprises of issuing an unmount command targeting a file system of a first server among the plurality of file servers. The timeout period is then expired without receiving an unmount acknowledgement associated with the unmount command. Thus, the timeout period is associated with an allowable time for the file system to acknowledge unmounting. In response to expiring the timeout period, a ping is transmitted to the first server among the plurality of file servers. The ping timeout then expires based on a failure to receive a ping acknowledgment corresponding to the ping. This action marks the first server for a later retry of unmounting to form a marked set based on the first server.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With reference now to the figures and in particular with reference toFIG. 1, a block diagram of a data processing system is shown in which aspects of an illustrative embodiment may be implemented. Data processing system100is an example of a computer, in which code or instructions implementing the processes of the present invention may be located. In the depicted example, data processing system100employs a hub architecture including a north bridge and memory controller hub (NB/MCH)102and a south bridge and input/output (I/O) controller hub (SB/ICH)104. Processor106, main memory108, and graphics processor110connect to north bridge and memory controller hub102. Graphics processor110may connect to the NB/MCH through an accelerated graphics port (AGP), for example.

In the depicted example, local area network (LAN) adapter112connects to south bridge and I/O controller hub104and audio adapter116, keyboard and mouse adapter120, modem122, read only memory (ROM)124, hard disk drive (HDD)126, CD-ROM drive130, universal serial bus (USB) ports and other communications ports132, and PCI/PCIe devices134connect to south bridge and I/O controller hub104through bus138and bus140. PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards, and PC cards for notebook computers. PCI uses a card bus controller, while PCIe does not. ROM124may be, for example, a flash binary input/output system (BIOS). Hard disk drive126and CD-ROM drive130may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. A super I/O (SIO) device136may be connected to south bridge and I/O controller hub104.

An operating system runs on processor106and coordinates and provides control of various components within data processing system100inFIG. 1. The operating system may be a commercially available operating system such as Microsoft® Windows® XP. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. An object oriented programming system, such as the Java™ programming system, may run in conjunction with the operating system and provides calls to the operating system from Java™ programs or applications executing on data processing system100. Java™ is a trademark of Sun Microsystems, Inc. in the United States, other countries, or both.

Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as hard disk drive126, and may be loaded into main memory108for execution by processor106. The processes of the present invention can be performed by processor106using computer implemented instructions, which may be located in a memory such as, for example, main memory108, read only memory124, or in one or more peripheral devices.

Those of ordinary skill in the art will appreciate that the hardware inFIG. 1may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, and the like, may be used in addition to or in place of the hardware depicted inFIG. 1. In addition, the processes of the illustrative embodiments may be applied to a multiprocessor data processing system.

The aspects of the illustrative embodiments provide a computer implemented method, data processing system, and computer program product for concluding disk accesses on a Networking File System (NFS) store, for example, in response to shutting down a client. A feature of such a system can be to perform a ping of a suspect server in response to a failure to receive an acknowledgement of completed disk writes within an allowable time. Accordingly, further attempts to unmount file systems from such a server may be suspended until other servers have been requested to unmount their respectively served file systems. If a marked server is dead or unresponsive during a later retry, the system may force an unmount of all the file systems mounted on that marked server.

FIG. 2is a logical diagram of mounted file systems to locally named directories in accordance with an illustrative embodiment of the invention. Client210supports locally named directories, such as client:/a, client:/b; client:/c, client:/d, client:/e, and client:/f. Directories client:/a, client:/b, and client:/c are coupled by a mount procedure to the file systems of server A220, in this case, server A:/x, server A:/y, and server A:/z, respectively. Similarly, directories client:/d, client:/e, client:/f are coupled by a mount procedure to the file systems of server B230, in this case server B:/x, server B:/y and server B:/z, respectively. In such a configuration, the file systems of server A:/x, server A:/y, and server A:/z, may be grouped together. Since each file system is dependent on common hardware elements, there is a strong correlation between the availability of one such file system being available and another file system of the group being available. It is appreciated that the configuration ofFIG. 2is only an example. In addition to server A220and server B230, additional servers may form a plurality of file servers.

The coupling between directory and file system may be via a network. Such a network may be wired or wireless. Similarly, there may be local segments to the network, as well as remote segments. Such interconnect is simplified inFIG. 2by showing a single logical link between a directory and the file system that supports the directory. For example, link215supports commands to mount and unmount server A:/x along a path from client:/a to server A:/x. An unmount command is a command issued by a client that requests write buffers of the client to actually be written to the corresponding file system hosted by the server. As a result, the logical link can be closed gracefully. By gracefully, it is meant that the contents of data at each end of the logical link are kept in a relatively uncorrupted and consistent state. As such, the unmount command targets a file system of a server.

Similarly, responses and acknowledgments, if any, are passed the opposite direction along a path from server A:/x to directory client:/a. One such acknowledgment is the unmount acknowledgement. An unmount acknowledgment is an acknowledgment that a server transmits to a client to indicate that an unmount command has completed successfully. Unmount acknowledgments can be blocked by a number of issues. For example, the server may suffer a failure between the receipt of the unmount command and the dispatch of an unmount acknowledgement. As another example, the server may be disconnected from the client, and the unmount command, though sent, may be unable to traverse a network to reach the client. Accordingly, the unmount command may fail to reach the client during an allowable time for the file system to acknowledge unmounting. An allowable time for a file system to acknowledge unmounting is a time established by default or by a system administrator as a system tunable. For example, a system administrator may choose to set the allowable time for a file system to acknowledge unmounting to 20 seconds.

FIG. 3is a flowchart of steps to unmount file systems in accordance with an illustrative embodiment of the invention. Initially, a system administrator of a client establishes file system groups associated with a server (step301). Consequently, the client receives a database or data entries that show a correlation of one or more file systems to a server or host. As a result, the client forms a file system group that lists or otherwise stores the file systems mounted from the server for the client.

Next, the client may receive a shutdown command (step302). A shutdown command is a shutdown command used to cause a data processing system to shutdown or reboot. A data processing system can be, for example, data processing system100ofFIG. 1, and may host Unix-like operating systems such as, AIX®, Linux®, and Unix®. AIX is a registered trademark of International Business Machines, Corp. Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group.

Next, the shutdown command may issue an unmount command to a file system of the server (step303). Such a file system may be selected from a file system group of file systems supported by the server for the client. The server may be among a plurality of servers, as depicted, for example, inFIG. 2. Next, the client may determine whether a timeout period has expired without receiving an unmount acknowledgment associated with the unmount command given in step303. Thus, the client determines whether the timeout period expired for the file system (step305). A timeout period is a time measured contemporaneously from a triggering event to an expected reply time. The timeout period can be based on an allowable time, wherein the interval from expected reply time to triggering event is the allowable time.

Though not depicted inFIG. 3, an illustrative embodiment may be implemented such that the client repeats steps303and305a configurable number of times so that the client may repeat a reasonable number of normal unmount attempts before moving forward. Accordingly, an administrator of the client may adjust for a quicker marking of the server by setting the configurable number low, or adjust for a lengthier series of attempts by setting the configurable number higher. By ‘normal’ unmount, it is meant that the client attempts to flush all the buffered data to the server system and wait for an acknowledgement for the flushed data. In contrast, a forced unmount is where the client does not attempt to flush buffered data.

A positive determination to step305causes the client to transmit a ping to the server (step307). The ping may be an Internet Control Message Protocol (ICMP) ping as defined by Request For Comments (RFC) 792, RFC 1122, and related standards. Accordingly, the client may wait for a ping acknowledgment. The client may determine whether the ping acknowledgement fails to arrive before the ping timeout (step309). A ping acknowledgement is a packet that is returned by a server to the client. Such a ping acknowledgment may be an echo reply message.

A positive determination to step309results in the client marking the server for later retry of unmounting. Such a positive determination occurs when the ping timeout expires. Thus, the client marks the server (step311). Step311may include forming a marked set based on the server. A marked set is a data structure that includes references to each server known to have failed to respond in time to both an unmount command as well as a ping. Thus, the marked set may be later retried during a subsequent unmount command without imposing unnecessary delays to additional servers that support file systems for the client. The process continues with a query of further servers to unmount (step315).

However, if either step305or step309have negative results, the client may determine if, for the server targeted in step303, an unmount has been attempted on the all file systems on the server (step313). A negative determination to step313causes the client to select a next file system of the server for further action (step314). Consequently, further iterations of steps303-309may be possible while targeting one or more remaining file systems of the file system group.

As a result of a positive determination to step313, or following step311, the client may determine if further servers remain to unmount (step315). By further servers, it is meant that further servers exist if there are servers that provide at least one file system to the client, but such servers have not been the target of an attempt to unmount during the process following step302. A positive determination causes the client to select the next server (step317). For example, inFIG. 2, after concluding an initial attempt to unmount a file system of server A220, client210, may continue with attempts to unmount a file system of server B230. Further processing may resume at step303.

At some point, there are no further servers remaining that have not been targeted by at least one unmount command at step303. Thus, a negative determination to step315may trigger a second phase of steps. Consequently, the client may renew attempts to unmount file systems by beginning at the first marked server (step321). The first marked server may be a server within the marked set.

Next, the client may issue an unmount command to a file system of the server (step323). The unmount command may be a retry unmount command in the sense that the retry unmount command is a second unmount command issued to a particular file system of the server that supports the client. The client may subsequently determine if a timeout has expired for the file system to acknowledge the unmount command (step325). If the file system fails to acknowledge the unmount command in a predetermined time, the outcome to step325is positive. The predetermined time may be based on the allowable time used in step305. In response to a failure to acknowledge the unmount command within a predetermined time, the client transmits a ping to the server (step327). Next, the client may determine if the ping timeout expires (step329). A ping timeout expiration causes the client to force an unmount of all mounted file systems of the server (step331). A forced unmount may be performed using a command line of “unmount—f<device>”, where ‘<device>’ may be substituted with a description of the targeted device or directory within a particular server or client. During a forced unmount, the client discards all the buffered data and without waiting for an acknowledgement from the server. All mounted file systems of the server are those file systems that have not yet been unmounted. After step331, the client continues at step341, explained below.

Following negative outcomes to steps325and329, the client determines if the file system targeted in step323was the last file system on the server (step333). If not, the client obtains the next file system (step335). Next, the client may continue with step323using the file system selected in step335.

However, if the outcome to step333is positive, the client may determine if there are further marked servers (step341). If there are further marked servers, the client obtains the next server (step343). Accordingly, the client repeats step323, and one or more subsequent steps based on the server selected in step323.

At some time, the outcome to step341is negative, that is, there are no further marked servers that have not received a second unmount request at least once at step323. Accordingly, the client performs a complete shutdown (step345). A complete shutdown may be among the steps a client performs when rebooting. The process terminates thereafter.

The illustrative embodiments permit shutdown or reboot of a client that relies on networked availability of file systems. A server that is slow to respond or is non-responsive does not bottleneck the shutdown process more than is reasonable. Rather, a server that is slow to respond, is retried after any additional supporting servers are targeted with an unmount command. Thus, such responsive servers may have an earlier opportunity to unmount and speed the graceful shutdown of the client.