public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nico Dummer <Nico.Dummer@Informatik.FH-Hamburg.de>
To: linux-kernel@vger.kernel.org
Subject: Re: write/read cache raid5
Date: Sat, 13 Oct 2001 15:14:39 +0200	[thread overview]
Message-ID: <3BC83E3F.6010203@Informatik.FH-Hamburg.de> (raw)
In-Reply-To: <Pine.LNX.4.40.0110082309400.28345-100000@ddx.a2000.nu> <E15qhyE-0001ws-00@the-village.bc.nu>

Alan Cox wrote:

>>>protected, battery backed, ECC'd etc. That is one place where things like
>>>the DPT (now Adaptec) millenium hardware raid can do a lot better than
>>>software solutions

>>So there is no way i can Speedup write to the raid5 array ?
>>(memory will be ecc and the server will be on ups)

> And you have no ECC on the PCI bus, nor will a UPS protect against a crash.

You have this Problem anyway with or without Writecaching, the only 
difference is that it will exist longer with Writecaching turned on than 
without it.

Something to think about:

A possible Solution for this Problem is to get 2 Raid5 Arrays, a Primary 
Array for fast writing and a Secondary for fast reading.
All incoming Data will be written to a Rambuffer and the Primary Array 
while Reads are handled by the Secondary (or by the Rambuffer for Data 
not written to the Secondary). In times with fewer load on the Secondary 
Array the Data can be written from Rambuffer to it.
The Data is save at the Point where it´s on the Primary Array while you 
have unblocked Performance for Reads, in case of a crash the Secondary 
Array need to be synced with the Primary.
A list with unsynced blocks can replace the Writebuffer to take more 
Cachebuffers for Reads and so reduce load on the Secondary Array that 
can be used for syncing.
You will get the Security of 1 Raid5 Array if the Data is unsynced and 
the Security of a mirrored Raid5 Array during low load times so the 
Money wont be completely wasted only for Performance.
Would be nice if you guys consider Writecaching as an Option for this 
configuration too if most possible Security isnt needed or can be low 
for a few Seconds between buffering and writing. Let the People choose, 
they will do the right decision for themselves.


  reply	other threads:[~2001-10-13 13:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E15qh8U-0001o8-00@the-village.bc.nu>
2001-10-08 21:10 ` write/read cache raid5 raid
2001-10-08 21:17   ` Alistair Riddell
2001-10-09  3:15     ` David Chow
2001-10-09  9:06       ` Alistair Riddell
2001-10-08 21:29   ` Alan Cox
2001-10-13 13:14     ` Nico Dummer [this message]
2001-10-08 12:01 raid

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BC83E3F.6010203@Informatik.FH-Hamburg.de \
    --to=nico.dummer@informatik.fh-hamburg.de \
    --cc=Nico.Dummer@T-Online.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox