Browse Prior Art Database

Method for Recovering Orphaned Locks in a Network File System (NFS) Server Environment

IP.com Disclosure Number: IPCOM000238831D
Publication Date: 2014-Sep-19
Document File: 2 page(s) / 37K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method is disclosed for recovering orphaned locks in a Network File System (NFS) clustered server environment during a client crash. The method includes enabling a Network Status Monitor (NSM) to intercept a SM_NOTIFY request from a client and propagate the SM_NOTIFY request to all servers in a cluster.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Method for Recovering Orphaned Locks in a Network File System (NFS) Server Environment

In a Network File System Version 3 (NFSv3) environment, byte range locks are managed using a Network Status Monitor (NSM) and a Network Lock Manager (NLM). An NLM client sends a SM_MON message to the NSM for requesting a first lock from a server. The server is then added to a monitored list on a persistent storage of the client. The NLM client then sends a NLM_LOCK request to an NLM server. The NLM server sends a SM_MON message to the NSM when it receives the NLM_LOCK request from the client and the NLM server grants one or more locks requested by the client. When the client crashes, the NSM sends a SM_NOTIFY request to the servers that are recorded in a monitored list of the client. Upon receiving the SM_NOFITY message, an NSM server invokes a callback routine to the NLM server to release one or more locks that are granted to the client and allows the client to reclaim the one or more locks.

When there are multiple servers in a cluster, a client uses a Domain Name System-Round Robin (DNS-RR) name for accessing the servers that represents a host name for multiple Internet Protocol (IP) addresses allocated for each server. It is a normal operation where host names configured for one server are reassigned to the IP address of other servers in cases of events such as fail over, reboot and a disaster event. This may lead to a problem when a client sends the NLM_LOCK request to a server with an initial IP address returned from DNS-RR. Additionally, the client may send the SM_NOTIFY request after a crash recovery to a different server that has a different IP address upon crash recovery of the client. The server that receives the SM_NOTIFY request does not unlock locked file objects as it does not have any record of NLM states of the client. This results in formation of orphaned locks.

Disc...