All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: linux-raid@vger.kernel.org
Subject: Re: Direct disk access on IBM Server
Date: Thu, 21 Apr 2011 13:00:39 +0200	[thread overview]
Message-ID: <iop2oo$vs4$1@dough.gmane.org> (raw)
In-Reply-To: <BANLkTint14TBOaBqaaXrUggeJWMPShWA8A@mail.gmail.com>

On 21/04/11 05:50, Ryan Wagoner wrote:
> On Wed, Apr 20, 2011 at 7:24 AM, David Brown<david@westcontrol.com>  wrote:
>> Pros for hardware raid:
>>
>> + It can have battery backup (I don't have one at the moment - I have an
>> excellent UPS for the whole system).
>> + Rebuilds will be handled automatically by just adding new disks
>> + The card supports online resizing and reshaping
>> + It looks like the card supports caching with an SSD
>> + The card supports snapshots of the virtual drives
>
> Unless the card allows you to enable the write cache without the
> backup battery you will not see the real performance of the card. This
> option is normally locked out to prevent data loss in case the system
> crashes, power is pulled, etc. An external UPS will not protect in all
> cases if you enable the write back cache without battery.
>

The write cache is allowed without the battery, but disabled by default.

I agree that even with an UPS there is still a risk - I guess that's why 
it is disabled.  But the risk is pretty minimal for me - there is no 
realistic chance of the power plug being pulled, for example.  Other 
risks do exist - the power supply on the server may fail, the UPS may 
fail, etc.  In the end there are /always/ risks - even with a battery on 
the raid card, it won't protect against everything.  All I can do is 
reduce the risks to a realistic minimum while keeping good performance 
and features (and sensible cost!), and make sure I've got good backups 
of everything.

> I have systems with both software raid and hardware raid. If the
> budget allows I tend to go the hardware raid route. When buying a
> Dell, HP, etc server with hardware raid you end up with a complete
> package. The enclosure, card, and server monitoring software make it
> easy to manage and visually see which drive has failed.
>
> Ryan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



  reply	other threads:[~2011-04-21 11:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-19 13:21 Direct disk access on IBM Server David Brown
2011-04-19 13:25 ` Mathias Burén
2011-04-19 14:04   ` David Brown
2011-04-19 14:07     ` Mathias Burén
2011-04-19 15:12       ` David Brown
2011-04-19 15:41         ` Mathias Burén
2011-04-20  8:08           ` David Brown
2011-04-19 20:08 ` Stan Hoeppner
2011-04-20 11:24   ` David Brown
2011-04-20 11:40     ` Rudy Zijlstra
2011-04-20 12:21       ` David Brown
2011-04-21  6:24         ` Stan Hoeppner
2011-04-21 11:36           ` David Brown
2011-04-23 14:05             ` Majed B.
2011-04-23 14:42               ` David Brown
2011-04-24 12:48             ` Drew
2011-04-24 20:00               ` David Brown
2011-04-24 20:25                 ` Rudy Zijlstra
2011-04-25  9:42                   ` David Brown
2011-04-21  3:50     ` Ryan Wagoner
2011-04-21 11:00       ` David Brown [this message]
2011-04-21  4:10     ` Stan Hoeppner
2011-04-21 11:19       ` David Brown

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='iop2oo$vs4$1@dough.gmane.org' \
    --to=david.brown@hesbynett.no \
    --cc=linux-raid@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 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.