Stephen,
You may want to tweak the following parameter(s) in your ceph.conf file and see
if it is further improving your performance or not.
debug_lockdep = 0/0
debug_context = 0/0
debug_crush = 0/0
debug_buffer = 0/0
debug_timer = 0/0
debug_filer = 0/0
debug_objecter = 0/0
debug_rados = 0/0
Hi Ceph,
Here is a sorted list of authors and organizations who contributed to v0.91, by
number of commits or reviews back to v0.90. The affiliation of authors to
organizations can be updated by submitting a patch to
https://github.com/ceph/ceph/blob/master/.organizationmap
All commits are
I went back and grabbed 87 and built it on RHEL7 as well, and performance is
also similar (much better). I've also run it on a few systems (Dual socket
10-core E5v2, Dual socket 6-core E5v3). So, it's related to my switch to
RHEL7, and not to the code changes between v0.90 and v0.87.
This is a long-awaited bugfix release for firefly. It has several
imporant (but relatively rare) OSD peering fixes, performance issues when
snapshots are trimmed, several RGW fixes, a paxos corner case fix, and
some packaging updates.
We recommend that all users for v0.80.x firefly upgrade
Haha :) Well, my intuition is still pointing to something I've configured
wrong (or had wrong).. but it will be interesting to see what it is.
-Original Message-
From: Mark Nelson [mailto:mark.nel...@inktank.com]
Sent: Wednesday, January 14, 2015 3:43 PM
To: Blinick, Stephen L; Ceph
Somnath -- thanks for the info. . I held out for a while but eventually settled
on running without debug as you've specified below.. I am not currently
disabling crc signatures on messages, however. I can see if that makes an
improvement.
The latency reduction for single-client
We are quickly approaching the Hammer feature freeze but have a few more
dev releases to go before we get there. The headline items are
subtree-based quota support in CephFS (ceph-fuse/libcephfs client support
only for now), a rewrite of the watch/notify librados API used by RBD and
RGW,
On 01/06/2015 12:14 PM, Ken Dreyer wrote:
There's the question of Unix Domain Sockets support. In Yehuda's testing
with mod_proxy_fcgi, Unix Domain Sockets (UDS) provide a lot better
performance in comparison to TCP sockets. Apache's UDS support shipped
in Apache upstream version 2.4.9, but
Repairing the pg_log with kv-store-tool would probably be your best bet.
-Sam
On Wed, Jan 14, 2015 at 1:02 AM, Nicheal zay11...@gmail.com wrote:
Yeah, I am convinced that the filesystem inconsistencies lead to a problem.
Since in my log:
2015-01-06 00:03:06.145093 7fc6bf0c47a0 0 log [ERR] :
On Wed, 14 Jan 2015, Pavan Rallabhandi wrote:
Thanks for the reply Sage; please ignore the same subject mails on
ceph-users, they seem to have got delivered today.
Hmm, we could have a 'noagent' option (similar to noout, nobackfill,
noscrub, etc.) that lets the admin tell the system to
On 01/09/2015 08:16 AM, Sage Weil wrote:
On Fri, 9 Jan 2015, Ken Dreyer wrote:
On 01/09/2015 03:33 AM, Loic Dachary wrote:
On 09/01/2015 07:55, David Zafman wrote:
We are seeing gitbuilder failures. This is what I saw on one.
error: Failed build dependencies:
xmlstarlet is needed by
Hi,
On 14/01/2015 17:56, Ken Dreyer wrote:
On 01/09/2015 08:16 AM, Sage Weil wrote:
On Fri, 9 Jan 2015, Ken Dreyer wrote:
On 01/09/2015 03:33 AM, Loic Dachary wrote:
On 09/01/2015 07:55, David Zafman wrote:
We are seeing gitbuilder failures. This is what I saw on one.
error: Failed build
On Wed, 14 Jan 2015, Ken Dreyer wrote:
On 01/09/2015 08:16 AM, Sage Weil wrote:
On Fri, 9 Jan 2015, Ken Dreyer wrote:
On 01/09/2015 03:33 AM, Loic Dachary wrote:
On 09/01/2015 07:55, David Zafman wrote:
We are seeing gitbuilder failures. This is what I saw on one.
error: Failed
Thanks for the reply Sage; please ignore the same subject mails on ceph-users,
they seem to have got delivered today.
Hmm, we could have a 'noagent' option (similar to noout, nobackfill, noscrub,
etc.) that lets the admin tell the system to stop tiering movements, but I'm
not sure that's
Yeah, I am convinced that the filesystem inconsistencies lead to a problem.
Since in my log:
2015-01-06 00:03:06.145093 7fc6bf0c47a0 0 log [ERR] : 2.5b log bound
mismatch, info (31150'2118828,31150'2121829] actual
[31150'2118824,31150'2121829]
2015-01-06 00:03:06.596293 7fc6bf0c47a0 0 log
hugetlbfs, kernfs and dlmfs can simply use noop_backing_dev_info instead
of creating a local duplicate.
Signed-off-by: Christoph Hellwig h...@lst.de
Acked-by: Tejun Heo t...@kernel.org
---
fs/hugetlbfs/inode.c| 14 +-
fs/kernfs/inode.c | 14 +-
The first 8 patches are unchanged from the series posted a week ago and
cleans up how we use the backing_dev_info structure in preparation for
fixing the life time rules for it. The most important change is to
split the unrelated nommu mmap flags from it, but it also remove a
backing_dev_info
Now that default_backing_dev_info is not used for writeback purposes we can
git rid of it easily:
- instead of using it's name for tracing unregistered bdi we just use
unknown
- btrfs and ceph can just assign the default read ahead window themselves
like several other filesystems already
mapping-backing_dev_info will go away, so don't rely on it.
Signed-off-by: Christoph Hellwig h...@lst.de
Acked-by: Ryusuke Konishi konishi.ryus...@lab.ntt.co.jp
Reviewed-by: Tejun Heo t...@kernel.org
---
fs/nilfs2/super.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
Since BDI: Provide backing device capability information [try #3] the
backing_dev_info structure also provides flags for the kind of mmap
operation available in a nommu environment, which is entirely unrelated
to it's original purpose.
Introduce a new nommu-only file operation to provide this
If we have dirty inodes we need to call the filesystem for it, even if the
device has been removed and the filesystem will error out early. The
current code does that by reassining all dirty inodes to the default
backing_dev_info when a bdi is unlinked, but that's pretty pointless given
that the
This bdi flag isn't too useful - we can determine that a vma is backed by
either swap or shmem trivially in the caller.
This also allows removing the backing_dev_info instaces for swap and shmem
in favor of noop_backing_dev_info.
Signed-off-by: Christoph Hellwig h...@lst.de
Reviewed-by: Tejun
Now that we got rid of the bdi abuse on character devices we can always use
sb-s_bdi to get at the backing_dev_info for a file, except for the block
device special case. Export inode_to_bdi and replace uses of
mapping-backing_dev_info with it to prepare for the removal of
Since 018a17bdc865 (bdi: reimplement bdev_inode_switch_bdi()) the
block device code writes out all dirty data whenever switching the
backing_dev_info for a block device inode. But a block device inode can
only be dirtied when it is in use, which means we only have to write it
out on the final
bdi_destroy already does all the work, and if we delay freeing the
anon bdev we can get away with just that single call.
Signed-off-by: Christoph Hellwig h...@lst.de
---
fs/ceph/super.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/fs/ceph/super.c
Now that we never use the backing_dev_info pointer in struct address_space
we can simply remove it and save 4 to 8 bytes in every inode.
Signed-off-by: Christoph Hellwig h...@lst.de
Acked-by: Ryusuke Konishi konishi.ryus...@lab.ntt.co.jp
Reviewed-by: Tejun Heo t...@kernel.org
---
bdi_destroy already does all the work, and if we delay freeing the
anon bdev we can get away with just that single call.
Addintionally remove the call during mount failure, as
deactivate_super_locked will already call -kill_sb and clean up
the bdi for us.
Signed-off-by: Christoph Hellwig
Directly grab the backing_dev_info from the request_queue instead of
detouring through the address_space.
Signed-off-by: Christoph Hellwig h...@lst.de
Reviewed-by: Tejun Heo t...@kernel.org
---
fs/fs-writeback.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
On Wed 14-01-15 10:42:40, Christoph Hellwig wrote:
If we have dirty inodes we need to call the filesystem for it, even if the
device has been removed and the filesystem will error out early. The
current code does that by reassining all dirty inodes to the default
backing_dev_info when a bdi
On Wed 14-01-15 10:42:38, Christoph Hellwig wrote:
bdi_destroy already does all the work, and if we delay freeing the
anon bdev we can get away with just that single call.
Looks good. You can add:
Reviewed-by: Jan Kara j...@suse.cz
On Wed 14-01-15 10:42:39, Christoph Hellwig wrote:
bdi_destroy already does all the work, and if we delay freeing the
anon bdev we can get away with just that single call.
Addintionally remove the call during mount failure, as
deactivate_super_locked will already call -kill_sb and clean up
On Wed 14-01-15 10:42:33, Christoph Hellwig wrote:
Since 018a17bdc865 (bdi: reimplement bdev_inode_switch_bdi()) the
block device code writes out all dirty data whenever switching the
backing_dev_info for a block device inode. But a block device inode can
only be dirtied when it is in use,
On Wed 14-01-15 10:42:34, Christoph Hellwig wrote:
Directly grab the backing_dev_info from the request_queue instead of
detouring through the address_space.
Signed-off-by: Christoph Hellwig h...@lst.de
Reviewed-by: Tejun Heo t...@kernel.org
Looks good. You can add:
Reviewed-by: Jan Kara
On Wed 14-01-15 10:42:30, Christoph Hellwig wrote:
hugetlbfs, kernfs and dlmfs can simply use noop_backing_dev_info instead
of creating a local duplicate.
Looks good.
Reviewed-by: Jan Kara j...@suse.cz
Honza
Signed-off-by:
On Wed 14-01-15 10:42:31, Christoph Hellwig wrote:
This bdi flag isn't too useful - we can determine that a vma is backed by
either swap or shmem trivially in the caller.
This also allows removing the backing_dev_info instaces for swap and shmem
in favor of noop_backing_dev_info.
On Wed 14-01-15 10:42:35, Christoph Hellwig wrote:
mapping-backing_dev_info will go away, so don't rely on it.
Signed-off-by: Christoph Hellwig h...@lst.de
Acked-by: Ryusuke Konishi konishi.ryus...@lab.ntt.co.jp
Reviewed-by: Tejun Heo t...@kernel.org
---
fs/nilfs2/super.c | 4 +---
1
On Wed 14-01-15 10:42:41, Christoph Hellwig wrote:
Now that default_backing_dev_info is not used for writeback purposes we can
git rid of it easily:
- instead of using it's name for tracing unregistered bdi we just use
unknown
- btrfs and ceph can just assign the default read ahead
37 matches
Mail list logo
