Link to paper
Main Claim
mmap is not a suitable replacement for a traditional buffer pool that manually handles read and write syscalls. This is despite the seemingly less complexity and more efficiency benefits that mmap offers.
Main problems
- Transparent Paging:
mmap might flush dirty page at any time, without regards to whether the page contains any changes from uncommitted transaction.
- (3.1) To ensure transactional safety, DB needs to implement either Copy-on-Write (maintaining an extra copy of the database file as private workspace) with WAL, or Shadow Paging.
- (3.3) To ensure data integrity, DB needs to validate checksum on every page access. Even worse, there is no mechanism to ensure that pages is not corrupted before writing to secondary storage.
- (3.2) Since page cache might be full at anytime, read-only queries can trigger unintended page fault, causing IO spikes.
- (3.2)
mmap doesn't support asynchronous reads.
- (3.4)
mmap-based file I/O suffers from page table contention, single-threaded page eviction and TLB shootdowns.
Link to paper
Main Claim
mmapis not a suitable replacement for a traditional buffer pool that manually handlesreadandwritesyscalls. This is despite the seemingly less complexity and more efficiency benefits thatmmapoffers.Main problems
mmapmight flush dirty page at any time, without regards to whether the page contains any changes from uncommitted transaction.mmapdoesn't support asynchronous reads.mmap-based file I/O suffers from page table contention, single-threaded page eviction and TLB shootdowns.