Micha³ Przy³uski <mikylie@xxxxxxxxx> writes:
> Hello,
>
> 2009/5/2 Daniel Reurich <daniel@xxxxxxxxxxxxxxxx>:
>>> It would get worse, as in many situations the installer would succeed,
>>> and the boot would fail. Many raid 5/6 configurations will spread over
>>> controllers, and not BIOS supports booting over several controllers.
>>>
>> Then we teach the bootloaders installer to detect whether all the member
>> disks are on the same controller, and refuse to install (or atleast warn
>> at that point) if not.
>
> That has been an interesting discussion over last week or so. I have
> some thoughts at this point, not really technical...
>
> First thing is, DO NOT boot from raid5/6. It's pointless anyway.
> Let's think of raid5 as a bigger raid1. It won't add any extra
> redundancy to our boot-process over a separate raid1 for /boot. Making
The point was not to add redundany but to remove complexity.
Just look at what you need to do for the next generation of disks
(>2TB):
- Create a MS Dos partition table with a fake /boot partition in the
first 2TB.
- Create a GPT table with a matching /boot partition and the rest
- Create a raid1 for /boot
- Create a raidX for the rest
Now you have to watch 2 raids and add/remove partitions from 2 raids,
You also need to copy the bootloader to every new disk you add.
The idea is to bring this down to:
- Create raidX over all disks
> it a hidden raid1 over first few sectors is just creating an
> automation that gains nothing and makes things unnecessarily
> complicated inside.
If the hidden raid1 is just reserved space that is considered part of
the raid metadata then this moves completly into mdadm userspace. The
extra complexity comes down to "read reserved space from old disk,
write reserved space to new disk". In the most basic form that is 3
lines of code (declare buffer, read, write).
> For example, if user has a, say, 4 disk raid5, with magic or normal
> raid1 for boot, and looses 2 disks, he or she is still pretty angry,
> no matter that they can boot, when they'd lost all their data. I'm
> quite sure users care more about data when they go raid5 than system
> itself.
Not the point.
> If you can afford real hw controller, that "does it all for raid5/6"
> and provides one int13 device for bootloader then no problems. But
> then, who makes his or hers /boot (and / and data) on one huge
> partition.
People that don't use softwareraid are not a traget group for software
raid. So irelevant.
> If you can't, and want to have reliable boot, then you should mirror
> your drives. Going anywhere over raid1 is pointless. You should just
> have a backup, boot is small and changes rarely, one can burn it to a
> dvd easily.
>
> So, as /boot (or even /) nowadays is really tiny, compared to disk
> sizes, you can easily carve out few gigs at the start of device for
> raid1, and use rest of all disks for raid5. Also, lvm'ing /boot sounds
> just wrong, I don't think resizing or other lvm features are of any
> use for /boot.
But being able to pvmove it can be verry usefull. Say you have a
system with 2 disk raid1 that is hotplug capable, has space for 4
disks and you want to migrate to bigger disks. Just plug in 2 new
disks, create raid, extend VG, pvmove everything, reduce VG, stop old
raid, remove old disks.
> Summing up, I don't get, why would anybody really want to boot from raid5 or 6.
>
> I second booting from one thing, and storing data on the other. It can
> be different partition, it can be different disk, but mixing those
> things together in one place is bad practice for many many reasons.
>
> And my very personal background; I chose mdadm because it allows me to
> make raid sets across multiple controllers, and I don't use my raid6
> for anything other than data. System boots from single (even EIDE)
> disk, I'm totally not worried about my system, only data matter.
>
> So all in all, I think all levels of protections are already
> available. And please, no next metadata format; we already have 4
> mdadm metadata versions, and users are still not sure which one they
> should choose.
>
> Please don't eat me at once,
> Have a nice spring day everybody,
> Mike
MfG
Goswin
--
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
