- Posted by sage
- July 25th, 2013
This release fixes another regression preventing monitors to start after undergoing certain upgrade sequences, as well as some corner cases with Paxos and unusual device names in ceph-disk/cephde-loy.
- mon: fix regression in latest full osdmap retrieval
- mon: fix a long-standing bug with a paxos corner case
- ceph-disk: improved support for unusual device names (e.g., /dev/cciss/c0d0p1)
For more information see the full release notes.
You can get v0.61.7 from the usual places:
- Posted by sage
- July 25th, 2013
We have a release candidate for v0.67 Dumpling! There are a handful of remaining known issues (which I suppose means it is technically *not* an actual candidate for the final release), but for the most part we are happy with the stability so far, and encourage anyone with test clusters to give it a try.
Known issues include:
- There is a known performance regression due to non-optimal tuning values for the writeback throttling. We are still playing with the numbers to get good results across all workloads, but do not be surprised if you see throughput drop slightly with -rc2.
- The metadata sync agent for multi-region radosgw clusters is not quite ready yet.
- Creating swift containers in the non-master region does not work; fix is already in next.
The v0.67-rc2 release candidate packages are available from:
Note that at any time you can move from this -rc to the latest pre-dumpling code by switching to the ‘next’ branch, available at
The draft release notes for v0.67 dumpling are at
You can see our bug queue at
Note that ‘Pending backport’ means it is fixed in next but the cuttlefish backport has not landed yet. Also note that the kernel bugs (kcephfs, krbd) are not related to the dumpling release.
The time is fast approaching when legacy storage, like all mothers, must say farewell to her children. To help facilitate that process Inktank is kicking off another Ceph day next week (Aug 1st) in New York, NY. This gathering is for everyone from the inquisitive and uninitiated to the experienced and opinionated. If you have any interest in Ceph we would love for you to join us for a full day of Inktank engineers, partners, and all manner of Ceph users talking about Ceph.
Attend Ceph Day NYC!
- Posted by sage
- July 24th, 2013
There was a problem with the monitor daemons in v0.61.5 that would prevent them from restarting after some period of time. This release fixes the bug and works around the issue to allow affected monitors to restart. All v0.61.5 users are strongly recommended to upgrade.
- mon: record latest full osdmap
- mon: work around previous bug in which latest full osdmap was not recorded
- mon: avoid scrub while paxos is updating
For more information please see the complete release notes.
You can get v0.61.6 from the usual locations:
It’s that time again! Time for the (virtual) Ceph Developer Summit. We are currently accepting community blueprints for ‘Emperor,’ the next stable release of Ceph, which is due out in November. This summit will be slightly different from the Dumpling summit in that it will be spread over two days to give some of our more geographically disparate community members the opportunity to participate. Below you can find the timeline for all summit activities.
||Blueprint submissions begin
||Blueprint submissions end
||Summit agenda announced
||Ceph Developer Summit: Day 1
||Ceph Developer Summit: Day 2
If you are interested in submitting a blueprint, collaborating on an existing blueprint, or just attending to learn more about Ceph, read on!
- Posted by sage
- July 18th, 2013
We’ve prepared another update for the Cuttlefish v0.61.x series. This release primarily contains monitor stability improvements, although there are also some important fixes for ceph-osd for large clusters and a few important CephFS fixes. We recommend that all v0.61.x users upgrade.
- mon: misc sync improvements (faster, more reliable, better tuning)
- mon: enable leveldb cache by default (big performance improvement)
- mon: new scrub feature (primarily for diagnostic, testing purposes)
- mon: fix occasional leveldb assertion on startup
- mon: prevent reads until initial state is committed
- mon: improved logic for trimming old osdmaps
- mon: fix pick_addresses bug when expanding mon cluster
- mon: several small paxos fixes, improvements
- mon: fix bug osdmap trim behavior
- osd: fix several bugs with PG stat reporting
- osd: limit number of maps shared with peers (which could cause domino failures)
- rgw: fix radosgw-admin buckets list (for all buckets)
- mds: fix occasional client failure to reconnect
- mds: fix bad list traversal after unlink
- mds: fix underwater dentry cleanup (occasional crash after mds restart)
- libcephfs, ceph-fuse: fix occasional hangs on umount
- libcephfs, ceph-fuse: fix old bug with O_LAZY vs O_NOATIME confusion
- ceph-disk: more robust journal device detection on RHEL/CentOS
- ceph-disk: better, simpler locking
- ceph-disk: do not inadvertantely mount over existing osd mounts
- ceph-disk: better handling for unusual device names
- sysvinit, upstart: handle symlinks in /var/lib/ceph/*
Please also refer to the complete release notes.
You can get v0.61.5 from the usual locations:
In case you missed Loic’s account of a recent visit to the Université de Nantes, we are replicating his blog here. It’s always great to see the community adopting Ceph and doing great things with it, even if they are doing it without Inktank support. Read on for a great look at a Ceph early adopter.
For those of you that may have just wandered in from some obscure corner of the internet and haven’t seen the earlier parts of this series, you may want to go back and start at the beginning.
If you’ve made it all the way from Part 1 to this article and are still reading, I’ve got to applaud you. There aren’t many people that have the attention span to make it through that much data and still care. Even Sage lost interest after a while! If you skipped portions of Part 2, Part 3, and Part 4, I won’t hold it against you. We collected a vast amount of information in those tests. Unless you are willing to make parsing performance data a major part of your life, it’s pretty easy to get lost in it all. The goal in this final article is to see if we can distill that data down into something a little more manageable and draw some useful conclusions from it. We won’t be talking about absolute performance numbers as we already have plenty of those. Instead, we’ll look at relative performance.
This is the part I’ve been waiting for. We’ll be testing just how fast we can make Ceph perform with 4M IOs on Kernel and QEMU/KVM RBD volumes. Again, we’ll be looking at how performance scales as the number of concurrent IOs increases across volumes and even different virtual machines. We’ll use the same sequential write, random write, sequential read, and random read IO patterns we used in part 2 and part 3. The big question in my mind is this: Just how close can we get to the RADOS performance we saw in Part 1? Now we’ll find out! ALLONS-Y!
I’m amazed you are still here! You must be a glutton for punishment (or you haven’t read part 1 and part 2 yet!) If you haven’t run away in fear yet, then prepare yourself! Today we will be looking at how the Ceph Kernel and QEMU/KVM RBD implementations perform with 128K IOs using fio. Again, we’ll be testing how performance scales as the number of concurrent IOs increases across different volumes and even different virtual machines. We’ll use the same sequential write, random write, sequential read, and random read IO patterns we used in part 2.