RE: How to grow RAID1 mirror on top of LVM?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




-----Original Message-----
From: linux-raid-owner@xxxxxxxxxxxxxxx [mailto:linux-raid-owner@xxxxxxxxxxxxxxx] On Behalf Of Lars Täuber
Sent: Monday, April 28, 2008 9:26 AM
To: Neil Brown
Cc: Anton Altaparmakov; linux-raid@xxxxxxxxxxxxxxx
Subject: Re: How to grow RAID1 mirror on top of LVM?

Hallo Neil,

Neil Brown <neilb@xxxxxxx> schrieb:
> On Thursday March 13, aia21@xxxxxxxxx wrote:
> > 
> > Is there a better way to do this?  I am hoping someone will tell me to  
> > use option blah to utility foo that will do this for me without having  
> > to break the mirror twice and resync each time.  (-;
> 
> Sorry, but no.  This mode of operation was never envisaged for md.
> I would always put the md/raid1 devices below the LVM.

could you write in some short words what in the design prohibits us to grow a raid1 on a grown lvm?
We wanted to do the same:


mutliple RAID1 (aoe targets)
on top of
multiple LVMs
on top of
gigantic RAID6


Thanks
Lars
-----------------
Lars:
Even if you *could* do this, then your design would still be an awful idea.  You'd effectively have a random I/O filesystem.  Any write on a RAID1 disk would generate writes on all of the other disks.  Even with a small number of RAID1 targets and default journaling, I wouldn't be surprised if a single application write translated into at least a dozen physical disk writes.  

What if (when) both the RAID1 & RAID6 became corrupted?  How would you proceed?  How would you propose the md engine deal with this?   What if you lose a disk on the RAID6 while expanding the LVM and have a bad sector on remaining disks, or fsck shows filesytem corruption while you are expanding a md volume. 

Maybe you are starting to get the point.  What is preventing the md layer from doing what you want is that a heck of a lot of code would have to be written, and the fileystem and md layers would have to be tightly coupled into a single entity.  This would have to be done not so much to facilitate what you want ... but to maintain and safely recover data integrity when things go bad.  The layered architecture of LINUX has benefits from developers perspective, because they don't have to worry about such things.  The downside is that if you want a robust storage pool that gives you such flexibility then you need to use external RAID or go with another O/S.


   
��.n��������+%������w��{.n�����{����w��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux