Vault 2016

This presentation gives an introduction to Open-Channels SSDs and LightNVM - the kernel subsystem for Open-Channel SSDs. Open-Channel SSDs allow applications to directly control data placement and garbage collection within an SSD. The benefits are consistent latency and throughput in high-performance workloads and extending SSD lifetime. The primary objective of this talk is to show the possibilities of this new storage interface, its architecture, the current status and roadmap for LightNVM for both upcoming kernel functionality and user-space support.

Fabric-Attached Memory (Rocky Craig, Hewlett Packard Enterprise) - The Machine from HPE is the prototoype of a novel architecture featuring memory-centric computing. Multiple Linux nodes see fabric-attached NVM in their physical address space as a shared global resource. This presentation introduces the hardware architecture as it relates to the NVM and the challenges in shared management. While NVM presents a key-value paradigm in data retrieval, we chose the route of a global file system. The bulk of the talk will focus on this "Librarian File System" and the benefits of a well-known API versus a proprietary solution.

Samba is the most important open source SMB file server, and arguably, one of the most important SMB
implementations out there. While the Active Directory Server has been the hip topic recently, the file server is really cooking. One of the most active areas of development is SMB version 3, introduced by Microsoft to move focus from pure workstation workload to server workload. SMB3 adds an abundance of new features to the protocol. In particular, Microsoft caught up with Samba/CTDB to offer all-active clustering.

After an overview of the state of Samba's file server, this talk will present the progress of SMB3 in Samba. It will focus on Multi-Channel, the core of which has just been added to Samba 4.4, including a demo. Afterwards an outlook will be given on other active areas like RDMA, persistent file handles, and scale-out SMB clustering, reporting on status and challenges.

SUSE will talk about multi-petabyte storage deployments.  The easiest adoption is with new projects that are typically in the low 100s of TBs.  This session will talk about the process of identifying the use cases and architectures that represent a solution the customer will actually buy while minimizing their risk.

With recent kernels block and SCSI multiqueue support has been integrated, showing a big performance boost on high-performance devices. At the same time, there are some features which a missing from multiqueue. Most notably multiqueue does not have any I/O scheduler, and it doesn't support I/O merging.

With high-speed storage these features should matter less, as the hardware is supposed to be fast enough to offset any impact here. However, numbers supporting this are hard to come by.

To validate this we have been running performance tests with Emulex 16G FC cards and NetApp EF-650 storage.

In this presentation we will show the performance results when running a 4.4 kernel. We will be giving a comparison with the original (3.12-based) SCSI implementation as well as the current implementation, with both multiqueue enabled and disabled.

2016 will be the year of Persistent Memory, and these high speed/capacity, non-volatile memory devices are just around the corner, we’re told. Similar to both current storage and memory devices, NVDIMMs will also be susceptible to developing ‘bad’ locations. Unlike DRAM, these errors will persist across reboots, and have to be handled like we do traditional storage.

With DRAM, if a poison location is read, the CPU takes a machine check exception, and typically reboots, and the poison is cleared. With NVDIMMs, the poison won’t be cleared, and it is likely that the application accessing that location will do so again, causing a reboot loop.

This talk details how we solve this problem and its different manifestations in the Linux kernel, and how we enable userspace applications to become aware of poison blocks and deal with them if they so choose.

A storage cache must implement an index to quickly locate the objects it holds. The index’s design is impacted by the storage medium. For example, a memory cache’s requirements differ from a cache built using storage tiers. In the former, an in-memory hash table or balanced tree may suffice. But in the later, those structures may stumble. The metadata required to track such a large number of objects won’t fit in memory. In such cases, the challenge is to find an index that scales. A further consideration is wether to track elements in LRU order, in which case a sorting mechanism is called for. This talk contrasts 3 cache tiering implementations in Linux that have tackled this problem from GlusterFS, Ceph, and DMcache. Solutions vary from bloom filters to sqlite databases. We will explore their relative pros and cons along the dimensions of performance, overhead, complexity, and more.

Linux block cgroup currently has two controllers. blk-throttle is bandwidth/IOPS based. CFQ cgroup is proportion based. Having two separate IO controllers is painful. And CFQ is known not performing optimal for high end storage. Also block multiqueue doesn't support CFQ, leaving block-mq only supports blk-throttle. It's time to have a unified IO controller supporting both bandwidth/IOPS and proportion based control and performing well with high end storage. In this presentation, Shaohua Li will discuss current status of IO controller, challenges of a unified IO controller, proposed solution and development status.

Bringing down storage cost is the key to any data storage solution. With big Data, IoT growth and social medias, pressure is put on data volume as information being stored grows exponentially. To help this evolving market, Intel is introducing the Quickassist technology.
The Intel® Quickassist Technology provides security and compression acceleration capabilities to improve performance and efficiency on Intel Architecture platforms. Server, networking, big data, and storage applications use Intel QuickAssist Technology to offload servers from handling compute-intensive operations, such as:
 Symmetric cryptography functions including cipher operations and authentication operations
 Public key functions including RSA, Diffie-Hellman, and elliptic curve cryptography
 Compression and decompression functions including DEFLATE
Ultimately, Intel® Quickassist Technology enables users to meet the demands of ever-increasing amounts of data, especially data with the need for encryption and compression. This helps users to ensure applications are fast, secure and available.
Lately Intel released a new feature for the compression service called Batch and Pack. This new feature enables the application that uses the Quickassist API to improve the system performance by reducing not only the compute cycles needed, but also reducing IoPs, DRAM bandwidth and cache utilization. Furthermore it enables fast and efficient reads performance by providing metadata to the application.

With the influx of cutting edge technologies around Linux Containers, contemporary Software Defined Storage (SDS) platforms face significant opportunities as well as challenges. Containers can overcome some of the differences between Linux distributions which can make SDS platforms easier to deploy. For example, a Ceph installation has to be aware of the differences between Linux distributions and carefully pick various dependent software packages. With the introduction of the ceph-docker project, Ceph daemons are put into Linux Containers and started on the Linux host using docker run, therebysimplifying the deployment and administration overhead. An in-depth look of containerizing SDS storage servers is provided in the talk, using lessons learned with Ceph and GlusterFS as a reference.

Likewise, containers can also make SDS platforms easy to consume for the clients. Putting client software into Linux Containers can eliminate package dependency issues which is especially useful when containerized applications are scheduled on random hosts using container orchestrators. However, there are several non-trivial technical issues associated with filesystem client containerization such as setting proper mount propagation modes so that mount points created by containers are visible by the host and other containers and lifecycle management of long running daemon process (as often seen in FUSE based filesystems). This talk examines these challenges in detail.

Lastly, this talk will explore what SDS platforms can offer to provide a better fit for Linux Containers. For example, Docker relies on SELinux labels to permit containers access filesystems. While SELinux is supported by filesystems such as GlusterFS and NFSv4.2, there are still many filesystems that don't support SELinux yet. This point will be illustrated in the presentation using Kubernetes.