* [PATCH 4/5] imsm: detail-platform improvements
From: Artur Paszkiewicz @ 2014-11-19 12:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, pawel.baldysiak, Artur Paszkiewicz
In-Reply-To: <1416401610-16209-1-git-send-email-artur.paszkiewicz@intel.com>
Print platform details per OROM, not per controller, differentiate
RST(e) platforms from legacy IMSM, print NVMe device paths, adjust port
printing to newer sysfs path.
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
---
platform-intel.c | 26 ++++++++++------
platform-intel.h | 23 ++++++++++++++
super-intel.c | 93 ++++++++++++++++++++++++++++++++++++++------------------
3 files changed, 103 insertions(+), 39 deletions(-)
diff --git a/platform-intel.c b/platform-intel.c
index ae72827..54ef37f 100644
--- a/platform-intel.c
+++ b/platform-intel.c
@@ -134,6 +134,16 @@ struct sys_dev *find_driver_devices(const char *bus, const char *driver)
static struct sys_dev *intel_devices=NULL;
static time_t valid_time = 0;
+struct sys_dev *device_by_id(__u16 device_id)
+{
+ struct sys_dev *iter;
+
+ for (iter = intel_devices; iter != NULL; iter = iter->next)
+ if (iter->dev_id == device_id)
+ return iter;
+ return NULL;
+}
+
static int devpath_to_ll(const char *dev_path, const char *entry, unsigned long long *val)
{
char path[strlen(dev_path) + strlen(entry) + 2];
@@ -219,18 +229,13 @@ struct pciExpDataStructFormat {
__u16 devListOffset;
} __attribute__ ((packed));
-struct devid_list {
- __u16 devid;
- struct devid_list *next;
-};
-
-struct orom_entry {
- struct imsm_orom orom;
- struct devid_list *devid_list;
-};
-
static struct orom_entry oroms[SYS_DEV_MAX];
+const struct orom_entry *get_oroms(void)
+{
+ return (const struct orom_entry *)&oroms;
+}
+
const struct imsm_orom *get_orom_by_device_id(__u16 dev_id)
{
int i;
@@ -529,6 +534,7 @@ const struct imsm_orom *find_imsm_nvme(struct sys_dev *hba)
.vpa = IMSM_OROM_VOLUMES_PER_ARRAY,
.vphba = IMSM_OROM_TOTAL_DISKS_NVME / 2 * IMSM_OROM_VOLUMES_PER_ARRAY,
.attr = IMSM_OROM_ATTR_2TB | IMSM_OROM_ATTR_2TB_DISK,
+ .driver_features = IMSM_OROM_CAPABILITIES_EnterpriseSystem
};
nvme_orom = add_orom(&nvme_orom_compat);
}
diff --git a/platform-intel.h b/platform-intel.h
index 6b4ebd8..3e85d44 100644
--- a/platform-intel.h
+++ b/platform-intel.h
@@ -173,6 +173,17 @@ static inline int fls(int x)
return r;
}
+static inline int imsm_orom_is_enterprise(const struct imsm_orom *orom)
+{
+ return !!(orom->driver_features & IMSM_OROM_CAPABILITIES_EnterpriseSystem);
+}
+
+static inline int imsm_orom_is_nvme(const struct imsm_orom *orom)
+{
+ return memcmp(orom->signature, IMSM_NVME_OROM_COMPAT_SIGNATURE,
+ sizeof(orom->signature)) == 0;
+}
+
enum sys_dev_type {
SYS_DEV_UNKNOWN = 0,
SYS_DEV_SAS,
@@ -194,6 +205,16 @@ struct efi_guid {
__u8 b[16];
};
+struct devid_list {
+ __u16 devid;
+ struct devid_list *next;
+};
+
+struct orom_entry {
+ struct imsm_orom orom;
+ struct devid_list *devid_list;
+};
+
static inline char *guid_str(char *buf, struct efi_guid guid)
{
sprintf(buf, "%02x%02x%02x%02x-%02x%02x-%02x%02x-"
@@ -215,4 +236,6 @@ int devt_attached_to_hba(dev_t dev, const char *hba_path);
char *devt_to_devpath(dev_t dev);
int path_attached_to_hba(const char *disk_path, const char *hba_path);
const char *get_sys_dev_type(enum sys_dev_type);
+const struct orom_entry * get_oroms(void);
const struct imsm_orom *get_orom_by_device_id(__u16 device_id);
+struct sys_dev *device_by_id(__u16 device_id);
diff --git a/super-intel.c b/super-intel.c
index d2ee1c6..4c53019 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -1709,7 +1709,8 @@ static int ahci_enumerate_ports(const char *hba_path, int port_count, int host_b
break;
}
*c = '\0';
- if (sscanf(&path[hba_len], "host%d", &port) == 1)
+ if ((sscanf(&path[hba_len], "ata%d", &port) == 1) ||
+ ((sscanf(&path[hba_len], "host%d", &port) == 1)))
port -= host_base;
else {
if (verbose > 0) {
@@ -1768,6 +1769,8 @@ static void print_found_intel_controllers(struct sys_dev *elem)
fprintf(stderr, "SATA ");
else if (elem->type == SYS_DEV_SAS)
fprintf(stderr, "SAS ");
+ else if (elem->type == SYS_DEV_NVME)
+ fprintf(stderr, "NVMe ");
fprintf(stderr, "RAID controller");
if (elem->pci_id)
fprintf(stderr, " at %s", elem->pci_id);
@@ -1789,7 +1792,8 @@ static int ahci_get_port_count(const char *hba_path, int *port_count)
for (ent = readdir(dir); ent; ent = readdir(dir)) {
int host;
- if (sscanf(ent->d_name, "host%d", &host) != 1)
+ if ((sscanf(ent->d_name, "ata%d", &host) != 1) &&
+ ((sscanf(ent->d_name, "host%d", &host) != 1)))
continue;
if (*port_count == 0)
host_base = host;
@@ -1805,9 +1809,15 @@ static int ahci_get_port_count(const char *hba_path, int *port_count)
static void print_imsm_capability(const struct imsm_orom *orom)
{
- printf(" Platform : Intel(R) Matrix Storage Manager\n");
- printf(" Version : %d.%d.%d.%d\n", orom->major_ver, orom->minor_ver,
- orom->hotfix_ver, orom->build);
+ printf(" Platform : Intel(R) ");
+ if (orom->capabilities == 0 && orom->driver_features == 0)
+ printf("Matrix Storage Manager\n");
+ else
+ printf("Rapid Storage Technology%s\n",
+ imsm_orom_is_enterprise(orom) ? " enterprise" : "");
+ if (orom->major_ver || orom->minor_ver || orom->hotfix_ver || orom->build)
+ printf(" Version : %d.%d.%d.%d\n", orom->major_ver,
+ orom->minor_ver, orom->hotfix_ver, orom->build);
printf(" RAID Levels :%s%s%s%s%s\n",
imsm_orom_has_raid0(orom) ? " raid0" : "",
imsm_orom_has_raid1(orom) ? " raid1" : "",
@@ -1836,16 +1846,18 @@ static void print_imsm_capability(const struct imsm_orom *orom)
printf(" 2TB disks :%s supported\n",
(orom->attr & IMSM_OROM_ATTR_2TB_DISK)?"":" not");
printf(" Max Disks : %d\n", orom->tds);
- printf(" Max Volumes : %d per array, %d per controller\n",
- orom->vpa, orom->vphba);
+ printf(" Max Volumes : %d per array, %d per %s\n",
+ orom->vpa, orom->vphba,
+ imsm_orom_is_nvme(orom) ? "platform" : "controller");
return;
}
static void print_imsm_capability_export(const struct imsm_orom *orom)
{
printf("MD_FIRMWARE_TYPE=imsm\n");
- printf("IMSM_VERSION=%d.%d.%d.%d\n",orom->major_ver, orom->minor_ver,
- orom->hotfix_ver, orom->build);
+ if (orom->major_ver || orom->minor_ver || orom->hotfix_ver || orom->build)
+ printf("IMSM_VERSION=%d.%d.%d.%d\n", orom->major_ver, orom->minor_ver,
+ orom->hotfix_ver, orom->build);
printf("IMSM_SUPPORTED_RAID_LEVELS=%s%s%s%s%s\n",
imsm_orom_has_raid0(orom) ? "raid0 " : "",
imsm_orom_has_raid1(orom) ? "raid1 " : "",
@@ -1889,7 +1901,6 @@ static int detail_platform_imsm(int verbose, int enumerate_only, char *controlle
* platform capabilities. If raid support is disabled in the BIOS the
* option-rom capability structure will not be available.
*/
- const struct imsm_orom *orom;
struct sys_dev *list, *hba;
int host_base = 0;
int port_count = 0;
@@ -1922,15 +1933,42 @@ static int detail_platform_imsm(int verbose, int enumerate_only, char *controlle
print_found_intel_controllers(list);
for (hba = list; hba; hba = hba->next) {
- if (controller_path && (compare_paths(hba->path,controller_path) != 0))
+ if (controller_path && (compare_paths(hba->path, controller_path) != 0))
continue;
- orom = find_imsm_capability(hba);
- if (!orom)
+ if (!find_imsm_capability(hba)) {
pr_err("imsm capabilities not found for controller: %s (type %s)\n",
hba->path, get_sys_dev_type(hba->type));
- else {
- result = 0;
- print_imsm_capability(orom);
+ continue;
+ }
+ result = 0;
+ }
+
+ if (controller_path && result == 1) {
+ pr_err("no active Intel(R) RAID controller found under %s\n",
+ controller_path);
+ return result;
+ }
+
+ const struct orom_entry *oroms = get_oroms();
+ int i;
+
+ for (i = 0; i < SYS_DEV_MAX && oroms[i].devid_list; i++) {
+ print_imsm_capability(&oroms[i].orom);
+
+ if (imsm_orom_is_nvme(&oroms[i].orom)) {
+ for (hba = list; hba; hba = hba->next) {
+ if (hba->type == SYS_DEV_NVME)
+ printf(" NVMe Device : %s\n", hba->path);
+ }
+ continue;
+ }
+
+ struct devid_list *devid;
+ for (devid = oroms[i].devid_list; devid; devid = devid->next) {
+ hba = device_by_id(devid->devid);
+ if (!hba)
+ continue;
+
printf(" I/O Controller : %s (%s)\n",
hba->path, get_sys_dev_type(hba->type));
if (hba->type == SYS_DEV_SATA) {
@@ -1943,18 +1981,14 @@ static int detail_platform_imsm(int verbose, int enumerate_only, char *controlle
}
}
}
+ printf("\n");
}
- if (controller_path && result == 1)
- pr_err("no active Intel(R) RAID "
- "controller found under %s\n",controller_path);
-
return result;
}
static int export_detail_platform_imsm(int verbose, char *controller_path)
{
- const struct imsm_orom *orom;
struct sys_dev *list, *hba;
int result=1;
@@ -1969,17 +2003,18 @@ static int export_detail_platform_imsm(int verbose, char *controller_path)
for (hba = list; hba; hba = hba->next) {
if (controller_path && (compare_paths(hba->path,controller_path) != 0))
continue;
- orom = find_imsm_capability(hba);
- if (!orom) {
- if (verbose > 0)
- pr_err("IMSM_DETAIL_PLATFORM_ERROR=NO_IMSM_CAPABLE_DEVICE_UNDER_%s\n",hba->path);
- }
- else {
- print_imsm_capability_export(orom);
+ if (!find_imsm_capability(hba) && verbose > 0)
+ pr_err("IMSM_DETAIL_PLATFORM_ERROR=NO_IMSM_CAPABLE_DEVICE_UNDER_%s\n", hba->path);
+ else
result = 0;
- }
}
+ const struct orom_entry *oroms = get_oroms();
+ int i;
+
+ for (i = 0; i < SYS_DEV_MAX && oroms[i].devid_list; i++)
+ print_imsm_capability_export(&oroms[i].orom);
+
return result;
}
--
1.8.4.5
^ permalink raw reply related
* [PATCH 3/5] imsm: add support for NVMe devices
From: Artur Paszkiewicz @ 2014-11-19 12:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, pawel.baldysiak, Artur Paszkiewicz
In-Reply-To: <1416401610-16209-1-git-send-email-artur.paszkiewicz@intel.com>
From: Pawel Baldysiak <pawel.baldysiak@intel.com>
Recognize Intel(R) NVMe devices as IMSM-capable.
Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
---
platform-intel.c | 46 ++++++++++++++++++++++++++++++++++++++++++++--
platform-intel.h | 5 +++++
super-intel.c | 11 +++++++----
3 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/platform-intel.c b/platform-intel.c
index c5a0aa4..ae72827 100644
--- a/platform-intel.c
+++ b/platform-intel.c
@@ -65,6 +65,8 @@ struct sys_dev *find_driver_devices(const char *bus, const char *driver)
type = SYS_DEV_SAS;
else if (strcmp(driver, "ahci") == 0)
type = SYS_DEV_SATA;
+ else if (strcmp(driver, "nvme") == 0)
+ type = SYS_DEV_NVME;
else
type = SYS_DEV_UNKNOWN;
@@ -174,7 +176,7 @@ static __u16 devpath_to_vendor(const char *dev_path)
struct sys_dev *find_intel_devices(void)
{
- struct sys_dev *ahci, *isci;
+ struct sys_dev *ahci, *isci, *nvme;
if (valid_time > time(0) - 10)
return intel_devices;
@@ -184,14 +186,24 @@ struct sys_dev *find_intel_devices(void)
isci = find_driver_devices("pci", "isci");
ahci = find_driver_devices("pci", "ahci");
+ nvme = find_driver_devices("pci", "nvme");
- if (!ahci) {
+ if (!isci && !ahci) {
+ ahci = nvme;
+ } else if (!ahci) {
ahci = isci;
+ struct sys_dev *elem = ahci;
+ while (elem->next)
+ elem = elem->next;
+ elem->next = nvme;
} else {
struct sys_dev *elem = ahci;
while (elem->next)
elem = elem->next;
elem->next = isci;
+ while (elem->next)
+ elem = elem->next;
+ elem->next = nvme;
}
intel_devices = ahci;
valid_time = time(0);
@@ -497,6 +509,33 @@ const struct imsm_orom *find_imsm_efi(struct sys_dev *hba)
return ret;
}
+const struct imsm_orom *find_imsm_nvme(struct sys_dev *hba)
+{
+ static const struct imsm_orom *nvme_orom;
+
+ if (hba->type != SYS_DEV_NVME)
+ return NULL;
+
+ if (!nvme_orom) {
+ struct imsm_orom nvme_orom_compat = {
+ .signature = IMSM_NVME_OROM_COMPAT_SIGNATURE,
+ .rlc = IMSM_OROM_RLC_RAID0 | IMSM_OROM_RLC_RAID1 |
+ IMSM_OROM_RLC_RAID10 | IMSM_OROM_RLC_RAID5,
+ .sss = IMSM_OROM_SSS_4kB | IMSM_OROM_SSS_8kB |
+ IMSM_OROM_SSS_16kB | IMSM_OROM_SSS_32kB |
+ IMSM_OROM_SSS_64kB | IMSM_OROM_SSS_128kB,
+ .dpa = IMSM_OROM_DISKS_PER_ARRAY_NVME,
+ .tds = IMSM_OROM_TOTAL_DISKS_NVME,
+ .vpa = IMSM_OROM_VOLUMES_PER_ARRAY,
+ .vphba = IMSM_OROM_TOTAL_DISKS_NVME / 2 * IMSM_OROM_VOLUMES_PER_ARRAY,
+ .attr = IMSM_OROM_ATTR_2TB | IMSM_OROM_ATTR_2TB_DISK,
+ };
+ nvme_orom = add_orom(&nvme_orom_compat);
+ }
+ add_orom_device_id(nvme_orom, hba->dev_id);
+ return nvme_orom;
+}
+
const struct imsm_orom *find_imsm_capability(struct sys_dev *hba)
{
const struct imsm_orom *cap = get_orom_by_device_id(hba->dev_id);
@@ -504,10 +543,13 @@ const struct imsm_orom *find_imsm_capability(struct sys_dev *hba)
if (cap)
return cap;
+ if (hba->type == SYS_DEV_NVME)
+ return find_imsm_nvme(hba);
if ((cap = find_imsm_efi(hba)) != NULL)
return cap;
if ((cap = find_imsm_hba_orom(hba)) != NULL)
return cap;
+
return NULL;
}
diff --git a/platform-intel.h b/platform-intel.h
index e41f386..6b4ebd8 100644
--- a/platform-intel.h
+++ b/platform-intel.h
@@ -23,6 +23,7 @@
struct imsm_orom {
__u8 signature[4];
#define IMSM_OROM_SIGNATURE "$VER"
+ #define IMSM_NVME_OROM_COMPAT_SIGNATURE "$NVM"
__u8 table_ver_major; /* Currently 2 (can change with future revs) */
__u8 table_ver_minor; /* Currently 2 (can change with future revs) */
__u16 major_ver; /* Example: 8 as in 8.6.0.1020 */
@@ -60,12 +61,15 @@ struct imsm_orom {
#define IMSM_OROM_SSS_64MB (1 << 15)
__u16 dpa; /* Disks Per Array supported */
#define IMSM_OROM_DISKS_PER_ARRAY 6
+ #define IMSM_OROM_DISKS_PER_ARRAY_NVME 12
__u16 tds; /* Total Disks Supported */
#define IMSM_OROM_TOTAL_DISKS 6
+ #define IMSM_OROM_TOTAL_DISKS_NVME 12
__u8 vpa; /* # Volumes Per Array supported */
#define IMSM_OROM_VOLUMES_PER_ARRAY 2
__u8 vphba; /* # Volumes Per Host Bus Adapter supported */
#define IMSM_OROM_VOLUMES_PER_HBA 4
+ #define IMSM_OROM_VOLUMES_PER_HBA_NVME 4
/* Attributes supported. This should map to the
* attributes in the MPB. Also, lower 16 bits
* should match/duplicate RLC bits above.
@@ -173,6 +177,7 @@ enum sys_dev_type {
SYS_DEV_UNKNOWN = 0,
SYS_DEV_SAS,
SYS_DEV_SATA,
+ SYS_DEV_NVME,
SYS_DEV_MAX
};
diff --git a/super-intel.c b/super-intel.c
index dabf011..d2ee1c6 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -509,7 +509,8 @@ struct imsm_update_add_remove_disk {
static const char *_sys_dev_type[] = {
[SYS_DEV_UNKNOWN] = "Unknown",
[SYS_DEV_SAS] = "SAS",
- [SYS_DEV_SATA] = "SATA"
+ [SYS_DEV_SATA] = "SATA",
+ [SYS_DEV_NVME] = "NVMe"
};
const char *get_sys_dev_type(enum sys_dev_type type)
@@ -559,7 +560,7 @@ static int attach_hba_to_super(struct intel_super *super, struct sys_dev *device
hba = super->hba;
/* Intel metadata allows for all disks attached to the same type HBA.
- * Do not sypport odf HBA types mixing
+ * Do not support HBA types mixing
*/
if (device->type != hba->type)
return 2;
@@ -3841,9 +3842,9 @@ static int find_intel_hba_capability(int fd, struct intel_super *super, char *de
" but the container is assigned to Intel(R) "
"%s RAID controller (",
devname,
- hba_name->path,
+ get_sys_dev_type(hba_name->type),
hba_name->pci_id ? : "Err!",
- get_sys_dev_type(hba_name->type));
+ get_sys_dev_type(super->hba->type));
while (hba) {
fprintf(stderr, "%s", hba->pci_id ? : "Err!");
@@ -3860,6 +3861,7 @@ static int find_intel_hba_capability(int fd, struct intel_super *super, char *de
super->orom = find_imsm_capability(hba_name);
if (!super->orom)
return 3;
+
return 0;
}
@@ -5916,6 +5918,7 @@ validate_geometry_imsm_orom(struct intel_super *super, int level, int layout,
pr_vrb(": platform does not support a volume size over 2TB\n");
return 0;
}
+
return 1;
}
--
1.8.4.5
^ permalink raw reply related
* [PATCH 2/5] imsm: support for second and combined AHCI controllers in UEFI mode
From: Artur Paszkiewicz @ 2014-11-19 12:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, pawel.baldysiak, Artur Paszkiewicz
In-Reply-To: <1416401610-16209-1-git-send-email-artur.paszkiewicz@intel.com>
Grantly platform introduces a second AHCI controller (sSATA) and two new
UEFI variables for the RSTe firmware. This patch adds support for those
variables in order to correctly determine IMSM platform capabilities in
UEFI mode.
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
---
platform-intel.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/platform-intel.c b/platform-intel.c
index f779d02..c5a0aa4 100644
--- a/platform-intel.c
+++ b/platform-intel.c
@@ -401,6 +401,8 @@ static const struct imsm_orom *find_imsm_hba_orom(struct sys_dev *hba)
#define SYS_EFI_VAR_PATH "/sys/firmware/efi/vars"
#define SCU_PROP "RstScuV"
#define AHCI_PROP "RstSataV"
+#define AHCI_SSATA_PROP "RstsSatV"
+#define AHCI_CSATA_PROP "RstCSatV"
#define VENDOR_GUID \
EFI_GUID(0x193dfefa, 0xa445, 0x4302, 0x99, 0xd8, 0xef, 0x3a, 0xad, 0x1a, 0x04, 0xc6)
@@ -455,6 +457,7 @@ const struct imsm_orom *find_imsm_efi(struct sys_dev *hba)
{
struct imsm_orom orom;
const struct imsm_orom *ret;
+ int err;
if (check_env("IMSM_TEST_AHCI_EFI") || check_env("IMSM_TEST_SCU_EFI"))
return imsm_platform_test(hba);
@@ -466,7 +469,26 @@ const struct imsm_orom *find_imsm_efi(struct sys_dev *hba)
if (hba->type == SYS_DEV_SATA && hba->class != PCI_CLASS_RAID_CNTRL)
return NULL;
- if (read_efi_variable(&orom, sizeof(orom), hba->type == SYS_DEV_SAS ? SCU_PROP : AHCI_PROP, VENDOR_GUID))
+ err = read_efi_variable(&orom, sizeof(orom), hba->type == SYS_DEV_SAS ? SCU_PROP : AHCI_PROP, VENDOR_GUID);
+
+ /* try to read variable for second AHCI controller */
+ if (err && hba->type == SYS_DEV_SATA)
+ err = read_efi_variable(&orom, sizeof(orom), AHCI_SSATA_PROP, VENDOR_GUID);
+
+ /* try to read variable for combined AHCI controllers */
+ if (err && hba->type == SYS_DEV_SATA) {
+ static const struct imsm_orom *csata;
+
+ err = read_efi_variable(&orom, sizeof(orom), AHCI_CSATA_PROP, VENDOR_GUID);
+ if (!err) {
+ if (!csata)
+ csata = add_orom(&orom);
+ add_orom_device_id(csata, hba->dev_id);
+ return csata;
+ }
+ }
+
+ if (err)
return NULL;
ret = add_orom(&orom);
--
1.8.4.5
^ permalink raw reply related
* [PATCH 1/5] imsm: support for OROMs shared by multiple HBAs
From: Artur Paszkiewicz @ 2014-11-19 12:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, pawel.baldysiak, Artur Paszkiewicz
In-Reply-To: <1416401610-16209-1-git-send-email-artur.paszkiewicz@intel.com>
HBAs can share OROMs (e.g. SATA/sSATA). They are matched by PCI device
id. Removed populated_orom/efi and imsm_orom/efi arrays - they are
replaced by oroms array and functions get_orom_by_device_id(),
add_orom(), add_orom_device_id().
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
---
platform-intel.c | 248 ++++++++++++++++++++++++++++++++-----------------------
platform-intel.h | 5 +-
super-intel.c | 134 +++++++++++++++++++++---------
3 files changed, 243 insertions(+), 144 deletions(-)
diff --git a/platform-intel.c b/platform-intel.c
index f347382..f779d02 100644
--- a/platform-intel.c
+++ b/platform-intel.c
@@ -59,6 +59,7 @@ struct sys_dev *find_driver_devices(const char *bus, const char *driver)
struct sys_dev *list = NULL;
enum sys_dev_type type;
unsigned long long dev_id;
+ unsigned long long class;
if (strcmp(driver, "isci") == 0)
type = SYS_DEV_SAS;
@@ -99,6 +100,9 @@ struct sys_dev *find_driver_devices(const char *bus, const char *driver)
if (devpath_to_ll(path, "device", &dev_id) != 0)
continue;
+ if (devpath_to_ll(path, "class", &class) != 0)
+ continue;
+
/* start / add list entry */
if (!head) {
head = xmalloc(sizeof(*head));
@@ -114,6 +118,7 @@ struct sys_dev *find_driver_devices(const char *bus, const char *driver)
}
list->dev_id = (__u16) dev_id;
+ list->class = (__u32) class;
list->type = type;
list->path = realpath(path, NULL);
list->next = NULL;
@@ -127,16 +132,6 @@ struct sys_dev *find_driver_devices(const char *bus, const char *driver)
static struct sys_dev *intel_devices=NULL;
static time_t valid_time = 0;
-static enum sys_dev_type device_type_by_id(__u16 device_id)
-{
- struct sys_dev *iter;
-
- for(iter = intel_devices; iter != NULL; iter = iter->next)
- if (iter->dev_id == device_id)
- return iter->type;
- return SYS_DEV_UNKNOWN;
-}
-
static int devpath_to_ll(const char *dev_path, const char *entry, unsigned long long *val)
{
char path[strlen(dev_path) + strlen(entry) + 2];
@@ -209,16 +204,79 @@ struct pciExpDataStructFormat {
__u8 ver[4];
__u16 vendorID;
__u16 deviceID;
+ __u16 devListOffset;
} __attribute__ ((packed));
-static struct imsm_orom imsm_orom[SYS_DEV_MAX];
-static int populated_orom[SYS_DEV_MAX];
+struct devid_list {
+ __u16 devid;
+ struct devid_list *next;
+};
+
+struct orom_entry {
+ struct imsm_orom orom;
+ struct devid_list *devid_list;
+};
+
+static struct orom_entry oroms[SYS_DEV_MAX];
+
+const struct imsm_orom *get_orom_by_device_id(__u16 dev_id)
+{
+ int i;
+ struct devid_list *list;
+
+ for (i = 0; i < SYS_DEV_MAX; i++) {
+ for (list = oroms[i].devid_list; list; list = list->next) {
+ if (list->devid == dev_id)
+ return &oroms[i].orom;
+ }
+ }
+ return NULL;
+}
+
+static const struct imsm_orom *add_orom(const struct imsm_orom *orom)
+{
+ int i;
+
+ for (i = 0; i < SYS_DEV_MAX; i++) {
+ if (&oroms[i].orom == orom)
+ return orom;
+ if (oroms[i].orom.signature[0] == 0) {
+ oroms[i].orom = *orom;
+ return &oroms[i].orom;
+ }
+ }
+ return NULL;
+}
+
+static void add_orom_device_id(const struct imsm_orom *orom, __u16 dev_id)
+{
+ int i;
+ struct devid_list *list;
+ struct devid_list *prev = NULL;
+
+ for (i = 0; i < SYS_DEV_MAX; i++) {
+ if (&oroms[i].orom == orom) {
+ for (list = oroms[i].devid_list; list; prev = list, list = list->next) {
+ if (list->devid == dev_id)
+ return;
+ }
+ list = xmalloc(sizeof(struct devid_list));
+ list->devid = dev_id;
+ list->next = NULL;
+
+ if (prev == NULL)
+ oroms[i].devid_list = list;
+ else
+ prev->next = list;
+ return;
+ }
+ }
+}
static int scan(const void *start, const void *end, const void *data)
{
int offset;
- const struct imsm_orom *imsm_mem;
- int dev;
+ const struct imsm_orom *imsm_mem = NULL;
int len = (end - start);
struct pciExpDataStructFormat *ptr= (struct pciExpDataStructFormat *)data;
@@ -231,81 +289,83 @@ static int scan(const void *start, const void *end, const void *data)
(ulong) __le16_to_cpu(ptr->vendorID),
(ulong) __le16_to_cpu(ptr->deviceID));
- if (__le16_to_cpu(ptr->vendorID) == 0x8086) {
- /* serach attached intel devices by device id from OROM */
- dev = device_type_by_id(__le16_to_cpu(ptr->deviceID));
- if (dev == SYS_DEV_UNKNOWN)
- return 0;
- }
- else
+ if (__le16_to_cpu(ptr->vendorID) != 0x8086)
return 0;
for (offset = 0; offset < len; offset += 4) {
- imsm_mem = start + offset;
- if ((memcmp(imsm_mem->signature, "$VER", 4) == 0)) {
- imsm_orom[dev] = *imsm_mem;
- populated_orom[dev] = 1;
- return populated_orom[SYS_DEV_SATA] && populated_orom[SYS_DEV_SAS];
+ const void *mem = start + offset;
+
+ if ((memcmp(mem, IMSM_OROM_SIGNATURE, 4) == 0)) {
+ imsm_mem = mem;
+ break;
}
}
+
+ if (!imsm_mem)
+ return 0;
+
+ const struct imsm_orom *orom = add_orom(imsm_mem);
+
+ if (ptr->devListOffset) {
+ const __u16 *dev_list = (void *)ptr + ptr->devListOffset;
+ int i;
+
+ for (i = 0; dev_list[i] != 0; i++)
+ add_orom_device_id(orom, dev_list[i]);
+ } else {
+ add_orom_device_id(orom, __le16_to_cpu(ptr->deviceID));
+ }
+
return 0;
}
-const struct imsm_orom *imsm_platform_test(enum sys_dev_type hba_id, int *populated,
- struct imsm_orom *imsm_orom)
+const struct imsm_orom *imsm_platform_test(struct sys_dev *hba)
{
- memset(imsm_orom, 0, sizeof(*imsm_orom));
- imsm_orom->rlc = IMSM_OROM_RLC_RAID0 | IMSM_OROM_RLC_RAID1 |
- IMSM_OROM_RLC_RAID10 | IMSM_OROM_RLC_RAID5;
- imsm_orom->sss = IMSM_OROM_SSS_4kB | IMSM_OROM_SSS_8kB |
- IMSM_OROM_SSS_16kB | IMSM_OROM_SSS_32kB |
- IMSM_OROM_SSS_64kB | IMSM_OROM_SSS_128kB |
- IMSM_OROM_SSS_256kB | IMSM_OROM_SSS_512kB |
- IMSM_OROM_SSS_1MB | IMSM_OROM_SSS_2MB;
- imsm_orom->dpa = IMSM_OROM_DISKS_PER_ARRAY;
- imsm_orom->tds = IMSM_OROM_TOTAL_DISKS;
- imsm_orom->vpa = IMSM_OROM_VOLUMES_PER_ARRAY;
- imsm_orom->vphba = IMSM_OROM_VOLUMES_PER_HBA;
- imsm_orom->attr = imsm_orom->rlc | IMSM_OROM_ATTR_ChecksumVerify;
- *populated = 1;
+ struct imsm_orom orom = {
+ .signature = IMSM_OROM_SIGNATURE,
+ .rlc = IMSM_OROM_RLC_RAID0 | IMSM_OROM_RLC_RAID1 |
+ IMSM_OROM_RLC_RAID10 | IMSM_OROM_RLC_RAID5,
+ .sss = IMSM_OROM_SSS_4kB | IMSM_OROM_SSS_8kB |
+ IMSM_OROM_SSS_16kB | IMSM_OROM_SSS_32kB |
+ IMSM_OROM_SSS_64kB | IMSM_OROM_SSS_128kB |
+ IMSM_OROM_SSS_256kB | IMSM_OROM_SSS_512kB |
+ IMSM_OROM_SSS_1MB | IMSM_OROM_SSS_2MB,
+ .dpa = IMSM_OROM_DISKS_PER_ARRAY,
+ .tds = IMSM_OROM_TOTAL_DISKS,
+ .vpa = IMSM_OROM_VOLUMES_PER_ARRAY,
+ .vphba = IMSM_OROM_VOLUMES_PER_HBA
+ };
+ orom.attr = orom.rlc | IMSM_OROM_ATTR_ChecksumVerify;
if (check_env("IMSM_TEST_OROM_NORAID5")) {
- imsm_orom->rlc = IMSM_OROM_RLC_RAID0 | IMSM_OROM_RLC_RAID1 |
+ orom.rlc = IMSM_OROM_RLC_RAID0 | IMSM_OROM_RLC_RAID1 |
IMSM_OROM_RLC_RAID10;
}
- if (check_env("IMSM_TEST_AHCI_EFI_NORAID5") && (hba_id == SYS_DEV_SAS)) {
- imsm_orom->rlc = IMSM_OROM_RLC_RAID0 | IMSM_OROM_RLC_RAID1 |
+ if (check_env("IMSM_TEST_AHCI_EFI_NORAID5") && (hba->type == SYS_DEV_SAS)) {
+ orom.rlc = IMSM_OROM_RLC_RAID0 | IMSM_OROM_RLC_RAID1 |
IMSM_OROM_RLC_RAID10;
}
- if (check_env("IMSM_TEST_SCU_EFI_NORAID5") && (hba_id == SYS_DEV_SATA)) {
- imsm_orom->rlc = IMSM_OROM_RLC_RAID0 | IMSM_OROM_RLC_RAID1 |
+ if (check_env("IMSM_TEST_SCU_EFI_NORAID5") && (hba->type == SYS_DEV_SATA)) {
+ orom.rlc = IMSM_OROM_RLC_RAID0 | IMSM_OROM_RLC_RAID1 |
IMSM_OROM_RLC_RAID10;
}
- return imsm_orom;
+ const struct imsm_orom *ret = add_orom(&orom);
+
+ add_orom_device_id(ret, hba->dev_id);
+
+ return ret;
}
-static const struct imsm_orom *find_imsm_hba_orom(enum sys_dev_type hba_id)
+static const struct imsm_orom *find_imsm_hba_orom(struct sys_dev *hba)
{
unsigned long align;
- if (hba_id >= SYS_DEV_MAX)
- return NULL;
+ if (check_env("IMSM_TEST_OROM"))
+ return imsm_platform_test(hba);
- /* it's static data so we only need to read it once */
- if (populated_orom[hba_id]) {
- dprintf("OROM CAP: %p, pid: %d pop: %d\n",
- &imsm_orom[hba_id], (int) getpid(), populated_orom[hba_id]);
- return &imsm_orom[hba_id];
- }
- if (check_env("IMSM_TEST_OROM")) {
- dprintf("OROM CAP: %p, pid: %d pop: %d\n",
- &imsm_orom[hba_id], (int) getpid(), populated_orom[hba_id]);
- return imsm_platform_test(hba_id, &populated_orom[hba_id], &imsm_orom[hba_id]);
- }
/* return empty OROM capabilities in EFI test mode */
- if (check_env("IMSM_TEST_AHCI_EFI") ||
- check_env("IMSM_TEST_SCU_EFI"))
+ if (check_env("IMSM_TEST_AHCI_EFI") || check_env("IMSM_TEST_SCU_EFI"))
return NULL;
find_intel_devices();
@@ -325,9 +385,7 @@ static const struct imsm_orom *find_imsm_hba_orom(enum sys_dev_type hba_id)
scan_adapter_roms(scan);
probe_roms_exit();
- if (populated_orom[hba_id])
- return &imsm_orom[hba_id];
- return NULL;
+ return get_orom_by_device_id(hba->dev_id);
}
#define GUID_STR_MAX 37 /* according to GUID format:
@@ -347,9 +405,7 @@ static const struct imsm_orom *find_imsm_hba_orom(enum sys_dev_type hba_id)
#define VENDOR_GUID \
EFI_GUID(0x193dfefa, 0xa445, 0x4302, 0x99, 0xd8, 0xef, 0x3a, 0xad, 0x1a, 0x04, 0xc6)
-int populated_efi[SYS_DEV_MAX] = { 0, 0 };
-
-static struct imsm_orom imsm_efi[SYS_DEV_MAX];
+#define PCI_CLASS_RAID_CNTRL 0x010400
int read_efi_variable(void *buffer, ssize_t buf_size, char *variable_name, struct efi_guid guid)
{
@@ -395,54 +451,40 @@ int read_efi_variable(void *buffer, ssize_t buf_size, char *variable_name, struc
return 0;
}
-const struct imsm_orom *find_imsm_efi(enum sys_dev_type hba_id)
+const struct imsm_orom *find_imsm_efi(struct sys_dev *hba)
{
- if (hba_id >= SYS_DEV_MAX)
- return NULL;
+ struct imsm_orom orom;
+ const struct imsm_orom *ret;
- dprintf("EFI CAP: %p, pid: %d pop: %d\n",
- &imsm_efi[hba_id], (int) getpid(), populated_efi[hba_id]);
+ if (check_env("IMSM_TEST_AHCI_EFI") || check_env("IMSM_TEST_SCU_EFI"))
+ return imsm_platform_test(hba);
- /* it's static data so we only need to read it once */
- if (populated_efi[hba_id]) {
- dprintf("EFI CAP: %p, pid: %d pop: %d\n",
- &imsm_efi[hba_id], (int) getpid(), populated_efi[hba_id]);
- return &imsm_efi[hba_id];
- }
- if (check_env("IMSM_TEST_AHCI_EFI") ||
- check_env("IMSM_TEST_SCU_EFI")) {
- dprintf("OROM CAP: %p, pid: %d pop: %d\n",
- &imsm_efi[hba_id], (int) getpid(), populated_efi[hba_id]);
- return imsm_platform_test(hba_id, &populated_efi[hba_id], &imsm_efi[hba_id]);
- }
/* OROM test is set, return that there is no EFI capabilities */
if (check_env("IMSM_TEST_OROM"))
return NULL;
- if (read_efi_variable(&imsm_efi[hba_id], sizeof(imsm_efi[0]), hba_id == SYS_DEV_SAS ? SCU_PROP : AHCI_PROP, VENDOR_GUID)) {
- populated_efi[hba_id] = 0;
+ if (hba->type == SYS_DEV_SATA && hba->class != PCI_CLASS_RAID_CNTRL)
return NULL;
- }
- populated_efi[hba_id] = 1;
- return &imsm_efi[hba_id];
-}
+ if (read_efi_variable(&orom, sizeof(orom), hba->type == SYS_DEV_SAS ? SCU_PROP : AHCI_PROP, VENDOR_GUID))
+ return NULL;
-/*
- * backward interface compatibility
- */
-const struct imsm_orom *find_imsm_orom(void)
-{
- return find_imsm_hba_orom(SYS_DEV_SATA);
+ ret = add_orom(&orom);
+ add_orom_device_id(ret, hba->dev_id);
+
+ return ret;
}
-const struct imsm_orom *find_imsm_capability(enum sys_dev_type hba_id)
+const struct imsm_orom *find_imsm_capability(struct sys_dev *hba)
{
- const struct imsm_orom *cap=NULL;
+ const struct imsm_orom *cap = get_orom_by_device_id(hba->dev_id);
+
+ if (cap)
+ return cap;
- if ((cap = find_imsm_efi(hba_id)) != NULL)
+ if ((cap = find_imsm_efi(hba)) != NULL)
return cap;
- if ((cap = find_imsm_hba_orom(hba_id)) != NULL)
+ if ((cap = find_imsm_hba_orom(hba)) != NULL)
return cap;
return NULL;
}
diff --git a/platform-intel.h b/platform-intel.h
index 8226be3..e41f386 100644
--- a/platform-intel.h
+++ b/platform-intel.h
@@ -22,6 +22,7 @@
/* The IMSM Capability (IMSM AHCI and ISCU OROM/EFI variable) Version Table definition */
struct imsm_orom {
__u8 signature[4];
+ #define IMSM_OROM_SIGNATURE "$VER"
__u8 table_ver_major; /* Currently 2 (can change with future revs) */
__u8 table_ver_minor; /* Currently 2 (can change with future revs) */
__u16 major_ver; /* Example: 8 as in 8.6.0.1020 */
@@ -180,6 +181,7 @@ struct sys_dev {
char *path;
char *pci_id;
__u16 dev_id;
+ __u32 class;
struct sys_dev *next;
};
@@ -201,10 +203,11 @@ static inline char *guid_str(char *buf, struct efi_guid guid)
char *diskfd_to_devpath(int fd);
struct sys_dev *find_driver_devices(const char *bus, const char *driver);
struct sys_dev *find_intel_devices(void);
-const struct imsm_orom *find_imsm_capability(enum sys_dev_type hba_id);
+const struct imsm_orom *find_imsm_capability(struct sys_dev *hba);
const struct imsm_orom *find_imsm_orom(void);
int disk_attached_to_hba(int fd, const char *hba_path);
int devt_attached_to_hba(dev_t dev, const char *hba_path);
char *devt_to_devpath(dev_t dev);
int path_attached_to_hba(const char *disk_path, const char *hba_path);
const char *get_sys_dev_type(enum sys_dev_type);
+const struct imsm_orom *get_orom_by_device_id(__u16 device_id);
diff --git a/super-intel.c b/super-intel.c
index e28ac7d..dabf011 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -555,11 +555,26 @@ static int attach_hba_to_super(struct intel_super *super, struct sys_dev *device
if (super->hba == NULL) {
super->hba = alloc_intel_hba(device);
return 1;
- } else
- /* IMSM metadata disallows to attach disks to multiple
- * controllers.
- */
+ }
+
+ hba = super->hba;
+ /* Intel metadata allows for all disks attached to the same type HBA.
+ * Do not sypport odf HBA types mixing
+ */
+ if (device->type != hba->type)
+ return 2;
+
+ /* Multiple same type HBAs can be used if they share the same OROM */
+ const struct imsm_orom *device_orom = get_orom_by_device_id(device->dev_id);
+
+ if (device_orom != super->orom)
return 2;
+
+ while (hba->next)
+ hba = hba->next;
+
+ hba->next = alloc_intel_hba(device);
+ return 1;
}
static struct sys_dev* find_disk_attached_hba(int fd, const char *devname)
@@ -1886,13 +1901,12 @@ static int detail_platform_imsm(int verbose, int enumerate_only, char *controlle
if (!list)
return 2;
for (hba = list; hba; hba = hba->next) {
- orom = find_imsm_capability(hba->type);
- if (!orom) {
- result = 2;
+ if (find_imsm_capability(hba)) {
+ result = 0;
break;
}
else
- result = 0;
+ result = 2;
}
return result;
}
@@ -1909,7 +1923,7 @@ static int detail_platform_imsm(int verbose, int enumerate_only, char *controlle
for (hba = list; hba; hba = hba->next) {
if (controller_path && (compare_paths(hba->path,controller_path) != 0))
continue;
- orom = find_imsm_capability(hba->type);
+ orom = find_imsm_capability(hba);
if (!orom)
pr_err("imsm capabilities not found for controller: %s (type %s)\n",
hba->path, get_sys_dev_type(hba->type));
@@ -1954,7 +1968,7 @@ static int export_detail_platform_imsm(int verbose, char *controller_path)
for (hba = list; hba; hba = hba->next) {
if (controller_path && (compare_paths(hba->path,controller_path) != 0))
continue;
- orom = find_imsm_capability(hba->type);
+ orom = find_imsm_capability(hba);
if (!orom) {
if (verbose > 0)
pr_err("IMSM_DETAIL_PLATFORM_ERROR=NO_IMSM_CAPABLE_DEVICE_UNDER_%s\n",hba->path);
@@ -3087,13 +3101,18 @@ static int compare_super_imsm(struct supertype *st, struct supertype *tst)
* use the same Intel hba
* If not on Intel hba at all, allow anything.
*/
- if (!check_env("IMSM_NO_PLATFORM")) {
- if (first->hba && sec->hba &&
- strcmp(first->hba->path, sec->hba->path) != 0) {
+ if (!check_env("IMSM_NO_PLATFORM") && first->hba && sec->hba) {
+ if (first->hba->type != sec->hba->type) {
+ fprintf(stderr,
+ "HBAs of devices do not match %s != %s\n",
+ get_sys_dev_type(first->hba->type),
+ get_sys_dev_type(sec->hba->type));
+ return 3;
+ }
+ if (first->orom != sec->orom) {
fprintf(stderr,
- "HBAs of devices does not match %s != %s\n",
- first->hba ? first->hba->path : NULL,
- sec->hba ? sec->hba->path : NULL);
+ "HBAs of devices do not match %s != %s\n",
+ first->hba->pci_id, sec->hba->pci_id);
return 3;
}
}
@@ -3832,14 +3851,13 @@ static int find_intel_hba_capability(int fd, struct intel_super *super, char *de
fprintf(stderr, ", ");
hba = hba->next;
}
-
- fprintf(stderr, ").\n");
- cont_err("Mixing devices attached to multiple controllers "
- "is not allowed.\n");
+ fprintf(stderr, ").\n"
+ " Mixing devices attached to different controllers "
+ "is not allowed.\n");
}
return 2;
}
- super->orom = find_imsm_capability(hba_name->type);
+ super->orom = find_imsm_capability(hba_name);
if (!super->orom)
return 3;
return 0;
@@ -9061,32 +9079,68 @@ int open_backup_targets(struct mdinfo *info, int raid_disks, int *raid_fds,
******************************************************************************/
int validate_container_imsm(struct mdinfo *info)
{
- if (!check_env("IMSM_NO_PLATFORM")) {
- struct sys_dev *idev;
- struct mdinfo *dev;
- char *hba_path = NULL;
- char *dev_path = devt_to_devpath(makedev(info->disk.major,
- info->disk.minor));
+ if (check_env("IMSM_NO_PLATFORM"))
+ return 0;
- for (idev = find_intel_devices(); idev; idev = idev->next) {
- if (strstr(dev_path, idev->path)) {
- hba_path = idev->path;
- break;
- }
+ struct sys_dev *idev;
+ struct sys_dev *hba = NULL;
+ struct sys_dev *intel_devices = find_intel_devices();
+ char *dev_path = devt_to_devpath(makedev(info->disk.major,
+ info->disk.minor));
+
+ for (idev = intel_devices; idev; idev = idev->next) {
+ if (dev_path && strstr(dev_path, idev->path)) {
+ hba = idev;
+ break;
}
+ }
+ if (dev_path)
free(dev_path);
- if (hba_path) {
- for (dev = info->next; dev; dev = dev->next) {
- if (!devt_attached_to_hba(makedev(dev->disk.major,
- dev->disk.minor), hba_path)) {
- pr_err("WARNING - IMSM container assembled with disks under different HBAs!\n"
- " This operation is not supported and can lead to data loss.\n");
- return 1;
- }
+ if (!hba) {
+ pr_err("WARNING - Cannot detect HBA for device %s!\n",
+ devid2kname(makedev(info->disk.major, info->disk.minor)));
+ return 1;
+ }
+
+ const struct imsm_orom *orom = get_orom_by_device_id(hba->dev_id);
+ struct mdinfo *dev;
+
+ for (dev = info->next; dev; dev = dev->next) {
+ dev_path = devt_to_devpath(makedev(dev->disk.major, dev->disk.minor));
+
+ struct sys_dev *hba2 = NULL;
+ for (idev = intel_devices; idev; idev = idev->next) {
+ if (dev_path && strstr(dev_path, idev->path)) {
+ hba2 = idev;
+ break;
}
}
+ if (dev_path)
+ free(dev_path);
+
+ const struct imsm_orom *orom2 = hba2 == NULL ? NULL :
+ get_orom_by_device_id(hba2->dev_id);
+
+ if (hba2 && hba->type != hba2->type) {
+ pr_err("WARNING - HBAs of devices do not match %s != %s\n",
+ get_sys_dev_type(hba->type), get_sys_dev_type(hba2->type));
+ return 1;
+ }
+
+ if (orom != orom2) {
+ pr_err("WARNING - IMSM container assembled with disks under different HBAs!\n"
+ " This operation is not supported and can lead to data loss.\n");
+ return 1;
+ }
+
+ if (!orom) {
+ pr_err("WARNING - IMSM container assembled with disks under HBAs without IMSM platform support!\n"
+ " This operation is not supported and can lead to data loss.\n");
+ return 1;
+ }
}
+
return 0;
}
#ifndef MDASSEMBLE
--
1.8.4.5
^ permalink raw reply related
* [PATCH 0/5] imsm: support for NVMe devices and AHCI spanning
From: Artur Paszkiewicz @ 2014-11-19 12:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, pawel.baldysiak, Artur Paszkiewicz
This set of patches adds support for IMSM metadata with Intel NVMe devices and
for multiple AHCI HBAs with separate and combined OROMs. This enables spanning
between AHCI HBAs if the firmware supports it. It also improves checking of
IMSM platform capabilities and printing them with detail-platform.
Artur Paszkiewicz (4):
imsm: support for OROMs shared by multiple HBAs
imsm: support for second and combined AHCI controllers in UEFI mode
imsm: detail-platform improvements
imsm: use efivarfs interface for reading UEFI variables
Pawel Baldysiak (1):
imsm: add support for NVMe devices
platform-intel.c | 339 +++++++++++++++++++++++++++++++++++++++----------------
platform-intel.h | 33 +++++-
super-intel.c | 232 +++++++++++++++++++++++++------------
3 files changed, 437 insertions(+), 167 deletions(-)
--
1.8.4.5
^ permalink raw reply
* Re: mdadm creates corrupt superblock
From: Hans Kraus @ 2014-11-19 9:55 UTC (permalink / raw)
To: NeilBrown; +Cc: Linux-RAID
In-Reply-To: <545157E4.3090204@hanswkraus.com>
Hi,
I think I found the problem. 'badblocks' reports sector 64 of the HD as
errornous. But the HD neither reports a read error nor remaps that
sector.
Is it possible to parametrize mdadm that it doesn't use that sector?
Regards, Hans
Am 29.10.2014 22:11, schrieb Hans Kraus:
> Hi Neil,
>
> many thanks for your response. I rebooted the machine and got new drive
> assignments. The drive in question is now sdc1. mdadm gave an error with
> the dump, results below (nothing to report by dmesg) [by the way, I
> wasn'nt even able to create an array on that drive with
> 'mdadm --create --level=1 -n 2 /dev/sdc1 missing', same error(s)]:
> -------------------------------------------------------------------------
> root@nashorn:~# mdadm -E /dev/sdb1
> /dev/sdb1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : e7caa5d1:b33fd2a5:7782fb0c:9d8d9d5b
> Name : nashorn:126 (local to host nashorn)
> Creation Time : Mon Oct 27 15:58:38 2014
> Raid Level : raid1
> Raid Devices : 2
>
> Avail Dev Size : 1953260976 (931.39 GiB 1000.07 GB)
> Array Size : 976630488 (931.39 GiB 1000.07 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> Unused Space : before=262056 sectors, after=0 sectors
> State : clean
> Device UUID : f7a91c46:e4cda0c0:1b770fd7:876634f8
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Wed Oct 29 18:42:16 2014
> Bad Block Log : 512 entries available at offset 72 sectors
> Checksum : 939b22d1 - correct
> Events : 3325
>
>
> Device Role : Active device 0
> Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
> root@nashorn:~#
> -------------------------------------------------------------------------
> root@nashorn:~# mdadm -E /dev/sdh1
> /dev/sdh1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : e7caa5d1:b33fd2a5:7782fb0c:9d8d9d5b
> Name : nashorn:126 (local to host nashorn)
> Creation Time : Mon Oct 27 15:58:38 2014
> Raid Level : raid1
> Raid Devices : 2
>
> Avail Dev Size : 1953260976 (931.39 GiB 1000.07 GB)
> Array Size : 976630488 (931.39 GiB 1000.07 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> Unused Space : before=262046 sectors, after=0 sectors
> State : clean
> Device UUID : 089d1d0e:4d5ca222:dd716acb:0813815c
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Wed Oct 29 18:42:16 2014
> Bad Block Log : 512 entries available at offset 82 sectors
> Checksum : 16454b96 - correct
> Events : 3325
>
>
> Device Role : Active device 1
> Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
> root@nashorn:~#
> -------------------------------------------------------------------------
> root@nashorn:~# mdadm -E /dev/sdc1
> /dev/sdc1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : e7caa5d1:b33fd2a5:7782fb0c:9d8d9d5b
> Name : nashorn:126 (local to host nashorn)
> Creation Time : Mon Oct 27 15:58:38 2014
> Raid Level : raid1
> Raid Devices : 2
>
> Avail Dev Size : 1953260976 (931.39 GiB 1000.07 GB)
> Array Size : 0
> Used Dev Size : 0
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> Unused Space : before=262056 sectors, after=1953260976 sectors
> State : clean
> Device UUID : 4d1420c6:79978477:e86412b1:24beebfc
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Tue Oct 28 11:53:49 2014
> Bad Block Log : 512 entries available at offset 72 sectors
> Checksum : 6f02d040 - expected 891eedff
> Events : 0
>
>
> Device Role : spare
> Array State : RR ('A' == active, '.' == missing, 'R' == replacing)
> -------------------------------------------------------------------------
> root@nashorn:~# mkdir -p /tmp/dump
> root@nashorn:~# mdadm --dump /tmp/dump /dev/sdc1
> mdadm: Failed to copy metadata from /dev/sdc1 to /tmp/dump/sdc1
> -------------------------------------------------------------------------
> Kind regards, Hans
>
> Am 28.10.2014 22:00, schrieb NeilBrown:
>> On Tue, 28 Oct 2014 19:06:20 +0100 Hans Kraus <hans@hanswkraus.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I debugged my problem a bit more: it seems that mdadm creates a defect
>>> superblock. That's repeatedly happening, but only for one drive. I
>>> copied zeros to that drive (via ddrescue /dev/zero ...) and the drive
>>> looks OK. The info I got:
>>>
>>
>> and you send me the metadata of all your devices please?
>>
>> mkdir /tmp/dump
>> mdadm --dump /tmp/dump /dev/sde1
>> tar czvf /tmp/dump.tgz /tmp/dump
>>
>> and then send /tmp/dump.tgz
>>
>> Thanks.
>>
>> NeilBrown
>>
>> =================================================================================================================================================================================================
>>
>>> root@nashorn:/home/kraush/work/smartctrl# mdadm --zero-superblock
>>> /dev/sde1
>>> mdadm: Unrecognised md component device - /dev/sde1
>>> root@nashorn:/home/kraush/work/smartctrl# mdadm --add /dev/md126
>>> /dev/sde1
>>> mdadm: add new device failed for /dev/sde1 as 4: Invalid argument
>>> root@nashorn:/home/kraush/work/smartctrl# mdadm -E /dev/sde1
>>> /dev/sde1:
>>> Magic : a92b4efc
>>> Version : 1.2
>>> Feature Map : 0x1
>>> Array UUID : e7caa5d1:b33fd2a5:7782fb0c:9d8d9d5b
>>> Name : nashorn:126 (local to host nashorn)
>>> Creation Time : Mon Oct 27 15:58:38 2014
>>> Raid Level : raid1
>>> Raid Devices : 2
>>>
>>> Avail Dev Size : 1953260976 (931.39 GiB 1000.07 GB)
>>> Array Size : 0
>>> Used Dev Size : 0
>>> Data Offset : 262144 sectors
>>> Super Offset : 8 sectors
>>> Unused Space : before=262056 sectors, after=1953260976 sectors
>>> State : clean
>>> Device UUID : 4d1420c6:79978477:e86412b1:24beebfc
>>>
>>> Internal Bitmap : 8 sectors from superblock
>>> Update Time : Tue Oct 28 11:53:49 2014
>>> Bad Block Log : 512 entries available at offset 72 sectors
>>> Checksum : 6f02d040 - expected 891eedff
>>> Events : 0
>>>
>>>
>>> Device Role : spare
>>> Array State : RR ('A' == active, '.' == missing, 'R' == replacing)
>>> root@nashorn:/home/kraush/work/smartctrl#
>>> -----------------------------------------------------------------------------------------------------------
>>>
>>> root@nashorn:/home/kraush/work/smartctrl# cat /proc/mdstat
>>> Personalities : [raid1] [raid6] [raid5] [raid4]
>>> md127 : active (auto-read-only) raid6 sda1[0] sdk1[6](S) sdl2[7](S)
>>> sdh1[5] sdg1[4] sdf1[3] sdc1[2] sdb1[1]
>>> 1953017856 blocks super 1.2 level 6, 512k chunk, algorithm 2
>>> [6/6] [UUUUUU]
>>> bitmap: 0/4 pages [0KB], 65536KB chunk
>>>
>>> md10 : active (auto-read-only) raid1 sdi2[0] sdl3[1]
>>> 87833408 blocks super 1.2 [2/2] [UU]
>>> bitmap: 0/1 pages [0KB], 65536KB chunk
>>>
>>> md126 : active raid1 sdd1[3] sdj1[2]
>>> 488254464 blocks super 1.2 [2/2] [UU]
>>> bitmap: 0/4 pages [0KB], 65536KB chunk
>>>
>>> md0 : active raid1 sdl1[4] sdd2[3] sdi1[5]
>>> 156157824 blocks super 1.2 [3/1] [U__]
>>> [===================>.] recovery = 95.6% (149290048/156157824)
>>> finish=8.4min speed=13496K/sec
>>> bitmap: 1/2 pages [4KB], 65536KB chunk
>>>
>>> unused devices: <none>
>>> root@nashorn:/home/kraush/work/smartctrl#
>>> -----------------------------------------------------------------------------------------------------------
>>>
>>> dmesg:
>>> [33299.387382] md: invalid superblock checksum on sde1
>>> [33299.387385] md: sde1 does not have a valid v1.2 superblock, not
>>> importing!
>>> [33299.387408] md: md_import_device returned -22
>>> root@nashorn:/home/kraush/work/smartctrl#
>>> -----------------------------------------------------------------------------------------------------------
>>>
>>> root@nashorn:/home/kraush/work/mdadm# mdadm --version
>>> mdadm - v3.3-161-gfed12d4 - 21st August 2014
>>> =================================================================================================================================================================================================
>>>
>>>
>>> Kind regards, Hans
>>> --
>>> 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
>>
>
> --
> 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
^ permalink raw reply
* Re: Re-assemble RAID6 from SW to HW RAID
From: Drew @ 2014-11-18 19:09 UTC (permalink / raw)
To: Phil Turmel; +Cc: Mathias Burén, Linux-RAID
In-Reply-To: <546B4AD7.3060408@turmel.org>
On Tue, Nov 18, 2014 at 5:34 AM, Phil Turmel <philip@turmel.org> wrote:
>
> You should look if your MegaRAID has a 'JBOD' mode for the drives.
Some LSI controllers, 1068e as well as 9(2,4,6)00 series controllers,
can be re-flashed to make them plain HBA's
--
Drew
"Nothing in life is to be feared. It is only to be understood."
--Marie Curie
^ permalink raw reply
* Re: Re-assemble RAID6 from SW to HW RAID
From: Phil Turmel @ 2014-11-18 13:34 UTC (permalink / raw)
To: Mathias Burén, Linux-RAID
In-Reply-To: <CADNH=7HeKemJvN5gNtxznZWArqe2ibBaMTMJqdfsKyYAr4EcKw@mail.gmail.com>
Hi Mathias,
On 11/17/2014 05:51 PM, Mathias Burén wrote:
> On 17 November 2014 22:14, Mathias Burén <mathias.buren@gmail.com> wrote:
>> Hi all,
>>
>> I've a 6 disk RAID6 array, with 1 missing disk. I moved 2 of the HDDs
>> from the on-board SATA controller to a LSI MegaRAID controller where I
>> created them as individual RAID0's. The data in the array isn't
>> important, but it'd be nice if I can reassemble it.
[trim /]
> It appears to have a superblock?
Take a close look at your new device sizes. The hardware raid almost
certainly shortened the devices to fit its own metadata on the end. MD
v1.2 metadata contains enough info to reject the SB if the used space
doesn't fit the device.
You should look if your MegaRAID has a 'JBOD' mode for the drives.
Regards,
Phil
--
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
^ permalink raw reply
* Re[2]: Raid 6 Fail Event
From: Justin Stephenson @ 2014-11-18 2:19 UTC (permalink / raw)
To: Chris Murphy; +Cc: linux-raid
In-Reply-To: <AB2BF2A1-8D2D-4AC0-920F-1D182875A31B@colorremedies.com>
Hello Chris,
I have read up on the SMART error the drive has been giving me. It is a
known issue with the SEAGATE 3TB drives I am using. I have swapped the
drive out for a new one and am rebuilding right now. I am including the
dump of the smartctl -x /dev/sdh below.
when i rebooted earlier mdadm kicked the device out so when I tried to
--manage fail and --manage remove the drive it told me it did not exist.
I removed the old drive and installed a spanky new one.
I re formatted the drive with parted as follows (this is how I did my
other drives - it is a 7 device raid):
#parted -a optimal
>mklabel gpt
>mkpart primary
>>start 2048s
>>end -1
>set
>>1
>>raid
>>on
I readded the newly formatted drive:
#mdadm --manage /dev/md0 --add /dev/sde1
When I check /proc/mdstat everthing seems to be going fine.
I did a smartctl -x on the other drives and they did not turn up this
error. I will keep my eye on them though.
See below for the smartctl -x of the failed drive.
Thank-you again for your help.
- Justin
[root@BigBlue Desktop]# smartctl -x /dev/sdh
smartctl 5.43 2012-06-30 r3573 [x86_64-linux-2.6.32-431.3.1.el6.x86_64]
(local build)
Copyright (C) 2002-12 by Bruce Allen,
http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda (SATA 3Gb/s, 4K Sectors)
Device Model: ST3000DM001-1CH166
Serial Number: Z1F3ZWAY
LU WWN Device Id: 5 000c50 0651b19cc
Firmware Version: CC27
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: ACS-2 (unknown minor revision code: 0x001f)
Local Time is: Mon Nov 17 17:58:16 2014 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is: Unavailable
APM level is: 128 (minimum power consumption without standby)
Rd look-ahead is: Enabled
Write cache is: Enabled
ATA Security is: Disabled, frozen [SEC2]
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
See vendor-specific Attribute list for marginal Attributes.
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine
completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 584) seconds.
Offline data collection
capabilities: (0x73) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 320) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x3085) SCT Status supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
1 Raw_Read_Error_Rate POSR-- 114 099 006 - 73003456
3 Spin_Up_Time PO---- 094 094 000 - 0
4 Start_Stop_Count -O--CK 100 100 020 - 46
5 Reallocated_Sector_Ct PO--CK 100 100 010 - 0
7 Seek_Error_Rate POSR-- 044 043 030 - 2100251894876
9 Power_On_Hours -O--CK 092 092 000 - 7128
10 Spin_Retry_Count PO--C- 100 100 097 - 0
12 Power_Cycle_Count -O--CK 100 100 020 - 46
183 Runtime_Bad_Block -O--CK 099 099 000 - 1
184 End-to-End_Error -O--CK 094 094 099 NOW 6
187 Reported_Uncorrect -O--CK 100 100 000 - 0
188 Command_Timeout -O--CK 100 100 000 - 0
189 High_Fly_Writes -O-RCK 098 098 000 - 2
190 Airflow_Temperature_Cel -O---K 068 057 045 - 32 (Min/Max 31/33)
191 G-Sense_Error_Rate -O--CK 100 100 000 - 0
192 Power-Off_Retract_Count -O--CK 100 100 000 - 20
193 Load_Cycle_Count -O--CK 084 084 000 - 32594
194 Temperature_Celsius -O---K 032 043 000 - 32 (0 19 0 0 0)
197 Current_Pending_Sector -O--C- 100 100 000 - 0
198 Offline_Uncorrectable ----C- 100 100 000 - 0
199 UDMA_CRC_Error_Count -OSRCK 200 200 000 - 0
240 Head_Flying_Hours ------ 100 253 000 - 265527763141589
241 Total_LBAs_Written ------ 100 253 000 - 12406885927
242 Total_LBAs_Read ------ 100 253 000 - 141450480453
||||||_ K auto-keep
|||||__ C event count
||||___ R error rate
|||____ S speed/performance
||_____ O updated online
|______ P prefailure warning
General Purpose Log Directory Version 1
SMART Log Directory Version 1 [multi-sector log support]
GP/S Log at address 0x00 has 1 sectors [Log Directory]
SMART Log at address 0x01 has 1 sectors [Summary SMART error log]
SMART Log at address 0x02 has 5 sectors [Comprehensive SMART error log]
GP Log at address 0x03 has 5 sectors [Ext. Comprehensive SMART error
log]
SMART Log at address 0x06 has 1 sectors [SMART self-test log]
GP Log at address 0x07 has 1 sectors [Extended self-test log]
SMART Log at address 0x09 has 1 sectors [Selective self-test log]
GP Log at address 0x10 has 1 sectors [NCQ Command Error log]
GP Log at address 0x11 has 1 sectors [SATA Phy Event Counters]
GP Log at address 0x21 has 1 sectors [Write stream error log]
GP Log at address 0x22 has 1 sectors [Read stream error log]
GP/S Log at address 0x80 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x81 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x82 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x83 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x84 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x85 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x86 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x87 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x88 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x89 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8a has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8b has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8c has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8d has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8e has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8f has 16 sectors [Host vendor specific log]
GP/S Log at address 0x90 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x91 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x92 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x93 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x94 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x95 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x96 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x97 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x98 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x99 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9a has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9b has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9c has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9d has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9e has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9f has 16 sectors [Host vendor specific log]
GP/S Log at address 0xa1 has 20 sectors [Device vendor specific log]
GP Log at address 0xa2 has 4496 sectors [Device vendor specific log]
GP/S Log at address 0xa8 has 129 sectors [Device vendor specific log]
GP/S Log at address 0xa9 has 1 sectors [Device vendor specific log]
GP Log at address 0xab has 1 sectors [Device vendor specific log]
GP Log at address 0xb0 has 5176 sectors [Device vendor specific log]
GP Log at address 0xbe has 65535 sectors [Device vendor specific log]
GP Log at address 0xbf has 65535 sectors [Device vendor specific log]
GP/S Log at address 0xc0 has 1 sectors [Device vendor specific log]
GP/S Log at address 0xc1 has 10 sectors [Device vendor specific log]
GP/S Log at address 0xc4 has 5 sectors [Device vendor specific log]
GP/S Log at address 0xe0 has 1 sectors [SCT Command/Status]
GP/S Log at address 0xe1 has 1 sectors [SCT Data Transfer]
SMART Extended Comprehensive Error Log Version: 1 (5 sectors)
Device Error Count: 1
CR = Command Register
FEATR = Features Register
COUNT = Count (was: Sector Count) Register
LBA_48 = Upper bytes of LBA High/Mid/Low Registers ] ATA-8
LH = LBA High (was: Cylinder High) Register ] LBA
LM = LBA Mid (was: Cylinder Low) Register ] Register
LL = LBA Low (was: Sector Number) Register ]
DV = Device (was: Device/Head) Register
DC = Device Control Register
ER = Error register
ST = Status register
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 1 [0] occurred at disk power-on lifetime: 7093 hours (295 days +
13 hours)
When the command that caused the error occurred, the device was active
or idle.
After command completion occurred, registers were:
ER -- ST COUNT LBA_48 LH LM LL DV DC
-- -- -- == -- == == == -- -- -- -- --
04 -- 71 00 04 00 00 00 80 87 80 e0 00
Commands leading to the command that caused the error were:
CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time
Command/Feature_Name
-- == -- == -- == == == -- -- -- -- -- ---------------
--------------------
ea 00 00 00 00 00 00 00 00 00 00 a0 00 22d+15:53:02.331 FLUSH CACHE EXT
61 00 00 00 01 00 00 00 00 08 08 40 00 22d+15:53:02.330 WRITE FPDMA
QUEUED
ea 00 00 00 00 00 00 00 00 00 00 a0 00 22d+15:53:02.330 FLUSH CACHE EXT
ea 00 00 00 00 00 00 00 00 00 00 a0 00 22d+15:52:40.493 FLUSH CACHE EXT
61 00 00 00 01 00 00 00 00 08 08 40 00 22d+15:52:40.492 WRITE FPDMA
QUEUED
SMART Extended Self-test Log Version: 1 (1 sectors)
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 7120 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute
delay.
Warning: device does not support SCT Data Table command
Warning: device does not support SCT Error Recovery Control command
SATA Phy Event Counters (GP Log 0x11)
ID Size Value Description
0x000a 2 2 Device-to-host register FISes sent due to a COMRESET
0x0001 2 0 Command failed due to ICRC error
0x0003 2 0 R_ERR response for device-to-host data FIS
0x0004 2 0 R_ERR response for host-to-device data FIS
0x0006 2 0 R_ERR response for device-to-host non-data FIS
0x0007 2 0 R_ERR response for host-to-device non-data FIS
On Mon, Nov 17, 2014 at 12:19 PM, Chris Murphy <lists@colorremedies.com>
wrote:
On Nov 16, 2014, at 6:34 PM, Justin Stephenson
<justin@evensteveninc.com> wrote:
> Thank-you, Chris. I appreciate your help with this.
>
> Backup are good. I'm a regular disk to disk to LTO guy. Here is what I
have turned up:
>
> ================================
> # smartctl -x /dev/sdh
>
> big long list of stuff.
Please post it.
> I found the serial.
>
> I also tried smartctl -H /dev/sdh and received
>
> Overall-health self-assesment test restul: PASSED
>
> 184 End-to-End_Error {flag value worst thresh} Old_age FAILING_NOW_6
Cute, it’s failing but it’s overall health is passing. This is a great
example of why the health self-assess is useless.
>
> I did not find anything for the serial in results from dmesg
>
> # smartctl -l scterc /dev/sdh
>
> Warning: device does not support SCT Commands
Interesting it supports a SMART IV attribut but doesn’t support SCT
commands.
>
> # cat /sys/block/sdh/device/state
>
> Running
>
> # cat /sys/block/sdh/device/timeout
>
> 30
Since the drives you have don’t support SCT commands, you need to set
the command timer to something much more than the default of 30,
otherwise your array will not function correctly when it encounters bad
sectors. In many cases the linux scsi command timer will reach 30
seconds and reset the interface, before the typical consumer drive
recovers (either returns data successfully or an error). This could be
quite long, maybe 2 minutes. Future drives you buy should have
configurable SCT ERC so the drive can be set to return a read error
after something like 7 seconds, i.e. you want the drive to give up
sooner, and by informing md of the problem sector range, the data is
rebuilt from parity and written back to the bad sectors on the drive
where the problem gets fixed.
>
> ================================
>
> Should I replace the drive or re add and resync?
Well I don’t know anything about attribute 184 End-to-End error, but
based on the description in wikipedia it sounds disqualifying to me.
I personally would get the drive replaced no matter what: either under
warranty, or if no warranty I’d get a new drive and test/play with this
one offline and if it proves its worth then maybe it can be a spare down
the road.
But you could also smartctl -x all the other drives and see what value
they have for this attribute.
>
> I also went through and reseated all the SATA and power connections as
I understand these can cause issues as well.
Chris Murphy
--
Even Steven Inc || Phone and Fax = 416-900-6069 || www.evensteveninc.com
||
--------
Justin Stephenson
Creative Director/Motion Designer
416-900-6069
http://justinstephenson.com
------ Original Message ------
From: "Chris Murphy" <lists@colorremedies.com>
To: "Justin Stephenson" <justin@evensteveninc.com>
Cc: linux-raid@vger.kernel.org
Sent: 17/11/2014 12:19:26 PM
Subject: Re: Raid 6 Fail Event
>
>On Nov 16, 2014, at 6:34 PM, Justin Stephenson
><justin@evensteveninc.com> wrote:
>
>> Thank-you, Chris. I appreciate your help with this.
>>
>> Backup are good. I'm a regular disk to disk to LTO guy. Here is what
>>I have turned up:
>>
>> ================================
>> # smartctl -x /dev/sdh
>>
>> big long list of stuff.
>
>Please post it.
>
>
>
>> I found the serial.
>>
>> I also tried smartctl -H /dev/sdh and received
>>
>> Overall-health self-assesment test restul: PASSED
>>
>> 184 End-to-End_Error {flag value worst thresh} Old_age FAILING_NOW_6
>
>Cute, it’s failing but it’s overall health is passing. This is a great
>example of why the health self-assess is useless.
>
>
>>
>> I did not find anything for the serial in results from dmesg
>>
>> # smartctl -l scterc /dev/sdh
>>
>> Warning: device does not support SCT Commands
>
>Interesting it supports a SMART IV attribut but doesn’t support SCT
>commands.
>
>
>>
>> # cat /sys/block/sdh/device/state
>>
>> Running
>>
>> # cat /sys/block/sdh/device/timeout
>>
>> 30
>
>Since the drives you have don’t support SCT commands, you need to set
>the command timer to something much more than the default of 30,
>otherwise your array will not function correctly when it encounters bad
>sectors. In many cases the linux scsi command timer will reach 30
>seconds and reset the interface, before the typical consumer drive
>recovers (either returns data successfully or an error). This could be
>quite long, maybe 2 minutes. Future drives you buy should have
>configurable SCT ERC so the drive can be set to return a read error
>after something like 7 seconds, i.e. you want the drive to give up
>sooner, and by informing md of the problem sector range, the data is
>rebuilt from parity and written back to the bad sectors on the drive
>where the problem gets fixed.
>
>
>
>
>>
>> ================================
>>
>> Should I replace the drive or re add and resync?
>
>Well I don’t know anything about attribute 184 End-to-End error, but
>based on the description in wikipedia it sounds disqualifying to me.
>
>I personally would get the drive replaced no matter what: either under
>warranty, or if no warranty I’d get a new drive and test/play with this
>one offline and if it proves its worth then maybe it can be a spare
>down the road.
>
>But you could also smartctl -x all the other drives and see what value
>they have for this attribute.
>
>>
>> I also went through and reseated all the SATA and power connections
>>as I understand these can cause issues as well.
>
>
>
>
>Chris Murphy
--
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
^ permalink raw reply
* Re: Re-assemble RAID6 from SW to HW RAID
From: Mathias Burén @ 2014-11-17 22:51 UTC (permalink / raw)
To: Linux-RAID
In-Reply-To: <CADNH=7H=ge5P9rm5hRjO3GhOFF-jAqFZrNMjNeEGVDwe=BOARw@mail.gmail.com>
On 17 November 2014 22:14, Mathias Burén <mathias.buren@gmail.com> wrote:
> Hi all,
>
> I've a 6 disk RAID6 array, with 1 missing disk. I moved 2 of the HDDs
> from the on-board SATA controller to a LSI MegaRAID controller where I
> created them as individual RAID0's. The data in the array isn't
> important, but it'd be nice if I can reassemble it.
>
> This is what it looks like:
>
> $ for I in /dev/sd?;do sudo mdadm -E $I;done
>
>
> /dev/sdb:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
> Name : ion:md0 (local to host ion)
> Creation Time : Tue Feb 5 17:33:27 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
> Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
> Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 78df2586:cb5649aa:e0b6d211:d92dc224
>
> Update Time : Tue Nov 4 21:43:49 2014
> Checksum : 50c95b7c - correct
> Events : 97557
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> Device Role : Active device 5
> Array State : AA.AAA ('A' == active, '.' == missing)
> /dev/sdc:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
> Name : ion:md0 (local to host ion)
> Creation Time : Tue Feb 5 17:33:27 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
> Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
> Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 41712f8c:255b0f3e:0e345f7b:e1504e42
>
> Update Time : Tue Nov 4 21:43:49 2014
> Checksum : 71b191d6 - correct
> Events : 97557
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> Device Role : Active device 1
> Array State : AA.AAA ('A' == active, '.' == missing)
> /dev/sdd:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
> Name : ion:md0 (local to host ion)
> Creation Time : Tue Feb 5 17:33:27 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
> Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
> Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : a09fc60d:5c4a27a5:4b89bc33:29b01582
>
> Update Time : Tue Nov 4 21:43:49 2014
> Checksum : 528563ee - correct
> Events : 97557
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> Device Role : Active device 3
> Array State : AA.AAA ('A' == active, '.' == missing)
> /dev/sde:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
> Name : ion:md0 (local to host ion)
> Creation Time : Tue Feb 5 17:33:27 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
> Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
> Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 39c0b717:a9ca1dd7:bcba618f:caed0879
>
> Update Time : Tue Nov 4 21:43:49 2014
> Checksum : 55758eeb - correct
> Events : 97557
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> Device Role : Active device 4
> Array State : AA.AAA ('A' == active, '.' == missing)
> /dev/sdf:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
> Name : ion:md0 (local to host ion)
> Creation Time : Tue Feb 5 17:33:27 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
> Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
> Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 93568b01:632395bf:7d0082a5:db9b6ff9
>
> Update Time : Tue Nov 4 21:43:49 2014
> Checksum : 49d756ca - correct
> Events : 97557
>
> Layout : left-symmetric
> Chunk Size : 512K
>
> Device Role : Active device 0
> Array State : AA.AAA ('A' == active, '.' == missing)
>
> $ ls -la /dev/disk/by-id/ | grep -v Cors | grep -v dm
>
> lrwxrwxrwx 1 root root 9 Nov 17 22:04
> ata-SAMSUNG_HD204UI_S2H7JR0B501861 -> ../../sdb
> lrwxrwxrwx 1 root root 9 Nov 17 22:04
> ata-WDC_WD20EARS-00J99B0_WD-WCAWZ2036074 -> ../../sdc
> lrwxrwxrwx 1 root root 9 Nov 17 22:04
> ata-WDC_WD20EARS-00MVWB0_WD-WMAZA6473013 -> ../../sdd
> lrwxrwxrwx 1 root root 9 Nov 17 22:04
> scsi-3600605b0025eff501bfd2d550b74a2d5 -> ../../sde
> lrwxrwxrwx 1 root root 9 Nov 17 22:04
> scsi-3600605b0025eff501bfd2d5709c4a486 -> ../../sdf
> lrwxrwxrwx 1 root root 9 Nov 17 22:04 wwn-0x50000f00500b6118 -> ../../sdb
> lrwxrwxrwx 1 root root 9 Nov 17 22:04 wwn-0x50014ee0030a1204 -> ../../sdd
> lrwxrwxrwx 1 root root 9 Nov 17 22:04 wwn-0x50014ee206d9cbd2 -> ../../sdc
> lrwxrwxrwx 1 root root 9 Nov 17 22:04
> wwn-0x600605b0025eff501bfd2d550b74a2d5 -> ../../sde
> lrwxrwxrwx 1 root root 9 Nov 17 22:04
> wwn-0x600605b0025eff501bfd2d5709c4a486 -> ../../sdf
>
> Any idea if this is rescuable?
>
> Thanks
I tried something, but I'm not sure how to proceed:
$ sudo mdadm --verbose --assemble /dev/md0 /dev/sdb /dev/sde /dev/sdf
/dev/sda /dev/sdd
mdadm: looking for devices for /dev/md0
mdadm: /dev/sdb is identified as a member of /dev/md0, slot 0.
mdadm: /dev/sde is identified as a member of /dev/md0, slot 1.
mdadm: /dev/sdf is identified as a member of /dev/md0, slot 3.
mdadm: /dev/sda is identified as a member of /dev/md0, slot 4.
mdadm: /dev/sdd is identified as a member of /dev/md0, slot 5.
mdadm: added /dev/sde to /dev/md0 as 1
mdadm: no uptodate device for slot 4 of /dev/md0
mdadm: added /dev/sdf to /dev/md0 as 3
mdadm: failed to add /dev/sda to /dev/md0: Invalid argument
mdadm: added /dev/sdd to /dev/md0 as 5
mdadm: failed to add /dev/sdb to /dev/md0: Invalid argument
mdadm: /dev/md0 assembled from 3 drives - need 5 to start (use --run to insist).
dmesg:
[ 1815.848865] md: md0 stopped.
[ 1815.848870] md: unbind<sdd>
[ 1815.869743] md: export_rdev(sdd)
[ 1815.869816] md: unbind<sdf>
[ 1815.894653] md: export_rdev(sdf)
[ 1815.894732] md: unbind<sde>
[ 1815.933751] md: export_rdev(sde)
[ 1823.136749] md: md0 stopped.
[ 1823.161460] md: bind<sde>
[ 1823.161556] md: bind<sdf>
[ 1823.161755] md: sda does not have a valid v1.2 superblock, not importing!
[ 1823.161759] md: md_import_device returned -22
[ 1823.161863] md: bind<sdd>
[ 1823.162029] md: sdb does not have a valid v1.2 superblock, not importing!
[ 1823.162032] md: md_import_device returned -22
[ 1823.162045] md: md0 stopped.
[ 1823.162048] md: unbind<sdd>
[ 1823.173683] md: export_rdev(sdd)
[ 1823.173690] md: unbind<sdf>
[ 1823.185723] md: export_rdev(sdf)
[ 1823.185742] md: unbind<sde>
[ 1823.193750] md: export_rdev(sde)
It appears to have a superblock?
$ sudo mdadm -E /dev/sda
/dev/sda:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
Name : ion:md0 (local to host ion)
Creation Time : Tue Feb 5 17:33:27 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=385940480 sectors
State : clean
Device UUID : 39c0b717:a9ca1dd7:bcba618f:caed0879
Update Time : Tue Nov 4 21:43:49 2014
Checksum : 55758eeb - correct
Events : 97557
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 4
Array State : AA.AAA ('A' == active, '.' == missing, 'R' == replacing)
$ sudo mdadm -E /dev/sdb
/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
Name : ion:md0 (local to host ion)
Creation Time : Tue Feb 5 17:33:27 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=18446744073706818560 sectors
State : clean
Device UUID : 93568b01:632395bf:7d0082a5:db9b6ff9
Update Time : Tue Nov 4 21:43:49 2014
Checksum : 49d756ca - correct
Events : 97557
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AA.AAA ('A' == active, '.' == missing, 'R' == replacing)
Ragards
Mathias
--
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
^ permalink raw reply
* Re-assemble RAID6 from SW to HW RAID
From: Mathias Burén @ 2014-11-17 22:14 UTC (permalink / raw)
To: Linux-RAID
Hi all,
I've a 6 disk RAID6 array, with 1 missing disk. I moved 2 of the HDDs
from the on-board SATA controller to a LSI MegaRAID controller where I
created them as individual RAID0's. The data in the array isn't
important, but it'd be nice if I can reassemble it.
This is what it looks like:
$ for I in /dev/sd?;do sudo mdadm -E $I;done
/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
Name : ion:md0 (local to host ion)
Creation Time : Tue Feb 5 17:33:27 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 78df2586:cb5649aa:e0b6d211:d92dc224
Update Time : Tue Nov 4 21:43:49 2014
Checksum : 50c95b7c - correct
Events : 97557
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 5
Array State : AA.AAA ('A' == active, '.' == missing)
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
Name : ion:md0 (local to host ion)
Creation Time : Tue Feb 5 17:33:27 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 41712f8c:255b0f3e:0e345f7b:e1504e42
Update Time : Tue Nov 4 21:43:49 2014
Checksum : 71b191d6 - correct
Events : 97557
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA.AAA ('A' == active, '.' == missing)
/dev/sdd:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
Name : ion:md0 (local to host ion)
Creation Time : Tue Feb 5 17:33:27 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : a09fc60d:5c4a27a5:4b89bc33:29b01582
Update Time : Tue Nov 4 21:43:49 2014
Checksum : 528563ee - correct
Events : 97557
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AA.AAA ('A' == active, '.' == missing)
/dev/sde:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
Name : ion:md0 (local to host ion)
Creation Time : Tue Feb 5 17:33:27 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 39c0b717:a9ca1dd7:bcba618f:caed0879
Update Time : Tue Nov 4 21:43:49 2014
Checksum : 55758eeb - correct
Events : 97557
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 4
Array State : AA.AAA ('A' == active, '.' == missing)
/dev/sdf:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 0ad2603e:e43283ee:02180773:98e716ef
Name : ion:md0 (local to host ion)
Creation Time : Tue Feb 5 17:33:27 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
Array Size : 7813531648 (7451.56 GiB 8001.06 GB)
Used Dev Size : 3906765824 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 93568b01:632395bf:7d0082a5:db9b6ff9
Update Time : Tue Nov 4 21:43:49 2014
Checksum : 49d756ca - correct
Events : 97557
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AA.AAA ('A' == active, '.' == missing)
$ ls -la /dev/disk/by-id/ | grep -v Cors | grep -v dm
lrwxrwxrwx 1 root root 9 Nov 17 22:04
ata-SAMSUNG_HD204UI_S2H7JR0B501861 -> ../../sdb
lrwxrwxrwx 1 root root 9 Nov 17 22:04
ata-WDC_WD20EARS-00J99B0_WD-WCAWZ2036074 -> ../../sdc
lrwxrwxrwx 1 root root 9 Nov 17 22:04
ata-WDC_WD20EARS-00MVWB0_WD-WMAZA6473013 -> ../../sdd
lrwxrwxrwx 1 root root 9 Nov 17 22:04
scsi-3600605b0025eff501bfd2d550b74a2d5 -> ../../sde
lrwxrwxrwx 1 root root 9 Nov 17 22:04
scsi-3600605b0025eff501bfd2d5709c4a486 -> ../../sdf
lrwxrwxrwx 1 root root 9 Nov 17 22:04 wwn-0x50000f00500b6118 -> ../../sdb
lrwxrwxrwx 1 root root 9 Nov 17 22:04 wwn-0x50014ee0030a1204 -> ../../sdd
lrwxrwxrwx 1 root root 9 Nov 17 22:04 wwn-0x50014ee206d9cbd2 -> ../../sdc
lrwxrwxrwx 1 root root 9 Nov 17 22:04
wwn-0x600605b0025eff501bfd2d550b74a2d5 -> ../../sde
lrwxrwxrwx 1 root root 9 Nov 17 22:04
wwn-0x600605b0025eff501bfd2d5709c4a486 -> ../../sdf
Any idea if this is rescuable?
Thanks
^ permalink raw reply
* Re: Raid 6 Fail Event
From: Chris Murphy @ 2014-11-17 17:19 UTC (permalink / raw)
To: Justin Stephenson; +Cc: linux-raid
In-Reply-To: <em90cf29a7-2a88-4bcc-a6fa-eca2cd446449@littlez>
On Nov 16, 2014, at 6:34 PM, Justin Stephenson <justin@evensteveninc.com> wrote:
> Thank-you, Chris. I appreciate your help with this.
>
> Backup are good. I'm a regular disk to disk to LTO guy. Here is what I have turned up:
>
> ================================
> # smartctl -x /dev/sdh
>
> big long list of stuff.
Please post it.
> I found the serial.
>
> I also tried smartctl -H /dev/sdh and received
>
> Overall-health self-assesment test restul: PASSED
>
> 184 End-to-End_Error {flag value worst thresh} Old_age FAILING_NOW_6
Cute, it’s failing but it’s overall health is passing. This is a great example of why the health self-assess is useless.
>
> I did not find anything for the serial in results from dmesg
>
> # smartctl -l scterc /dev/sdh
>
> Warning: device does not support SCT Commands
Interesting it supports a SMART IV attribut but doesn’t support SCT commands.
>
> # cat /sys/block/sdh/device/state
>
> Running
>
> # cat /sys/block/sdh/device/timeout
>
> 30
Since the drives you have don’t support SCT commands, you need to set the command timer to something much more than the default of 30, otherwise your array will not function correctly when it encounters bad sectors. In many cases the linux scsi command timer will reach 30 seconds and reset the interface, before the typical consumer drive recovers (either returns data successfully or an error). This could be quite long, maybe 2 minutes. Future drives you buy should have configurable SCT ERC so the drive can be set to return a read error after something like 7 seconds, i.e. you want the drive to give up sooner, and by informing md of the problem sector range, the data is rebuilt from parity and written back to the bad sectors on the drive where the problem gets fixed.
>
> ================================
>
> Should I replace the drive or re add and resync?
Well I don’t know anything about attribute 184 End-to-End error, but based on the description in wikipedia it sounds disqualifying to me.
I personally would get the drive replaced no matter what: either under warranty, or if no warranty I’d get a new drive and test/play with this one offline and if it proves its worth then maybe it can be a spare down the road.
But you could also smartctl -x all the other drives and see what value they have for this attribute.
>
> I also went through and reseated all the SATA and power connections as I understand these can cause issues as well.
Chris Murphy--
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
^ permalink raw reply
* Re: Does order/ sequence of SATA drives matter?
From: Robin Hill @ 2014-11-17 11:31 UTC (permalink / raw)
To: forumscollective; +Cc: linux-raid
In-Reply-To: <4CC0CE83-56B9-40FE-AC92-9F60B4C80D4E@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 973 bytes --]
On Mon Nov 17, 2014 at 12:13:26PM +0200, forumscollective@gmail.com wrote:
> The motherboard on which I was running a mdadm 8TB array comprised of
> 5 x 2TB drives has packed up so the array needs to be moved to a new
> motherboard.
>
> Is the sequence of connectivity to motherboard SATA ports important or
> does mdadm identify each drive and automagically know its sequence in
> the array?
>
The array position is stored in the array metadata on each disk, so the
physical connection order does not matter. If you're using a RAID1 array
for the boot drive, you'll need to make sure that the correct disk is
set in the BIOS to boot from though (or that the boot block was
installed to all array members).
Cheers,
Robin
--
___
( ' } | Robin Hill <robin@robinhill.me.uk> |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Does order/ sequence of SATA drives matter?
From: forumscollective @ 2014-11-17 10:13 UTC (permalink / raw)
To: linux-raid
The motherboard on which I was running a mdadm 8TB array comprised of 5 x 2TB drives has packed up so the array needs to be moved to a new motherboard.
Is the sequence of connectivity to motherboard SATA ports important or does mdadm identify each drive and automagically know its sequence in the array?
Sent from my iPhone
^ permalink raw reply
* Re[2]: Raid 6 Fail Event
From: Justin Stephenson @ 2014-11-17 1:34 UTC (permalink / raw)
To: Chris Murphy; +Cc: linux-raid
In-Reply-To: <3B23D2F1-09A3-4C1F-AB38-2AB0DDC2D5A7@colorremedies.com>
Thank-you, Chris. I appreciate your help with this.
Backup are good. I'm a regular disk to disk to LTO guy. Here is what I
have turned up:
================================
# smartctl -x /dev/sdh
big long list of stuff. I found the serial.
I also tried smartctl -H /dev/sdh and received
Overall-health self-assesment test restul: PASSED
184 End-to-End_Error {flag value worst thresh} Old_age FAILING_NOW_6
I did not find anything for the serial in results from dmesg
# smartctl -l scterc /dev/sdh
Warning: device does not support SCT Commands
# cat /sys/block/sdh/device/state
Running
# cat /sys/block/sdh/device/timeout
30
================================
Should I replace the drive or re add and resync?
I also went through and reseated all the SATA and power connections as I
understand these can cause issues as well.
Best,
- J
------ Original Message ------
From: "Chris Murphy" <lists@colorremedies.com>
To: "Justin Stephenson" <justin@evensteveninc.com>
Cc: linux-raid@vger.kernel.org
Sent: 16/11/2014 2:52:02 PM
Subject: Re: Raid 6 Fail Event
>
>On Nov 16, 2014, at 8:39 AM, Justin Stephenson
><justin@evensteveninc.com> wrote:
>
>> Hello,
>>
>> I am new to MDADM and have just experienced my first device fail on
>>my raid 6.
>>
>> I am wondering if someone might be able to help by outlining a proper
>>protocol for troubleshooting and rebuilding this array (proc/mdstat
>>below).
>>
>> Here is how I might approach it:
>>
>> - remove the device
>> - test the device
>> - if the device tests OK then re add the device
>> - if the device fails, then replace the device
>> - resync
>>
>> Thank-you for your consideration.
>>
>> Best,
>>
>> - Justin
>>
>> Here is the mdstat email
>>
>> -----------------
>>
>> This is an automatically generated mail message from mdadm
>> running on BigBlue
>>
>> A Fail event had been detected on md device /dev/md0.
>>
>> It could be related to component device /dev/sdh1.
>
>First step is getting the backup current.
>
>Second you can do this without removing the device:
>
># smartctl -x /dev/sdh
>
>And then look in dmesg for errors related to its ata designation. You
>should be able to get a serial number from the smartctl output and can
>search that with dmesg | grep <serial#> to find out what it’s ata
>designation (port and device number) is, then you can dmesg | grep
>ataX.YY to get any read/write error events that explain what’s going
>on.
>
>While you’re at it the following would be helpful as well:
>
># smartctl -l scterc /dev/sdh
># cat /sys/block/sdh/device/state
># cat /sys/block/sdh/device/timeout
>
>These are read-only commands to determine states, they don’t change
>states so it’s safe.
>
>Chris Murphy
--
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
^ permalink raw reply
* Re: RAID1 removing failed disk returns EBUSY
From: NeilBrown @ 2014-11-16 23:03 UTC (permalink / raw)
To: Joe Lawrence; +Cc: linux-raid, Bill Kuzeja
In-Reply-To: <20141113090549.296a13ee@jlaw-desktop.mno.stratus.com>
[-- Attachment #1: Type: text/plain, Size: 8622 bytes --]
On Thu, 13 Nov 2014 09:05:49 -0500 Joe Lawrence <joe.lawrence@stratus.com>
wrote:
> On Wed, 29 Oct 2014 13:36:04 -0400
> Joe Lawrence <joe.lawrence@stratus.com> wrote:
>
> > On Wed, 29 Oct 2014 08:41:13 +1100
> > NeilBrown <neilb@suse.de> wrote:
> >
> > > On Mon, 27 Oct 2014 16:27:48 -0400 Joe Lawrence <joe.lawrence@stratus.com>
> > > wrote:
> > >
> > > > Hi Neil,
> > > >
> > > > We've encountered changes in MD and mdadm that have broken our automated
> > > > disk removal script. In the past, we've been able to run the following
> > > > after a RAID1 disk component removal:
> > > >
> > > > % echo fail > /sys/block/md3/md/dev-sdr5/state
> > > > % echo remove > /sys/block/md3/md/dev-sdr5/state
> > > >
> > > > However, the latest RHEL6.6 code drop has rebased to sufficiently recent
> > > > MD kernel and mdadm changes, in which the previous commands occasionally
> > > > fail like so:
> > > >
> > > > * MD array is usually resyncing or checking
> > > > * Component disk /dev/sdr removed via HBA sysfs PCI removal
> > > > * Following UDEV rule fires:
> > > >
> > > > SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}=="?*", \
> > > > RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"
> > > >
> > > > % mdadm --detail /dev/md3
> > > > /dev/md3:
> > > > Version : 1.1
> > > > Creation Time : Tue Oct 14 17:31:59 2014
> > > > Raid Level : raid1
> > > > Array Size : 25149440 (23.98 GiB 25.75 GB)
> > > > Used Dev Size : 25149440 (23.98 GiB 25.75 GB)
> > > > Raid Devices : 2
> > > > Total Devices : 2
> > > > Persistence : Superblock is persistent
> > > >
> > > > Intent Bitmap : Internal
> > > >
> > > > Update Time : Wed Oct 15 14:22:34 2014
> > > > State : active, degraded
> > > > Active Devices : 1
> > > > Working Devices : 1
> > > > Failed Devices : 1
> > > > Spare Devices : 0
> > > >
> > > > Name : localhost.localdomain:3
> > > > UUID : 40ed68ee:ba41d4cd:28c361ed:be7470b8
> > > > Events : 142
> > > >
> > > > Number Major Minor RaidDevice State
> > > > 0 65 21 0 faulty
> > > > 1 65 5 1 active sync /dev/sdj5
> > > >
> > > > All attempts to remove this device fail:
> > > >
> > > > % echo remove > /sys/block/md3/md/dev-sdr5/state
> > > > -bash: echo: write error: Device or resource busy
> > > >
> > > > This can be traced to state_store():
> > > >
> > > > } else if (cmd_match(buf, "remove")) {
> > > > if (rdev->raid_disk >= 0)
> > > > err = -EBUSY;
> > > >
> > > > After much debugging and systemtapping, I think I've figured out that the
> > > > sysfs scripting may fail after the following combination of changes:
> > > >
> > > > mdadm 8af530b07fce "Enhance incremental removal."
> > > > kernel 30b8feb730f9 "md/raid5: avoid deadlock when raid5 array has unack
> > > > badblocks during md_stop_writes"
> > > >
> > > > With these two changes:
> > > >
> > > > 1 - On the user side, mdadm is trying to set the array_state to read-auto
> > > > on incremental removal (as invoked by UDEV rule).
> > > >
> > > > 2 - Kernel side, md_set_readonly() will set the MD_RECOVERY_FROZEN flag,
> > > > wake up the mddev->thread and if there is a sync_thread, it will set
> > > > MD_RECOVERY_INTR and then wait until the sync_thread is set to NULL.
> > > >
> > > > When md_check_recovery() gets a chance to run as part of the
> > > > raid1d() mddev->thread, it may or may not ever get to
> > > > an invocation of remove_and_add_spares(), for there are but *many*
> > > > conditional early exits along the way -- for example, if
> > > > MD_RECOVERY_FROZEN is set, the following condition will bounce out of
> > > > the routine:
> > > >
> > > > if (!test_and_clear_bit(MD_RECOVERY_NEEDED, &mddev->recovery) ||
> > > > test_bit(MD_RECOVERY_FROZEN, &mddev->recovery))
> > > > goto unlock;
> > > >
> > > > the next time around, MD_RECOVERY_NEEDED will have been cleared, so
> > > > all future tests will return 0 and the negation will always take the
> > > > early exit path.
> > > >
> > > > Back in md_set_readonly(), it may notice that the MD is still in use,
> > > > so it clears the MD_RECOVERY_FROZEN and then returns -EBUSY, without
> > > > setting mddev->ro. But the damage has been done as conditions have
> > > > been set such that md_check_recovery() will never call
> > > > remove_and_add_spares().
> > > >
> > > > This would also explain why an "idle" sync_action clears the wedge: it
> > > > sets MD_RECOVERY_NEEDED allowing md_check_recovery() to continue executing
> > > > to remove_and_add_spares().
> > > >
> > > > As far as I can tell, this is what is happening to prevent the "remove"
> > > > write to /sys/block/md3/md/dev-sdr5/state from succeeding. There are
> > > > certainly a lot of little bit-states between disk removal, UDEV mdadm, and
> > > > various MD kernel threads, so apologies if I missed an important
> > > > transition.
> > > >
> > > > Would you consider writing "idle" to the MD array sync_action file as a
> > > > safe and reasonable intermediate workaround step for our script?
> > > >
> > > > And of course, any suggestions to whether this is intended behavior (ie,
> > > > the removed component disk is failed, but stuck in the array)?
> > > >
> > > > This is fairly easy for us to reproduce with multiple MD arrays per disk
> > > > (one per partition) and interrupting a raid check on all of them
> > > > (especially when they are delayed waiting for the first to finish) by
> > > > removing the component disk via sysfs PCI removal. We can provide
> > > > additional debug or testing if required.
> > > >
> > >
> > > Hi Joe,
> > > thanks for the details analysis!!
> > >
> > > I think the correct fix would be that MD_RECOVERY_NEEDED should be set after
> > > clearing MD_RECOVERY_FROZEN, like the patch below.
> > > Can you confirm that it works for you?
> > >
> > > Writing 'idle' should in general be safe, so that could be used as an interim.
> > >
> > > Thanks,
> > > NeilBrown
> > >
> > > diff --git a/drivers/md/md.c b/drivers/md/md.c
> > > index c03d87b6890a..2c73fcb82593 100644
> > > --- a/drivers/md/md.c
> > > +++ b/drivers/md/md.c
> > > @@ -5261,6 +5261,7 @@ static int md_set_readonly(struct mddev *mddev, struct block_device *bdev)
> > > printk("md: %s still in use.\n",mdname(mddev));
> > > if (did_freeze) {
> > > clear_bit(MD_RECOVERY_FROZEN, &mddev->recovery);
> > > + set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
> > > md_wakeup_thread(mddev->thread);
> > > }
> > > err = -EBUSY;
> > > @@ -5275,6 +5276,8 @@ static int md_set_readonly(struct mddev *mddev, struct block_device *bdev)
> > > mddev->ro = 1;
> > > set_disk_ro(mddev->gendisk, 1);
> > > clear_bit(MD_RECOVERY_FROZEN, &mddev->recovery);
> > > + set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
> > > + md_wakeup_thread(mddev->thread);
> > > sysfs_notify_dirent_safe(mddev->sysfs_state);
> > > err = 0;
> > > }
> > > @@ -5318,6 +5321,7 @@ static int do_md_stop(struct mddev *mddev, int mode,
> > > mutex_unlock(&mddev->open_mutex);
> > > if (did_freeze) {
> > > clear_bit(MD_RECOVERY_FROZEN, &mddev->recovery);
> > > + set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
> > > md_wakeup_thread(mddev->thread);
> > > }
> > > return -EBUSY;
> >
> > Hi Neil,
> >
> > In my tests, the UDEV "mdadm -If" invocation fails *and* removes the
> > pulled disk from the MD array. This is okay for our intentions, but I
> > wanted to make sure that it's okay to skip any failed-but-not-removed
> > state.
> >
> > Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
> >
> > and should this have a
> >
> > Fixes: 30b8feb730f9 ("md/raid5: avoid deadlock when raid5 array has unack badblocks during md_stop_writes")
> >
> > tag to mark for stable?
>
>
> Hi Neil,
>
> Would you like me to write up a proper patch, or is this one in the queue?
>
Several times over the last week I've thought that I should probably push
that patch along ... but each time something else seemed more interesting.
But it's a new week now. I've just posted a pull request.
Thanks for the prompt (and the report and testing of course).
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* [PULL REQUEST] md bug fix for 3.18
From: NeilBrown @ 2014-11-16 23:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Joe Lawrence, linux RAID
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]
The following changes since commit 206c5f60a3d902bc4b56dab2de3e88de5eb06108:
Linux 3.18-rc4 (2014-11-09 14:55:29 -0800)
are available in the git repository at:
git://neil.brown.name/md tags/md/3.18-fix
for you to fetch changes up to 45eaf45dfa4850df16bc2e8e7903d89021137f40:
md: Always set RECOVERY_NEEDED when clearing RECOVERY_FROZEN (2014-11-17 09:17:46 +1100)
----------------------------------------------------------------
One fix for md for 3.18.
This fixes a regression introduced in 3.13.
----------------------------------------------------------------
NeilBrown (1):
md: Always set RECOVERY_NEEDED when clearing RECOVERY_FROZEN
drivers/md/md.c | 4 ++++
1 file changed, 4 insertions(+)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: Raid 6 Fail Event
From: Chris Murphy @ 2014-11-16 19:52 UTC (permalink / raw)
To: Justin Stephenson; +Cc: linux-raid
In-Reply-To: <em16d8035c-84ce-4b71-bcbb-b5c965e35b04@littlez>
On Nov 16, 2014, at 8:39 AM, Justin Stephenson <justin@evensteveninc.com> wrote:
> Hello,
>
> I am new to MDADM and have just experienced my first device fail on my raid 6.
>
> I am wondering if someone might be able to help by outlining a proper protocol for troubleshooting and rebuilding this array (proc/mdstat below).
>
> Here is how I might approach it:
>
> - remove the device
> - test the device
> - if the device tests OK then re add the device
> - if the device fails, then replace the device
> - resync
>
> Thank-you for your consideration.
>
> Best,
>
> - Justin
>
> Here is the mdstat email
>
> -----------------
>
> This is an automatically generated mail message from mdadm
> running on BigBlue
>
> A Fail event had been detected on md device /dev/md0.
>
> It could be related to component device /dev/sdh1.
First step is getting the backup current.
Second you can do this without removing the device:
# smartctl -x /dev/sdh
And then look in dmesg for errors related to its ata designation. You should be able to get a serial number from the smartctl output and can search that with dmesg | grep <serial#> to find out what it’s ata designation (port and device number) is, then you can dmesg | grep ataX.YY to get any read/write error events that explain what’s going on.
While you’re at it the following would be helpful as well:
# smartctl -l scterc /dev/sdh
# cat /sys/block/sdh/device/state
# cat /sys/block/sdh/device/timeout
These are read-only commands to determine states, they don’t change states so it’s safe.
Chris Murphy--
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
^ permalink raw reply
* Raid 6 Fail Event
From: Justin Stephenson @ 2014-11-16 15:39 UTC (permalink / raw)
To: linux-raid
Hello,
I am new to MDADM and have just experienced my first device fail on my
raid 6.
I am wondering if someone might be able to help by outlining a proper
protocol for troubleshooting and rebuilding this array (proc/mdstat
below).
Here is how I might approach it:
- remove the device
- test the device
- if the device tests OK then re add the device
- if the device fails, then replace the device
- resync
Thank-you for your consideration.
Best,
- Justin
Here is the mdstat email
-----------------
This is an automatically generated mail message from mdadm
running on BigBlue
A Fail event had been detected on md device /dev/md0.
It could be related to component device /dev/sdh1.
Faithfully yours, etc.
P.S. The /proc/mdstat file currently contains the following:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdh1[5](F) sdg1[4] sdf1[3] sde1[2] sdd1[1] sdb1[6]
sdc1[0]
14650666880 blocks super 1.2 level 6, 128k chunk, algorithm 2 [7/6]
[UUUUU_U]
unused devices: <none>
--------
Justin Stephenson
Creative Director/Motion Designer
416-900-6069
http://justinstephenson.com
^ permalink raw reply
* Re: failed RAID 5 array
From: Phil Turmel @ 2014-11-15 15:03 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: DeadManMoving, linux-raid
In-Reply-To: <20141115064215.99B01382C37@gemini.denx.de>
Hi Wolfgang,
On 11/15/2014 01:42 AM, Wolfgang Denk wrote:
> Dear Phil,
>
> In message <54662804.7040005@turmel.org> you wrote:
>>
>> Yes. Braces are expanded as given. Square brackets are expanded in the
>> order found in the filesystem, not the order given.
>
> "in the order found in the filesystem" is not correct. Pathname
> expansion using [ ... ] patterns generates a _sorted_ list.
I stand corrected.
Thanks, and Regards,
Phil
^ permalink raw reply
* Re: failed RAID 5 array
From: Wolfgang Denk @ 2014-11-15 6:42 UTC (permalink / raw)
To: Phil Turmel; +Cc: DeadManMoving, linux-raid
In-Reply-To: <54662804.7040005@turmel.org>
Dear Phil,
In message <54662804.7040005@turmel.org> you wrote:
>
> Yes. Braces are expanded as given. Square brackets are expanded in the
> order found in the filesystem, not the order given.
"in the order found in the filesystem" is not correct. Pathname
expansion using [ ... ] patterns generates a _sorted_ list.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Quantum particles: The dreams that stuff is made of.
^ permalink raw reply
* Re: failed RAID 5 array
From: Phil Turmel @ 2014-11-14 16:04 UTC (permalink / raw)
To: DeadManMoving; +Cc: linux-raid
In-Reply-To: <1415980414.4241.49.camel@lappy.neofreak.org>
On 11/14/2014 10:53 AM, DeadManMoving wrote:
> Hi Phil,
> That is my plan to closely look at devices role to ensure proper order
> in array creation. To avoid any mistake, i was planning to
> use /dev/sda /dev/sdb /dev/sdc syntax instead of /dev/sd{a,b,c}, it's
> probably the same, is it not?
Yes. Braces are expanded as given. Square brackets are expanded in the
order found in the filesystem, not the order given.
> Like said in my original post, i am making duplicate copies of each
> disk, just to be extra safe. I already did it for two disks i have on
> hands. I have ordered and waiting for two other drives to come in. As
> soon as the copies will be done for the two other disks, i will try that
> procedure. I will use the --data-offset parameter as you suggest.
You've provided very good detail in your report, so in your situation I
would proceed with the original drives. But an extra layer of safety
doesn't hurt. And you'll have enough drives to switch to raid6 (highly
recommended!) when your array is stable again.
> Thank you so much for your help!
You're welcome.
Phil
^ permalink raw reply
* Re: failed RAID 5 array
From: DeadManMoving @ 2014-11-14 15:53 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid, DeadManMoving
In-Reply-To: <5466173F.2060007@turmel.org>
Hi Phil,
On Fri, 2014-11-14 at 09:52 -0500, Phil Turmel wrote:
> Hi Tony,
>
> {Convention on kernel.org is to trim posts & bottom or interleave posts}
>
Thanks a lot for the advice.
>
> Indeed.
>
> At this point, I would use --create --assume-clean, along with
> "missing". You have a recent enough mdadm to specify
> --data-offset=2048, which you definitely need. Something like:
>
> mdadm --create /dev/mdX --assume-clean --data-offset=2048 \
> --level=5 --raid-devices=4 --chunk=512 \
> missing /dev/sd{f,i,h}
>
> You should verify the Device Role numbers with mdadm -E again, as your
> drive letters have changed from the initial report. To be absolutely
> sure, I suggest you record drive serial numbers for each role #. Also
> note the use of braces instead of square brackets--bash re-orders the
> latter, and that would break your array. For this type of recovery, it
> is vital that the devices be listed precisely in device role order,
> starting with zero.
>
> After creation, verify that the space before and space after stats for
> each device match the original report, before fsck or mount.
> (--data-offset controls space before, that plus --size controls space
> after.)
That is my plan to closely look at devices role to ensure proper order
in array creation. To avoid any mistake, i was planning to
use /dev/sda /dev/sdb /dev/sdc syntax instead of /dev/sd{a,b,c}, it's
probably the same, is it not?
Like said in my original post, i am making duplicate copies of each
disk, just to be extra safe. I already did it for two disks i have on
hands. I have ordered and waiting for two other drives to come in. As
soon as the copies will be done for the two other disks, i will try that
procedure. I will use the --data-offset parameter as you suggest.
Thank you so much for your help!
Tony
^ permalink raw reply
* Re: failed RAID 5 array
From: Phil Turmel @ 2014-11-14 14:52 UTC (permalink / raw)
To: DeadManMoving; +Cc: linux-raid
In-Reply-To: <1415974131.4241.41.camel@lappy.neofreak.org>
Hi Tony,
{Convention on kernel.org is to trim posts & bottom or interleave posts}
On 11/14/2014 09:08 AM, DeadManMoving wrote:
> Hi Phil,
>
> Unfortunately, that does not work :
>
> # mdadm --assemble --force /dev/md127 /dev/sd[fhi]
> mdadm: /dev/md127 assembled from 2 drives - not enough to start the
> array.
That's quite surprising.
> I don't think that booting with an alternate boot media will help me out
> as kernel and mdadm software are quite recent :
>
> # uname -r
> 3.14.14-gentoo
> # mdadm -V
> mdadm - v3.3.1 - 5th June 2014
Indeed.
At this point, I would use --create --assume-clean, along with
"missing". You have a recent enough mdadm to specify
--data-offset=2048, which you definitely need. Something like:
mdadm --create /dev/mdX --assume-clean --data-offset=2048 \
--level=5 --raid-devices=4 --chunk=512 \
missing /dev/sd{f,i,h}
You should verify the Device Role numbers with mdadm -E again, as your
drive letters have changed from the initial report. To be absolutely
sure, I suggest you record drive serial numbers for each role #. Also
note the use of braces instead of square brackets--bash re-orders the
latter, and that would break your array. For this type of recovery, it
is vital that the devices be listed precisely in device role order,
starting with zero.
After creation, verify that the space before and space after stats for
each device match the original report, before fsck or mount.
(--data-offset controls space before, that plus --size controls space
after.)
Phil
^ permalink raw reply
* Re: failed RAID 5 array
From: DeadManMoving @ 2014-11-14 14:08 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid, DeadManMoving
In-Reply-To: <546606D4.5070406@turmel.org>
Hi Phil,
Unfortunately, that does not work :
# mdadm --assemble --force /dev/md127 /dev/sd[fhi]
mdadm: /dev/md127 assembled from 2 drives - not enough to start the
array.
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : inactive sdf[1](S) sdh[4](S) sdi[2](S)
5860540680 blocks super 1.2
unused devices: <none>
# mdadm -D /dev/md127
/dev/md127:
Version : 1.2
Raid Level : raid0
Total Devices : 3
Persistence : Superblock is persistent
State : inactive
Name : abc:xyz (local to host abc)
UUID : d707f577:a9e572d5:e5d5f10c:b232f15a
Events : 9370
Number Major Minor RaidDevice
- 8 80 - /dev/sdf
- 8 112 - /dev/sdh
- 8 128 - /dev/sdi
I don't think that booting with an alternate boot media will help me out
as kernel and mdadm software are quite recent :
# uname -r
3.14.14-gentoo
# mdadm -V
mdadm - v3.3.1 - 5th June 2014
Thanks again,
Tony
On Fri, 2014-11-14 at 08:42 -0500, Phil Turmel wrote:
> On 11/14/2014 08:19 AM, DeadManMoving wrote:
> > Hi Phil,
> >
> > Thank you so much to have taken the time to write back to me.
> >
> > I already tried --assemble --force, indeed and, that did not work. I
> > guess it can work if you have a single drive which is out of sync but in
> > my case, it is a mix of a drive with a problematic superblock (dmesg =
> > does not have a valid v1.2 superblock, not importing!) plus a drive
> > which is out of sync (dmesg = kicking non-fresh sdx from array!).
> >
> > Here is the output of --assemble --force with double verbose :
> >
> >
> > # mdadm -vv --assemble
> > --force /dev/md127 /dev/sdf /dev/sdg /dev/sdh /dev/sdi
> > mdadm: looking for devices for /dev/md127
> > mdadm: /dev/sdf is busy - skipping
> > mdadm: /dev/sdh is busy - skipping
> > mdadm: /dev/sdi is busy - skipping
> > mdadm: Merging with already-assembled /dev/md/xyz
> > mdadm: /dev/sdi is identified as a member of /dev/md/xyz, slot 2.
> > mdadm: /dev/sdh is identified as a member of /dev/md/xyz, slot 3.
> > mdadm: /dev/sdf is identified as a member of /dev/md/xyz, slot 1.
> > mdadm: /dev/sdg is identified as a member of /dev/md/xyz, slot 0.
> > mdadm: /dev/sdf is already in /dev/md/xyz as 1
> > mdadm: /dev/sdi is already in /dev/md/xyz as 2
> > mdadm: /dev/sdh is already in /dev/md/xyz as 3
> > mdadm: failed to add /dev/sdg to /dev/md/xyz: Invalid argument
> > mdadm: failed to RUN_ARRAY /dev/md/xyz: Input/output error
> >
> >
> > If i stop the array (which was autostarted) and retry, similar output :
> >
> >
> > # mdadm -S /dev/md127
> > mdadm: stopped /dev/md127
> > # mdadm -vv --assemble
> > --force /dev/md127 /dev/sdf /dev/sdg /dev/sdh /dev/sdi
> > mdadm: looking for devices for /dev/md127
> > mdadm: /dev/sdf is identified as a member of /dev/md127, slot 1.
> > mdadm: /dev/sdg is identified as a member of /dev/md127, slot 0.
> > mdadm: /dev/sdh is identified as a member of /dev/md127, slot 3.
> > mdadm: /dev/sdi is identified as a member of /dev/md127, slot 2.
> > mdadm: added /dev/sdf to /dev/md127 as 1
> > mdadm: added /dev/sdi to /dev/md127 as 2
> > mdadm: added /dev/sdh to /dev/md127 as 3 (possibly out of date)
> > mdadm: failed to add /dev/sdg to /dev/md127: Invalid argument
> > mdadm: failed to RUN_ARRAY /dev/md127: Input/output error
> >
> >
> > Here is the relevant dmesg output :
> >
> > [173174.307703] sdf: unknown partition table
> > [173174.308374] sdg: unknown partition table
> > [173174.308811] md: bind<sdf>
> > [173174.309385] sdh: unknown partition table
> > [173174.309552] md: bind<sdi>
> > [173174.310411] sdi: unknown partition table
> > [173174.310573] md: bind<sdh>
> > [173174.311299] sdi: unknown partition table
> > [173174.311449] md: invalid superblock checksum on sdg
> > [173174.311450] md: sdg does not have a valid v1.2 superblock, not
> > importing!
> > [173174.311460] md: md_import_device returned -22
> > [173174.311482] md: kicking non-fresh sdh from array!
> > [173174.311498] md: unbind<sdh>
> > [173174.311909] sdh: unknown partition table
> > [173174.338007] md: export_rdev(sdh)
> > [173174.338651] md/raid:md127: device sdi operational as raid disk 2
> > [173174.338652] md/raid:md127: device sdf operational as raid disk 1
> > [173174.338868] md/raid:md127: allocated 0kB
> > [173174.338880] md/raid:md127: not enough operational devices (2/4
> > failed)
> > [173174.338886] RAID conf printout:
> > [173174.338887] --- level:5 rd:4 wd:2
> > [173174.338887] disk 1, o:1, dev:sdf
> > [173174.338888] disk 2, o:1, dev:sdi
> > [173174.339013] md/raid:md127: failed to run raid set.
> > [173174.339014] md: pers->run() failed ...
>
> Hmmm. Should have worked. Please show kernel version and mdadm
> version. There have been bugs fixed in this area in the past couple years.
>
> Also try "mdadm --assemble --force /dev/mdX /dev/sd[fhi]", leaving out
> the bad disk.
>
> If it still doesn't work, use alternate boot media, like systemrescuecd,
> to get a current kernel and mdadm combination and try again. If that
> works, get your critical backups before you do anything else.
>
> Then you can reboot back to your normal kernel and it should assemble
> degraded.
>
> Phil
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox