RAID 1+0 quick questions
 

Hello,

I have been reading the following tuts

http://www.howtogeek.com/51873/how-t...ver-on-ubuntu/

&

http://kamlau.com/software/how-to-se...omment-page-1/

After going over these a few times and had a few questions...
I have 4 identical drives same model which I want to raid.

1. are both of these a software raid? so does my raid controller need to support raid 10?

2. why use LVM?

3. What is the advantages of using LVM?

4. Does LVM make it easier ( say security, recovery, )

5. and have any of you ever had to replace a failed drive in a raid10 array and how did your experience go?

5a. what things did you run into ?
5b. What would you had done differently if you know what you know now?

thanks in advance.

As this isn't Slackware specific, you really shouldn't silo yourself by posting it here.

1. yes all software, no need for a controller

2, 3, 4. because it's SO much more flexible than the raid0 part of the equation. LVM adds snapshotting which is very handy for recovery etc, but moreover the flexibilty of allocating dynamic Logical Volumes rather than partitions is a VAST improvement.

Personally if you want a RAID1+0 type scenario I would suggest making independent pairs of RAID1 disks, and that joining them up with LVM2 config. recovery of an individual failed disk would not concern LVM as that would still be happily trundling along on the remaining disk of the pair.

It is actually possible to do mirroring in LVM too, so effectively giving you RAID1+0 entriely within LVM2 but I don't know how mature that part of the code is.

I try to stay true to the Keep It Simple Spirit. With 4 disks I usually configure software RAID 5 without LVM.

Here's my setup:

http://www.microlinux.fr/slackware/L...rver-HOWTO.txt

It's in French, but the Slackware bits are universal *nix lingo.

Cheers,

Niki

I agree with the KISS principle, but I prefer raid10 without LVM.
Here is my previous setup
http://www.linuxquestions.org/questi...nit-rd-930753/

I now have 4 disks and changed to GPT partitions and grub2 as bootmanager, maybe I should create a updated article if you are interested let me know.

We all know that's not what KISS stands for.

RAID5 is not that awesome, and not at all simple if it goes wrong. It feels like a wonderfully simple way to get resilience without "wasting" disks... but when it goes wrong it can be sucky to fix, and a lot is at stake. and you don't have the clarity to say that file X is on disk Y. (and of course LVM can cloud that too, but it's easier to find out.)

Great there were somethings there I still have to consider.. Which brings up a few more questions.

1. Should I use partitions or devices?

2. more of a comment than a ? .. I have a good idea about how to create the array with mdadm and preparing the disks with fdisk no problems there & making the FS and the mount point + fstab... But I really don't know anything about LVM would it be wise to add another layer of complexity since this is my first raid?

3. how about monitoring and managing the array how hard/easy is it to recover if you have a HDD byte (pun intented) the dust?

1. If you want to boot from the raid you have to use partitions. Otherwise you can use devices, but it is probably easiest to just use partitions. In my previous setup I created a raid10 from two disk devices and a partition. /dev/sda and /dev/sdb and partition /dev/sdc1 And I had a boot partition on /dev/sdc.
But currently I just use partition and because grub2 can boot from raid the setup is simpler.
I don't know what kind of partition setup you have in mind and if you want to use GPT or MBR partitions. The advantage of GPT is that you can create 128 partitions and you can label them. The downside is that windows xp can't be installed on a GPT partition. You can use some hybrid form but it isn't ideal. If you use win7 then there is no problem.
2. About LVM how often do you change partition sizes. If you only have a boot, root, home and eventually a data partition the need to resize partitions is small. And you can also resize a raid10 by breaking the mirrors. Create new partitions on 2 of the disks and create a new raid array with 2 disks missing. After copying the data from the old array to the new array you can add the old array disks as mirrors to the new array. This is definitely more work as with LVM but manageable. LVM doesn't have performance issues. So the question is do you have a need for the advantages, if not then don't use it.
3. A often overlooked item is disk scrubbing test ones or twice a month your disks for reliability.
Create a backup for unreplaceable data. Because raid is not a backup solution. Put a sticker on every disk so when one disk fails you can easily see which one it is. And replacing a failed disk is not difficult remove the failed disk add the new disk with mdadm and watch the array rebuild.
PS make a note with the commands you used to create the partition and the arrays and the commands you used to format the arrays. That can be very helpfull in case of a failure.

Thanks whizje I ran through a quick tutorial of LVM, and kind of like the idea... I don't need to resize my partition, but it seems pretty cool, and it would be fun. So lastly as far as diagnosing an array where would start there? Is it similiar to when you have a HD dying you have the dmesg & /log folder to go through and see if you can find your failure.

Thanks,

There are essentially three different ways that RAID may be done by a PC.

1. Operating System RAID (standard OS software)
2. Fake Hardware RAID (BIOS and special OS software)
3. True Hardware RAID (done completely in hardware)

Operating System (software) RAID is done by a single OS and is usually compatible only with that particular OS. Examples of software RAID are Linux RAID using LVM or Windows operating system RAID. The primary drawback of software RAID is that only the operating system that created the RAID arrays can access them. For example Linux can't access Windows RAID arrays and Windows can't access Linux RAID arrays. Since the OS essentially treats all disks the same, it is possible to have the disks of a RAID array on different controllers and even different size disks (the partitions may have to be the same size). Since the BIOS does not know how to access these RAID arrays, there are usually some limitations on booting from software RAID. For example you might have to place the boot loader or Linux kernel in a non-RAID partition.

Fake Hardware RAID uses software in the BIOS to provide RAID booting support, and a special manufacturer provided driver for each operating system. The operating system driver essentially does software RAID. Assuming that there are drivers available for all the operating systems, this kind of RAID can allow all the operating systems to access the same RAID array. The BIOS software allows booting directly from a RAID array. The performance of Fake Hardware RAID is similar to software RAID. Some fake RAID controllers have parity calculation hardware that can improve the performance a little bit over operating system software RAID. Usually Fake Hardware RAID requires all the RAID disks to be attached to the same controller, and that the disks are all the same size. It may be difficult to find drivers or software for Linux. However, in some cases a program such as "dmraid" or "mdadm" can configure Linux to access Fake Hardware RAID arrays (EX: Intel Matrix Storage Manager). There are many problems with this kind of RAID because drivers may not be kept up to date by manufacturers, and the RAID metadata format may not be supported by Linux. However, in cases where booting from RAID or multiple operating system access is required this kind of RAID can be advantageous.

True Hardware RAID is expensive because all of the RAID is done by hardware (usually a micro-controller). This usually requires an add-on board plugged into an I/O slot. Because of the cost, this kind of RAID is rare on consumer PCs. The RAID controller includes BIOS software to enable booting from RAID. The hardware RAID controller mostly looks like a normal disk controller to the operating system. The hardware takes care of all the data copying, stripes and parity calculation. There is often a standard operating system driver for a hardware RAID controller, or one is provided by the manufacturer. It is common for hardware RAID controllers to support Linux.

It all boils down to what understands the metadata. Metadata describes the layout of the RAID array, what disks are involved, and what portions of those disks. With operating system RAID, only one operating system understands the metadata. With Fake Hardware RAID, the BIOS and manufacturer-provided drivers understand that metadata. Utilities such as "dmraid" may allow Linux to understand the Fake Hardware RAID metadata. True hardware RAID avoids the need for any software to understand the metadata, since the hardware takes care of all the translation.

To choose the type of RAID to use, consider your requirements.

• Do you need to boot directly from the RAID array?
• Will multiple operating systems have to access the same array?
• Are you willing to spend extra time configuring special drivers or software such as "dmraid"?
• Do you need 64-bit support?
• Are you looking for a simple, easy to configure RAID setup?
• What kinds of RAID do you need (RAID 0, RAID 1, RAID 0+1, RAID 5, etc.)?
• What cost is acceptable?
• Do you need to decrease disk access time?
• Do you need data redundancy?

To address Slackware specifically, the operating system RAID or true hardware RAID are the best supported solutions. It is possible to use fake hardware RAID in some cases (Intel Matrix Storage Manager or some type supported by "dmraid"). Except for Intel Matrix Storage Manager RAID, you will probably need to use a 32-bit kernel for fake hardware RAID. I use Slackware 64-bit with Intel Matrix Storage Manager RAID, and I use Slackware 32-bit with a Promise fake hardware RAID controller.

If you are considering fake hardware RAID, I recommend sticking with Intel Matrix Storage Manager used on Intel ICH and other Intel chip-sets. If you can't do that, look carefully at what is supported by "dmraid". Avoid proprietary drivers because they tend to become out of date as Linux moves forward and companies abandon legacy hardware.

Here are a few of the types of RAID arrays that you can create.

• RAID 0 - 100% of total storage (performance by striping across disks)
• RAID 1 - 50% of total storage (fast redundancy using a direct mirror copy)
• RAID 0 + 1 - 50% of total storage (fast redundancy and striping for performance)
• RAID 5 - 66% of total storage (slower redundancy using parity data)

I do not recommend using RAID 5 if you are using a slow CPU or concerned about system performance. The parity calculations can slow down the CPU, and if a disk fails, accessing the missing data slows down reading. The main advantage of RAID 5 is the increase in storage capacity versus disk cost. RAID 1 may actually prove more economical, since you only need to buy two disks. Also, software RAID performs less I/O for RAID 1 than RAID 5. RAID 0+1 is theoretically faster than RAID 1, but in practice the extra I/O for two more disks can make it slower. Unless you are using a true hardware RAID controller I recommend staying with two disks (no more than three) on one computer.

Keep in mind that any kind of redundant RAID (1, 0+1 or 5) will require periodic synchronization of the data. You will want to look at the performance impact of synchronizing the data and the time required. Don't make redundant arrays larger than you need. For static data, it may be better to just do a periodic backup or copy to a standby disk rather than using redundant arrays. You also need to avoid unexpected shut-downs when using redundancy. Keep the computer on a battery backup unit. What happens if the power is interrupted? Typically the RAID software will detect that situation on the next boot and force resynchronization of the entire array. That can be annoying and time consuming. Operating system crashes have the same effect as power interruptions. True hardware RAID controllers usually have battery powered RAM to avoid losing data on sudden power interruptions.

Operating systems such as Windows and Linux use delayed writing, so for small files, write performance is less critical than read performance. Depending on how you use the computer RAID 1 may provide about the same performance as RAID 0 or RAID 0+1. If you frequently copy large files, then RAID 0 or 0+1 is likely to improve performance over RAID 1. RAID 5 might normally give you better performance than RAID 1 or even RAID 0, but it will probably perform worse when one of the disks is inoperative.

I hope some of this information is helpful. Some of it is based on my own opinions, and everyone is welcome to comment if they agree or disagree. I found the whole subject of RAID quite confusing when I started learning about it.

As for diagnosing there are three things you should setup.

-An array monitor this can be done with In case of a failure you get a email. There for you need to add a mailaddress to /etc/mdadm.conf or add an extra option You can add this line to /etc/rc.d/rc.local so it is run when you boot your pc. To get the mail you need to have a MTA like sendmail.

-An array check ones a month you can create a cron job for this.This checks /dev/md0 for read errors. You need to set this up for all your arrays. If there is a error you can try to repair it with -A full disk check ones a monthFor all your disks and a short test ones a week.And it can be beneficial to run the smartd daemon.

An extra tip create back-ups of your partition tables on a usb stick preferable a rescue boot stick with When you have to replace a drive you can then put the partition back with!!DOCUMENT EVERY STEP YOU TAKE TO CREATE THE ARRAY!!

And put this also on the usb stick. Most likely you don't need it but when you have to, it saves a lot of trouble.

succes

@Erik_FL. ...just one slight correction, Linux can actually mount Windows Raid aka dynamic disks using mdadm. Not that I'm recommending that.

Thanks for that information. It's helpful to know that for rescuing Windows RAID data.

I only wish that "mdadm" would provide some way to add user-defined metadata formats. That would allow mapping fake RAID without "mdadm" having to be changed for each new metadata format. Having Intel Matrix Storage Manager compatibility is nice, but there are always going to be other fake RAID controllers around. I've been using "dmraid" but that is not being updated for new metadata formats. It's also a problem getting 64-bit versions of "dmraid" if it isn't included with a distro. I'm not brave enough to just give the device mapper a bunch of raw disk mapping information without using metadata (if that's even possible).