Re: brainstorm: intermediate disk caching

2001-05-30 Thread Gordon Tetlow
I'm struck by the old axiom: You can have it fast. You can have it reliable. You can have it cheap. But you can only have 2 of the 3. If you figure out how to get all 3. Call me. -gordon On Mon, 28 May 2001, Wilko Bulte wrote: On Mon, May 28, 2001 at 04:31:17PM +, E.B. Dreger wrote:

Re: brainstorm: intermediate disk caching

2001-05-30 Thread Karsten W. Rohrbach
Matthew Jacob([EMAIL PROTECTED])@2001.05.28 09:54:28 +: Ah. You want to reinvent the drum? matt, when i recall it right, someone told me about a paper presented at usenix about logging to a single disk which is exactly the thing that would do the job here. it was, i think, discussed in a

brainstorm: intermediate disk caching

2001-05-28 Thread E.B. Dreger
Greetings all, I just had a brainstorm... I was thinking about database servers with several spindles in a RAID 5 array. Write performance is inherently disappointing -- which may or may not be an issue. Would it be worth the trouble to design an intermediate cache, whereby data are quickly

Re: brainstorm: intermediate disk caching

2001-05-28 Thread Matthew Jacob
Ah. You want to reinvent the drum? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message

Re: brainstorm: intermediate disk caching

2001-05-28 Thread Dominic Marks
Hi, (I'm geussing the 'public+spam' bit is standard removal stuff) On Mon, May 28, 2001 at 04:31:17PM +, E.B. Dreger wrote: array. Write performance is inherently disappointing -- which may or may In my opinion this is the same as how MFS when used without limitation can also be a bad

Re: brainstorm: intermediate disk caching

2001-05-28 Thread Christoph Sold
E.B. Dreger schrieb: Greetings all, I just had a brainstorm... I was thinking about database servers with several spindles in a RAID 5 array. Write performance is inherently disappointing -- which may or may not be an issue. It is. Even RAID 1 is better than RAID 5

Re: brainstorm: intermediate disk caching

2001-05-28 Thread E.B. Dreger
Date: Mon, 28 May 2001 19:49:40 +0200 From: Christoph Sold [EMAIL PROTECTED] My gut feel is that this would be more trouble than it's worth, would not net any overall performance*reliability (expressed as a product) gain, and that one might actually realize a p*r decrease. IMHO it would

Re: brainstorm: intermediate disk caching

2001-05-28 Thread E.B. Dreger
Date: Mon, 28 May 2001 17:54:24 +0100 From: Dominic Marks [EMAIL PROTECTED] [ snip ] disc caching. The idea of perhaps caching writes onto a RAID-0 system I meant caching onto an arbitrary volume, probably using a simple journalling filesystem. Personally, a RAID 1 volume would be my

Re: brainstorm: intermediate disk caching

2001-05-28 Thread Wilko Bulte
On Mon, May 28, 2001 at 04:31:17PM +, E.B. Dreger wrote: Greetings all, I just had a brainstorm... I was thinking about database servers with several spindles in a RAID 5 array. Write performance is inherently disappointing -- which may or may not be an issue. Would it be worth

Re: brainstorm: intermediate disk caching

2001-05-28 Thread David Scheidt
On Mon, 28 May 2001, E.B. Dreger wrote: : :Of course, with 36 GB drives readily available, maybe I shouldn't worry :until I have a database larger than 72 GB. ;-) If you're really interested in database performance, remember Spindles is good. Spreading your IO load over as many seperate disks,

Re: brainstorm: intermediate disk caching

2001-05-28 Thread E.B. Dreger
Date: Mon, 28 May 2001 19:01:37 -0500 (CDT) From: David Scheidt [EMAIL PROTECTED] [ snip ] If you're really interested in database performance, remember Spindles is good. Spreading your IO load over as many seperate disks, on as many independent IO channels as practical will improve

Re: brainstorm: intermediate disk caching

2001-05-28 Thread Mike Smith
Date: Mon, 28 May 2001 19:01:37 -0500 (CDT) From: David Scheidt [EMAIL PROTECTED] [ snip ] If you're really interested in database performance, remember Spindles is good. Spreading your IO load over as many seperate disks, on as many independent IO channels as practical will