"Mark Knecht" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 05 Oct 2007 19:43:45 -0700:
> In my case I'm very noise sensitive. I do a lot of audio work and don't > want additional hard drive noise in here. In my mind that rules out > multi-drive RAID and I guess I don't see how any form of single-drive > RAID helps if the issue is the drive doing bad. Noise sensitive... go with lower RPM drives. Some Seagate 4200 or 5400 RPM drives may be good, and Seagate still has a 5 year warrantee while many of the others are now one year. Many drives are also adjustable for quietness vs. performance, if you have the right hdparm or smartctl type utils to set them. I've not bothered and it has been awhile since I read up on the details, so I'm a bit fuzzy on them now, but many, particularly here in the US, would come pre-set to the performance side. (In parts of the EU at least, I understand there's some pretty strict regulations on workplace environment including noise, and it's likely that some drives set for performance in the US market come preset for toward quietness in that market.) Note that it's also possible to setup the drives in a separate external enclosure and/or to house either that or the entire computer in another room and run video and control cables. SATA/eSATA Five-drive external enclosures, complete with their own power supply and fans, with hotplug backplane (change out a bad drive while the system is in use), run $300 or so. Add another $100 and throw in a 5:1 SATA port multiplier so you only run a single SATA/eSATA cable back to the computer. The computer itself can then be much smaller/lighter/quieter, since it doesn't contain the drives nor does it need to power them from its own power supply. Another option: For RAID-1/mirroring, the ultimate in reliability since the data is copied N-way, Linux makes it possible to declare some of the devices write-mostly, and make them remote. The Linux RAID driver will write to write-mostly devices as normal, mirroring the data to all devices as usual, but will only read from the write-mostly devices if the normal (non-write-mostly) devices in the array die or return errors. This DRAMATICALLY increases mirroring flexibility, as provided you can keep open a connection with enough bandwidth to maintain expected write- rates, you can locate the write-mostly devices basically anywhere in the world -- connected over the Internet or whatever if necessary. Want your data automatically mirrored to your co-hosted server three states over, to another in Australia, and another in Europe, thus ensuring the ultimate in disaster recoverability? Not a problem! Connect them up over the Internet and create write-mostly devices for them, and your data will be auto-mirrored N-ways including to all those off-site backup locations! Of course, the same technology can be used to host a much-more-local mirror as well, at the other end of the house or at your next-door- neighbor's over Ethernet, or to your server located at work/home from the other, over Internet. You get full data redundancy without requiring but your single normal drive in your on-location computer. If you combine write-mostly with a local but external SATA/eSATA solution hosted in another room, even with heavy data needs, you can be as fully redundant as you wish, with no drives at all in the computer itself, thus lowering the weight/noise/power-requirements of the computer rather drastically. > Probably I'm not aware of all the value of doing all of that work. Maybe > there would be significant reliability gains but it's a subject that is > pretty far beyond me today. That was my reaction too, plus the expense, until I had two drives in a row go out in a year each, while my normal replace cycle would be more like three years. That plus the now relatively low entry cost and complexity, simple SATA drives and the kernel's own software RAID driver, made actually possible what I hadn't even considered within my reach, until that second drive overheated and I began doing research on a suitable replacement with a bit more reliability. (The overheat killed parts of the drive, basically the parts that it tried to read while overheated, but I could still use the rest of it, including the second copy of my data on the same drive, and was still operational on that, so I had some time to research, but didn't want to press my luck...) Basically, minimum cost now is the cost of the additional drive(s), as long as your computer has spare SATA ports, drive bay space, and a power supply sufficient to power the additional drives. Of course, for your low noise needs, you may pay a bit more, but the cost is still only a few hundred dollars total, reasonably comparable to that of getting a second computer, not the thousands of dollars for Enterprise equipment one used to think of in the context of RAID. > I'm also has concerns that 1) the drive could go sooner than later > causing me to have more work getting the system set up again If your entire system is RAID-1/mirrored or RAID-10, and to a somewhat lessor extent if it's RAID-1/5 or 1/6 mixed (as mine is, basically, RAID-0 for the temp-only stuff, but that's not redundant and I know I'd lose it if I lost a drive), particularly if you are running one of the newer hot-plug SATA things, either internal or external, not only need your system never even go down for a drive outage as you can replace it with the system running, but getting out of degraded mode into full redundancy protection once again can literally be as simple as turning the lock and pushing the button to release the old drive in its tray, taking it out of the tray and putting the new drive in, reloading and relocking the tray complete with new drive in place, and running a couple mdadm commands to tell the RAID driver to add it as a spare and reinitialize. Then it's simply a matter of waiting the few hours of still operational but degraded performance until the new drive is brought online fully up to speed. Restating in briefer form, simply push a button, slide out the old drive and replace it with the new, tell mdadm it's now part of the RAID, and wait thru a few hours of lower than normal performance until it's brought online and the system is fully recovered. No need to even reboot; it's all accomplished "live", with a couple of button pushes and issuing a couple of commands, plus a few hours of somewhat lower than normal performance as the new drive is brought up to speed. That's it! More work? No, LESS work, by FAR! While that is the simplest case, full RAID-1 mirroring, if you skimp and go RAID-5 or RAID-6 due to cost, mixed with a RAID-1 for /boot and perhaps a RAID-0/striped for speed for your temp stuff, you do add a few more commands, mainly fdisk to set up the partitions for the mixed RAID before you add the new disk to the RAID, you lose the temp stuff on the RAID-0 and have to rebuild that, and you need to reboot after the fdisk, but the copying over of your data remains fully automatic, and it's still far less work than recovery from a single main disk going bad could every be. > and 2) if I do add some form of RAID that it will cause problems for > the cloned Win XP installation being it isn't there now. Well, if you use Linux-kernel RAID, of course you do lose the ability to read it from MS, and even using hardware RAID, there's the eXPrivacy anti- privacy activation hoops you have to go thru... You certainly do have a point there! Of course, that's one of the big reasons I left MS and switched to Linux... that was a line I simply could not and would not cross. I simply refused, and when MS insisted, as with any relationship where one partner makes demands for something the other simply cannot and will not do, it ends the relationship. Needless to say given no other choice, we parted ways. So I have MS to thank for finally pushing me to Linux. Oh well, their loss as I spent a decent amount of money on them, my ever so great gain! =8^) > And how does LVM work for Windows anyway? I thought that was a Linux > thing? It is... unless you are running one in a VM on the other, of course. Then the host system supplies the devices and drivers. =8^) > Maybe everything Duncan said is right, and I'll give it some thought, > but my #1 worry is trying to make sure the system doesn't go down hard > and leave me with a week's worth of work getting Humpty Dumpty back > together again that I don't need right now. Of course, you know I'd be dumping MS, but it's your system and your choices to make. In any case, I'd certainly consider buying a separate system to run MS on (or run it in a VM... you may actually be surprised to find it runs faster in a VM than it does on the bare metal -- provided you have sufficient memory, of course). Either your MS or Linux side is likely sufficiently low demanding to run on what is now days a fairly cheap system, even new, so the option shouldn't be more than a few hundred dollars. Actually, I intended for that to mainly convey the message that my relatively basic new-drive transfer method, three steps partition/mkfs/ conventional-copy, has served me very well for many years and over a wide variety of implementation details, including my new mixed RAID/LVM setup. It was therefore intended to be less about the RAID/LVM, which was supposed to be simply an incidental mention, and more about the simple partition/mkfs/copy transfer method, but that's not how it turned out, obviously. =8^? In any case, if you are keeping eXPrivacy on there and want to continue to run it on the bare metal and not in a VM, and if you need most of your Linux side to be eXPrivacy accessible, that's going to limit your options somewhat and the LVM/RAID stuff definitely won't be as practical as it could arguably be if you were Linux-only. I still think the basic partition/mkfs/conventional-copy method is simpler than most of the others, tho, particularly since you don't have to worry about additional software, and the repartitioning will allow you to better adapt to the larger drive than straight imaging, or even using dd and then growing the partitions. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
