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.
next prev parent 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