I'm not gonna use lvm or mdadm.
I choose zfs.
I will probably end up buying a little server since i cannot find compatible hardware cheaper than an full server...
On Mon, 1 Feb 2016 at 04:59, Chris Murphy <lists@colorremedies.com> wrote:
On Sun, Jan 24, 2016 at 7:05 AM, Roberto Ragusa <mail@robertoragusa.it> wrote:
> On 01/22/2016 01:49 PM, thibaut noah wrote:
>> Hello, all in the title, i'm sick of loosing hours trying to get hardware working with super outdated drivers (tech support not helping) so if anyone knows a raid card compatible with raid 6 AND that will work on fedora 23 please by all means share it.
>> Price is not relevant, i can go up to 300euros/dollars if needed, i just want something that works for sure.
>
> Do not dismiss the SoftwareRAID option too easily.
> Nothing is better than SoftwareRAID in terms of reliability, data unlocking and total
> control of what's happening at your data.
> Consider that with $300 you can seriously upgrade your system and let
> it manage RAID by itself without losing performance.

The caveat is that with this level of control comes quite a bit of a
learning curve. There are lots of gotchas, possible the biggest two
are:

1. SCT ERC value per drive must be less than that of the SCSI command
timer. If this is not true the misconfiguration will prevent bad
sectors from being fixed up by md. So it's important to get either
enterprise drives that have SCT ERC already configured with ~ 7 second
recovery, or buy drives with a configurable time. 'smartctl -l scterc
<dev>' is the way to find out. Both the SCT ERC and SCSI command timer
are per device and aren't persistent. This advice applies to md/mdadm,
lvm, and Btrfs raids.

2. Separately backup mdadm.conf, and the mdadm superblock (that's
mdadm -E) for each drive.

3. Bonus, don't follow advice on the web about using mdadm -C to
recreate a broken array. Go the linux-raid@ list and ask for help
first.  Many users end up with total data loss of otherwise
recoverable arrays because they followed this absurd advice to
recreate arrays rather than force assemble.

If you are familiar with LVM, then it's got a neat edge over mdadm:
each LV can have its own raid level. So you can create linear "throw
away" LVs, or more scalable raid10 LVs, or slower but more space
efficient raid6 LVs. So if you expect to want different redundancy
levels, or make changes frequently, you might prefer LVM. But, it
still doesn't have all the features mdadm offers, so you'll want to
make a must haves list and check both out.




--
Chris Murphy
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org