Re: Installing Linux directly onto RAID6 Array...........

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3954 bytes --]

On Sun, 24 May 2015 10:08:59 +0100 Another Sillyname
<anothersname@googlemail.com> wrote:

> I suspect you're correct in that I'll end up with the boot partitions
> being in RAID1 and the data in RAID6, however I am seriously
> considering having the boot in RAID6 as well...if I can integrate the
> mdadm.conf into the initramfs properly I can't see a reason not to do
> this?

mdadm.conf is largely a non-issue.  You don't need an mdadm.conf to assemble
your array.  All the raid configuration lives in the raid metadata.
All you need is for your initrd to know what device contains your root
filesystem (preferably by UUID) so that when mdadm finds that array, the
initrd code can mount it for you.

I believe that GRUB2 can load an initrd and kernel from a filesystem on an
mdraid device, but I don't know where the boot sector would load GRUB2 from.

md's v1.2 metadata leaves 4K at the start of each device.  If GRUB2 fits in
there, then it could certainly load, assemble the RAID6, then pull the files
off your root filesystem.  But I doubt it.

If GRUB tries to put the boot loader anywhere else, there is a good chance
that md could over-write it, as it believes that it owns all the space after
4K.

According to the documentation, GRUB2 either places the second stage in the
first 32K before the first partition, or in the filesystem at specific block
locations.
The first cannot work if md uses the whole device (works fine if md uses
partitions).
The second cannot work with RAID6 as the blocks are in locations on one
device.  This only really work for RAID1.

So feel free to try, and do report any results, but I doubt you'll get it to
work reliably.

NeilBrown

> 
> Had a look at the metadata=0.9 option but reading the info on mdadm
> metadata I think I'd prefer to have the metadata at the start of the
> drive, also it looks like metadata=1.2 has extra functionality that I
> may want to use later.
> 
> On 24 May 2015 at 09:36, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> > On Sun, 24 May 2015, Another Sillyname wrote:
> >
> >> So I now have 5 partitions.
> >>
> >> a  -  bios_boot
> >> b  -  efi
> >> c  -  boot
> >> d  -  root
> >> e  -  swap
> >>
> >> I'll be adding one more when I'm happy this is working.
> >>
> >> f  -  home
> >>
> >> 3.  Using the methods above I have now created a bootable fedora
> >> system, on a single drive in preparation to now RAID the required
> >> partitions.  However my concern comes regarding the mdadm metadata,
> >> simplistically metadata=1.2 apparently writes it's superblock to 4k
> >> after the start of the device, this is exactly where my efi partition
> >> (b above) starts, so my concern is will this superblock overwrite or
> >> mess with my current partition table?
> >>
> >> 4.  If the next stage works then I think what I'll actually end up
> >> doing is......
> >>
> >> scrub what I have now.
> >>
> >> create the arrays before running the Fedora Live installer (this
> >> assumes the installer will see /md[x] devices and allow them to be
> >> used to install to). Then incorporate the mdadm.conf data into the
> >> initramfs and regenerate initramfs.
> >>
> >> Ideas/Thoughts/Criticisms?
> >
> >
> > You don't want to run MD on the entire drive in this case, you most likely
> > want to create multiple RAID1 and RAID6 mirrors. RAID1 your boot, root and
> > swap, then run RAID6 on your home partition. Use use superblock type that
> > creates the superblock at the end for the RAID1 partitions.
> >
> > Also, you don't want to refer to "sda" when booting, you want to use
> > UUID=<uuid> in fstab, crypttab etc.
> >
> > --
> > Mikael Abrahamsson    email: swmike@swm.pp.se
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]