> 1-2) No, only the md-device, the container, raid level and number of
devices (it's possible to create different RAID volumes with different
levels in one container, however the number of devices must be the same
in all).

OK.

Looking at the 
https://www.intel.com/content/dam/support/us/en/documents/memory-and-storage/ssd-software/Linux_VROC_6-0_User_Guide.pdf
without specifying a size, (raid never does, it uses whole devices) I can't
quite wrap my head around what creating to volumes in a container means.

If I have 4 disks, and put them into a container and then create a raid0
and a raid5 from the container ... what devices do I have?

Ah, the manual suggests size is important for the multi-container
support

    -l Specifies the RAID level. The options supported are 0, 1, 5, 10.
    -z Specifies the size (in Kibibyte) of space dedicated on each disk to the 
RAID volume. This must be a multiple of the chunk size. For example

> 3) AFAIK after stopping and removing all arrays from the container,
mdamd --zero-superblock on the member devices will remove the container
itself. Need to check again.

OK. We currently do:

a) enumerate devices and spares
b) set_sync_action=idle
c) set_sync_action=frozen
d) wipe the superblock if the composed raid device (it may have metadata for a
   higher level device, like nested raid or LVM over RAID etc)
e) for each raid members + spares
      mdadm fail device
      mdadm remove device
f) mdadm stop
g) mdadm zero_device
h) wait for /dev/mdX to be released from the kernel

I think we'd need to notice /dev/mdX is part of a container, and if so after
tearing down the mdx, to then wipe the container?  You mentioned the delete
curtin does isn't sufficient;  If you have the curtin install.log with the
failure, that'll help sort this bit out.

https://www.intel.com/content/dam/support/us/en/documents/memory-and-
storage/ssd-software/Linux_VROC_6-0_User_Guide.pdf

That has more details.

specifically mdadm -vS which stops volumes and if we support the multi-volume
setup, then removing sub-arrays is more complicated


> 4) Yes, and even the EFI partition can be on RAID. Btw, it doesn't really 
> works with the legacy BIOS, mdadm doesn't find the raid support on our 
> servers without EFI. I'm not sure if it's supposed to work with legacy BIOS, 
> or it's just a firmware issue.

EFI really shouldn't be on RAID in that EFI is VFAT and I don't believe there
are EFI drivers for mdadm,  maybe Intel provides a VROC/mdadm EFI driver, do
you know?

For legacy, the open question is whether grub2 can read an mdadm with metadata
imsm metadata... sounds like no.

> 5) That need to be checked, as the cleaning info comes from there.
>
> Yeah, I fear it cannot be automatically tested without actual hardware.

=(

>
>
> Maybe it would be possible to abstract out the container, like:
> - type: raid
>   metadata: imsm
>   container: /dev/md/imsm0
>   name: imsm0
>   devices:
>     - /dev/nvme0n1p1
>     - /dev/nvme1n1p1
>
> - type: raid
>   devices:
>     - /dev/md/imsm0 # but need to get the number of real devices for -n

We can do that by either repeating the values; it's a shame that the
mdadm implementation doesn't just take the container name and look up
the disks.  It seems like a big oversite to require repeating the
devices names since as you mention they have to keep the same devices
and numbers.

>   name: mirror0
>   level: 1

Given that to create multiple volumes from the container, we'll need to
use two entries, the raid volumes will need a size.


- type: raid
  id: disk_raid_container0
  metadata: imsm
  name: /dev/md/imsm0
  devices:
    - /dev/nvme0n1p1
    - /dev/nvme1n1p1

- type: raid:
  id: disk_raid0_c0_vol0
  level: 1
  name: /dev/md/mirror0
  container: disk_raid_container0
  size_kb: <KiB value>

- type: raid:
  id: disk_raid0_c0_vol1
  level: 0
  name: /dev/md/striped0
  container: disk_raid_container0
  size_kb: <KiB value>

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1893661

Title:
  Support for Intel VROC (Virtual RAID On CPU)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1893661/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to