Storage Liability Management for Version Families
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current data storage systems struggle to accurately calculate liability for file systems with multiple production objects and their snaps, especially when writable data objects are allowed to grow and differentiate, leading to increased storage requirements that may exceed available space.
Innovation Solution
An improved technique that differentiates between writable and read-only data objects, generating a worst-case liability estimate to support growth and differentiation of writable objects while limiting liability for read-only objects, allowing administrators to plan and allocate sufficient storage capacity.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If writable data objects are allowed to grow and differentiate, then storage flexibility and functionality are improved, but storage space requirements increase and may exceed available space
Solution Approach 1:
The patent segments the storage pool into version families, where each family contains a production object and its snaps. This segmentation allows independent liability calculation for each version family, enabling the system to track and manage storage requirements of writable objects separately from read-only snaps, thus supporting growth while maintaining overall storage control.
Solution Approach 2:
The patent changes the parameter of liability calculation from a unified per-file-system approach to a differentiated per-version-family approach. This parameter change enables the system to account for the growth and differentiation of writable objects while limiting liability for read-only snaps, resolving the contradiction between storage flexibility and space requirements.
2Device complexity
If liability is calculated per-file system, then simplicity of calculation is maintained, but accuracy of storage requirement estimation deteriorates for systems with multiple production objects
Solution Approach 1:
The patent divides the file system into multiple version families, each representing a production object and its snaps. By calculating liability at the version family level rather than the entire file system level, the patent achieves more accurate storage requirement estimation while maintaining relatively simple calculation procedures within each segmented unit.
Solution Approach 2:
The patent applies local quality by treating each version family as a distinct unit with its own liability characteristics. This allows the system to apply different liability calculation rules to different parts of the file system based on their specific needs, improving overall estimation accuracy without requiring a completely complex global calculation system.
3Reliability
If snaps are treated as preserved objects with space guarantees, then data integrity and reliability are improved, but storage space consumption increases when writable objects grow and differentiate
Solution Approach 1:
The patent generates worst-case liability values in advance that account for the maximum possible growth and differentiation of writable objects. This preliminary action ensures that sufficient storage space is reserved to support both the preserved snaps and the potential growth of writable objects, maintaining data integrity while preventing storage shortages.
Solution Approach 2:
The patent creates a cushion of reserved storage space by calculating worst-case liability scenarios before they actually occur. This beforehand cushioning ensures that when writable objects grow and differentiate, there is sufficient space available to support both the growing writable objects and the preserved read-only snaps without compromising either data integrity or storage efficiency.
Data Source
AI summary
A technique for managing storage space in a data storage system generates liability values on a per-family basis, with each family including files in the file system that are related to one another by snapping. Each family thus groups together files in the file system that generally share at least some blocks among one another based on snapshot activities. Distinct files that do not share blocks based on snapping are provided in separate families. The technique further generates worst-case storage liability of a version family by differentiating between writable data objects and read-only data objects, thus allowing administrators to provide spare storage and/or prepare for increases in storage requirements as writable data objects grow and differentiate.