The 2014 Linux Filesystem, Storage, and Memory Management Summit

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

The 2014 Linux Storage, Filesystem, and Memory Management Summit was held March 24 and 25 in Napa, California. Nearly 90 developers met to discuss many issues of interest to the core kernel community; it is one of the most focused and technical events on the calendar. Naturally, LWN was there; articles documenting the discussions held there will be added to this page as they become available.

Plenary sessions

Many of the topics to be discussed were deemed to be relevant to all three groups of developers at the event. Those topics include:

• Page cache issues: in particular, how do we support storage devices with block sizes that are greater than the page cache size?

• Persistent memory and how to support it well under Linux.

• PostgreSQL pain points: developers from the PostgreSQL project came to discuss the places where the Linux kernel causes problems for them and what form solutions might take.

• Facebook and the kernel: how Facebook uses Linux and the problems it faces with the kernel.

• Support for shingled drives; the standards for these drives are evolving, and the kernel will need to evolve with them.

• Toward better testing for filesystems and beyond.

• A revoke() update and more: progress on revoke() along with some work on unifying the different read() and write() variants in the kernel.

• Problems with vmsplice() and how they might be addressed.

The memory management track

There were a number of topics discussed in a smaller setting involving just those developers who are interested in memory management issues:

• Trinity and memory management testing: the carnage that results when fuzz testing hits the memory management subsystem.

• Compressed swap, and improving zswap in particular.

• Memory management locking: improving performance around some highly contended locks.

• Hardware pain points: how could processor vendors make life easier for memory management hackers?

• Volatile ranges: more discussion on this often-revised patch set.

• User-space out-of-memory handling: letting user space decide what to do when there is no memory left.

• NUMA placement problems: how are we doing at improving NUMA performance?

• Memory compaction and how to figure out why it occasionally goes wrong.

• Huge page issues: transparent huge pages improve performance in a number of situations, but hurt in others. How can things be made to perform reliably better?

• Memory accounting and limits: fixing memcg soft limits and the accounting of pinned pages.

The storage and filesystem track

For the most part, the storage and filesystem developers had joint sessions, though there is one exception. Here is what was discussed:

• Ideas for supporting shingled magnetic recording (SMR), a user-space API plus some ideas on splitting filesystems into two parts.

• Data integrity user-space interfaces: support for DIF/DIX draws ever nearer.

• Copy offload: a status report on offloading copy operations to storage arrays and file servers.

• Error handling in the SCSI and block layers.

• Thin provisioning is mostly working, but performance issues need to be addressed.

• Block multi-queue status: progress is being made, but there is still more to do.

• Large-sector drives; what to do about drives with sector sizes >4K?

• Direct I/O status: a rewrite is in progress.

Filesystem-only track

There were also two storage-only track sessions, but those got wrapped up into articles above. Here is what the filesystem developers discussed:

• FedFS, NFS, Samba, and user-space file servers: lots of kernel support needed to support federation and user-space file servers.

Group photo

The traditional group photo was a somewhat disorganized affair. Your editor apologizes to everybody who is not visible in this picture.

---

(Log in to post comments)