On Mon, 2008-09-08 at 10:47 -0400, Chris Mason wrote:
> On Sat, 2008-09-06 at 23:43 -0600, Eric Anopolsky wrote:
> > Hi,
> >
> > A couple of questions.
> >
> > 1. Does btrfs currently have anything like raid 5 or 6?
> >
>
> Not yet, it might one day.
>
> > 2. One guy on my LUG's mailing list i
On Monday 08 September 2008 18:32:14 Ric Wheeler wrote:
> Christoph Hellwig wrote:
> > On Mon, Sep 08, 2008 at 09:49:42AM -0700, Stephen Hemminger wrote:
> >> Not to mention the problem that developers seem to have faster machines
> >> than average user, but slower than the enterprise and future ge
On Monday 08 September 2008 16:28:34 Chris Mason wrote:
> > People seem to repeatedly come up with adaptive mutex based on intuitive
> > hunch, and never do much analysis before or afterwards.
>
> In my case, it very easy to measure. Just watch the context switch rate
> on any metadata intensive w
Hello,
Space balancing creates some 'holes' in the address space, this confuses
the allocator. This patch removes all checks against the super_total_bytes.
Regards
Yan Zheng
---
diff -r 16615727163e ctree.h
--- a/ctree.h Tue Sep 09 02:16:25 2008 +0800
+++ b/ctree.h Tue Sep 09 02:16:35 2008
Hello,
This patch adds reserved extents accounting. This helps the allocator
choose block group that free extents are allocated from.
Regards
Yan Zheng
---
diff -r b5babeda93fa ctree.h
--- a/ctree.h Tue Sep 09 02:16:12 2008 +0800
+++ b/ctree.h Tue Sep 09 02:16:20 2008 +0800
@@ -499,6 +499,7
Hello,
This patch updates the space balancing code to utilize the new backref
format. By using the new format, we can walk up the reference chain and
find all references to a given extent quickly.
This patch improves the space balancing for data extents. To relocate
a data block group, there are
Christoph Hellwig wrote:
On Mon, Sep 08, 2008 at 09:49:42AM -0700, Stephen Hemminger wrote:
Not to mention the problem that developers seem to have faster machines than
average user, but slower than the enterprise and future generation CPU's.
So any tuning value seems to get out of date fast.
On Mon, Sep 08, 2008 at 09:49:42AM -0700, Stephen Hemminger wrote:
> Not to mention the problem that developers seem to have faster machines than
> average user, but slower than the enterprise and future generation CPU's.
> So any tuning value seems to get out of date fast.
So where do my fellow d
On Mon, Sep 08, 2008 at 08:07:51AM -0700, Stephen Hemminger wrote:
> The problem is that they are a nuisance. It is impossible to choose
> the right trade off between spin an no-spin, also they optimize for
> a case that doesn't occur often enough to be justified.
>
> People seem to repeatedly com
On Mon, 08 Sep 2008 12:20:32 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-09-08 at 12:13 -0400, jim owens wrote:
> > Chris Mason wrote:
> > >> My guess is that the improvement happens mostly from the first couple of
> > >> tries,
> > >> not from repeated spinning. And since it is a
On Mon, 2008-09-08 at 12:13 -0400, jim owens wrote:
> Chris Mason wrote:
> >> My guess is that the improvement happens mostly from the first couple of
> >> tries,
> >> not from repeated spinning. And since it is a mutex, you could even do:
> >
> > I started with lower spin counts, I really didn't
Chris Mason wrote:
My guess is that the improvement happens mostly from the first couple of tries,
not from repeated spinning. And since it is a mutex, you could even do:
I started with lower spin counts, I really didn't want to spin at all
but the current values came from trial and error.
Ex
On Mon, 2008-09-08 at 08:50 -0700, Stephen Hemminger wrote:
> On Mon, 8 Sep 2008 17:47:14 +0200
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Sep 08, 2008 at 08:07:51AM -0700, Stephen Hemminger wrote:
> > > On Mon, 8 Sep 2008 16:20:52 +0200
> > > Andi Kleen <[EMAIL PROTECTED]> wrote:
> > >
On Mon, 8 Sep 2008 17:47:14 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 08, 2008 at 08:07:51AM -0700, Stephen Hemminger wrote:
> > On Mon, 8 Sep 2008 16:20:52 +0200
> > Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> > >
On Mon, Sep 08, 2008 at 08:07:51AM -0700, Stephen Hemminger wrote:
> On Mon, 8 Sep 2008 16:20:52 +0200
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> > > On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > > > > The idea is to try
On Mon, 2008-09-08 at 08:07 -0700, Stephen Hemminger wrote:
> On Mon, 8 Sep 2008 16:20:52 +0200
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> > > On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > > > > The idea is to try to spin
On Mon, 8 Sep 2008 16:20:52 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> > On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > > > The idea is to try to spin for a bit to avoid scheduling away, which is
> > > > especially importa
On Sat, 2008-09-06 at 23:43 -0600, Eric Anopolsky wrote:
> Hi,
>
> A couple of questions.
>
> 1. Does btrfs currently have anything like raid 5 or 6?
>
Not yet, it might one day.
> 2. One guy on my LUG's mailing list is really excited about the
> potential for setting redundancy on a per-file
On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > > The idea is to try to spin for a bit to avoid scheduling away, which is
> > > especially important for the high levels. Most holders of the mutex
> > > let it go very quickly.
On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > The idea is to try to spin for a bit to avoid scheduling away, which is
> > especially important for the high levels. Most holders of the mutex
> > let it go very quickly.
>
> Ok but that surely should be implemented in the general mutex co
> The idea is to try to spin for a bit to avoid scheduling away, which is
> especially important for the high levels. Most holders of the mutex
> let it go very quickly.
Ok but that surely should be implemented in the general mutex code then
or at least in a standard adaptive mutex wrapper?
-An
On Mon, 2008-09-08 at 13:10 +0200, Andi Kleen wrote:
> I did some btrfs RTFS over the weeking and I have a hard time understanding
> what this code is attempting to do:
>
> 28 int btrfs_tree_lock(struct extent_buffer *eb)
> 29 {
> 30 int i;
> 31
> 32 if (mutex_trylock(&eb->m
I did some btrfs RTFS over the weeking and I have a hard time understanding
what this code is attempting to do:
28 int btrfs_tree_lock(struct extent_buffer *eb)
29 {
30 int i;
31
32 if (mutex_trylock(&eb->mutex))
33 return 0;
34 for (i = 0; i < 512
23 matches
Mail list logo
