Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
"Derek Atkins" <warlord at MIT.EDU> wrote: > I can't be the first person to think about this problem but > not want an infinitely increasing number of MDn RAID arrays. I think you're expressing concern about something that's really not as much of an issue as you think. If you did an average of one hardware upgrade each year, you'd have /dev/md0 through /dev/md9 at the end of a decade. By then the whole approach to the problem will almost certainly have evolved, and the tools you seek may very well have developed. With today's tools, yes, in order to shrink down the number of md[0-9] devices back toward 1 or 2 you'd have to make a big fs on a new volume and rsync it, might be a few hours of shuffling files. But that's only after quite a few years of continuous runtime. dsr wrote: >> Each partition for RAID must be the same size. > > Odd.. According to a modern mdadm man page (and a great LVM-RAID > resource [0]) each partition does NOT have to be the same size You're both right but the end result's the same: the software will work best if you make your RAID partition elements for any given /dev/md[X] device all the same size. Not so long ago, you had to use identical-sized drives operating at identical speed: things are much more flexible today. I can only assume system tools will eventually get better. My point in bringing up this whole topic is that today's tools are really quite nice but very few--not enough--people use them under Linux. And they aren't available at all on Windows XP Home Edition, which is one reason I'm eager for further evolution of the Linux desktop. I hope that more of y'all decide to take advantage of RAID+LVM during your next system installation or upgrade. -rich -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |