-threaded tests.
I took a look at 1MB O_DIRECT writes, and the latencies of sending off
checksumming to the checksum threads seem to be the biggest problem. I
get full tput at 8MB O_DIRECT writes, so for now I'm going to leave this
one alone.
Updated performance results are available. Ran both
Chris Mason wrote:
On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote:
Only bit of bad news is I did get one error that crashed the system
on single threaded nocow run. So that data point is missing.
Output below:
I hope I've got this fixed. If you pull from the master branch of
On Thu, Sep 17, 2009 at 01:39:01PM -0500, Steven Pratt wrote:
Eric Whitney wrote:
Chris Mason wrote:
On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote:
Only bit of bad news is I did get one error that crashed the system
on single threaded nocow run. So that data point is
[ crashes on runs involving unmounts ]
The run is still going here, but it has survived longer than before.
I'm trying with Yan Zheng's patch:
From: Yan Zheng zheng@oracle.com
Date: Fri, 11 Sep 2009 16:11:19 -0400
Subject: [PATCH] Btrfs: improve async block group caching
This patch gets rid
On Thu, Sep 17, 2009 at 04:17:14PM -0400, Chris Mason wrote:
[ crashes on runs involving unmounts ]
The run is still going here, but it has survived longer than before.
I'm trying with Yan Zheng's patch:
From: Yan Zheng zheng@oracle.com
Date: Fri, 11 Sep 2009 16:11:19 -0400
Subject:
Chris Mason wrote:
On Thu, Sep 17, 2009 at 04:17:14PM -0400, Chris Mason wrote:
[ crashes on runs involving unmounts ]
The run is still going here, but it has survived longer than before.
I'm trying with Yan Zheng's patch:
From: Yan Zheng zheng@oracle.com
Date: Fri, 11 Sep 2009
Steven Pratt wrote:
Chris Mason wrote:
On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote:
Only bit of bad news is I did get one error that crashed the system
on single threaded nocow run. So that data point is missing.
Output below:
I hope I've got this fixed. If you pull
On Wed, Sep 16, 2009 at 12:57:22PM -0500, Steven Pratt wrote:
Steven Pratt wrote:
Chris Mason wrote:
On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote:
Only bit of bad news is I did get one error that crashed the system
on single threaded nocow run. So that data point is missing.
Chris Mason wrote:
On Wed, Sep 16, 2009 at 12:57:22PM -0500, Steven Pratt wrote:
Steven Pratt wrote:
Chris Mason wrote:
On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote:
Only bit of bad news is I did get one error that crashed the system
on single threaded
Chris Mason wrote:
On Wed, Sep 16, 2009 at 12:57:22PM -0500, Steven Pratt wrote:
Steven Pratt wrote:
Chris Mason wrote:
On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote:
Only bit of bad news is I did get one error that crashed the system
on single threaded
On Wed, Sep 16, 2009 at 01:15:12PM -0500, Steven Pratt wrote:
Chris Mason wrote:
On Wed, Sep 16, 2009 at 12:57:22PM -0500, Steven Pratt wrote:
Steven Pratt wrote:
Chris Mason wrote:
On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote:
Only bit of bad news is I did get one error that
On Wed, Sep 16, 2009 at 01:16:56PM -0500, Steven Pratt wrote:
Chris Mason wrote:
On Wed, Sep 16, 2009 at 12:57:22PM -0500, Steven Pratt wrote:
Steven Pratt wrote:
Chris Mason wrote:
On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote:
Only bit of bad news is I did get one error that
Chris Mason wrote:
On Wed, Sep 16, 2009 at 01:16:56PM -0500, Steven Pratt wrote:
Chris Mason wrote:
On Wed, Sep 16, 2009 at 12:57:22PM -0500, Steven Pratt wrote:
Steven Pratt wrote:
Chris Mason wrote:
On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt
On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote:
Only bit of bad news is I did get one error that crashed the system
on single threaded nocow run. So that data point is missing.
Output below:
I hope I've got this fixed. If you pull from the master branch of
btrfs-unstable there
On Fri, Sep 11, 2009 at 04:35:50PM -0500, Steven Pratt wrote:
Chris Mason wrote:
On Mon, Aug 31, 2009 at 12:49:13PM -0500, Steven Pratt wrote:
Better late than never. Finally got this finished up. Mixed bag on
this one. BTRFS lags significantly on single threaded. Seems
unable to keep IO
On Mon, Sep 14 2009, Chris Mason wrote:
On Fri, Sep 11, 2009 at 04:35:50PM -0500, Steven Pratt wrote:
Chris Mason wrote:
On Mon, Aug 31, 2009 at 12:49:13PM -0500, Steven Pratt wrote:
Better late than never. Finally got this finished up. Mixed bag on
this one. BTRFS lags significantly on
On Mon, Sep 14, 2009 at 04:41:48PM -0500, Steven Pratt wrote:
Chris Mason wrote:
On Fri, Sep 11, 2009 at 04:35:50PM -0500, Steven Pratt wrote:
Chris Mason wrote:
On Mon, Aug 31, 2009 at 12:49:13PM -0500, Steven Pratt wrote:
Better late than never. Finally got this finished up. Mixed bag on
On Mon, Aug 31, 2009 at 12:49:13PM -0500, Steven Pratt wrote:
Better late than never. Finally got this finished up. Mixed bag on
this one. BTRFS lags significantly on single threaded. Seems
unable to keep IO outstanding to the device. Less that 60% busy on
the DM device, compared to 97%+
HI,
Do you have any benchmarks against non-raid common workloads?
Like say a desktop user? It would be great to compare against ext3,
ext4, xfs etc.,
Thanks,
On Thu, Aug 6, 2009 at 2:05 AM, Chris Masonchris.ma...@oracle.com wrote:
On Tue, Jul 28, 2009 at 04:10:41PM -0500, Steven Pratt wrote:
debian developer wrote:
HI,
Do you have any benchmarks against non-raid common workloads?
Like say a desktop user? It would be great to compare against ext3,
ext4, xfs etc.,
Yes, have had a little trouble with that box recently, but plenty of
results based on the 2.6.29 kernels here:
On Fri, Aug 07, 2009 at 08:56:52AM -0500, Steven Pratt wrote:
Chris Mason wrote:
On Tue, Jul 28, 2009 at 04:10:41PM -0500, Steven Pratt wrote:
Hi Steve,
I think I'm going to start tuning something other than the
random-writes, there is definitely low hanging fruit in the large file
creates
On Tue, Jul 28, 2009 at 04:10:41PM -0500, Steven Pratt wrote:
Hi Steve,
I think I'm going to start tuning something other than the
random-writes, there is definitely low hanging fruit in the large file
creates workload ;) Thanks again for posting all of these.
Sure, no problem.
The
Chris Mason wrote:
On Tue, Jul 28, 2009 at 03:12:38PM -0500, Steven Pratt wrote:
Chris Mason wrote:
On Fri, Jul 24, 2009 at 09:24:07AM -0400, Chris Mason wrote:
Sure, will try to get to it tomorrow.
Sorry, I missed a fix in the experimental branch. I'll push out a
On Thu, Jul 23, 2009 at 05:04:49PM -0500, Steven Pratt wrote:
Chris Mason wrote:
On Thu, Jul 23, 2009 at 01:35:21PM -0500, Steven Pratt wrote:
I have re-run the raid tests with re-creating the fileset between
each of the random write workloads and performance does now match
the
Chris Mason wrote:
On Fri, Jul 24, 2009 at 09:24:07AM -0400, Chris Mason wrote:
Sure, will try to get to it tomorrow.
Sorry, I missed a fix in the experimental branch. I'll push out a
rebased version in a few minutes.
Ok, the rebased version is ready to use.
I have re-run the raid tests with re-creating the fileset between each
of the random write workloads and performance does now match the
previous newformat results. The bad news is that the huge gain that I
had attributed to the newformat release, does not really exist. All of
the previous
On Thu, Jul 23, 2009 at 01:35:21PM -0500, Steven Pratt wrote:
I have re-run the raid tests with re-creating the fileset between each
of the random write workloads and performance does now match the
previous newformat results. The bad news is that the huge gain that I
had attributed to
27 matches
Mail list logo
