View Full Version : Dual Booting With Linux in Raid
Some new hardware of mine is throwing me for a loop. I have 2 80GB SATAs set in a striped array (0), giving a usable capacity of 152.66GB. I divided the array into 2 partitions, therefore XP shows these partitions as being about 1/2 the total capacity as they should. with XP on the first partition, and the remainding space as unused space. The problem comes when I attempt to install Linux, because Debian shows 2 drives, not partitions and the capacity of each at 82GB, which is too high, it also shows an NTFS drive of the same size below the other 2 with a zig zag arrow pointing down. I decided to check what the SuSe installation would show, it shows both of the drives, but XP as only being on SDB1 and no other freespace or partions anywhere. I should also mention that when I plugin the IDE drive, Linux only sees 1 partion on it also, despite the fact that there are 2. A friend of mine seemed to think that the problem might be due to an incompatability between Linux and the SATA raid controller on the motherboard. My old motherboard, which had a Via chipset, instead of the nForce chipset on my new mobo, did not have this problem. That same friend suggested buying a separate PCI controller, which I will do if I must, but it seems that surely this motherboard aught to be able to do the job itself. Is there a way to approach this problem that I'm not thinking of? Would it make a difference if I used another type of raid?
PeaceFaker
12-31-05, 08:28 AM
my guess is that whatever drivers the installation kernel includes does not support the raid your motherboard supplies. Motherboard raid is in many cases a semi software raid depending on windows drivers for correct operation. Using it as an additional controller should not be a problem but the raid functionality might be.
I don't know what raid controller you have nor what the status of the linux support.
It probably won't tell you much, but the raid is nForce on a Gigabyte K8 Triton (K8NSC 939). From what I have heard everyone say about this in the general sense, I thought that is would be more advance than my old Via mobo...that's why I bought it. I'm starting to have thoughts about reinstalling the old board again.
According to nVidia, who can certainly chirp-in here if they want, there are no installable drivers for Linux because direct support for NV RAID has been in the kernel for "quite some time" which means, IIRC, kernels greater than 2.6.9-12. ANY distro using ANY kernel version less than that has NO support whatsoever for what I have renamed HARM(see sig).
IF the Linux distribution uses a recent version of the Linux kernel, e.g., 2.6.9-22, it can support the HARM via dmraid (not md as most RAIDs use) for the RAID modes that Linux can support: 0, 1, 5 & 10(I don't know about the JBOD...).
The level of that support is a complete unknown as NVIDIA has not published any document that I can find which describes how the RAID support works in Linux. HARM is a FAKE RAID but because NVIDIA HIDES THAT FACT, it is unknown how much they do or do not do to assist Microsoft OS in running RAID 0, 1, 1+0, JBOD or on some *new* mobos the RAID 5. RAID 5 support was only recently added; older mobos with the nForce platform might get support through BIOS upgrade or might not. ASK nVidia or the mobo manf. directly about that. At best, I think the HARM performs parity calculations on the chipset, thereby offloading some of the more CPU intensive memory work. Whether that is of any real life benefit is also UNKNOWN because there are NO independent tests that I have seen to indicate that using the HARM as a HW+SW RAID actually increases quality(i.e., accurate & safe) throughput which is the real bottom line.
However, the problem you have described, as best as I could determine from what you wrote, is a matter of the distribution supporting dmraid (and thereby HARM) during the install. NONE do that with the possible exception of Gentoo and it is only mentioned because nobody seems to know whether one can get support for dmraid during install of Gentoo or not but there is a web page claiming it can be done with the instructions on that page. I have never tried it nor do I know of anyone who has ever claimed to have done it other than the author of that article, of course. I am sure s/he would enjoy feedback about the success/failure from anyone attempting it.
The problem boils down to support of dmraid during the install of the distribution. Mandrakelinux was working on that last year but I have no idea if the renamed company, Mandriva, continued that effort. The reason that dmraid is needed is that it supports what is known as "foreign" RAID, i.e., HW RAIDs as well as the SW RAIDs that are used by various companies. The md driver cannot do that. The md driver is what virtually all distributions use to setup and manage RAID on the distro for many years. Linux SW RAID has been around for quite a while... however the dmraid support is, in comparison to md, relatively new.
The support for dmraid requires changes to the wya the boot process is done. The is not so easy to implement but can be done. At this time, the best we can do is to test what is available so that it can be implemented universally in a streamlined manner. Sometime back (>1yr) I did see a post that someone was working on the implemenatation for Fedora also. idunno what happened on it...
I don't have the link handy but if you search this forum there is a link here for the web page describing how Gentoo gets support for dmraid during the install. Of course Google should work too ...
You can check at Man* cooker or in the Bugzilla for the dmraid support status by them. The only Debian that *might* have support would be the *buntu Deb's(Ubuntu or Kubuntu) because they use relatively recent kernels. MY personal experience indicates they do not. CentOS 4.2, which is ~ RHEL 4.2, might but I did not see it. I could report on that but while trying to get the MS support working, my mobo somewhat mysteriously died: It failed to POST after a shutdown.
I have no idea what caused it. I won't have a new one from RMA until next week...
Based upon the last couple of weeks, I would say that you will get ZERO support from nVidia on this subject. Perhaps that was because of the holidays but upon reading other much too brief replies to "Platform" problems, I think not. I think it is general nVidia standard policy to provide the shaft to Linux users as much as possible by obfuscation and ignorance. You will have better luck/answers from other non-nv forums, especially those designated for md and dmraid support.
If my mobo continues to have problems I will be exchanging it for a NON-NV platform and, by the Grace of God Almighty, be thankful that I got out from under the NV thumb by never buying another mobo with NV as the base chipset again. Foolish me thought that NV would have support for Linux because of their graphics support. I was even a bigger D! fool for believing that the platform was implementing a HW RAID solution which it does not.
HTH
fhj52,
It certainly sounds as though you are the person that I needed to hear from. You have already been around the block, and I haven't even got out the front door. I'm still digesting what you have said, so I'm not certain what I will do yet. I do still have time to return the mobo to the store, but it does have some features that I like, and it seems to work well with XP. I'm still working on some unrelated problems, but if it turns out that any of these are due to the mobo, I probably will return it. It caught my eye, where you mentioned having a motherboard die, because I have had similar problems lately. That is why I decided to try this mobo. As it turned out, I believe that the real problerm was simply some bad wiring on the power supply, but it would sometimes work and sometimes not, which caused me alot of confusion about what was happening.
The only problem with getting rid of your nForce board is that the only option that I know anything about is a Via motherboard, and these have a set of problems of their own. I have yet to figure how to setup the system on this mobo, because from what I have read, it appears that it may have a problem that has griped me with my MSI Neo2-F board. The Via system wants to use any IDE drive as a hot spare, which might be a nice idea, but what I want is for the SATAs and PATAs to function separately. The only way that I can do that, is to alternate which controller is turned off or on. If both are on at the same time, it leads to alot of potential problems.
I do have a copy of Centos 4.2, as well a couple of others. So I will experiment with each of them to see if any can see the drives and partitions properly.
If all else fails, I almost have enough parts to build a second tower, which I could dedicate to Linux. The big problem with that is that would complicate connecting the peripherals between them.
If you learn anything else along these lines, I would be all ears.
Hmm, I have now tried SuSe 10.0, Xandros 2.0.1 OCE, Kubuntu 5.04 and CentOS 4.2 in addition to the other 2 that I tried previously. All of these come up with the same results...they see the drives, but no partitions. On sda0 it sees no data, and on sda1, it sees the NTFS file system, but as though it were using the entire drive instead of half of it.
At this point, I feel like jumping on your boat, and pulling the motherboard to return to Via. I don't like Via, but at least I know how to deal with it.
This raises one more question. I have never had anything to do with it before, but would a hardware SATA Raid PCI card solve this problem...without destroying my XP installation? I'm not sure about how this Nvidia raid system works, but on my Via system, I could dismantle the raid array and still have XP operational on one drive. If Nvidia raid would do the same, then I might be able to add a separate PCI controller to both reassemble XP raid, and to install Linux raid. Any ideas about this?
A portion of the problem solved. After resetting the IDE jumper to slave, and reordering the boot sequence, SuSe 10.0 now sees the partitions on the IDE, however, not on the SATAs. I suppose that I could unplug the SATAs and reformat and install Linux on the IDE, but that would leave me with possibly a complex switching requirement to go between systems. I'm still reluctant to experiment with the SATAs, because SuSe pops a warning during setup that it detected the software raid, and that it is only sometimes sucessful with these. It did recommend either the Highpoint or Promise controllers, but I guess that a bit late to help me in selecting the motherboard.
BTW, the SuSe 10.0 kernel is 2.6.13-15
would a hardware SATA Raid PCI card solve this problem...without destroying my XP installation?
Maybe, but you'd have to add your array one drive at a time. Most RAID controllers "tag" each drive (in a boot sector) w/ some unique ID that says "this is an Adaptec RAID drive in RAID5", "this is an nVidia RAID drive in RAID1", etc. Your RAID array won't work as a RAID array until you tag it w/ your RAID controller and RAID controllers let you choose the block sizes for sectors.
You might get lucky and find a RAID controller that'll accept your RAID0 drives w/o formatting the drives for that controller...
The Areca ARC-1210 is a SATA II PCIe *complete* hardware RAID solution that it is compatible with *nix & MS Win* so it should resolve any dual system issue. The price is slightly less than 400USD to a USA door for the 4 SATA, and ~800USD for the 12 SATA(ARC-1230). There is an 8(the 1220) but I don't know the price. The ARC needs a PCIe x8 slot for full speed but will fit into PCIe x16 as well as an open-ended PCIe x4 slot and run at whatever is available from it. Throughput is reported as > 155MB/s using x8 with SATA150s.
It has been receiving extremely high reviews but after all, it is 400USD so it should. The thing is that many others cost as much or more but do not have the performance so it is good to find one that does.
There are AMD 8111 & 8132 solutions for the mobos. AMD had those solutions before(ithink) the nForce4 with the SLI solutions. There are the Crossfire solutions too.
I am no fan of VIA as they have a long hit & miss history so would probably not go that direction.
I am hoping that the new board will not have problems.
I don't have much faith there because I have since found that there are problems with the NV audio drivers and/or mixer too. ( The drivers caused instant reboot(s) when using the mixer... ) In fact, it might be possible that is what caused my system to have a SID... don't know yet.
Since SATA do not have Master/Slave relationships, it becomes a little more difficult for the BIOS or OS to recognize which is which. I am not sure why, exactly, but it is obvious that it is true.
I setup a RAID 5 during one of the first (linux) installs using the four SATA drives(3 + 1 spare). During the subsequent (linux) installations, I found that the SATA drives were recognized as software RAID with ext3 filesystems but the RAID volume type was undefined. It was somehwere about that point that I started focusing on getting the NV RAID done and, well, the rest is history, so to speak.
I do not think XP can be saved. It is, after all, a MS product. :D
But, seriously, I think that you should try to migrate the current installation over to a new installation because I do not think you could setup a new RAID that includes the current drive with XP on it. You need to ask someone with more hands on RAID experience but when I last checked on trying to do that(a year or so ago) I found that there is a method but it is risky and quite difficult. In summary, it was not worth it.
I am glad you have made some progress! Although I am sure it is not as much or the quality you desired.
I am not sure what SuSE means by their warning.I'm still reluctant to experiment with the SATAs, because SuSe pops a warning during setup that it detected the software raid, and that it is only sometimes sucessful with these.I do know that sometimes such warnings are for covering their backsides in the event something fails and end user wants to blame XYZ0 for it. It might be similar to the warning one gets prior to opening disk druid or similar product to modify the partitioning. While it is true, it is basically just a reminder that you better be very sure of what you are doing and how to do it as well as have everything backed-up to a separate location which cannot be affected by the changes(the last part being essiential). It might be worth the time to look for info about what it really means.
It sounds like you have another system. Have you considered using a KVM to share monitor, mouse and keyboard? With a crossed patch cord you can connect the two systems together directly or use the standard LAN patch cord and do it with a server/client relationship. It does have the advantage of not requiring reboots to use the other OS...
I cannot do that at this time ... power supply problems(house power) won't be resolved for a while.
Hope progress continues for you. I have to work on other things and, besides, I don't have the mobo here...
(cheers)
I seem to be running in circles on this system, and I don't know what is the problem. Last night, on rebooting XP started giving what looked like a flicker of a BSOD and rebooted again. I couldn't seem to resolve it, so I decided to install XP on the IDE drive. But it had a wild hair and decided to format the SATAs instead, so I lost everything. Not being deterred, I tried again, and then it formatted the drive that it was supposed to, so I installed XP, and afterward tried to install SuSe 10.0 on the 2nd partition of the IDE, since it seemed that the IDE was the only drive that it could see properly. That install appeared normal, but upon rebooting after the first part of the installation, it couldn't proceed. I guess that I will format it and try again, maybe with a different distro, if any of them can see the drive. What is even stranger is that when I did attempt to install XP afterward on the SATAs, the installer could not see those drives. That may be due to the fact that Windows did not get rid of everything on them as I thought, because during the SuSe install it did see these with SDB1 as containing NTFS. I deleted that and haven't had time to see what would happen now. If all of this sounds confusing, I totally agree. I have never considered myself an expert on raid systems, but I have never had problems like these.
What I need is a detailed step by step tutorial specifically for my mobo. The manual instructions is quite barebones.
I seem to be running in circles on this system, and I don't know what is the problem. Last night, on rebooting XP started giving what looked like a flicker of a BSOD and rebooted again. I couldn't seem to resolve it, so I decided to install XP on the IDE drive. uh, oh. ... But it had a wild hair and decided to format the SATAs instead, so I lost everything. Ohhhh, God. I feel your pain.
Win2k RC2 did something similar some years back. I am very sorry to hear it happened.
Not being deterred, I tried again, and then it formatted the drive that it was supposed to, so I installed XP, and afterward tried to install SuSe 10.0 on the 2nd partition of the IDE, since it seemed that the IDE was the only drive that it could see properly. That install appeared normal, but upon rebooting after the first part of the installation, it couldn't proceed. I guess that I will format it and try again, maybe with a different distro, if any of them can see the drive. My goodness, you do have persistence. Good for you! What is even stranger is that when I did attempt to install XP afterward on the SATAs, the installer could not see those drives. That may be due to the fact that Windows did not get rid of everything on them as I thought, because during the SuSe install it did see these with SDB1 as containing NTFS. I deleted that and haven't had time to see what would happen now. If all of this sounds confusing, I totally agree. I have never considered myself an expert on raid systems, but I have never had problems like these. Well, consider that it might be the first time you have ventured into the unknown. Don't be too surprised by anything that might happen with MS WinXXXX. Really! They do not have a f**g clue of what they are doing if anything is not exactly what they expect. You _must_ do it their way or no way at all. MS is a marketing organization.( and very D* good at it, I will add)
What I need is a detailed step by step tutorial specifically for my mobo. The manual instructions is quite barebones.Nada; doesn't (and won't) exist. You and everybody who uses RAID are in an extreme minority although, it does seem that RAID 0, the only RAID that is not a real RAID, has become popular with the gaming crowd because of the small performance improvement. It might get past the point of everyone running whenever the word RAID is mentioned but not anytime soon. :)
For what it might be worth:
There are conflicting points of view about whether to install MS or Linux OS first. Actually, IMHO, either way works but there are tradeoffs to each.
The best for me seems to be to install Linux and make room for MS Win* at the same time. Historically, Win* will throw a bitch-fit if it does not have the first primary partition on a drive so format the first 4GB of the first drive as FAT32 and make it a primary partition. In the past I have only used 2GB but Win* is such a hog more is better; up to ~8GB is okay(ithink).
Then install Linux on, in order of best/easiest use
(1) another (physical) drive, leaving the first drive for Win*
(2) the same drive with a /boot partition included in the partitioning scheme. Install GrUB to the /boot partition, NOT the MBR. (/boot only needs to be 50MB or so but can be larger; some Linux OS want it to be >=120MB...)
After Linux is installed and you are happy with the installation, do Win* to the first drive primary partition. Win* will recognize that there is some other OS and add it to the NTLDR. It won't do it correctly so you cannot boot to "Other Unrecognized OS" but it will be there for later modification (which can allow using NTLDR to boot to Linux).
The key to (1) is that in your BIOS you have a choice of what to boot from first. If you have different drives, one will boot to GrUB and the other will boot to the NTLDR
This relives a lot of configuration/frustration pain because you can change the BIOS to boot into the OS of choice until you get each bootloader setup *properly* so you can boot to any listed OS from either bootloader.
The real *trick* to (1), for some BIOS, is using different types of drives. Some BIOS are stupid or lazy or ...whatever... and won't allow booting from just any IDE drive because they group all IDE(PATA) together. Same for SCSI and, IIRC, for SATA. However, if you have one OS on IDE(PATA) and the other on, in your case, SATA, you can select which to use: either PATA or SATA.
I did this for years with SCSI and IDE(PATA); Works like a fr*in charm. :)
The (2) also works but there is the difficulty that after installing Win*, it will boot from the MBR and there is no way from BIOS to get GrUB. Win*, as you know, is Master of the Universe so it takes over. Mr. Bill does not care if you have any other OS and in fact wants to make your life as difficult as possible to use it. But you can give the 3-fingered salute to Bill with a little prep beforehand. There are several different instruction pages available on the web for this method but this is the only one I have readily available at the moment:
http://software.newsforge.com/article.pl?sid=05/02/15/2023237&tid=130
(AFAIK, the procedure applies to any MS Win NT OS)
( This might help you too:
http://www.linuxselfhelp.com/gnu/grub/html_chapter/grub_4.html#SEC14 )
It basically means that you need to do the dd work _before_ you install Win* so that after MS takes over your system from you, you can modify the NTLDR boot.ini to allow use of the "Unrecognized other OS" and get the system back under your control.
I cannot help you with it. I don't use it(prefer GrUB) and don't have a system here, as I mentioned before, with NV 2200/2050 on it.
One other thing that I did which you might to be able to avoid.
When I made the RAID 5 during the Linux install, I used ext3 as the filesystem. This is a good/wise thing because it is a journaling fs. However, MS, as you know, refuses to properly recognize ext3 even after the install is complete. It might be wiser to use FAT32 on at least part of the RAID and that way MS is more or less forced to recognize the SATA drives even during the install. ...
I also noticed that Win* (2k sp4, in my case) did not recognize the SATA which was resolved, mostly, by the installation of the NVIDIA SATA and RAID controller drivers, i.e., both being necessary. You will need to do that during the Win* install so prior to the Win* install, you will need to make a 3rd party drivers disk which contains the NV SATA drivers.
A real mess, huh?
Sorry that I cannot help more. Monarch Computer Systems contacted me by email today and told me the mobo sent to them was "not checked into the system" which I know is not true. It arrived yesterday at noon so I called yesterday evening for status and two different people pulled it up on the computer screen.
I probably won't be getting that mobo back - will be asking for refund if I don't get an email from FedEx tonight that the replacement is on the way. I don't expect the latter.
HTH
it does seem that RAID 0, the only RAID that is not a real RAID
I'm still digesting the rest of your post, because it seems to have some value. Parts of it are things that I already know and agree with, others I am still weighing out in my mind. Your comment about Raid 0 threw me just a bit, because the only form of raid that I knew was not really raid, is JBOD. However, a rose by any other name.... The other thing that I'm thinking about, is your discussion of using NTLDR as the boot loader. Most of the people with whom I have discussed this, seem to favor either Grub or LILO. These have caused me some problems, i.e. doing a kernel upgrade and the system tearing itself apart. I have also read some about using 3rd party bootloaders, but I still tend to use a Linux flavor. In the end, the best would be the one that is most reliable, but I do not have the experience to judge this for myself.
I found part of what I was looking for...a manual for the Gigaraid controller...but this is only for an IDE raid array, which I don't have. It has still been helpful to some extent, because I have been confused about the BIOS options for both Nvidia raid and Gigaraid. If I could find a similar manual for the Nvidia raid, I might almost understand the systems. However, even the manual that I have doesn't explain the BIOS options and configuration. If I had enough IDE HDs, I might be better off using Gigaraid, because it appears to be a hardware controller vs Nvidia raid, which is a software controller...this being significant with Linux installations.
RAID is a Redundant Array of Inexpensive Disks
RAID 0 was defined in the original document but there is no redundancy and the point was made that the reason for using a bunch of cheap disks was to avoid spending thousands of dollars protecting data with other solutions which RAID 0 does not do... It is a RAID but not a real "Redudant" AID because it just spreads the data across the disks: if one dies all is lost.
JBOD is not RAID at all.
Sorry, but if doing a kernel upgrade is tearing things up, it won't help to use NTLDR. The NTLDR boot.ini will have a line that points to that which you just changed. :(
If GrUB is affected by a kernel upgrade, the OS must have installed it to the MBR. I have done many upgrades and a few kernel builds with zero problems with GrUB. I always install it to the boot partition on the disk, not the MBR. That has to be done during the install of GrUB, of course, and it is best to have a 120MB or so /boot partition for it.
(That's a pretty big boot partiition but IIRC, RHEL complains if it is less. Using only ~ 30MB is really big enuf unless you have a bunch of kernels and/or are doing kernel hacking/building.)
It is safer there and causes fewer headaches in the long run. Also, MS OS don't screw it up(or vice-versa).
It also has the advantage that if it is on a separate disk controller, say IDE, from the MS OS boot partition(MBR) which could be on a SATA or SCSI disk, the BIOS will allow you to boot to either boot loader by choosing the appropriate disk in the BIOS. ;)
Well, I have done what I did not want to do and bought a different dual Opteron mobo that uses NV 2200 & 2050 as well as the AMD 8232. So chances are good that I will be taking a closer look at HARM in the near future. The only other option is to buy the HW controller and forget using NV RAID which I hate to do since I PAID FOR IT but sometimes one just has to cut the loss and move on. The time lost factor can become overwhelming...
There are Nvidia guides. Nvidia RAID Users guide and another(forget the name at the moment). They are pretty simple "do this and that" without many explanations. If you need to have the steps and basic explanations you can find them on Google for sure but I think NV still has them:
__ Forceware NVRaid_Users_Guide_v1.1.pdf
The newer version was renamed Media Shield:
ForceWare_MediaShield_Users_Guide_v.3.1.pdf
And a 15 page sales pitch which explains some things about the "Media Shield" NV is promoting:
01760-001_v02_MediaShield_090805.pdf
I know nothing about gigaraid. The only RAID controller I have seen in years that is tempting me is the Areca ARC 1200 series(e.g., 1210). It is a true HW SATA RAID controller with Linix, Solaris, MS and ithink even BSD drivers. It is also 400USD...
Good Luck!
fjh52,
I appreciate your response, and it would probably help me quite a bit, except that since I last posted, I had some more mobo problems, and removed it and took it back to the store. I now have another Gigabyte mobo of a different model on order (GA-K8NS Ultra-939. It has a number of differences from the previous board, ranging from a faster chipset, more SATA connections, dual BIOS, and raid controller. Instead of the Nvidia raid, it has a Silicon Image 3512 raid controller. I do not yet know if this is a softward or hardware controller, but I'm hoping the latter. I'm not sure if the Gigaraid is still available or not. I don't know if this will work with Linux, but it couldn't be any worse than what I had. If it doesn't work this time, I will probably get a hardware controller, as you suggestecd.
AFAIK, the Sil3512 is another software RAID controller where the "hardware" consists mostly of a BIOS that lets you boot off it :-P
I second the Areca if you want real RAID. Just wish the dang things were only $150 instead of $400 :-(
I said that I had a motherboard on order, but I found out this morning that my supplier could not find his supplier, so I'm still looking. I sent an email to Gigabyte to find out if that motherboard is in production, because after spending most of the day, everybody said that the board was either not in production yet, or had been dropped. I'm still persisting, because it is the only motherboard that I have been able to find that has the features that I want. Apparently, the manufacturers have been dropping their AGP boards, forcing everyone to go PCIe, but that is something that I shall not do.
Even if the Silicon Image Raid controller is run by software, maybe it can work okay...I will just have to find out for myself. I'm more than willing to accept that Areca and the other recommendations, as far as I'm concerned, are superior raid controllers, I can't spend $400 for one. Surely, there is a more affordable option that will work.
If you don't need an mATX board, you might want to look at the "server" boards that have built in SAS RAID chipsets. Motherboard makers might not be able to pull this "hardware RAID means I have a BIOS to boot into software RAID" stunt w/ customers who expect SAS RAID to work as fast as SCSI RAID :-)
If you don't need an mATX board, you might want to look at the "server" boards that have built in SAS RAID chipsets. Motherboard makers might not be able to pull this "hardware RAID means I have a BIOS to boot into software RAID" stunt w/ customers who expect SAS RAID to work as fast as SCSI RAID :-)
Outside of the fact that the board needs an ATX power plug to connect the PS, I'm not sure how ATX differs otherwise from a server board? Since I do not intend to operate a server, would this kind of motherboard deprive me of any other kind of ability?
micro-ATX boards generally aren't as full featured as ATX sized server boards. The point was to get a board w/ onboard SAS RAID instead. You can still plug SATA drives into a SAS RAID controller.
AFAIK, the Sil3512 is another software RAID controller where the "hardware" consists mostly of a BIOS that lets you boot off it :-P
I second the Areca if you want real RAID. Just wish the dang things were only $150 instead of $400 :-(I'll second that! :)
The PCI-X versions cost the same too...
I said that I had a motherboard on order, but I found out this morning that my supplier could not find his supplier, so I'm still looking. I sent an email to Gigabyte to find out if that motherboard is in production, because after spending most of the day, everybody said that the board was either not in production yet, or had been dropped. I'm still persisting, because it is the only motherboard that I have been able to find that has the features that I want.Look at the GigaByte GA-2CEWH: http://www.gigabyte.com.tw/Server/Products/Products_ServerBoard_GA-2CEWH.htm
It runs CentOS 4.2.* x64 which is same as Redhat Enterprise Linux 4.2.* without the $upport contract$. It also runs MS Win*, etc... but it is not Mandriva or (k)Unbuntu friendly since neither of them have included the recent kernel patches(apparently).
Apparently, the manufacturers have been dropping their AGP boards, forcing everyone to go PCIe, but that is something that I shall not do.I can appreciate hanging onto AGP for budget sakes but it would be a huge mistake not to move to PCIe now if you can. Nobody, and I mean nobody, is going to be using AGP in the future. It is dead. PCI is on the deathwatch too although PCI-X is probably going to make it a long painful death.
And you can add PATA to the list with SCSI not far behind. SATA is already pushing them into the extreme low-end and high-end only markets, respectively. SCSI is mostly high-end anyway...
Even if the Silicon Image Raid controller is run by software, maybe it can work okay...I will just have to find out for myself. I'm more than willing to accept that Areca and the other recommendations, as far as I'm concerned, are superior raid controllers, I can't spend $400 for one. Surely, there is a more affordable option that will work.As you and I have found out somewhat painfully, the onboard controllers are not hardware raid controllers. They do setup with the hardware and offload the work to the CPU(s). BUT there is some across platform compatibility which beats none at all if you are going to use software RAID, right?
It may come as a surprise but the Areca is actually priced below most hardware raid solutions that boast such good transfer numbers. LSI(including Dell PERC) and Adaptec are or were twice as much...
The best solution for an individual or small company without huge demands is software RAID. It is the cheapest solution too.
I have my new 2CEWH up and running but it is going to be a while before I can start on HARM (again). I'll be using CentOS 4.2 x64 and Win2k Advanced Server for testing and hopefully it will just work.
And, BTW, spending 400USD on a RAID controller is not in my budget either. Besides, I would need the ARC-1220 and it is ~700USD which is definitely not in the budget at this time. I am still having sticker shock from the mobo, CPUs and graphics card...
micro-ATX boards generally aren't as full featured as ATX sized server boards. The point was to get a board w/ onboard SAS RAID instead. You can still plug SATA drives into a SAS RAID controller.
Okay, I'll show my ignorance. I have never had a micro sized board, all of them are about 12x9.6 inches, so I guess that means that these were server sized. As far as the SAS RAID controller, from the very short glance that I took at Google, these appear to be separate controller cards...no? I'm more than a little confused about this kind of option, because I have found Raid controller available from $50 and up. But, I assume that from your and fhj52's remarks, that the low priced controller would not do the job. In the past, I have had motherboards with raid functions that worked well enough in both Windows and Linux...is that a thing of the past? In any case, I can not afford to spend $400 on this. If I were going to spend that kind of money, I could build a second tower for less, and run the two OSs on separate machines. I do understand that a person only gets what they pay for, but is this the least price for something workable?
vBulletin® v3.7.1, Copyright ©2000-2012, Jelsoft Enterprises Ltd.