headers
Neil Brown | 1 Aug 2005 06:22
X-Face
Picon
Picon
Favicon

Re: Multiplexed RAID-1 mode

On Sunday July 31, a1426z <at> gawab.com wrote:
> Gordon Henderson wrote: {
> On Sat, 30 Jul 2005, Jeff Breidenbach wrote:
> >
> > I just ran a Linux software RAID-1 benchmark with some 500GB SATA 
> > drives in NCQ mode, along with a non-RAID control. Details are here 
> > for those interested.
> >
> >       http://www.jab.org/raid-bench/
> 
> The results you get are about what I get on various systems - essentially
> with RAID-1 you get about the same speed as a single drive will get. 
> 
> ns1:/var/tmp# hdparm -tT /dev/md1 /dev/sda1 /dev/sdb1
> 
> /dev/md1:
>  Timing cached reads:   4116 MB in  2.00 seconds = 2058.31 MB/sec
>  Timing buffered disk reads:  174 MB in  3.00 seconds =  57.99 MB/sec
> 
> /dev/sda1:
>  Timing cached reads:   4096 MB in  2.00 seconds = 2048.31 MB/sec
>  Timing buffered disk reads:  176 MB in  3.03 seconds =  58.11 MB/sec
> 
> /dev/sdb1:
>  Timing cached reads:   4116 MB in  2.00 seconds = 2057.28 MB/sec
>  Timing buffered disk reads:  176 MB in  3.02 seconds =  58.27 MB/sec
> }
> 
> Multiplexing read/write requests would certainly improve performance ala
> RAID-0 (-offset overhead).
(Continue reading)

Permalink | Reply | 3 comments |
headers
NeilBrown | 1 Aug 2005 06:46
X-Face
Picon
Picon
Favicon

[PATCH md ] Make sure raid5/raid6 resync uses correct 'max_sectors'

I'm putting together a test-suite for mdadm and md (About time), and
it found this bug for me.  Without it, an array creating in just the
right way (i.e. the way that mdadm-v2 creates array) will resync
forever.

It would be good if this went into 2.6.13

Thanks,
NeilBrown

--

The default resync_max_sector is set to "mddev->size << 1".
If the raid-personality-module updates mddev->size, it must
update resync_max_sectors too.

Signed-off-by: Neil Brown <neilb <at> cse.unsw.edu.au>

### Diffstat output
 ./drivers/md/raid5.c     |    1 +
 ./drivers/md/raid6main.c |    1 +
 2 files changed, 2 insertions(+)

diff ./drivers/md/raid5.c~current~ ./drivers/md/raid5.c
--- ./drivers/md/raid5.c~current~	2005-08-01 14:36:10.000000000 +1000
+++ ./drivers/md/raid5.c	2005-08-01 14:36:10.000000000 +1000
 <at>  <at>  -1653,6 +1653,7  <at>  <at>  static int run (mddev_t *mddev)

 	/* device size must be a multiple of chunk size */
 	mddev->size &= ~(mddev->chunk_size/1024 -1);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Breidenbach | 1 Aug 2005 08:09
Picon

Re: Multiplexed RAID-1 mode

Hi Neil, 

Are you suggesting I do this?

mdadm --create /dev/md0 --level=10 --raid-devices=2 \
              --parity=f2 /dev/sdc1 /dev/sdd1

I just tried it and it appears dog slow - for example
hdparm -t /dev/md0 claims 18MB/s, and I see a similar 
number in /proc/mdstat for resync speed.

Getting rid of the --parity=f2 parameter, the numbers 
jump up to about 65MB/s which is similar to single drive
transfer rate.

Anyway, I haven't thoroughly benchmarked and I know hdparm
is not to be trusted, but so far it's not obvious to me level=10 
beats level=1 for a two drive array. If you think it is worth 
pursuing I will do so.

Cheers,
Jeff

PS. I care most about small (~5K) file read performance. Think
very busy webserver with hundreds of gigabytes of small files.
And an occasional medium size file of a few megabytes.
-
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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Neil Brown | 1 Aug 2005 08:23
X-Face
Picon
Picon
Favicon

Re: Multiplexed RAID-1 mode

On Monday August 1, breidenbach <at> gmail.com wrote:
> Hi Neil, 
> 
> Are you suggesting I do this?

Well, suggesting you "try" rather than "do", but yes, that is what I
was suggesting.

> 
> mdadm --create /dev/md0 --level=10 --raid-devices=2 \
>               --parity=f2 /dev/sdc1 /dev/sdd1
> 
> I just tried it and it appears dog slow - for example
> hdparm -t /dev/md0 claims 18MB/s, and I see a similar 
> number in /proc/mdstat for resync speed.

Hmm, you're right.  It isn't as fast as I expected.  I'll look into
that.

Thanks,
NeilBrown
-
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
Al Boldi | 1 Aug 2005 16:12

RE: Multiplexed RAID-1 mode

Neil Brown wrote: {
On Sunday July 31, a1426z <at> gawab.com wrote:
> 
> Multiplexing read/write requests would certainly improve performance 
> ala RAID-0 (-offset overhead).
> During reads the same RAID-0 code (+mirroring offset) could be used.
> During writes though, this would imply delayed mirroring.

But what exactly do you mean by 'delayed mirroring'?
Are you suggesting that the write request completes after only writing to
one mirror?  If so, which one?  Wouldn't this substantially reduce the value
of mirroring?
}

Think of it as a _smart_ resync running on idle.
Should be an option though!

--
Al

-
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
Forrest Taylor | 1 Aug 2005 16:30
Picon
Favicon

Re: One disk busy in RAID5?

On Sun, 2005-07-31 at 00:33, Neil Brown wrote:
> On Saturday July 30, scott-raid <at> riskboys.com wrote:
> > I'm doing a big rsync to my 5 disk RAID 5 partition and am seeing an
> > uneven loading of my disks.  The files are almost all huge video files.
> > Has anyone got any idea what I could have done wrong?
> > 
> > md6 : active raid5 sdi1[4] sdh1[3] sdg1[2] sdf1[1] sde1[0]
> >       976783360 blocks level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]
> > 
> > The filesystem is ext3 created with 
> > mkfs.ext3 -R stride=32 /dev/md6
> 
> I suggest you ask on ext3-users <at> redhat.com.
> I have seen references to this sort of thing before.  I think some
> metadata gets aligned despite the '-R stride=' flag.
> Also, I think the stride should be 128 (32 fs-blocks per chunk, 4
> chunks per stripe).
> 
> NeilBrown

Speaking of which, how does one determine the stride size?  If I do:
  mdadm -C /dev/md0 -l 5 -c 64 -n 2 /dev/sd{ab}1
  mke2fs -j -b 4096 -R stride=???  /dev/md0

What should the stride size be--64x4?  Is the default chunk size still
64K?

Thanks,

Forrest
(Continue reading)

Permalink | Reply | 0 comments |
headers
'SPOKEN ENGLISH' INGILIZCE DILI EGITIM MERKEZI | 1 Aug 2005 16:36
Picon

INGILIZCE EGITIMI YENI DONEMIMIZ HAKKINDA

 SPOKEN ENGLISH   INGILIZCE DILI EGITIM MERKEZI
Amerikali egitmenlerle birlikte yuksek egitim performansiyla
1/4 ZAMANDA   1/4 UCRETE  Kalip Ezberlemeden Egitim sistemimizle  tanismanizi öneriyoruz...
     Konusmanizi  gelistirerek Ingilizcenize akŭcilik  kazandirmanin  yani sira, Ingiliz ve Amerikan aksanlarina
 asina olarak anlama kapasitenizi artŭrmak için konusma siniflarina  katilabilirsiniz.Her seviye ve
egitim düzeyi 
için bizi mutlaka arayiniz...
    Egitim kurumumuz size gerekli çözüm imkanlari sunacaktir.
      Bilgi icin Bizi Arayin  ,,
0212 244 90 00 dan   yada  
spokenenglishtr.com-dan bize ulasabilirsiniz.
      Saygilarimizla
  'SPOKEN ENGLISH'  INGILIZCE DILI EGITIM MERKEZI

-
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
NeilBrown | 2 Aug 2005 11:53
X-Face
Picon
Picon
Favicon

[PATCH md 005 of 7] Always honour md bitmap being read from disk


The code currently will ignore the bitmap if the array seem to be
in-sync.  This is wrong if the array is degraded, and probably wrong anyway.
If the bitmap says some chunks are not in in-sync, and the superblock says
everything IS in sync, then something is clearly wrong, and it is safer
to trust the bitmap.

Signed-off-by: Neil Brown <neilb <at> cse.unsw.edu.au>

### Diffstat output
 ./drivers/md/bitmap.c |   52 ++++++++++++++++++++++----------------------------
 1 files changed, 23 insertions(+), 29 deletions(-)

diff ./drivers/md/bitmap.c~current~ ./drivers/md/bitmap.c
--- ./drivers/md/bitmap.c~current~	2005-08-02 15:23:11.000000000 +1000
+++ ./drivers/md/bitmap.c	2005-08-02 15:23:11.000000000 +1000
 <at>  <at>  -817,8 +817,7  <at>  <at>  int bitmap_unplug(struct bitmap *bitmap)
 	return 0;
 }

-static void bitmap_set_memory_bits(struct bitmap *bitmap, sector_t offset,
-	unsigned long sectors, int in_sync);
+static void bitmap_set_memory_bits(struct bitmap *bitmap, sector_t offset);
 /* * bitmap_init_from_disk -- called at bitmap_create time to initialize
  * the in-memory bitmap from the on-disk bitmap -- also, sets up the
  * memory mapping of the bitmap file
 <at>  <at>  -827,7 +826,7  <at>  <at>  static void bitmap_set_memory_bits(struc
  *   previously kicked from the array, we mark all the bits as
  *   1's in order to cause a full resync.
  */
(Continue reading)

Permalink | Reply | 0 comments |
headers
NeilBrown | 2 Aug 2005 11:53
X-Face
Picon
Picon
Favicon

[PATCH md 001 of 7] Remove a stray debugging printk.


Signed-off-by: Neil Brown <neilb <at> cse.unsw.edu.au>

### Diffstat output
 ./drivers/md/md.c |    1 -
 1 files changed, 1 deletion(-)

diff ./drivers/md/md.c~current~ ./drivers/md/md.c
--- ./drivers/md/md.c~current~	2005-08-02 15:22:11.000000000 +1000
+++ ./drivers/md/md.c	2005-08-02 15:22:11.000000000 +1000
 <at>  <at>  -3484,7 +3484,6  <at>  <at>  static void md_do_sync(mddev_t *mddev)
 			goto skip;
 		}
 		ITERATE_MDDEV(mddev2,tmp) {
-			printk(".");
 			if (mddev2 == mddev)
 				continue;
 			if (mddev2->curr_resync && 
-
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
NeilBrown | 2 Aug 2005 11:53
X-Face
Picon
Picon
Favicon

[PATCH md 006 of 7] Yet another attempt to get bitmap-based resync to do the right thing in all cases...


Firstly, R1BIO_Degraded was being set in a number of places in the
resync code, but is never used there, so get rid of those settings.

Then: When doing a resync, we want to clear the bit in the bitmap iff
the array will be non-degraded when the sync has completed.  However
the current code would clear the bitmap if the array was non-degraded
when the resync *started*, which obviously isn't right (it is for
'resync' but not for 'recovery' - i.e. rebuilding a failed drive).

This patch calculated 'still_degraded' and uses the to tell
bitmap_start_sync whether this sync should clear the corresponding
bit.

Signed-off-by: Neil Brown <neilb <at> cse.unsw.edu.au>

### Diffstat output
 ./drivers/md/raid1.c |   29 +++++++++++++++--------------
 1 files changed, 15 insertions(+), 14 deletions(-)

diff ./drivers/md/raid1.c~current~ ./drivers/md/raid1.c
--- ./drivers/md/raid1.c~current~	2005-08-02 15:23:02.000000000 +1000
+++ ./drivers/md/raid1.c	2005-08-02 15:23:16.000000000 +1000
 <at>  <at>  -897,7 +897,6  <at>  <at>  static int end_sync_read(struct bio *bio
 	if (!uptodate) {
 		md_error(r1_bio->mddev,
 			 conf->mirrors[r1_bio->read_disk].rdev);
-		set_bit(R1BIO_Degraded, &r1_bio->state);
 	} else
 		set_bit(R1BIO_Uptodate, &r1_bio->state);
(Continue reading)

Permalink | Reply | 0 comments |

Gmane