Scratch List Update Coordination in Shared Filesystems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In virtual tape storage systems, maintaining accurate lists of scratch volumes across multiple nodes accessing shared filesystems leads to collisions, excessive filesystem input/output load, and repeated updates, which can degrade performance.
Innovation Solution
Implementing a method where each node uses a scratchhint file to determine if it should update its scratch list, and if so, waits dynamically based on the need to update, checking if another node is currently updating, and using a scratchprocess file to prevent simultaneous updates, thus reducing unnecessary filesystem access.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If each node continuously updates its scratch list from shared filesystems, then the scratch list accuracy is improved, but filesystem input/output load increases and performance degrades
Solution Approach 1:
The system implements periodic updates instead of continuous updates. Each node determines whether to update its scratch list based on a timestamp comparison between the filesystem's last modification time and the node's last update time. Updates occur only when the filesystem has actually changed, reducing unnecessary I/O operations while maintaining list accuracy.
Solution Approach 2:
Each node autonomously determines whether it needs to update its scratch list by comparing timestamps locally. The node checks if the filesystem timestamp is more recent than its cached timestamp, and only updates if needed. This self-service mechanism eliminates the need for centralized coordination and reduces filesystem access overhead.
2Reliability
If multiple nodes simultaneously update scratch lists from shared filesystems, then update freshness is improved, but collisions and repeated updates occur
Solution Approach 1:
The patent introduces intermediary files (scratchhint file and scratchprocess file) that mediate between multiple nodes and the filesystem. These files store timestamps and update status information, allowing nodes to coordinate updates without direct communication or locking mechanisms. The intermediary files enable nodes to determine if updates are necessary and if other nodes are currently updating, preventing collisions.
3Loss of time
If nodes frequently check for scratch volume changes, then list currency is improved, but filesystem access overhead increases
Solution Approach 1:
The system performs preliminary actions by maintaining a cached timestamp of the filesystem's last modification in each node's scratchhint file. Before attempting to update the scratch list, the node first checks this cached timestamp against the current filesystem timestamp. This preliminary check avoids unnecessary filesystem accesses and list updates when no changes have occurred.
Data Source
AI summary
In one embodiment, a method of updating a list of available scratchfiles at a node accessing a filesystem includes determining whether the node should update the list of available scratchfiles on the filesystem. If the node should update the list of available scratchfiles of the filesystem, the method updates the list of available scratchfiles on the filesystem. In one embodiment, the method may determine whether the list of available scratchfiles on the filesystem should be updated by determining whether another node is currently updating its scratch list for the filesystem. If it is not, then the method may further determine whether the filesystem has added a scratch volume since a previous update of the list of available scratchfiles at the node.