Inode Sharing Detection in Namespace Snapshots
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In large filesystems with many concurrent users, determining whether a file is shared or not during write operations is inefficient, impacting filesystem performance due to the need to check if an inode needs to be split to preserve the original file state.
Innovation Solution
The technology employs in-memory data structures to rapidly determine if a file is shared by using virtual inode numbers mapping to real inodes, with decision logic accessing these structures to split the inode if shared, thereby preserving the original file state during write operations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If traditional filesystem methods are used to determine whether a file is shared during write operations, then accuracy in preserving original file state is maintained, but filesystem performance deteriorates due to inefficient checking processes
Solution Approach 1:
The patent pre-computes and stores sharing status information in inode metadata before write operations occur. During snapshot creation, the system proactively identifies shared files and marks them in the inode structure, so that during write operations, the sharing status can be determined immediately without performing expensive checks at that moment.
Solution Approach 2:
The patent replaces traditional filesystem methods of determining file sharing status (which involve checking multiple data structures and performing complex lookups) with a simplified mechanism that reads a pre-computed flag directly from the inode metadata. This substitution dramatically reduces the computational overhead and time required to determine sharing status during write operations.
2Reliability
If inode splitting is performed to preserve original file state during write operations to shared files, then data integrity is maintained, but system overhead increases due to the complexity of splitting and allocating new inodes
Solution Approach 1:
The patent pre-identifies shared files by examining file paths during snapshot creation and marks them in the inode metadata before any write operations occur. This preliminary marking allows the filesystem to immediately recognize when inode splitting is needed without performing complex analysis during the write operation itself.
Solution Approach 2:
The patent extracts the sharing status determination logic from the write operation path and places it in the snapshot creation path. By separating these concerns, the complex logic of identifying shared files is executed once during snapshot creation, while write operations simply need to check a pre-computed flag and perform splitting only when necessary.
3Measurement precision
If sharing status is determined for each write operation in large filesystems with many concurrent users, then accurate file state preservation is achieved, but performance impact increases due to the frequency of write operations
Solution Approach 1:
The patent pre-computes sharing status information during snapshot creation and stores it in the inode metadata. This allows write operations to simply read the pre-computed flag rather than performing complex sharing status determination, maintaining accuracy while dramatically improving write operation throughput.
Solution Approach 2:
The patent creates a copy of the sharing status information in the inode metadata during snapshot creation. This copied information is then used during write operations to determine whether inode splitting is needed, eliminating the need to perform expensive sharing status checks during each write operation while maintaining determination accuracy.
Data Source
AI summary
The technology described herein efficiently determines whether a real inode is shared among views, or owned. In-memory data structures include a view snapshot generation counter that is increased as a snapshot that generates a view is created, and an inode total weight. An in-memory virtual inode cache dataset for a filesystem object associated with the view is instantiated with the value of snapshot generation counter, sharing-related data based on the inode mapping file entry for the object, and an inode access weight. To determine whether the inode is shared (and needs to be split), such as on a write to the object, the in-memory data is evaluated. The real inode is shared if the generation counters are unequal, if the sharing-related data indicates sharing at an intermediate indirect block level, or indicates sharing at the inode level and the inode access weight is less than the inode total weight.