Thanks Sage and Yehuda.
On May 17, 2014, at 12:42 AM, Yehuda Sadeh yeh...@inktank.com wrote:
On Fri, May 16, 2014 at 6:09 AM, Sage Weil s...@inktank.com wrote:
Hi Guang,
[I think the problem is that your email is HTML formatted, and vger
silently drops those. Make sure your mailer is set
After a major crushmap reconfiguration, OSDs needed some help to speed
up recovery, freeing up space on nearly-full OSDs earlier than the
cluster would on its own, in some cases temporarily sacrificing some
redundancy.
Unfortunately, ceph_filestore_dump may take a long time to remove even
a
When a btrfs OSD suicides because it couldn't keep up with others
(recovery included), it is often the case that the filesystem is in a
state in which creating and removing snapshots takes a long time. It
is likely that there are going to be plenty of recovering PGs (with
corresponding TEMP
This patch applies on top of the one I just posted, Subject “osd: avoid
flushing every TEMP removal to speedup startup”.
When PG removals are underway and the OSD is restarted, or when
multiple removals are scheduled manually with ceph_filestore_dump
premove, the OSD may take a long time to
After using the filestore of one osd to initialize another so as to
speed things up, adjusting the osd number in the superblock, I found
out the monitor will silently reject osds that don't have the expected
id: they seem to be just taking long to complete the boot, but nothing
is logged to the
On Sun, 18 May 2014, Guang wrote:
radosgw is using the omap key/value API for objects, which is more or less
equivalent to what swift is doing with sqlite. This data passes straight
into leveldb on the backend (or whatever other backend you are using).
Using something like rocksdb in its
subscribe ceph-devel
--
___
Songjiang Zhao
songjiangz...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
