* [PATCH 18/24] overlayfs: use uuid_t instead of uuid_be
From: Christoph Hellwig @ 2017-05-31 16:18 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells,
linux-block-u79uwXL29TY76Z2rM5mHXA, Mimi Zohar, Steven Whitehouse
In-Reply-To: <20170531161826.23243-1-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Reviewed-by: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
fs/overlayfs/copy_up.c | 2 +-
fs/overlayfs/overlayfs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 5b795873f7fa..2a67e8c13098 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -233,7 +233,7 @@ int ovl_set_attr(struct dentry *upperdentry, struct kstat *stat)
return err;
}
-static struct ovl_fh *ovl_encode_fh(struct dentry *lower, uuid_be *uuid)
+static struct ovl_fh *ovl_encode_fh(struct dentry *lower, uuid_t *uuid)
{
struct ovl_fh *fh;
int fh_type, fh_len, dwords;
diff --git a/fs/overlayfs/overlayfs.h b/fs/overlayfs/overlayfs.h
index caa36cb9c46d..cb0fc450419b 100644
--- a/fs/overlayfs/overlayfs.h
+++ b/fs/overlayfs/overlayfs.h
@@ -55,7 +55,7 @@ struct ovl_fh {
u8 len; /* size of this header + size of fid */
u8 flags; /* OVL_FH_FLAG_* */
u8 type; /* fid_type of fid */
- uuid_be uuid; /* uuid of filesystem */
+ uuid_t uuid; /* uuid of filesystem */
u8 fid[0]; /* file identifier */
} __packed;
--
2.11.0
^ permalink raw reply related
* [PATCH 19/24] partitions/ldm: switch to use uuid_t
From: Christoph Hellwig @ 2017-05-31 16:18 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells,
linux-block-u79uwXL29TY76Z2rM5mHXA, Mimi Zohar, Steven Whitehouse
In-Reply-To: <20170531161826.23243-1-hch-jcswGhMUV9g@public.gmane.org>
And the uuid helpers.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Reviewed-by: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
block/partitions/ldm.c | 10 +++++-----
block/partitions/ldm.h | 6 ++----
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/block/partitions/ldm.c b/block/partitions/ldm.c
index edcea70674c9..2a365c756648 100644
--- a/block/partitions/ldm.c
+++ b/block/partitions/ldm.c
@@ -115,7 +115,7 @@ static bool ldm_parse_privhead(const u8 *data, struct privhead *ph)
ldm_error("PRIVHEAD disk size doesn't match real disk size");
return false;
}
- if (uuid_be_to_bin(data + 0x0030, (uuid_be *)ph->disk_id)) {
+ if (uuid_parse(data + 0x0030, &ph->disk_id)) {
ldm_error("PRIVHEAD contains an invalid GUID.");
return false;
}
@@ -234,7 +234,7 @@ static bool ldm_compare_privheads (const struct privhead *ph1,
(ph1->logical_disk_size == ph2->logical_disk_size) &&
(ph1->config_start == ph2->config_start) &&
(ph1->config_size == ph2->config_size) &&
- !memcmp (ph1->disk_id, ph2->disk_id, GUID_SIZE));
+ uuid_equal(&ph1->disk_id, &ph2->disk_id));
}
/**
@@ -557,7 +557,7 @@ static struct vblk * ldm_get_disk_objid (const struct ldmdb *ldb)
list_for_each (item, &ldb->v_disk) {
struct vblk *v = list_entry (item, struct vblk, list);
- if (!memcmp (v->vblk.disk.disk_id, ldb->ph.disk_id, GUID_SIZE))
+ if (uuid_equal(&v->vblk.disk.disk_id, &ldb->ph.disk_id))
return v;
}
@@ -892,7 +892,7 @@ static bool ldm_parse_dsk3 (const u8 *buffer, int buflen, struct vblk *vb)
disk = &vb->vblk.disk;
ldm_get_vstr (buffer + 0x18 + r_diskid, disk->alt_name,
sizeof (disk->alt_name));
- if (uuid_be_to_bin(buffer + 0x19 + r_name, (uuid_be *)disk->disk_id))
+ if (uuid_parse(buffer + 0x19 + r_name, &disk->disk_id))
return false;
return true;
@@ -927,7 +927,7 @@ static bool ldm_parse_dsk4 (const u8 *buffer, int buflen, struct vblk *vb)
return false;
disk = &vb->vblk.disk;
- memcpy (disk->disk_id, buffer + 0x18 + r_name, GUID_SIZE);
+ uuid_copy(&disk->disk_id, (uuid_t *)(buffer + 0x18 + r_name));
return true;
}
diff --git a/block/partitions/ldm.h b/block/partitions/ldm.h
index 374242c0971a..f4c6055df956 100644
--- a/block/partitions/ldm.h
+++ b/block/partitions/ldm.h
@@ -112,8 +112,6 @@ struct frag { /* VBLK Fragment handling */
/* In memory LDM database structures. */
-#define GUID_SIZE 16
-
struct privhead { /* Offsets and sizes are in sectors. */
u16 ver_major;
u16 ver_minor;
@@ -121,7 +119,7 @@ struct privhead { /* Offsets and sizes are in sectors. */
u64 logical_disk_size;
u64 config_start;
u64 config_size;
- u8 disk_id[GUID_SIZE];
+ uuid_t disk_id;
};
struct tocblock { /* We have exactly two bitmaps. */
@@ -154,7 +152,7 @@ struct vblk_dgrp { /* VBLK Disk Group */
};
struct vblk_disk { /* VBLK Disk */
- u8 disk_id[GUID_SIZE];
+ uuid_t disk_id;
u8 alt_name[128];
};
--
2.11.0
^ permalink raw reply related
* [PATCH 20/24] sysctl: switch to use uuid_t
From: Christoph Hellwig @ 2017-05-31 16:18 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells,
linux-block-u79uwXL29TY76Z2rM5mHXA, Mimi Zohar, Steven Whitehouse
In-Reply-To: <20170531161826.23243-1-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Reviewed-by: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
kernel/sysctl_binary.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
index ece4b177052b..939a158eab11 100644
--- a/kernel/sysctl_binary.c
+++ b/kernel/sysctl_binary.c
@@ -1119,7 +1119,7 @@ static ssize_t bin_uuid(struct file *file,
/* Only supports reads */
if (oldval && oldlen) {
char buf[UUID_STRING_LEN + 1];
- uuid_be uuid;
+ uuid_t uuid;
result = kernel_read(file, 0, buf, sizeof(buf) - 1);
if (result < 0)
@@ -1128,7 +1128,7 @@ static ssize_t bin_uuid(struct file *file,
buf[result] = '\0';
result = -EIO;
- if (uuid_be_to_bin(buf, &uuid))
+ if (uuid_parse(buf, &uuid))
goto out;
if (oldlen > 16)
--
2.11.0
^ permalink raw reply related
* [PATCH 21/24] nvme: switch to uuid_t
From: Christoph Hellwig @ 2017-05-31 16:18 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells,
linux-block-u79uwXL29TY76Z2rM5mHXA, Mimi Zohar, Steven Whitehouse
In-Reply-To: <20170531161826.23243-1-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Reviewed-by: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
drivers/nvme/host/fabrics.c | 8 ++++----
drivers/nvme/host/fabrics.h | 2 +-
drivers/nvme/host/fc.c | 3 +--
drivers/nvme/target/nvmet.h | 1 +
include/linux/nvme-fc.h | 3 +--
include/linux/nvme.h | 3 ++-
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c
index 990e6fb32a63..c190d7e36900 100644
--- a/drivers/nvme/host/fabrics.c
+++ b/drivers/nvme/host/fabrics.c
@@ -58,7 +58,7 @@ static struct nvmf_host *nvmf_host_add(const char *hostnqn)
kref_init(&host->ref);
memcpy(host->nqn, hostnqn, NVMF_NQN_SIZE);
- uuid_be_gen(&host->id);
+ uuid_gen(&host->id);
list_add_tail(&host->list, &nvmf_hosts);
out_unlock:
@@ -75,7 +75,7 @@ static struct nvmf_host *nvmf_host_default(void)
return NULL;
kref_init(&host->ref);
- uuid_be_gen(&host->id);
+ uuid_gen(&host->id);
snprintf(host->nqn, NVMF_NQN_SIZE,
"nqn.2014-08.org.nvmexpress:NVMf:uuid:%pUb", &host->id);
@@ -395,7 +395,7 @@ int nvmf_connect_admin_queue(struct nvme_ctrl *ctrl)
if (!data)
return -ENOMEM;
- memcpy(&data->hostid, &ctrl->opts->host->id, sizeof(uuid_be));
+ uuid_copy(&data->hostid, &ctrl->opts->host->id);
data->cntlid = cpu_to_le16(0xffff);
strncpy(data->subsysnqn, ctrl->opts->subsysnqn, NVMF_NQN_SIZE);
strncpy(data->hostnqn, ctrl->opts->host->nqn, NVMF_NQN_SIZE);
@@ -454,7 +454,7 @@ int nvmf_connect_io_queue(struct nvme_ctrl *ctrl, u16 qid)
if (!data)
return -ENOMEM;
- memcpy(&data->hostid, &ctrl->opts->host->id, sizeof(uuid_be));
+ uuid_copy(&data->hostid, &ctrl->opts->host->id);
data->cntlid = cpu_to_le16(ctrl->cntlid);
strncpy(data->subsysnqn, ctrl->opts->subsysnqn, NVMF_NQN_SIZE);
strncpy(data->hostnqn, ctrl->opts->host->nqn, NVMF_NQN_SIZE);
diff --git a/drivers/nvme/host/fabrics.h b/drivers/nvme/host/fabrics.h
index f5a9c1fb186f..29be7600689d 100644
--- a/drivers/nvme/host/fabrics.h
+++ b/drivers/nvme/host/fabrics.h
@@ -36,7 +36,7 @@ struct nvmf_host {
struct kref ref;
struct list_head list;
char nqn[NVMF_NQN_SIZE];
- uuid_be id;
+ uuid_t id;
};
/**
diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
index 5b14cbefb724..96b983bb44bd 100644
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -878,8 +878,7 @@ nvme_fc_connect_admin_queue(struct nvme_fc_ctrl *ctrl,
assoc_rqst->assoc_cmd.sqsize = cpu_to_be16(qsize);
/* Linux supports only Dynamic controllers */
assoc_rqst->assoc_cmd.cntlid = cpu_to_be16(0xffff);
- memcpy(&assoc_rqst->assoc_cmd.hostid, &ctrl->ctrl.opts->host->id,
- min_t(size_t, FCNVME_ASSOC_HOSTID_LEN, sizeof(uuid_be)));
+ uuid_copy(&assoc_rqst->assoc_cmd.hostid, &ctrl->ctrl.opts->host->id);
strncpy(assoc_rqst->assoc_cmd.hostnqn, ctrl->ctrl.opts->host->nqn,
min(FCNVME_ASSOC_HOSTNQN_LEN, NVMF_NQN_SIZE));
strncpy(assoc_rqst->assoc_cmd.subnqn, ctrl->ctrl.opts->subsysnqn,
diff --git a/drivers/nvme/target/nvmet.h b/drivers/nvme/target/nvmet.h
index cfc5c7fb0ab7..8ff6e430b30a 100644
--- a/drivers/nvme/target/nvmet.h
+++ b/drivers/nvme/target/nvmet.h
@@ -21,6 +21,7 @@
#include <linux/percpu-refcount.h>
#include <linux/list.h>
#include <linux/mutex.h>
+#include <linux/uuid.h>
#include <linux/nvme.h>
#include <linux/configfs.h>
#include <linux/rcupdate.h>
diff --git a/include/linux/nvme-fc.h b/include/linux/nvme-fc.h
index e997c4a49a88..bc711a10be05 100644
--- a/include/linux/nvme-fc.h
+++ b/include/linux/nvme-fc.h
@@ -177,7 +177,6 @@ struct fcnvme_lsdesc_rjt {
};
-#define FCNVME_ASSOC_HOSTID_LEN 16
#define FCNVME_ASSOC_HOSTNQN_LEN 256
#define FCNVME_ASSOC_SUBNQN_LEN 256
@@ -191,7 +190,7 @@ struct fcnvme_lsdesc_cr_assoc_cmd {
__be16 cntlid;
__be16 sqsize;
__be32 rsvd52;
- u8 hostid[FCNVME_ASSOC_HOSTID_LEN];
+ uuid_t hostid;
u8 hostnqn[FCNVME_ASSOC_HOSTNQN_LEN];
u8 subnqn[FCNVME_ASSOC_SUBNQN_LEN];
u8 rsvd632[384];
diff --git a/include/linux/nvme.h b/include/linux/nvme.h
index b625bacf37ef..e400a69fa1d3 100644
--- a/include/linux/nvme.h
+++ b/include/linux/nvme.h
@@ -16,6 +16,7 @@
#define _LINUX_NVME_H
#include <linux/types.h>
+#include <linux/uuid.h>
/* NQN names in commands fields specified one size */
#define NVMF_NQN_FIELD_LEN 256
@@ -843,7 +844,7 @@ struct nvmf_connect_command {
};
struct nvmf_connect_data {
- __u8 hostid[16];
+ uuid_t hostid;
__le16 cntlid;
char resv4[238];
char subsysnqn[NVMF_NQN_FIELD_LEN];
--
2.11.0
^ permalink raw reply related
* [PATCH 22/24] scsi_debug: switch to uuid_t
From: Christoph Hellwig @ 2017-05-31 16:18 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells,
linux-block-u79uwXL29TY76Z2rM5mHXA, Mimi Zohar, Steven Whitehouse
In-Reply-To: <20170531161826.23243-1-hch-jcswGhMUV9g@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Reviewed-by: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
drivers/scsi/scsi_debug.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 17249c3650fe..35ee09644cfb 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -245,7 +245,7 @@ struct sdebug_dev_info {
unsigned int channel;
unsigned int target;
u64 lun;
- uuid_be lu_name;
+ uuid_t lu_name;
struct sdebug_host_info *sdbg_host;
unsigned long uas_bm[1];
atomic_t num_in_q;
@@ -965,7 +965,7 @@ static const u64 naa3_comp_c = 0x3111111000000000ULL;
static int inquiry_vpd_83(unsigned char *arr, int port_group_id,
int target_dev_id, int dev_id_num,
const char *dev_id_str, int dev_id_str_len,
- const uuid_be *lu_name)
+ const uuid_t *lu_name)
{
int num, port_a;
char b[32];
@@ -3568,7 +3568,7 @@ static void sdebug_q_cmd_wq_complete(struct work_struct *work)
}
static bool got_shared_uuid;
-static uuid_be shared_uuid;
+static uuid_t shared_uuid;
static struct sdebug_dev_info *sdebug_device_create(
struct sdebug_host_info *sdbg_host, gfp_t flags)
@@ -3578,12 +3578,12 @@ static struct sdebug_dev_info *sdebug_device_create(
devip = kzalloc(sizeof(*devip), flags);
if (devip) {
if (sdebug_uuid_ctl == 1)
- uuid_be_gen(&devip->lu_name);
+ uuid_gen(&devip->lu_name);
else if (sdebug_uuid_ctl == 2) {
if (got_shared_uuid)
devip->lu_name = shared_uuid;
else {
- uuid_be_gen(&shared_uuid);
+ uuid_gen(&shared_uuid);
got_shared_uuid = true;
devip->lu_name = shared_uuid;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 23/24] tmpfs: generate random sb->s_uuid
From: Christoph Hellwig @ 2017-05-31 16:18 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA, Andrew Morton,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li, Hugh Dickins,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells,
linux-block-u79uwXL29TY76Z2rM5mHXA, Mimi Zohar, Steven Whitehouse
In-Reply-To: <20170531161826.23243-1-hch-jcswGhMUV9g@public.gmane.org>
From: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This is used by overlayfs to encode intrasystem unique file handles.
Suggested-by: Miklos Szeredi <mszeredi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: Amir Goldstein <amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
mm/shmem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/shmem.c b/mm/shmem.c
index e67d6ba4e98e..391f2dcca727 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -75,6 +75,7 @@ static struct vfsmount *shm_mnt;
#include <uapi/linux/memfd.h>
#include <linux/userfaultfd_k.h>
#include <linux/rmap.h>
+#include <linux/uuid.h>
#include <linux/uaccess.h>
#include <asm/pgtable.h>
@@ -3761,6 +3762,7 @@ int shmem_fill_super(struct super_block *sb, void *data, int silent)
#ifdef CONFIG_TMPFS_POSIX_ACL
sb->s_flags |= MS_POSIXACL;
#endif
+ uuid_gen(&sb->s_uuid);
inode = shmem_get_inode(sb, NULL, S_IFDIR | sbinfo->mode, 0, VM_NORESERVE);
if (!inode)
--
2.11.0
^ permalink raw reply related
* [PATCH 24/24] MAINTAINERS: add uuid entry
From: Christoph Hellwig @ 2017-05-31 16:18 UTC (permalink / raw)
To: Andy Shevchenko, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells,
linux-block-u79uwXL29TY76Z2rM5mHXA, Mimi Zohar, Steven Whitehouse
In-Reply-To: <20170531161826.23243-1-hch-jcswGhMUV9g@public.gmane.org>
I'll keep maintaining whatever little changed we need here, with Andy as
my designated reviewer.
Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
MAINTAINERS | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 053c3bdd1fe5..660c14729205 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13463,6 +13463,17 @@ W: http://en.wikipedia.org/wiki/Util-linux
T: git git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
S: Maintained
+UUID HELPERS
+M: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
+R: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
+L: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+T: git git://git.infradead.org/users/hch/uuid.git
+F: lib/uuid.c
+F: lib/test_uuid.c
+F: include/linux/uuid.h
+F: include/uapi/linux/uuid.h
+S: Maintained
+
UVESAFB DRIVER
M: Michal Januszewski <spock-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
L: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 2/2] md: Make flush bios explicitely sync
From: Shaohua Li @ 2017-05-31 16:23 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-raid, stable
In-Reply-To: <20170531074433.14298-3-jack@suse.cz>
On Wed, May 31, 2017 at 09:44:33AM +0200, Jan Kara wrote:
> Commit b685d3d65ac7 "block: treat REQ_FUA and REQ_PREFLUSH as
> synchronous" removed REQ_SYNC flag from WRITE_{FUA|PREFLUSH|...}
> definitions. generic_make_request_checks() however strips REQ_FUA and
> REQ_PREFLUSH flags from a bio when the storage doesn't report volatile
> write cache and thus write effectively becomes asynchronous which can
> lead to performance regressions
>
> Fix the problem by making sure all bios which are synchronous are
> properly marked with REQ_SYNC.
Applied, thanks!
> CC: linux-raid@vger.kernel.org
> CC: Shaohua Li <shli@kernel.org>
> Fixes: b685d3d65ac791406e0dfd8779cc9b3707fea5a3
> CC: stable@vger.kernel.org
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
> drivers/md/md.c | 2 +-
> drivers/md/raid5-cache.c | 4 ++--
> drivers/md/raid5-ppl.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 10367ffe92e3..212a6777ff31 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -765,7 +765,7 @@ void md_super_write(struct mddev *mddev, struct md_rdev *rdev,
> test_bit(FailFast, &rdev->flags) &&
> !test_bit(LastDev, &rdev->flags))
> ff = MD_FAILFAST;
> - bio->bi_opf = REQ_OP_WRITE | REQ_PREFLUSH | REQ_FUA | ff;
> + bio->bi_opf = REQ_OP_WRITE | REQ_SYNC | REQ_PREFLUSH | REQ_FUA | ff;
>
> atomic_inc(&mddev->pending_writes);
> submit_bio(bio);
> diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> index 4c00bc248287..0a7af8b0a80a 100644
> --- a/drivers/md/raid5-cache.c
> +++ b/drivers/md/raid5-cache.c
> @@ -1782,7 +1782,7 @@ static int r5l_log_write_empty_meta_block(struct r5l_log *log, sector_t pos,
> mb->checksum = cpu_to_le32(crc32c_le(log->uuid_checksum,
> mb, PAGE_SIZE));
> if (!sync_page_io(log->rdev, pos, PAGE_SIZE, page, REQ_OP_WRITE,
> - REQ_FUA, false)) {
> + REQ_SYNC | REQ_FUA, false)) {
> __free_page(page);
> return -EIO;
> }
> @@ -2388,7 +2388,7 @@ r5c_recovery_rewrite_data_only_stripes(struct r5l_log *log,
> mb->checksum = cpu_to_le32(crc32c_le(log->uuid_checksum,
> mb, PAGE_SIZE));
> sync_page_io(log->rdev, ctx->pos, PAGE_SIZE, page,
> - REQ_OP_WRITE, REQ_FUA, false);
> + REQ_OP_WRITE, REQ_SYNC | REQ_FUA, false);
> sh->log_start = ctx->pos;
> list_add_tail(&sh->r5c, &log->stripe_in_journal_list);
> atomic_inc(&log->stripe_in_journal_count);
> diff --git a/drivers/md/raid5-ppl.c b/drivers/md/raid5-ppl.c
> index 5d25bebf3328..ccce92e68d7f 100644
> --- a/drivers/md/raid5-ppl.c
> +++ b/drivers/md/raid5-ppl.c
> @@ -907,8 +907,8 @@ static int ppl_write_empty_header(struct ppl_log *log)
> pplhdr->checksum = cpu_to_le32(~crc32c_le(~0, pplhdr, PAGE_SIZE));
>
> if (!sync_page_io(rdev, rdev->ppl.sector - rdev->data_offset,
> - PPL_HEADER_SIZE, page, REQ_OP_WRITE | REQ_FUA, 0,
> - false)) {
> + PPL_HEADER_SIZE, page, REQ_OP_WRITE | REQ_SYNC |
> + REQ_FUA, 0, false)) {
> md_error(rdev->mddev, rdev);
> ret = -EIO;
> }
> --
> 2.12.3
>
^ permalink raw reply
* Re: [PATCH 08/24] uuid: rename uuid_to_bin to uuid_parse
From: Andy Shevchenko @ 2017-05-31 18:14 UTC (permalink / raw)
To: Christoph Hellwig, Amir Goldstein,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Shaohua Li,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Howells,
linux-block-u79uwXL29TY76Z2rM5mHXA, Mimi Zohar, Steven Whitehouse
In-Reply-To: <20170531161826.23243-9-hch-jcswGhMUV9g@public.gmane.org>
On Wed, 2017-05-31 at 18:18 +0200, Christoph Hellwig wrote:
> This matches the userspace version of it, and describes the
> functionality
> much better. Also do the same for the guid version.
>
No objections for renaming, though I'm pretty sure it should be squashed
to patch 6.
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/uuid.h | 8 ++++----
> lib/test_uuid.c | 8 ++++----
> lib/uuid.c | 14 +++++++-------
> 3 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/uuid.h b/include/linux/uuid.h
> index a9d0fdba5404..82b165b579f5 100644
> --- a/include/linux/uuid.h
> +++ b/include/linux/uuid.h
> @@ -45,8 +45,8 @@ bool __must_check uuid_is_valid(const char *uuid);
> extern const u8 guid_index[16];
> extern const u8 uuid_index[16];
>
> -int guid_to_bin(const char *uuid, guid_t *u);
> -int uuid_to_bin(const char *uuid, uuid_t *u);
> +int guid_parse(const char *uuid, guid_t *u);
> +int uuid_parse(const char *uuid, uuid_t *u);
>
> /* backwards compatibility, don't use in new code */
> typedef uuid_t uuid_be;
> @@ -58,8 +58,8 @@ typedef uuid_t uuid_be;
>
> #define uuid_le_gen(u) guid_gen(u)
> #define uuid_be_gen(u) uuid_gen(u)
> -#define uuid_le_to_bin(guid, u) guid_to_bin(guid, u)
> -#define uuid_be_to_bin(uuid, u) uuid_to_bin(uuid, u)
> +#define uuid_le_to_bin(guid, u) guid_parse(guid, u)
> +#define uuid_be_to_bin(uuid, u) uuid_parse(uuid, u)
>
> static inline int uuid_le_cmp(const guid_t u1, const guid_t u2)
> {
> diff --git a/lib/test_uuid.c b/lib/test_uuid.c
> index 9cad846fd805..edda536a7b45 100644
> --- a/lib/test_uuid.c
> +++ b/lib/test_uuid.c
> @@ -67,7 +67,7 @@ static void __init test_uuid_test(const struct
> test_uuid_data *data)
>
> /* LE */
> total_tests++;
> - if (guid_to_bin(data->uuid, &le))
> + if (guid_parse(data->uuid, &le))
> test_uuid_failed("conversion", false, false, data-
> >uuid, NULL);
>
> total_tests++;
> @@ -78,7 +78,7 @@ static void __init test_uuid_test(const struct
> test_uuid_data *data)
>
> /* BE */
> total_tests++;
> - if (uuid_to_bin(data->uuid, &be))
> + if (uuid_parse(data->uuid, &be))
> test_uuid_failed("conversion", false, true, data-
> >uuid, NULL);
>
> total_tests++;
> @@ -95,12 +95,12 @@ static void __init test_uuid_wrong(const char
> *data)
>
> /* LE */
> total_tests++;
> - if (!guid_to_bin(data, &le))
> + if (!guid_parse(data, &le))
> test_uuid_failed("negative", true, false, data,
> NULL);
>
> /* BE */
> total_tests++;
> - if (!uuid_to_bin(data, &be))
> + if (!uuid_parse(data, &be))
> test_uuid_failed("negative", true, true, data, NULL);
> }
>
> diff --git a/lib/uuid.c b/lib/uuid.c
> index f80dc63f6ca8..90bee73f7bd7 100644
> --- a/lib/uuid.c
> +++ b/lib/uuid.c
> @@ -97,7 +97,7 @@ bool uuid_is_valid(const char *uuid)
> }
> EXPORT_SYMBOL(uuid_is_valid);
>
> -static int __uuid_to_bin(const char *uuid, __u8 b[16], const u8
> ei[16])
> +static int __uuid_parse(const char *uuid, __u8 b[16], const u8
> ei[16])
> {
> static const u8 si[16] =
> {0,2,4,6,9,11,14,16,19,21,24,26,28,30,32,34};
> unsigned int i;
> @@ -115,14 +115,14 @@ static int __uuid_to_bin(const char *uuid, __u8
> b[16], const u8 ei[16])
> return 0;
> }
>
> -int guid_to_bin(const char *uuid, guid_t *u)
> +int guid_parse(const char *uuid, guid_t *u)
> {
> - return __uuid_to_bin(uuid, u->b, guid_index);
> + return __uuid_parse(uuid, u->b, guid_index);
> }
> -EXPORT_SYMBOL(guid_to_bin);
> +EXPORT_SYMBOL(guid_parse);
>
> -int uuid_to_bin(const char *uuid, uuid_t *u)
> +int uuid_parse(const char *uuid, uuid_t *u)
> {
> - return __uuid_to_bin(uuid, u->b, uuid_index);
> + return __uuid_parse(uuid, u->b, uuid_index);
> }
> -EXPORT_SYMBOL(uuid_to_bin);
> +EXPORT_SYMBOL(uuid_parse);
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [PATCH 15/24] block: remove blk_part_pack_uuid
From: Andy Shevchenko @ 2017-05-31 18:16 UTC (permalink / raw)
To: Christoph Hellwig, Amir Goldstein, linux-fsdevel
Cc: Shaohua Li, Dan Williams, David Howells, Steven Whitehouse,
Mimi Zohar, linux-xfs, linux-raid, linux-nvdimm, linux-kernel,
linux-block
In-Reply-To: <20170531161826.23243-16-hch@lst.de>
On Wed, 2017-05-31 at 18:18 +0200, Christoph Hellwig wrote:
> This helper was only used by IMA of all things, which would get
> spurious
> errors if CONFIG_BLOCK is disabled. Just opencode the call there.
> - result = blk_part_pack_uuid(args[0].from,
> - entry->fsuuid);
> + result = uuid_to_bin(args[0].from, (uuid_t
> *)&entry->fsuuid);
>
uuid_parse() ?
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH 01/24] uuid,afs: move struct uuid_v1 back into afs
From: David Howells @ 2017-05-31 18:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dhowells, Andy Shevchenko, Amir Goldstein, linux-fsdevel,
Shaohua Li, Dan Williams, Steven Whitehouse, Mimi Zohar,
linux-xfs, linux-raid, linux-nvdimm, linux-kernel, linux-block
In-Reply-To: <20170531161826.23243-2-hch@lst.de>
Christoph Hellwig <hch@lst.de> wrote:
> This essentially is a partial revert of commit ff548773
> ("afs: Move UUID struct to linux/uuid.h") and moves struct uuid_v1 back into
> fs/afs as struct afs_uuid. It however keeps it as big endian structure
> so that we can use the normal uuid generation helpers when casting to/from
> struct afs_uuid.
>
> The V1 uuid intrepreatation in struct form isn't really useful to the
> rest of the kernel, and not really compatible to it either, so move it
> back to AFS instead of polluting the global uuid.h.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: [PATCH 15/24] block: remove blk_part_pack_uuid
From: Christoph Hellwig @ 2017-05-31 19:39 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Mimi Zohar, Amir Goldstein,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Steven Whitehouse,
David Howells, linux-block-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Shaohua Li,
Christoph Hellwig
In-Reply-To: <1496254594.28981.37.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Wed, May 31, 2017 at 09:16:34PM +0300, Andy Shevchenko wrote:
> On Wed, 2017-05-31 at 18:18 +0200, Christoph Hellwig wrote:
> > This helper was only used by IMA of all things, which would get
> > spurious
> > errors if CONFIG_BLOCK is disabled. Just opencode the call there.
>
> > - result = blk_part_pack_uuid(args[0].from,
> > - entry->fsuuid);
> > + result = uuid_to_bin(args[0].from, (uuid_t
> > *)&entry->fsuuid);
> >
>
> uuid_parse() ?
Yes. I fixed this up, but it seems like I didn't squash it into
the right patch..
^ permalink raw reply
* Re: [PATCH 08/24] uuid: rename uuid_to_bin to uuid_parse
From: Christoph Hellwig @ 2017-05-31 19:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw, Mimi Zohar, Amir Goldstein,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Steven Whitehouse,
David Howells, linux-block-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Shaohua Li,
Christoph Hellwig
In-Reply-To: <1496254475.28981.36.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Wed, May 31, 2017 at 09:14:35PM +0300, Andy Shevchenko wrote:
> On Wed, 2017-05-31 at 18:18 +0200, Christoph Hellwig wrote:
> > This matches the userspace version of it, and describes the
> > functionality
> > much better. Also do the same for the guid version.
> >
>
> No objections for renaming, though I'm pretty sure it should be squashed
> to patch 6.
Fine with me, it just seemed like a unrelated enough change to justify
keeping it separate.
^ permalink raw reply
* The dev node can't be released at once after stopping raid
From: Xiao Ni @ 2017-06-01 3:47 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <51439640.15505639.1496113073965.JavaMail.zimbra@redhat.com>
Hi all
I tried with the latest linux stable kernel and latest mdadm.
After stopping a raid device, the dev node directory can't be released
at once. I did a simple test, the script is:
#!/bin/sh
while [ 1 ]; do
mdadm -CR /dev/md0 -l1 -n2 /dev/loop0 /dev/loop1
sleep 5
mdadm -S /dev/md0
ls /dev/md0
sleep 1
ls /dev/md0
done
mdadm: stopped /dev/md0
/dev/md0
ls: cannot access /dev/md0: No such file or directory
It usually detects dev node /dev/md0 isn't released after stopping raid.
I'm not sure whether it's a bug or not. Do we need to do some job to
make sure that the node should be released before command mdadm -S return?
Best Regards
Xiao
^ permalink raw reply
* Re: The dev node can't be released at once after stopping raid
From: Zhilong Liu @ 2017-06-01 4:43 UTC (permalink / raw)
To: Xiao Ni, linux-raid
In-Reply-To: <1159964415.16461871.1496288839399.JavaMail.zimbra@redhat.com>
On 06/01/2017 11:47 AM, Xiao Ni wrote:
> Hi all
>
> I tried with the latest linux stable kernel and latest mdadm.
>
> After stopping a raid device, the dev node directory can't be released
> at once. I did a simple test, the script is:
>
> #!/bin/sh
>
> while [ 1 ]; do
> mdadm -CR /dev/md0 -l1 -n2 /dev/loop0 /dev/loop1
> sleep 5
> mdadm -S /dev/md0
> ls /dev/md0
> sleep 1
> ls /dev/md0
> done
>
> mdadm: stopped /dev/md0
> /dev/md0
> ls: cannot access /dev/md0: No such file or directory
>
> It usually detects dev node /dev/md0 isn't released after stopping raid.
> I'm not sure whether it's a bug or not. Do we need to do some job to
> make sure that the node should be released before command mdadm -S return?
it's waiting for processing the udev events. we can monitor it via to "#
udevadm monitor".
For mdadm -S /dev/md0, Manage_stop() has already did the errno checking,
cut piece of code from Manage.c
.. .. .. ..
done:
/* As we have an O_EXCL open, any use of the device
* which blocks STOP_ARRAY is probably a transient use,
* so it is reasonable to retry for a while - 5 seconds.
*/
count = 25; err = 0;
while (count && fd >= 0 &&
(err = ioctl(fd, STOP_ARRAY, NULL)) < 0 && errno == EBUSY) {
usleep(200000);
count --;
}
Best regards,
-Zhilong
> Best Regards
> Xiao
> --
> 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: The dev node can't be released at once after stopping raid
From: Xiao Ni @ 2017-06-01 5:50 UTC (permalink / raw)
To: Zhilong Liu; +Cc: linux-raid
In-Reply-To: <43bca632-9d77-2063-603c-6dcf47f3d250@suse.com>
----- Original Message -----
> From: "Zhilong Liu" <zlliu@suse.com>
> To: "Xiao Ni" <xni@redhat.com>, linux-raid@vger.kernel.org
> Sent: Thursday, June 1, 2017 12:43:49 PM
> Subject: Re: The dev node can't be released at once after stopping raid
>
>
>
> On 06/01/2017 11:47 AM, Xiao Ni wrote:
> > Hi all
> >
> > I tried with the latest linux stable kernel and latest mdadm.
> >
> > After stopping a raid device, the dev node directory can't be released
> > at once. I did a simple test, the script is:
> >
> > #!/bin/sh
> >
> > while [ 1 ]; do
> > mdadm -CR /dev/md0 -l1 -n2 /dev/loop0 /dev/loop1
> > sleep 5
> > mdadm -S /dev/md0
> > ls /dev/md0
> > sleep 1
> > ls /dev/md0
> > done
> >
> > mdadm: stopped /dev/md0
> > /dev/md0
> > ls: cannot access /dev/md0: No such file or directory
> >
> > It usually detects dev node /dev/md0 isn't released after stopping raid.
> > I'm not sure whether it's a bug or not. Do we need to do some job to
> > make sure that the node should be released before command mdadm -S return?
>
> it's waiting for processing the udev events. we can monitor it via to "#
> udevadm monitor".
>
> For mdadm -S /dev/md0, Manage_stop() has already did the errno checking,
>
> cut piece of code from Manage.c
> .. .. .. ..
> done:
>
> /* As we have an O_EXCL open, any use of the device
> * which blocks STOP_ARRAY is probably a transient use,
> * so it is reasonable to retry for a while - 5 seconds.
> */
> count = 25; err = 0;
> while (count && fd >= 0 &&
> (err = ioctl(fd, STOP_ARRAY, NULL)) < 0 && errno == EBUSY) {
> usleep(200000);
> count --;
> }
Hi Zhilong
Good suggestions. I tried it and it can add some codes in the script to wait.
Is it better to check the udev events in mdadm? Let's check it after closing
mdfd when Manage_stop returns. Because it's mdadm's job, right?
Regards
Xiao
>
> Best regards,
> -Zhilong
>
> > Best Regards
> > Xiao
> > --
> > 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: RAID10 performance with 20 drives
From: CoolCold @ 2017-06-01 5:59 UTC (permalink / raw)
To: Roman Mamedov; +Cc: Linux RAID
In-Reply-To: <20170531191441.40240b7f@natsu>
Hello!
Roman, i've updated the kernel to 4.11 and started "check" action,
results are basically the same, output on github
https://gist.github.com/CoolCold/663de7c006490d7fd0ac7cc98b7a6844
1 cpu is overloaded, not more than 1.3 - 1.4GB/sec
On Wed, May 31, 2017 at 9:14 PM, Roman Mamedov <rm@romanrm.net> wrote:
> On Wed, 31 May 2017 19:20:10 +0700
> CoolCold <coolthecold@gmail.com> wrote:
>
>> Creation (disable write intent bitmap, with bitmap all is much worse):
>> mdadm --create -c 64 -b none -n 20 -l 10 /dev/md1 /dev/sde /dev/sdf
>> /dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm
>> /dev/sdn /dev/sdo /dev/sdp /dev/sdq /dev/sdr /dev/sds /dev/sdt
>> /dev/sdu /dev/sdv /dev/sdw /dev/sdx
>>
>> kernel:
>> [root@spare-a17484327407661 rovchinnikov]# cat /proc/version
>> Linux version 3.10.0-327.el7.x86_64 (builder@kbuilder.dev.centos.org)
>> (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Thu Nov
>> 19 22:10:57 UTC 2015
>>
>> So, the question is - why cpu usage is so high and I suppose is a limit here?
>
> Definitely try a newer kernel, 4.4 at the very least; if no changes then 4.11.
>
> Also I would suggest to try out larger chunk sizes, such as 512 and 1024 KB.
>
> If you plan to use this long-term in production, also read up on the various
> RAID10 data layouts and their benefits and downsides (man md, search for
> "layout"; and search the Internet for benchmarks of all three).
>
> --
> With respect,
> Roman
--
Best regards,
[COOLCOLD-RIPN]
^ permalink raw reply
* Re: RAID10 performance with 20 drives
From: Pasi Kärkkäinen @ 2017-06-01 6:33 UTC (permalink / raw)
To: CoolCold; +Cc: Roman Mamedov, Linux RAID
In-Reply-To: <CAGqmV7qB=8a_peu2gsU9Xne6v4nymT-O+vhDwkwaUJhyYpkieg@mail.gmail.com>
On Thu, Jun 01, 2017 at 12:59:01PM +0700, CoolCold wrote:
> Hello!
> Roman, i've updated the kernel to 4.11 and started "check" action,
> results are basically the same, output on github
> https://gist.github.com/CoolCold/663de7c006490d7fd0ac7cc98b7a6844
> 1 cpu is overloaded, not more than 1.3 - 1.4GB/sec
>
You need to provide more details about the actual storage setup.
Like already said/asked for:
- Which HBA are you using?
- Which PCIe link speed are you using for the HBA?
- Which driver version for the HBA?
- Which HBA firmware version?
- How are the disks connected to the HBA ? Direct-connect, or via an Expander?
- If you have an expander, what's the (SAS) link speed/count between the HBA(s) and the Expander?
-- Pasi
> On Wed, May 31, 2017 at 9:14 PM, Roman Mamedov <rm@romanrm.net> wrote:
> > On Wed, 31 May 2017 19:20:10 +0700
> > CoolCold <coolthecold@gmail.com> wrote:
> >
> >> Creation (disable write intent bitmap, with bitmap all is much worse):
> >> mdadm --create -c 64 -b none -n 20 -l 10 /dev/md1 /dev/sde /dev/sdf
> >> /dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm
> >> /dev/sdn /dev/sdo /dev/sdp /dev/sdq /dev/sdr /dev/sds /dev/sdt
> >> /dev/sdu /dev/sdv /dev/sdw /dev/sdx
> >>
> >> kernel:
> >> [root@spare-a17484327407661 rovchinnikov]# cat /proc/version
> >> Linux version 3.10.0-327.el7.x86_64 (builder@kbuilder.dev.centos.org)
> >> (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Thu Nov
> >> 19 22:10:57 UTC 2015
> >>
> >> So, the question is - why cpu usage is so high and I suppose is a limit here?
> >
> > Definitely try a newer kernel, 4.4 at the very least; if no changes then 4.11.
> >
> > Also I would suggest to try out larger chunk sizes, such as 512 and 1024 KB.
> >
> > If you plan to use this long-term in production, also read up on the various
> > RAID10 data layouts and their benefits and downsides (man md, search for
> > "layout"; and search the Internet for benchmarks of all three).
> >
> > --
> > With respect,
> > Roman
>
>
>
> --
> Best regards,
> [COOLCOLD-RIPN]
> --
> 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: RAID10 performance with 20 drives
From: Roger Heflin @ 2017-06-01 11:20 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: CoolCold, Roman Mamedov, Linux RAID
In-Reply-To: <20170601063318.GJ24459@reaktio.net>
Also supply an "iostat -x 1 5" since that will show each disks usage.
vmstat in my experience does not appear to show internal MD disk traffic.
On Thu, Jun 1, 2017 at 1:33 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Thu, Jun 01, 2017 at 12:59:01PM +0700, CoolCold wrote:
>> Hello!
>> Roman, i've updated the kernel to 4.11 and started "check" action,
>> results are basically the same, output on github
>> https://gist.github.com/CoolCold/663de7c006490d7fd0ac7cc98b7a6844
>> 1 cpu is overloaded, not more than 1.3 - 1.4GB/sec
>>
>
> You need to provide more details about the actual storage setup.
>
> Like already said/asked for:
>
> - Which HBA are you using?
> - Which PCIe link speed are you using for the HBA?
> - Which driver version for the HBA?
> - Which HBA firmware version?
>
> - How are the disks connected to the HBA ? Direct-connect, or via an Expander?
> - If you have an expander, what's the (SAS) link speed/count between the HBA(s) and the Expander?
>
>
> -- Pasi
>
>> On Wed, May 31, 2017 at 9:14 PM, Roman Mamedov <rm@romanrm.net> wrote:
>> > On Wed, 31 May 2017 19:20:10 +0700
>> > CoolCold <coolthecold@gmail.com> wrote:
>> >
>> >> Creation (disable write intent bitmap, with bitmap all is much worse):
>> >> mdadm --create -c 64 -b none -n 20 -l 10 /dev/md1 /dev/sde /dev/sdf
>> >> /dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm
>> >> /dev/sdn /dev/sdo /dev/sdp /dev/sdq /dev/sdr /dev/sds /dev/sdt
>> >> /dev/sdu /dev/sdv /dev/sdw /dev/sdx
>> >>
>> >> kernel:
>> >> [root@spare-a17484327407661 rovchinnikov]# cat /proc/version
>> >> Linux version 3.10.0-327.el7.x86_64 (builder@kbuilder.dev.centos.org)
>> >> (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Thu Nov
>> >> 19 22:10:57 UTC 2015
>> >>
>> >> So, the question is - why cpu usage is so high and I suppose is a limit here?
>> >
>> > Definitely try a newer kernel, 4.4 at the very least; if no changes then 4.11.
>> >
>> > Also I would suggest to try out larger chunk sizes, such as 512 and 1024 KB.
>> >
>> > If you plan to use this long-term in production, also read up on the various
>> > RAID10 data layouts and their benefits and downsides (man md, search for
>> > "layout"; and search the Internet for benchmarks of all three).
>> >
>> > --
>> > With respect,
>> > Roman
>>
>>
>>
>> --
>> Best regards,
>> [COOLCOLD-RIPN]
>> --
>> 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
* [PATCH] md: simplify code with bio_io_error
From: Guoqing Jiang @ 2017-06-02 7:49 UTC (permalink / raw)
To: linux-raid; +Cc: shli, Guoqing Jiang
bio_io_error was introduced in the commit 4246a0b
("block: add a bi_error field to struct bio"), so
use it to simplify code.
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/raid1.c | 3 +--
drivers/md/raid10.c | 3 +--
drivers/md/raid5.c | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index af5056d..c20eb78 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -802,8 +802,7 @@ static void flush_bio_list(struct r1conf *conf, struct bio *bio)
bio->bi_next = NULL;
bio->bi_bdev = rdev->bdev;
if (test_bit(Faulty, &rdev->flags)) {
- bio->bi_error = -EIO;
- bio_endio(bio);
+ bio_io_error(bio);
} else if (unlikely((bio_op(bio) == REQ_OP_DISCARD) &&
!blk_queue_discard(bdev_get_queue(bio->bi_bdev))))
/* Just ignore it */
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 4343d7f..ceb9709 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -913,8 +913,7 @@ static void flush_pending_writes(struct r10conf *conf)
bio->bi_next = NULL;
bio->bi_bdev = rdev->bdev;
if (test_bit(Faulty, &rdev->flags)) {
- bio->bi_error = -EIO;
- bio_endio(bio);
+ bio_io_error(bio);
} else if (unlikely((bio_op(bio) == REQ_OP_DISCARD) &&
!blk_queue_discard(bdev_get_queue(bio->bi_bdev))))
/* Just ignore it */
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 7220646..57aa044 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3429,8 +3429,7 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
struct bio *nextbi =
r5_next_bio(bi, sh->dev[i].sector);
- bi->bi_error = -EIO;
- bio_endio(bi);
+ bio_io_error(bi);
bi = nextbi;
}
}
--
2.10.0
^ permalink raw reply related
* Re: Grow set size issue
From: Tomasz Majchrzak @ 2017-06-02 11:01 UTC (permalink / raw)
To: Jes Sorensen; +Cc: NeilBrown, linux-raid
In-Reply-To: <89891c04-620c-0dc2-97af-719b480aa4e5@gmail.com>
On Thu, Mar 30, 2017 at 10:10:32AM -0400, Jes Sorensen wrote:
> On 03/29/2017 05:34 PM, NeilBrown wrote:
> >On Thu, Mar 30 2017, jes.sorensen@gmail.com wrote:
> >
> >>Hi Neil,
> >>
> >>In the below patch you changed the error handling, to make the kernel
> >>not setting the size of the device being an error. However we still have
> >>the code in place to handle the error, except it never triggers.
> >
> >So we do. I should have removed all of that.
> >I should have just reverted
> >Commit: 65a9798b58b4 ("FIX: Detect error and rollback metadata")
> >
> >
> >>
> >>Question is do you remember the reason for this change? Old kernels not
> >>allowing it, are there any legitimate reasons for the kernel to refuse
> >>the size change?
> >
> >I needed to go further back to remind myself why we do these size change
> >at all.
> >The command being run here is "mdadm --grow /dev/mdX --size=foo"
> >which has a primary purpose of changing the component_size of the array.
> >What can happen is that someone makes all the components bigger
> >(E.g. with LVM) and then uses this command to set --size=max, and it
> >doesn't work. That is because md doesn't know the devices are bigger.
> >
> >You can tell md that devices have changes size by writing to the "size"
> >attribute.
> >mdadm doesn't have an option for doing that per-device - you need to
> >poke into sysfs.
> >
> >To make it a bit easier, when you use "--grow --size=foo", mdadm will
> >always write "foo" to the "size" attribute of each device, just incase
> >that will be helpful. In the case where the device is now bigger, it
> >will.
> >
> >In the case where the size of the array is being reduced, it is not
> >permitted to change the "size" of each device until the "component_size"
> >of the array has changed, so these attempts to change "size" will fail.
> >But that isn't a problem.
> >
> >In short, the attempt to change "size" here is a convenience, and
> >optimization. It doesn't matter if it fails.
> >
> >So please just revert all bits of the above commit that are still
> >present.
>
> Hi Neil,
>
> Thanks for the explanation, I'll take the big hammer to the
> leftovers and get rid of them.
>
> Jes
Hi,
The commit 758b327cf5a ("Grow: Remove unnecessary optimization") breaks grow
operation for external metadata.
mdadm --create /dev/md/imsm0 --metadata=imsm --raid-devices=4 /dev/nvme[0-3]n1 --run
mdadm --create /dev/md/r5 --level=5 --chunk 64 --size=1G --raid-devices=3 /dev/nvme[0-2]n1 --run --assume-clean
MDADM_EXPERIMENTAL=1 mdadm --grow /dev/md/r5 --size=2G
mdadm: Cannot set device size for /dev/md/r5: No space left on device
From update_size in MD driver:
if (avail < num_sectors)
-ENOSPC;
In the above case 'avail' is set to old value (1GiB) and new size requested
('num_sectors') is 2GiB.
Shall we revert the recent change then?
Regards,
Tomek
^ permalink raw reply
* Re: A sector-of-mismatch warning patch (was Re: Fault tolerance with badblocks)
From: Nix @ 2017-06-02 12:28 UTC (permalink / raw)
To: Shaohua Li
Cc: NeilBrown, Chris Murphy, David Brown, Anthony Youngman,
Phil Turmel, Ravi (Tom) Hale, Linux-RAID
In-Reply-To: <20170519164800.v76xyx3h4x3rydqz@kernel.org>
[getting back to this...]
On 19 May 2017, Shaohua Li told this:
> On Fri, May 19, 2017 at 11:31:23AM +0100, Nix wrote:
>> On 19 May 2017, NeilBrown verbalised:
>> > we'd probably make the list of inconsistencies appear in a
>> > sysfs file. That would be less 'crappy'. But as I say, I don't think
>> > we really want to do that.
>>
>> Aren't sysfs files in effect length-limited to one page (or at least
>> length-limited by virtue of being stored in memory?) It seems to me this
>> would just bring the same problem ratelimit is solving right back again,
>> except a sysfs file doesn't have a logging daemon sucking the contents
>> out constantly so you can overwrite your old output without worrying.
>> (And there is no other daemon running to do that, except mdadm in
>> monitor mode, which might not be running and really this job feels out
>> of scope for it anyway.)
>
> No, my question is not the print is ratelimited. The problem is dmesg isn't a
> good way to communicate info to userspace. You can easily lose all dmesg info
> with a simple 'dmesg -c'. sysfs file is more reliable. Length-limited isn't a
> problem, as you said, if there are a lot of mismatch, the array is toast.
I agree that in future having a mechanism for reporting this more easily
usable by programs would be good, and sysfs does seem like just such a
mechanism.
--
NULL && (void)
^ permalink raw reply
* [GIT PULL] MD update for 4.12-rc4
From: Shaohua Li @ 2017-06-02 16:19 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, linux-raid
Hi,
Several patches for MD. One notable is making flush bios sync, others fix small
issues. Please pull!
Thanks,
Shaohua
The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:
Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shli/md.git tags/md/4.12-rc4
for you to fetch changes up to 5a8948f8a32ba56c17b3fb75d318ac98157f3ba5:
md: Make flush bios explicitely sync (2017-05-31 09:25:53 -0700)
----------------------------------------------------------------
Guoqing Jiang (1):
md-cluster: fix potential lock issue in add_new_disk
Jan Kara (1):
md: Make flush bios explicitely sync
Kyungchan Koh (1):
md: uuid debug statement now in processor byte order.
Nix (1):
md: report sector of stripes with check mismatches
drivers/md/bitmap.c | 8 ++++----
drivers/md/md-cluster.c | 4 +++-
drivers/md/md.c | 2 +-
drivers/md/raid5-cache.c | 4 ++--
drivers/md/raid5-ppl.c | 4 ++--
drivers/md/raid5.c | 18 ++++++++++++++----
6 files changed, 26 insertions(+), 14 deletions(-)
^ permalink raw reply
* Re: [PATCH] md: simplify code with bio_io_error
From: Shaohua Li @ 2017-06-02 16:29 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: linux-raid
In-Reply-To: <20170602074914.26842-1-gqjiang@suse.com>
On Fri, Jun 02, 2017 at 03:49:14PM +0800, Guoqing Jiang wrote:
> bio_io_error was introduced in the commit 4246a0b
> ("block: add a bi_error field to struct bio"), so
> use it to simplify code.
>
> Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
Applied, thanks! There are several other places which could use conversion, I added
too.
> ---
> drivers/md/raid1.c | 3 +--
> drivers/md/raid10.c | 3 +--
> drivers/md/raid5.c | 3 +--
> 3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index af5056d..c20eb78 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -802,8 +802,7 @@ static void flush_bio_list(struct r1conf *conf, struct bio *bio)
> bio->bi_next = NULL;
> bio->bi_bdev = rdev->bdev;
> if (test_bit(Faulty, &rdev->flags)) {
> - bio->bi_error = -EIO;
> - bio_endio(bio);
> + bio_io_error(bio);
> } else if (unlikely((bio_op(bio) == REQ_OP_DISCARD) &&
> !blk_queue_discard(bdev_get_queue(bio->bi_bdev))))
> /* Just ignore it */
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index 4343d7f..ceb9709 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -913,8 +913,7 @@ static void flush_pending_writes(struct r10conf *conf)
> bio->bi_next = NULL;
> bio->bi_bdev = rdev->bdev;
> if (test_bit(Faulty, &rdev->flags)) {
> - bio->bi_error = -EIO;
> - bio_endio(bio);
> + bio_io_error(bio);
> } else if (unlikely((bio_op(bio) == REQ_OP_DISCARD) &&
> !blk_queue_discard(bdev_get_queue(bio->bi_bdev))))
> /* Just ignore it */
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 7220646..57aa044 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -3429,8 +3429,7 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
> struct bio *nextbi =
> r5_next_bio(bi, sh->dev[i].sector);
>
> - bi->bi_error = -EIO;
> - bio_endio(bi);
> + bio_io_error(bi);
> bi = nextbi;
> }
> }
> --
> 2.10.0
>
> --
> 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: Grow set size issue
From: Jes Sorensen @ 2017-06-02 17:48 UTC (permalink / raw)
To: Tomasz Majchrzak; +Cc: NeilBrown, linux-raid
In-Reply-To: <20170602110110.GA29246@proton.igk.intel.com>
On 06/02/2017 07:01 AM, Tomasz Majchrzak wrote:
> On Thu, Mar 30, 2017 at 10:10:32AM -0400, Jes Sorensen wrote:
>> On 03/29/2017 05:34 PM, NeilBrown wrote:
>>> On Thu, Mar 30 2017, jes.sorensen@gmail.com wrote:
>>>
>>>> Hi Neil,
>>>>
>>>> In the below patch you changed the error handling, to make the kernel
>>>> not setting the size of the device being an error. However we still have
>>>> the code in place to handle the error, except it never triggers.
>>>
>>> So we do. I should have removed all of that.
>>> I should have just reverted
>>> Commit: 65a9798b58b4 ("FIX: Detect error and rollback metadata")
>>>
>>>
>>>>
>>>> Question is do you remember the reason for this change? Old kernels not
>>>> allowing it, are there any legitimate reasons for the kernel to refuse
>>>> the size change?
>>>
>>> I needed to go further back to remind myself why we do these size change
>>> at all.
>>> The command being run here is "mdadm --grow /dev/mdX --size=foo"
>>> which has a primary purpose of changing the component_size of the array.
>>> What can happen is that someone makes all the components bigger
>>> (E.g. with LVM) and then uses this command to set --size=max, and it
>>> doesn't work. That is because md doesn't know the devices are bigger.
>>>
>>> You can tell md that devices have changes size by writing to the "size"
>>> attribute.
>>> mdadm doesn't have an option for doing that per-device - you need to
>>> poke into sysfs.
>>>
>>> To make it a bit easier, when you use "--grow --size=foo", mdadm will
>>> always write "foo" to the "size" attribute of each device, just incase
>>> that will be helpful. In the case where the device is now bigger, it
>>> will.
>>>
>>> In the case where the size of the array is being reduced, it is not
>>> permitted to change the "size" of each device until the "component_size"
>>> of the array has changed, so these attempts to change "size" will fail.
>>> But that isn't a problem.
>>>
>>> In short, the attempt to change "size" here is a convenience, and
>>> optimization. It doesn't matter if it fails.
>>>
>>> So please just revert all bits of the above commit that are still
>>> present.
>>
>> Hi Neil,
>>
>> Thanks for the explanation, I'll take the big hammer to the
>> leftovers and get rid of them.
>>
>> Jes
>
> Hi,
>
> The commit 758b327cf5a ("Grow: Remove unnecessary optimization") breaks grow
> operation for external metadata.
>
> mdadm --create /dev/md/imsm0 --metadata=imsm --raid-devices=4 /dev/nvme[0-3]n1 --run
> mdadm --create /dev/md/r5 --level=5 --chunk 64 --size=1G --raid-devices=3 /dev/nvme[0-2]n1 --run --assume-clean
>
> MDADM_EXPERIMENTAL=1 mdadm --grow /dev/md/r5 --size=2G
> mdadm: Cannot set device size for /dev/md/r5: No space left on device
>
> From update_size in MD driver:
>
> if (avail < num_sectors)
> -ENOSPC;
>
> In the above case 'avail' is set to old value (1GiB) and new size requested
> ('num_sectors') is 2GiB.
>
> Shall we revert the recent change then?
Rather than just reverting, track down whats wrong and fix it.
Jes
^ 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