This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "". The branch, master has been updated via 3a9a44318a0018bc8f37b40b3ecdc8bb15561012 (commit) from 44b504be9801bb87b4c26c8b5925e2d08b79edfd (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 3a9a44318a0018bc8f37b40b3ecdc8bb15561012 Author: John Jenkins <[email protected]> Date: Tue Mar 17 15:44:50 2015 -0500 autonomous object reorg text ----------------------------------------------------------------------- Summary of changes: .../triton-quarterly/2015.03.30/2.1.5-reorg.txt | 21 ++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-) create mode 100644 reports/triton-quarterly/2015.03.30/2.1.5-reorg.txt Diff of changes: diff --git a/reports/triton-quarterly/2015.03.30/2.1.5-reorg.txt b/reports/triton-quarterly/2015.03.30/2.1.5-reorg.txt new file mode 100644 index 0000000..7017c7d --- /dev/null +++ b/reports/triton-quarterly/2015.03.30/2.1.5-reorg.txt @@ -0,0 +1,21 @@ +Status: 25% +Synopsis: + +In this quarter, we have begun an investigation into reorganization of objects to reflect system and application workloads. Our initial exploration has been informed by the trends towards deeper memory/storage hierarchies, as evidenced by numerous projects investigating the usage of nonvolatile burst buffers [burst buffers,ff], recent storage medium advancements [2], and purpose-driven storage technologies specializing storage by data age and "temperature" (rate of access) [f4,pelican]. For such systems, there are numerous significant design questions to address. For example, should the namespace of these layers be unified under a single naming service or disjoint and managed by separate services? What are the costs of moving data between levels of the hierarchy, and under what conditions does it make sense to perform such moves? + +With respect to Triton, our plan is to first investigate the design points for Triton within such an architecture. Second, we plan to zoom out and investigate how different design aspects in Triton can inform hierarchical system architecture. + +As an example of the former, we plan to examine the feasibility of Triton as both a "hot" and "warm" storage layer, to use the "temperature" connotations in recent literature. In other words, we envision Triton serving as a persistent storage layer underneath burst storage media, for data that is both frequently accessed and accessed at a rate that would be unacceptable for more capacity-optimized storage layers. In this context, it is typically preferable for "hot" data to be replicated (resulting in a high redundancy ratio) to avoid erasure-coding overheads, while "warm" data is accessed at such a rate that erasure coding overheads (resulting in a lower redundancy ratio) are acceptable for access performance. In general, managing "hot" and "warm" data, especially in an automated manner, requires a good treatment of cost models and algorithms data transition between "hot" and "warm" storage modes (a frequently cited example being HP's AutoRAID system [TODO:autoraid]). Speci fic to Triton, there are a few challenges and research questions to explore: +1) how do we efficiently serve I/O requests to parity-coded objects distributed across multiple servers, while keeping with our design goals of server-directed I/O and conditional update functionality? +2) how does the use of parity-coded objects affect our local storage strategy, which is currently log-structured? +3) how do we consistently map RAID stripes in the face of failure while avoiding full object re-coding? + +(TODO: need to iterate on this more) +As an example of the latter, we plan to investigate the use of Triton's container/object/fork/record data model in a hierarchical storage context. In addition, the combination of consistent object location algorithms with tier-aware location services could be an area of study. + +[??] TODO: burst buffer cite. Fast Forward? +[??] TODO: fast forward project? +[??] TODO: shingle drive +[?] Subramanian Muralidhar et al., "F4: Facebook’s Warm BLOB Storage System," in Proceedings of the 11th USENIX Conference on Operating Systems Design and Implementation, Berkeley, CA, USA, 2014, pp. 383–398. +[?] Shobana Balakrishnan et al., "Pelican: A Building Block for Exascale Cold Data Storage," in Proceedings of the 11th USENIX Conference on Operating Systems Design and Implementation, Berkeley, CA, USA, 2014, pp. 351–365. +[?] John Wilkes et al., "The HP AutoRAID Hierarchical Storage System," ACM Trans. Comput. Syst., vol. 14, no. 1, pp. 108–136, Feb. 1996. hooks/post-receive --