* Re: [PATCH 1/1] super1: Always round data offset to 1M
From: Jes Sorensen @ 2017-07-27 9:32 UTC (permalink / raw)
To: Pawel Baldysiak; +Cc: linux-raid
In-Reply-To: <20170726144154.31798-1-pawel.baldysiak@intel.com>
On 07/26/2017 10:41 AM, Pawel Baldysiak wrote:
> Currently if metadata requires more then 1M,
> data offset will be rounded down to closest MB.
> This is not correct, since less then required space is reserved.
> Always round data offset up to multiple of 1M.
>
> Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
> ---
> super1.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Applied
Thanks,
Jes
^ permalink raw reply
* Re: [PATCH] Monitor: containers don't have the same sysfs properties as arrays
From: Jes Sorensen @ 2017-07-27 9:48 UTC (permalink / raw)
To: Mariusz Tkaczyk, linux-raid
In-Reply-To: <1500639337-12816-1-git-send-email-mariusz.tkaczyk@intel.com>
On 07/21/2017 08:15 AM, Mariusz Tkaczyk wrote:
> GET_MISMATCH option doesn't exist for containers so sysfs_read fails if
> this information is requested. Set options according to the device using
> information from /proc/mdstat.
>
> Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>
> Reviewed-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
> ---
> Monitor.c | 50 ++++++++++++++++++++++++++++----------------------
> 1 file changed, 28 insertions(+), 22 deletions(-)
Hi Mariusz,
Sorry for the late response, I am currently traveling so there have been
some delays.
I am fine with the principle of this patch, but I have a few nits:
> diff --git a/Monitor.c b/Monitor.c
> index 48c451c..8d753ca 100644
> --- a/Monitor.c
> +++ b/Monitor.c
> @@ -459,22 +459,41 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
> mdu_array_info_t array;
> struct mdstat_ent *mse = NULL, *mse2;
> char *dev = st->devname;
> - int fd;
> + int fd = -1;
> int i;
> int remaining_disks;
> int last_disk;
> int new_array = 0;
> - int retval;
> + int retval = 0;
> + int is_container;
> + unsigned long array_only_flags = 0;
You initialize array_only_flags here.
[snip]
> @@ -482,11 +501,11 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
> if (md_get_array_info(fd, &array) < 0)
> goto disappeared;
>
> - if (st->devnm[0] == 0)
> - strcpy(st->devnm, fd2devnm(fd));
> + array_only_flags |= !is_container ? GET_MISMATCH : 0;
> +
... and again here.
Could we try and avoid that obfuscated approach and simply do
if (!is_container)
array_only_flags |= GET_MISMATCH
That would avoid the double initialization and is a lot more readable.
Second issue, you are moving to global initialization for a number of
variables. That is pretty much always bad as it hides things - please
avoid that unless absolutely necessary.
Thanks,
Jes
^ permalink raw reply
* [PATCH v2] Monitor: containers don't have the same sysfs properties as arrays
From: Mariusz Tkaczyk @ 2017-07-27 13:22 UTC (permalink / raw)
To: linux-raid; +Cc: jes.sorensen, Mariusz Tkaczyk
GET_MISMATCH option doesn't exist for containers so sysfs_read fails if
this information is requested. Set options according to the device using
information from /proc/mdstat.
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>
---
Monitor.c | 45 +++++++++++++++++++++++++++------------------
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/Monitor.c b/Monitor.c
index 48c451c..de470bd 100644
--- a/Monitor.c
+++ b/Monitor.c
@@ -465,6 +465,8 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
int last_disk;
int new_array = 0;
int retval;
+ int is_container;
+ unsigned long array_only_flags = 0;
if (test)
alert("TestMessage", dev, NULL, ainfo);
@@ -475,6 +477,25 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
if (fd < 0)
goto disappeared;
+ if (st->devnm[0] == 0)
+ strcpy(st->devnm, fd2devnm(fd));
+
+ for (mse2 = mdstat; mse2; mse2 = mse2->next)
+ if (strcmp(mse2->devnm, st->devnm) == 0) {
+ mse2->devnm[0] = 0; /* flag it as "used" */
+ mse = mse2;
+ }
+
+ if (!mse) {
+ /* duplicated array in statelist
+ * or re-created after reading mdstat
+ */
+ st->err++;
+ goto out;
+ }
+
+ is_container = mse->level == NULL;
+
if (!md_array_active(fd))
goto disappeared;
@@ -482,11 +503,12 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
if (md_get_array_info(fd, &array) < 0)
goto disappeared;
- if (st->devnm[0] == 0)
- strcpy(st->devnm, fd2devnm(fd));
+ if (!is_container)
+ array_only_flags |= GET_MISMATCH;
+
+ sra = sysfs_read(-1, st->devnm, GET_LEVEL | GET_DISKS | GET_DEVS |
+ GET_STATE | array_only_flags);
- sra = sysfs_read(-1, st->devnm, GET_LEVEL | GET_DISKS | GET_MISMATCH |
- GET_DEVS | GET_STATE);
if (!sra)
goto disappeared;
@@ -500,19 +522,6 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
goto out;
}
- for (mse2 = mdstat; mse2; mse2 = mse2->next)
- if (strcmp(mse2->devnm, st->devnm) == 0) {
- mse2->devnm[0] = 0; /* flag it as "used" */
- mse = mse2;
- }
-
- if (!mse) {
- /* duplicated array in statelist
- * or re-created after reading mdstat*/
- st->err++;
- close(fd);
- goto out;
- }
/* this array is in /proc/mdstat */
if (array.utime == 0)
/* external arrays don't update utime, so
@@ -653,7 +662,7 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
out:
if (sra)
sysfs_free(sra);
- if (fd > 0)
+ if (fd >= 0)
close(fd);
return retval;
--
1.8.3.1
^ permalink raw reply related
* raid0: device does not exist with examine and scan
From: Nigel Croxon @ 2017-07-27 16:11 UTC (permalink / raw)
To: linux-raid
Hello all,
The device name referenced in the mdadm --examine --scan does not exist
when using metadata=1.2 and --name on the creation.
I am using metadata 0.9 as a bases to test against 1.2.
Am I fighting a udev rule? Did the symlink from /dev/md/TEST_MD to
/dev/md0 disappear?
If I start with METADATA=0.9 and specifying a --name
# mdadm --create --verbose /dev/md0 --level=0 --metadata=0.9
--raid-devices=2 --name=TEST_MD /dev/sdd /dev/sde
with METADATA=0.9, there is no NAME field printed on DETAIL
# mdadm -D /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Thu Jul 27 10:36:02 2017
Raid Level : raid0
Array Size : 293045760 (279.47 GiB 300.08 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Jul 27 10:36:02 2017
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Chunk Size : 512K
Consistency Policy : none
UUID : 623d8bac:8819491b:e9034e5d:acd14f01
Events : 0.1
Number Major Minor RaidDevice State
0 8 48 0 active sync /dev/sdd
1 8 64 1 active sync /dev/sde
The --examine --scan shows /dev/md0, and not /dev/md/TEST_MD.
# mdadm --examine --scan
ARRAY /dev/md0 UUID=65cb66eb:d8a0d9ff:85609b40:89383835
Next, change the METADATA=1.2 and specifying a --name
# mdadm --create --verbose /dev/md0 --level=0 --metadata=1.2
--raid-devices=2 --name=TEST_MD /dev/sdd /dev/sde
With METADATA=1.2, there is a NAME field printed:
thinkstation:TEST_MD (local to host thinkstation)
# mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Thu Jul 27 11:13:02 2017
Raid Level : raid0
Array Size : 292784128 (279.22 GiB 299.81 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Thu Jul 27 11:13:02 2017
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Chunk Size : 512K
Consistency Policy : none
Name : thinkstation:TEST_MD (local to host thinkstation)
UUID : 591d68eb:5182a6e2:ead93be0:812f7fc6
Events : 0
Number Major Minor RaidDevice State
0 8 48 0 active sync /dev/sdd
1 8 64 1 active sync /dev/sde
The --examine --scan is shows /dev/md/TEST_MD and not /dev/md0.
# mdadm --examine --scan
ARRAY /dev/md/TEST_MD metadata=1.2
UUID=413a8ca9:a1edb21b:9eb8876d:784349ed name=thinkstation:TEST_MD
This problem is, /dev/md/TEST_MD does not exist. /dev/md0 does.
mdadm --version
mdadm - v4.0-158-gcb91230 - 2017-07-10
Am I fighting udev rules?
Regards,
-Nigel
^ permalink raw reply
* Re: raid0: device does not exist with examine and scan
From: Wols Lists @ 2017-07-27 17:07 UTC (permalink / raw)
To: Nigel Croxon, linux-raid
In-Reply-To: <1f4ad2b8-70f4-12e1-16e9-40550a05fd96@redhat.com>
On 27/07/17 17:11, Nigel Croxon wrote:
>
> Hello all,
>
> The device name referenced in the mdadm --examine --scan does not exist
> when using metadata=1.2 and --name on the creation.
> I am using metadata 0.9 as a bases to test against 1.2.
> Am I fighting a udev rule? Did the symlink from /dev/md/TEST_MD to
> /dev/md0 disappear?
>
>
> If I start with METADATA=0.9 and specifying a --name
>
> # mdadm --create --verbose /dev/md0 --level=0 --metadata=0.9
> --raid-devices=2 --name=TEST_MD /dev/sdd /dev/sde
>
> with METADATA=0.9, there is no NAME field printed on DETAIL
I don't think 0.9 metadata supports names ...
>
> # mdadm -D /dev/md0
> /dev/md0:
> Version : 0.90
> Creation Time : Thu Jul 27 10:36:02 2017
> Raid Level : raid0
> Array Size : 293045760 (279.47 GiB 300.08 GB)
> Raid Devices : 2
> Total Devices : 2
> Preferred Minor : 0
> Persistence : Superblock is persistent
>
> Update Time : Thu Jul 27 10:36:02 2017
> State : clean
> Active Devices : 2
> Working Devices : 2
> Failed Devices : 0
> Spare Devices : 0
>
> Chunk Size : 512K
>
> Consistency Policy : none
>
> UUID : 623d8bac:8819491b:e9034e5d:acd14f01
> Events : 0.1
>
> Number Major Minor RaidDevice State
> 0 8 48 0 active sync /dev/sdd
> 1 8 64 1 active sync /dev/sde
>
>
> The --examine --scan shows /dev/md0, and not /dev/md/TEST_MD.
> # mdadm --examine --scan
> ARRAY /dev/md0 UUID=65cb66eb:d8a0d9ff:85609b40:89383835
>
>
> Next, change the METADATA=1.2 and specifying a --name
> # mdadm --create --verbose /dev/md0 --level=0 --metadata=1.2
> --raid-devices=2 --name=TEST_MD /dev/sdd /dev/sde
>
> With METADATA=1.2, there is a NAME field printed:
> thinkstation:TEST_MD (local to host thinkstation)
>
> # mdadm -D /dev/md0
> /dev/md0:
> Version : 1.2
> Creation Time : Thu Jul 27 11:13:02 2017
> Raid Level : raid0
> Array Size : 292784128 (279.22 GiB 299.81 GB)
> Raid Devices : 2
> Total Devices : 2
> Persistence : Superblock is persistent
>
> Update Time : Thu Jul 27 11:13:02 2017
> State : clean
> Active Devices : 2
> Working Devices : 2
> Failed Devices : 0
> Spare Devices : 0
>
> Chunk Size : 512K
>
> Consistency Policy : none
>
> Name : thinkstation:TEST_MD (local to host thinkstation)
> UUID : 591d68eb:5182a6e2:ead93be0:812f7fc6
> Events : 0
>
> Number Major Minor RaidDevice State
> 0 8 48 0 active sync /dev/sdd
> 1 8 64 1 active sync /dev/sde
>
> The --examine --scan is shows /dev/md/TEST_MD and not /dev/md0.
>
> # mdadm --examine --scan
> ARRAY /dev/md/TEST_MD metadata=1.2
> UUID=413a8ca9:a1edb21b:9eb8876d:784349ed name=thinkstation:TEST_MD
>
> This problem is, /dev/md/TEST_MD does not exist. /dev/md0 does.
Is the array running? This is an educated guess on my part, but I think
it's running the array that creates the symlink.
>
> mdadm --version
> mdadm - v4.0-158-gcb91230 - 2017-07-10
>
> Am I fighting udev rules?
>
Cheers,
Wol
^ permalink raw reply
* Re: raid0: device does not exist with examine and scan
From: Nigel Croxon @ 2017-07-27 17:17 UTC (permalink / raw)
To: Wols Lists, linux-raid
In-Reply-To: <597A1DD2.50906@youngman.org.uk>
On 07/27/2017 01:07 PM, Wols Lists wrote:
> On 27/07/17 17:11, Nigel Croxon wrote:
>>
>> Hello all,
>>
>> The device name referenced in the mdadm --examine --scan does not exist
>> when using metadata=1.2 and --name on the creation.
>> I am using metadata 0.9 as a bases to test against 1.2.
>> Am I fighting a udev rule? Did the symlink from /dev/md/TEST_MD to
>> /dev/md0 disappear?
>>
>>
>> If I start with METADATA=0.9 and specifying a --name
>>
>> # mdadm --create --verbose /dev/md0 --level=0 --metadata=0.9
>> --raid-devices=2 --name=TEST_MD /dev/sdd /dev/sde
>>
>> with METADATA=0.9, there is no NAME field printed on DETAIL
>
> I don't think 0.9 metadata supports names ...
>>
>> # mdadm -D /dev/md0
>> /dev/md0:
>> Version : 0.90
>> Creation Time : Thu Jul 27 10:36:02 2017
>> Raid Level : raid0
>> Array Size : 293045760 (279.47 GiB 300.08 GB)
>> Raid Devices : 2
>> Total Devices : 2
>> Preferred Minor : 0
>> Persistence : Superblock is persistent
>>
>> Update Time : Thu Jul 27 10:36:02 2017
>> State : clean
>> Active Devices : 2
>> Working Devices : 2
>> Failed Devices : 0
>> Spare Devices : 0
>>
>> Chunk Size : 512K
>>
>> Consistency Policy : none
>>
>> UUID : 623d8bac:8819491b:e9034e5d:acd14f01
>> Events : 0.1
>>
>> Number Major Minor RaidDevice State
>> 0 8 48 0 active sync /dev/sdd
>> 1 8 64 1 active sync /dev/sde
>>
>>
>> The --examine --scan shows /dev/md0, and not /dev/md/TEST_MD.
>> # mdadm --examine --scan
>> ARRAY /dev/md0 UUID=65cb66eb:d8a0d9ff:85609b40:89383835
>>
>>
>> Next, change the METADATA=1.2 and specifying a --name
>> # mdadm --create --verbose /dev/md0 --level=0 --metadata=1.2
>> --raid-devices=2 --name=TEST_MD /dev/sdd /dev/sde
>>
>> With METADATA=1.2, there is a NAME field printed:
>> thinkstation:TEST_MD (local to host thinkstation)
>>
>> # mdadm -D /dev/md0
>> /dev/md0:
>> Version : 1.2
>> Creation Time : Thu Jul 27 11:13:02 2017
>> Raid Level : raid0
>> Array Size : 292784128 (279.22 GiB 299.81 GB)
>> Raid Devices : 2
>> Total Devices : 2
>> Persistence : Superblock is persistent
>>
>> Update Time : Thu Jul 27 11:13:02 2017
>> State : clean
>> Active Devices : 2
>> Working Devices : 2
>> Failed Devices : 0
>> Spare Devices : 0
>>
>> Chunk Size : 512K
>>
>> Consistency Policy : none
>>
>> Name : thinkstation:TEST_MD (local to host thinkstation)
>> UUID : 591d68eb:5182a6e2:ead93be0:812f7fc6
>> Events : 0
>>
>> Number Major Minor RaidDevice State
>> 0 8 48 0 active sync /dev/sdd
>> 1 8 64 1 active sync /dev/sde
>>
>> The --examine --scan is shows /dev/md/TEST_MD and not /dev/md0.
>>
>> # mdadm --examine --scan
>> ARRAY /dev/md/TEST_MD metadata=1.2
>> UUID=413a8ca9:a1edb21b:9eb8876d:784349ed name=thinkstation:TEST_MD
>>
>> This problem is, /dev/md/TEST_MD does not exist. /dev/md0 does.
>
> Is the array running? This is an educated guess on my part, but I think
> it's running the array that creates the symlink.
>>
# mdadm --create --verbose /dev/md0 --level=0 --metadata=1.2
--raid-devices=2 --name=TEST_MD /dev/sdd /dev/sde
mdadm: chunk size defaults to 512K
mdadm: array /dev/md0 started.
# cat /proc/mdstat
Personalities : [raid0]
md0 : active raid0 sde[1] sdd[0]
292784128 blocks super 1.2 512k chunks
unused devices: <none>
# mdadm --examine --scan
ARRAY /dev/md/TEST_MD metadata=1.2
UUID=fff9f89d:62dcc596:665386ca:d19f2487 name=thinkstation:TEST_MD
# ls /dev/md/
ls: cannot access /dev/md/: No such file or directory
>> mdadm --version
>> mdadm - v4.0-158-gcb91230 - 2017-07-10
>>
>> Am I fighting udev rules?
>>
> Cheers,
> Wol
>
>
^ permalink raw reply
* [PATCH 1/2] md/r5cache: fix r5c_journal_mode_store
From: Song Liu @ 2017-07-27 23:35 UTC (permalink / raw)
To: linux-raid
Cc: shli, neilb, kernel-team, dan.j.williams, hch, jes.sorensen,
Song Liu
In r5c_journal_mode_store(), conf->log may change (and become NULL)
after mddev_suspend(). This patch check conf->log again after
mddev_suspend() to mitigate this risk.
Signed-off-by: Song Liu <songliubraving@fb.com>
---
drivers/md/raid5-cache.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index bfa1e90..315cabf 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -2541,9 +2541,8 @@ static ssize_t r5c_journal_mode_show(struct mddev *mddev, char *page)
int r5c_journal_mode_set(struct mddev *mddev, int mode)
{
struct r5conf *conf = mddev->private;
- struct r5l_log *log = conf->log;
- if (!log)
+ if (!conf->log)
return -ENODEV;
if (mode < R5C_JOURNAL_MODE_WRITE_THROUGH ||
@@ -2555,6 +2554,10 @@ int r5c_journal_mode_set(struct mddev *mddev, int mode)
return -EINVAL;
mddev_suspend(mddev);
+ if (!conf || !conf->log) {
+ mddev_resume(mddev);
+ return -ENODEV;
+ }
conf->log->r5c_journal_mode = mode;
mddev_resume(mddev);
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] md/r5cache: fix io_unit handling in r5l_log_endio()
From: Song Liu @ 2017-07-27 23:35 UTC (permalink / raw)
To: linux-raid
Cc: shli, neilb, kernel-team, dan.j.williams, hch, jes.sorensen,
Song Liu
In-Reply-To: <20170727233556.3802574-1-songliubraving@fb.com>
In r5l_log_endio(), the io_unit should only be modified with lock
io_list_lock held.
Also, r5l_log_endio() should not call __r5l_stripe_write_finished()
directly. It should be just set io_state to IO_UNIT_STRIPE_END and
__r5l_stripe_write_finished() will be called later.
Signed-off-by: Song Liu <songliubraving@fb.com>
---
drivers/md/raid5-cache.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 315cabf..d4e08a2 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -580,6 +580,20 @@ static void r5l_log_endio(struct bio *bio)
spin_lock_irqsave(&log->io_list_lock, flags);
__r5l_set_io_unit_state(io, IO_UNIT_IO_END);
+
+ if (io->has_null_flush) {
+ struct bio *bi;
+
+ WARN_ON(bio_list_empty(&io->flush_barriers));
+ while ((bi = bio_list_pop(&io->flush_barriers)) != NULL) {
+ bio_endio(bi);
+ atomic_dec(&io->pending_stripe);
+ }
+ }
+ /* finish flush only io_unit and PAYLOAD_FLUSH only io_unit */
+ if (atomic_read(&io->pending_stripe) == 0)
+ __r5l_set_io_unit_state(io, IO_UNIT_STRIPE_END);
+
if (log->need_cache_flush && !list_empty(&io->stripe_list))
r5l_move_to_end_ios(log);
else
@@ -599,20 +613,6 @@ static void r5l_log_endio(struct bio *bio)
if (log->need_cache_flush)
md_wakeup_thread(log->rdev->mddev->thread);
-
- if (io->has_null_flush) {
- struct bio *bi;
-
- WARN_ON(bio_list_empty(&io->flush_barriers));
- while ((bi = bio_list_pop(&io->flush_barriers)) != NULL) {
- bio_endio(bi);
- atomic_dec(&io->pending_stripe);
- }
- }
-
- /* finish flush only io_unit and PAYLOAD_FLUSH only io_unit */
- if (atomic_read(&io->pending_stripe) == 0)
- __r5l_stripe_write_finished(io);
}
static void r5l_do_submit_io(struct r5l_log *log, struct r5l_io_unit *io)
--
2.9.3
^ permalink raw reply related
* [PATCH v2] md: notify about new spare disk in the container
From: Artur Paszkiewicz @ 2017-07-28 13:49 UTC (permalink / raw)
To: shli; +Cc: linux-raid
In-Reply-To: <20170721202446.lpy7noq6bbn7g7qt@kernel.org>
From: "Alexey Obitotskiy" <aleksey.obitotskiy@intel.com>
In case of external metadata arrays spare disks are added to containers
first. mdadm keeps monitoring /proc/mdstat output and when spare disk is
available, it moves it from the container to the array. The problem is
there is no notification of new spare disk in the container and mdadm
waits a long time (until timeout) before it takes the action.
Signed-off-by: Alexey Obitotskiy <aleksey.obitotskiy@intel.com>
---
drivers/md/md.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 8cdca0296749..594ebbaf4171 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -4283,6 +4283,8 @@ new_dev_store(struct mddev *mddev, const char *buf, size_t len)
if (err)
export_rdev(rdev);
mddev_unlock(mddev);
+ if (!err)
+ md_new_event(mddev);
return err ? err : len;
}
--
2.13.1
^ permalink raw reply related
* Re: raid0: device does not exist with examine and scan
From: Nigel Croxon @ 2017-07-28 13:50 UTC (permalink / raw)
To: Wols Lists, linux-raid
In-Reply-To: <983cdf1c-abab-d20f-f71f-9f7441f4f3ce@redhat.com>
On 07/27/2017 01:17 PM, Nigel Croxon wrote:
> On 07/27/2017 01:07 PM, Wols Lists wrote:
>> On 27/07/17 17:11, Nigel Croxon wrote:
>>>
>>> Hello all,
>>>
>>> The device name referenced in the mdadm --examine --scan does not exist
>>> when using metadata=1.2 and --name on the creation.
>>> I am using metadata 0.9 as a bases to test against 1.2.
>>> Am I fighting a udev rule? Did the symlink from /dev/md/TEST_MD to
>>> /dev/md0 disappear?
>>>
>>>
>>> If I start with METADATA=0.9 and specifying a --name
>>>
>>> # mdadm --create --verbose /dev/md0 --level=0 --metadata=0.9
>>> --raid-devices=2 --name=TEST_MD /dev/sdd /dev/sde
>>>
>>> with METADATA=0.9, there is no NAME field printed on DETAIL
>>
>> I don't think 0.9 metadata supports names ...
>>>
>>> # mdadm -D /dev/md0
>>> /dev/md0:
>>> Version : 0.90
>>> Creation Time : Thu Jul 27 10:36:02 2017
>>> Raid Level : raid0
>>> Array Size : 293045760 (279.47 GiB 300.08 GB)
>>> Raid Devices : 2
>>> Total Devices : 2
>>> Preferred Minor : 0
>>> Persistence : Superblock is persistent
>>>
>>> Update Time : Thu Jul 27 10:36:02 2017
>>> State : clean
>>> Active Devices : 2
>>> Working Devices : 2
>>> Failed Devices : 0
>>> Spare Devices : 0
>>>
>>> Chunk Size : 512K
>>>
>>> Consistency Policy : none
>>>
>>> UUID : 623d8bac:8819491b:e9034e5d:acd14f01
>>> Events : 0.1
>>>
>>> Number Major Minor RaidDevice State
>>> 0 8 48 0 active sync /dev/sdd
>>> 1 8 64 1 active sync /dev/sde
>>>
>>>
>>> The --examine --scan shows /dev/md0, and not /dev/md/TEST_MD.
>>> # mdadm --examine --scan
>>> ARRAY /dev/md0 UUID=65cb66eb:d8a0d9ff:85609b40:89383835
>>>
>>>
>>> Next, change the METADATA=1.2 and specifying a --name
>>> # mdadm --create --verbose /dev/md0 --level=0 --metadata=1.2
>>> --raid-devices=2 --name=TEST_MD /dev/sdd /dev/sde
>>>
>>> With METADATA=1.2, there is a NAME field printed:
>>> thinkstation:TEST_MD (local to host thinkstation)
>>>
>>> # mdadm -D /dev/md0
>>> /dev/md0:
>>> Version : 1.2
>>> Creation Time : Thu Jul 27 11:13:02 2017
>>> Raid Level : raid0
>>> Array Size : 292784128 (279.22 GiB 299.81 GB)
>>> Raid Devices : 2
>>> Total Devices : 2
>>> Persistence : Superblock is persistent
>>>
>>> Update Time : Thu Jul 27 11:13:02 2017
>>> State : clean
>>> Active Devices : 2
>>> Working Devices : 2
>>> Failed Devices : 0
>>> Spare Devices : 0
>>>
>>> Chunk Size : 512K
>>>
>>> Consistency Policy : none
>>>
>>> Name : thinkstation:TEST_MD (local to host thinkstation)
>>> UUID : 591d68eb:5182a6e2:ead93be0:812f7fc6
>>> Events : 0
>>>
>>> Number Major Minor RaidDevice State
>>> 0 8 48 0 active sync /dev/sdd
>>> 1 8 64 1 active sync /dev/sde
>>>
>>> The --examine --scan is shows /dev/md/TEST_MD and not /dev/md0.
>>>
>>> # mdadm --examine --scan
>>> ARRAY /dev/md/TEST_MD metadata=1.2
>>> UUID=413a8ca9:a1edb21b:9eb8876d:784349ed name=thinkstation:TEST_MD
>>>
>>> This problem is, /dev/md/TEST_MD does not exist. /dev/md0 does.
>>
>> Is the array running? This is an educated guess on my part, but I think
>> it's running the array that creates the symlink.
>>>
>
> # mdadm --create --verbose /dev/md0 --level=0 --metadata=1.2
> --raid-devices=2 --name=TEST_MD /dev/sdd /dev/sde
> mdadm: chunk size defaults to 512K
> mdadm: array /dev/md0 started.
>
> # cat /proc/mdstat
> Personalities : [raid0]
> md0 : active raid0 sde[1] sdd[0]
> 292784128 blocks super 1.2 512k chunks
>
> unused devices: <none>
>
> # mdadm --examine --scan
> ARRAY /dev/md/TEST_MD metadata=1.2
> UUID=fff9f89d:62dcc596:665386ca:d19f2487 name=thinkstation:TEST_MD
>
> # ls /dev/md/
> ls: cannot access /dev/md/: No such file or directory
>
>
>>> mdadm --version
>>> mdadm - v4.0-158-gcb91230 - 2017-07-10
>>>
>>> Am I fighting udev rules?
>>>
>> Cheers,
>> Wol
>>
>>
Looks like I'm all set.
1) Reboot - and the symlink will be there.
or
2) stop the device and reassemble with -I
This is how the udev rules do it.
-Nigel
^ permalink raw reply
* [GIT PULL] MD update for 4.13-rc3
From: Shaohua Li @ 2017-07-28 15:05 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, linux-raid
Hi,
This update fixes several bugs, 3 of them are suitable for stable:
- An initialization issue fixed by Ming
- A bio clone race issue fixed by me
- An async tx flush issue fixed by Ofer
- Other cleanups
Thanks,
Shaohua
The following changes since commit 4ec9f7a18b9fcef6e8f7c13279b48e3bb5d4d704:
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2017-07-21 11:20:58 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shli/md.git for-next
for you to fetch changes up to ed9b66d21866ae3bf16557406258ebe6c00a9a84:
MD: fix warnning for UP case (2017-07-25 15:18:13 -0700)
----------------------------------------------------------------
Guoqing Jiang (1):
md: simplify code with bio_io_error
Ming Lei (3):
md: remove 'idx' from 'struct resync_pages'
md: raid1/raid10: initialize bvec table via bio_add_page()
md: raid1-10: move raid1/raid10 common code into raid1-10.c
Ofer Heifetz (1):
md/raid5: add thread_group worker async_tx_issue_pending_all
Shaohua Li (2):
md/raid1: fix writebehind bio clone
MD: fix warnning for UP case
drivers/md/md.c | 2 +-
drivers/md/md.h | 54 ----------------------------------
drivers/md/raid1-10.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/md/raid1.c | 68 +++++++++++++-----------------------------
drivers/md/raid10.c | 25 +++++-----------
drivers/md/raid5.c | 11 ++++---
6 files changed, 115 insertions(+), 126 deletions(-)
create mode 100644 drivers/md/raid1-10.c
^ permalink raw reply
* Re: [PATCH v2] md: notify about new spare disk in the container
From: Shaohua Li @ 2017-07-28 17:00 UTC (permalink / raw)
To: Artur Paszkiewicz; +Cc: linux-raid
In-Reply-To: <20170728134925.11088-1-artur.paszkiewicz@intel.com>
On Fri, Jul 28, 2017 at 03:49:25PM +0200, Artur Paszkiewicz wrote:
> From: "Alexey Obitotskiy" <aleksey.obitotskiy@intel.com>
>
> In case of external metadata arrays spare disks are added to containers
> first. mdadm keeps monitoring /proc/mdstat output and when spare disk is
> available, it moves it from the container to the array. The problem is
> there is no notification of new spare disk in the container and mdadm
> waits a long time (until timeout) before it takes the action.
>
> Signed-off-by: Alexey Obitotskiy <aleksey.obitotskiy@intel.com>
applied, thanks
> ---
> drivers/md/md.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 8cdca0296749..594ebbaf4171 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -4283,6 +4283,8 @@ new_dev_store(struct mddev *mddev, const char *buf, size_t len)
> if (err)
> export_rdev(rdev);
> mddev_unlock(mddev);
> + if (!err)
> + md_new_event(mddev);
> return err ? err : len;
> }
>
> --
> 2.13.1
>
^ permalink raw reply
* 2657849082，诚邀参加中国最大汽配外贸展 —— APF 2017 ◆ 与“广交会”同期同地举行 [上U2/L50-Z]
From: Unknown @ 2017-07-29 5:20 UTC (permalink / raw)
2657849082 尊敬的 企业领导/公司负责人：
诚邀参加中国最大汽配外贸展 —— APF 2017
汽配行业品牌盛会，外贸企业最佳选择，全球采购首选平台！
★ 与“广交会”同期同地举行，
★ 以“广交会”庞大的客流量为依托，买家互动，借势兴展，
★ 共享来自全球数十万采购商资源•••
【 基 本 信 息 】
中文名称： 2017广州国际进出口汽车配件展览会
英文名称： The Guangzhou International Import and Export Auto Parts Fair 2017 （APF 2017）
展会日期： 2017年10月13—15日
展会场馆： 广州琶洲国际采购中心
批准单位： 中华人民共和国商务部
主办单位： 中国对外贸易经济合作企业协会、映德国际会展有限公司
官方网站： http://www.CAPE-china.com
在线客服： 邮箱/QQ：qq@12809395.com； 微信：ZhanShangZhiJia； 微博：http://weibo.com/yingdehuizhan
咨询电话： 4000-580-850（转5206或8144）； 131-2662-5206； 010―8699-7155、 8084-2128；
【 展 会 介 绍 】
中国目前的汽车保有量已达1.95亿多辆，预计到2020年，中国汽车保有量将超过2.5亿辆。预计2016年中国汽车年产销量将超过3000万辆，到2020年中国汽车产销量将分别超过4500万辆，从而成为名副其实的全球第一大汽车市场。汽车配件是汽车工业发展的基础，汽车配件配套及售后服务市场是汽车市场的重要组成部分，中国汽车工业的迅猛发展，为汽车配件行业提供了坚实的产业基础和有力的市场支撑，并将形成1.5-2万亿元超大规模的市场产值。
作为汽车市场的焦点，广州拥有国内最大的汽车生产基地和汽车产业集群，连续三年汽车消费增速全国前列。2017年是“十三五”规划实施的重要一年，是供给侧结构性改革的深化之年，中国汽车工业已步入由大到强的发展之路，行业资源分配日益优化、产业布局日趋合理的态势已初现端倪，产业发展正逐步由产销量的提升演变为质量的飞跃。尤其在夯实产业根基、促使健康发展原则指导下，汽车配件产业，已被提升为汽车产业链条中首要的发展对象，资源倾斜、政策扶持、整顿规范，可以预计，继我国整车生产及消费在过去十年取得蓬勃发展成就之后，未来五到十年，将是我国汽车配件行业产生根本性变革的黄金时期。
得益于中国汽车产业高速发展和全球汽车零部件产业链积极向中国转移，映德会展、中汽展览联合行业权威机构定于2017年10月13-15日在广州琶洲国际采购中心举办“2017广州国际进出口汽车配件展览会”（APF 2017）。依托汽车产业和全球最大的潜在市场资源，根据汽车配件产业发展现状和中外市场需求，在继承和延伸往届展会成功经验的基础上，在各级政府部门、行业协会的关心与支持下、经过主承办单位的精心组织策划，“APF 2017”将以全新的面貌再现广州，展会将全面展示汽车领域的最新产品与成果及未来发展方向，将有超过百家合作媒体的超大阵容作全方位的立体宣传。APF 全国统一参展报名热线：4000-580-850（转5206、8144）。
我们将继续以“突出品牌、开拓创新、注重实效、强化服务”的办展宗旨，凭借独特的创意，科学的组织管理和卓越的服务，以全新的理念为广大中外参展商提供一个“专业化、国际化、品牌化”的展示交流平台，为全球汽车配件及后市场行业提供更多的合作机会，有力推动中国汽车配件产品全面进入全球采购体系，与世界各国汽车产业协调合作、互利共赢、共同发展进步。
【 展 会 优 势 】
● 绝佳商机 —— APF 2017举办时间正值“广交会”期间，享有“中国第一展”美誉的“广交会”，每年参加的采购商大约20多万，来自一百多个国家和地区。我们将通过一系列途径充分借助“广交会”全球买家的巨大资源，并通过组委会客户关系邀请系统向国内外三十多万采购商发出邀请，与“广交会”完全互动，借势兴展，同时弥补“广交会”内销的不足，形成“一内一外、相辅相成”的作用。以“广交会”庞大的客流量为依托，中外采购商云集，市场潜力不可估量，巨大商机全面彰显，是开拓国际市场的重要平台！
● 黄金地段 —— 广州琶洲国际采购中心与广交会展馆一路之隔，连为一体，形成完美对接，连接广交会同类产品展区，距离地铁八号线琶洲站A出口仅200米之遥，交通非常便利，方便海外客商前来参观、采购。
● 参展回报 —— 与每个国内外采购决策者面对面交流，和意向客户达成交易，在专业客户中扩大品牌影响力；建立海外分销网络，拓展国际市场；新产品、新技术推广；开拓新市场；了解竞争对手及行业发展趋势；洞悉国际最新技术与资讯；约见老客户并发展新业务。
【 目 标 观 众 】
中国（广州）国际汽车零部件及用品展览会组委会（映德会展―YOND EXPO）将专业观众组织和媒体宣传作为工作重点，邀请中外汽车制造商、改装厂、改装行、改装店，汽车工业设备制造商、汽车零配件用品制造商、贸易商、代理商、经销商、终端用户，汽车配件用品市场、超市、连锁加盟店、4S店，汽车保养及美容中心、汽车维修中心、汽车修理厂，汽车综合性能检测站、汽车后市场经销商，汽车后市场连锁经营领域专家、学者、投资公司及国内外有志于汽车后市场投资创业人士、汽车服务行业、汽车爱好者、车友会、俱乐部、商务机构、汽车维修检测行业相关部门、汽车交通运输部门、政府主管部门、汽车行业协会、专业媒体等主要单位及负责人参会。采取卓有实效的措施为参展企业搭建交流与合作的平台，促进科技成果转化，提高企业市场竞争力；同时通过系列紧密有序的宣传活动，确保展会在国内外引起最大关注。
16万国内外专业买家云集羊城 ——
一、 国内专业买家
1、300家整车厂和汽车销售公司
- 本田（广州，东风），丰田（一汽，广汽），大众（一汽，上海），北京现代，上海通用，东风日产，长安福特，比亚迪，奇瑞等35家主流整车企业和60家汽车销售公司，汽车用品公司的采购负责人现场参观采购。
2、8000家4S店集团及全国4S店
- 新疆广汇，冀东庞大，上海永达，浙江物产元通，广物汽贸，东创建国，大连中升，湖南申湘，深圳深业，中汽西南，安徽亚夏，郑州豫华等300家4S店集团和中国各品牌4000家4S店采购负责人参展采购。
3、1500家全国一级批发物流商
- 欧特隆（辽宁，杭州，南京，山西），沈阳新天成，郑州二仟家，山西茂德隆，长沙湘泸，福建永联，成都穗丰，广州永丰，新疆半分利，北京派安，石家庄中惠等1200家一级批发物流参展采购。
4、7000家全国各地市代理经销商
5、2500家全国优质影音改装专业店
- 以新城子昂，上海车之宝，北京双周，音乐前线，先歌兄弟， 非常城市等为代表的全国各区域优质影音改装店参展采购。
6、300家大型零售终端连锁
- 以新奇特，黄帽子，上海美车饰等为代表的全国各区域优质零售终端及大型连锁参展采购。。
7、90000家国内终端零售店（含南方/泛珠三角地区终端店30000家）
- 以金手指，车元素等为代表的福建，江西，湖南，广东，广西，海南，四川，贵州，云南，香港，澳门等泛珠三角地区零售终端现场采购。以及2万家全国优秀零售终端。
二、 国外专业买家
1、4000亚洲买家：
- 包括日本、韩国、印度尼西亚、马来西亚、印度、泰国、菲律宾、越南、新加坡等国行业商会组团采购参观。
2、1500中东买家：
- 包括阿联酋、沙特阿拉伯、伊朗、叙利亚、以色列、科威特、卡塔尔、也门等国采购商组团参观采购。
3、2500欧美买家：
- 包括德国、英国、法国、美国、墨西哥、加拿大等国采购商采购参观。
【 展 品 范 围 】
汽车零部件、零配件，发动机系统、底盘系统、制动系统、行驶系统、转向系统、车身系统、传动系统、排气系统、散热冷却系统、燃油系统，汽车附件、通用件、紧固件、密封件、摩擦材料，汽车电机、轴承、蓄电池、滤清器、散热器、消声器、传感器、仪器仪表、雨刷器、变速器、离合器、离合片、刹车片、汽车弹簧、减震器、保险杠、安全气囊、座椅、玻璃、车镜、车灯、汽车空调、轮胎、轮毂、链条、防滑链，汽车线束、插接器、硬管、软管、软轴、拉索，车用纺织品，汽车油漆、润滑油、机油、添加剂，汽车用品，汽车电子电器，汽车音影、音响、导航、车载通讯、安全和防盗系统，汽车改装部件及用品，汽保设备及工具，汽车模具，汽车零部件制造技术、设备、工具及材料，汽车零部件清洗设备及包装，汽车新产品，汽车节能环保与新能源技术及产品，相关软件、媒体、认证、金融和保险机构等。
【 参 展 细 则 】
◆ 展位规格：
1、特装展位：36平方米起租，仅提供相应面积室内外空地。展台搭建、展览器具、用电用水等自理。
2、标准展位：9平方米（3m×3m）每个，2.5m高壁板、一条楣板（展商名称）、一张洽谈桌、两把椅子、两盏射灯、220V/5A电源插座一处。
◆ 展位费用：
特装展位：境内企业RMB2000/平方米； 境外企业USD500/平方米；
标准展位：境内企业RMB20000/个； 境外企业USD5000/个； （双面开口标准展位另加收10%费用）
◆ 会刊广告： （大会《会刊》将帮助您在展会后找到客户！除在展会期间广为发送外，还通过各种有关渠道发送给未能前来参观展会的各地专业人士手中，他们可利用会刊迅速查找服务内容与联络方法。 会刊尺寸：130mm*210mm，进口铜板纸彩色精印，发行量10万册。）
封面 CNY 30000； 封二封三 CNY 22000； 扉页 CNY 18000； 黑白页 CNY 5000；
封底 CNY 20000； 彩页跨版 CNY 18000； 彩页 CNY 12000； 300字简介 CNY 2000；
◆ 会议论坛：
如技术交流会/产品推广发布会，CNY9000/小时/场，用于会场及相关设备租金（包括场地、扩音设施、灯具、投影机、投影仪，桌椅、空调、茶水并协助主讲企业组织听众）。
【 参 展 程 序 】
1、大会即日起开始接受厂商报名，组委会（映德会展―YOND EXPO）严格按“款到先后顺序优先安排展位”，先期报名参展企业除“在统一参展费用的基础上获得较靠前展台位置”的同时，并可享受更多“展前宣传”和“买家推介”等增值服务。
2、参展单位请详细填写《参展申请表》（备索）并加盖公章，传真或复印后寄送至大会组织办公室（映德会展―YOND EXPO），并于三个工作日内向大会指定账户汇出参展费用。
3、参展单位请于报名时将300字内企业简介同时提供至大会组织办公室，以便进行及时展前宣传和刊登《会刊》等。
4、展品运输、仓储、吊装，展商报道、接待、食宿等后勤服务，详见会前《参展商手册》，约在大会开幕前一个半月发送。
5、需用动力电、气或用水、特装展台装修等事宜，请于大会开幕前一月将有关资料提供给大会组委会，以便会务组协助参展企业做好相应安排。
6、组委会拒绝与参展范围不符的厂商参展。报名截止日期：2017年08月31日。
【 筹 展 联 络 】
广州国际进出口汽车配件展组委会
官方网站： http://www.CAPE-china.com
全国统一客服热线： 4000-580-850.（分机：8144、5206或5220）
全国统一报名专线： 4000-680-860.（兼传真）
参展顾问： 李先生、 王先生、 段小姐、 梁小姐
参展热线： 131-2662-5206、 139-1031-8144； 010— 8699- 7155、 8084- 2128.
在线客服： QQ/邮箱：12809395#qq.com； 微信/ ZhanShangZhiJia； 微博/ http://weibo.com/yondexpo
〔 映德会展 / 诚邀参加2017年度权威实效品牌盛会﹞
【 公众平台 】
微信： 参展消息 （ID：CanZhanXiaoXi）—— 品牌扩张的平台 市场开拓的桥梁
微信： 展商之家 （ID：ZhanShangZhiJia）—— 为展商提供最佳营地 为阁下营造参展价值
-----------------------------------------------------------------------------------------------------------
百万群发系统|为您发送|如不希望再收到此行业资讯|请回复“退订+APF”至邮箱1055800812@qq.com
^ permalink raw reply
* [PATCH] md: replace seq_release_private with seq_release
From: Cihangir Akturk @ 2017-07-29 16:52 UTC (permalink / raw)
To: shli; +Cc: linux-raid, linux-kernel, Cihangir Akturk
Since commit f15146380d28 ("fs: seq_file - add event counter to simplify
poll() support"), md.c code has been no longer used the private field of
the struct seq_file, but seq_release_private() has been continued to be
used to release the allocated seq_file. This seems to have been
forgotten. So convert it to use seq_release() instead of
seq_release_private().
Signed-off-by: Cihangir Akturk <cakturk@gmail.com>
---
drivers/md/md.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 8cdca029..6174360 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -7836,7 +7836,7 @@ static const struct file_operations md_seq_fops = {
.open = md_seq_open,
.read = seq_read,
.llseek = seq_lseek,
- .release = seq_release_private,
+ .release = seq_release,
.poll = mdstat_poll,
};
--
2.7.4
^ permalink raw reply related
* RecovData Handshk error
From: Alex @ 2017-07-30 1:54 UTC (permalink / raw)
To: Linux RAID
Hi,
I have a fedora25 system with a MegaRAID SAS 9260-8i. I believe
there's 8 500GB SSDs connected. It appears one (or more?) may be
having a problem. I'm now noticing this message periodically in the
kernel logs:
[Wed Jun 28 01:40:06 2017] ata1.00: exception Emask 0x0 SAct 0x0 SErr
0x400001 action 0x6 frozen
[Wed Jun 28 01:40:06 2017] ata1: SError: { RecovData Handshk }
[Wed Jun 28 01:40:06 2017] ata1.00: cmd
a0/00:00:00:08:00/00:00:00:00:00/a0 tag 29 pio 16392 in
Get event status notification 4a
01 00 00 10 00 00 00 08 00res 40/00:00:00:00:00/00:00:00:00:00/00
Emask 0x4 (timeout)
[Wed Jun 28 01:40:06 2017] ata1.00: status: { DRDY }
[Wed Jun 28 01:40:06 2017] ata1: hard resetting link
[Wed Jun 28 01:40:06 2017] ata1: SATA link up 1.5 Gbps (SStatus 113
SControl 300)
[Wed Jun 28 01:40:06 2017] ata1.00: configured for UDMA/133
[Wed Jun 28 01:40:06 2017] ata1: EH complete
Is it something to be concerned with? What level of panic? :-)
It appears to recover normally? Is it a device or disk issue? How can
I identify which disk is involved?
This is the information on the control from lspci:
05:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS
2108 [Liberator] (rev 05)
Subsystem: LSI Logic / Symbios Logic MegaRAID SAS 9260-8i
Flags: bus master, fast devsel, latency 0, IRQ 29, NUMA node 0
I/O ports at 7000 [size=256]
Memory at df960000 (64-bit, non-prefetchable) [size=16K]
Memory at df900000 (64-bit, non-prefetchable) [size=256K]
Expansion ROM at df940000 [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [68] Express Endpoint, MSI 00
Capabilities: [d0] Vital Product Data
Capabilities: [a8] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [c0] MSI-X: Enable+ Count=15 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [138] Power Budgeting <?>
Kernel driver in use: megaraid_sas
Kernel modules: megaraid_sas
Thanks for any ideas.
^ permalink raw reply
* How to add journal device to existing RAID5?
From: Vasco Steinmetz @ 2017-07-30 15:19 UTC (permalink / raw)
To: linux-raid
Hi,
I bought a 32GB Intel Optane NVMe and would like to add it to an
existing RAID5 array as the journal device.
My hope was that with the latest Loonix kernel 4.12.4 and mdadm 4.0
adding a log device to an already existing array should work.
It didn't. :(
Though I marked the R5 array as RO, mdadm complained that adding a
journal to that particular array is not possible because it didn't have
had a journal device in teh past.
Unfortunately it is not possible for me to recreate the array, as that
would imply to move all data to backup, delete and recreate the array
and afterwards move it back.
When is it planned for mdadm/md-raid?.c to add/remove journal devices on
the fly (assuming they array may not be currently in use, e.g. --readonly)?
Kind regards,
Vasco
^ permalink raw reply
* Re: How to add journal device to existing RAID5?
From: Larkin Lowrey @ 2017-07-30 17:05 UTC (permalink / raw)
To: Vasco Steinmetz, linux-raid
In-Reply-To: <ec6b9beb-b239-9ab9-03ac-7351e152d1af@kyberraum.net>
The patch to allow the adding of a journal to an existing array was
applied in March. See:
http://marc.info/?l=linux-raid&m=149072503301987
The most recent mdadm release, v4.0, was in January so it does not
include that patch.
All the patch does is remove the restriction in mdadm so it may be
possible to patch the v4.0 source and build locally to test.
I too am very interested in this capability and would like to know when
the next mdadm release is expected.
--Larkin
On 7/30/2017 11:19 AM, Vasco Steinmetz wrote:
> Hi,
>
> I bought a 32GB Intel Optane NVMe and would like to add it to an
> existing RAID5 array as the journal device.
>
> My hope was that with the latest Loonix kernel 4.12.4 and mdadm 4.0
> adding a log device to an already existing array should work.
>
> It didn't. :(
>
> Though I marked the R5 array as RO, mdadm complained that adding a
> journal to that particular array is not possible because it didn't have
> had a journal device in teh past.
>
> Unfortunately it is not possible for me to recreate the array, as that
> would imply to move all data to backup, delete and recreate the array
> and afterwards move it back.
>
>
> When is it planned for mdadm/md-raid?.c to add/remove journal devices on
> the fly (assuming they array may not be currently in use, e.g. --readonly)?
>
>
> Kind regards,
> Vasco
> --
> 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
* remove mdadm stripe limitation, pls
From: Dima Dvorcovoy @ 2017-07-31 15:52 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <S1752524AbdGaPpr/20170731154547Z+299@vger.kernel.org>
I got in trouble trying to mount RAID0 drives from brocen HW
controller. The mdadm utility is locked to 4k stripe minimum, but these
drives have 1s (512bytes) stripes.
Then, I dig into kernel and found there are no actual stripe limitation
seems. So, all the limits are in mdadm code. I patched soure and all
works ok.
mdadm --build /dev/md0 --level=0 --chunk=1s --raid-devices=2 /dev/sdd
/dev/sdc
First: there are UNDOCUCMENTED option in --chunk, size could be given
in sectors (s).
Second: 1s used as INVALID_SECTORS constant. I changed it to 0xffff
Third: The sector number is stored in K. I removes this division, maybe
it is only for output.
Where to connect with mdadm team to ask for changes? What I skipped to
patch?
[mdadm.h]
1737c1737
< * a value for 'invalid'. Use '1'.
---
> * a value for 'invalid'. Use '-1'.
1739c1739
< #define INVALID_SECTORS 1
---
> #define INVALID_SECTORS 0xffff
[mdadm.c]
381,384c381,382
< if (s.chunk == INVALID_SECTORS ||
< s.chunk < 8 || (s.chunk&1)) {
< pr_err("invalid chunk/rounding value: %s\n",
< optarg);
---
> if (s.chunk == INVALID_SECTORS) {
> pr_err("invalid chunk/rounding value: %s\n",optarg);
[Build.c]
387,388d384
< /* Convert sectors to K */
< s.chunk /= 2;
145c145
< array.chunk_size = s->chunk*1024;
---
> array.chunk_size = s->chunk*512;
[Create.c]
696c696
< info.array.chunk_size = s->chunk*1024;
---
> info.array.chunk_size = s->chunk*512;
^ permalink raw reply
* Re: [PATCH] md: replace seq_release_private with seq_release
From: Shaohua Li @ 2017-07-31 16:49 UTC (permalink / raw)
To: Cihangir Akturk; +Cc: linux-raid, linux-kernel
In-Reply-To: <1501347165-32241-1-git-send-email-cakturk@gmail.com>
On Sat, Jul 29, 2017 at 07:52:45PM +0300, Cihangir Akturk wrote:
> Since commit f15146380d28 ("fs: seq_file - add event counter to simplify
> poll() support"), md.c code has been no longer used the private field of
> the struct seq_file, but seq_release_private() has been continued to be
> used to release the allocated seq_file. This seems to have been
> forgotten. So convert it to use seq_release() instead of
> seq_release_private().
>
> Signed-off-by: Cihangir Akturk <cakturk@gmail.com>
applied, thanks!
> ---
> drivers/md/md.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 8cdca029..6174360 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -7836,7 +7836,7 @@ static const struct file_operations md_seq_fops = {
> .open = md_seq_open,
> .read = seq_read,
> .llseek = seq_lseek,
> - .release = seq_release_private,
> + .release = seq_release,
> .poll = mdstat_poll,
> };
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: remove mdadm stripe limitation, pls
From: Shaohua Li @ 2017-07-31 17:00 UTC (permalink / raw)
To: Dima Dvorcovoy; +Cc: linux-raid, jes.sorensen
In-Reply-To: <1501516344.23767.4.camel@bsu.by>
On Mon, Jul 31, 2017 at 06:52:24PM +0300, Dima Dvorcovoy wrote:
> I got in trouble trying to mount RAID0 drives from brocen HW
> controller. The mdadm utility is locked to 4k stripe minimum, but these
> drives have 1s (512bytes) stripes.
>
> Then, I dig into kernel and found there are no actual stripe limitation
> seems. So, all the limits are in mdadm code. I patched soure and all
> works ok.
> mdadm --build /dev/md0 --level=0 --chunk=1s --raid-devices=2 /dev/sdd
> /dev/sdc
>
> First: there are UNDOCUCMENTED option in --chunk, size could be given
> in sectors (s).
>
> Second: 1s used as INVALID_SECTORS constant. I changed it to 0xffff
>
> Third: The sector number is stored in K. I removes this division, maybe
> it is only for output.
>
> Where to connect with mdadm team to ask for changes? What I skipped to
> patch?
Cc: Jes
If we really want to do this, please limit it to raid0 now. I think there is
problem with 512B chunksize for raid5, raid10 probably is ok.
Thanks,
Shaohua
> [mdadm.h]
> 1737c1737
> < * a value for 'invalid'. Use '1'.
> ---
> > * a value for 'invalid'. Use '-1'.
> 1739c1739
> < #define INVALID_SECTORS 1
> ---
> > #define INVALID_SECTORS 0xffff
> [mdadm.c]
> 381,384c381,382
> < if (s.chunk == INVALID_SECTORS ||
> < s.chunk < 8 || (s.chunk&1)) {
> < pr_err("invalid chunk/rounding value: %s\n",
> < optarg);
> ---
> > if (s.chunk == INVALID_SECTORS) {
> > pr_err("invalid chunk/rounding value: %s\n",optarg);
> [Build.c]
> 387,388d384
> < /* Convert sectors to K */
> < s.chunk /= 2;
> 145c145
> < array.chunk_size = s->chunk*1024;
> ---
> > array.chunk_size = s->chunk*512;
> [Create.c]
> 696c696
> < info.array.chunk_size = s->chunk*1024;
> ---
> > info.array.chunk_size = s->chunk*512;
> --
> 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
* raid1 lockups on 4.12.x
From: Simon Kirby @ 2017-07-31 18:36 UTC (permalink / raw)
To: linux-raid
Hello,
I recently upgraded two old boxes to 4.12.3 only to find that they
started to lock up several times per day. I upgraded to 4.12.4 and the
problem persisted. Downgrading to 4.11.11 seems to have stopped the
issue.
I captured the following with nmi_watchdog=1 and a serial console while
on 4.12.4.
[ 9672.236351] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [md2_raid1:1704]
[ 9672.236351] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack serio_raw evdev e1000
[ 9672.236351] CPU: 0 PID: 1704 Comm: md2_raid1 Not tainted 4.12.4-hw #6
[ 9672.236351] Hardware name: Dell Computer Corporation PowerEdge 750 /0R1479, BIOS A03 10/22/2004
[ 9672.236351] task: f4a1a100 task.stack: f47fa000
[ 9672.236351] EIP: md_check_recovery+0x2d4/0x460
[ 9672.236351] EFLAGS: 00000246 CPU: 0
[ 9672.236351] EAX: 00000000 EBX: f448ec00 ECX: 00000001 EDX: 00000000
[ 9672.236351] ESI: 00000000 EDI: 00000000 EBP: f47fbe38 ESP: f47fbe28
[ 9672.236351] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 9672.236351] CR0: 80050033 CR2: b77c0000 CR3: 31501000 CR4: 000006d0
[ 9672.236351] Call Trace:
[ 9672.236351] raid1d+0x27/0x16f0
[ 9672.236351] ? ktime_get+0x44/0x100
[ 9672.236351] ? lapic_next_event+0x13/0x20
[ 9672.236351] ? clockevents_program_event+0x9d/0x150
[ 9672.236351] ? __hrtimer_run_queues+0x13a/0x210
[ 9672.236351] ? hrtimer_interrupt+0xb0/0x190
[ 9672.236351] ? smp_apic_timer_interrupt+0x33/0x40
[ 9672.236351] ? apic_timer_interrupt+0x32/0x38
[ 9672.236351] ? perf_trace_thermal_power_cpu_limit+0x68/0x120
[ 9672.344374] md_thread+0x116/0x140
[ 9672.344374] ? do_wait_intr+0x70/0x70
[ 9672.344374] kthread+0xe3/0x110
[ 9672.344374] ? md_register_thread+0xc0/0xc0
[ 9672.344374] ? __kthread_init_worker+0x90/0x90
[ 9672.344374] ret_from_fork+0x19/0x24
[ 9672.344374] Code: 68 01 00 00 ef f0 0f ba b3 68 01 00 00 05 72 47 8b b3 08 01 00 00 85 f6 0f 85 d9 fe ff ff f0 80 a3 68 01 00 00 fe b9 01 00 00 00 <ba> 03 00 00 00 c7 04 24 00 00 00 00 b8 c0 a8 bc c1 e8 86 d9 97
later, there were (looping) backtraces such as:
[34552.236353] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [md0_raid1:1684]
[34552.236353] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack serio_raw evdev e1000
[34552.236353] CPU: 0 PID: 1684 Comm: md0_raid1 Tainted: G L 4.12.4-hw #6
[34552.236353] Hardware name: Dell Computer Corporation PowerEdge 750 /0R1479, BIOS A03 10/22/2004
[34552.236353] task: f4a95280 task.stack: f52c0000
[34552.236353] EIP: _raw_spin_unlock_irqrestore+0xa/0x10
[34552.236353] EFLAGS: 00000292 CPU: 0
[34552.236353] EAX: 00000292 EBX: f46a3d08 ECX: 00000001 EDX: 00000292
[34552.236353] ESI: 00000292 EDI: 00000003 EBP: f52c1de4 ESP: f52c1de4
[34552.236353] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[34552.236353] CR0: 80050033 CR2: 08062e00 CR3: 347af000 CR4: 000006d0
[34552.236353] Call Trace:
[34552.236353] __wake_up+0x40/0x50
[34552.236353] md_wakeup_thread+0x2b/0x30
[34552.236353] mddev_unlock+0x74/0xc0
[34552.236353] md_check_recovery+0x1c3/0x460
[34552.324380] raid1d+0x27/0x16f0
[34552.324380] ? ktime_get+0x44/0x100
[34552.324380] ? lapic_next_event+0x13/0x20
[34552.324380] ? clockevents_program_event+0x9d/0x150
[34552.324380] ? __hrtimer_run_queues+0x13a/0x210
[34552.344366] ? smp_apic_timer_interrupt+0x33/0x40
[34552.344366] ? apic_timer_interrupt+0x32/0x38
[34552.344366] ? perf_trace_thermal_power_cpu_limit+0xb/0x120
[34552.344366] md_thread+0x116/0x140
[34552.344366] ? do_wait_intr+0x70/0x70
[34552.344366] kthread+0xe3/0x110
[34552.344366] ? md_register_thread+0xc0/0xc0
[34552.344366] ? __kthread_init_worker+0x90/0x90
[34552.344366] ret_from_fork+0x19/0x24
[34552.344366] Code: 00 f0 0f b1 0a 85 c0 75 08 b0 01 5d c3 8d 74 26 00 31 c0 5d c3 8d b6 00 00 00 00 8d bf 00 00 00 00 55 89 e5 c6 00 00 89 d0 50 9d <8d> 74 26 00 5d c3 55 89 c1 89 e5 b8 00 ff ff ff f0 0f c1 01 89
[34567.020353] INFO: rcu_sched self-detected stall on CPU
[34567.020361] 0-...: (104347 ticks this GP) idle=d52/140000000000001/0 softirq=615378/615378 fqs=52025
[34567.020361] (t=105006 jiffies g=349461 c=349460 q=85)
[34567.020361] NMI backtrace for cpu 0
[34567.020361] CPU: 0 PID: 1684 Comm: md0_raid1 Tainted: G L 4.12.4-hw #6
[34567.020361] Hardware name: Dell Computer Corporation PowerEdge 750 /0R1479, BIOS A03 10/22/2004
[34567.020361] Call Trace:
[34567.020361] dump_stack+0x58/0x78
[34567.020361] nmi_cpu_backtrace+0xa6/0xb0
[34567.020361] nmi_trigger_cpumask_backtrace+0x92/0xd0
[34567.020361] ? irq_force_complete_move+0xd0/0xd0
[34567.020361] arch_trigger_cpumask_backtrace+0x10/0x20
[34567.020361] rcu_dump_cpu_stacks+0x64/0xa7
[34567.020361] rcu_check_callbacks+0x6af/0x710
[34567.020361] ? account_process_tick+0x54/0x130
[34567.020361] update_process_times+0x2a/0x60
[34567.020361] tick_sched_handle.isra.11+0x30/0x60
[34567.020361] tick_sched_timer+0x3b/0x80
[34567.020361] __hrtimer_run_queues+0xb0/0x210
[34567.020361] ? tick_nohz_handler+0xa0/0xa0
[34567.020361] hrtimer_interrupt+0x95/0x190
[34567.020361] local_apic_timer_interrupt+0x2a/0x50
[34567.020361] smp_apic_timer_interrupt+0x2e/0x40
[34567.020361] apic_timer_interrupt+0x32/0x38
[34567.020361] EIP: _raw_spin_unlock_irqrestore+0xa/0x10
[34567.020361] EFLAGS: 00000292 CPU: 0
[34567.020361] EAX: 00000292 EBX: f448e5f0 ECX: 00000001 EDX: 00000292
[34567.020361] ESI: 00000292 EDI: 00000003 EBP: f52c1e00 ESP: f52c1e00
[34567.020361] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[34567.020361] __wake_up+0x40/0x50
[34567.020361] md_check_recovery+0x1bc/0x460
[34567.020361] raid1d+0x27/0x16f0
[34567.020361] ? ktime_get+0x44/0x100
[34567.020361] ? lapic_next_event+0x13/0x20
[34567.020361] ? clockevents_program_event+0x9d/0x150
[34567.020361] ? __hrtimer_run_queues+0x13a/0x210
[34567.020361] ? hrtimer_interrupt+0xb0/0x190
[34567.020361] ? hrtimer_interrupt+0xb0/0x190
[34567.020361] ? smp_apic_timer_interrupt+0x33/0x40
[34567.020361] ? apic_timer_interrupt+0x32/0x38
[34567.020361] md_thread+0x116/0x140
[34567.020361] ? do_wait_intr+0x70/0x70
[34567.020361] kthread+0xe3/0x110
[34567.020361] ? md_register_thread+0xc0/0xc0
[34567.020361] ? __kthread_init_worker+0x90/0x90
[34567.020361] ret_from_fork+0x19/0x24
[34592.236352] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [md0_raid1:1684]
[34592.236352] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack serio_raw evdev e1000
[34592.236352] CPU: 0 PID: 1684 Comm: md0_raid1 Tainted: G L 4.12.4-hw #6
[34592.236352] Hardware name: Dell Computer Corporation PowerEdge 750 /0R1479, BIOS A03 10/22/2004
[34592.236352] task: f4a95280 task.stack: f52c0000
[34592.236352] EIP: _raw_spin_unlock_irqrestore+0xa/0x10
[34592.236352] EFLAGS: 00000292 CPU: 0
[34592.236352] EAX: 00000292 EBX: c1bca8c0 ECX: 00000001 EDX: 00000292
[34592.236352] ESI: 00000292 EDI: 00000003 EBP: f52c1e00 ESP: f52c1e00
[34592.236352] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[34592.236352] CR0: 80050033 CR2: 08062e00 CR3: 347af000 CR4: 000006d0
[34592.236352] Call Trace:
[34592.236352] __wake_up+0x40/0x50
[34592.236352] md_check_recovery+0x2ea/0x460
[34592.236352] raid1d+0x27/0x16f0
[34592.236352] ? ktime_get+0x44/0x100
[34592.236352] ? lapic_next_event+0x13/0x20
[34592.236352] ? clockevents_program_event+0x9d/0x150
[34592.236352] ? __hrtimer_run_queues+0x13a/0x210
[34592.236352] ? tick_program_event+0x41/0x80
[34592.236352] ? hrtimer_interrupt+0xb0/0x190
[34592.344366] ? irq_exit+0x58/0xb0
[34592.344366] ? smp_apic_timer_interrupt+0x33/0x40
[34592.344366] ? apic_timer_interrupt+0x32/0x38
[34592.356384] ? perf_trace_thermal_power_cpu_limit+0xb/0x120
[34592.356384] md_thread+0x116/0x140
[34592.356384] ? do_wait_intr+0x70/0x70
[34592.356384] kthread+0xe3/0x110
[34592.356384] ? md_register_thread+0xc0/0xc0
[34592.356384] ? __kthread_init_worker+0x90/0x90
[34592.356384] ret_from_fork+0x19/0x24
[34592.356384] Code: 00 f0 0f b1 0a 85 c0 75 08 b0 01 5d c3 8d 74 26 00 31 c0 5d c3 8d b6 00 00 00 00 8d bf 00 00 00 00 55 89 e5 c6 00 00 89 d0 50 9d <8d> 74 26 00 5d c3 55 89 c1 89 e5 b8 00 ff ff ff f0 0f c1 01 89
Config here: http://0x.ca/sim/ref/4.12.4-32/config
Simon-
^ permalink raw reply
* Re: Recovery after accidental raid5 superblock rewrite
From: Paul Tonelli @ 2017-07-31 19:57 UTC (permalink / raw)
To: Andreas Klauer; +Cc: linux-raid
In-Reply-To: <20170610204105.GA19409@metamorpher.de>
Hello (again)
Sorry to resuscitate this topic back from the dead, but I have again the
same issue.
TL;DR
The difference compared to last time:
- I created a clean raid a few days back
- the data is completely backed up and available
- I can actually access the data
but I still have no clue about what went wrong.
1) I created the raid:
sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3
/dev/sdb /dev/sdc /dev/sdd
without lvm this time, juste a single ext4 partition
mkfs.ext4 /dev/md0
mount /dev/md0 /srv/data
I copied 3Tb on it
I just rebooted the machine
2) and (again) no md0 assembled at boot:
mdadm -E /dev/sd[bcd]
/dev/sdb:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
/dev/sdc:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
/dev/sdd:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
This time, I am able to get my data back. I first create the overlays and:
mdadm --create --verbose /dev/md0 --assume-clean --level=5
--raid-devices=3 /dev/mapper/sdb /dev/mapper/sdc /dev/mapper/sdd
mount /dev/md0 /srv/data
# mdadm --detail --scan /dev/md0
ARRAY /dev/md0 metadata=1.2 name=smic:0
UUID=2ebab32e:82283ac5:4232d2ee:92abf170
and it mounts, so I did exactly the same using the real disks and
(again) got my data back. The raid is now running:
# mdadm -E /dev/sdb
/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 2ebab32e:82283ac5:4232d2ee:92abf170
Name : smic:0 (local to host smic)
Creation Time : Mon Jul 31 21:36:12 2017
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 5860270080 (5588.79 GiB 6000.92 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=944 sectors
State : clean
Device UUID : 2d1daf78:1e085799:6f1799b2:e88e60d1
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jul 31 21:36:19 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 63abce91 - correct
Events : 1
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAA ('A' == active, '.' == missing, 'R' == replacing)
# mdadm -E /dev/sdc
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 2ebab32e:82283ac5:4232d2ee:92abf170
Name : smic:0 (local to host smic)
Creation Time : Mon Jul 31 21:36:12 2017
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 5860270080 (5588.79 GiB 6000.92 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=944 sectors
State : clean
Device UUID : db6d0696:072c5166:1491157d:6ddf34cf
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jul 31 21:36:19 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 164e0d53 - correct
Events : 1
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AAA ('A' == active, '.' == missing, 'R' == replacing)
# mdadm -E /dev/sdd
/dev/sdd:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 2ebab32e:82283ac5:4232d2ee:92abf170
Name : smic:0 (local to host smic)
Creation Time : Mon Jul 31 21:36:12 2017
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 5860270080 (5588.79 GiB 6000.92 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=944 sectors
State : clean
Device UUID : 0c52bea6:a0cbf060:fe5edff0:4ee71d21
Internal Bitmap : 8 sectors from superblock
Update Time : Mon Jul 31 21:36:19 2017
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : e75866e8 - correct
Events : 1
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : AAA ('A' == active, '.' == missing, 'R' == replacing)
but a reboot always brings me back to step 2), with the need to press
ctrl-D at boot time.
What am I missing? Am I using a bad version of the mdadm or kernel
(mdadm:amd64 3.3.2-5+deb8u2, kernel 4.8.0-0.bpo.2-amd64) or am I doing
it wrong in another way ?
best regards,
On 06/10/2017 10:41 PM, Andreas Klauer wrote:
> On Sat, Jun 10, 2017 at 10:04:16PM +0200, Paul Tonelli wrote:
>> I believe the offset we manually specify is after the default one on a
>> raid assembly with 3 disks, so it should have rebuilt the previous LVM
>> superblock, or am I missing something (again).
> It should be the reverse. When you grow the raid, the offset shrinks.
>
> Not able to provide further insights. You have a LVM2 header which,
> given the correct offset, should appear on the /dev/md device and
> in that case everything else should appear too.
>
> If that is not the case then things will be a lot more complicated.
>
> Regards
> Andreas Klauer
^ permalink raw reply
* Re: Recovery after accidental raid5 superblock rewrite
From: Wols Lists @ 2017-07-31 20:35 UTC (permalink / raw)
To: Paul Tonelli, Andreas Klauer; +Cc: linux-raid
In-Reply-To: <e0c059b0-2d68-92bf-3eb9-e2827602061c@tonel.li>
On 31/07/17 20:57, Paul Tonelli wrote:
> but a reboot always brings me back to step 2), with the need to press
> ctrl-D at boot time.
>
> What am I missing? Am I using a bad version of the mdadm or kernel
> (mdadm:amd64 3.3.2-5+deb8u2, kernel 4.8.0-0.bpo.2-amd64) or am I doing
> it wrong in another way ?
Okay. Step 2. Does an "mdadm --assemble --scan" work instead? This will
tell us whether your raid array is fine, just that it's not being
properly assembled at boot. Actually, before you do that, try a "mdadm
/dev/md0 --stop".
If the stop then assemble scan works, it tells us that your boot
sequence is at fault, not the array.
Can you post the relevant section of grub.cfg? That might not be
assembling the arrays.
Cheers,
Wol
^ permalink raw reply
* [PATCH v2 1/2] md/r5cache: call mddev_lock/unlock() in r5c_journal_mode_set
From: Song Liu @ 2017-07-31 21:52 UTC (permalink / raw)
To: linux-raid
Cc: shli, neilb, kernel-team, dan.j.williams, hch, jes.sorensen,
Song Liu
In r5c_journal_mode_set(), it is necessary to call mddev_lock()
before accessing conf and conf->log. Otherwise, the conf->log
may change (and become NULL).
Signed-off-by: Song Liu <songliubraving@fb.com>
---
drivers/md/raid5-cache.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index bfa1e90..98b5aa9 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -2540,16 +2540,20 @@ static ssize_t r5c_journal_mode_show(struct mddev *mddev, char *page)
*/
int r5c_journal_mode_set(struct mddev *mddev, int mode)
{
- struct r5conf *conf = mddev->private;
- struct r5l_log *log = conf->log;
-
- if (!log)
- return -ENODEV;
+ struct r5conf *conf;
+ int err;
if (mode < R5C_JOURNAL_MODE_WRITE_THROUGH ||
mode > R5C_JOURNAL_MODE_WRITE_BACK)
return -EINVAL;
+ err = mddev_lock(mddev);
+ if (err)
+ return err;
+ conf = mddev->private;
+ if (!conf || !conf->log)
+ return -ENODEV;
+
if (raid5_calc_degraded(conf) > 0 &&
mode == R5C_JOURNAL_MODE_WRITE_BACK)
return -EINVAL;
@@ -2557,6 +2561,7 @@ int r5c_journal_mode_set(struct mddev *mddev, int mode)
mddev_suspend(mddev);
conf->log->r5c_journal_mode = mode;
mddev_resume(mddev);
+ mddev_unlock(mddev);
pr_debug("md/raid:%s: setting r5c cache mode to %d: %s\n",
mdname(mddev), mode, r5c_journal_mode_str[mode]);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/2] md/r5cache: fix io_unit handling in r5l_log_endio()
From: Song Liu @ 2017-07-31 21:52 UTC (permalink / raw)
To: linux-raid
Cc: shli, neilb, kernel-team, dan.j.williams, hch, jes.sorensen,
Song Liu
In-Reply-To: <20170731215227.2409587-1-songliubraving@fb.com>
In r5l_log_endio(), once log->io_list_lock is released, the io unit
may be accessed (or even freed) by other threads. Current code
doesn't handle the io_unit properly, which leads to potential race
conditions.
This patch solves this race condition by:
1. Add a pending_stripe count flush_payload. Note that multiple
flush_payloads are counted as only one pending_stripe. Flag
has_flush_payload is added to show whether the io unit has
flush_payload;
2. In r5l_log_endio(), check flags has_null_flush and
has_flush_payload with log->io_list_lock held. After the lock
is released, this IO unit is only accessed when we know the
pending_stripe counter cannot be zeroed by other threas.
Signed-off-by: Song Liu <songliubraving@fb.com>
---
drivers/md/raid5-cache.c | 33 ++++++++++++++++++++++++++++-----
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 98b5aa9..76c236c 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -239,6 +239,7 @@ struct r5l_io_unit {
unsigned int has_flush:1; /* include flush request */
unsigned int has_fua:1; /* include fua request */
unsigned int has_null_flush:1; /* include empty flush request */
+ unsigned int has_flush_payload:1; /* include flush payload */
/*
* io isn't sent yet, flush/fua request can only be submitted till it's
* the first IO in running_ios list
@@ -571,6 +572,8 @@ static void r5l_log_endio(struct bio *bio)
struct r5l_io_unit *io_deferred;
struct r5l_log *log = io->log;
unsigned long flags;
+ bool has_null_flush;
+ bool has_flush_payload;
if (bio->bi_status)
md_error(log->rdev->mddev, log->rdev);
@@ -580,6 +583,19 @@ static void r5l_log_endio(struct bio *bio)
spin_lock_irqsave(&log->io_list_lock, flags);
__r5l_set_io_unit_state(io, IO_UNIT_IO_END);
+
+ /*
+ * if the io doesn't not have null_flush or flush payload,
+ * it is not safe to access it after releasing io_list_lock.
+ * Therefore, it is necessary to check the condition with
+ * the lock held.
+ */
+ has_null_flush = io->has_null_flush;
+ has_flush_payload = io->has_flush_payload;
+ /* finish flush only io_unit and PAYLOAD_FLUSH only io_unit */
+ if (atomic_read(&io->pending_stripe) == 0)
+ __r5l_set_io_unit_state(io, IO_UNIT_STRIPE_END);
+
if (log->need_cache_flush && !list_empty(&io->stripe_list))
r5l_move_to_end_ios(log);
else
@@ -600,18 +616,20 @@ static void r5l_log_endio(struct bio *bio)
if (log->need_cache_flush)
md_wakeup_thread(log->rdev->mddev->thread);
- if (io->has_null_flush) {
+ if (has_null_flush) {
struct bio *bi;
WARN_ON(bio_list_empty(&io->flush_barriers));
while ((bi = bio_list_pop(&io->flush_barriers)) != NULL) {
bio_endio(bi);
- atomic_dec(&io->pending_stripe);
+ if (atomic_dec_and_test(&io->pending_stripe)) {
+ __r5l_stripe_write_finished(io);
+ return;
}
}
-
- /* finish flush only io_unit and PAYLOAD_FLUSH only io_unit */
- if (atomic_read(&io->pending_stripe) == 0)
+ }
+ if (has_flush_payload)
+ if (atomic_dec_and_test(&io->pending_stripe))
__r5l_stripe_write_finished(io);
}
@@ -881,6 +899,11 @@ static void r5l_append_flush_payload(struct r5l_log *log, sector_t sect)
payload->size = cpu_to_le32(sizeof(__le64));
payload->flush_stripes[0] = cpu_to_le64(sect);
io->meta_offset += meta_size;
+ /* multiple flush payloads count as one pending_stripe */
+ if (!io->has_flush_payload) {
+ io->has_flush_payload = 1;
+ atomic_inc(&io->pending_stripe);
+ }
mutex_unlock(&log->io_mutex);
}
--
2.9.3
^ permalink raw reply related
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