Back

Ceph: a scalable, high-performance distributed file system

Sage A. WeilScott A. BrandtEthan L. MillerDarrell D. E. LongCarlos Maltzahn

article2006OSDI2,012 citations

Presents Ceph, an influential distributed file system architecture that achieves petabyte-scale storage performance by replacing centralized allocation tables with the CRUSH pseudo-random data placement algorithm and distributing data management tasks across semi-autonomous object storage devices.

Listen

As organizations expand to petabyte-scale storage, conventional distributed file systems struggle to maintain performance and reliability. Traditional centralized architectures suffer from severe bottlenecks because metadata management—such as tracking file names, directories, and storage block allocations—cannot scale linearly with growing client demand and dynamic workloads, where node failures are routine.

The article demonstrates the design, implementation, and performance of Ceph, a distributed file system engineered to achieve scalable performance, high reliability, and massive storage capacity. It evaluates whether decoupling data and metadata while assigning management tasks to intelligent storage devices can eliminate traditional architectural bottlenecks.

To evaluate Ceph, the researchers built a functional software prototype and tested it on dual-processor Linux computing clusters, including a 430-node supercomputing cluster partition at Lawrence Livermore National Laboratory. The architecture introduces three core elements: a pseudo-random distribution algorithm known as CRUSH that calculates object locations instead of looking up allocation tables; a dynamic metadata management cluster using dynamic subtree partitioning to balance file directory workloads; and an autonomous object storage layer (RADOS) paired with a custom low-level object file system (EBOFS) to delegate replication, failure detection, and recovery directly to storage devices.

The evaluation produced several critical findings. First, metadata management achieved near-linear scaling, processing over 250,000 metadata operations per second on a 128-node metadata cluster—representing an order-of-magnitude increase over legacy high-performance storage environments. Second, as the metadata cluster scaled from small configurations to 128 nodes, per-node efficiency dropped by no more than 50% across diverse workloads, maintaining high throughput even under intense write and read sharing. Third, storage device throughput scaled linearly and nearly saturated physical disk write limits (approximately 58 megabytes per second) for write sizes above 32 kilobytes, while outperforming general-purpose file systems on reads. Finally, the algorithmic data placement minimized data migration during cluster resizing and avoided centralized lookup bottlenecks entirely.

These findings indicate that storage infrastructure can scale to hundreds of petabytes without incurring proportional administrative or performance overheads. By shifting replication, recovery, and placement calculation tasks to intelligent storage devices, organizations can drastically reduce single points of failure, shorten recovery times, and lower the infrastructure costs associated with maintaining large, static metadata servers. Furthermore, selective POSIX consistency relaxation allows high-performance computing applications to bypass latency penalties during heavy read-write sharing.

Organizations planning petabyte-scale deployments should consider adopting Ceph's decoupled object storage architecture, especially for high-concurrency scientific and data-intensive workloads. When deploying, teams should ensure sufficient placement group allocation (targeting at least 100 placement groups per storage device) to keep device utilization variance below 10%, and utilize the custom relaxed I/O extensions where strict synchronous consistency is unnecessary.

While the findings strongly demonstrate architectural viability and scalability, readers should note that the prototype evaluated in the article has specific limitations. At the time of evaluation, metadata server failure recovery and security authorization protocol mechanisms were not yet fully implemented, tests were conducted on fresh rather than aged file systems, and the user-space client interface introduced overhead that necessitates a native in-kernel implementation for maximum efficiency.

University of California, Santa Cruzdistributed file systemsdistribution functionsgeneral purposeDataMetadataCeph
ceph/cephWeil et al (2006).pdf
Cover for Ceph: a scalable, high-performance distributed file system

Abstract

We have developed Ceph, a distributed file system that provides excellent performance, reliability, and scalability. Ceph maximizes the separation between data and metadata management by replacing allocation tables with a pseudo-random data distribution function (CRUSH) designed for heterogeneous and dynamic clusters of unreliable object storage devices (OSDs). We leverage device intelligence by distributing data replication, failure detection and recovery to semi-autonomous OSDs running a specialized local object file system. A dynamic distributed metadata cluster provides extremely efficient metadata management and seamlessly adapts to a wide range of general purpose and scientific computing file system workloads. Performance measurements under a variety of workloads show that Ceph has excellent I/O performance and scalable metadata management, supporting more than 250,000 metadata operations per second.

Topics

distributed file systemsdistribution functionsgeneral purposescientific computingstorage devicesdetection algorithm

Keywords

DataMetadataCephMDSOSDsStorageClusterOSDDistributedPerformance

Table of Contents

  • Abstract
  • 1 Introduction
  • 2 System Overview
  • 3 Client Operation
  • 3.1 File I/O and Capabilities
  • 3.2 Client Synchronization
  • 3.3 Namespace Operations
  • 4 Dynamically Distributed Metadata
  • 4.1 Metadata Storage
  • 4.2 Dynamic Subtree Partitioning
  • 4.3 Traffic Control
  • 5 Distributed Object Storage
  • 5.1 Data Distribution with CRUSH
  • 5.2 Replication
  • 5.3 Data Safety
  • 5.4 Failure Detection
  • 5.5 Recovery and Cluster Updates
  • 5.6 Object Storage with EBOFS
  • 6 Performance and Scalability Evaluation
  • 6.1 Data Performance
  • 6.1.1 OSD Throughput
  • 6.1.2 Write Latency
  • 6.1.3 Data Distribution and Scalability
  • 6.2 Metadata Performance
  • 6.2.1 Metadata Update Latency
  • 6.2.2 Metadata Read Latency
  • 6.2.3 Metadata Scaling
  • 7 Experiences
  • 8 Related Work
  • 9 Future Work
  • 10 Conclusions
  • Acknowledgments
  • References

Knowls

  1. Knowl 1 — Ceph Architecture: Decoupled Data and Metadata via Intelligent OSDs

    model/method

    Ceph is a distributed file system designed for petabyte-scale storage that decouples metadata management from data storage across three primary components:

    1. Client Instances: Run on application hosts (either linked directly into user-space applications or mounted via FUSE). Clients expose a near-POSIX file system interface, maintain private data caches, and perform direct I/O with storage devices without routing file data through metadata servers.
    2. Metadata Server (MDS) Cluster: Coordinates the file system directory hierarchy, translates file paths to inodes, manages client capabilities and consistency semantics, and operates without maintaining block or object allocation tables.
    3. Object Storage Device (OSD) Cluster (RADOS): A collection of semi-autonomous, intelligent OSDs (each combining a CPU, memory, network interface, and local disk storage). The OSD cluster collectively presents a unified flat object namespace, autonomously executing data replication, failure detection, dynamic rebalancing, and failure recovery.

  2. Knowl 2 — Deterministic Data Placement via Placement Groups and the CRUSH Algorithm

    model/method

    Ceph eliminates centralized file allocation tables and per-file block lists by computing data locations algorithmically:

    • Object Striping: Files are striped into predictably named objects identified by combining the file inode number and a stripe index: oid=(inode_number,stripe_number)\text{oid} = (\text{inode\_number}, \text{stripe\_number})
    • Placement Groups (PGs): Objects are mapped to a fixed number of placement groups using an adjustable hash mask: pgid=hash(oid)(modM)\text{pgid} = \text{hash}(\text{oid}) \pmod M where MM is the number of placement groups, chosen such that each OSD manages on the order of 100 PGs to balance variance in device utilization with per-device metadata tracking overhead.
    • CRUSH Mapping: The placement group identifier pgid\text{pgid} is mapped to an ordered list of nn OSDs using CRUSH (Controlled Replication Under Scalable Hashing): CRUSH(pgid,cluster_map,rule)→(osd1,osd2,…,osdn)\text{CRUSH}(\text{pgid}, \text{cluster\_map}, \text{rule}) \to (\text{osd}_1, \text{osd}_2, \dots, \text{osd}_n) CRUSH evaluates a hierarchical cluster map that encodes physical failure domains (e.g., shelves, racks, power circuits) and individual OSD capacity weights. Placement computations are deterministic, execute in O(log⁡N)O(\log N) time for NN total OSDs, and can be evaluated independently by clients, MDSs, and OSDs without querying a centralized server.

  3. Knowl 3 — Dynamic Subtree Partitioning for Metadata Cluster Load Balancing

    model/method

    The Ceph Metadata Server (MDS) cluster distributes file system namespace operations across multiple servers using Dynamic Subtree Partitioning:

    • Popularity Tracking: Each MDS measures the popularity of metadata within the directory hierarchy using exponential time-decay counters. Any operation increments the counter on the affected inode and all its ancestor directories up to the root, generating a weighted tree of recent workload distribution.
    • Dynamic Rebalancing: MDS nodes periodically compare their load values and dynamically migrate appropriately sized directory subtrees between MDS instances by transferring in-memory cache states. Authority transfers are committed to journals using a two-phase protocol.
    • Locality Preservation: Subtrees are partitioned coarsely to retain directory locality, facilitating sequential disk updates and efficient directory prefetching.
    • Replicated Inode State FSMs: Inode contents replicated across MDS nodes are divided into three lock groups with independent finite state machines (FSMs):
      1. Security: Owner and mode (checked during path traversal, rarely modified).
      2. File: File size and modification time (mtimemtime), which control client read/write capability distribution.
      3. Immutable: Inode number, creation time (ctimectime), and striping layout.

  4. Knowl 4 — Metadata Traffic Control: Read Replication and Directory Hashing

    model/method

    To handle flash crowds and hot spots that overwhelm single-MDS directory partitioning, Ceph dynamically adjusts partition granularity based on access patterns:

    • Read-Heavy Hot Spots: Heavily read directories (e.g., directories experiencing many concurrent open operations) are selectively replicated across multiple MDS nodes. Clients receive updated authority maps in MDS replies and direct subsequent read requests to random replicas.
    • Write-Heavy Hot Spots: Directories that are very large or undergo heavy write loads (e.g., thousands of concurrent file creations in a single directory) have their directory entries dynamically hashed by file name across the entire MDS cluster. This distributes the write workload evenly across all MDS nodes at the expense of directory locality. Directory modification time (mtimemtime) coherence is relaxed during distributed hashing.
    • Client Cache Distribution: MDS responses inform clients about the authority and replication of inodes along requested paths, dispersing future client traffic across the MDS cluster.

  5. Knowl 5 — RADOS Primary-Copy Replication and Two-Phase Update Acknowledgment

    model/method

    Ceph's Reliable Autonomic Distributed Object Store (RADOS) manages nn-way object replication through primary-copy replication with decoupled synchronization and data safety:

    1. Client Submission: Clients send write requests directly to the primary OSD (the first active OSD in the placement group determined by CRUSH).
    2. Version Assignment and Replication: The primary OSD assigns a new version number to the object and the placement group, and forwards the update concurrently to the n−1n-1 replica OSDs.
    3. In-Memory Synchronization (ack): Once each replica applies the write to its in-memory buffer cache and replies to the primary, the primary applies the write locally and sends an acknowledgment (ack) to the client. This allows synchronous POSIX calls on the client to return immediately.
    4. On-Disk Safety Commit (commit): When the update is committed to non-volatile disk on all OSDs, a final commit message is sent to the client. Clients buffer uncommitted writes locally to protect against simultaneous power loss across all OSDs in a placement group.

  6. Knowl 6 — Autonomous Failure Detection and Distributed Peer Recovery in RADOS

    model/method

    RADOS distributes failure detection and recovery across semi-autonomous OSDs without central coordination bottlenecks:

    • Failure Detection: OSDs monitor peer OSDs with which they share placement groups using existing data replication traffic as passive heartbeats, falling back to explicit ping messages when traffic is idle.
    • Liveness Classification: An unresponsive OSD is marked down, causing primary responsibilities to pass temporarily to the next active OSD in the PG. If the failure persists, a small monitor cluster using Paxos consensus marks the OSD out of the data distribution in an updated cluster map epoch, triggering re-replication to replacement OSDs.
    • Log-Based Peering and Recovery: Each OSD maintains an object version identifier and an incremental change log per placement group. Upon receiving an updated cluster map, OSDs peer with members of their assigned PGs, exchange version numbers, identify missing updates from the logs, and transfer missing objects directly between peers in parallel across the cluster.

  7. Knowl 7 — EBOFS: User-Space Extent and B-Tree Object File System

    model/method

    Each Ceph OSD manages local storage using EBOFS (Extent and B-tree Object File System), a custom user-space file system interacting directly with raw block devices:

    • Atomic Transactions: Supports atomic multi-object data and attribute update transactions, separating update serialization (returning when in-memory caches are modified) from on-disk commits (notified asynchronously).
    • Extent Allocation: Replaces block-level pointers with extents (start block and length pairs). Free extents are binned by size and sorted by disk location to allocate space contiguous with write sizes and minimize fragmentation.
    • B-Tree Indexing: Uses an integrated B-tree hierarchy to locate objects, track block allocations, and index placement group collections. All metadata except per-object allocation lists is cached in memory.
    • Copy-on-Write and Write Scheduling: Implements copy-on-write for all data updates (except superblock writes) and aggressively schedules disk writes, cancelling pending I/O operations if overwritten by subsequent updates.

  8. Knowl 8 — POSIX Interface Extensions and Consistency Modes in Ceph

    model/method

    Ceph supports strict POSIX file semantics via capability tokens (granting read, read-cache, write, and write-buffer rights) but provides specialized API extensions for high-performance distributed applications:

    • Strict POSIX Fallback: When multiple clients open a file concurrently with at least one writer, the MDS revokes read-caching and write-buffering capabilities. Client I/O reverts to synchronous operations directly against primary OSDs, using OSD-level locks for overlapping write serialization.
    • O_LAZY: An open flag that relaxes standard POSIX coherency for shared-write files, enabling clients to buffer writes and cache reads locally when multiple processes access disjoint regions of the same file.
    • lazyio_propagate(offset, count): Explicitly flushes a specified byte range from client memory to the OSD storage cluster.
    • lazyio_synchronize(offset, count): Ensures subsequent read calls reflect all previously propagated writes from other clients.
    • readdirplus: Returns full lstat metadata along with directory entries in a single MDS round-trip.
    • statlite(mask): Requests file attributes while specifying a bitmask of fields that do not require synchronization with active writers.

  9. Knowl 9 — Metadata Storage Hierarchy: Journaling, Directory Embedding, and Anchor Tables

    model/method

    Ceph stores metadata across a two-tiered hierarchy optimized for fast updates, directory locality, and low overhead:

    • MDS Journaling: Metadata updates are streamed sequentially to large, bounded, lazily flushed journals (hundreds of megabytes) stored as objects in the RADOS cluster. These journals absorb repetitive updates before committing data to long-term storage and facilitate fast MDS state recovery upon failure.
    • Directory-Embedded Inodes: Inodes (80 bytes) are embedded directly within directory objects rather than in a separate global inode table. This enables an MDS to prefetch an entire directory and all constituent file metadata in a single OSD read request.
    • Anchor Table for Hard Links: Inode numbers are allocated in disjoint ranges per MDS. For the rare case of files with multiple hard links, an auxiliary anchor table maps inode numbers to primary directory paths, preserving global addressability without requiring a monolithic inode table for singly linked files.

  10. Knowl 10 — Scalability and Throughput of the Ceph Metadata Server Cluster

    empirical result

    Evaluation on a 430-node Linux cluster demonstrates the scaling behavior and performance of Ceph's dynamic metadata server cluster:

    • Aggregate Throughput: A 128-node MDS cluster achieves over 250,000250,000 metadata operations per second (128×2,000 ops/sec128 \times 2,000\text{ ops/sec}).
    • Scaling Efficiency Across Workloads:
      • makedirs (nested directory creation): Per-MDS throughput decreases from ≈2,000 ops/sec\approx 2,000\text{ ops/sec} on small clusters to ≈1,000 ops/sec\approx 1,000\text{ ops/sec} at 128 MDS nodes (achieving over 100,000 ops/sec100,000\text{ ops/sec} aggregate, representing ≈50%\approx 50\% efficiency relative to linear scaling).
      • makefiles (massive file creations in a single directory): Dynamic directory hashing and relaxed directory mtimemtime coherence distribute write load uniformly across 128 MDS nodes.
      • openssh+lib (compilation trace with private dirs and shared /lib): Exhibits high scaling efficiency due to low modification contention and moderate sharing.
      • openshared and openssh+include (heavy read sharing of shared files/headers): Show lower scaling efficiency due to non-optimal client replica selection.
    • Update Latency: Synchronous metadata updates on a diskless MDS incur ≈1.5 ms\approx 1.5\text{ ms} latency for 1-way replication, ≈2.5 ms\approx 2.5\text{ ms} for 2-way, and ≈2.7 ms\approx 2.7\text{ ms} for 3-way. With a local disk as primary journal OSD, 2-way replication latency drops to ≈1.5 ms\approx 1.5\text{ ms} (matching 1-way diskless latency).

  11. Knowl 11 — Data I/O Performance and Scalability of RADOS and EBOFS

    empirical result

    Microbenchmarks evaluating Ceph's OSD storage cluster and EBOFS local object store show:

    • EBOFS vs. General-Purpose File Systems: For write sizes exceeding 32 KB32\text{ KB}, EBOFS nearly saturates raw physical disk bandwidth (≈58 MB/sec\approx 58\text{ MB/sec} per OSD), matching or outperforming ext3, ReiserFS, and XFS. For reads, EBOFS significantly outperforms general-purpose file systems by laying out data in large contiguous extents matching write sizes.
    • Cluster Throughput Scaling: Per-OSD write throughput scales linearly with OSD cluster size up to 24 OSD nodes, where performance saturates the physical network switch.
    • Replication Overhead and Latency: For small synchronous writes (≤64 KB\le 64\text{ KB}), 2-way and 3-way replication incur minimal additional latency over 1-way because the primary OSD transmits updates to replicas concurrently. For large synchronous writes, transmission time dominates: 1 MB1\text{ MB} write latency increases from 13 ms13\text{ ms} (1 replica) to 33 ms33\text{ ms} (3 replicas).
    • Placement Group Balance: In a cluster using CRUSH, placement group count controls load balance variance: 100 PGs per OSD yields a standard deviation in OSD utilization of 10%10\%, whereas 1000 PGs per OSD reduces standard deviation to 3%3\%.

Coverage note — No substantial contributed material was omitted; the knowls cover Ceph's architecture, data mapping, dynamic metadata balancing, RADOS replication and failure recovery, EBOFS, POSIX extensions, and empirical evaluations.

References

  1. 1.A. Adya, W. J. Bolosky, M. Castro, R. Chaiken, G. Cermak, J. R. Douceur, J. Howell, J. R. Lorch, M. Theimer, and R. Wattenhofer. FARSITE: Federated, available, and reliable storage for an incompletely trusted environment. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI), Boston, MA, Dec. 2002. USENIX.
  2. 2.A. Azagury, V. Dreizin, M. Factor, E. Henis, D. Naor, N. Rinetzky, O. Rodeh, J. Satran, A. Tavory, and L. Yerushalmi. Towards an object store. In Proceedings of the 20th IEEE / 11th NASA Goddard Conference on Mass Storage Systems and Technologies, pages 165–176, Apr. 2003.
  3. 3.P. J. Braam. The Lustre storage architecture. http://www.lustre.org/documentation.html, Cluster File Systems, Inc., Aug. 2004.
  4. 4.L.-F. Cabrera and D. D. E. Long. Swift: Using distributed disk striping to provide high I/O data rates. Computing Systems, 4(4):405–436, 1991.
  5. 5.P. F. Corbett and D. G. Feitelson. The Vesta parallel file system. ACM Transactions on Computer Systems, 14(3):225–264, 1996.
  6. 6.S. Ghemawat, H. Gobioff, and S.-T. Leung. The Google file system. In Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP ’03), Bolton Landing, NY, Oct. 2003. ACM.
  7. 7.G. A. Gibson, D. F. Nagle, K. Amiri, J. Butler, F. W. Chang, H. Gobioff, C. Hardin, E. Riedel, D. Rochberg, and J. Zelenka. A cost-effective, high-bandwidth storage architecture. In Proceedings of the 8th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), pages 92–103, San Jose, CA, Oct. 1998.
  8. 8.D. Hildebrand and P. Honeyman. Exporting storage systems in a scalable manner with pNFS. Technical Report CITI-05-1, CITI, University of Michigan, Feb. 2005.
  9. 9.D. Karger, E. Lehman, T. Leighton, M. Levine, D. Lewin, and R. Panigrahy. Consistent hashing and random trees: Distributed caching protocols for relieving hot spots on the World Wide Web. In ACM Symposium on Theory of Computing, pages 654–663, May 1997.
  10. 10.J. Kubiatowicz, D. Bindel, Y. Chen, P. Eaton, D. Geels, R. Gummadi, S. Rhea, H. Weatherspoon, W. Weimer, C. Wells, and B. Zhao. OceanStore: An architecture for global-scale persistent storage. In Proceedings of the 9th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), Cambridge, MA, Nov. 2000. ACM.
  11. 11.R. Latham, N. Miller, R. Ross, and P. Carns. A next-generation parallel file system for Linux clusters. LinuxWorld, pages 56–59, Jan. 2004.
  12. 12.B. Liskov, S. Ghemawat, R. Gruber, P. Johnson, L. Shrira, and M. Williams. Replication in the Harp file system. In Proceedings of the 13th ACM Symposium on Operating Systems Principles (SOSP ’91), pages 226–238. ACM, 1991.
  13. 13.C. R. Lumb, G. R. Ganger, and R. Golding. D-SPTF: Decentralized request distribution in brick-based storage systems. In Proceedings of the 11th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), pages 37–47, Boston, MA, 2004.
  14. 14.J. Menon, D. A. Pease, R. Rees, L. Duyanovich, and B. Hillsberg. IBM Storage Tank—a heterogeneous scalable SAN file system. IBM Systems Journal, 42(2):250–267, 2003.
  15. 15.N. Nieuwejaar and D. Kotz. The Galley parallel file system. In Proceedings of 10th ACM International Conference on Supercomputing, pages 374–381, Philadelphia, PA, 1996. ACM Press.
  16. 16.N. Nieuwejaar, D. Kotz, A. Purakayastha, C. S. Ellis, and M. Best. File-access characteristics of parallel scientific workloads. IEEE Transactions on Parallel and Distributed Systems, 7(10):1075–1089, Oct. 1996.
  17. 17.C. A. Olson and E. L. Miller. Secure capabilities for a petabyte-scale object-based distributed file system. In Proceedings of the 2005 ACM Workshop on Storage Security and Survivability, Fairfax, Virgina, USA, Nov. 2005.
  18. 18.B. Pawlowski, C. Juszczak, P. Staubach, C. Smith, D. Lebel, and D. Hitz. NFS version 3: Design and implementation. In Proceedings of the Summer 1994 USENIX Technical Conference, pages 137–151, 1994.
  19. 19.O. Rodeh and A. Teperman. zFS—a scalable distributed file system using object disks. In Proceedings of the 20th IEEE / 11th NASA Goddard Conference on Mass Storage Systems and Technologies, pages 207–218, Apr. 2003.
  20. 20.D. Roselli, J. Lorch, and T. Anderson. A comparison of file system workloads. In Proceedings of the 2000 USENIX Annual Technical Conference, pages 41–54, San Diego, CA, June 2000. USENIX Association.
  21. 21.Y. Saito, S. Frølund, A. Veitch, A. Merchant, and S. Spence. FAB: Building distributed enterprise disk arrays from commodity components. In Proceedings of the 11th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), pages 48–58, 2004.
  22. 22.F. Schmuck and R. Haskin. GPFS: A shared-disk file system for large computing clusters. In Proceedings of the 2002 Conference on File and Storage Technologies (FAST), pages 231–244. USENIX, Jan. 2002.
  23. 23.H. Tang, A. Gulbeden, J. Zhou, W. Strathearn, T. Yang, and L. Chu. A self-organizing storage cluster for parallel data-intensive applications. In Proceedings of the 2004 ACM/IEEE Conference on Supercomputing (SC ’04), Nov. 2004.
  24. 24.F. Wang, Q. Xin, B. Hong, S. A. Brandt, E. L. Miller, D. D. E. Long, and T. T. McLarty. File system workload analysis for large scale scientific computing applications. In Proceedings of the 21st IEEE / 12th NASA Goddard Conference on Mass Storage Systems and Technologies, pages 139–152, College Park, MD, Apr. 2004.
  25. 25.S. A. Weil. Scalable archival data and metadata management in object-based file systems. Technical Report SSRC-04-01, University of California, Santa Cruz, May 2004.
  26. 26.S. A. Weil, K. T. Pollack, S. A. Brandt, and E. L. Miller. Dynamic metadata management for petabyte-scale file systems. In Proceedings of the 2004 ACM/IEEE Conference on Supercomputing (SC ’04), Pittsburgh, PA, Nov. 2004. ACM.
  27. 27.B. Welch. POSIX IO extensions for HPC. In Proceedings of the 4th USENIX Conference on File and Storage Technologies (FAST), Dec. 2005.
  28. 28.B. Welch and G. Gibson. Managing scalability in object storage systems for HPC Linux clusters. In Proceedings of the 21st IEEE / 12th NASA Goddard Conference on Mass Storage Systems and Technologies, pages 433–445, Apr. 2004.
  29. 29.B. S. White, M. Walker, M. Humphrey, and A. S. Grimshaw. LegionFS: A secure and scalable file system supporting cross-domain high-performance applications. In Proceedings of the 2001 ACM/IEEE Conference on Supercomputing (SC ’01), Denver, CO, 2001.
  30. 30.J. Wilkes, R. Golding, C. Staelin, and T. Sullivan. The HP AutoRAID hierarchical storage system. In Proceedings of the 15th ACM Symposium on Operating Systems Principles (SOSP ’95), pages 96–108, Copper Mountain, CO, 1995. ACM Press.
  31. 31.T. M. Wong, R. A. Golding, J. S. Glider, E. Borowsky, R. A. Becker-Szendy, C. Fleiner, D. R. Kenchammana-Hosekote, and O. A. Zaki. Kybos: self-management for distributed brick-base storage. Research Report RJ 10356, IBM Almaden Research Center, Aug. 2005.
  32. 32.J. C. Wu and S. A. Brandt. The design and implementation of AQuA: an adaptive quality of service aware object-based storage device. In Proceedings of the 23rd IEEE / 14th NASA Goddard Conference on Mass Storage Systems and Technologies, College Park, Maryland, May 2006. To appear.
  33. 33.Q. Xin, E. L. Miller, and T. J. E. Schwarz. Evaluation of distributed recovery in large-scale storage systems. In Proceedings of the 13th IEEE International Symposium on High Performance Distributed Computing (HPDC), pages 172–181, Honolulu, HI, June 2004.

Citation

MLA
Weil, S. A., et al. “Ceph: A Scalable, High-performance Distributed File System”. eScholarship (California Digital Library), 2006, pp. 307–20, https://escholarship.org/uc/item/1pf8q17j.
APA
Weil, S. A., Brandt, S., Miller, E. L., Long, D. D. E., & Maltzahn, C. (2006). Ceph: a scalable, high-performance distributed file system. eScholarship (California Digital Library), 307–320. https://escholarship.org/uc/item/1pf8q17j
Chicago
Weil, S. A., S. Brandt, E. L. Miller, D. D. E. Long, and C. Maltzahn. 2006. “Ceph: A Scalable, High-performance Distributed File System”. eScholarship (California Digital Library), 307–20. https://escholarship.org/uc/item/1pf8q17j.
Harvard
Weil, S.A. et al. (2006) “Ceph: a scalable, high-performance distributed file system”, eScholarship (California Digital Library), pp. 307–320. Available at: https://escholarship.org/uc/item/1pf8q17j.
Vancouver
1. Weil SA, Brandt S, Miller EL, Long DDE, Maltzahn C (2006) Ceph: a scalable, high-performance distributed file system. eScholarship (California Digital Library) 307–320

BibTeX

@article{weil2006ceph,
  title = {Ceph: a scalable, high-performance distributed file system},
  author = {Weil, Sage A. and Brandt, Scott and Miller, Ethan L. and Long, Darrell D. E. and Maltzahn, Carlos},
  year = {2006},
  journal = {eScholarship (California Digital Library)},
  pages = {307-320},
  url = {https://escholarship.org/uc/item/1pf8q17j}
}
Metadata:DOI registry

Source Code

This paper has an official code repository available. Click below to access the source code.

View Repository

Access the Paper

This paper is available from its original source. Click below to access the PDF.

Open PDF