Inode Summary Change Log for Efficient File Backup
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Modern file systems with 64-bit or 128-bit inode numbers lack locality, making existing bitmap-based change log systems inefficient due to large disk space usage and time-consuming backups, as the bitmap file needs to be read in entirety to track modified inodes.
Innovation Solution
A summary change log structure using a translation file to store and manage inode change records efficiently, with separate files for modifications and file names, allowing sequential reading of change records for backup, and using fixed-length records to minimize storage and processing time.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If a bitmap file is used to track modified inodes with 64-bit or 128-bit inode numbers, then all inodes can be tracked, but the bitmap file size becomes extremely large (2^61 bytes for 64-bit) and reading it in entirety becomes very time consuming
Solution Approach 1:
The patent divides the single large bitmap file into multiple smaller bitmap files, each tracking a specific range of inode numbers. This segmentation allows the system to track all inodes (64-bit or 128-bit) while only reading the relevant smaller bitmap portions during backup operations, dramatically reducing I/O time and improving backup efficiency.
2Quantity of substance
If a bitmap file is used to track modified inodes, then all inodes can be tracked, but disk space usage becomes extremely large
Solution Approach 1:
The patent segments the enormous bitmap into multiple smaller bitmap files, each managing a subset of inode ranges. This reduces the size of individual files that must be stored and managed, while collectively providing coverage for all 64-bit or 128-bit inodes. The segmented structure also enables more efficient storage allocation and management.
3Reliability
If the inode summary change log and inode bitmap log are allocated one logical storage block for each modified inode, then each modification is tracked, but disk space usage becomes quite large and inefficient
Solution Approach 1:
The patent merges multiple inode ranges into single bitmap files when those ranges are contiguous or close together. This consolidation reduces the total number of bitmap files and improves storage efficiency by eliminating redundant file structures and metadata overhead, while maintaining accurate tracking of all modified inodes.
Solution Approach 2:
The bitmap system is designed to handle multiple inode number formats (32-bit, 64-bit, 128-bit) and various file system types through a unified architecture. The same bitmap infrastructure adapts to different inode sizes and ranges, providing universal change tracking capability without requiring separate systems for each inode format.
Data Source
AI summary
A summary change log indexed by inode number is disclosed. An indication is received that a file system object associated with a corresponding file system index node (inode) has been modified. A summary change record is stored for the corresponding inode, including by: locating or creating an entry for the inode in an inode translation file; storing data associated with the modification in a summary change record located within a summary change file at an offset indicated in the entry; and using the summary change record to perform a backup.