[KUDU-423] Implement scalable and performant on-disk storage

• Type: New Feature
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: M4
• Component/s: fs
• Labels: roadmap-candidate scalability
• Assignee: Unassigned
• Reporter: Todd Lipcon
• Created: 31/Jul/14 12:36
• Updated: 28/May/20 15:45

Description

Our current on-disk storage has a number of issues:

• only writes to one local disk (need to scale to at least 12)
• exhausts file descriptors quickly (see KUDU-56)
• causes a ton of seeks at startup (KUDU-374)
• has big latency stalls on write due to ext4 journal-related chunky writeback
• doesn't support features we'll eventually want to support such as tiered storage

Issue Links

• is related to: KUDU-620 Ensure that log block manager punched holes actually reclaim space
• relates to: KUDU-374 Tablet startup should not eagerly open every CFile
• relates to: KUDU-56 "Cannot allocate memory" error in long running test

Sub-Tasks

• Design API for block storage layer: Resolved
• Reimplement current Kudu on-disk storage approach as allocation strategy: Resolved
• Integrate new block storage API with Kudu: Resolved
• Prototype log container allocation strategy: Resolved
• Implement multi-disk support: Resolved
• Implement data block GC: Resolved
• Block storage operability improvements: Resolved
• Add checksumming to cfile and other on-disk formats: Resolved
• Implement block storage microbenchmark: Open
• Prototype additional allocation strategies: Open
• Implement block placement hints: Open
• On-disk layout changes for tablet splits and snapshots: Resolved
• Mitigate tablet damage when disks are lost: Resolved
• Log block container metadata files should be more forgiving to truncation: Open
• Support online GC of orphaned data blocks: Open