Optimistic I/O Lease Mechanism for Clustered File Systems

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Clustered file systems incur higher costs and latencies due to the need for concurrency control mechanisms, such as locking, to prevent data corruption, which can be a bottleneck for operations like opening and reading small files, especially during power state changes.

Innovation Solution

Implementing an optimistic IO lease mechanism that allows hosts to access files without acquiring a lock, using a timeout value to assess if another host has acquired the lock, and invalidating received data if the lock is acquired, thereby reducing locking overhead for read-only IO operations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional locking mechanisms are used to prevent data corruption in clustered file systems, then data consistency is maintained, but IO latency increases and performance deteriorates

Engineering Contradiction:
Improvedata consistencyVSAvoidIO latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary actions by validating file access permissions and checking lock status before actual IO operations occur. The host system checks whether a lock is currently held on the file before attempting read operations, and validates that no other host has acquired the lock during the read operation. This preliminary validation prevents data corruption while avoiding the need for continuous locking overhead during normal read operations.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements an optimistic read mechanism where the host system reads file data without acquiring a traditional lock, effectively creating a copy of the data for local processing. The system validates that the data remains consistent by checking lock status before and during the read operation. This copying approach allows multiple hosts to read the same file simultaneously without mutual exclusion, dramatically reducing IO latency while maintaining data consistency through validation checks.

Inventive Principle:
Principle #26Copying

2Reliability

If locks are acquired for each file open and IO operation, then concurrency control is ensured, but system throughput decreases due to locking overhead

Engineering Contradiction:
Improveconcurrency controlVSAvoidsystem throughput
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system applies partial locking by acquiring locks only when absolutely necessary - specifically, when there is a possibility of concurrent modification. For read-only operations on files that are not being modified by other hosts, the system performs validation checks without acquiring traditional exclusive locks. This partial action approach maintains concurrency control for critical operations while allowing high-throughput read operations to proceed without locking overhead.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The patent changes the parameter of lock acquisition from binary (lock or no lock) to a conditional state based on validation results. The system dynamically determines whether lock acquisition is necessary by checking lock status and validating access permissions. This parameter change allows the system to adaptively apply locking only when needed, improving overall system throughput while maintaining reliability for operations that require concurrency control.

Inventive Principle:
Principle #35Parameter changes

3Reliability

If exclusive access is granted to prevent data corruption, then data integrity is maintained, but access efficiency deteriorates due to reservation costs

Engineering Contradiction:
Improvedata integrityVSAvoidaccess efficiency
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The system introduces an intermediary validation mechanism that acts as a mediator between multiple hosts accessing the same file. Instead of using traditional exclusive locks that block other hosts, the intermediary validation checks whether the file is being modified by another host and validates the read operation accordingly. This intermediary approach maintains data integrity by detecting and preventing concurrent modifications while allowing multiple hosts to access the file simultaneously, dramatically improving access efficiency.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces the mechanical locking system with a software-based validation mechanism. Instead of using hardware-level or filesystem-level locks that physically block access, the system uses software validation to check lock status and validate read operations. This substitution eliminates the need for SCSI reservations and traditional lock acquisition overhead, improving access efficiency while maintaining data integrity through software-based validation checks.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS8868610B2File system with optimistic I/O operations on shared storage
Publication Date: 2014.10.21 VMWARE INC
  • US8868610B2 patent drawing
  • US8868610B2 patent drawing
  • US8868610B2 patent drawing

AI summary

A method for performing I/O operations on a file stored in a file system utilizing a shared data storage system and accessible by a plurality of host computers is disclosed. A host computer receives from a process executing on it, a request to read data stored in the file. The host computer then requests the data stored in the file without acquiring a lock from the file system. The host computer also maintains a timeout value associated with the file while reading the data. The host computer receives at least a portion of the data prior to an expiration of time, and if all the data has not been received before the expiration of time, it then assesses whether another of the host computers has acquired a lock on the file, and, if so, invalidates the received data without providing it to the requesting process.