headers
Dan Williams | 1 Dec 2009 01:39
Picon
Favicon

Re: [PATCH v2] ppc440spe-adma: adds updated ppc440spe adma driver

Anatolij Gustschin wrote:
> This patch adds new version of the PPC440SPe ADMA driver.
> 
> Signed-off-by: Anatolij Gustschin <agust <at> denx.de>
> Signed-off-by: Yuri Tikhonov <yur <at> emcraft.com>

[minor] Sign-offs are typically in delivery path order, so yours would 
appear last.

[..]
>  drivers/dma/ppc440spe/ppc440spe-adma.c             | 5015 ++++++++++++++++++++
>  drivers/dma/ppc440spe/ppc440spe_adma.h             |  195 +
>  drivers/dma/ppc440spe/ppc440spe_dma.h              |  223 +
>  drivers/dma/ppc440spe/ppc440spe_xor.h              |  110 +

I belong to the school of thought that says something along the lines of 
"don't duplicate the directory path in the filename".  You seem to have 
copied the iop-adma driver's inconsistent use of '-' and '_' let's not 
carry that forward, i.e. looking for a changelog like:

   drivers/dma/ppc440spe/adma.c             | 5015 ++++++++++++++++++++
   drivers/dma/ppc440spe/adma.h             |  195 +
   drivers/dma/ppc440spe/dma.h              |  223 +
   drivers/dma/ppc440spe/xor.h              |  110 +

> +/**
> + * ppc440spe_adma_prep_dma_pqzero_sum - prepare CDB group for
> + * a PQ_ZERO_SUM operation
> + */
> +static struct dma_async_tx_descriptor *ppc440spe_adma_prep_dma_pqzero_sum(
(Continue reading)

Permalink | Reply | 2 comments |
headers
Neil Brown | 1 Dec 2009 02:18
Picon
Gravatar

Re: md: oops on dropping bitmaps from an array

On Mon, 30 Nov 2009 15:00:24 +0100
Arkadiusz Miskiewicz <a.miskiewicz <at> gmail.com> wrote:

> 
> After reading
> http://etbe.coker.com.au/2008/01/28/write-intent-bitmaps/ wanted to
> check bitmaps, turned these on but
> http://blog.liw.fi/posts/write-intent-bitmaps/ caused me to do

Yes, bitmaps can slow things down.  Using a larger bitmap chunk size
can help.  mdadm-3.1.1 uses a significantly larger chunk size by
default which should help.
I just ran some fairly simple tests on a RAID5 over 5 150G drives.
The test was untaring and then removing the linux kernel source.

The old default bitmap chunksize is 512K which resulted in a slowdown of
7%-9% compared with no bitmap.
The new default size is 64MB with resulted in a slowdown or 0.3% to 2%.

So there is still a cost, but smaller.
A larger bitmap chunksize will theoretically make the resync time after
a crash a little longer, but it would still be a fraction of 1% with
this size of bitmap chunk.

Like any insurance there is a cost.
  They pay you every time your house burns down,
  You pay them every time it doesn't.

It is a question of when the cost is justified, which needs to be made
on an individual basis.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arun Jagatheesan | 1 Dec 2009 03:24
Picon

MAX IOPS - s/w scaling issues?

We are trying some experiments on our linux raid. We are having  
bottleneck in scaling the RAID after ~250K IOPS.  Is there a known  
issue of s/w max limit or is it simply an issue of configuration?

We have (16 x 64G) SSDs on a RAID0. Our IOPS on this RAID0 stops at  
250K (even with lesser or more SSD drives).    Whereas we get 540K  
IOPS with the same number of SSDs (RAW no RAID). We find a linear  
scale-up for each SSD we add to RAID0 until we reach ~250K IOPS  
limit. After the RAID0 reaches this limit, its just a straight line  
plateau with no increase in performance.

Is there any known issue of the maximum IOPS the s/w can handle?

Cheers,
Arun

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
David Rees | 1 Dec 2009 04:07
Picon

Re: MAX IOPS - s/w scaling issues?

On Mon, Nov 30, 2009 at 6:24 PM, Arun Jagatheesan
<arun.jagatheesan <at> gmail.com> wrote:
> We are trying some experiments on our linux raid. We are having bottleneck
> in scaling the RAID after ~250K IOPS.  Is there a known issue of s/w max
> limit or is it simply an issue of configuration?
>
> We have (16 x 64G) SSDs on a RAID0. Our IOPS on this RAID0 stops at 250K
> (even with lesser or more SSD drives).    Whereas we get 540K IOPS with the
> same number of SSDs (RAW no RAID). We find a linear scale-up for each SSD we
> add to RAID0 until we reach ~250K IOPS limit. After the RAID0 reaches this
> limit, its just a straight line plateau with no increase in performance.

What are the specs of the rest of the system, and was does top/vmstat look like?

-Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Majed B. | 1 Dec 2009 05:05
Picon

Re: MAX IOPS - s/w scaling issues?

Keep an eye on CPU and RAM utilization. You may be hitting a bottleneck there.

Have you tried changing the queue depth of each SSD?
This may be of interest to you: http://linux-raid.osdl.org/index.php/Performance

On Tue, Dec 1, 2009 at 5:24 AM, Arun Jagatheesan
<arun.jagatheesan <at> gmail.com> wrote:
>
> We are trying some experiments on our linux raid. We are having bottleneck in scaling the RAID after ~250K
IOPS.  Is there a known issue of s/w max limit or is it simply an issue of configuration?
>
> We have (16 x 64G) SSDs on a RAID0. Our IOPS on this RAID0 stops at 250K (even with lesser or more SSD drives).
   Whereas we get 540K IOPS with the same number of SSDs (RAW no RAID). We find a linear scale-up for each
SSD we add to RAID0 until we reach ~250K IOPS limit. After the RAID0 reaches this limit, its just a straight
line plateau with no increase in performance.
>
> Is there any known issue of the maximum IOPS the s/w can handle?
>
> Cheers,
> Arun
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
      Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Brown | 1 Dec 2009 07:55
X-Face
Picon
Gravatar

[PULL REQUEST] room for one more md patch in 2.6.32??


Hi Linus / Greg,
 While reading code I found a bug in raid1 that can cause it handle
 read errors poorly.  It can sometimes report an error to the
 filesystem when it shouldn't have done.
 This bug was introduced in 2.6.29 and the patch is suitable for any
 -stable since then that it still active.

thanks,
NeilBrown

The following changes since commit a9366e61b03f55a6e009e687ad10e706714c9907:
  Linus Torvalds (1):
        Merge git://git.infradead.org/users/dwmw2/iommu-2.6.32

are available in the git repository at:

  git://neil.brown.name/md/ for-linus

NeilBrown (1):
      md: revert incorrect fix for read error handling in raid1.

 drivers/md/raid1.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

From d0e260782c3702a009645c3caa02e381dab8798b Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb <at> suse.de>
Date: Tue, 1 Dec 2009 17:30:59 +1100
Subject: [PATCH] md: revert incorrect fix for read error handling in raid1.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Artur Wojcik | 1 Dec 2009 12:52
Picon
Favicon

Re: [patch 1/1][mdadm] Fix needed to enable RAID volumes on SAS devices (version 2).

Hi Dan,
Thank you for your comments. All you suggestions I will incorporate in
next version of a patch. Please see my comments below.

> better alternative is to use the "stg mail" command from Stacked GIT
> which, among other things, will format the patch according to akpm's
> "perfect patch" guidelines [1].

Definitely I should follow your suggestion.

> >  <at>  <at>  -899,19 +900,12  <at>  <at>  static int imsm_enumerate_ports(const char
> > *hba_path, int port_count, int host_b
> >                }
> >
> >                /* retrieve the scsi device type */
> > -               if (asprintf(&device, "/sys/dev/block/%d:%d/device/xxxxxxx", major,
> > minor) < 0) {
> > -                       if (verbose)
> > -                               fprintf(stderr, Name ": failed to allocate 'device'\n");
> > -                       err = 2;
> > -                       break;
> > -               }
> > -               sprintf(device, "/sys/dev/block/%d:%d/device/type", major, minor);
> > +               str_fmt(device, "/sys/dev/block/%d:%d/device/type", major, minor);
> 
> Admittedly this change isn't needed because asprintf has guaranteed
> that the buffer is large enough, but I can see why you made the change
> if the goal is eradication of all sprintf calls.

Yes, that is my intention and if you are ok with this I would keep it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Robinson | 1 Dec 2009 17:08
Picon

Re: md: oops on dropping bitmaps from an array

On 01/12/2009 01:18, Neil Brown wrote:
> On Mon, 30 Nov 2009 15:00:24 +0100
> Arkadiusz Miskiewicz <a.miskiewicz <at> gmail.com> wrote:
[...]
>> [2500705.083965] BUG: unable to handle kernel NULL pointer
>> dereference at
>> (null) [2500705.090142] IP: [<ffffffffa001387a>]
>> bitmap_daemon_work+0x20a/0x500
> 
> That is bad.  I think I can see what is happening.  I suspect that this
> is a fairly hard race to hit - you must been unlucky:-(

I had an oops removing a bitmap a wee while ago, and I mentioned it on 
this list, but I couldn't post a backtrace. I guess I was unlucky too 
but I'm delighted to hear luck's not going to be an issue in the future :-)

Cheers,

John.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Enigma | 1 Dec 2009 18:39

Re: RAID 6 freezing system when stripe_cache_size is increased from default

Is there nobody who can give me any additional information on this?
Executive Summary:  Machine freezes with the kernel dump below when
stripe_cache_size > 256

Please help if you can, running at 256 is killing performance.

On Thu, Nov 19, 2009 at 7:53 PM, Enigma <enigma <at> thedonnerparty.com> wrote:
> I am in the process of migrating a 8x200 GB disk RAID 6 array to a
> 8x500 disk array.  I created the array with 2 missing disks and I
> added them after the array is started.  The array synced fine at the
> default of 256 for /sys/block/md0/md/stripe_cache_size, but if I
> changed it to a higher value, for example  "echo 4096 >
> /sys/block/md0/md/stripe_cache_size" the system freezes up.  The
> previous array was running fine with a cache size of 8192.  The only
> difference between my old array and this array is I increased the
> chunk size to 512 from 256.  The machine is a dual Xeon w/
> hyperthreading, 3 GB of main memory, kernel 2.6.29.1, mdadm v2.6.7.2.
> I let the array sync at the default cache size (with fairly poor
> performance) and tested the synced array and get the same behavior
> under load.  Whenever the cache size > 256 I get the following hang:
>
> [ 1453.847111] BUG: soft lockup - CPU#3 stuck for 61s! [md0_raid5:571]
> [ 1453.863456] Modules linked in: ipv6 dm_mod iTCO_wdt intel_rng
> rng_core pcspkr evdev i2c_i801 i2c_core e7xxx_edac edac_core
> parport_pc parport containern
> [ 1453.919458]
> [ 1453.923455] Pid: 571, comm: md0_raid5 Not tainted (2.6.29.1-JJ #7) SE7501CW2
> [ 1453.943454] EIP: 0060:[<c033ec4e>] EFLAGS: 00000286 CPU: 3
> [ 1453.959453] EIP is at raid6_sse22_gen_syndrome+0x132/0x16c
> [ 1453.979454] EAX: dcca66c0 EBX: ffffffff ECX: 000006c0 EDX: dd1be000
(Continue reading)

Permalink | Reply | 1 comment |
headers
Asdo | 2 Dec 2009 11:15

Re: Help on first dangerous scrub / suggestions

Neil Brown wrote:
> If the array is marked read-only, it wont do a scrub.
>
> However if you simply don't have any filesystem mounted, then the array
> will remain 'clean' and any failures are less likely cause further
> failures.
>
> So doing it off line is a good idea, but setting the array to read-only
> won't work.
>   

Thanks for the info Neil,
would mounting the filesystems readonly be safe in the same way?
(I might try to rsync some data out during the scrub)
Thank you
Asdo
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane