<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span style="font-family: Optima-Regular;">[Apologies if you have received multiple copies of this email]</span></div></div></div></div><div><br></div><div>1st Programmable File Systems Workshop (PFSW’14)</div><div><br></div><div>in conjunction with</div><div>The 23rd International ACM Symposium on High Performance Parallel and Distributed Computing (HPDC 2014)</div><div>Vancouver, BC, Canada on June 23-27, 2014 (workshop is one day TBD)</div><div><br></div><div><a href="http://www.cs.ucsc.edu/~carlosm/PFSW/">http://www.cs.ucsc.edu/~carlosm/PFSW/</a></div><div><br></div><div>UPDATES: Submissions: March 21, 2014, Final versions: April 26, 2014</div><div><br></div><div>WORKSHOP ABSTRACT</div><div>A major milestone in the evolution of digital computers was the development of</div><div>the stored-program concept and the design of Turing-complete machines as</div><div>opposed to fixed-program computers. Yet, we still treat an increasingly</div><div>important subsystem of computers largely as a fixed-program computer: file and</div><div>storage systems. Among the key reasons for this history is the justified fear</div><div>that (1) any interface changes in file and storage systems will make legacy</div><div>data inaccessible and locks the data to a particular system and (2)</div><div>programmability will increase the probability of data loss.</div><div><br></div><div>Yet with the advent of open source file systems a new usage pattern emerges:</div><div>users isolate subsystems of these file systems and put them in contexts not</div><div>foreseen by original designers. Examples are: (1) an object-based storage back</div><div>end gets a new RESTful front end to become a Amazon Web Service's S3 compliant</div><div>key value store, (2) a data placement function is used as a placement function</div><div>for customer accounts, and (3) the HDF5 scientific data access library is</div><div>embedded into parallel storage systems. This trend shows a desire for the</div><div>ability to use existing file system services and compose them to implement new</div><div>services — a desire, however, that is frequently stumped by the difficulty of</div><div>bringing new services of advanced functionality up to production quality and</div><div>sufficiently low probability of data loss. At the same time government and</div><div>industry are heavily investing into the development of new, extremely</div><div>scalable, and highly efficient, distributed I/O stacks that largely abandon</div><div>traditional file and storage system interfaces.</div><div><br></div><div>Designing programmability into file and storage systems has the following</div><div>benefits: (1) we are achieving greater separation of storage performance</div><div>engineering from storage reliability engineering, making it possible to</div><div>optimize storage systems in a wide variety of ways without risking years of</div><div>investments into code hardening; (2) we are creating an environment that</div><div>encourages people to create a new stack of storage systems abstractions, both</div><div>domain-specific and across domains, including sophisticated optimizers that</div><div>rely on machine learning techniques; (3) we are informing commercial parallel</div><div>file system vendors on the design of low-level APIs for their products so that</div><div>they match the versatility of open source storage systems without having to</div><div>release their entire code into open source; and (4) we are using this</div><div>historical opportunity to leverage the tension between the versatility of open</div><div>source storage systems and the reliability of proprietary systems to lead the</div><div>community of storage system designers.</div><div><br></div><div>GOAL</div><div>This one-day workshop focusses on frameworks that allow the programmability of</div><div>file and storage systems while addressing the risks of data interface change.</div><div>The workshop aims to serve as a venue for leaders in the file system and</div><div>storage community to exchange ideas outside the tradition of half a century of</div><div>classic file and storage systems research which focussed on a small set of</div><div>unchanging interfaces. </div><div><br></div><div>PAPER SUBMISSIONS</div><div>Authors are invited to submit papers with unpublished, original work of not</div><div>more than 8 pages of double column text using single-spaced 10 point size on</div><div>8.5 x 11 inch pages (including all text, figures, references, and appendices),</div><div>as per ACM 8.5 x 11 manuscript guidelines (document templates can be found at</div><div><a href="http://www.acm.org/sigs/publications/proceedings-templates">http://www.acm.org/sigs/publications/proceedings-templates</a>). Electronic</div><div>submissions in pdf format are received at</div><div><a href="https://www.easychair.org/conferences/?conf=pfsw2014">https://www.easychair.org/conferences/?conf=pfsw2014</a> at the submission</div><div>deadline. </div><div><br></div><div>TOPICS</div><div>Addressing programmability of the non-volatile part of the memory hierarchy,</div><div>the workshop seeks contributions on relevant topics, included but not limited</div><div>to:</div><div><br></div><div>- Programming models </div><div>- Data interface change management and isolation </div><div>- Interface metadata management and propagation </div><div>- Compile-time and runtime storage optimization </div><div>- Data and task placement in large-scale storage stack </div><div>- Local and distributed performance management and isolation</div><div>- Nonstop storage system evolution</div><div><br></div><div>IMPORTANT DATES</div><div>Submission of papers: March 21, 2014, 11:59 PM PST</div><div>Author notification: April 15, 2014</div><div>Final versions: April 26, 2014 (UPDATED, to ensure ACM Digital Library publication)</div><div>Workshop: One day during June 23-27, 2014</div><div><br></div><div>WORKSHOP ORGANIZERS</div><div>Carlos Maltzahn - University of California, Santa Cruz</div><div>Patrick McCormick - Los Alamos National Laboratory</div><div><br></div><div>PROGRAM COMMITTEE</div><div>John Bent, EMC</div><div>Andre Brinkmann, Johannes Gutenberg-Universität Mainz</div><div>Randal Burns, Johns Hopkins University</div><div>Phil Carns, Argonne National Laboratory</div><div>Yong Chen, Texas Tech University</div><div>Toni Cortes, Universitat Politècnica de Catalunya </div><div>Evan Felix, Pacific Northwest National Laboratory</div><div>Maya Gokhale, Lawrence Livermore National Laboratory</div><div>Gary Grider, Los Alamos National Laboratory</div><div>Dean Hildebrand, IBM Almaden</div><div>Dries Kimpe, Argonne National Laboratory</div><div>Scott Klasky, Oak Ridge National Laboratory</div><div>Quincey Koziol, HDF Group</div><div>Jay Lofstead, Sandia National Laboratory</div><div>Barney Maccabe, Oak Ridge National Laboratory</div><div>Carlos Maltzahn, University of California at Santa Cruz</div><div>Adam Manzanares, HGST</div><div>Pat McCormick, Los Alamos National Laboratory</div><div>Michael Mesnier, Intel</div><div>Kiran-Kumar Muniswamy-Reddy, <a href="http://Amazon.com">Amazon.com</a></div><div>Neoklis Polyzotis, University of California at Santa Cruz</div><div>Rob Ross, Argonne National Laboratory</div><div>Sage Weil, Inktank Storage</div><div>Brent Welch, Google</div><div>Jon Woodring, Los Alamos National Laboratory</div><br><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Optima; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;  "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">-- <br>Carlos Maltzahn<br>Associate Adjunct Professor<span class="Apple-tab-span" style="white-space: pre; ">       </span><br>Computer Science Department<br>University of California, Santa Cruz<span class="Apple-tab-span" style="white-space: pre; ">      </span><br><a href="http://www.cs.ucsc.edu/~carlosm/">http://www.cs.ucsc.edu/~carlosm/</a></div></span></div></span></div></span></div></span></div></span></div></span>
</div>
<br></body></html>