Yehuda Sadeh Weinraub wrote:
That usually happens when there's some pending request that waits too
long. It's really hard to tell what exactly happened from this log as
for some reason we don't see the expected backtrace.
Thanks for the response.
was just cp'n some files into a ceph volume.
On Fri, Jun 11, 2010 at 7:23 AM, Peter Niemayer niema...@isg.de wrote:
Is there some documentation/discussion on the pro's and con's of using
other filesystems with Ceph?
Unfortunately, I can't seem to find anything.
Also, the documentation in the Wiki does not mention what would need
to be
On Fri, 11 Jun 2010, Gregory Farnum wrote:
That said, btrfs is most beneficial when you engage in snapshotting,
or have to handle recoveries. Ceph makes use of a number of ioctls to
ensure consistency and provide speed when running on btrfs; on other
filesystems snapshots will be much slower,
On 06/11/2010 06:26 PM, Gregory Farnum wrote:
Also, the documentation in the Wiki does not mention what would need
to be configured differently if another filesystem was to be used -
what would I have to use instead of btrfs devs = /dev/sdy?
You can look at the ceph.conf file produced by the
On 06/11/2010 06:40 PM, Sage Weil wrote:
The btrfs isn't required for consistency if the writeahead journal is
enabled (which it is by default). However, at the moment the code that
controls trimming the journal assumes ext3 data=ordered fsync semantics
(fsync flushes the entire journal and all
On Fri, 11 Jun 2010, Peter Niemayer wrote:
On 06/11/2010 06:40 PM, Sage Weil wrote:
The btrfs isn't required for consistency if the writeahead journal is
enabled (which it is by default). However, at the moment the code that
controls trimming the journal assumes ext3 data=ordered fsync
Hi Christian,
thanks for you patch. I tried it a little and it worked quite well but
during some live migration tests I noticed a problem.
The problem is related to live migration with high I/O using the AIO
calls (I triggered it with a simple dd).
If you launch a live migration and the guest
Hi Paul,
On Fri, 11 Jun 2010, Paul wrote:
Hiding the details of the id number sequence from the user seems like
a great idea.
Havn't seen any serious problems while running the mon-remove branch.
A few minor ones:
1. the mkcephfs and init scripts need a bit of tweaking to parse the
new
