With flash dropping in price and phase-change memory on the horizon, FreeBSD’s storage subsystems need to change so they perform well with these low-latency devices. How should CAM, GEOM, I/O scheduling, unmapped I/O, and storage APIs change to meet this challenge? During the FreeBSD Storage Summit, small working groups will focus on discussing these and other pressing concerns, propose solutions, and document ideas/decisions/roadmaps on the FreeBSD wiki.
In addition, a panel of networking specialists will provide their ideas and experience on topics that are equally relevant to storage and networking. Do we need to change the application model for low-latency and multi-Q I/O? Are there any examples of old coding idioms that worked well in the past, but just don’t scale now? How do we deal with object lifetime issues in a scalable way (e.g. a virtual interface or ZFS volume disappears)? How has multi-Q impacted the design of the networking stack and should the I/O stack follow suit? This will hopefully encourage collaboration and a unified approach where it makes sense.
