Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Dec 1999 21:26:08 -0600 (CST)
From:      Jay Nelson <noslenj@swbell.net>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        chat@FreeBSD.ORG
Subject:   Re: dual 400 -> dual 600 worth it?
Message-ID:  <Pine.BSF.4.05.9912102024270.306-100000@acp.swbell.net>
In-Reply-To: <199912110128.SAA19053@usr02.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
I've pruned the cc list so people dont have to read this twice.

On Sat, 11 Dec 1999, Terry Lambert wrote:

[snip]

>Soft updates speak to the ability to stall dependent writes
>until they either _must_ be done, or until they no longer are
>relevent.  It does this as a strategy for ordering the metadata
>updates (other methods are DOW - Delayed Ordered Writes - and
>synchronous writing of metadata... in decreasing order of
>performance).

It's this ability to delay and gather writes that prompted the
question. If a SCSI bus can handle 8-12MB with tagged queuing and
UltraDMA can do 30MB while blocking, where do the performance lines
cross -- or do they? As the number of spindles go up, I would expect
SCSI to outperform IDE -- but on a single drive system, do writes to
an IDE at UDMA speeds block less than gathered writes to a drive on a
nominally slower SCSI bus?

[snip]

>So the very short answer to the question is "on a multi-applicaiton
>server, using soft updates doesn't mean that you wouldn't benefit
>from interleaving your I/O".

Hmm... that suggests you also might not. On a single drive system 
with soft updates, would an Ultra IDE perform worse, on par or better
than SCSI with a light to moderate IO load?

>To speak to Brett's issue of RAID 5, parity is striped across
>all disks, and doing parity updates on one stripe on one disk
>will block all non-interleaved I/O to all other areas of the
>disk; likewise, doing a data write will prevent a parity write
>from completing for the other four disks in the array.

I have seen reletavely few benefits of RAID 5. Performance sucks
relative to mirroring across separate controllers and until you reach
10-12 drives, the cost is about the same. I never thought about the
parity, though. Now that I have, I like RAID 5 even less.

>This effectively means that, unless you can interleave I/O
>requests, as tagged command queues do, you are much worse off.

Applying that to the single drive IDE vs. SCSI question suggests that,
even with higher bus burst speeds, I'm still lkely to end up worse
off, depending on load, than I would with SCSI -- soft updates
not withstanding. Is that correct?

>As to the issue of spindle sync, which Brett alluded to, I
>don't think that it is supported for IDE, so you will be
>eating a full rotational latency on average, instead of one
>half a rotational latency, on average: (0 + 1)/2 vs. (1 + 1)/2.

I think that just answered my earlier question.

>Rod Grimes did some experimentation with CCD and spindle sync
>on SCSI devices back when CCD first became capable of mirroring,
>and has some nice hard data that you should ask him for (or dig
>it out of DejaNews on the FreeBSD news group).

Thanks -- I'll look them up. And -- I appreciate your answer. I
learned quite a bit from it. It did raise the question of differences
between soft updates and lfs -- but I'll save that for another time.

-- Jay



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9912102024270.306-100000>