Vault 2017

Drive-Managed Shingled Magentic Recording (SMR) disks offer a higher capacity alternative to traditional disk drives. However, non-sequential workloads can show bi-modal behaviour. After a short period of high performance they enter a continuous period of low performance. We were able to make a small change (600 LOC) to ext4 that significantly improves the throughput in both modes, resulting in 2-13x improvements on metadata-heavy workloads, and 1.7-4.9x improvements on a file server benchmark. The changes also resulted in performance improvements on conventional disk drives.

Flash based storage supports the concept of discarding data in blocks without actually overwriting, a concept that helps with the internal wear level and data placement algorithms. Linux has supported this concept, which has different names in different storage protocols (trim, unmap, deallocate), for a long time. But the concept of "online" or live discards that notify the device instantly after the deletion of data in the file system has only seen limited traction in Linux, mostly due to the severe performance degradation caused by it.

This talks explains optimizations to the file system and block layer to allow better batching and asynchronous execution of discard requests, as well how the file system block allocator can better be aware of ongoing discards.

It will also explore how discarding of data overlaps with fast zeroing operations, and why it really shouldn't at the interface level.

The GFS2 cluster filesystem has proved itself as a robust and reliable filesystem for cluster use cases. Most of the recent development has been focussed on performance improvments, and improving the ease of use and deployment. This talk will cover recent developments in GFS2, but also discuss future plans too. When GFS was originally designed, it took a lot of inspiration from ext2/3 which resulted in bitmap based resource groups, and an equal height pointer tree for inode metadata. The question arises as to whether and how GFS2 might integrate support for extents. The talk will present the issues involved and the latest thoughts of the development team on this topic.

Disk drives fail at an average annual rate of ~2%. Any system with Availability and Durability requirements must mitigate for such failures through a redundancy technique such as RAID, Erasure Coding, Replication or Backup.

With the wealth of monitoring data available nowadays and the ability to process the data in near real-time, can we predict such failures? How well can we do it? And how would that impact how we design and operate large distributed systems?

We examine and motivate predictive failure detection in the context of Availability, Rebuild Times and Recovery Objectives of large systems. We then train and evaluate multiple models achieving favorable accuracy (97.5%) to common datacenter practices. We demonstrate how we can tune our learners to achieve different Precision and Recall objectives thus improving Availability, Protection or Operational Efficiency.

Computing sites need long-term retention of cool data often “data lakes” which focus on capacity but with non trivial bandwidth requirements. For many years, tape was the best economic solution but bandwidth and access needs have outstripped tape solutions. Disk can be more economically for this storage tier. The Cloud Community uses erasure based object stores to gain scalability and durability using commodity hardware. The Object Interface works for new applications but legacy applications utilize POSIX. Campaign Storage is a Near-POSIX File System using cloud storage for data and many POSIX file systems for metadata. Campaign Storage scales namespace metadata to trillions of files and billions of files in a single directory and files from 1 byte to Petabytes. This solution is now available commercially. This talk describes Campaign Storage motivation, design, and performance.

Many talks about containers start with Orchestration systems like Docker or Kubernetes. However, this one will look at the storage impacts on the actual in-kernel container API. With the addition of the superblock namespace (essentially a user namespace for the kernel to filesystem boundary) much of the stage is now set for fixing one of the biggest underlying container problems: that of translating unprivileged container writes into real filesystem uid/gids. This talk will examine how this system works, why it is necessary and what pieces still need to be added for orchestration systems to make use of it (yes, we'll also cover fully unprivileged Docker ... but only briefly).