From: Mark Nipper <nipsy@bitgnome.net>
To: Bill Rees <wsrees@gmail.com>
Cc: reiserfs-list@namesys.com
Subject: Re: Bad Hardware / Software Disk Detection for Production Systems
Date: Fri, 2 Jun 2006 07:40:45 -0500 [thread overview]
Message-ID: <20060602124045.GC16113@king.bitgnome.net> (raw)
In-Reply-To: <8bdd70ae0606020521o177b840eya5580b511f3526a3@mail.gmail.com>
On 02 Jun 2006, Bill Rees wrote:
> This is a general question but I thought I'd post it to the list to see if
> anyone has any suggestions.
You cannot expect any sort of data integrity if you are
using JBOD mode on a RAID controller. The very nature of JBOD
means that any time a single drive fails, you lose every
partition across that entire JBOD volume.
If your file systems are even coming back after such a
catastrophe, you have been extremely fortunate to date. I still
cannot imagine that you aren't losing data though since there is
no mirroring going on whatsoever which means blocks are
inherently being lost during such failures.
If you are just looking for read performance, you should
seriously consider at least a RAID 1 volume. If you can
sacrifice some overall performance, you will get the best space
optimization by going with a RAID 5. Anything more exotic than
that, you should start at:
---
http://en.wikipedia.org/wiki/Redundant_array_of_independent_disks
and go with whichever level of RAID makes the most sense for your
application.
The bottom line is, you are going to lose data in a JBOD
array (unless you also happen to be doing some sort of software
RAID on top of that). There is really no gain through some sort
of software trick to try to avoid the data loss. SMART enabled
hard drives may occasionally warn you of an imminent failure, but
then again, they may not. Drives will just occasionally fail
entirely without any warning, hence the whole purpose of RAID
levels above 0.
--
Mark Nipper e-contacts:
832 Tanglewood Drive nipsy@bitgnome.net
Bryan, Texas 77802-4013 http://nipsy.bitgnome.net/
(979)575-3193 AIM/Yahoo: texasnipsy ICQ: 66971617
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GG/IT d- s++:+ a- C++$ UBL++++$ P--->+++ L+++$ !E---
W++(--) N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--)
Y+ PGP t+ 5 X R tv b+++@ DI+(++) D+ G e h r++ y+(**)
------END GEEK CODE BLOCK------
---begin random quote of the moment---
Anyone who is capable of getting themselves made President
should on no account be allowed to do the job.
-- Douglas Adams, _The Hitchhiker's Guide to the Galaxy_
----end random quote of the moment----
next prev parent reply other threads:[~2006-06-02 12:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-02 12:21 Bad Hardware / Software Disk Detection for Production Systems Bill Rees
2006-06-02 12:40 ` Mark Nipper [this message]
2006-06-02 13:10 ` Bill Rees
2006-06-02 16:47 ` Hans Reiser
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=20060602124045.GC16113@king.bitgnome.net \
--to=nipsy@bitgnome.net \
--cc=reiserfs-list@namesys.com \
--cc=wsrees@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.