|
|
Subscribe / Log in / New account

The 2015 Linux Storage, Filesystem, and Memory Management Summit

By Jonathan Corbet
March 11, 2015
The Linux Storage, Filesystem, and Memory Management Summit is arguably the most severely technical event on many kernel developers' schedules. The 2015 event, held March 9 and 10 in Boston, was no exception. Discussions over these two days went deeply into a wide range of topics of interest to the core kernel development community.

As usual, LWN was present at the event. Writeups of the individual sessions are in progress; they will appear here once they are ready.

Plenary sessions

Some topics were deemed to be of interest to the entire assembled group of developers. The plenary sessions held at the summit were:

  • Persistent memory: where we stand with regard to support for large persistent-memory devices and where the remaining challenges are.

  • Allowing small allocations to fail. The news that the memory-management subsystem generally does not allow small allocation requests to fail under any circumstances came as a surprise to many developers. There seems to be a consensus that this behavior should change, but effecting that change will be a multi-year prospect.

  • Reservations for must-succeed allocations: the continuation of the discussion on improving the handling of low-memory situations.

  • Virtual filesystem changes: Al Viro talks about what is happening in the VFS layer and what developers can look forward to in the near future.

  • Investigating a performance bottleneck: a brief, low-energy session trying to debug an obscure problem at the end of the first day.

Memory-management track sessions

Filesystem/storage track sessions

A number of sessions were shared between the filesystem and storage tracks, especially on the first day of the Summit.

  • Filesystem/block interfaces: how can communications between these two layers be widened and made more flexible?

  • Overlayfs issues and experiences: the overlayfs union filesystem has been in the mainline since 3.18; that has been enough time for a number of issues to arise and, in some cases, be solved.

  • Asynchronous buffered read operations: the preadv2() system call and related topics.

  • Handling 32KB-block drives: disk drive manufacturers are pushing toward larger native block sizes; what will it take for the kernel to be able to work with such drives?

  • Filesystem support for SMR drives; shingled magnetic recording devices have a number of constraints that make them hard to drive from Linux. Is it possible to run Linux filesystems over SMR drives, and, if so, is it worth the effort?

  • Power-failure testing: making filesystems more robust even when power goes out at the worst possible time.

  • Copy offload: getting a filesystem or storage system to do the work of copying files so user space doesn't have to.

Filesystem track sessions

The sessions involving just the filesystem developers were:

  • NFS performance: what to do about a number of network filesystem performance bottlenecks.

  • Filesystem defragmentation. All filesystems tend to fragment over time; what can be done to clean them up again?

  • Identity and filesystems: a brief session on how to better manage user and group ID mapping for filesystems.

  • Issues with epoll(): addressing some of the scalability issues that have come up with the epoll() system calls.

[Group photo]



to post comments


Copyright © 2015, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds