The Necessary Death of the Block Device Interface

International audienceSolid State Drives (SSDs) are replacing magnetic disks assecondary storage for database management, as they offer ordersof magnitude improvement in terms of bandwidth and latency. Interms of system design, the advent of SSDs raises considerablechallenges. First, the storage chips, which are the basic componentof a SSD, have widely different characteristics – e.g., copy-onwrite,erase-before-write and page-addressability for flash chipsvs. in-place update and byte-addressability for PCM chips.Second, SSDs are no longer a bottleneck in terms of I/O latencyforcing streamlined execution throughout the I/O stack. Finally,SSDs provide a high degree of parallelism that must be leveragedto reach nominal bandwidth. This evolution puts database systemresearchers at a crossroad. The first option is to hang on to thecurrent architecture where secondary storage is encapsulatedbehind a block device interface. This is the mainstream optionboth in industry and academia. This leaves the storage and OScommunities with the responsibility to deal with the complexityintroduced by SSDs in the hope that they will provide us with arobust, yet simple, performance model. In this paper, we showthat this option amounts to building on quicksand. We illustrateour point by debunking some popular myths about flash devicesand by pointing out mistakes in the papers we have publishedthroughout the years. The second option is to abandon the simpleabstraction of the block device interface and reconsider howdatabase storage managers, operating system drivers and SSDcontrollers interact. We give our vision of how modern databasesystems should interact with secondary storage. This approachrequires a deep re-design of the database system architecture,which is the only viable option for database system researchers toavoid becoming irrelevant