headers
Greg 'groggy' Lehey | 1 Feb 2003 03:05
Favicon

Re: comparing raid-like filesystems

On Friday, 31 January 2003 at 14:18:12 -0500, Greg A. Woods wrote:
> [ On Friday, January 31, 2003 at 10:32:22 (-0800), Jeremy C. Reed wrote: ]
>> Subject: comparing raid-like filesystems (was Re: Experimental support forATA  "RAID" volumes)
>>
>> On Thu, 30 Jan 2003, Jason R Thorpe wrote:
>>
>>> I would actually prefer to see a much lighter-weight RAID implementation
>>> in NetBSD.
>>
>> Does one exist?
>
> No freely available RAID implementation that is "much lighter-weight"
> than RAIDframe exists, at least not so far as I can discover.

I suppose it depends on what you mean by "lighter-weight".  If you're
talking about CPU load, I don't think that any of the implementations
add much to it.

> There is VINUM, but I think it's even more complex (it does full
> logical volume handling, at least in FreeBSD), and in my experience
> it is quite a bit less robust (slight mis-configurations panic the
> kernel).

There have been problems.  If you know of one that's still there, it
would be nice to hear details.

Greg
--
Finger grog <at> lemis.com for PGP public key
See complete headers for address and phone numbers
(Continue reading)

Permalink | Reply | 59 comments |
headers
Jason R Thorpe | 1 Feb 2003 03:17

Re: comparing raid-like filesystems

On Sat, Feb 01, 2003 at 12:35:45PM +1030, Greg 'groggy' Lehey wrote:

 > On Friday, 31 January 2003 at 14:18:12 -0500, Greg A. Woods wrote:
 > > [ On Friday, January 31, 2003 at 10:32:22 (-0800), Jeremy C. Reed wrote: ]
 > >> Subject: comparing raid-like filesystems (was Re: Experimental support forATA  "RAID" volumes)
 > >>
 > >> On Thu, 30 Jan 2003, Jason R Thorpe wrote:
 > >>
 > >>> I would actually prefer to see a much lighter-weight RAID implementation
 > >>> in NetBSD.
 > >>
 > >> Does one exist?
 > >
 > > No freely available RAID implementation that is "much lighter-weight"
 > > than RAIDframe exists, at least not so far as I can discover.
 > 
 > I suppose it depends on what you mean by "lighter-weight".  If you're
 > talking about CPU load, I don't think that any of the implementations
 > add much to it.

I'm mostly referring to:

	* RAIDframe's code size.  It's huge.  It's gigantic.

	* RAIDframe's over-zealous use of threads.  It makes multiple
	  context switches for each component I/O.  That's .. pathetic.

	* RAIDframe's twisty-maze of data structures.  Eek.

	* RAIDframe's multiple-implementations-of-some-things (like
(Continue reading)

Permalink | Reply | 58 comments |
headers
Greg 'groggy' Lehey | 1 Feb 2003 03:40
Favicon

Re: comparing raid-like filesystems

On Friday, 31 January 2003 at 18:17:30 -0800, Jason R Thorpe wrote:
> On Sat, Feb 01, 2003 at 12:35:45PM +1030, Greg 'groggy' Lehey wrote:
>
>> On Friday, 31 January 2003 at 14:18:12 -0500, Greg A. Woods wrote:
>>> [ On Friday, January 31, 2003 at 10:32:22 (-0800), Jeremy C. Reed wrote: ]
>>>> Subject: comparing raid-like filesystems (was Re: Experimental support forATA  "RAID" volumes)
>>>>
>>>> On Thu, 30 Jan 2003, Jason R Thorpe wrote:
>>>>
>>>>> I would actually prefer to see a much lighter-weight RAID implementation
>>>>> in NetBSD.
>>>>
>>>> Does one exist?
>>>
>>> No freely available RAID implementation that is "much lighter-weight"
>>> than RAIDframe exists, at least not so far as I can discover.
>>
>> I suppose it depends on what you mean by "lighter-weight".  If you're
>> talking about CPU load, I don't think that any of the implementations
>> add much to it.
>
> I'm mostly referring to:
>
> 	* RAIDframe's code size.  It's huge.  It's gigantic.

Hmm.  So it is.  I could 42,000 lines of code, compared to 12,000 for
Vinum.  As somebody else observed, that includes full volume manager
functionality.

> 	* RAIDframe's over-zealous use of threads.  It makes multiple
(Continue reading)

Permalink | Reply | 13 comments |
headers
Thor Lancelot Simon | 1 Feb 2003 06:24

Re: comparing raid-like filesystems

On Fri, Jan 31, 2003 at 06:17:30PM -0800, Jason R Thorpe wrote:
> 
> Let's face it, we can do better.  RAID card vendors put RAID 0,1,5
> implementations into reasonably small amounts of flash every day ..
> I mean, the firmware updates fit easily onto a floppy with lots of
> room to spare.  And then they proceed to run that firmware on i960s,
> which aren't the fastest CPUs around.

It's noteworthy that:

1) Last time I picked one of those update floppies apart, the i960
   code on it turned out to be LZW-compressed.  Is RAIDframe really
   more than 2MB of object code?

2) It's just plain *astounding* how inefficient some of those
   implementations are.  On hardware with comparable memory bandwidth
   and CPU cycles available, *and lacking hardware XOR support*, with
   the same disks, RAIDframe is often considerably faster.  I have
   never understood how some RAID vendors' firmware can consistently
   perform so poorly.

--

-- 
 Thor Lancelot Simon	                                      tls <at> rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud
Permalink | Reply | 42 comments |
headers
Jason R Thorpe | 1 Feb 2003 07:08

Re: comparing raid-like filesystems

On Sat, Feb 01, 2003 at 12:24:12AM -0500, Thor Lancelot Simon wrote:

 > 1) Last time I picked one of those update floppies apart, the i960
 >    code on it turned out to be LZW-compressed.  Is RAIDframe really
 >    more than 2MB of object code?

Regardless -- these RAID cards contain the RAID card, thread
scheduler, disk drivers, drivers for the SCSI/ATA controllers,
error logging, and configuration managment *in addition* to
the RAID software.

 > 2) It's just plain *astounding* how inefficient some of those
 >    implementations are.  On hardware with comparable memory bandwidth
 >    and CPU cycles available, *and lacking hardware XOR support*, with
 >    the same disks, RAIDframe is often considerably faster.  I have
 >    never understood how some RAID vendors' firmware can consistently
 >    perform so poorly.

I guess you haven't run RAIDframe on a system with expensive context
switches.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 0 comments |
headers
Daniel Carosone | 1 Feb 2003 08:28
Picon

Re: Mozilla Mail with SA?

On Fri, Jan 31, 2003 at 01:50:45PM +0100, Frank Kardel wrote:

> The thread seems to crawl a bit when the
> mouse is moved - but that may also be wishful thinking.

Not just wishful thinking.  If I close all other mozilla windows
and leave just the mail one there, before it tries to connect, it
will stop. Mouse movement (events) will make the progressbar/animated
box thing move over. Stop the mouse, stop the animation. Move the
mouse in steps, step the animation. And so on.  It doesn't seem to
actually make any real progress, just animate stuff, so it's probably
just tickling a drawing thread.

Maybe the real thread it's waiting on has unexpectedly died?

While this is going on, ps -s shows mozilla with thre lwps, two in
"select" and the other in sawait - which is what it shows when its
working fine too.

Just in case it helps anyone figure out what's going on.  Don't
really know how to gather more useful info.

--
Dan.
Permalink | Reply | 5 comments |
headers
Jukka Marin | 1 Feb 2003 09:04
Picon

Re: comparing raid-like filesystems

On Sat, Feb 01, 2003 at 12:24:12AM -0500, Thor Lancelot Simon wrote:
> 2) It's just plain *astounding* how inefficient some of those
>    implementations are.  On hardware with comparable memory bandwidth
>    and CPU cycles available, *and lacking hardware XOR support*, with
>    the same disks, RAIDframe is often considerably faster.  I have
>    never understood how some RAID vendors' firmware can consistently
>    perform so poorly.

I have no experience of the RAID controllers, but I'm not particularly
happy with the NetBSD RAIDframe implementation.  I bought fast disks,
configured RAID - and found out that RAID drops the performance to a
fraction of that of the disks.

I don't know why, because when RAID is 100% busy, CPU load is almost
zero and the disk load 25% or so.  It's like if RAIDframe had some
usleep() calls in the code to make things go slower..

  -jm
Permalink | Reply | 40 comments |
headers
Jaromir Dolecek | 1 Feb 2003 09:23
Picon

Re: comparing raid-like filesystems

Greg 'groggy' Lehey wrote:
> One of the things on my tuit queue is to port Vinum to NetBSD

I don't think anyone is really interested in Vinum on NetBSD
(obviously, I might be wrong ;)
RF has proven very reliable and fast enough, and I don't think
it's particularily useful to introduce different heavy-weight
software RAID implementation, with Vinum-unique set of issues.

OTOH, I've never seen any benchmark comparing RF and Vinum.
It would be interesting to compare their performance on same
hardware.

Well, I'm not the one to implement software RAID (at least don't
have any immediate plans to ;). But I personally would only consider
something different to RF if it's clearly much better designed and
implemented. Whether Vinum would qualify as such I don't know.

I'm very happy RF user. Obviously I'm not going to switch
to anything else unless it's clearly superiour. Which Vinum
is not, AFAIK.

Jaromir
--

-- 
Jaromir Dolecek <jdolecek <at> NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-
(Continue reading)

Permalink | Reply | 12 comments |
headers
NetBSD source update | 1 Feb 2003 09:37
Picon

triweekly CVS update output


Updating release-1-5 src tree (netbsd-1-5):

Updating release-1-5 tar files:
src/top-level: collecting...pax: Unable to access src/BUILDING <No such file or directory>
pax: Unable to access src/UPDATING <No such file or directory>
pax: Unable to access src/build.sh <No such file or directory>
pax: WARNING! These file names were not selected:
src/BUILDING
src/UPDATING
src/build.sh
 replacing... done
src/bin: collecting... replacing... done
src/crypto: collecting... replacing... done
src/dist: collecting... replacing... done
src/distrib: collecting... replacing... done
src/doc: collecting...pax: Unable to access src/doc <No such file or directory>
pax: WARNING! These file names were not selected:
src/doc
 replacing... done
src/etc: collecting... replacing... done
src/games: collecting... replacing... done
src/gnu: collecting... replacing... done
src/include: collecting... replacing... done
src/lib: collecting... replacing... done
src/libexec: collecting... replacing... done
src/regress: collecting... replacing... done
src/rescue: collecting...pax: Unable to access src/rescue <No such file or directory>
pax: WARNING! These file names were not selected:
src/rescue
(Continue reading)

Permalink | Reply | 0 comments |
headers
Antti Kantee | 1 Feb 2003 10:08
Picon
Picon

Re: comparing raid-like filesystems

On Sat Feb 01 2003 at 10:04:25 +0200, Jukka Marin wrote:
> I have no experience of the RAID controllers, but I'm not particularly
> happy with the NetBSD RAIDframe implementation.  I bought fast disks,
> configured RAID - and found out that RAID drops the performance to a
> fraction of that of the disks.
> 
> I don't know why, because when RAID is 100% busy, CPU load is almost
> zero and the disk load 25% or so.  It's like if RAIDframe had some
> usleep() calls in the code to make things go slower..

What's your stripe unit size? I also was suffering from inexplainable
slowness until I dropped the stripe unit size to 16 sectors. Before that
my RAID5 gave something like 5MB/s write speeds, now it's giving more
than 25MB/s.

--

-- 
Antti Kantee <pooka <at> iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
                 "connoisseurs do not chill their malts."
Permalink | Reply | 39 comments |

Gmane