Storage Controller Location Database Acceleration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Storage networks experience latency due to context switching and message passing overhead in filesystem software, which delays data access operations such as read requests.
Innovation Solution
A clustered network environment with node computing devices and a location database that allows direct access to data storage devices, reducing latency by intercepting requests and using a multi-processor safe location database to service them without involving the filesystem module, thereby minimizing overhead.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If filesystem software is used to manage data access operations, then data access can be organized and controlled, but latency increases due to context switching and message passing overhead
Solution Approach 1:
The system segments data access operations into two paths: common read operations are handled directly by the storage controller without filesystem software involvement, while write and layout management operations continue to use the filesystem software. This segmentation allows fast path access for simple operations while maintaining software control for complex operations.
Solution Approach 2:
A location database is introduced as an intermediary component that stores the mapping between logical block addresses and physical storage locations. The storage controller uses this location database to directly service read requests without involving the filesystem software, thereby eliminating context switching and message passing overhead for these operations.
2Loss of time
If direct access to storage devices is implemented, then latency is reduced, but the complexity of managing data layout and consistency increases
Solution Approach 1:
The filesystem software performs preliminary actions by establishing and maintaining the location database that maps logical block addresses to physical storage locations. This preliminary setup allows the storage controller to perform direct access operations without needing to understand or manage the complex filesystem layout, as all location information is pre-computed and stored in the location database.
Solution Approach 2:
The location database serves as an intermediary that absorbs the complexity of filesystem layout management. It provides a simple interface for the storage controller to query physical locations based on logical block addresses, while the filesystem software handles the complex tasks of maintaining this mapping in the background.
3Reliability
If filesystem software services all data access requests, then data consistency and layout management are maintained, but overhead from context switching and message passing significantly delays access
Solution Approach 1:
The system segments data access requests into two categories: read requests that can be serviced directly by the storage controller using the location database, and write/layout management requests that require filesystem software involvement. This segmentation maintains data consistency for critical operations while accelerating common read operations.
Solution Approach 2:
The storage controller is empowered to self-service common read operations by directly querying the location database and accessing storage devices without filesystem software intervention. This self-service capability eliminates the overhead of context switching and message passing for these operations while the filesystem software continues to manage data consistency for write operations.
Data Source
AI summary
Methods, non-transitory computer readable media, and computing devices that accelerate data access requests. With this technology, a hierarchy of a plurality of objects is inserted into a location database. Each of at least a subset of the plurality of objects comprises a physical storage location for data stored in a filesystem. One or more of the plurality of objects includes an object version number and a parent version number of a parent one of the plurality of objects. A determination is made when an invalidation event has occurred in the filesystem. The invalidation event is associated with one of the plurality of objects. The object version number for the one of the plurality of objects is modified to invalidate one or more of the subset of the objects, when the determining indicates that the invalidation event has occurred in the filesystem.