2006-09-28
11:10
Why…
Posted by Luke Schierer under technical | Permalink | | Leave A Comment
oh why is there no support for the Areca raid controllers in the stock linux kernel yet? They provide source code, they have packages for a number of different distributions (and often several versions of those distributions). Support for it was in the -ac kernel back when there was a -ac kernel. Why has it not been accepted? It would make my life so much easier.
9 Responses to “Why…”
Leave a Reply
You must be logged in to post a comment.
Didn’t find areca-raid-linux-scsi-driver-update7-fix-3.patch (from Areca, I think)?
Erich Chen posted it in several spots. You can google for it, but I am not sure how clean the qz files are.
Oh, I have the source code from their FTP server, http://www.areca.com.tw/ does not make it hard to find, even though the FTP server itself is just an IP address, with no domain name. That is rather besides the point.
I need to install an RHEL4.4 system using an areca card. That is one point version newer than they support officially, though it works just fine. This means the install procedure is as follows:
At this point I am somewhat hazy, as I was sidetracked earlier today and have not in fact finished this install, I spent most of today since the last post doing other projects.
Basically, it doubles the time to install. Moreover, it means that our customers cannot simply grab an updated kernel from RH’s errata, but, having done so, must now follow directions that they will not remember if simply told, and will lose if given in file or printout form, to compile and install the additional module, and to build the custom initrd image. Which means the entire system is more fragile.
This gets compounded when you start working with diskless images to be served up for nodes.
Note that with a supported raid card, I would only be doing step 1. Yes, that is an hour long step with tons of substeps, but I am not upset about that because at an hour, it is still one of the shorter installs out there. Plus, I tend to automate that part with pxeboot images.
Hmm, thought a plug-and-play auto script was bundled inside Areca’s latest patches (at least 5). The gunzip’d version is already on removable media when we get it.
BTW, how is the diskless imaging working anyway? We can’t do it, so I’ve never had a chance to monkey around with yhe technique. You storing in v-mem? Flashing it somewhere?
The patch versions I see are standard patch files, addressing the kernel source for those building a new kernel. I could use that in place of steps 2-5 above, and would go that route on any machine I needed a custom kernel for anyway.
Building a kernel with an additional driver is not hard, once the system is installed, and assuming that I am handing this off to a customer with a clueful administrator. Some of our customers are more clueful than others though.
Most people using these cards avoid this whole issue by having an IDE or separate SATA drive for /boot (or / if /boot is not separate). If I could get away with doing that, I would not have complained about it. Though I have not seen your script, I can pretty much infer that it assumes you have taken this route. Afterall, to run a script, you have to have a running system.
I work with clusters remember, we do all sorts of things that normal people do not do.
There are a couple good routes to go wtih diskless systems, it depends on if you also want stateless or not.
One good route is the Linux Terminal Server Project, they work with Fedora systems primarily. There’s a version of this ready-to-go on an iso targeted at schools. Google should find it.
For more advanced work, you could go with Clustermatic (which I highly do not recommend, it tends to be unstable and has been abandoned by its developers), a diskless version of the OSCAR clustering system (experiemental), Warewulf clustering (that is what I am using currently for most projects), XCPU (I have not played with this one. It was not ready for use a year ago, and is developed primarily for plan9, not linux), or one of a couple others.
I’d look at warewulf. Its a funky name, but the system is fairly easy (Especially if you use centos or fedora, though I can give you the extra files you would need to do it on an RHEL system), and fairly stable.
Hmm… what sort of config is all this? We’re hosting RAID50 (I still think of it as 5+0 but whatever, I’m not a doc custodian so I won’t split the hairs)…
Controllers are 8100 cards. RAID assembled is using LVM2 config (user has to add it). Seems that hot OCE and jumpstarting isn’t that complex. Add to VG, adjust the LV (or volumes), and go. It’s pretty seemless and transparent. Doesn’t interfere with RAID action requests. In our lab there are TONS r/w exchanges happening all the time, and there has been any measurable latency.
Notes: 1 - Requires device-mapper in the kernel with support lib’s 2+1 - There ARE issues with lvm and/or ext3 I think. /boot can’t be in a logical volume (and child PVs) because the loader won’t see it. - - As far as I know, the only workaround if /boot is already in a LV is to create another boot partition on the side (kinda sucks). - - If you ask me to talk ext3 journaling and quiescing and all that, you’re SOL, I am definitely not on that level. 4 - Our RAID has never been LVM1 (and the wretched read-only snapshots) so I don’t know if there are transition issues. We can go back though (in theory) 4+1 - !!! - BTW, 32-bit proc on k2.6 equals a lot of space to write to :grin:. We’re thinking of going up to 64-bit pro’s.
Note: I’ll be aware from internet connectivity for the weekend.
lol, for work stuff you could buy some of my time from Accelerated, you all have worked with us in the past, though you were never the customer, just passing through paperwork stuff. ;-)
RAID 5+0 isn’t a bad setup. We don’t like RAID 5 because if all the disks are from the same batch, they tend to have similar failure times. And the stress of rebuilding the array can cause a second failure, which is then unrecoverable. RAID 6 is more robust if you can afford it. Still, we do use RAID 5+0 in some situations.
Right, you can’t put /boot in an LV because grub has to know where it is. But /boot typically only has to hold a few hundred MB of data anyway.
Accelerated Servers, and thus I, since I do alot of the OS installs, do all sorts of HPC and data storage computers and clusters. We specialize in data storage though.
I have not worked much with LVM. Still, once you have a kernel+initrd loaded that can handle it, it really doesn’t matter.
Basically, with any setup, you can split it into two logical sections. The OS and the Data. The OS takes a few Gb of space, typically 10-20 if you actually install to disk, but MUCH less ram to run, and even less if you go diskless. If you have enough ram per machine, say 4-8Gb/proc(or core if dual core chips), you can start thinking about diskless. This is particularly true if you still have a swap partition on each node. you can do swap over nfs, but it sucks badly. You put your OS on the ramdisk (or nfs/ramdisk hybrid, warewulf can do that)
if you are having performance issues with your IO, try mounting your partitions, replacing “defaults” with “noatime” in your /etc/fstab. You can also mess with inode size and block size and such, but that’s all done at the time you format the parition and is rather archane. I’d have to talk to Dan about it to help you beyond noatime.
The 64 bit opterons rock hard. You should definitally upgrade. You will need to reinstall the OS to take advantage of them though. Your data partitions do not need to be touched.
Do you have my business card? or cell #? You can call me tomorrow if you want to go over more on these lines.