gparted/include/SWRaid_Info.h

82 lines
2.4 KiB
C
Raw Normal View History

Detect Linux SWRaid members by querying mdadm (#756829) Detection of Linux SWRaid members currently fails in a number of cases: 1) Arrays which use metadata type 0.90 or 1.0 store the super block at the end of the partition. So file system signatures in at least linear and mirrored arrays occur at the same offsets in the underlying partitions. As libparted only recognises file systems this is what is detected, rather than an SWRaid member. # mdadm -E -s -v ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1 devices=/dev/sda1,/dev/sdb1 ... # wipefs /dev/sda1 offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] LABEL: chimney-boot UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501 0x1fffe000 linux_raid_member [raid] LABEL: chimney:1 UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a # parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary ext4 boot, raid ... 2) Again with metadata type 0.90 or 1.0 arrays blkid may report the contained file system instead of an SWRaid member. Have a single example of this configuration with a mirrored array containing the /boot file system. Blkid reports one member as ext4 and the other as SWRaid! # blkid | egrep 'sd[ab]1' /dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot" /dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member" Bypassing the blkid cache gets the correct result. # blkid -c /dev/null /dev/sda1 /dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member" However this can't be used because if a user has a floppy configured in the BIOS but no floppy attached, GParted will wait for minutes as the kernel tries to access non-existent hardware on behalf of the blkid query. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect 3) Old versions of blkid don't recognise SWRaid members at all so always report the file system when found. Occurs with blkid v1.0 on RedHat / CentOS 5. The only way I can see how to fix all these cases is to use the mdadm command to query the configured arrays. Then use this information for first choice when detecting partition content, making the order: SWRaid members, libparted, blkid and internal. GParted shell wrapper already creates temporary blank udev rules to prevent Linux Software RAID arrays being automatically started when GParted refreshes its device information[1]. However an administrator could manually stop or start arrays or change their configuration between refreshes so GParted must load this information every refresh. On my desktop with 4 internal hard drives and 3 testing Linux Software RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the device refresh time. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Bug 756829 - SWRaid member detection enhancements
2015-10-20 13:52:19 -06:00
/* Copyright (C) 2015 Mike Fleetwood
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, see <http://www.gnu.org/licenses/>.
*/
/* SWRaid_Info
*
Parse ATARAID members from mdadm output and /proc/mdstat (#75) Since mdadm release 3.0 (2009-06-02) [1] it has also supported external metadata formats IMSM (Intel Matrix Storage Manager) and DDF, previously only managed by dmraid. A number of distributions have switched to use mdadm and kernel MD (Multiple Devices) driver for managing these Firmware / BIOS / ATARAID arrays. These include: Fedora >= 14 [2], RHEL / CentOS >= 6 [3], SLES >= 12 [4], Ubuntu >= 16.04 LTS. Therefore additionally parse members in these ATARAID arrays included in mdadm output, and when activated using the kernel MD driver, in file /proc/mdstat. Add fstype to the SWRaid_Info cache records to distinguish members apart. So far the rest of the GParted code continues to treat all members as FS_LINUX_SWRAID. This will be resolved in following commits. Note that this in no way affects how GParted shows and partitions the array device itself, even those managed by dmraid and use the GParted DMRaid module. It only affects how GParted shows the member drives themselves. [1] mdadm ANNOUNCE-3.0 file https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/ANNOUNCE-3.0?h=mdadm-3.0 [2] Fedora 14, Storage Administration Guide, 12.5. Linux RAID Subsystem https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/raid-subsys.html "... Fedora 14 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [3] RHEL 6, Storage Administration Guide, 17.3. Linux RAID Subsystem https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/raid-subsys "mdraid also supports other metadata formats, known as external metadata. Red Hat Enterprise Linux 6 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [4] SUSE Linux Enterprise Server 12 Release Notes, 7.2.3 Driver for IMSM and DDF https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-316007 "For IMSM and DDF RAIDs the mdadm driver is used unconditionally." Closes #75 - Errors with GPT on RAID 0 ATARAID array
2019-11-17 03:39:02 -07:00
* Cache of information about RAID array members recognised by mdadm so
* the command only needs to be executed once per refresh. This will
* include Linux Software RAID arrays and also IMSM and DDF type
* Firmware / BIOS / ATARAID arrays whether or not the distribution uses
* dmraid or mdadm to manage them.
*
* Note that ATARAID array members will only report as active in this
* module if they were started using mdadm and appear in /proc/mdstat.
Detect Linux SWRaid members by querying mdadm (#756829) Detection of Linux SWRaid members currently fails in a number of cases: 1) Arrays which use metadata type 0.90 or 1.0 store the super block at the end of the partition. So file system signatures in at least linear and mirrored arrays occur at the same offsets in the underlying partitions. As libparted only recognises file systems this is what is detected, rather than an SWRaid member. # mdadm -E -s -v ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1 devices=/dev/sda1,/dev/sdb1 ... # wipefs /dev/sda1 offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] LABEL: chimney-boot UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501 0x1fffe000 linux_raid_member [raid] LABEL: chimney:1 UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a # parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary ext4 boot, raid ... 2) Again with metadata type 0.90 or 1.0 arrays blkid may report the contained file system instead of an SWRaid member. Have a single example of this configuration with a mirrored array containing the /boot file system. Blkid reports one member as ext4 and the other as SWRaid! # blkid | egrep 'sd[ab]1' /dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot" /dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member" Bypassing the blkid cache gets the correct result. # blkid -c /dev/null /dev/sda1 /dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member" However this can't be used because if a user has a floppy configured in the BIOS but no floppy attached, GParted will wait for minutes as the kernel tries to access non-existent hardware on behalf of the blkid query. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect 3) Old versions of blkid don't recognise SWRaid members at all so always report the file system when found. Occurs with blkid v1.0 on RedHat / CentOS 5. The only way I can see how to fix all these cases is to use the mdadm command to query the configured arrays. Then use this information for first choice when detecting partition content, making the order: SWRaid members, libparted, blkid and internal. GParted shell wrapper already creates temporary blank udev rules to prevent Linux Software RAID arrays being automatically started when GParted refreshes its device information[1]. However an administrator could manually stop or start arrays or change their configuration between refreshes so GParted must load this information every refresh. On my desktop with 4 internal hard drives and 3 testing Linux Software RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the device refresh time. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Bug 756829 - SWRaid member detection enhancements
2015-10-20 13:52:19 -06:00
*/
#ifndef GPARTED_SWRAID_INFO_H
#define GPARTED_SWRAID_INFO_H
Parse ATARAID members from mdadm output and /proc/mdstat (#75) Since mdadm release 3.0 (2009-06-02) [1] it has also supported external metadata formats IMSM (Intel Matrix Storage Manager) and DDF, previously only managed by dmraid. A number of distributions have switched to use mdadm and kernel MD (Multiple Devices) driver for managing these Firmware / BIOS / ATARAID arrays. These include: Fedora >= 14 [2], RHEL / CentOS >= 6 [3], SLES >= 12 [4], Ubuntu >= 16.04 LTS. Therefore additionally parse members in these ATARAID arrays included in mdadm output, and when activated using the kernel MD driver, in file /proc/mdstat. Add fstype to the SWRaid_Info cache records to distinguish members apart. So far the rest of the GParted code continues to treat all members as FS_LINUX_SWRAID. This will be resolved in following commits. Note that this in no way affects how GParted shows and partitions the array device itself, even those managed by dmraid and use the GParted DMRaid module. It only affects how GParted shows the member drives themselves. [1] mdadm ANNOUNCE-3.0 file https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/ANNOUNCE-3.0?h=mdadm-3.0 [2] Fedora 14, Storage Administration Guide, 12.5. Linux RAID Subsystem https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/raid-subsys.html "... Fedora 14 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [3] RHEL 6, Storage Administration Guide, 17.3. Linux RAID Subsystem https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/raid-subsys "mdraid also supports other metadata formats, known as external metadata. Red Hat Enterprise Linux 6 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [4] SUSE Linux Enterprise Server 12 Release Notes, 7.2.3 Driver for IMSM and DDF https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-316007 "For IMSM and DDF RAIDs the mdadm driver is used unconditionally." Closes #75 - Errors with GPT on RAID 0 ATARAID array
2019-11-17 03:39:02 -07:00
#include "BlockSpecial.h"
Parse ATARAID members from mdadm output and /proc/mdstat (#75) Since mdadm release 3.0 (2009-06-02) [1] it has also supported external metadata formats IMSM (Intel Matrix Storage Manager) and DDF, previously only managed by dmraid. A number of distributions have switched to use mdadm and kernel MD (Multiple Devices) driver for managing these Firmware / BIOS / ATARAID arrays. These include: Fedora >= 14 [2], RHEL / CentOS >= 6 [3], SLES >= 12 [4], Ubuntu >= 16.04 LTS. Therefore additionally parse members in these ATARAID arrays included in mdadm output, and when activated using the kernel MD driver, in file /proc/mdstat. Add fstype to the SWRaid_Info cache records to distinguish members apart. So far the rest of the GParted code continues to treat all members as FS_LINUX_SWRAID. This will be resolved in following commits. Note that this in no way affects how GParted shows and partitions the array device itself, even those managed by dmraid and use the GParted DMRaid module. It only affects how GParted shows the member drives themselves. [1] mdadm ANNOUNCE-3.0 file https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/ANNOUNCE-3.0?h=mdadm-3.0 [2] Fedora 14, Storage Administration Guide, 12.5. Linux RAID Subsystem https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/raid-subsys.html "... Fedora 14 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [3] RHEL 6, Storage Administration Guide, 17.3. Linux RAID Subsystem https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/raid-subsys "mdraid also supports other metadata formats, known as external metadata. Red Hat Enterprise Linux 6 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [4] SUSE Linux Enterprise Server 12 Release Notes, 7.2.3 Driver for IMSM and DDF https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-316007 "For IMSM and DDF RAIDs the mdadm driver is used unconditionally." Closes #75 - Errors with GPT on RAID 0 ATARAID array
2019-11-17 03:39:02 -07:00
#include "Utils.h"
Detect Linux SWRaid members by querying mdadm (#756829) Detection of Linux SWRaid members currently fails in a number of cases: 1) Arrays which use metadata type 0.90 or 1.0 store the super block at the end of the partition. So file system signatures in at least linear and mirrored arrays occur at the same offsets in the underlying partitions. As libparted only recognises file systems this is what is detected, rather than an SWRaid member. # mdadm -E -s -v ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1 devices=/dev/sda1,/dev/sdb1 ... # wipefs /dev/sda1 offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] LABEL: chimney-boot UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501 0x1fffe000 linux_raid_member [raid] LABEL: chimney:1 UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a # parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary ext4 boot, raid ... 2) Again with metadata type 0.90 or 1.0 arrays blkid may report the contained file system instead of an SWRaid member. Have a single example of this configuration with a mirrored array containing the /boot file system. Blkid reports one member as ext4 and the other as SWRaid! # blkid | egrep 'sd[ab]1' /dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot" /dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member" Bypassing the blkid cache gets the correct result. # blkid -c /dev/null /dev/sda1 /dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member" However this can't be used because if a user has a floppy configured in the BIOS but no floppy attached, GParted will wait for minutes as the kernel tries to access non-existent hardware on behalf of the blkid query. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect 3) Old versions of blkid don't recognise SWRaid members at all so always report the file system when found. Occurs with blkid v1.0 on RedHat / CentOS 5. The only way I can see how to fix all these cases is to use the mdadm command to query the configured arrays. Then use this information for first choice when detecting partition content, making the order: SWRaid members, libparted, blkid and internal. GParted shell wrapper already creates temporary blank udev rules to prevent Linux Software RAID arrays being automatically started when GParted refreshes its device information[1]. However an administrator could manually stop or start arrays or change their configuration between refreshes so GParted must load this information every refresh. On my desktop with 4 internal hard drives and 3 testing Linux Software RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the device refresh time. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Bug 756829 - SWRaid member detection enhancements
2015-10-20 13:52:19 -06:00
#include <glibmm/ustring.h>
#include <vector>
Parse ATARAID members from mdadm output and /proc/mdstat (#75) Since mdadm release 3.0 (2009-06-02) [1] it has also supported external metadata formats IMSM (Intel Matrix Storage Manager) and DDF, previously only managed by dmraid. A number of distributions have switched to use mdadm and kernel MD (Multiple Devices) driver for managing these Firmware / BIOS / ATARAID arrays. These include: Fedora >= 14 [2], RHEL / CentOS >= 6 [3], SLES >= 12 [4], Ubuntu >= 16.04 LTS. Therefore additionally parse members in these ATARAID arrays included in mdadm output, and when activated using the kernel MD driver, in file /proc/mdstat. Add fstype to the SWRaid_Info cache records to distinguish members apart. So far the rest of the GParted code continues to treat all members as FS_LINUX_SWRAID. This will be resolved in following commits. Note that this in no way affects how GParted shows and partitions the array device itself, even those managed by dmraid and use the GParted DMRaid module. It only affects how GParted shows the member drives themselves. [1] mdadm ANNOUNCE-3.0 file https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/ANNOUNCE-3.0?h=mdadm-3.0 [2] Fedora 14, Storage Administration Guide, 12.5. Linux RAID Subsystem https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/raid-subsys.html "... Fedora 14 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [3] RHEL 6, Storage Administration Guide, 17.3. Linux RAID Subsystem https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/raid-subsys "mdraid also supports other metadata formats, known as external metadata. Red Hat Enterprise Linux 6 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [4] SUSE Linux Enterprise Server 12 Release Notes, 7.2.3 Driver for IMSM and DDF https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-316007 "For IMSM and DDF RAIDs the mdadm driver is used unconditionally." Closes #75 - Errors with GPT on RAID 0 ATARAID array
2019-11-17 03:39:02 -07:00
Detect Linux SWRaid members by querying mdadm (#756829) Detection of Linux SWRaid members currently fails in a number of cases: 1) Arrays which use metadata type 0.90 or 1.0 store the super block at the end of the partition. So file system signatures in at least linear and mirrored arrays occur at the same offsets in the underlying partitions. As libparted only recognises file systems this is what is detected, rather than an SWRaid member. # mdadm -E -s -v ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1 devices=/dev/sda1,/dev/sdb1 ... # wipefs /dev/sda1 offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] LABEL: chimney-boot UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501 0x1fffe000 linux_raid_member [raid] LABEL: chimney:1 UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a # parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary ext4 boot, raid ... 2) Again with metadata type 0.90 or 1.0 arrays blkid may report the contained file system instead of an SWRaid member. Have a single example of this configuration with a mirrored array containing the /boot file system. Blkid reports one member as ext4 and the other as SWRaid! # blkid | egrep 'sd[ab]1' /dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot" /dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member" Bypassing the blkid cache gets the correct result. # blkid -c /dev/null /dev/sda1 /dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member" However this can't be used because if a user has a floppy configured in the BIOS but no floppy attached, GParted will wait for minutes as the kernel tries to access non-existent hardware on behalf of the blkid query. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect 3) Old versions of blkid don't recognise SWRaid members at all so always report the file system when found. Occurs with blkid v1.0 on RedHat / CentOS 5. The only way I can see how to fix all these cases is to use the mdadm command to query the configured arrays. Then use this information for first choice when detecting partition content, making the order: SWRaid members, libparted, blkid and internal. GParted shell wrapper already creates temporary blank udev rules to prevent Linux Software RAID arrays being automatically started when GParted refreshes its device information[1]. However an administrator could manually stop or start arrays or change their configuration between refreshes so GParted must load this information every refresh. On my desktop with 4 internal hard drives and 3 testing Linux Software RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the device refresh time. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Bug 756829 - SWRaid member detection enhancements
2015-10-20 13:52:19 -06:00
namespace GParted
{
Parse ATARAID members from mdadm output and /proc/mdstat (#75) Since mdadm release 3.0 (2009-06-02) [1] it has also supported external metadata formats IMSM (Intel Matrix Storage Manager) and DDF, previously only managed by dmraid. A number of distributions have switched to use mdadm and kernel MD (Multiple Devices) driver for managing these Firmware / BIOS / ATARAID arrays. These include: Fedora >= 14 [2], RHEL / CentOS >= 6 [3], SLES >= 12 [4], Ubuntu >= 16.04 LTS. Therefore additionally parse members in these ATARAID arrays included in mdadm output, and when activated using the kernel MD driver, in file /proc/mdstat. Add fstype to the SWRaid_Info cache records to distinguish members apart. So far the rest of the GParted code continues to treat all members as FS_LINUX_SWRAID. This will be resolved in following commits. Note that this in no way affects how GParted shows and partitions the array device itself, even those managed by dmraid and use the GParted DMRaid module. It only affects how GParted shows the member drives themselves. [1] mdadm ANNOUNCE-3.0 file https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/ANNOUNCE-3.0?h=mdadm-3.0 [2] Fedora 14, Storage Administration Guide, 12.5. Linux RAID Subsystem https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/raid-subsys.html "... Fedora 14 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [3] RHEL 6, Storage Administration Guide, 17.3. Linux RAID Subsystem https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/raid-subsys "mdraid also supports other metadata formats, known as external metadata. Red Hat Enterprise Linux 6 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [4] SUSE Linux Enterprise Server 12 Release Notes, 7.2.3 Driver for IMSM and DDF https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-316007 "For IMSM and DDF RAIDs the mdadm driver is used unconditionally." Closes #75 - Errors with GPT on RAID 0 ATARAID array
2019-11-17 03:39:02 -07:00
struct SWRaid_Member
{
BlockSpecial member;
Parse ATARAID members from mdadm output and /proc/mdstat (#75) Since mdadm release 3.0 (2009-06-02) [1] it has also supported external metadata formats IMSM (Intel Matrix Storage Manager) and DDF, previously only managed by dmraid. A number of distributions have switched to use mdadm and kernel MD (Multiple Devices) driver for managing these Firmware / BIOS / ATARAID arrays. These include: Fedora >= 14 [2], RHEL / CentOS >= 6 [3], SLES >= 12 [4], Ubuntu >= 16.04 LTS. Therefore additionally parse members in these ATARAID arrays included in mdadm output, and when activated using the kernel MD driver, in file /proc/mdstat. Add fstype to the SWRaid_Info cache records to distinguish members apart. So far the rest of the GParted code continues to treat all members as FS_LINUX_SWRAID. This will be resolved in following commits. Note that this in no way affects how GParted shows and partitions the array device itself, even those managed by dmraid and use the GParted DMRaid module. It only affects how GParted shows the member drives themselves. [1] mdadm ANNOUNCE-3.0 file https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/ANNOUNCE-3.0?h=mdadm-3.0 [2] Fedora 14, Storage Administration Guide, 12.5. Linux RAID Subsystem https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/raid-subsys.html "... Fedora 14 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [3] RHEL 6, Storage Administration Guide, 17.3. Linux RAID Subsystem https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/raid-subsys "mdraid also supports other metadata formats, known as external metadata. Red Hat Enterprise Linux 6 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [4] SUSE Linux Enterprise Server 12 Release Notes, 7.2.3 Driver for IMSM and DDF https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-316007 "For IMSM and DDF RAIDs the mdadm driver is used unconditionally." Closes #75 - Errors with GPT on RAID 0 ATARAID array
2019-11-17 03:39:02 -07:00
FSType fstype;
Glib::ustring array;
Glib::ustring uuid;
Glib::ustring label;
bool active;
};
Detect Linux SWRaid members by querying mdadm (#756829) Detection of Linux SWRaid members currently fails in a number of cases: 1) Arrays which use metadata type 0.90 or 1.0 store the super block at the end of the partition. So file system signatures in at least linear and mirrored arrays occur at the same offsets in the underlying partitions. As libparted only recognises file systems this is what is detected, rather than an SWRaid member. # mdadm -E -s -v ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1 devices=/dev/sda1,/dev/sdb1 ... # wipefs /dev/sda1 offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] LABEL: chimney-boot UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501 0x1fffe000 linux_raid_member [raid] LABEL: chimney:1 UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a # parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary ext4 boot, raid ... 2) Again with metadata type 0.90 or 1.0 arrays blkid may report the contained file system instead of an SWRaid member. Have a single example of this configuration with a mirrored array containing the /boot file system. Blkid reports one member as ext4 and the other as SWRaid! # blkid | egrep 'sd[ab]1' /dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot" /dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member" Bypassing the blkid cache gets the correct result. # blkid -c /dev/null /dev/sda1 /dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member" However this can't be used because if a user has a floppy configured in the BIOS but no floppy attached, GParted will wait for minutes as the kernel tries to access non-existent hardware on behalf of the blkid query. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect 3) Old versions of blkid don't recognise SWRaid members at all so always report the file system when found. Occurs with blkid v1.0 on RedHat / CentOS 5. The only way I can see how to fix all these cases is to use the mdadm command to query the configured arrays. Then use this information for first choice when detecting partition content, making the order: SWRaid members, libparted, blkid and internal. GParted shell wrapper already creates temporary blank udev rules to prevent Linux Software RAID arrays being automatically started when GParted refreshes its device information[1]. However an administrator could manually stop or start arrays or change their configuration between refreshes so GParted must load this information every refresh. On my desktop with 4 internal hard drives and 3 testing Linux Software RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the device refresh time. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Bug 756829 - SWRaid member detection enhancements
2015-10-20 13:52:19 -06:00
class SWRaid_Info
{
public:
static void load_cache();
static bool is_member( const Glib::ustring & member_path );
static bool is_member_active( const Glib::ustring & member_path );
static FSType get_fstype(const Glib::ustring& member_path);
static const Glib::ustring& get_array(const Glib::ustring& member_path);
static const Glib::ustring& get_uuid(const Glib::ustring& member_path);
static const Glib::ustring& get_label(const Glib::ustring& member_path);
Detect Linux SWRaid members by querying mdadm (#756829) Detection of Linux SWRaid members currently fails in a number of cases: 1) Arrays which use metadata type 0.90 or 1.0 store the super block at the end of the partition. So file system signatures in at least linear and mirrored arrays occur at the same offsets in the underlying partitions. As libparted only recognises file systems this is what is detected, rather than an SWRaid member. # mdadm -E -s -v ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1 devices=/dev/sda1,/dev/sdb1 ... # wipefs /dev/sda1 offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] LABEL: chimney-boot UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501 0x1fffe000 linux_raid_member [raid] LABEL: chimney:1 UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a # parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary ext4 boot, raid ... 2) Again with metadata type 0.90 or 1.0 arrays blkid may report the contained file system instead of an SWRaid member. Have a single example of this configuration with a mirrored array containing the /boot file system. Blkid reports one member as ext4 and the other as SWRaid! # blkid | egrep 'sd[ab]1' /dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot" /dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member" Bypassing the blkid cache gets the correct result. # blkid -c /dev/null /dev/sda1 /dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member" However this can't be used because if a user has a floppy configured in the BIOS but no floppy attached, GParted will wait for minutes as the kernel tries to access non-existent hardware on behalf of the blkid query. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect 3) Old versions of blkid don't recognise SWRaid members at all so always report the file system when found. Occurs with blkid v1.0 on RedHat / CentOS 5. The only way I can see how to fix all these cases is to use the mdadm command to query the configured arrays. Then use this information for first choice when detecting partition content, making the order: SWRaid members, libparted, blkid and internal. GParted shell wrapper already creates temporary blank udev rules to prevent Linux Software RAID arrays being automatically started when GParted refreshes its device information[1]. However an administrator could manually stop or start arrays or change their configuration between refreshes so GParted must load this information every refresh. On my desktop with 4 internal hard drives and 3 testing Linux Software RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the device refresh time. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Bug 756829 - SWRaid member detection enhancements
2015-10-20 13:52:19 -06:00
private:
static void initialise_if_required();
Detect Linux SWRaid members by querying mdadm (#756829) Detection of Linux SWRaid members currently fails in a number of cases: 1) Arrays which use metadata type 0.90 or 1.0 store the super block at the end of the partition. So file system signatures in at least linear and mirrored arrays occur at the same offsets in the underlying partitions. As libparted only recognises file systems this is what is detected, rather than an SWRaid member. # mdadm -E -s -v ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1 devices=/dev/sda1,/dev/sdb1 ... # wipefs /dev/sda1 offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] LABEL: chimney-boot UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501 0x1fffe000 linux_raid_member [raid] LABEL: chimney:1 UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a # parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary ext4 boot, raid ... 2) Again with metadata type 0.90 or 1.0 arrays blkid may report the contained file system instead of an SWRaid member. Have a single example of this configuration with a mirrored array containing the /boot file system. Blkid reports one member as ext4 and the other as SWRaid! # blkid | egrep 'sd[ab]1' /dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot" /dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member" Bypassing the blkid cache gets the correct result. # blkid -c /dev/null /dev/sda1 /dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member" However this can't be used because if a user has a floppy configured in the BIOS but no floppy attached, GParted will wait for minutes as the kernel tries to access non-existent hardware on behalf of the blkid query. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect 3) Old versions of blkid don't recognise SWRaid members at all so always report the file system when found. Occurs with blkid v1.0 on RedHat / CentOS 5. The only way I can see how to fix all these cases is to use the mdadm command to query the configured arrays. Then use this information for first choice when detecting partition content, making the order: SWRaid members, libparted, blkid and internal. GParted shell wrapper already creates temporary blank udev rules to prevent Linux Software RAID arrays being automatically started when GParted refreshes its device information[1]. However an administrator could manually stop or start arrays or change their configuration between refreshes so GParted must load this information every refresh. On my desktop with 4 internal hard drives and 3 testing Linux Software RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the device refresh time. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Bug 756829 - SWRaid member detection enhancements
2015-10-20 13:52:19 -06:00
static void set_command_found();
static void load_swraid_info_cache();
static SWRaid_Member & get_cache_entry_by_member( const Glib::ustring & member_path );
static Glib::ustring mdadm_to_canonical_uuid( const Glib::ustring & mdadm_uuid );
Detect Linux SWRaid members by querying mdadm (#756829) Detection of Linux SWRaid members currently fails in a number of cases: 1) Arrays which use metadata type 0.90 or 1.0 store the super block at the end of the partition. So file system signatures in at least linear and mirrored arrays occur at the same offsets in the underlying partitions. As libparted only recognises file systems this is what is detected, rather than an SWRaid member. # mdadm -E -s -v ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1 devices=/dev/sda1,/dev/sdb1 ... # wipefs /dev/sda1 offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] LABEL: chimney-boot UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501 0x1fffe000 linux_raid_member [raid] LABEL: chimney:1 UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a # parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary ext4 boot, raid ... 2) Again with metadata type 0.90 or 1.0 arrays blkid may report the contained file system instead of an SWRaid member. Have a single example of this configuration with a mirrored array containing the /boot file system. Blkid reports one member as ext4 and the other as SWRaid! # blkid | egrep 'sd[ab]1' /dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot" /dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member" Bypassing the blkid cache gets the correct result. # blkid -c /dev/null /dev/sda1 /dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member" However this can't be used because if a user has a floppy configured in the BIOS but no floppy attached, GParted will wait for minutes as the kernel tries to access non-existent hardware on behalf of the blkid query. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect 3) Old versions of blkid don't recognise SWRaid members at all so always report the file system when found. Occurs with blkid v1.0 on RedHat / CentOS 5. The only way I can see how to fix all these cases is to use the mdadm command to query the configured arrays. Then use this information for first choice when detecting partition content, making the order: SWRaid members, libparted, blkid and internal. GParted shell wrapper already creates temporary blank udev rules to prevent Linux Software RAID arrays being automatically started when GParted refreshes its device information[1]. However an administrator could manually stop or start arrays or change their configuration between refreshes so GParted must load this information every refresh. On my desktop with 4 internal hard drives and 3 testing Linux Software RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the device refresh time. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Bug 756829 - SWRaid member detection enhancements
2015-10-20 13:52:19 -06:00
static bool cache_initialised;
Detect Linux SWRaid members by querying mdadm (#756829) Detection of Linux SWRaid members currently fails in a number of cases: 1) Arrays which use metadata type 0.90 or 1.0 store the super block at the end of the partition. So file system signatures in at least linear and mirrored arrays occur at the same offsets in the underlying partitions. As libparted only recognises file systems this is what is detected, rather than an SWRaid member. # mdadm -E -s -v ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1 devices=/dev/sda1,/dev/sdb1 ... # wipefs /dev/sda1 offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] LABEL: chimney-boot UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501 0x1fffe000 linux_raid_member [raid] LABEL: chimney:1 UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a # parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary ext4 boot, raid ... 2) Again with metadata type 0.90 or 1.0 arrays blkid may report the contained file system instead of an SWRaid member. Have a single example of this configuration with a mirrored array containing the /boot file system. Blkid reports one member as ext4 and the other as SWRaid! # blkid | egrep 'sd[ab]1' /dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot" /dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member" Bypassing the blkid cache gets the correct result. # blkid -c /dev/null /dev/sda1 /dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member" However this can't be used because if a user has a floppy configured in the BIOS but no floppy attached, GParted will wait for minutes as the kernel tries to access non-existent hardware on behalf of the blkid query. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect 3) Old versions of blkid don't recognise SWRaid members at all so always report the file system when found. Occurs with blkid v1.0 on RedHat / CentOS 5. The only way I can see how to fix all these cases is to use the mdadm command to query the configured arrays. Then use this information for first choice when detecting partition content, making the order: SWRaid members, libparted, blkid and internal. GParted shell wrapper already creates temporary blank udev rules to prevent Linux Software RAID arrays being automatically started when GParted refreshes its device information[1]. However an administrator could manually stop or start arrays or change their configuration between refreshes so GParted must load this information every refresh. On my desktop with 4 internal hard drives and 3 testing Linux Software RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the device refresh time. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Bug 756829 - SWRaid member detection enhancements
2015-10-20 13:52:19 -06:00
static bool mdadm_found;
static std::vector<SWRaid_Member> swraid_info_cache;
Detect Linux SWRaid members by querying mdadm (#756829) Detection of Linux SWRaid members currently fails in a number of cases: 1) Arrays which use metadata type 0.90 or 1.0 store the super block at the end of the partition. So file system signatures in at least linear and mirrored arrays occur at the same offsets in the underlying partitions. As libparted only recognises file systems this is what is detected, rather than an SWRaid member. # mdadm -E -s -v ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1 devices=/dev/sda1,/dev/sdb1 ... # wipefs /dev/sda1 offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] LABEL: chimney-boot UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501 0x1fffe000 linux_raid_member [raid] LABEL: chimney:1 UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a # parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary ext4 boot, raid ... 2) Again with metadata type 0.90 or 1.0 arrays blkid may report the contained file system instead of an SWRaid member. Have a single example of this configuration with a mirrored array containing the /boot file system. Blkid reports one member as ext4 and the other as SWRaid! # blkid | egrep 'sd[ab]1' /dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot" /dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member" Bypassing the blkid cache gets the correct result. # blkid -c /dev/null /dev/sda1 /dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member" However this can't be used because if a user has a floppy configured in the BIOS but no floppy attached, GParted will wait for minutes as the kernel tries to access non-existent hardware on behalf of the blkid query. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect 3) Old versions of blkid don't recognise SWRaid members at all so always report the file system when found. Occurs with blkid v1.0 on RedHat / CentOS 5. The only way I can see how to fix all these cases is to use the mdadm command to query the configured arrays. Then use this information for first choice when detecting partition content, making the order: SWRaid members, libparted, blkid and internal. GParted shell wrapper already creates temporary blank udev rules to prevent Linux Software RAID arrays being automatically started when GParted refreshes its device information[1]. However an administrator could manually stop or start arrays or change their configuration between refreshes so GParted must load this information every refresh. On my desktop with 4 internal hard drives and 3 testing Linux Software RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the device refresh time. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Bug 756829 - SWRaid member detection enhancements
2015-10-20 13:52:19 -06:00
};
Parse ATARAID members from mdadm output and /proc/mdstat (#75) Since mdadm release 3.0 (2009-06-02) [1] it has also supported external metadata formats IMSM (Intel Matrix Storage Manager) and DDF, previously only managed by dmraid. A number of distributions have switched to use mdadm and kernel MD (Multiple Devices) driver for managing these Firmware / BIOS / ATARAID arrays. These include: Fedora >= 14 [2], RHEL / CentOS >= 6 [3], SLES >= 12 [4], Ubuntu >= 16.04 LTS. Therefore additionally parse members in these ATARAID arrays included in mdadm output, and when activated using the kernel MD driver, in file /proc/mdstat. Add fstype to the SWRaid_Info cache records to distinguish members apart. So far the rest of the GParted code continues to treat all members as FS_LINUX_SWRAID. This will be resolved in following commits. Note that this in no way affects how GParted shows and partitions the array device itself, even those managed by dmraid and use the GParted DMRaid module. It only affects how GParted shows the member drives themselves. [1] mdadm ANNOUNCE-3.0 file https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/ANNOUNCE-3.0?h=mdadm-3.0 [2] Fedora 14, Storage Administration Guide, 12.5. Linux RAID Subsystem https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/raid-subsys.html "... Fedora 14 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [3] RHEL 6, Storage Administration Guide, 17.3. Linux RAID Subsystem https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/raid-subsys "mdraid also supports other metadata formats, known as external metadata. Red Hat Enterprise Linux 6 uses mdraid with external metadata to access ISW / IMSM (Intel firmware RAID) sets. mdraid sets are configured and controlled through the mdadm utility." [4] SUSE Linux Enterprise Server 12 Release Notes, 7.2.3 Driver for IMSM and DDF https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-316007 "For IMSM and DDF RAIDs the mdadm driver is used unconditionally." Closes #75 - Errors with GPT on RAID 0 ATARAID array
2019-11-17 03:39:02 -07:00
Detect Linux SWRaid members by querying mdadm (#756829) Detection of Linux SWRaid members currently fails in a number of cases: 1) Arrays which use metadata type 0.90 or 1.0 store the super block at the end of the partition. So file system signatures in at least linear and mirrored arrays occur at the same offsets in the underlying partitions. As libparted only recognises file systems this is what is detected, rather than an SWRaid member. # mdadm -E -s -v ARRAY /dev/md/1 level=raid1 metadata=1.0 num-devices=2 UUID=15224a42:c25bbcd9:15db6000:4e5fe53a name=chimney:1 devices=/dev/sda1,/dev/sdb1 ... # wipefs /dev/sda1 offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] LABEL: chimney-boot UUID: 10ab5f7d-7d8a-4171-8b6a-5e973b402501 0x1fffe000 linux_raid_member [raid] LABEL: chimney:1 UUID: 15224a42-c25b-bcd9-15db-60004e5fe53a # parted /dev/sda print Model: ATA VBOX HARDDISK (scsi) Disk /dev/sda: 34.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 538MB 537MB primary ext4 boot, raid ... 2) Again with metadata type 0.90 or 1.0 arrays blkid may report the contained file system instead of an SWRaid member. Have a single example of this configuration with a mirrored array containing the /boot file system. Blkid reports one member as ext4 and the other as SWRaid! # blkid | egrep 'sd[ab]1' /dev/sda1: UUID="10ab5f7d-7d8a-4171-8b6a-5e973b402501" TYPE="ext4" LABEL="chimney-boot" /dev/sdb1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="0a095e45-9360-1b17-0ad1-1fe369e22b98" LABEL="chimney:1" TYPE="linux_raid_member" Bypassing the blkid cache gets the correct result. # blkid -c /dev/null /dev/sda1 /dev/sda1: UUID="15224a42-c25b-bcd9-15db-60004e5fe53a" UUID_SUB="d0460f90-d11a-e80a-ee1c-3d104dae7e5d" LABEL="chimney:1" TYPE="linux_raid_member" However this can't be used because if a user has a floppy configured in the BIOS but no floppy attached, GParted will wait for minutes as the kernel tries to access non-existent hardware on behalf of the blkid query. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect 3) Old versions of blkid don't recognise SWRaid members at all so always report the file system when found. Occurs with blkid v1.0 on RedHat / CentOS 5. The only way I can see how to fix all these cases is to use the mdadm command to query the configured arrays. Then use this information for first choice when detecting partition content, making the order: SWRaid members, libparted, blkid and internal. GParted shell wrapper already creates temporary blank udev rules to prevent Linux Software RAID arrays being automatically started when GParted refreshes its device information[1]. However an administrator could manually stop or start arrays or change their configuration between refreshes so GParted must load this information every refresh. On my desktop with 4 internal hard drives and 3 testing Linux Software RAID arrays, running mdadm adds between 0.20 and 0.30 seconds to the device refresh time. [1] a255abf3432ad106fac9c766f0816ada20be8e42 Prevent GParted starting stopped Linux Software RAID arrays (#709640) Bug 756829 - SWRaid member detection enhancements
2015-10-20 13:52:19 -06:00
}//GParted
#endif /* GPARTED_SWRAID_INFO_H */