screenshot taken from: https://de.slideshare.net/slideshow/20190627-intro-to-ceph/233987022
When
Monday, 29th June 2026, 5:30pm to 6:40pm
Where
Design Offices Berlin Leipziger Platz, Leipziger Platz 16, Berlin, Germany
Hosting Organization
Ceph Berlin
Participation Fee
Free Entrance
Agenda
Talk
Topics Covered
Introduction to the Open Source Distributed Storage Technology Ceph (Talk)
I’ve learned something today
- “Intro to Ceph — Open Source Distributed Storage” is a Ceph Tech Talk by Sage Weil (see YouTube). Presented more than 7 years ago, it introduces Ceph as an open-source distributed storage system. In particular, the talk explains the RADOS layer, object storage, block storage, and file storage. Furthermore, it highlights Ceph’s scalability, reliability, and data placement through the CRUSH algorithm.
- For the people developing Ceph, a typical assumed design size is around 5,000 storage devices. While experiments with up to 130,000 storage devices have already been conducted, such extreme scales are not yet recommended for enterprise use cases.
- Ceph emerged from Sage A. Weil’s PhD research at the University of California, Santa Cruz. This work culminated in his 2007 dissertation, Ceph: Reliable, Scalable, and High-Performance Distributed Storage.
- Ceph does not support standard SMR HDDs because these drives need data to be written mostly sequentially, while Ceph performs many small and random writes across the disk. For example, a Ceph OSD may write a 4 KB metadata update or a small object change at a random location, but an SMR drive may need to rewrite a much larger zone internally to place that small change safely.
- Engineers dealing with data storage should avoid placing all query-intensive objects on the same physical media. This can create localized hotspots. It can also degrade overall system performance. A robust placement group design in Ceph should distribute high-load objects deliberately. This reduces the risk that unlucky co-location becomes a bottleneck under heavy query activity.
- When an OSD fails, performance can paradoxically improve. One latency-inducing replication path could be temporarily removed. However, such an apparent gain comes at the cost of reduced redundancy. It should not be interpreted as an indicator of healthy system behavior.
- Uneasy lies the head that wears a red fedora:
picture taken at venue
Published:
Modified: