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 |
On Wed, 2006-11-08 at 13:17 -0500, Derek Atkins wrote: > > Ok, you've confused me again. Doing it this way, to swap out > 4 drives you need to have space for 8 drives! Or are you saying > that you swap out one drive at a time? The way I would think about > it: [snip] > Now, I can see how in the next swap-out, when I add a p4 (built into > an md3), if p4 is greater than p2+p3 then I can see how I could move > everything from md1 and md2 onto md3, and then combine p2 and p3 and > build a new array from the newly combined p2+p3. But this only works > if I keep getting geometrically-bigger hard drives (well, it needs to > be Fibonachily-increasing sizes). > > Am I missing something? It sounds like you're trying to mix together several different layers. You mention combining partitions, for instance, but that's at the layer below RAID, whereas LVM is the layer above RAID. And the ext3 layer sits above LVM. I've only done this with RAID-1, which is simpler than trying to juggle drives in a RAID-5 metadevice. I only had to swap 2 drives at a time. The HOWTOs I read on it described an alternate way to manage it that involved partitioning large drives into several partitions and building RAID volumes from the partitions. The scheme used multiple md's, and combined them into one volume at the LVM layer. With this scheme, you can remove md's when removing drives, so you don't have md's proliferating infinitely, but you'd still have more than one md. At the LVM layer, you can combine the multiple md's into a single virtual volume. -- John Abreau / Executive Director, Boston Linux & Unix IM: jabr at jabber.blu.org / abreauj at AIM / abreauj at Yahoo / zusa_it_mgr at Skype Email jabr at blu.org / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9 PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.blu.org/pipermail/discuss/attachments/20061108/183daac7/attachment.sig>
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |