1 |
"Mark Knecht" <markknecht@×××××.com> posted |
2 |
5bdc1c8b0710051943w4cd14241v795c599285891959@××××××××××.com, excerpted |
3 |
below, on Fri, 05 Oct 2007 19:43:45 -0700: |
4 |
|
5 |
> In my case I'm very noise sensitive. I do a lot of audio work and don't |
6 |
> want additional hard drive noise in here. In my mind that rules out |
7 |
> multi-drive RAID and I guess I don't see how any form of single-drive |
8 |
> RAID helps if the issue is the drive doing bad. |
9 |
|
10 |
Noise sensitive... go with lower RPM drives. Some Seagate 4200 or 5400 |
11 |
RPM drives may be good, and Seagate still has a 5 year warrantee while |
12 |
many of the others are now one year. |
13 |
|
14 |
Many drives are also adjustable for quietness vs. performance, if you |
15 |
have the right hdparm or smartctl type utils to set them. I've not |
16 |
bothered and it has been awhile since I read up on the details, so I'm a |
17 |
bit fuzzy on them now, but many, particularly here in the US, would come |
18 |
pre-set to the performance side. (In parts of the EU at least, I |
19 |
understand there's some pretty strict regulations on workplace |
20 |
environment including noise, and it's likely that some drives set for |
21 |
performance in the US market come preset for toward quietness in that |
22 |
market.) |
23 |
|
24 |
Note that it's also possible to setup the drives in a separate external |
25 |
enclosure and/or to house either that or the entire computer in another |
26 |
room and run video and control cables. SATA/eSATA Five-drive external |
27 |
enclosures, complete with their own power supply and fans, with hotplug |
28 |
backplane (change out a bad drive while the system is in use), run $300 |
29 |
or so. Add another $100 and throw in a 5:1 SATA port multiplier so you |
30 |
only run a single SATA/eSATA cable back to the computer. The computer |
31 |
itself can then be much smaller/lighter/quieter, since it doesn't contain |
32 |
the drives nor does it need to power them from its own power supply. |
33 |
|
34 |
Another option: For RAID-1/mirroring, the ultimate in reliability since |
35 |
the data is copied N-way, Linux makes it possible to declare some of the |
36 |
devices write-mostly, and make them remote. The Linux RAID driver will |
37 |
write to write-mostly devices as normal, mirroring the data to all |
38 |
devices as usual, but will only read from the write-mostly devices if the |
39 |
normal (non-write-mostly) devices in the array die or return errors. |
40 |
This DRAMATICALLY increases mirroring flexibility, as provided you can |
41 |
keep open a connection with enough bandwidth to maintain expected write- |
42 |
rates, you can locate the write-mostly devices basically anywhere in the |
43 |
world -- connected over the Internet or whatever if necessary. Want your |
44 |
data automatically mirrored to your co-hosted server three states over, |
45 |
to another in Australia, and another in Europe, thus ensuring the |
46 |
ultimate in disaster recoverability? Not a problem! Connect them up |
47 |
over the Internet and create write-mostly devices for them, and your data |
48 |
will be auto-mirrored N-ways including to all those off-site backup |
49 |
locations! |
50 |
|
51 |
Of course, the same technology can be used to host a much-more-local |
52 |
mirror as well, at the other end of the house or at your next-door- |
53 |
neighbor's over Ethernet, or to your server located at work/home from the |
54 |
other, over Internet. You get full data redundancy without requiring but |
55 |
your single normal drive in your on-location computer. |
56 |
|
57 |
If you combine write-mostly with a local but external SATA/eSATA solution |
58 |
hosted in another room, even with heavy data needs, you can be as fully |
59 |
redundant as you wish, with no drives at all in the computer itself, thus |
60 |
lowering the weight/noise/power-requirements of the computer rather |
61 |
drastically. |
62 |
|
63 |
> Probably I'm not aware of all the value of doing all of that work. Maybe |
64 |
> there would be significant reliability gains but it's a subject that is |
65 |
> pretty far beyond me today. |
66 |
|
67 |
That was my reaction too, plus the expense, until I had two drives in a |
68 |
row go out in a year each, while my normal replace cycle would be more |
69 |
like three years. That plus the now relatively low entry cost and |
70 |
complexity, simple SATA drives and the kernel's own software RAID driver, |
71 |
made actually possible what I hadn't even considered within my reach, |
72 |
until that second drive overheated and I began doing research on a |
73 |
suitable replacement with a bit more reliability. (The overheat killed |
74 |
parts of the drive, basically the parts that it tried to read while |
75 |
overheated, but I could still use the rest of it, including the second |
76 |
copy of my data on the same drive, and was still operational on that, so |
77 |
I had some time to research, but didn't want to press my luck...) |
78 |
|
79 |
Basically, minimum cost now is the cost of the additional drive(s), as |
80 |
long as your computer has spare SATA ports, drive bay space, and a power |
81 |
supply sufficient to power the additional drives. Of course, for your |
82 |
low noise needs, you may pay a bit more, but the cost is still only a few |
83 |
hundred dollars total, reasonably comparable to that of getting a second |
84 |
computer, not the thousands of dollars for Enterprise equipment one used |
85 |
to think of in the context of RAID. |
86 |
|
87 |
> I'm also has concerns that 1) the drive could go sooner than later |
88 |
> causing me to have more work getting the system set up again |
89 |
|
90 |
If your entire system is RAID-1/mirrored or RAID-10, and to a somewhat |
91 |
lessor extent if it's RAID-1/5 or 1/6 mixed (as mine is, basically, |
92 |
RAID-0 for the temp-only stuff, but that's not redundant and I know I'd |
93 |
lose it if I lost a drive), particularly if you are running one of the |
94 |
newer hot-plug SATA things, either internal or external, not only need |
95 |
your system never even go down for a drive outage as you can replace it |
96 |
with the system running, but getting out of degraded mode into full |
97 |
redundancy protection once again can literally be as simple as turning |
98 |
the lock and pushing the button to release the old drive in its tray, |
99 |
taking it out of the tray and putting the new drive in, reloading and |
100 |
relocking the tray complete with new drive in place, and running a couple |
101 |
mdadm commands to tell the RAID driver to add it as a spare and |
102 |
reinitialize. Then it's simply a matter of waiting the few hours of |
103 |
still operational but degraded performance until the new drive is brought |
104 |
online fully up to speed. |
105 |
|
106 |
Restating in briefer form, simply push a button, slide out the old drive |
107 |
and replace it with the new, tell mdadm it's now part of the RAID, and |
108 |
wait thru a few hours of lower than normal performance until it's brought |
109 |
online and the system is fully recovered. |
110 |
|
111 |
No need to even reboot; it's all accomplished "live", with a couple of |
112 |
button pushes and issuing a couple of commands, plus a few hours of |
113 |
somewhat lower than normal performance as the new drive is brought up to |
114 |
speed. That's it! More work? No, LESS work, by FAR! |
115 |
|
116 |
While that is the simplest case, full RAID-1 mirroring, if you skimp and |
117 |
go RAID-5 or RAID-6 due to cost, mixed with a RAID-1 for /boot and |
118 |
perhaps a RAID-0/striped for speed for your temp stuff, you do add a few |
119 |
more commands, mainly fdisk to set up the partitions for the mixed RAID |
120 |
before you add the new disk to the RAID, you lose the temp stuff on the |
121 |
RAID-0 and have to rebuild that, and you need to reboot after the fdisk, |
122 |
but the copying over of your data remains fully automatic, and it's still |
123 |
far less work than recovery from a single main disk going bad could every |
124 |
be. |
125 |
|
126 |
> and 2) if I do add some form of RAID that it will cause problems for |
127 |
> the cloned Win XP installation being it isn't there now. |
128 |
|
129 |
Well, if you use Linux-kernel RAID, of course you do lose the ability to |
130 |
read it from MS, and even using hardware RAID, there's the eXPrivacy anti- |
131 |
privacy activation hoops you have to go thru... You certainly do have a |
132 |
point there! |
133 |
|
134 |
Of course, that's one of the big reasons I left MS and switched to |
135 |
Linux... that was a line I simply could not and would not cross. I simply |
136 |
refused, and when MS insisted, as with any relationship where one partner |
137 |
makes demands for something the other simply cannot and will not do, it |
138 |
ends the relationship. Needless to say given no other choice, we parted |
139 |
ways. So I have MS to thank for finally pushing me to Linux. Oh well, |
140 |
their loss as I spent a decent amount of money on them, my ever so great |
141 |
gain! =8^) |
142 |
|
143 |
> And how does LVM work for Windows anyway? I thought that was a Linux |
144 |
> thing? |
145 |
|
146 |
It is... unless you are running one in a VM on the other, of course. |
147 |
Then the host system supplies the devices and drivers. =8^) |
148 |
|
149 |
> Maybe everything Duncan said is right, and I'll give it some thought, |
150 |
> but my #1 worry is trying to make sure the system doesn't go down hard |
151 |
> and leave me with a week's worth of work getting Humpty Dumpty back |
152 |
> together again that I don't need right now. |
153 |
|
154 |
Of course, you know I'd be dumping MS, but it's your system and your |
155 |
choices to make. In any case, I'd certainly consider buying a separate |
156 |
system to run MS on (or run it in a VM... you may actually be surprised |
157 |
to find it runs faster in a VM than it does on the bare metal -- provided |
158 |
you have sufficient memory, of course). Either your MS or Linux side is |
159 |
likely sufficiently low demanding to run on what is now days a fairly |
160 |
cheap system, even new, so the option shouldn't be more than a few |
161 |
hundred dollars. |
162 |
|
163 |
Actually, I intended for that to mainly convey the message that my |
164 |
relatively basic new-drive transfer method, three steps partition/mkfs/ |
165 |
conventional-copy, has served me very well for many years and over a wide |
166 |
variety of implementation details, including my new mixed RAID/LVM |
167 |
setup. It was therefore intended to be less about the RAID/LVM, which |
168 |
was supposed to be simply an incidental mention, and more about the |
169 |
simple partition/mkfs/copy transfer method, but that's not how it turned |
170 |
out, obviously. =8^? |
171 |
|
172 |
In any case, if you are keeping eXPrivacy on there and want to continue |
173 |
to run it on the bare metal and not in a VM, and if you need most of your |
174 |
Linux side to be eXPrivacy accessible, that's going to limit your options |
175 |
somewhat and the LVM/RAID stuff definitely won't be as practical as it |
176 |
could arguably be if you were Linux-only. I still think the basic |
177 |
partition/mkfs/conventional-copy method is simpler than most of the |
178 |
others, tho, particularly since you don't have to worry about additional |
179 |
software, and the repartitioning will allow you to better adapt to the |
180 |
larger drive than straight imaging, or even using dd and then growing the |
181 |
partitions. |
182 |
|
183 |
-- |
184 |
Duncan - List replies preferred. No HTML msgs. |
185 |
"Every nonfree program has a lord, a master -- |
186 |
and if you use the program, he is your master." Richard Stallman |
187 |
|
188 |
-- |
189 |
gentoo-amd64@g.o mailing list |