On Thu, August 21, 2014 5:32 pm, GKH wrote:
Valeri,
I hope you realize that your arguments for hardware RAID all depend on everything working just right.
If something goes wrong with a disk (on HW RAID) you can't just simply take out the disk, move it to another computer and maybe do some forensics.
If the drive that is member of hardware RAID failed (say timed out while dealing with reallocation of badblock), it is kicked out of the RAID, I get notification by 3ware daemon, hot unplug the drive, hot plug in replacement (of same or larger size), and start rebuild RAID through firmware utility, or GUI interface, or controller starts RAID rebuild automatically if configured so. The system on the machine has no idea about all this and keeps running happily.
I do no forensics on failed drives. I run manufacturer drive fitness test (whichever it is called by particular manufacturer), if drive passes, I usually reuse it, if it fails test, I send it to drive manufacturer for warranty replacement or toss if it is out of warranty.
The formatting of disks on HW RAID is transparent to Linux. Therefore my disks are all RAID or not.
What if I wanted to mix and match?
With 3ware RAID controller you can export one or more of attached drives directly to the system. They can not participate in [hardware] RAID then.
Maybe I don't want my swap RAID for performance.
Speaking of swap: RAM is large and cheap these days. I do not use swap on machines with 32 GB of RAM or larger. On multitasking system you have to switch between processes, which is more often than every millisecond. Imagine now you need to swap in or out 32GB during some of the switching between processes. Your system will be on its knees just because of that. Unless you have very special block device which is almost as fast as RAM, which you better just have added to the address space of RAM (from kernel point of view), so we are not speaking of these devices as of hard drives.
The idea of taking my data (which is controlled by an OSS Operating System, Linux) and putting it behind a closed source and closed system RAID controller is appalling to me.
Me too. Yet all of us use them. Example: hard drive firmware. Which has a bit more sophisticated function than just take data and write track or other way around. It detects badblocks, reallocated them, recovers as much as possible information that was inside that bad block. Another example: video card, say, NVIDIA one. It has processors inside that run software that is flashed on its non-volatile memory. Now, with Nvidia cards sometimes you have to use proprietary driver (if you have more or less sophisticated display arrangement). Which is closed code binary driver. What you compile when you install that is just an interface between closed code driver and this particular version of kernel. And this code runs not in the card itself, but under your system. And the list goes on. Not to mention our cell phones...
The only time I was mad about firmware of some controller was one particular version of via PATA controller that had a bug which was leading to drive corruption...
It comes down to this: Linux knows where and when to position the heads of disks in order to max performance. If a RAID controller is in the middle, whatever algorithm Linux is using is no longer valid. The RAID controller is the one who makes the I/O decisions.
Yes, but... And some of what I'll say was already mentioned in this thread. You can tweak RAID controller to align stripe sizes with optimal data chunks of the drives. Furthermore, you can have cache (battery backed up), which increases device speed tremendously (30 times I saw for something particular - just off the top of my head). Of course, RAM is used as a cache for software RAID, but to the contrary to RAID controller cache RAM content vanishes with power loss. You don't seem to be the person who had to recover after [software] RAID cache loss. And _I_ definitely will not like to be the one. Hence I use hardware RAID, with optimized stripe size, and optimized filesystem block size, and with cache in RAID controller that is battery backed up. If you beat me in IO with software RAID, I will live with that. As I do not like to give up reliability. Not at as small extra cost as I have to pay for hardware RAID. (And I do not include into hardware RAID these fake "raid" cards that rely on "driver" - which are indeed software RAID cards. 3ware never fell that low to make/sell any of such junk. Somebody who knows LSI better than I do will probably say the same about them).
Again, just my 2c.
Valeri
Sorry, this is not something I want to live with.
GKH
On Thu, August 21, 2014 3:54 pm, Matt wrote:
Hate to change the conversation here but that's why I hate hardware RAID.
I love hardware RAID. 3ware more than others. In case of hardware RAID it is tiny specialized system (firmware) that is doing RAID function. In the specialized CPU (I should have called it differently) inside hardware RAID controller. Independent on the rest of computer, and needing only power to keep going. Tiny piece of code, very simple function. It is really hard to introduce bugs into these. Therefore you unlikely will have problem on device level. To find the status of the device and its components (physical drives) you always can use utility that comes from hardware vendor, you can have even web interface if it is 3ware.
If it was software RAID, Linux would always tell you what's going on.
It does. And so does hardware RAID device. And most of them (3ware in particular) do not do offline (i.e. delaying boot) check/rebuild, but they do it online (they are being operational in degraded state, and do necessary rebuild with IO present on the device, they just export themselves to Linux kernel with the warning of being degraded RAID during boot).
Software RAID, however, has a disadvantage (more knowledgeable people will correct me wherever necessary). Software RAID function is executed by main CPU. Under very sophisticated system (linux kernel), as one of the processes (even if it is real time process), on the system that is switching between processes. Therefore, RAID task for software RAID lives in much more dangerous environment. Now, if it never finishes (say, kernel panics due to something else), you get inconsistent device (software RAID one), and it is much much much harder task to bring that to to some extent consistent state than, e.g., to bring back dirty filesystem that lives on the sane device. This is why we still pay for hardware RAID devices. I do.
Just my 2c.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++