From: Daniel Pocock <daniel@pocock.com.au>
To: Hubert Kario <hka@qbs.com.pl>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs RAID with RAID cards (thread renamed)
Date: Fri, 18 May 2012 16:19:05 +0000 [thread overview]
Message-ID: <4FB67679.3040205@pocock.com.au> (raw)
In-Reply-To: <1494795.CqqnWfNEaS@bursa22>
>> - if a non-RAID SAS card is used, does it matter which card is chosen?
>> Does btrfs work equally well with all of them?
>
> If you're using btrfs RAID, you need a HBA, not a RAID card. If the RAID
> card can work as a HBA (usually labelled as JBOD mode) then you're good to
> go.
>
> For example, HP CCISS controllers can't work in JBOD mode.
Would you know if they implement their own checksumming, similar to what
btrfs does? Or if someone uses SmartArray (CCISS) RAID1, then they
simply don't get the full benefit of checksumming under any possible
configuration?
I've had a quick look at what is on the market, here are some observations:
- in many cases, IOPS (critical for SSDs) vary wildly: e.g.
- SATA-3 SSDs advertise up to 85k IOPS, so RAID1 needs 170k IOPS
- HP's standard HBAs don't support high IOPS
- HP Gen8 SmartArray (e.g. P420) claims up to 200k IOPS
- previous HP arrays (e.g. P212) support only 60k IOPS
- many vendors don't advertise the IOPS prominently - I had to Google
the HP site to find those figures quoted in some PDFs, they don't quote
them in the quickspecs or product summary tables
- Adaptec now offers an SSD caching function in hardware, supposedly
drop it in the machine and all disks respond faster
- how would this interact with btrfs checksumming? E.g. I'm guessing
it would be necessary to ensure that data from both spindles is not
cached on the same SSD?
- I started thinking about the possibility that data is degraded on
the mechanical disk but btrfs gets a good checksum read from the SSD and
remains blissfully unaware that the real disk is failing, then the other
disk goes completely offline one day, for whatever reason the data is
not in the SSD cache and the sector can't be read reliably from the
remaining physical disk - should such caching just be avoided or can it
be managed from btrfs itself in a manner that is foolproof?
How about the combination of btrfs/root/boot filesystems and grub? Can
they all play nicely together? This seems to be one compelling factor
with hardware RAID, the cards have a BIOS that can boot from any drive
even if the other is offline.
next prev parent reply other threads:[~2012-05-18 16:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 22:01 btrfs RAID with enterprise SATA or SAS drives Daniel Pocock
2012-05-10 19:58 ` Hubert Kario
2012-05-18 16:19 ` Daniel Pocock [this message]
2012-05-11 2:18 ` Duncan
2012-05-11 16:58 ` Martin Steigerwald
2012-05-14 8:38 ` Duncan
2014-07-09 14:48 ` Martin Steigerwald
2014-07-10 2:10 ` Russell Coker
2014-07-10 8:27 ` Martin Steigerwald
2014-07-10 11:28 ` Austin S Hemmelgarn
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=4FB67679.3040205@pocock.com.au \
--to=daniel@pocock.com.au \
--cc=hka@qbs.com.pl \
--cc=linux-btrfs@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;
as well as URLs for NNTP newsgroup(s).