From: Hubert Tonneau <hubert.tonneau@fullpliant.org>
To: linux-kernel@vger.kernel.org
Subject: The missing RAID level
Date: Tue, 20 Apr 2004 19:50:07 GMT [thread overview]
Message-ID: <045P8FJ12@server5.heliogroup.fr> (raw)
Assuming that I want to do long term archiving (many many gigabytes of datas,
but tiny load) on disks, the cheapest and easiest solution nowdays seems to
connect large 300 GB IDE disks through USB 2 to a comodity PC.
Now the problem is how to best recover from some disks failure ?
For the production storage, I use software RAID 5 on internal disks, but
for huge external ones, it might no more be a good idea, because of two
reasons:
. having several disks failure is more likely
. in case of a catastrophy, I would like to be abble to recover at least some
of the datas, so no RAID at all is better that RAID 5 since I have DVD
backups and what I want to optimise is operator time
So, one very interesting possibility would be to have an extra RAID level that
would do the following:
assuming that you connect 5+1 partitions, then you get 5 md partitions, not a
single one, with the following properties:
. any read to mdX goes straight forward to reading the underlying partition.
. any write goes staight forward to writting the underlying partition, but also
updates the parity on the extra partition.
So, at the expense of slow write capabilities, which is not a problem for long
term archiving, I get a system with very interesting properties not covered by
existing Linux software RAID levels:
. in case of one disk failure, I can plug a new one, then rebuild just as with
classical RAID
. in case of more disk failures, I only loose part of the archives (so spend
less operator time for recovery from DVD).
. all partitions can be read just through ignoring the RAID details, so it is
possible to unplug any of disks and connect it sowehere else with no extra
constrains
. adding or removing disks from the raidset is trivial: just rebuild the parity
partition
On the 'use what's available instead of requesting new features' side, I'm also
interested with feedback from users using large (8 to 16 SATA disks) external
cheap (anything that raises the price for 8 disk from 8 x 350 euro to more than
16 x 360 euro is no solution since clustering is then the way to go) towers that
would make RAID 5 a resonable solution, and how they connect to the Linux kernel
(each disk seen individualy, RAID handled by the contoler, need for a driver
outside the stock kernel, etc)
Regards,
Hubert Tonneau
next reply other threads:[~2004-04-20 22:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-20 19:50 Hubert Tonneau [this message]
2004-04-21 21:04 ` The missing RAID level Eric D. Mudama
[not found] ` <fa.eu3v38b.10meq3@ifi.uio.no>
2004-04-21 21:52 ` Junio C Hamano
2004-04-22 2:54 ` H. Peter Anvin
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=045P8FJ12@server5.heliogroup.fr \
--to=hubert.tonneau@fullpliant.org \
--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