Hallo David!
"David Lethe" <david@xxxxxxxxxxxx> schrieb:
> 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.
No, sorry. I really don't understand. But maybe because I didn't tell detailed enough what our systems looks like.
We have here two huge RAID6 systems, that are connected through a 10G Ethernet switch. They are equally in size.
On these RAID6 we create LVs euqally in size and want them to be parts of a RAID1:
RAID6 RAID6
monosan duosan
LV LV (multiple of)
\ / 10GE
RAID1
| 10GE
aoe
| 1GE
server (multiple of)
> 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,
But could you tell me what in the current »design« prevents us to resize the LVs and the RAID1 on top?
When I understand it correctly the RAID information are written at the end of each accessible partition/LV.
What is different on an extended LV from a partition that is replaced with a bigger one?
[...]
Thanks
Lars
--
Informationstechnologie
Berlin-Brandenburgische Akademie der Wissenschaften
Jägerstrasse 22-23 10117 Berlin
Tel.: +49 30 20370-352 http://www.bbaw.de
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
