One of the things I think I did wrong (or "ASUS M3A78-EM & SATA Drives")
 

I've setup OpenSuSE 11.0 with SAMBA 3.2.5, and have it working as a file server. I'm running it on a dedicated machine with the ASUS M3A78-EM motherboard and an AMD Athlon 6400. It has 5 SATA connections and a single IDE (where the DVD-ROM is connected). I've got my operating system on an 80 GB dedicated drive, with 4 250 GB drives configured in OpenSuSE as a RAID5 array (Don't ask me about using the SB700 chipset on the motherboard - that was DEFINITELY a mistake).

I have the system able, and ready, to use as a file server, but have only COPIED enough data off our desktop machines to know that it will allow us to use it in the way we need, with no surprises due to bad permissions or hidden access. However, I have not MOVED any data to the system, and I could easily empty my Glock 20 (.40 caliber) into the machine, physically destroying every component beyond recovery, and none of my data would be hurt, only destroying easily and cheaply replaceable hardware. So, a complete rebuild will be a really simple feat. And, I'm planning on doing one within the next two weeks so that I can document the "tweaks" that have been required to get each of us access and proper permissions & rights from our individual desktops. This system is to be our home/family file & print server, tho it will eventually also house the data files for our family business, too.

I THINK that it was a mistake to have all 5 hard drives connected when I installed OpenSuSE. The reason I say that is because the 80 GB drive auto-configured as /dev/sdb, and my 4 250 GB drives auto-configured as /dev/sda, /dev/sdc, /dev/sdd, & /dev/sde.

One of the things that my motherboard is doing is driving me crazy. The 5 SATA ports are SATA1, SATA2, SATA3, SATA5, & SATA6. I don't know what happened to SATA4, but that's how they're marked on the motherboard and in the User Guide provided by ASUS.

I originally had the drives connected with SATA1 to the 80 GB drive, and the other 4 in sequence. Physically, the 80 GB drive was the top one, with the other 4 in sequence underneath it. When I booted the machine & went into BIOS, it showed the 80 GB drive as Drive 3, with Drives 1, 2, 4, & 5 being 250 GB drives. The BOOT SEQUENCE would only allow one of the 250 GB drives to boot ("Drive 1"). But, there was a hardware definition for the drives and I could choose which one was #1, enabling me to respecify that the 80 GB drive was the boot drive.

By now, I've gone round & round trying to figure out what the board is doing. I even FDisk'd and Formatted the drives with sequential names such as Drive_1, Drive_2 ... Drive_5, but even that made absolutely no sense based upon where the drives were actually connected. And, shuffling the cables in sequence did not follow the sequence in the BIOS. Really strange, but it's working fine - at least physically.

Logically, I have a few concerns (please follow me as I think through this process "aloud"):

If I completely rebuild the entire thing from dead-scratch, including deleting all data and removing all partitions - I mean a DEAD SCRATCH rebuild, I should PROBABLY do the installation of the OpenSuSE operating system with only the 80 GB drive connected, and have it connected to the SATA1 slot. That SHOULD force the auto-config to define the drive as /dev/sda. That will help. Then, I can shut down the system & connect the four 250 GB drives one-at-a-time, and then reconfigure the RAID5 array.

• I'm wondering if I do this one-disk-at-a-time, will I be able to have the 2nd drive (the one installed immediately below the 80 GB drive and sequentially connected into the SATA2 port) auto-configure as /dev/sdb.
• Then, another shut-down, connect the 3rd drive in the stack to the SATA3 port, reboot, and have it auto-configure sequentially as /dev/sdc.
• Then, another shut-down, connect the 4th drive in the stack to the SATA5 port, reboot, and have it auto-configure sequentially as /dev/sdd.
• Then, another shut-down, connect the 5th drive in the stack to the SATA6 port, reboot, and have it auto-configure sequentially as /dev/sde.
• Then, configure the RAID5 array in the YaST2 Partitioner application, from the indicated drives.

I know this seems like a LOT of trouble just to know which names align with which physical drives. If the drives could RAID5 with different sizes, it'd be much easier. But, you can't do that. Plus, I've already got 4 of the exact same model# 250GB drives from Western Digital, exactly alike except for their individual and unique serial numbers. Hmmm ...

I'm now wondering if there's any way, from the Operating System - either YaST or the console, to see the serial numbers for each drive device? That would give me definitive assurance that I know what I've got and exactly where each one is.

Ultimately, I want to be able to figure out what is happening WHEN the time comes that one of the drives fails. For example, I want to be able to look at Partitioner and see that /dev/sdc is no longer working/listed/active/mounted, and KNOW that I simply need to pull out the 3rd drive in the stack & replace it. I don't want to be guessing and, maybe, remove the wrong one and end up crashing the data beyond repair.

Any suggestions and/or guidance that might be offered will be GREATLY appreciated. I'm planning on doing this complete tear-down and rebuild sometime this weekend - RIGHT AFTER I replace our now leaking gas-fired water heater :rolleyes: - Yes, this instance of home repair takes precedence over my attempt to achieve "ultimate geekdom" by building a family file & print server. The Water Heater is a major pain, the File Server is an exciting challenge!

I don't understand what this is supposed to mean. You say it as if it means something without elaborating what it is. What great secret about the SB700 chipset is a mistake?

The MISTAKE was mine for USING the "hardware" RAID setup. It doesn't support RAID5, just RAID0, RAID1, & RAID10. I went through all kinds of hell trying to remove the dang thing, even tho I had turned it off in the BIOS setup. I still had to go back and turn it back on & then remove all 4 drives and then turn it off.

This little glitch - this mistake OF MINE - cost me 2 days of hassles that I could have used for something productive. But, after the 10 minutes it took to actually rectify the situation, I'm now using the RAID5 option from within OpenSuSE, and instead of 465GB of hard drive space, I've got 700GB.

Plus, I've been informed that the SB700 chipset is NOT a "HARDWARE" RAID controller, but a "SOFTWARE" RAID controller that actually slows down the processor to some extent (maybe minimal, but still a benchmarkable difference, I'm told). Granted, OpenSuSE's RAID controller/partitioner is software, also, but it's from Novel, and they "solve the problems created by others" (used to be one of their key sayings).

And, I wanted RAID5 from the beginning, and it was partially why I bought that particular motherboard for the server, tho I had just bought 2 of them for the 2 desktop PCs I built, one for me & the other for my wife.

I wasn't trying to be secretive, or especially not to put any emphasis on it by prompting someone to ask about it. It just wasn't material to the current issue at hand, and I wasn't wanting to cloud the issue with the minutae. However, here it is, in all it's frustrating glory.

I hope this helps satisfy your curiosity. Even more so, if you've got the same setup, or especially if you're thinking about it, maybe it'll help you make a more informed decision and help prevent you from having an experience that raised my frustration level higher than my tolerance level - causing me to back off completely so that the answer could come to me in the middle of doing some other non-computer related activity.;)

So it's not that there is something inherently bad or defective about the SB700 chipset, it's just that that particular chipset does not meet your particular needs. I have several dozen systems running happily on the 780G / SB700 chipset.

Oh, one other thing. It appears that YaST2's Partitioner application does show some information that MIGHT be the drive serial number. I'll have to delve further into it (open the box & remove the drives to read their SNs) to see if that is the case. If so, it will go a LONG way toward me being able to identify WHICH drive is WHICH device, and to be able to quickly and easily replace whichever drive eventually fails first. Of course, by then, I won't be replacing them with 250GB drives, but maybe, hopefully affordably, multi-terabyte drives. I'll try to remember to post an answer here after I sort out the data on the screen versus the serial numbers printed on the drives.

First, this thread wasn't supposed to be a discussion about what I perceive to be an improperly functioning chipset, or about my trials and tribulations regarding my experience with the chipset. This thread was posted for the purpose of picking up where I am now, and trying to re-do the system so that I'll have the ability to see which drive in the now working RAID5 array is the one that fails and being able to replace it without having to search for it.

That said...

You are correct that the SB700 chipset doesn't meet my needs, tho I was willing to work with it until I saw that the OS did provide the desired functionality.

Where I think the chipset is flawed is that I had disabled the SB700 RAID, but OpenSuSE still saw the drives as RAIDed and wouldn't let me delete them. I had to go BACK into the SATA BIOS (SB700 BIOS) and turn the RAID back on, then delete the drives one-by-one - until none were left, then turn RAID off and SATA back on - AGAIN, before I could use the OS's RAID functionality. Let me emphasize, I HAD ALREADY TURNED OFF THE BIOS RAID, BUT IT DIDN'T (WORK CORRECTLY) STOP THE RAID!!!

That would seem to be either a DESIGN FLAW, or a malfunctioning chipset. I mean, if you TURN OFF THE LIGHT, then it should be dark, not still illuminating. That seems like a pretty simple concept. The SB700 chipset, on that motherboard, failed in that respect. It was TURNED OFF BUT STILL WORKING.

Granted, I solved the problem by disassembling the software RAID and THEN turning it off. And, I could have avoided the whole thing completely had I realized that the OS provided the desired RAID5 functionality. So, I put the blame on myself. However, one would think that "TURNING OFF THE RAID IN BIOS" would actually turn it off and NOT leave it permanently in it's TURNED-ON state. I understand the work-around, but is THAT how it's SUPPOSED to work???

Now, if anyone has any suggestions about KNOWING which drive is which in the RAID5 array, I'm open to any info. Thanks!