headers
Raz Ben-Jehuda(caro | 1 Apr 2007 01:03
Picon

Re: raid5 write performance

On 3/31/07, Bill Davidsen <davidsen <at> tmr.com> wrote:
> Raz Ben-Jehuda(caro) wrote:
> > Please see bellow.
> >
> > On 8/28/06, Neil Brown <neilb <at> suse.de> wrote:
> >> On Sunday August 13, raziebe <at> gmail.com wrote:
> >> > well ... me again
> >> >
> >> > Following your advice....
> >> >
> >> > I added a deadline for every WRITE stripe head when it is created.
> >> > in raid5_activate_delayed i checked if deadline is expired and if
> >> not i am
> >> > setting the sh to prereadactive mode as .
> >> >
> >> > This small fix ( and in few other places in the code) reduced the
> >> > amount of reads
> >> > to zero with dd but with no improvement to throghput. But with
> >> random access to
> >> > the raid  ( buffers are aligned by the stripe width and with the size
> >> > of stripe width )
> >> > there is an improvement of at least 20 % .
> >> >
> >> > Problem is that a user must know what he is doing else there would be
> >> > a reduction
> >> > in performance if deadline line it too long (say 100 ms).
> >>
> >> So if I understand you correctly, you are delaying write requests to
> >> partial stripes slightly (your 'deadline') and this is sometimes
> >> giving you a 20% improvement ?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bill Davidsen | 1 Apr 2007 04:16

Re: raid5 write performance

Raz Ben-Jehuda(caro) wrote:
> On 3/31/07, Bill Davidsen <davidsen <at> tmr.com> wrote:
>> Raz Ben-Jehuda(caro) wrote:
>> > Please see bellow.
>> >
>> > On 8/28/06, Neil Brown <neilb <at> suse.de> wrote:
>> >> On Sunday August 13, raziebe <at> gmail.com wrote:
>> >> > well ... me again
>> >> >
>> >> > Following your advice....
>> >> >
>> >> > I added a deadline for every WRITE stripe head when it is created.
>> >> > in raid5_activate_delayed i checked if deadline is expired and if
>> >> not i am
>> >> > setting the sh to prereadactive mode as .
>> >> >
>> >> > This small fix ( and in few other places in the code) reduced the
>> >> > amount of reads
>> >> > to zero with dd but with no improvement to throghput. But with
>> >> random access to
>> >> > the raid  ( buffers are aligned by the stripe width and with the 
>> size
>> >> > of stripe width )
>> >> > there is an improvement of at least 20 % .
>> >> >
>> >> > Problem is that a user must know what he is doing else there 
>> would be
>> >> > a reduction
>> >> > in performance if deadline line it too long (say 100 ms).
>> >>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Engelhardt | 1 Apr 2007 14:19
Picon

raid1 does not seem faster

Hello list,

normally, I'd think that combining drives into a raid1 array would give 
me at least a little improvement in read speed. In my setup however, 
this does not seem to be the case.

14:16 opteron:/var/log # hdparm -t /dev/sda
 Timing buffered disk reads:  170 MB in  3.01 seconds =  56.52 MB/sec
14:17 opteron:/var/log # hdparm -t /dev/md3
 Timing buffered disk reads:  170 MB in  3.01 seconds =  56.45 MB/sec
(and dd_rescue shows the same numbers)

The raid array was created using
# mdadm -C /dev/md3 -b internal -e 1.0 -l 1 -n 2 /dev/sd[ab]3

Jan
--

-- 
-
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
Al Boldi | 1 Apr 2007 14:58

Re: raid1 does not seem faster

Jan Engelhardt wrote:
> normally, I'd think that combining drives into a raid1 array would give
> me at least a little improvement in read speed. In my setup however,
> this does not seem to be the case.
>
> 14:16 opteron:/var/log # hdparm -t /dev/sda
>  Timing buffered disk reads:  170 MB in  3.01 seconds =  56.52 MB/sec
> 14:17 opteron:/var/log # hdparm -t /dev/md3
>  Timing buffered disk reads:  170 MB in  3.01 seconds =  56.45 MB/sec
> (and dd_rescue shows the same numbers)

The problem is that raid1 one doesn't do striped reads, but rather uses 
read-balancing per proc.  Try your test with parallel reads; it should be 
faster.

You could use raid10, but then you loose single-disk-image compatibility.

Thanks!

--
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
Henrik Holst | 1 Apr 2007 14:27

Re: raid1 does not seem faster

On Sun, 2007-04-01 at 14:19 +0200, Jan Engelhardt wrote:
> Hello list,
> 
> 
> normally, I'd think that combining drives into a raid1 array would give 
> me at least a little improvement in read speed. In my setup however, 
> this does not seem to be the case.
> 
> 14:16 opteron:/var/log # hdparm -t /dev/sda
>  Timing buffered disk reads:  170 MB in  3.01 seconds =  56.52 MB/sec
> 14:17 opteron:/var/log # hdparm -t /dev/md3
>  Timing buffered disk reads:  170 MB in  3.01 seconds =  56.45 MB/sec
> (and dd_rescue shows the same numbers)
> 
> The raid array was created using
> # mdadm -C /dev/md3 -b internal -e 1.0 -l 1 -n 2 /dev/sd[ab]3
> 
> 
> Jan

>From section 9.5 in [FAQ]

"To check out speed and performance of your RAID systems, do NOT use
hdparm. It won't do real benchmarking of the arrays." <snip>

I might recommend bonnie++. I think I've seen accepted benchmarks here
using bonnie++.

[FAQ] http://tldp.org/HOWTO/html_single/Software-RAID-HOWTO/#s9
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Williams | 2 Apr 2007 01:08
Picon
Favicon

Re: raid5 write performance

On 3/30/07, Raz Ben-Jehuda(caro) <raziebe <at> gmail.com> wrote:
> Please see bellow.
>
> On 8/28/06, Neil Brown <neilb <at> suse.de> wrote:
> > On Sunday August 13, raziebe <at> gmail.com wrote:
> > > well ... me again
> > >
> > > Following your advice....
> > >
> > > I added a deadline for every WRITE stripe head when it is created.
> > > in raid5_activate_delayed i checked if deadline is expired and if not i am
> > > setting the sh to prereadactive mode as .
> > >
> > > This small fix ( and in few other places in the code) reduced the
> > > amount of reads
> > > to zero with dd but with no improvement to throghput. But with random access to
> > > the raid  ( buffers are aligned by the stripe width and with the size
> > > of stripe width )
> > > there is an improvement of at least 20 % .
> > >
> > > Problem is that a user must know what he is doing else there would be
> > > a reduction
> > > in performance if deadline line it too long (say 100 ms).
> >
> > So if I understand you correctly, you are delaying write requests to
> > partial stripes slightly (your 'deadline') and this is sometimes
> > giving you a 20% improvement ?
> >
> > I'm not surprised that you could get some improvement.  20% is quite
> > surprising.  It would be worth following through with this to make
(Continue reading)

Permalink | Reply | 1 comment |
headers
Casey Boone | 2 Apr 2007 01:13
Picon

raidtools to mdadm

ok so i am trying to recover some data for a friend.  what i am wanting 
to do is forcibly set up /dev/mdN to be a raid0 of /dev/sda and /dev/sdb

i do not want to actually change any of the contents of these drives, 
just mount very simply as a raid0.  the raid was originally created 
using an onboard nvidia raid on the motherboard these drives used to be 
hooked to.  my friend thought he could shove them into another windows 
box (that is what he was running on them) and have windows recover the 
raid.  all this did was totally destroy the superblock on one of the two 
drives.  dmraid now wont see them as a matched pair so that is out.  the 
actual data areas of both drives seems to be intact, but unless i can 
get them into raid0 i dont know how i can recover the data.  it figures 
he gives me the drives after he makes it a notch or two more of a pain :\

now before the advent of mdadm i would use /etc/raidtab and have no 
issues setting up the raid device.

as best i can tell i am using the correct commands for what i want but i 
pretty much get nothing but errors:

root <at> Knoppix:/media# mdadm --build /dev/md1 --chunk=128 --level=0 
--raid-devices=2 /dev/sda /dev/sdb
mdadm: error opening /dev/md1: No such device or address
root <at> Knoppix:/media# mdadm --build -n 2 -c 128 -l 0 /dev/md1 /dev/sda 
/dev/sdb
mdadm: error opening /dev/md1: No such device or address

when i run those commands i do get /dev/mdN entries created, but they do 
not point to a valid block device (as tested with fdisk -l and with 
dmraid -b)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Neil Brown | 2 Apr 2007 02:07
X-Face
Picon
Gravatar

Re: raidtools to mdadm

On Sunday April 1, caseyboone <at> gmail.com wrote:
> as best i can tell i am using the correct commands for what i want but i 
> pretty much get nothing but errors:
> 
> root <at> Knoppix:/media# mdadm --build /dev/md1 --chunk=128 --level=0 
> --raid-devices=2 /dev/sda /dev/sdb
> mdadm: error opening /dev/md1: No such device or address

"No such device or address" probably means that the md module is not
loaded. 
  modprobe md
or
  modprobe md_mod

and try again.

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
Jan Engelhardt | 2 Apr 2007 02:15
Picon

raid10 kernel panic on sparc64

Hi,

just when I did
# mdadm -C /dev/md2 -b internal -e 1.0 -l 10 -n 4 /dev/sd[cdef]4
(created)
# mdadm -D /dev/md2
Killed

dmesg filled up with a kernel oops. A few seconds later, the box
locked solid. Since I was only in by ssh and there is not (yet) any
possibility to reset it remotely, this is all I can give right now,
the last 80x25 screen:

l4: 0000000000000000 l5: 0000000000000000 l6: 0000000000000000
l7: 0000000000000i0: fffff8007f218d18 i1: fffff8002e3d9608
i2: 000000000047f974 i3: 0000000000000i4: 0000000000000000
i5: 00000000006e2800 i6: fffff80008c12a41 i7: 0000000000526
I7: <elv_next_request+0x94/0x188>
Caller[00000000005263e8]: elv_next_request+0x94/0x188
Caller[0000000010086618]: scsi_request_fn+0x60/0x3f4 [scsi_mod]
Caller[0000000000529b70]: __generic_unplug_device+0x34/0x3c
Caller[000000000052a7d4]: generic_unplug_device+0x14/0x2c
Caller[0000000000526e48]: blk_backing_dev_unplug+0x20/0x28
Caller[00000000004a464c]: block_sync_page+0x64/0x6c
Caller[000000000047f9d0]: sync_page+0x64/0x74
Caller[0000000000677e48]: __wait_on_bit_lock+0x58/0x90
Caller[000000000047f86c]: __lock_page+0x54/0x5c
Caller[00000000004802ec]: do_generic_mapping_read+0x204/0x49c
Caller[0000000000480d68]: __generic_file_aio_read+0x120/0x18c
Caller[0000000000481fdc]: generic_file_read+0x70/0x94
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Miller | 2 Apr 2007 05:13
Favicon

Re: raid10 kernel panic on sparc64

From: Jan Engelhardt <jengelh <at> linux01.gwdg.de>
Date: Mon, 2 Apr 2007 02:15:57 +0200 (MEST)

> just when I did
> # mdadm -C /dev/md2 -b internal -e 1.0 -l 10 -n 4 /dev/sd[cdef]4
> (created)
> # mdadm -D /dev/md2
> Killed
> 
> dmesg filled up with a kernel oops. A few seconds later, the box
> locked solid. Since I was only in by ssh and there is not (yet) any
> possibility to reset it remotely, this is all I can give right now,
> the last 80x25 screen:

Unfortunately the beginning of the OOPS is the most important part,
that says where exactly the kernel died, the rest of the log you
showed only gives half the registers and the rest of the call trace.

Please try to capture the whole thing.

Please also provide hardware type information as well, which you
should give in any bug report like this.
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" 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