* [PATCH V2] md: simplify code with bio_io_error
From: Guoqing Jiang @ 2017-07-21 8:33 UTC (permalink / raw)
To: shli; +Cc: linux-raid, Guoqing Jiang
Since bio_io_error sets bi_status to BLK_STS_IOERR,
and calls bio_endio, so we can use it directly.
And as mentioned by Shaohua, there are also two
places in raid5.c can use bio_io_error either.
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
V2:
No changes, just rebased on latest kernel tree.
drivers/md/raid1.c | 3 +--
drivers/md/raid10.c | 6 ++----
drivers/md/raid5.c | 9 +++------
3 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 1d235cc..f50958d 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -790,8 +790,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_status = BLK_STS_IOERR;
- 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 e2617d0..f55d4cc 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -905,8 +905,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_status = BLK_STS_IOERR;
- 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 */
@@ -1090,8 +1089,7 @@ static void raid10_unplug(struct blk_plug_cb *cb, bool from_schedule)
bio->bi_next = NULL;
bio->bi_bdev = rdev->bdev;
if (test_bit(Faulty, &rdev->flags)) {
- bio->bi_status = BLK_STS_IOERR;
- 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 aeeb8d6..4904dff 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3381,9 +3381,8 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
sh->dev[i].sector + STRIPE_SECTORS) {
struct bio *nextbi = r5_next_bio(bi, sh->dev[i].sector);
- bi->bi_status = BLK_STS_IOERR;
md_write_end(conf->mddev);
- bio_endio(bi);
+ bio_io_error(bi);
bi = nextbi;
}
if (bitmap_end)
@@ -3403,9 +3402,8 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
sh->dev[i].sector + STRIPE_SECTORS) {
struct bio *bi2 = r5_next_bio(bi, sh->dev[i].sector);
- bi->bi_status = BLK_STS_IOERR;
md_write_end(conf->mddev);
- bio_endio(bi);
+ bio_io_error(bi);
bi = bi2;
}
@@ -3429,8 +3427,7 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
struct bio *nextbi =
r5_next_bio(bi, sh->dev[i].sector);
- bi->bi_status = BLK_STS_IOERR;
- bio_endio(bi);
+ bio_io_error(bi);
bi = nextbi;
}
}
--
2.10.0
^ permalink raw reply related
* Re: Linear device of two arrays
From: Veljko @ 2017-07-21 9:15 UTC (permalink / raw)
To: NeilBrown, linux-raid
In-Reply-To: <87d18uydir.fsf@notabene.neil.brown.name>
On 07/21/2017 12:00 AM, NeilBrown wrote:
> On Mon, Jul 17 2017, Veljko wrote:
>
>> On 07/15/2017 02:12 AM, NeilBrown wrote:
>>
>>> So command should be
>>>
>>>>> dd if=/dev/md2 of=SOMEWHERE/SAFE bs=1M skip=5626590
>>>
>>> and expect it to create a 3M file.
>>>
>>> Use this 'skip' number of the 'seek' number later.
>>>
>>> NeilBrown
>>
>> Thanks, Neil, now it makes more sense.
>>
>> I tried to create new linear device, but mdadm is complaining about
>> data-offset:
>>
>> # mdadm -C /dev/md4 -l linear -n 2 --rounding=1M -e 1.0 --data-offset=0
>> /dev/md2 /dev/md3
>> mdadm: invalid data-offset: 0
>
> Bother.
> mdadm uses "parse_size()" to parse the offset, and this rejects
> "0", which makes sense for a size, but not for an offset.
>
> Just leave the "--data-offset=0" out. I checked and that is defintely
> the default for 1.0.
>
>> I noticed that md2 and md3 use 1.2 metadata. Can that be the issue?
>
> No the metadata on md4 is quite independent of the metadata on md2 and md3.
>
> NeilBrown
Yes, now it works. I was able to create new linear device, restored the
saved 3M file and grown xfs. It was really fast and indeed, I'm happy.
Thank you very much, Neil!
Regards,
Veljko
^ permalink raw reply
* Re: Advice please re failed Raid6
From: Peter Grandi @ 2017-07-21 9:48 UTC (permalink / raw)
To: Linux RAID
In-Reply-To: <ea81b594-9da1-4efb-2c6d-3bf50cf9e3e9@gmail.com>
>> Tried different order: sde, sdc, sdd and blkid worked.
It is not clear what "blkid worked" means here. It should have
reported an 'ext4' filesystem.
>> Added sdb as you suggested.
I actually wrote: "try a different order or 3-way subset of
'sd[bcde]'." Perhaps "3-way subset" was not clear. Only when the
right subset in the right order were found adding a fourth
member was worth it.
Also it matter enormously whether "Added sdb" was done after
recreating the set with four members with 'missing' or just 3.
It is not clear what you have done.
Also I had written: "not clear to me whether the 'mdadm' daemon
instance triggered a 'check' or a 'repair'" and you seem to have
not looked into that.
Also I had written: "I hope that you disabled that in the
meantime" and it is not clear whether you have done so.
Also I had written: "Trigger a 'check' and see if the set is
consistent", and I have no idea whether that happened and what
the result was.
Your actions and reports seem to be somewhat lackadaisical and
distracted as to what is a quite subtle situation.
>> Currently rebuilding.
Adding back 'sdb' and rebuilding: you can leave that to the
point where you have found the right order. Also before adding
'sdb' you would have used 'wipefs'/'mdadm --zero' it, I hope.
> Peter, here is where I come unstuck. Where to from here?
> Raid6 has rebuilt, apparently successfully, but I can't mount.
It's difficult to say, because it is not clear what is going on,
because if the right order of members is (sdb sde sdc sdd) the
original output of 'mdadm --examine' is not consistent with that.
The issue here continues to be what is the right order of the
devices as members, and I am not sure that you know which
devices are which. I don't know how accurate are your reports
as to what happened and as to what you are doing.
> [29458.547989] disk 0, o:1, dev:sde
> [29458.547995] disk 1, o:1, dev:sdc
> [29458.548001] disk 2, o:1, dev:sdd
> [29458.548007] disk 3, o:1, dev:sdb
To me it seems pretty unlikely that 'sdb' would be member 3, but
again given your conflicting information as to past and current
actions, I cannot guess what is really going on.
But then your situation should be pretty easy: according to your
reports, you have a set of 4 devices in RAID6, which means that
any 2 devices of the 4 are sufficient to make the set work. The
only problem is knowing in which positions.
For the first stripe, the first 512KiB on each drive, the layout
will be:
member 0: the first 512KiB of the 'ext4', with the superblock.
member 1: the second 512KiB of the 'ext4', with a distinctive layout.
member 2: 512KiB of P (XOR parity), looking like gibberish.
member 3: 512KiB of Q (syndrome), looking like gibberish.
It might be interesting to see the output of:
for D in c d e
do
echo
echo "*** $D"
blkid /dev/sd$D
dd bs=512K count=1 if=/dev/sd$D | file -
dd bs=512K count=1 if=/dev/sd$D | strings -a
done
^ permalink raw reply
* [PATCH] md: notify about new spare disk in the container
From: Alexey Obitotskiy @ 2017-07-21 10:19 UTC (permalink / raw)
To: linux-raid; +Cc: shli
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 | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 66f6b92..02f4c6f 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -4283,6 +4283,7 @@ new_dev_store(struct mddev *mddev, const char *buf, size_t len)
if (err)
export_rdev(rdev);
mddev_unlock(mddev);
+ md_new_event(mddev);
return err ? err : len;
}
--
2.7.4
^ permalink raw reply related
* Re: Linear device of two arrays
From: Veljko @ 2017-07-21 11:37 UTC (permalink / raw)
To: NeilBrown, linux-raid
In-Reply-To: <be3ba727-2456-3507-e6d8-5b46d8b64339@gmail.com>
Hello Neil,
On 07/21/2017 11:15 AM, Veljko wrote:
>> On 07/21/2017 12:00 AM, NeilBrown wrote:
>> Bother.
>> mdadm uses "parse_size()" to parse the offset, and this rejects
>> "0", which makes sense for a size, but not for an offset.
>>
>> Just leave the "--data-offset=0" out. I checked and that is defintely
>> the default for 1.0.
>
> Yes, now it works. I was able to create new linear device, restored the
> saved 3M file and grown xfs. It was really fast and indeed, I'm happy.
>
> Thank you very much, Neil!
Well, not without problems, it seams.
I was having problem with root partition that was mounted read-only
because of some problem with ext4. After fixing that on reboot, I still
have extra space that was added with 4 new drives, but there are no md3
or md4. I'm mounting this device in fstab with UUID. I noticed that UUID
for md4 was the same as md2 before rebooting. But if I use array UUID
from examine of md2 (first member of linear raid), I get:
mount: can't find UUID="24843a41:8f84ee37:869fbe7b:bc953b58"
The one that works and that is in fstab is that one for md2 in by-uuid
below.
# cat /proc/mdstat
Personalities : [raid1] [raid10]
md2 : active raid10 sda4[4] sdd3[5] sdc3[7] sdb4[6]
5761631232 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
md1 : active raid10 sda3[4] sdd2[5] sdc2[7] sdb3[6]
97590272 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
md0 : active raid1 sda2[2] sdb2[3]
488128 blocks super 1.2 [2/2] [UU]
No md3 or md4.
Also, no mention of them in mdadm.conf
# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 UUID=e5a17766:b4df544d:c2770d6e:214113ec
name=backup1:0
ARRAY /dev/md/1 metadata=1.2 UUID=91560d5a:245bbc56:cc08b0ce:9c78fea1
name=backup1:1
ARRAY /dev/md/2 metadata=1.2 UUID=f6eeaa57:a55f36ff:6980a62a:d4781e44
name=backup1:2
or in dev:
# ls /dev/md/
0 1 2
or in /dev/disk/by-uuid:
ls -al /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 120 Jul 21 12:11 .
drwxr-xr-x 7 root root 140 Jul 21 12:11 ..
lrwxrwxrwx 1 root root 10 Jul 21 12:15
64f194a4-7a3f-4cff-b167-ff6d8e70adff -> ../../dm-1
lrwxrwxrwx 1 root root 9 Jul 21 12:15
81060b25-b698-4cbd-b67f-d35c42c9482c -> ../../md2
lrwxrwxrwx 1 root root 10 Jul 21 12:15
b0285993-75db-48fd-bcd7-10d870e6069f -> ../../dm-0
lrwxrwxrwx 1 root root 9 Jul 21 12:15
dcfde992-2fe2-4da2-bb66-8c541a4bd473 -> ../../md0
--examine of md2 shows that this is a member of newly created linear md4
array:
# mdadm --examine /dev/md2
/dev/md2:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 24843a41:8f84ee37:869fbe7b:bc953b58
Name : backup2:4 (local to host backup2)
Creation Time : Fri Jul 21 10:58:07 2017
Raid Level : linear
Raid Devices : 2
Avail Dev Size : 11523262440 (5494.72 GiB 5899.91 GB)
Used Dev Size : 0
Super Offset : 11523262448 sectors
State : clean
Device UUID : d8931222:30af893e:9e0d2fe3:b18274ef
Update Time : Fri Jul 21 10:58:07 2017
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : eff10ec - correct
Events : 0
Rounding : 1024K
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
This device and array has different UUID than one used for mounting the
device in fstab.
--detail on md2 still works.
mdadm --detail /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Fri Sep 14 12:40:13 2012
Raid Level : raid10
Array Size : 5761631232 (5494.72 GiB 5899.91 GB)
Used Dev Size : 2880815616 (2747.36 GiB 2949.96 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Update Time : Fri Jul 21 12:28:07 2017
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : near=2
Chunk Size : 512K
Name : backup1:2
UUID : f6eeaa57:a55f36ff:6980a62a:d4781e44
Events : 2689052
Number Major Minor RaidDevice State
4 8 4 0 active sync set-A /dev/sda4
6 8 20 1 active sync set-B /dev/sdb4
7 8 35 2 active sync set-A /dev/sdc3
5 8 51 3 active sync set-B /dev/sdd3
--examine switch on partitions that are members of md2 or md3 shows that
they know where they belong.
Is there a procedure for finding the missing devices? I'm not really
comfortable with this confusing situation.
Regards,
Veljko
^ permalink raw reply
* [PATCH] Monitor: containers don't have the same sysfs properties as arrays
From: Mariusz Tkaczyk @ 2017-07-21 12:15 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>
Reviewed-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
---
Monitor.c | 50 ++++++++++++++++++++++++++++----------------------
1 file changed, 28 insertions(+), 22 deletions(-)
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;
if (test)
alert("TestMessage", dev, NULL, ainfo);
- retval = 0;
-
fd = open(dev, O_RDONLY);
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 +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;
+
+ 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 +519,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 +659,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
* [PATCH] Monitor: Include containers in spare migration
From: Mariusz Tkaczyk @ 2017-07-21 12:58 UTC (permalink / raw)
To: linux-raid; +Cc: jes.sorensen, Mariusz Tkaczyk
md_array_active used GET_ARRAY_INFO ioctl to find out if array is
active. If called for a container, it also returned true as ioctl for
container was successful. sysfs implementation of md_array_active
returns false for container and spare migration for external metadata
doesn't work.
One option would be to make sysfs implementation work the same way as
ioctl implementation, however md_array_active is a misleading function
name to return true for inactive containers. As ioctl implementation is
supposed to be abandoned one day, let's keep different (but correct)
behaviour. Most of the callers of md_array_active don't use it on a
containers anyway so change the only place where it matters.
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@intel.com>
Reviewed-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
---
Monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Monitor.c b/Monitor.c
index 8d753ca..ac9e421 100644
--- a/Monitor.c
+++ b/Monitor.c
@@ -494,7 +494,7 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
is_container = mse->level == NULL;
- if (!md_array_active(fd))
+ if (!is_container && !md_array_active(fd))
goto disappeared;
fcntl(fd, F_SETFD, FD_CLOEXEC);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/3] mdadm.h: Undefine dprintf before redefining
From: maxin.john @ 2017-07-21 13:25 UTC (permalink / raw)
To: linux-raid; +Cc: Khem Raj, Maxin B. John
From: Khem Raj <raj.khem@gmail.com>
dprintf is also defined in libc see
usr/include/bits/stdio2.h, this comes into
play especially when fortify sources is enabled
and compilers like clang reports the override
In file included from policy.c:25:
./mdadm.h:1562:9: error: 'dprintf' macro redefined [-Werror,-Wmacro-redefined]
^
/mnt/oe/openembedded-core/build/tmp-glibc/sysroots/qemux86/usr/include/bits/stdio2.h:145:12: note: previous definition is here
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Maxin B. John <maxin.john@intel.com>
---
mdadm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mdadm.h b/mdadm.h
index ee9b837..55c707a 100644
--- a/mdadm.h
+++ b/mdadm.h
@@ -1647,11 +1647,13 @@ static inline char *to_subarray(struct mdstat_ent *ent, char *container)
}
#ifdef DEBUG
+#undef dprintf
#define dprintf(fmt, arg...) \
fprintf(stderr, "%s: %s: "fmt, Name, __func__, ##arg)
#define dprintf_cont(fmt, arg...) \
fprintf(stderr, fmt, ##arg)
#else
+#undef dprintf
#define dprintf(fmt, arg...) \
({ if (0) fprintf(stderr, "%s: %s: " fmt, Name, __func__, ##arg); 0; })
#define dprintf_cont(fmt, arg...) \
--
2.4.0
^ permalink raw reply related
* [PATCH 2/3] mdadm.h: include sys/sysmacros.h for major/minor defintions
From: maxin.john @ 2017-07-21 13:25 UTC (permalink / raw)
To: linux-raid; +Cc: Khem Raj, Maxin B. John
In-Reply-To: <1500643560-21322-1-git-send-email-maxin.john@gmail.com>
From: Khem Raj <raj.khem@gmail.com>
glibc 2.25 is warning about it if applications depend on
sys/types.h for these macros, it expects to be included
from <sys/sysmacros.h>
Fixes
| Grow.c:3534:13: error: In the GNU C Library, "minor" is defined
| by <sys/sysmacros.h>. For historical compatibility, it is
| currently defined by <sys/types.h> as well, but we plan to
| remove this soon. To use "minor", include <sys/sysmacros.h>
| directly. If you did not intend to use a system-defined macro
| "minor", you should undefine it after including <sys/types.h>. [-Werror]
| Query.c: In function 'Query':
| Query.c:105:13: error: In the GNU C Library, "makedev" is defined
| by <sys/sysmacros.h>. For historical compatibility, it is
| currently defined by <sys/types.h> as well, but we plan to
| remove this soon. To use "makedev", include <sys/sysmacros.h>
| directly. If you did not intend to use a system-defined macro
| "makedev", you should undefine it after including <sys/types.h>. [-Werror]
| makedev((unsigned)disc.major,(unsigned)disc.minor) == stb.st_rdev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Maxin B. John <maxin.john@intel.com>
---
mdadm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/mdadm.h b/mdadm.h
index 55c707a..dce5f82 100644
--- a/mdadm.h
+++ b/mdadm.h
@@ -34,6 +34,7 @@ extern __off64_t lseek64 __P ((int __fd, __off64_t __offset, int __whence));
#endif
#include <sys/types.h>
+#include <sys/sysmacros.h>
#include <sys/stat.h>
#include <stdint.h>
#include <stdlib.h>
--
2.4.0
^ permalink raw reply related
* [PATCH 3/3] monitor.c: Fix build in x32 ABI
From: maxin.john @ 2017-07-21 13:26 UTC (permalink / raw)
To: linux-raid; +Cc: Aníbal Limón, Maxin B. John
In-Reply-To: <1500643560-21322-1-git-send-email-maxin.john@gmail.com>
From: Aníbal Limón <anibal.limon@linux.intel.com>
When we try to print time_t values as a long int it causes an error
because time_t data type in x32 ABI is long long int.
Signed-off-by: Maxin B. John <maxin.john@intel.com>
---
monitor.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/monitor.c b/monitor.c
index 81537ed..7cd9b8a 100644
--- a/monitor.c
+++ b/monitor.c
@@ -447,7 +447,11 @@ static int read_and_act(struct active_array *a, fd_set *fds)
}
gettimeofday(&tv, NULL);
+#if defined(__x86_64__) && defined(__ILP32__)
+ dprintf("(%d): %lld.%06lld state:%s prev:%s action:%s prev: %s start:%llu\n",
+#else
dprintf("(%d): %ld.%06ld state:%s prev:%s action:%s prev: %s start:%llu\n",
+#endif
a->info.container_member,
tv.tv_sec, tv.tv_usec,
array_states[a->curr_state],
--
2.4.0
^ permalink raw reply related
* Re: raid 1 assembled but inactive - works from a "live" distribution...
From: Georgios Petasis @ 2017-07-21 14:04 UTC (permalink / raw)
To: Wols Lists, linux-raid
In-Reply-To: <5970B35F.1030007@youngman.org.uk>
Στις 20/7/2017 16:42, ο Wols Lists έγραψε:
> On 20/07/17 12:52, Georgios Petasis wrote:
>> Another puzzling fact, is that booting fedora 25 with the previous
>> kernel works.
>> With the latest kernel does not.
>> I tried because I saw "md: personality for level 1 is not loaded!" in
>> the logs...
> Has the initrd or similar been changed somehow? I'll let the experts
> chime in more, but this sounds like the kernel module for raid1 has
> become inaccessible.
I think the problem is a kernel update that was issued by fedora. I have
updated to the newest kernel, but since this is a server running 24/7, I
had the problem after I reboot. And it took me many hours to find out it
was a kernel issue.
I have filed a bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1473308
and I am waiting what will happen.
>
> You've got superblock v1.2, which means the old trick of booting off of
> one disk read-only, before assembling the raid and switching root
> read/write won't work. Therefore you
>
> (a) *MUST* have raid1 support in grub, in order to be able to read the
> mirror to find the kernel, and
>
> (b) must have raid1 support in the kernel, so the kernel can see /.
My configuration does not use raid at /. The /boot and / partitions are
on a plain SSD. What I have as raid-1 are /var, /home, and /free (an
irrelevant space you can drop things).
What happens during Fedora 25 boot with kernel 4.11.10-200.fc25 is:
everything is normal until the boot process mounts the file systems.
There is waits from 1,5 minute to find all three devices, and then times
out and enters in emergency mode.
In there, the 3 raid devices are available, but inactive. The reason
they are inactive, is because personalities is empty.
For sure raid-1 personality is missing, there can be also other
personalities missing but I don't have them in my system to check.
There is a clear message in the boot logs that says:
md: personality for level 1 is not loaded!
So, I suspect relevant modules are missing from the specific kernel.
>
> As I say, that message makes me suspect that either the grub or the
> kernel raid-1 support module has disappeared ...
I also think that the kernel module for raid-1 has disappeared...
Thanks,
George
>
> Cheers,
> Wol
> --
> 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: [PATCH V2] md: simplify code with bio_io_error
From: Shaohua Li @ 2017-07-21 20:16 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: linux-raid
In-Reply-To: <20170721083344.32134-1-gqjiang@suse.com>
On Fri, Jul 21, 2017 at 04:33:44PM +0800, Guoqing Jiang wrote:
> Since bio_io_error sets bi_status to BLK_STS_IOERR,
> and calls bio_endio, so we can use it directly.
>
> And as mentioned by Shaohua, there are also two
> places in raid5.c can use bio_io_error either.
applied, thanks!
> Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
> ---
> V2:
> No changes, just rebased on latest kernel tree.
>
> drivers/md/raid1.c | 3 +--
> drivers/md/raid10.c | 6 ++----
> drivers/md/raid5.c | 9 +++------
> 3 files changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index 1d235cc..f50958d 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -790,8 +790,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_status = BLK_STS_IOERR;
> - 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 e2617d0..f55d4cc 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -905,8 +905,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_status = BLK_STS_IOERR;
> - 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 */
> @@ -1090,8 +1089,7 @@ static void raid10_unplug(struct blk_plug_cb *cb, bool from_schedule)
> bio->bi_next = NULL;
> bio->bi_bdev = rdev->bdev;
> if (test_bit(Faulty, &rdev->flags)) {
> - bio->bi_status = BLK_STS_IOERR;
> - 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 aeeb8d6..4904dff 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -3381,9 +3381,8 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
> sh->dev[i].sector + STRIPE_SECTORS) {
> struct bio *nextbi = r5_next_bio(bi, sh->dev[i].sector);
>
> - bi->bi_status = BLK_STS_IOERR;
> md_write_end(conf->mddev);
> - bio_endio(bi);
> + bio_io_error(bi);
> bi = nextbi;
> }
> if (bitmap_end)
> @@ -3403,9 +3402,8 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
> sh->dev[i].sector + STRIPE_SECTORS) {
> struct bio *bi2 = r5_next_bio(bi, sh->dev[i].sector);
>
> - bi->bi_status = BLK_STS_IOERR;
> md_write_end(conf->mddev);
> - bio_endio(bi);
> + bio_io_error(bi);
> bi = bi2;
> }
>
> @@ -3429,8 +3427,7 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
> struct bio *nextbi =
> r5_next_bio(bi, sh->dev[i].sector);
>
> - bi->bi_status = BLK_STS_IOERR;
> - bio_endio(bi);
> + bio_io_error(bi);
> bi = nextbi;
> }
> }
> --
> 2.10.0
>
^ permalink raw reply
* Re: [PATCH] md: notify about new spare disk in the container
From: Shaohua Li @ 2017-07-21 20:24 UTC (permalink / raw)
To: Alexey Obitotskiy; +Cc: linux-raid
In-Reply-To: <1500632344-22339-1-git-send-email-aleksey.obitotskiy@intel.com>
On Fri, Jul 21, 2017 at 12:19:04PM +0200, Alexey Obitotskiy wrote:
> 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.
Hopefully we don't need this in the future after mdadm uses sysfs.
> Signed-off-by: Alexey Obitotskiy <aleksey.obitotskiy@intel.com>
> ---
> drivers/md/md.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 66f6b92..02f4c6f 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -4283,6 +4283,7 @@ new_dev_store(struct mddev *mddev, const char *buf, size_t len)
> if (err)
> export_rdev(rdev);
> mddev_unlock(mddev);
> + md_new_event(mddev);
Probably only do this in success?
> return err ? err : len;
> }
>
> --
> 2.7.4
>
^ permalink raw reply
* Wrong array assembly on boot?
From: Dark Penguin @ 2017-07-22 18:39 UTC (permalink / raw)
To: linux-raid
Greetings!
I have a mirror RAID with two devices (sdc1 and sde1). It's not a root
partition, just a RAID with some data for services running on this
server. (I'm running Debian Jessie x86_64 with a 4.1.18 kernel.) The
RAID is listed in /etc/mdadm, and it has an external bitmap in /RAID .
One of the devices in the RAID (sdc1) "fell off" - it disappeared from
the system for some reason. Well, I thought, I have to reboot to get the
drive back, and then re-add it.
That's what I did. After the reboot, I saw a degraded array with one
drive missing, so I found out which one , and re-added it back.
Later, I noticed that I'm missing some data, and thinking about this
situation led me to understanding what happened. After a reboot, the
system tried to assemble my arrays; it found sdc1 first (the one that
disappeared), assembled a degraded array with only this drive, and
started it. When I re-added the second drive, I've overwritten
everything that happened between those events.
Now I'm trying to understand why this happened and what am I supposed to
do in this situation to handle it properly. So now I have a lot of
questions boiling down to "how should booting with degraded arrays be
handled?"
- Why did mdadm not notice that the second drive is "newer"? I thought
there were timestamps in the devices and even in the bitmap!..
- Why did it START this array?! I thought if a degraded array is found
at boot, it's supposed to be assembled but not started?.. At least I
think that's how it used to be in Wheezy (before systemd?).
- Googling revealed that if a degraded array is detected, the system
should stop booting and ask for a confirmation in the console. (Only for
root partitions? And only before systemd?..)
- My services are not going to be happy either way. If the array is
assembled but not run, they will have data missing. If the array is
assembled and run, it's even worse - they will start with outdated data!
How is this even supposed to be handled?.. Should I add dependencies on
mounting a specific mountpoint in each service definition?.. Am I wrong
in thinking that mdadm should have detected that the second drive is
"newer" and assemble the array just like it was before, thus avoiding
all those problems easily?.. Especially considering that the array on
the "new" drive already consists of only one drive, which is "not as
degraded" and would be fine to run, compared to the array on the "old"
drive which was not stopped properly and only now learns about one of
the drives missing? Maybe this behaviour is already changed in the newer
versions?..
--
darkpenguin
^ permalink raw reply
* Re: Linear device of two arrays
From: NeilBrown @ 2017-07-22 23:03 UTC (permalink / raw)
To: Veljko, linux-raid
In-Reply-To: <cc2ff16e-5368-b828-6acc-6698d6e0b521@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2905 bytes --]
On Fri, Jul 21 2017, Veljko wrote:
> Hello Neil,
>
> On 07/21/2017 11:15 AM, Veljko wrote:
>>> On 07/21/2017 12:00 AM, NeilBrown wrote:
>>> Bother.
>>> mdadm uses "parse_size()" to parse the offset, and this rejects
>>> "0", which makes sense for a size, but not for an offset.
>>>
>>> Just leave the "--data-offset=0" out. I checked and that is defintely
>>> the default for 1.0.
>>
>> Yes, now it works. I was able to create new linear device, restored the
>> saved 3M file and grown xfs. It was really fast and indeed, I'm happy.
>>
>> Thank you very much, Neil!
>
>
> Well, not without problems, it seams.
>
> I was having problem with root partition that was mounted read-only
> because of some problem with ext4. After fixing that on reboot, I still
> have extra space that was added with 4 new drives, but there are no md3
> or md4. I'm mounting this device in fstab with UUID. I noticed that UUID
> for md4 was the same as md2 before rebooting. But if I use array UUID
> from examine of md2 (first member of linear raid), I get:
>
> mount: can't find UUID="24843a41:8f84ee37:869fbe7b:bc953b58"
>
> The one that works and that is in fstab is that one for md2 in by-uuid
> below.
The UUID you give to mount is the UUID of the filesystem, not of the
device (or array) which stores the filesystem.
One of the problems with use 1.0 metadata (or 0.90) is that the first
component device looks like it contains the same filesystem as the whole
array. I think this is what is causing your confusion.
>
>
> # cat /proc/mdstat
> Personalities : [raid1] [raid10]
> md2 : active raid10 sda4[4] sdd3[5] sdc3[7] sdb4[6]
> 5761631232 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
>
> md1 : active raid10 sda3[4] sdd2[5] sdc2[7] sdb3[6]
> 97590272 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
>
> md0 : active raid1 sda2[2] sdb2[3]
> 488128 blocks super 1.2 [2/2] [UU]
>
>
> No md3 or md4.
>
> Also, no mention of them in mdadm.conf
>
> # definitions of existing MD arrays
> ARRAY /dev/md/0 metadata=1.2 UUID=e5a17766:b4df544d:c2770d6e:214113ec
> name=backup1:0
> ARRAY /dev/md/1 metadata=1.2 UUID=91560d5a:245bbc56:cc08b0ce:9c78fea1
> name=backup1:1
> ARRAY /dev/md/2 metadata=1.2 UUID=f6eeaa57:a55f36ff:6980a62a:d4781e44
> name=backup1:2
This all depends on the details of the particular distro you are using.
You don't, in general, need arrays to be listed in mdadm.conf. A
particular distro could require it though.
If you run
mdadm -Es
It will show a sample mdadm.conf which should contain /dev/md/3 - the
new raid10, and /dev/md/4.
You could add those lines to mdadm.conf, then
mdadm --assemble /dev/md/3
mdadm --assemble /dev/md/4
and it should get assembled. Then you should be able to mount the large
filesystem successfully.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Superblocks lost on 5/6 disks
From: MasterPrenium @ 2017-07-22 23:54 UTC (permalink / raw)
To: linux-raid; +Cc: MasterPrenium@gmail.com
Hi guys,
I was running a raid 6 array, made of 6x 3TB drives. Everything was
working fine on this server.
I decided to shut it down in order to made a usual dust cleaning, no
problem here. I'm 99% sure I check the raid stack status before shutting
it down (/proc/mdstat) and everything was fine.
When I started back the server (please note I started it on a LiveCD,
because I originally wanted to setup a new / (root) system which has
nothing to deal with the raid 6 array). I changed my mind and decided to
boot the original OS, the array wasn't up at startup. No problem I tried
to assemble it, but mdadm claimed that it can't assemble the array since
there was only one disk out of 6.
All disk were present, but superblock was zero-ed.
No SMART error or anything that could make me think of hard drive failure.
Please note the server was runing an old kernel, on which the array was
made, it's a kernel 3.5.7, and the livecd had a newer version 4.9.24.
The array which was originally built was a raid 5 with 5 drives, I grew
it up to 6 drives in raid 6 when I had some hard drives failure.
Everything was synchronised since a long time. At least a few months.
The array was : /dev/md/3TB, with partitions /dev/sd[c-h]1.
mdadm --examine /dev/sdc1 give me the correct superblock infos :
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 9372578e:331a752a:d132dbef:3a67286d
Name : Server:3TB
Creation Time : Sun Aug 21 00:27:32 2016
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860528128 (2794.52 GiB 3000.59 GB)
Array Size : 8589928448 (8191.99 GiB 8796.09 GB)
Used Dev Size : 4294964224 (2048.00 GiB 2199.02 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
Unused Space : before=1968 sectors, after=1565563904 sectors
State : clean
Device UUID : d8051645:40eff7c2:7eb00722:711efe7a
Update Time : Sat Jul 22 11:58:51 2017
Checksum : 1b841a0e - correct
Events : 463
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
but
mdadm --examine on all other drives said "No md superblock detected on
xxxx".
- blkid also report nothing on UUID_SUB= parameter, neither label etc
... Only work on /dev/sdc1 (I also got another raid 5 stack on this
server which is still running flawlessly).
- gparted (on the livecd), cannot guess what type of partition hard
drives are running (except sdc).
I also tried some force assemble etc ... and got some message that mdadm
was expecting a superblock value, but got "0000000" instead.
I dump 8K of first sector of the partition and they were completely
blank (except for sdc).
So I definitely lost my superblock informations on 5 out of 6 drives.
Maybe I panic a bit and made now some mistakes. But here what I've tried :
Only on one drive (/dev/sdd) (as a test) I tried re-creating the
partition (was thinking the problem could be here, because I already had
such kind of issue (another setup, but maybe same kernel), and after
re-creating the partition (I always use the same scheme), the device was
back again).
I've tried re-creating the array, with --assume-clean, but I think there
could be some order for the drive ? I don't know what is the original
order. Nevermind it doesn't work.
I restore a backup of the 50 first Megabytes of sdc to get back it's
original information and superblock.
But now I'm stucked and I'm asking for your help.
==> Can I copy the "working" (ie : original sdc) superblock to other
drives to make it work ?
I've looked a bit with some hex dump. I can copy data from sdc to sdd
(for ex), but I don't know how to make the checksum correct (or how to
change the device UUID).
If someone can give me more informations, or some guidance ...
Any help would be greatly appreciated.
Btw, I still don't know how the superblocks could have been zeroed.
Regards,
MasterPrenium
^ permalink raw reply
* Re: Advice please re failed Raid6
From: Bogo Mipps @ 2017-07-23 0:13 UTC (permalink / raw)
To: Peter Grandi, Linux Raid
In-Reply-To: <22897.52696.164078.23536@tree.ty.sabi.co.uk>
On 07/21/2017 09:48 PM, Peter Grandi wrote:
>>> Tried different order: sde, sdc, sdd and blkid worked.
>
> It is not clear what "blkid worked" means here. It should have
> reported an 'ext4' filesystem.
>
>>> Added sdb as you suggested.
>
> I actually wrote: "try a different order or 3-way subset of
> 'sd[bcde]'." Perhaps "3-way subset" was not clear. Only when the
> right subset in the right order were found adding a fourth
> member was worth it.
>
> Also it matter enormously whether "Added sdb" was done after
> recreating the set with four members with 'missing' or just 3.
> It is not clear what you have done.
>
> Also I had written: "not clear to me whether the 'mdadm' daemon
> instance triggered a 'check' or a 'repair'" and you seem to have
> not looked into that.
>
> Also I had written: "I hope that you disabled that in the
> meantime" and it is not clear whether you have done so.
>
> Also I had written: "Trigger a 'check' and see if the set is
> consistent", and I have no idea whether that happened and what
> the result was.
>
> Your actions and reports seem to be somewhat lackadaisical and
> distracted as to what is a quite subtle situation.
>
>>> Currently rebuilding.
>
> Adding back 'sdb' and rebuilding: you can leave that to the
> point where you have found the right order. Also before adding
> 'sdb' you would have used 'wipefs'/'mdadm --zero' it, I hope.
>
>> Peter, here is where I come unstuck. Where to from here?
>> Raid6 has rebuilt, apparently successfully, but I can't mount.
>
> It's difficult to say, because it is not clear what is going on,
> because if the right order of members is (sdb sde sdc sdd) the
> original output of 'mdadm --examine' is not consistent with that.
>
> The issue here continues to be what is the right order of the
> devices as members, and I am not sure that you know which
> devices are which. I don't know how accurate are your reports
> as to what happened and as to what you are doing.
>
>> [29458.547989] disk 0, o:1, dev:sde
>> [29458.547995] disk 1, o:1, dev:sdc
>> [29458.548001] disk 2, o:1, dev:sdd
>> [29458.548007] disk 3, o:1, dev:sdb
>
> To me it seems pretty unlikely that 'sdb' would be member 3, but
> again given your conflicting information as to past and current
> actions, I cannot guess what is really going on.
>
> But then your situation should be pretty easy: according to your
> reports, you have a set of 4 devices in RAID6, which means that
> any 2 devices of the 4 are sufficient to make the set work. The
> only problem is knowing in which positions.
>
> For the first stripe, the first 512KiB on each drive, the layout
> will be:
>
> member 0: the first 512KiB of the 'ext4', with the superblock.
> member 1: the second 512KiB of the 'ext4', with a distinctive layout.
> member 2: 512KiB of P (XOR parity), looking like gibberish.
> member 3: 512KiB of Q (syndrome), looking like gibberish.
>
> It might be interesting to see the output of:
>
> for D in c d e
> do
> echo
> echo "*** $D"
> blkid /dev/sd$D
> dd bs=512K count=1 if=/dev/sd$D | file -
> dd bs=512K count=1 if=/dev/sd$D | strings -a
> done
Peter, thank you for your detailed response. Much appreciated. My major
regret is not coming to this list earlier. I only discovered, far too
late, that I should have taken expert advice before I attempted any
remedial work. Too much erroneous information flying around the 'net.
I will now carefully follow your suggestions as above and report back in
a couple of days. The data on this Raid set is irreplaceable, and I want
to do everything I can to regain access.
Regards.
^ permalink raw reply
* Re: Linear device of two arrays
From: Veljko @ 2017-07-23 10:05 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <871sp8xeey.fsf@notabene.neil.brown.name>
On 2017-Jul-23 09:03, NeilBrown wrote:
> The UUID you give to mount is the UUID of the filesystem, not of the
> device (or array) which stores the filesystem.
>
> One of the problems with use 1.0 metadata (or 0.90) is that the first
> component device looks like it contains the same filesystem as the whole
> array. I think this is what is causing your confusion.
Yes, I mixed up those two. Now is all clear.
> This all depends on the details of the particular distro you are using.
> You don't, in general, need arrays to be listed in mdadm.conf. A
> particular distro could require it though.
>
> If you run
> mdadm -Es
>
> It will show a sample mdadm.conf which should contain /dev/md/3 - the
> new raid10, and /dev/md/4.
> You could add those lines to mdadm.conf, then
> mdadm --assemble /dev/md/3
> mdadm --assemble /dev/md/4
> and it should get assembled. Then you should be able to mount the large
> filesystem successfully.
Well, I feel much better now that I do have arrays listed in mdadm.conf
and in /dev.
Thanks very much for your help, Neil!
Regards,
Veljko
^ permalink raw reply
* Re: Superblocks lost on 5/6 disks
From: Wols Lists @ 2017-07-23 21:36 UTC (permalink / raw)
To: MasterPrenium, linux-raid; +Cc: MasterPrenium@gmail.com
In-Reply-To: <1b693f6a-28e9-2a3a-7b62-2d9bdb52cf31@gmail.com>
On 23/07/17 00:54, MasterPrenium wrote:
> The array which was originally built was a raid 5 with 5 drives, I grew
> it up to 6 drives in raid 6 when I had some hard drives failure.
> Everything was synchronised since a long time. At least a few months.
OWW!!!!
Combined with your --create --assume-clean, I think this means you have
a mess on your hands!!!
The data is probably recoverable, but DO NOT WRITE ANYTHING TO DISK !!!
Wait for the experts to chime in, but in the meantime, look at the wiki,
"When things go wrogn", and the page "mdadm says my array doesn't exist".
That'll tell you how to search for missing superblocks, file-system
signatures etc. I think that's where you're going to have to go to
recover your data ... hopefully it's not going to be too hard a job.
As I said, DO NOT let anything write to your disks until the experts
tell you what to do!
Cheers,
Wol
^ permalink raw reply
* Triggering WARN_ON_ONCE in drivers/md/md.c::set_in_sync()
From: Joshua Kinard @ 2017-07-24 1:11 UTC (permalink / raw)
To: linux-raid
Hi,
I'm testing out a netboot installer image on an old SGI MIPS machine,
which has two disks (/dev/sda, /dev/sdb) in an md raid1 setup, all
filesystems using XFS V5. root filesystem is on /dev/md0 and /dev/md2
is where /usr will mount, but /usr is in the middle of a resync. The
remaining md devices are synced and have bitmaps enabled.
If I attempt to mount the root filesystem, I trigger these messages on
the console:
[ 147.156932] XFS (md0): Mounting V5 Filesystem
[ 148.545726] ------------[ cut here ]------------
[ 148.550522] WARNING: CPU: 0 PID: 258 at drivers/md/md.c:2273 set_in_sync+0x38/0xfc
[ 148.558265] CPU: 0 PID: 258 Comm: md0_raid1 Not tainted 4.12.3-mipsgit-20170703 #1
[ 148.565915] Stack : 0000000000000046 0000000000000000 0000000000000000 ffffffff9401fce1
[ 148.574021] 0000000000000000 0000000000000000 0000000000000005 ffffffff8005a03c
[ 148.582100] ffffffff80726e57 ffffffff806b3060 980000005318d800 0000000000000102
[ 148.590198] ffffffff80b91f90 00000000000008e1 ffffffff806b0000 ffffffff80b70000
[ 148.598298] 0000000000000000 ffffffff80096b5c 980000005355fbc8 ffffffff8002d170
[ 148.606395] ffffffff8046c974 ffffffff8005b03c 0000000000000007 ffffffff806b3060
[ 148.614495] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 148.622576] 0000000000000000 980000005355fb10 0000000000000000 ffffffff8002d3e0
[ 148.630673] 0000000000000000 0000000000000000 ffffffff8046c974 0000000000000000
[ 148.638773] 0000000000000000 ffffffff8000e81c 0000000000000000 ffffffff8002d3e0
[ 148.646869] ...
[ 148.649354] Call Trace:
[ 148.651878] [<ffffffff8000e81c>] show_stack+0x70/0x8c
[ 148.657012] [<ffffffff8002d3e0>] __warn+0x108/0x110
[ 148.661935] [<ffffffff8046c974>] set_in_sync+0x38/0xfc
[ 148.667157] [<ffffffff80476990>] md_check_recovery+0x2fc/0x5c0
[ 148.673080] [<ffffffff8044bba8>] raid1d+0x48/0x1298
[ 148.678032] [<ffffffff8046c934>] md_thread+0x178/0x180
[ 148.683235] [<ffffffff80047650>] kthread+0x140/0x148
[ 148.688271] [<ffffffff80009260>] ret_from_kernel_thread+0x14/0x1c
[ 148.694438] ---[ end trace d27f806e939dc049 ]---
[ 149.210292] XFS (md0): Ending clean mount
Checking *(set_in_sync+0x38) in gdb yields:
(gdb) l *(set_in_sync+0x38)
0xffffffff8046c974 is in set_in_sync (drivers/md/md.c:2274).
2269 }
2270
2271 static bool set_in_sync(struct mddev *mddev)
2272 {
2273 WARN_ON_ONCE(!spin_is_locked(&mddev->lock));
2274 if (!mddev->in_sync) {
2275 mddev->sync_checkers++;
2276 spin_unlock(&mddev->lock);
2277 percpu_ref_switch_to_atomic_sync(&mddev->writes_pending);
2278 spin_lock(&mddev->lock);
Everything is still usable after this point, but attempting to untar a
large file onto the /usr mount (/dev/md2) will crash/panic the kernel,
but those panic messages are marked as "tainted". I'm currently
waiting for the resync to finish now before proceeding further. I'll
add that this machine only has one CPU, so my understanding was all
spinlocks compile out in that case (if PREEMPT is not enabled, which it
isn't). Thus I am a bit stumped why this is being triggered, especially
when mounting an unrelated md device that is already fully resynced.
If any additional info is needed, let me know. Thanks!
--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
^ permalink raw reply
* [PATCH] md/raid5: add thread_group worker async_tx_issue_pending_all
From: oferh @ 2017-07-24 6:17 UTC (permalink / raw)
To: shli; +Cc: nadavh, linux-raid, Ofer Heifetz, stable
From: Ofer Heifetz <oferh@marvell.com>
Since thread_group worker and raid5d kthread are not in sync, if
worker writes stripe before raid5d then requests will be waiting
for issue_pendig.
Issue observed when building raid5 with ext4, in some build runs
jbd2 would get hung and requests were waiting in the HW engine
waiting to be issued.
Fix this by adding a call to async_tx_issue_pending_all in the
raid5_do_work.
Signed-off-by: Ofer Heifetz <oferh@marvell.com>
Cc: stable@vger.kernel.org
---
drivers/md/raid5.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index aeeb8d6..3c0b924 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -6237,6 +6237,8 @@ static void raid5_do_work(struct work_struct *work)
pr_debug("%d stripes handled\n", handled);
spin_unlock_irq(&conf->device_lock);
+
+ async_tx_issue_pending_all();
blk_finish_plug(&plug);
pr_debug("--- raid5worker inactive\n");
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] md/raid5: add thread_group worker async_tx_issue_pending_all
From: Shaohua Li @ 2017-07-24 14:48 UTC (permalink / raw)
To: oferh; +Cc: nadavh, linux-raid, stable
In-Reply-To: <1500877060-12256-1-git-send-email-oferh@marvell.com>
On Mon, Jul 24, 2017 at 09:17:40AM +0300, oferh@marvell.com wrote:
> From: Ofer Heifetz <oferh@marvell.com>
>
> Since thread_group worker and raid5d kthread are not in sync, if
> worker writes stripe before raid5d then requests will be waiting
> for issue_pendig.
>
> Issue observed when building raid5 with ext4, in some build runs
> jbd2 would get hung and requests were waiting in the HW engine
> waiting to be issued.
>
> Fix this by adding a call to async_tx_issue_pending_all in the
> raid5_do_work.
applied, thanks!
> Signed-off-by: Ofer Heifetz <oferh@marvell.com>
> Cc: stable@vger.kernel.org
> ---
> drivers/md/raid5.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index aeeb8d6..3c0b924 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -6237,6 +6237,8 @@ static void raid5_do_work(struct work_struct *work)
> pr_debug("%d stripes handled\n", handled);
>
> spin_unlock_irq(&conf->device_lock);
> +
> + async_tx_issue_pending_all();
> blk_finish_plug(&plug);
>
> pr_debug("--- raid5worker inactive\n");
> --
> 1.9.1
>
^ permalink raw reply
* Re: Wrong array assembly on boot?
From: Wols Lists @ 2017-07-24 14:48 UTC (permalink / raw)
To: Dark Penguin, linux-raid
In-Reply-To: <59739BDD.30307@yandex.ru>
On 22/07/17 19:39, Dark Penguin wrote:
> Greetings!
>
> I have a mirror RAID with two devices (sdc1 and sde1). It's not a root
> partition, just a RAID with some data for services running on this
> server. (I'm running Debian Jessie x86_64 with a 4.1.18 kernel.) The
> RAID is listed in /etc/mdadm, and it has an external bitmap in /RAID .
As an absolute minimum, can you please give us your version of mdadm.
And the output of "mdadm --display" of your arrays. (I think I've got
that right, I think --examine is the disk ...)
Cheers,
Wol
^ permalink raw reply
* Write journal sizing
From: Larkin Lowrey @ 2017-07-24 15:22 UTC (permalink / raw)
To: linux-raid
From what I read at the link below, the write journal mirrors the
contents of the stripe cache. This suggests that the write journal
cannot contain more uncommitted data than the stripe cache can hold. Is
that correct?
https://www.kernel.org/doc/Documentation/md/raid5-cache.txt
So, if the stripe cache size is 1GB then is there any advantage in
making the journal device larger than 1GB? I assume no, but I'm also
wondering about journal overhead.
My understanding is that the stripe cache size is limited to 32768 and
that the total memory size is the size value x 4096 x num disks. IOW,
max 128MB per disk (32k x 4k x 1). Is that correct?
--Larkin
^ permalink raw reply
* Re: Wrong array assembly on boot?
From: Dark Penguin @ 2017-07-24 15:27 UTC (permalink / raw)
To: Wols Lists, linux-raid
In-Reply-To: <597608BD.7080108@youngman.org.uk>
On 24/07/17 17:48, Wols Lists wrote:
> On 22/07/17 19:39, Dark Penguin wrote:
>> Greetings!
>>
>> I have a mirror RAID with two devices (sdc1 and sde1). It's not a root
>> partition, just a RAID with some data for services running on this
>> server. (I'm running Debian Jessie x86_64 with a 4.1.18 kernel.) The
>> RAID is listed in /etc/mdadm, and it has an external bitmap in /RAID .
>
> As an absolute minimum, can you please give us your version of mdadm.
Oh, right, sorry. I thought the "absolute minimum" would be the kernel
version and the distribution. :)
mdadm - v3.3.2 - 21st August 2014
> And the output of "mdadm --display" of your arrays. (I think I've got
> that right, I think --examine is the disk ...)
It's "mdadm --detail --scan" for all arrays or "mdadm --detail /dev/md0"
for md0.
I have 8 arrays on this server, and the only one that's relevant is this
one. (The rest of them are set up exactly the same way, but with
different names and UUIDs.) So, to avoid cluttering:
$ sudo mdadm --detail /dev/md/RAID
/dev/md/RAID:
Version : 1.2
Creation Time : Thu Oct 6 23:15:56 2016
Raid Level : raid1
Array Size : 244066432 (232.76 GiB 249.92 GB)
Used Dev Size : 244066432 (232.76 GiB 249.92 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : /RAID
Update Time : Mon Jul 24 17:59:53 2017
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : BAAL:RAID (local to host BAAL)
UUID : 8b5f18f0:54f655b7:8bfcc60d:4db6e6c8
Events : 5000
Number Major Minor RaidDevice State
0 8 65 0 active sync /dev/sde1
1 8 33 1 active sync writemostly /dev/sdc1
And the /etc/mdadm/mdadm.conf entry is:
ARRAY /dev/md/RAID metadata=1.2 name=BAAL:RAID bitmap=/RAID
UUID=8b5f18f0:54f655b7:8bfcc60d:4db6e6c8
I don't use the device names here because they change often in a server
with 8 arrays and 20 drives (sometimes I connect a new one or remove an
old one...). The UUID is here, the bitmap file is here, so it just looks
for all drives with this UUID and assembles the array.
As I understand, it has found the first device (/dev/sdc1, which was
outdated) and immediately added it to an array. Then it found the second
device (/dev/sde1, the up-to-date one), noticed an inconsistency and did
not add it. The question is, why did it start the array, why did it not
halt the boot process, why did it not realize that the second device is
newer (and also it already knows about the disappearance of the first
one!)...
--
darkpenguin
^ 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