Hi
I tried the branch on one of my ceph osd, and there is a big difference
in the performance.
The average request size stayed high, but after around a hour the kernel
crashed.
IOstat
http://pastebin.com/xjuriJ6J
Kernel trace
http://pastebin.com/SYE95GgH
-martin
Am 23.01.2012 19:50,
On Tue, Jan 24, 2012 at 08:15:58PM +0100, Martin Mailand wrote:
Hi
I tried the branch on one of my ceph osd, and there is a big
difference in the performance.
The average request size stayed high, but after around a hour the
kernel crashed.
IOstat
http://pastebin.com/xjuriJ6J
Kernel
Hi Chris,
great to hear that, could you give me a ping if you fixed it, than I can
retry it?
-martin
Am 24.01.2012 20:40, schrieb Chris Mason:
On Tue, Jan 24, 2012 at 08:15:58PM +0100, Martin Mailand wrote:
Hi
I tried the branch on one of my ceph osd, and there is a big
difference in the
On Fri, Jan 20, 2012 at 01:13:37PM +0100, Christian Brunner wrote:
As you might know, I have been seeing btrfs slowdowns in our ceph
cluster for quite some time. Even with the latest btrfs code for 3.3
I'm still seeing these problems. To make things reproducible, I've now
written a small test,
On Mon, Jan 23, 2012 at 01:19:29PM -0500, Josef Bacik wrote:
On Fri, Jan 20, 2012 at 01:13:37PM +0100, Christian Brunner wrote:
As you might know, I have been seeing btrfs slowdowns in our ceph
cluster for quite some time. Even with the latest btrfs code for 3.3
I'm still seeing these
As you might know, I have been seeing btrfs slowdowns in our ceph
cluster for quite some time. Even with the latest btrfs code for 3.3
I'm still seeing these problems. To make things reproducible, I've now
written a small test, that imitates ceph's behavior:
On a freshly created btrfs filesystem
Hi Sage,
I did some testing with btrfs-unstable yesterday. With the recent
commit from Chris it looks quite good:
Btrfs: force unplugs when switching from high to regular priority bios
However I can't test it extensively, because our main environment is
on ext4 at the moment.
Regards
2011/7/28 Marcus Sorensen shadow...@gmail.com:
Christian,
Have you checked up on the disks themselves and hardware? High
utilization can mean that the i/o load has increased, but it can also
mean that the i/o capacity has decreased. Your traces seem to
indicate that a good portion of the
On Thu, 28 Jul 2011, Christian Brunner wrote:
When I look at the latencytop results, there is a high latency when
calling btrfs_commit_transaction_async. Isn't async supposed to
return immediately?
It depends. That function has to block until the commit has started
before returning in the
Christian,
Have you checked up on the disks themselves and hardware? High
utilization can mean that the i/o load has increased, but it can also
mean that the i/o capacity has decreased. Your traces seem to
indicate that a good portion of the time is being spent on commits,
that could be waiting
Hi,
we are running a ceph cluster with btrfs as it's base filesystem
(kernel 3.0). At the beginning everything worked very well, but after
a few days (2-3) things are getting very slow.
When I look at the object store servers I see heavy disk-i/o on the
btrfs filesystems (disk utilization is
Excerpts from Christian Brunner's message of 2011-07-25 03:54:47 -0400:
Hi,
we are running a ceph cluster with btrfs as it's base filesystem
(kernel 3.0). At the beginning everything worked very well, but after
a few days (2-3) things are getting very slow.
When I look at the object store
12 matches
Mail list logo
