Multi-Transaction Memory System Metadata Atomicity
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing multi-transaction memory systems face challenges in securing the atomicity of file system metadata, leading to increased processing burdens on hosts and potential violations of transaction atomicity due to inefficient logging and reflection of file system metadata changes.
Innovation Solution
A method and system for a multi-transaction memory system that stores changed Logical Block Address (LBA) information and inode data within memory blocks, performing transaction commits by updating valid block bitmaps and inode pages, ensuring that only changed metadata is logged and reflected, thereby maintaining atomicity and reducing host processing burdens.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If all file system metadata changes are logged and reflected in existing multi-transaction memory systems, then transaction atomicity can be maintained, but host processing burden increases significantly
Solution Approach 1:
The patent extracts the file system metadata management functions (block bitmap and inode table) from the host system and relocates them to the memory system. This allows the memory system to independently manage and log metadata changes, maintaining transaction atomicity without requiring the host to process and log all metadata operations, thereby reducing host processing burden while preserving reliability
Solution Approach 2:
The patent introduces a valid block bitmap as an intermediary mechanism between the host and the file system metadata. The valid block bitmap tracks the validity status of metadata blocks and enables the memory system to independently manage metadata transactions, reducing the processing burden on the host while ensuring transaction atomicity through automated validation and recovery mechanisms
2Device complexity
If only changed metadata is logged in the memory system, then host processing burden is reduced, but securing atomicity of file system metadata becomes challenging
Solution Approach 1:
The patent implements preliminary action by pre-allocating metadata blocks and creating a valid block bitmap that tracks the validity status of each metadata block before transactions occur. This preliminary structure enables the memory system to efficiently log only changed metadata while maintaining atomicity, as the pre-established tracking mechanism allows for selective logging without compromising transaction integrity
Solution Approach 2:
The patent employs feedback mechanisms through the valid block bitmap, which continuously tracks and reflects the validity status of metadata blocks. This feedback system enables the memory system to identify and log only the changed metadata blocks while ensuring atomicity, as the bitmap provides real-time information about which blocks require logging and recovery actions
3Reliability
If the memory system manages block bitmaps and inode tables, then atomicity is secured and host burden is reduced, but device complexity increases
Solution Approach 1:
The patent applies universality by designing the memory system to perform multiple functions: it not only stores user data but also manages file system metadata (block bitmap and inode table). This multi-functionality consolidates metadata management within the memory system, securing atomicity while the standardized interface and automated mechanisms prevent excessive complexity from arising
4Reliability
If transaction commits update the valid block bitmap based on LBA information, then metadata consistency is improved, but processing time increases
Solution Approach 1:
The patent segments the valid block bitmap into manageable units corresponding to metadata blocks, allowing transaction commits to update only the specific bitmap segments affected by LBA changes rather than updating the entire bitmap. This segmentation maintains metadata consistency while reducing the time required for transaction commits by limiting the scope of updates to only the necessary portions
Data Source
AI summary
A method for operating a multi-transaction memory system, the method includes: storing Logical Block Address (LBA) information changed in response to a request from a host and a transaction identification (ID) of the request into one page of a memory block; and performing a transaction commit in response to a transaction commit request including the transaction ID from the host, wherein the performing of the transaction commit includes: changing a valid block bitmap in a controller of the multi-transaction memory system based on the LBA information.