Hi all! I've been pondering some options for how to set up my next SUSE system, and have come to the conclusion that software RAID would most likely serve my needs best. I've only had non-RAIDed, "regular" desktop systems till now, since the days of SuSE 8.0 or thereabout, but have of late become fed up with the reliability issues the typical IDE/SATA drives suffer from and the stress test they pose on one's backup policies. So now that I've decided to have my next box assembled for me from components I select, I've also decided to discard the traditional "one or two primary disks + a backup disk" approach; as despite how often or well I backup, if, or rather when, the disk where the OS lies dies, there's awfully lot of trouble and work anyway. I first looked at SCSI disks as a more reliable alternative -- if a disk can withstand server-level I/O for a few years, it sure as hell will stand up to anything I can throw at it on my humble desktop -- but there still exists a single point of failure unless I RAID-1 two decent-sized SCSI disks. This, with the controllers etc., would be very expensive, at least based on my I've seen thus far. The SCSI drives are also said to be noisy beasts -- a no-no for a desktop at which I will have to spend quite a few hours every day. Next I read about RAID controllers and the possibility of putting a few standard SATA disks into one, thus gaining fault tolerance for simple hardware failures (i.e. a disk dies). Of course, a RAID won't help against other kinds of data loss, such as the power supply's failing and killing other components with some mighty spike; or from fire, or flood, or what ever. That is OK. That's why I backup. Next I learnt that decent RAID controllers are supposedly very expensive. Worse, some people have reported of the controllers themselves breaking down unexpectedly, taking with them all the disks or, with luck, simply failing to function correctly, having to be replaced. The hardware controlled RAID is, so I learnt, often incompatible with other controllers, requiring it to be replaced with one from the same manufacturer or even with the exact same model which may or may not still be readily available, keeping the system down till one is found. This seemed more difficult than I had anticipated. However, based on what I last read about software RAIDs, it seems I actually need not make this more difficult than it has to be. I do not need performance but mere reliability. It seems the Linux software RAID would be able to provide this. I'd like to know if I've understood this correctly, and whether the proposed-below setup would work as expected on the to-be openSUSE 11.1 system. (I've also considered Enterprise Desktop for longer support, but the base system is getting a tad old while the next version won't still be out anytime soon, I'd think. Luckily the regular 11.1 will still include KDE 3.5) So, I would acquire for the system, say, four disk, three of which would be "online" as a RAID-1 setup at any given time, representing together a single virtual disk with x number of partitions, seen by the system as a single block device, while the fourth could sit as an online spare disk that upon the Linux RAID's learning of one disk's failure, would become online as part of the array and would be integrated / reconstructed accordinly. A fifth disk could be kept offline as a spare disk for the one that would get removed, and thus becoming the new online spare disk, and so forth. Or I could have just an offline spare disk that I would insert in the failed one's place during a power off, after which I would have it partitioned as necessary and have it then become part of the RAID array and to be reconstructed. And all would be well again and peace would reign. If this is indeed true, and based on what I read at openSUSE's guide on this at http://en.opensuse.org/How_to_install_SUSE_Linux_on_software_RAID it should be, will it matter at all what kind of (SATA) disks I use for the array as long as they all meet the minimum disk size as dictated by the virtual disk they present? In other words, may I combine disks from different manufacturers, with different specs, etc. without affecting the RAID somehow negatively? I.e. the disks need not be identical; this would be preferred to avoid an unlikely-but-not-unheard-of situation where a defect is shared by a batch of drives from the same manufacturer; or that they wear down the exact same speed and fail close to one another, etc. If one disk is slower than the others, will it impose the speed limit onto the RAID virtual block device? Meaning, that all disks will have to return some kind of "I/O done" before the Linux RAID will request further I/O? (Seems most logical for reliability.) On the other hand, replacing disks later with larger capacity ones will cause no problem as they only need to meet the minimum size criterion. Hence, I could replace them one-by-one such that each new disk, replacing a removed old one, is first let to fully integrate/reconstruct; finally, after all disk have been replaced, I could enlarge a partition or two, for example, as allowed by the new shared minimum, thus increasing the capacity of the virtual device that is being RAIDed. And there would, of course, be regular other backup routines in place, such as rsyncing the RAIDed block device to an external disk via USB/Firewire etc. Also, I presume the kernel would not mind a non-RAIDed internal SATA disk(s) being part of the system as well. Would it be possible to have two separate RAID arrays? (as long as all the disk can be connected and there is space and power available...) Is it really true that the system may still boot gracefully after the disk where the MBR was dies and is replaced during a power down? How exactly will this work -- is the MBR too mirrored on all disks? To me this kind of setup seems now the most convenient one, especially with the guide available on how to install openSUSE with a software RAID and how to monitor it. I'd presume there would be no other benefits in going for SCSI over this except better performance? I also believe hardware RAID controllers would only improve performance, too, while possessing no other relevant factors affecting typical desktop use? It seems I could get five or six 320GB SATA drives for the price of a single 146GB SCSI one, and I would need at least two of those for RAID-1 and a controller too, and extra capacity elsewhere. A lot of money, that is, with no improvement in reliability, it would seem, as three or four SATA's in a RAID with spare disks at hand would seem quite enough despite however unlucky I happened to be with picking the disks. One more question: Will I be able to access each disk's (that make the RAID) SMART data still with hdparm or even though the system would see them as a single block device? (Or so I presume, as they share the same mount points) I'd like to hear if the general ideas and arguments made above are more or less correct. I'm not going to order my new system just yet -- it is still a few weeks away at minimum, as is 11.1 too, I think -- but I'd like to think these issues through well beforehand. Thanks for all comments! Regards, Tero Pesonen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org