* Re: [PATCH 0/2] Check node nums for cluster raid
From: Doug Ledford @ 2016-05-04 15:19 UTC (permalink / raw)
To: Jes Sorensen, Guoqing Jiang; +Cc: linux-raid
In-Reply-To: <wrfjinytx3fv.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]
On 05/04/2016 11:12 AM, Jes Sorensen wrote:
> Guoqing Jiang <gqjiang@suse.com> writes:
>> For cluster raid, we do need at least two nodes for it,
>> the two patches add the checks before create and change
>> bitmap.
>>
>> Thanks,
>> Guoqing
>>
>> Guoqing Jiang (2):
>> Create: check the node nums when create clustered raid
>> super1: don't update node nums if it is not more than 1
>>
>> Create.c | 7 ++++++-
>> super1.c | 5 +++++
>> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> Hi Guoqing,
>
> I am a little confused on this one - albeit I haven't looked at it in
> detail. Why should it not be possible to start a cluster with one node?
> In theory you should be able to do that, and then add nodes later?
Not typically. A single node of a cluster is likely the odd man out, so
starting it and allowing changes to the underlying device has a high
potential of creating split brain issues. For that reason, most cluster
setups require some minimum (usually 2) for a quorum before they will
start. Otherwise, given a three node cluster, you could end up with
three separate live filesystems and the need to merge changes between
them to bring the cluster back into sync.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Check node nums for cluster raid
From: Jes Sorensen @ 2016-05-04 15:25 UTC (permalink / raw)
To: Doug Ledford; +Cc: Guoqing Jiang, linux-raid
In-Reply-To: <305eaf9b-1275-f9b9-dae4-1be8f21ed98c@redhat.com>
Doug Ledford <dledford@redhat.com> writes:
> On 05/04/2016 11:12 AM, Jes Sorensen wrote:
>> Guoqing Jiang <gqjiang@suse.com> writes:
>>> For cluster raid, we do need at least two nodes for it,
>>> the two patches add the checks before create and change
>>> bitmap.
>>>
>>> Thanks,
>>> Guoqing
>>>
>>> Guoqing Jiang (2):
>>> Create: check the node nums when create clustered raid
>>> super1: don't update node nums if it is not more than 1
>>>
>>> Create.c | 7 ++++++-
>>> super1.c | 5 +++++
>>> 2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> Hi Guoqing,
>>
>> I am a little confused on this one - albeit I haven't looked at it in
>> detail. Why should it not be possible to start a cluster with one node?
>> In theory you should be able to do that, and then add nodes later?
>
> Not typically. A single node of a cluster is likely the odd man out, so
> starting it and allowing changes to the underlying device has a high
> potential of creating split brain issues. For that reason, most cluster
> setups require some minimum (usually 2) for a quorum before they will
> start. Otherwise, given a three node cluster, you could end up with
> three separate live filesystems and the need to merge changes between
> them to bring the cluster back into sync.
Valid point, but it still looks like a duplicate of the classic raid1
situation. We still allow the creation of a raid1 with just one drive,
would it not make more sense to spit out a warning here, rather than
deny it?
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH 0/2] Check node nums for cluster raid
From: Doug Ledford @ 2016-05-04 15:28 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Guoqing Jiang, linux-raid
In-Reply-To: <wrfjy47pvoab.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2449 bytes --]
On 05/04/2016 11:25 AM, Jes Sorensen wrote:
> Doug Ledford <dledford@redhat.com> writes:
>> On 05/04/2016 11:12 AM, Jes Sorensen wrote:
>>> Guoqing Jiang <gqjiang@suse.com> writes:
>>>> For cluster raid, we do need at least two nodes for it,
>>>> the two patches add the checks before create and change
>>>> bitmap.
>>>>
>>>> Thanks,
>>>> Guoqing
>>>>
>>>> Guoqing Jiang (2):
>>>> Create: check the node nums when create clustered raid
>>>> super1: don't update node nums if it is not more than 1
>>>>
>>>> Create.c | 7 ++++++-
>>>> super1.c | 5 +++++
>>>> 2 files changed, 11 insertions(+), 1 deletion(-)
>>>
>>> Hi Guoqing,
>>>
>>> I am a little confused on this one - albeit I haven't looked at it in
>>> detail. Why should it not be possible to start a cluster with one node?
>>> In theory you should be able to do that, and then add nodes later?
>>
>> Not typically. A single node of a cluster is likely the odd man out, so
>> starting it and allowing changes to the underlying device has a high
>> potential of creating split brain issues. For that reason, most cluster
>> setups require some minimum (usually 2) for a quorum before they will
>> start. Otherwise, given a three node cluster, you could end up with
>> three separate live filesystems and the need to merge changes between
>> them to bring the cluster back into sync.
>
> Valid point, but it still looks like a duplicate of the classic raid1
> situation. We still allow the creation of a raid1 with just one drive,
> would it not make more sense to spit out a warning here, rather than
> deny it?
Local raid1 is a little different in that if both members of a raid1 are
supposed to be present on the same machine, and that machine only sees
one of the disks, we take it on faith that the other one isn't running
around live in another machine. If it is, we can end up corrupting our
array (we rely on the events counter on one disk superseding the other
disk to know which disk is the master copy and which one needs to be
refreshed, if both disks are brought up the same number of times without
each other, then their event counters will be the same and we won't know
which one should be master). With a clustered MD filesystem, that
assumption isn't true, and so starting a device without a quorum carries
a much higher risk.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs
From: Mike Christie @ 2016-05-04 17:51 UTC (permalink / raw)
To: Jeff Moyer
Cc: linux-f2fs-devel, linux-ext4, konrad.wilk, drbd-dev,
philipp.reisner, lars.ellenberg, linux-raid, dm-devel,
linux-fsdevel, linux-bcache, linux-block, linux-kernel,
linux-scsi, linux-mtd, target-devel, linux-btrfs, osd-dev, xfs,
ocfs2-devel
In-Reply-To: <x49d1p2c1nx.fsf@segfault.boston.devel.redhat.com>
On 05/03/2016 03:44 PM, Jeff Moyer wrote:
> mchristi@redhat.com writes:
>
>> The following patches begin to cleanup the request->cmd_flags and
>> bio->bi_rw mess. We currently use cmd_flags to specify the operation,
>> attributes and state of the request. For bi_rw we use it for similar
>> info and also the priority but then also have another bi_flags field
>> for state. At some point, we abused them so much we just made cmd_flags
>> 64 bits, so we could add more.
>>
>> The following patches seperate the operation (read, write discard,
>> flush, etc) from cmd_flags/bi_rw.
>>
>> This patchset was made against linux-next from today April 15
>> (git tag next-20160415).
>>
>> I put a git tree here:
>> https://github.com/mikechristie/linux-kernel.git
>> The patches are in the op branch.
>
> Hi, Mike,
>
> That git tree doesn't seem to exist. I did manage to apply your patch
> set on top of next-20160415, though.
>
> So... what testing did you do? ;-) I ran into the following problems
I normally run xfstests and run it on my daily workstation and laptop. I
did not do this for every FS this time and hit a regression.
What FS were you using?
> - git clone fails
> - yum segfaults
In v7/v6, I missed a new submit_bio call, so I hit issues like the two
above. I have this fixed in the next version.
> - many blktrace/blkparse issues, including incorrect cpu recorded in
> traces, null task names, and blkparse outputting nothing for a trace
> file several gigabytes in size.
I will double check for these issues.
^ permalink raw reply
* Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs
From: Jeff Moyer @ 2016-05-04 17:58 UTC (permalink / raw)
To: Mike Christie
Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA,
linux-block-u79uwXL29TY76Z2rM5mHXA, xfs-VZNHf3L845pBDgjK7y7TUQ,
ocfs2-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
target-devel-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
osd-dev-yNzVSZO3znNg9hUCZPvPmw,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA,
linux-btrfs-u79uwXL29TY76Z2rM5mHXA,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <572A36BF.3070208-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Mike Christie <mchristi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> On 05/03/2016 03:44 PM, Jeff Moyer wrote:
>> Hi, Mike,
>>
>> That git tree doesn't seem to exist. I did manage to apply your patch
>> set on top of next-20160415, though.
>>
>> So... what testing did you do? ;-) I ran into the following problems
>
> I normally run xfstests and run it on my daily workstation and laptop. I
> did not do this for every FS this time and hit a regression.
>
> What FS were you using?
I'm using xfs, scsi disk, no blk-mq, no dm.
>> - git clone fails
>> - yum segfaults
>
> In v7/v6, I missed a new submit_bio call, so I hit issues like the two
> above. I have this fixed in the next version.
OK, does this mean you're posting another version, or you already did
and I somehow missed it?
>> - many blktrace/blkparse issues, including incorrect cpu recorded in
>> traces, null task names, and blkparse outputting nothing for a trace
>> file several gigabytes in size.
>
> I will double check for these issues.
Thanks. I'll stop digging for now, then.
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs
From: Mike Christie @ 2016-05-04 18:04 UTC (permalink / raw)
To: Jeff Moyer
Cc: linux-f2fs-devel, linux-ext4, konrad.wilk, drbd-dev,
philipp.reisner, lars.ellenberg, linux-raid, dm-devel,
linux-fsdevel, linux-bcache, linux-block, linux-kernel,
linux-scsi, linux-mtd, target-devel, linux-btrfs, osd-dev, xfs,
ocfs2-devel
In-Reply-To: <x49a8k5aen2.fsf@segfault.boston.devel.redhat.com>
On 05/04/2016 12:58 PM, Jeff Moyer wrote:
> Mike Christie <mchristi@redhat.com> writes:
>
>> On 05/03/2016 03:44 PM, Jeff Moyer wrote:
>>> Hi, Mike,
>>>
>>> That git tree doesn't seem to exist. I did manage to apply your patch
>>> set on top of next-20160415, though.
>>>
>>> So... what testing did you do? ;-) I ran into the following problems
>>
>> I normally run xfstests and run it on my daily workstation and laptop. I
>> did not do this for every FS this time and hit a regression.
>>
>> What FS were you using?
>
> I'm using xfs, scsi disk, no blk-mq, no dm.
>
>>> - git clone fails
>>> - yum segfaults
>>
>> In v7/v6, I missed a new submit_bio call, so I hit issues like the two
>> above. I have this fixed in the next version.
>
> OK, does this mean you're posting another version, or you already did
> and I somehow missed it?
>
I did not repost yet. I am still testing. Jens had me add some wrappers
around the operation access, so because of my last screw up and the
wrapper change affected all my patches I am redoing all my testing.
^ permalink raw reply
* Re: [PATCH 0/2] Check node nums for cluster raid
From: Guoqing Jiang @ 2016-05-05 3:03 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-raid
In-Reply-To: <wrfjinytx3fv.fsf@redhat.com>
Hi Jes,
On 05/04/2016 11:12 AM, Jes Sorensen wrote:
> Guoqing Jiang <gqjiang@suse.com> writes:
>> For cluster raid, we do need at least two nodes for it,
>> the two patches add the checks before create and change
>> bitmap.
>>
>> Thanks,
>> Guoqing
>>
>> Guoqing Jiang (2):
>> Create: check the node nums when create clustered raid
>> super1: don't update node nums if it is not more than 1
>>
>> Create.c | 7 ++++++-
>> super1.c | 5 +++++
>> 2 files changed, 11 insertions(+), 1 deletion(-)
> Hi Guoqing,
>
> I am a little confused on this one - albeit I haven't looked at it in
> detail. Why should it not be possible to start a cluster with one node?
> In theory you should be able to do that, and then add nodes later?
The "nodes" means how many nodes could run with the clustered raid.
IOW, if nodes is set to 1, then we can't assemble the clustered raid in
node B after clustered raid is created in node A.
And we had provided below protection in md-cluster.c, so it doesn't make
sense to create clustered raid with "nodes = 1" since we can't use this raid
across cluster.
f (nodes < cinfo->slot_number) {
pr_err("md-cluster: Slot allotted(%d) is greater than
available slots(%d).",
cinfo->slot_number, nodes);
ret = -ERANGE;
goto err;
}
Regards,
Guoqing
^ permalink raw reply
* Re: I was dump, I need help.
From: Patrice @ 2016-05-05 10:00 UTC (permalink / raw)
To: Robin Hill; +Cc: linux-raid
In-Reply-To: <20160502124113.GA1973@cthulhu.home.robinhill.me.uk>
Hi robin,
luckily someone managed to repair the RAID.
Now all works fine! :-)
I think he does it like you guessed it.
Here is his way:
Because the disks of NAS data volume did not synced, so it cannot be
assemble, I used command to force it to be started.
$ start_raids
mdadm: /dev/md/0 has been started with 4 drives.
mdadm: /dev/md/1 has been started with 4 drives.
mdadm: NOT forcing event count in /dev/sda3(0) from 266 up to 273
mdadm: You can use --really-force to do that (DANGEROUS)
mdadm: failed to RUN_ARRAY /dev/md/data-0: Input/output error
mdadm: Not enough devices to start the array.
$ cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md1 : active raid6 sda2[0] sdc2[3] sdb2[2] sdd2[1]
1046528 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]
md0 : active raid1 sda1[4] sdd1[3] sdc1[2] sdb1[5]
4190208 blocks super 1.2 [4/4] [UUUU]
unused devices: <none>
$ mdadm -S /dev/md127
mdadm: error opening /dev/md127: No such file or directory
$ mdadm -A /dev/md127 /dev/sd[a-d]3 --really-force
mdadm: forcing event count in /dev/sda3(0) from 266 upto 273
mdadm: forcing event count in /dev/sdb3(1) from 266 upto 273
mdadm: /dev/md127 has been started with 4 drives.
Then I can mount data volume and access shares.
root@4FH15855000E3:/# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 3.7G 1.1G 2.5G 30% /
tmpfs 10M 0 10M 0% /dev
/dev/md127 11T 882G 11T 8% /data
Thank you for your time and your help!
Best regards,
Patrice
On 02.05.2016 14:41, Robin Hill wrote:
> On Sun May 01, 2016 at 04:28:30PM +0200, Patrice wrote:
>
>> Hi Robin,
>>
>> thank you for your reply.
>> Ok, I try not to panic but in my opinion that sounds bad. It seems to me
>> like a mess.
>> Why is there a RAID 1 und 6? I need a RAID 5.
>>
> It looks like you have a RAID1, a RAID6 and a RAID5. I'd guess that the
> RAID1 and RAID6 store the OS for the NAS system, and the RAID5 is the
> data.
>
>> > are there any others which should be being
>> > assembled into another array?
>>
>> There are no others. At least there should be only one partition on each
>> HDD. I didn`t do partitioning.
>>
>>
>> fdisk -l output:
>> ------------------
>>
>> Disk /dev/sda: 4000.8 GB, 4000787030016 bytes
>> 256 heads, 63 sectors/track, 484501 cylinders, total 7814037168 sectors
>> Units = sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 4096 bytes
>> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
>> Disk identifier: 0x00000000
>>
>> Device Boot Start End Blocks Id System
>> /dev/sda1 1 4294967295 2147483647+ ee GPT
>> Partition 1 does not start on physical sector boundary.
>>
>> WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util
>> fdisk doesn't support GPT. Use GNU Parted.
>>
>>
>> Disk /dev/sdb: 4000.8 GB, 4000787030016 bytes
>> 256 heads, 63 sectors/track, 484501 cylinders, total 7814037168 sectors
>> Units = sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 4096 bytes
>> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
>> Disk identifier: 0x00000000
>>
>> Device Boot Start End Blocks Id System
>> /dev/sdb1 1 4294967295 2147483647+ ee GPT
>> Partition 1 does not start on physical sector boundary.
>>
>> WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util
>> fdisk doesn't support GPT. Use GNU Parted.
>>
>>
>> Disk /dev/sdc: 4000.8 GB, 4000787030016 bytes
>> 256 heads, 63 sectors/track, 484501 cylinders, total 7814037168 sectors
>> Units = sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 4096 bytes
>> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
>> Disk identifier: 0x00000000
>>
>> Device Boot Start End Blocks Id System
>> /dev/sdc1 1 4294967295 2147483647+ ee GPT
>> Partition 1 does not start on physical sector boundary.
>>
>> WARNING: GPT (GUID Partition Table) detected on '/dev/sdd'! The util
>> fdisk doesn't support GPT. Use GNU Parted.
>>
>>
>> Disk /dev/sdd: 4000.8 GB, 4000787030016 bytes
>> 256 heads, 63 sectors/track, 484501 cylinders, total 7814037168 sectors
>> Units = sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 4096 bytes
>> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
>> Disk identifier: 0x00000000
>>
>> Device Boot Start End Blocks Id System
>> /dev/sdd1 1 4294967295 2147483647+ ee GPT
>> Partition 1 does not start on physical sector boundary.
>>
>> -------------------------------------------------------------------------
>>
> Okay, so there's 4 4TB drives - they're using GPT partitions so fdisk
> doesn't report anything useful here.
>
>> mdadm -E /dev/sd* output:
>> --------------------------
>>
>> /dev/sda3:
>> Magic : a92b4efc
>> Version : 1.2
>> Feature Map : 0x0
>> Array UUID : 632ff5fd:65342524:9c9798d7:80e47e94
>> Name : 119c1bce:data-0 (local to host 119c1bce)
>> Creation Time : Sun Apr 3 06:27:49 2016
>> Raid Level : raid5
>> Raid Devices : 4
>>
>> Avail Dev Size : 7804333680 (3721.40 GiB 3995.82 GB)
>> Array Size : 11706500352 (11164.19 GiB 11987.46 GB)
>> Used Dev Size : 7804333568 (3721.40 GiB 3995.82 GB)
>> Data Offset : 262144 sectors
>> Super Offset : 8 sectors
>> Unused Space : before=262056 sectors, after=112 sectors
>> State : clean
>> Device UUID : 38adc372:3e0eba36:0f819758:950a0411
>>
>> Update Time : Sat Apr 30 23:03:32 2016
>> Bad Block Log : 512 entries available at offset 72 sectors
>> Checksum : d7f5b303 - correct
>> Events : 266
>>
>> Layout : left-symmetric
>> Chunk Size : 64K
>>
>> Device Role : Active device 0
>> Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
>>
>>
>> /dev/sdb3:
>> Magic : a92b4efc
>> Version : 1.2
>> Feature Map : 0x0
>> Array UUID : 632ff5fd:65342524:9c9798d7:80e47e94
>> Name : 119c1bce:data-0 (local to host 119c1bce)
>> Creation Time : Sun Apr 3 06:27:49 2016
>> Raid Level : raid5
>> Raid Devices : 4
>>
>> Avail Dev Size : 7804333680 (3721.40 GiB 3995.82 GB)
>> Array Size : 11706500352 (11164.19 GiB 11987.46 GB)
>> Used Dev Size : 7804333568 (3721.40 GiB 3995.82 GB)
>> Data Offset : 262144 sectors
>> Super Offset : 8 sectors
>> Unused Space : before=262056 sectors, after=112 sectors
>> State : clean
>> Device UUID : 655ee144:43c43771:0d8a6157:9b556584
>>
>> Update Time : Sat Apr 30 23:03:32 2016
>> Bad Block Log : 512 entries available at offset 72 sectors
>> Checksum : 56bc6e3b - correct
>> Events : 266
>>
>> Layout : left-symmetric
>> Chunk Size : 64K
>>
>> Device Role : Active device 1
>> Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
>>
>>
>> /dev/sdc3:
>> Magic : a92b4efc
>> Version : 1.2
>> Feature Map : 0x0
>> Array UUID : 632ff5fd:65342524:9c9798d7:80e47e94
>> Name : 119c1bce:data-0 (local to host 119c1bce)
>> Creation Time : Sun Apr 3 06:27:49 2016
>> Raid Level : raid5
>> Raid Devices : 4
>>
>> Avail Dev Size : 7804333680 (3721.40 GiB 3995.82 GB)
>> Array Size : 11706500352 (11164.19 GiB 11987.46 GB)
>> Used Dev Size : 7804333568 (3721.40 GiB 3995.82 GB)
>> Data Offset : 262144 sectors
>> Super Offset : 8 sectors
>> Unused Space : before=262056 sectors, after=112 sectors
>> State : clean
>> Device UUID : d066d1aa:ffd1e432:e9ecdd9d:08540efa
>>
>> Update Time : Sat Apr 30 23:17:27 2016
>> Bad Block Log : 512 entries available at offset 72 sectors
>> Checksum : 3a7ce8f6 - correct
>> Events : 273
>>
>> Layout : left-symmetric
>> Chunk Size : 64K
>>
>> Device Role : Active device 2
>> Array State : ..AA ('A' == active, '.' == missing, 'R' == replacing)
>>
>>
>> /dev/sdd3:
>> Magic : a92b4efc
>> Version : 1.2
>> Feature Map : 0x0
>> Array UUID : 632ff5fd:65342524:9c9798d7:80e47e94
>> Name : 119c1bce:data-0 (local to host 119c1bce)
>> Creation Time : Sun Apr 3 06:27:49 2016
>> Raid Level : raid5
>> Raid Devices : 4
>>
>> Avail Dev Size : 7804333680 (3721.40 GiB 3995.82 GB)
>> Array Size : 11706500352 (11164.19 GiB 11987.46 GB)
>> Used Dev Size : 7804333568 (3721.40 GiB 3995.82 GB)
>> Data Offset : 262144 sectors
>> Super Offset : 8 sectors
>> Unused Space : before=262056 sectors, after=112 sectors
>> State : clean
>> Device UUID : b8a43a56:2f833e72:7dd9f166:6f80b5a2
>>
>> Update Time : Sat Apr 30 23:17:27 2016
>> Bad Block Log : 512 entries available at offset 72 sectors
>> Checksum : 96faf109 - correct
>> Events : 273
>>
>> Layout : left-symmetric
>> Chunk Size : 64K
>>
>> Device Role : Active device 3
>> Array State : ..AA ('A' == active, '.' == missing, 'R' == replacing)
>>
> I've removed the info for the first two partitions on each disk as those
> arrays are assembling fine. The third partitions look to contain your
> data array - the events for sda3 and sdb3 match at 266, and sdc3 and
> sdd3 are on 273 (and show sda3 & sdb3 missing). A forced assembly should
> work without any issues here - the array name would look to be
> /dev/md/data-0, so:
> mdadm -Af /dev/md/data-0 /dev/sd[abcd]3
>
> That should assemble the array from 3 of the disks (probably sda3, sdc3
> and sdd3) - you'll then need to add the other one back in and allow the
> rebuild to complete. You should also do a check on the filesystem to
> ensure there's no corruption.
>
> Cheers,
> Robin
^ permalink raw reply
* Re: [PATCH 0/2] Check node nums for cluster raid
From: Jes Sorensen @ 2016-05-05 20:28 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: linux-raid
In-Reply-To: <572AB7EF.6090403@suse.com>
Guoqing Jiang <gqjiang@suse.com> writes:
> Hi Jes,
>
> On 05/04/2016 11:12 AM, Jes Sorensen wrote:
>> Guoqing Jiang <gqjiang@suse.com> writes:
>>> For cluster raid, we do need at least two nodes for it,
>>> the two patches add the checks before create and change
>>> bitmap.
>>>
>>> Thanks,
>>> Guoqing
>>>
>>> Guoqing Jiang (2):
>>> Create: check the node nums when create clustered raid
>>> super1: don't update node nums if it is not more than 1
>>>
>>> Create.c | 7 ++++++-
>>> super1.c | 5 +++++
>>> 2 files changed, 11 insertions(+), 1 deletion(-)
>> Hi Guoqing,
>>
>> I am a little confused on this one - albeit I haven't looked at it in
>> detail. Why should it not be possible to start a cluster with one node?
>> In theory you should be able to do that, and then add nodes later?
>
> The "nodes" means how many nodes could run with the clustered raid.
> IOW, if nodes is set to 1, then we can't assemble the clustered raid in
> node B after clustered raid is created in node A.
>
> And we had provided below protection in md-cluster.c, so it doesn't make
> sense to create clustered raid with "nodes = 1" since we can't use this raid
> across cluster.
>
> f (nodes < cinfo->slot_number) {
> pr_err("md-cluster: Slot allotted(%d) is greater than
> available slots(%d).",
> cinfo->slot_number, nodes);
> ret = -ERANGE;
> goto err;
> }
OK, thanks for the explanation! I'll apply these shortly.
Cheers,
Jes
^ permalink raw reply
* problems with lots of arrays
From: Mike Lovell @ 2016-05-05 23:24 UTC (permalink / raw)
To: linux-raid
we have a number of systems that have a large number of software
arrays running. its in the couple hundred range. we have been using a
custom built kernel based on 3.4 but are wanting to update to a
mainline kernel and have been experimenting with 4.4. the systems are
running recent centos 6 releases but we have been downgrading the
mdadm version from 3.3.2 in 6.7 to a custom build 3.2.6. we installed
the downgraded version due to a problem with array numbering. i
emailed the list a while ago explaining the issue and submitting a
patch to fix [1]. i never heard anything back and since we had a
simple fix i didn't follow up on it.
unfortunately, when testing the 3.2.6 mdadm with linux kernel 4.4
wasn't working. mdadm and the kernel would complain about the devices
not having a valid v1.2 superblock and not start the array. testing
with 3.3.2 from the current centos repos worked. i'd like to update
but we still have the issue with lots of arrays mentioned previously.
i spent some time checking to make sure that my patch rebases against
master properly (and it does) but during testing i was unable to
create an array with number larger than /dev/md511 when using the 4.4
kernel we were testing as well as the 4.2 kernel i had on another test
box. creating one larger than 511 on a system with a 3.16 kernel
worked. it looks like something broke between kernel 3.16 and 4.2 that
limited the number of arrays to 512 (/dev/md0 to /dev/md511). this was
a problem regardless of mdadm version and i haven't yet done much
digging into the problem.
there are a couple things that could potentially be done. the easiest,
would be to just modify find_free_devnm() in mdopen.c from wrapping to
(1<<20)-1 and instead have it wrap around to (1<<9))-1. this would
limit mdadm to 512 auto-generated array numbers. i'm guessing this
would be sufficient for the vast majority of cases and would solve the
problem i'm facing at work. the next option would be to apply the
patch in my previous email and then figuring out why the newer
versions of the kernel don't support more than 512 arrays. this would
take more work but probably the better long term approach.
what do you all think?
thanks
mike
[1] http://marc.info/?l=linux-raid&m=142387809409798&w=2
^ permalink raw reply
* Re: problems with lots of arrays
From: NeilBrown @ 2016-05-06 6:43 UTC (permalink / raw)
To: Mike Lovell, linux-raid
In-Reply-To: <CAK9wOaB+Cic3nR5kzB3n=nVpbRtfo8+Qr9j_VNM3hh5tJRw6YA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3581 bytes --]
On Fri, May 06 2016, Mike Lovell wrote:
> we have a number of systems that have a large number of software
> arrays running. its in the couple hundred range. we have been using a
> custom built kernel based on 3.4 but are wanting to update to a
> mainline kernel and have been experimenting with 4.4. the systems are
> running recent centos 6 releases but we have been downgrading the
> mdadm version from 3.3.2 in 6.7 to a custom build 3.2.6. we installed
> the downgraded version due to a problem with array numbering. i
> emailed the list a while ago explaining the issue and submitting a
> patch to fix [1]. i never heard anything back and since we had a
> simple fix i didn't follow up on it.
>
> unfortunately, when testing the 3.2.6 mdadm with linux kernel 4.4
> wasn't working. mdadm and the kernel would complain about the devices
> not having a valid v1.2 superblock and not start the array. testing
> with 3.3.2 from the current centos repos worked. i'd like to update
> but we still have the issue with lots of arrays mentioned previously.
>
> i spent some time checking to make sure that my patch rebases against
> master properly (and it does) but during testing i was unable to
> create an array with number larger than /dev/md511 when using the 4.4
> kernel we were testing as well as the 4.2 kernel i had on another test
> box. creating one larger than 511 on a system with a 3.16 kernel
> worked. it looks like something broke between kernel 3.16 and 4.2 that
> limited the number of arrays to 512 (/dev/md0 to /dev/md511). this was
> a problem regardless of mdadm version and i haven't yet done much
> digging into the problem.
>
> there are a couple things that could potentially be done. the easiest,
> would be to just modify find_free_devnm() in mdopen.c from wrapping to
> (1<<20)-1 and instead have it wrap around to (1<<9))-1. this would
> limit mdadm to 512 auto-generated array numbers. i'm guessing this
> would be sufficient for the vast majority of cases and would solve the
> problem i'm facing at work. the next option would be to apply the
> patch in my previous email and then figuring out why the newer
> versions of the kernel don't support more than 512 arrays. this would
> take more work but probably the better long term approach.
>
I know why newer kernels don't seem to support more than 512 array.
Commit: af5628f05db6 ("md: disable probing for md devices 512 and over.")
You can easily use many more md devices by using a newish mdadm and
setting
CREATE names=yes
in /etc/mdadm.conf
You cannot use names like "md512" because that gets confusing, but any
name that isn't a string of digits is fine. e.g. create /dev/md/foo
and the array will be named "md_foo" in the kernel rather than "md127".
I guess this qualifies as a regression and regressions are bad.....
But I really wanted to be able to have arrays that didn't get magically
created simply because you open a file in /dev. That just leads to
races with udev.
The magic number "512" appears three times in the kernel.
/* find an unused unit number */
static int next_minor = 512;
and
blk_register_region(MKDEV(MD_MAJOR, 0), 512, THIS_MODULE,
md_probe, NULL, NULL);
and
blk_unregister_region(MKDEV(MD_MAJOR,0), 512);
A boot parameter which set that to something larger would probably be OK
and would solve your immediate problem.
But if you could transition to using named arrays instead of numbered
arrays - even if that are "/dev/md/X%d", that would be be good I think.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: problems with lots of arrays
From: Mike Lovell @ 2016-05-06 17:02 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <87k2j7vg8m.fsf@notabene.neil.brown.name>
On Fri, May 6, 2016 at 12:43 AM, NeilBrown <nfbrown@novell.com> wrote:
> I know why newer kernels don't seem to support more than 512 array.
>
> Commit: af5628f05db6 ("md: disable probing for md devices 512 and over.")
>
>
> You can easily use many more md devices by using a newish mdadm and
> setting
>
> CREATE names=yes
>
> in /etc/mdadm.conf
>
> You cannot use names like "md512" because that gets confusing, but any
> name that isn't a string of digits is fine. e.g. create /dev/md/foo
> and the array will be named "md_foo" in the kernel rather than "md127".
>
> I guess this qualifies as a regression and regressions are bad.....
> But I really wanted to be able to have arrays that didn't get magically
> created simply because you open a file in /dev. That just leads to
> races with udev.
>
> The magic number "512" appears three times in the kernel.
>
> /* find an unused unit number */
> static int next_minor = 512;
>
> and
>
> blk_register_region(MKDEV(MD_MAJOR, 0), 512, THIS_MODULE,
> md_probe, NULL, NULL);
> and
> blk_unregister_region(MKDEV(MD_MAJOR,0), 512);
>
> A boot parameter which set that to something larger would probably be OK
> and would solve your immediate problem.
>
> But if you could transition to using named arrays instead of numbered
> arrays - even if that are "/dev/md/X%d", that would be be good I think.
>
> NeilBrown
we actually do specify the name to mdadm --create and mdadm --assemble
and have a naming scheme from our own internal tools. the problem we
were running into was that mdadm would auto-generate a minor number
that was invalid but we also don't have "CREATE names=yes" in
mdadm.conf. i'll have to experiment with that one.
thanks
mike
^ permalink raw reply
* Re: problems with lots of arrays
From: Mike Lovell @ 2016-05-06 17:59 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <CAK9wOaDLu+edK5R=U61mTb3+OP2=QNotExsZzu2Sce-qLCVHcA@mail.gmail.com>
On Fri, May 6, 2016 at 11:02 AM, Mike Lovell <mike.lovell@endurance.com> wrote:
> On Fri, May 6, 2016 at 12:43 AM, NeilBrown <nfbrown@novell.com> wrote:
>> I know why newer kernels don't seem to support more than 512 array.
>>
>> Commit: af5628f05db6 ("md: disable probing for md devices 512 and over.")
>>
>>
>> You can easily use many more md devices by using a newish mdadm and
>> setting
>>
>> CREATE names=yes
>>
>> in /etc/mdadm.conf
>>
>> You cannot use names like "md512" because that gets confusing, but any
>> name that isn't a string of digits is fine. e.g. create /dev/md/foo
>> and the array will be named "md_foo" in the kernel rather than "md127".
>>
>> I guess this qualifies as a regression and regressions are bad.....
>> But I really wanted to be able to have arrays that didn't get magically
>> created simply because you open a file in /dev. That just leads to
>> races with udev.
>>
>> The magic number "512" appears three times in the kernel.
>>
>> /* find an unused unit number */
>> static int next_minor = 512;
>>
>> and
>>
>> blk_register_region(MKDEV(MD_MAJOR, 0), 512, THIS_MODULE,
>> md_probe, NULL, NULL);
>> and
>> blk_unregister_region(MKDEV(MD_MAJOR,0), 512);
>>
>> A boot parameter which set that to something larger would probably be OK
>> and would solve your immediate problem.
>>
>> But if you could transition to using named arrays instead of numbered
>> arrays - even if that are "/dev/md/X%d", that would be be good I think.
>>
>> NeilBrown
>
> we actually do specify the name to mdadm --create and mdadm --assemble
> and have a naming scheme from our own internal tools. the problem we
> were running into was that mdadm would auto-generate a minor number
> that was invalid but we also don't have "CREATE names=yes" in
> mdadm.conf. i'll have to experiment with that one.
i just tested with "CREATE names=yes" in /etc/mdadm.conf and using
some test names seems to work properly. the array was created using
the name and the kernel chose minor numbers starting at 512. i then
tried some of our management tools and things failed. it looks like
its having a problem with our naming scheme. its using names that are
a little over 30 characters with - and _ in them. are there supposed
to be any restrictions on the array name?
specifically, this is what happened from mdadm when trying. (names
changes to protect the innocent :) )
$ sudo mdadm -A /dev/md/test-volume_a-123456_123456 /dev/dm-1 /dev/dm-2
*** buffer overflow detected ***: mdadm terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f7e50f40567]
/lib64/libc.so.6(+0x100450)[0x7f7e50f3e450]
/lib64/libc.so.6(+0xff8a9)[0x7f7e50f3d8a9]
/lib64/libc.so.6(_IO_default_xsputn+0xc9)[0x7f7e50eb2639]
/lib64/libc.so.6(_IO_vfprintf+0x41c0)[0x7f7e50e86190]
/lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f7e50f3d94d]
/lib64/libc.so.6(__sprintf_chk+0x7f)[0x7f7e50f3d88f]
mdadm[0x43068e]
mdadm[0x417089]
mdadm[0x4058a4]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f7e50e5cd5d]
mdadm[0x402ca9]
======= Memory map: ========
00400000-0046d000 r-xp 00000000 09:00 16908296
/sbin/mdadm
0066d000-00674000 rw-p 0006d000 09:00 16908296
/sbin/mdadm
00674000-00687000 rw-p 00000000 00:00 0
00fbb000-00fdc000 rw-p 00000000 00:00 0 [heap]
7f7e50c28000-7f7e50c3e000 r-xp 00000000 09:00 18874642
/lib64/libgcc_s-4.4.7-20120601.so.1
7f7e50c3e000-7f7e50e3d000 ---p 00016000 09:00 18874642
/lib64/libgcc_s-4.4.7-20120601.so.1
7f7e50e3d000-7f7e50e3e000 rw-p 00015000 09:00 18874642
/lib64/libgcc_s-4.4.7-20120601.so.1
7f7e50e3e000-7f7e50fc8000 r-xp 00000000 09:00 18874440
/lib64/libc-2.12.so
7f7e50fc8000-7f7e511c8000 ---p 0018a000 09:00 18874440
/lib64/libc-2.12.so
7f7e511c8000-7f7e511cc000 r--p 0018a000 09:00 18874440
/lib64/libc-2.12.so
7f7e511cc000-7f7e511cd000 rw-p 0018e000 09:00 18874440
/lib64/libc-2.12.so
7f7e511cd000-7f7e511d2000 rw-p 00000000 00:00 0
7f7e511d2000-7f7e511f2000 r-xp 00000000 09:00 18874758
/lib64/ld-2.12.so
7f7e513e5000-7f7e513e8000 rw-p 00000000 00:00 0
7f7e513ee000-7f7e513f1000 rw-p 00000000 00:00 0
7f7e513f1000-7f7e513f2000 r--p 0001f000 09:00 18874758
/lib64/ld-2.12.so
7f7e513f2000-7f7e513f3000 rw-p 00020000 09:00 18874758
/lib64/ld-2.12.so
7f7e513f3000-7f7e513f4000 rw-p 00000000 00:00 0
7ffe90a1f000-7ffe90a40000 rw-p 00000000 00:00 0 [stack]
7ffe90ab1000-7ffe90ab3000 r--p 00000000 00:00 0 [vvar]
7ffe90ab3000-7ffe90ab5000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
this was with kernel 4.4.8 and mdadm 3.3.2-5.el6
thanks
mike
^ permalink raw reply
* Help! Qnap array crash - trying to recover arrays without OS and syslog
From: Christopher Jeffry Hamilton @ 2016-05-06 20:14 UTC (permalink / raw)
To: linux-raid
Hello community!
So, I'm decent with linux but want to tread carefully here as
soft-raid is not my strength. I'm also searching archives and
googling quite a bit to see if I can solve the problem, but would very
much appreciate any assistance provided from this list.
Setup: I have an older QNAP 809U-RP box which was showing a bad disk
in 1 of the 2 arrays (both RAID 5). The system was acting funny and I
could not log in so I "soft powered" off the device using the shutdown
button on the enclosure. Upon power-on it had lost its OS and asked
to "factory reset" or "initialize" --- it noted that "factory reset"
would preserve all data so that is what I chose (This was probably a
bad choice).
What happened was it re-wrote its own OS onto the disks (I believe it
uses the first partition across a few disks). I believe it left the
later partitions alone; however I also lost /var/log/messages and any
debugging ability in this process.
Here is what I have on that system:
RAID5 (WD 2TB Blacks) - sda, sdb, sdc, sdd, sdh
RAID5 (HGST 4TB) - sde, sdf, sdg
The bad drive should have been in the WD 2TB array. As was the "QNAP OS"
[/tmp] # uname -a
Linux NASC834B5 3.4.6 #1 SMP Fri Mar 11 10:54:42 CST 2016 x86_64 unknown
[/tmp] # mount
/proc on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw,size=64M)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/bus/usb type usbfs (rw)
/dev/sda4 on /mnt/ext type ext3 (rw)
/dev/md9 on /mnt/HDA_ROOT type ext3 (rw,data=ordered)
tmpfs on /mnt/rf/nd type tmpfs (rw,size=1m)
[/tmp] # dmesg |grep sd
[ 64.469381] EXT3-fs (sdg1): mounted filesystem with writeback data mode
[ 64.529845] EXT3-fs (sdh1): mounted filesystem with writeback data mode
[ 64.964243] md: bind<sda1>
[ 64.968061] md: bind<sdc1>
[ 64.971892] md: bind<sdg1>
[ 64.975727] md: bind<sdd1>
[ 64.979477] md: bind<sdh1>
[ 64.983185] md: bind<sde1>
[ 64.986840] md: bind<sdf1>
[ 64.990480] md: bind<sdb1>
[ 67.399806] md: bind<sda4>
[ 110.406857] ufsd: module license 'Commercial product' taints kernel.
[ 110.415588] ufsd: driver (lke_9.2.0 QNAP,
build_host("BuildServer37"), acl, ioctl, bdi, sd2(0), fua, bz, rsrc)
loaded at ffffffffa0152000
[ 234.350035] md: bind<sda2>
[ 249.073911] md: bind<sda3>
[ 250.084610] md: unbind<sda3>
[ 250.092028] md: export_rdev(sda3)
[ 250.116276] md: bind<sda3>
[ 250.120499] md/raid:md0: device sda3 operational as raid disk 0
[ 250.146663] disk 0, o:1, dev:sda3
[ 251.180995] md: unbind<sda3>
[ 251.187031] md: export_rdev(sda3)
[ 256.544983] md: bind<sda3>
[ 256.548597] md/raid:md0: device sda3 operational as raid disk 0
[ 256.573794] disk 0, o:1, dev:sda3
[ 256.607064] md: unbind<sda3>
[ 256.613034] md: export_rdev(sda3)
[ 261.777279] md: bind<sda3>
[ 261.781028] md/raid:md0: device sda3 operational as raid disk 0
[ 261.805371] disk 0, o:1, dev:sda3
[ 261.847186] md: unbind<sda3>
[ 261.853028] md: export_rdev(sda3)
[/tmp] # mdadm --examine /dev/sd[abcdefghi][1234] >raid.status2
mdadm: No md superblock detected on /dev/sda4.
mdadm: cannot open /dev/sdb2: No such device or address
mdadm: cannot open /dev/sdb3: No such device or address
mdadm: cannot open /dev/sdb4: No such device or address
mdadm: cannot open /dev/sdc2: No such device or address
mdadm: cannot open /dev/sdc3: No such device or address
mdadm: cannot open /dev/sdc4: No such device or address
mdadm: cannot open /dev/sdd2: No such device or address
mdadm: cannot open /dev/sdd3: No such device or address
mdadm: cannot open /dev/sdd4: No such device or address
mdadm: cannot open /dev/sde2: No such device or address
mdadm: cannot open /dev/sde3: No such device or address
mdadm: cannot open /dev/sde4: No such device or address
mdadm: cannot open /dev/sdf2: No such device or address
mdadm: cannot open /dev/sdf3: No such device or address
mdadm: cannot open /dev/sdf4: No such device or address
mdadm: cannot open /dev/sdg2: No such device or address
mdadm: cannot open /dev/sdg3: No such device or address
mdadm: cannot open /dev/sdg4: No such device or address
mdadm: cannot open /dev/sdh2: No such device or address
mdadm: cannot open /dev/sdh3: No such device or address
mdadm: cannot open /dev/sdh4: No such device or address
mdadm: cannot open /dev/sdi1: No such device or address
mdadm: cannot open /dev/sdi2: No such device or address
mdadm: cannot open /dev/sdi3: No such device or address
mdadm: cannot open /dev/sdi4: No such device or address
[/tmp] # cat raid.status2
/dev/sda1:
Magic : a92b4efc
Version : 00.90.00
UUID : 48ad1c97:9f0a7c9f:d8b3b3c6:021a9414
Creation Time : Fri Apr 6 20:36:20 2012
Raid Level : raid1
Used Dev Size : 530048 (517.71 MiB 542.77 MB)
Array Size : 530048 (517.71 MiB 542.77 MB)
Raid Devices : 8
Total Devices : 8
Preferred Minor : 9
>
Update Time : Fri May 6 19:13:05 2016
State : clean
Internal Bitmap : present
Active Devices : 8
Working Devices : 8
Failed Devices : 0
Spare Devices : 0
Checksum : 132ffeb0 - correct
Events : 0.6637531
>
>
Number Major Minor RaidDevice State
this 1 8 1 1 active sync /dev/sda1
>
0 0 8 17 0 active sync /dev/sdb1
1 1 8 1 1 active sync /dev/sda1
2 2 8 33 2 active sync /dev/sdc1
3 3 8 97 3 active sync /dev/sdg1
4 4 8 49 4 active sync /dev/sdd1
5 5 8 113 5 active sync /dev/sdh1
6 6 8 65 6 active sync /dev/sde1
7 7 8 81 7 active sync /dev/sdf1
/dev/sda2:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 0f2dee7f:5513f0fe:37d369f2:6344ed21
Name : 8
Creation Time : Thu May 5 20:53:18 2016
Raid Level : raid1
Raid Devices : 2
>
Used Dev Size : 1060256 (517.79 MiB 542.85 MB)
Array Size : 1060256 (517.79 MiB 542.85 MB)
Super Offset : 1060264 sectors
State : clean
Device UUID : 2c5feba8:aff78b27:431543f5:aa6655de
>
Update Time : Thu May 5 20:53:20 2016
Checksum : 8e374d11 - correct
Events : 5
>
>
Array Slot : 0 (0, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed, failed, failed, failed, failed, failed, failed, failed,
failed)
Array State : U_ 383 failed
/dev/sda3:
Magic : a92b4efc
Version : 00.90.00
UUID : 4566ad78:44a12cc5:3e572f10:1012131f
Creation Time : Sun Jul 10 14:27:42 2011
Raid Level : raid5
Used Dev Size : 1951945600 (1861.52 GiB 1998.79 GB)
Array Size : 7807782400 (7446.08 GiB 7995.17 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 0
>
Update Time : Thu May 5 21:03:34 2016
State : clean
Internal Bitmap : present
Active Devices : 5
Working Devices : 5
Failed Devices : 0
Spare Devices : 0
Checksum : 9d580050 - correct
Events : 0.17725281
>
Layout : left-symmetric
Chunk Size : 64K
>
Number Major Minor RaidDevice State
this 0 8 3 0 active sync /dev/sda3
>
0 0 8 3 0 active sync /dev/sda3
1 1 8 19 1 active sync /dev/sdb3
2 2 8 35 2 active sync /dev/sdc3
3 3 8 51 3 active sync /dev/sdd3
4 4 8 115 4 active sync /dev/sdh3
/dev/sdb1:
Magic : a92b4efc
Version : 00.90.00
UUID : 48ad1c97:9f0a7c9f:d8b3b3c6:021a9414
Creation Time : Fri Apr 6 20:36:20 2012
Raid Level : raid1
Used Dev Size : 530048 (517.71 MiB 542.77 MB)
Array Size : 530048 (517.71 MiB 542.77 MB)
Raid Devices : 8
Total Devices : 8
Preferred Minor : 9
>
Update Time : Fri May 6 19:13:05 2016
State : clean
Internal Bitmap : present
Active Devices : 8
Working Devices : 8
Failed Devices : 0
Spare Devices : 0
Checksum : 132ffebe - correct
Events : 0.6637531
>
>
Number Major Minor RaidDevice State
this 0 8 17 0 active sync /dev/sdb1
>
0 0 8 17 0 active sync /dev/sdb1
1 1 8 1 1 active sync /dev/sda1
2 2 8 33 2 active sync /dev/sdc1
3 3 8 97 3 active sync /dev/sdg1
4 4 8 49 4 active sync /dev/sdd1
5 5 8 113 5 active sync /dev/sdh1
6 6 8 65 6 active sync /dev/sde1
7 7 8 81 7 active sync /dev/sdf1
/dev/sdc1:
Magic : a92b4efc
Version : 00.90.00
UUID : 48ad1c97:9f0a7c9f:d8b3b3c6:021a9414
Creation Time : Fri Apr 6 20:36:20 2012
Raid Level : raid1
Used Dev Size : 530048 (517.71 MiB 542.77 MB)
Array Size : 530048 (517.71 MiB 542.77 MB)
Raid Devices : 8
Total Devices : 8
Preferred Minor : 9
>
Update Time : Fri May 6 19:13:05 2016
State : clean
Internal Bitmap : present
Active Devices : 8
Working Devices : 8
Failed Devices : 0
Spare Devices : 0
Checksum : 132ffed2 - correct
Events : 0.6637531
>
>
Number Major Minor RaidDevice State
this 2 8 33 2 active sync /dev/sdc1
>
0 0 8 17 0 active sync /dev/sdb1
1 1 8 1 1 active sync /dev/sda1
2 2 8 33 2 active sync /dev/sdc1
3 3 8 97 3 active sync /dev/sdg1
4 4 8 49 4 active sync /dev/sdd1
5 5 8 113 5 active sync /dev/sdh1
6 6 8 65 6 active sync /dev/sde1
7 7 8 81 7 active sync /dev/sdf1
/dev/sdd1:
Magic : a92b4efc
Version : 00.90.00
UUID : 48ad1c97:9f0a7c9f:d8b3b3c6:021a9414
Creation Time : Fri Apr 6 20:36:20 2012
Raid Level : raid1
Used Dev Size : 530048 (517.71 MiB 542.77 MB)
Array Size : 530048 (517.71 MiB 542.77 MB)
Raid Devices : 8
Total Devices : 8
Preferred Minor : 9
>
Update Time : Fri May 6 19:13:05 2016
State : clean
Internal Bitmap : present
Active Devices : 8
Working Devices : 8
Failed Devices : 0
Spare Devices : 0
Checksum : 132ffee6 - correct
Events : 0.6637531
>
>
Number Major Minor RaidDevice State
this 4 8 49 4 active sync /dev/sdd1
>
0 0 8 17 0 active sync /dev/sdb1
1 1 8 1 1 active sync /dev/sda1
2 2 8 33 2 active sync /dev/sdc1
3 3 8 97 3 active sync /dev/sdg1
4 4 8 49 4 active sync /dev/sdd1
5 5 8 113 5 active sync /dev/sdh1
6 6 8 65 6 active sync /dev/sde1
7 7 8 81 7 active sync /dev/sdf1
/dev/sde1:
Magic : a92b4efc
Version : 00.90.00
UUID : 48ad1c97:9f0a7c9f:d8b3b3c6:021a9414
Creation Time : Fri Apr 6 20:36:20 2012
Raid Level : raid1
Used Dev Size : 530048 (517.71 MiB 542.77 MB)
Array Size : 530048 (517.71 MiB 542.77 MB)
Raid Devices : 8
Total Devices : 8
Preferred Minor : 9
>
Update Time : Fri May 6 19:13:05 2016
State : clean
Internal Bitmap : present
Active Devices : 8
Working Devices : 8
Failed Devices : 0
Spare Devices : 0
Checksum : 132ffefa - correct
Events : 0.6637531
>
>
Number Major Minor RaidDevice State
this 6 8 65 6 active sync /dev/sde1
>
0 0 8 17 0 active sync /dev/sdb1
1 1 8 1 1 active sync /dev/sda1
2 2 8 33 2 active sync /dev/sdc1
3 3 8 97 3 active sync /dev/sdg1
4 4 8 49 4 active sync /dev/sdd1
5 5 8 113 5 active sync /dev/sdh1
6 6 8 65 6 active sync /dev/sde1
7 7 8 81 7 active sync /dev/sdf1
/dev/sdf1:
Magic : a92b4efc
Version : 00.90.00
UUID : 48ad1c97:9f0a7c9f:d8b3b3c6:021a9414
Creation Time : Fri Apr 6 20:36:20 2012
Raid Level : raid1
Used Dev Size : 530048 (517.71 MiB 542.77 MB)
Array Size : 530048 (517.71 MiB 542.77 MB)
Raid Devices : 8
Total Devices : 8
Preferred Minor : 9
>
Update Time : Fri May 6 19:13:05 2016
State : clean
Internal Bitmap : present
Active Devices : 8
Working Devices : 8
Failed Devices : 0
Spare Devices : 0
Checksum : 132fff0c - correct
Events : 0.6637531
>
>
Number Major Minor RaidDevice State
this 7 8 81 7 active sync /dev/sdf1
>
0 0 8 17 0 active sync /dev/sdb1
1 1 8 1 1 active sync /dev/sda1
2 2 8 33 2 active sync /dev/sdc1
3 3 8 97 3 active sync /dev/sdg1
4 4 8 49 4 active sync /dev/sdd1
5 5 8 113 5 active sync /dev/sdh1
6 6 8 65 6 active sync /dev/sde1
7 7 8 81 7 active sync /dev/sdf1
/dev/sdg1:
Magic : a92b4efc
Version : 00.90.00
UUID : 48ad1c97:9f0a7c9f:d8b3b3c6:021a9414
Creation Time : Fri Apr 6 20:36:20 2012
Raid Level : raid1
Used Dev Size : 530048 (517.71 MiB 542.77 MB)
Array Size : 530048 (517.71 MiB 542.77 MB)
Raid Devices : 8
Total Devices : 8
Preferred Minor : 9
>
Update Time : Fri May 6 19:13:05 2016
State : clean
Internal Bitmap : present
Active Devices : 8
Working Devices : 8
Failed Devices : 0
Spare Devices : 0
Checksum : 132fff14 - correct
Events : 0.6637531
>
>
Number Major Minor RaidDevice State
this 3 8 97 3 active sync /dev/sdg1
>
0 0 8 17 0 active sync /dev/sdb1
1 1 8 1 1 active sync /dev/sda1
2 2 8 33 2 active sync /dev/sdc1
3 3 8 97 3 active sync /dev/sdg1
4 4 8 49 4 active sync /dev/sdd1
5 5 8 113 5 active sync /dev/sdh1
6 6 8 65 6 active sync /dev/sde1
7 7 8 81 7 active sync /dev/sdf1
/dev/sdh1:
Magic : a92b4efc
Version : 00.90.00
UUID : 48ad1c97:9f0a7c9f:d8b3b3c6:021a9414
Creation Time : Fri Apr 6 20:36:20 2012
Raid Level : raid1
Used Dev Size : 530048 (517.71 MiB 542.77 MB)
Array Size : 530048 (517.71 MiB 542.77 MB)
Raid Devices : 8
Total Devices : 8
Preferred Minor : 9
>
Update Time : Fri May 6 19:13:05 2016
State : clean
Internal Bitmap : present
Active Devices : 8
Working Devices : 8
Failed Devices : 0
Spare Devices : 0
Checksum : 132fff28 - correct
Events : 0.6637531
>
>
Number Major Minor RaidDevice State
this 5 8 113 5 active sync /dev/sdh1
>
0 0 8 17 0 active sync /dev/sdb1
1 1 8 1 1 active sync /dev/sda1
2 2 8 33 2 active sync /dev/sdc1
3 3 8 97 3 active sync /dev/sdg1
4 4 8 49 4 active sync /dev/sdd1
5 5 8 113 5 active sync /dev/sdh1
6 6 8 65 6 active sync /dev/sde1
7 7 8 81 7 active sync /dev/sdf1
Please let me know if there's something I else I should be looking at
to rebuild these two arrays - I hope recovering the HGST array will be
easy, and ideally I'd get both back. I have backups of 80% of the
data but not everything and figure this is a good opportunity to rack
my brain and learn more about linux RAID.
Thanks!
Ciao,
-Chris
T: +1.805.628.2126 | F: +1.610.395.6832 | E: chris@cjhx.net
^ permalink raw reply
* Re: problems with lots of arrays
From: NeilBrown @ 2016-05-06 23:13 UTC (permalink / raw)
To: Mike Lovell; +Cc: linux-raid
In-Reply-To: <CAK9wOaCN5gYtyTTf8n=5j=3oR6mZLAXN+PrREfzjKH9S1MgJiw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5496 bytes --]
On Sat, May 07 2016, Mike Lovell wrote:
> On Fri, May 6, 2016 at 11:02 AM, Mike Lovell <mike.lovell@endurance.com> wrote:
>> On Fri, May 6, 2016 at 12:43 AM, NeilBrown <nfbrown@novell.com> wrote:
>>> I know why newer kernels don't seem to support more than 512 array.
>>>
>>> Commit: af5628f05db6 ("md: disable probing for md devices 512 and over.")
>>>
>>>
>>> You can easily use many more md devices by using a newish mdadm and
>>> setting
>>>
>>> CREATE names=yes
>>>
>>> in /etc/mdadm.conf
>>>
>>> You cannot use names like "md512" because that gets confusing, but any
>>> name that isn't a string of digits is fine. e.g. create /dev/md/foo
>>> and the array will be named "md_foo" in the kernel rather than "md127".
>>>
>>> I guess this qualifies as a regression and regressions are bad.....
>>> But I really wanted to be able to have arrays that didn't get magically
>>> created simply because you open a file in /dev. That just leads to
>>> races with udev.
>>>
>>> The magic number "512" appears three times in the kernel.
>>>
>>> /* find an unused unit number */
>>> static int next_minor = 512;
>>>
>>> and
>>>
>>> blk_register_region(MKDEV(MD_MAJOR, 0), 512, THIS_MODULE,
>>> md_probe, NULL, NULL);
>>> and
>>> blk_unregister_region(MKDEV(MD_MAJOR,0), 512);
>>>
>>> A boot parameter which set that to something larger would probably be OK
>>> and would solve your immediate problem.
>>>
>>> But if you could transition to using named arrays instead of numbered
>>> arrays - even if that are "/dev/md/X%d", that would be be good I think.
>>>
>>> NeilBrown
>>
>> we actually do specify the name to mdadm --create and mdadm --assemble
>> and have a naming scheme from our own internal tools. the problem we
>> were running into was that mdadm would auto-generate a minor number
>> that was invalid but we also don't have "CREATE names=yes" in
>> mdadm.conf. i'll have to experiment with that one.
>
> i just tested with "CREATE names=yes" in /etc/mdadm.conf and using
> some test names seems to work properly. the array was created using
> the name and the kernel chose minor numbers starting at 512. i then
> tried some of our management tools and things failed. it looks like
> its having a problem with our naming scheme. its using names that are
> a little over 30 characters with - and _ in them. are there supposed
> to be any restrictions on the array name?
The kernel imposes a limit on the size of disk names:
#define DISK_NAME_LEN 32
1 byte is needed for the trailing '\0' and 3 for the leading "md_" so 28
are available for md device names.
That doesn't excuse mdadm for behaving so badly. There are quite a lot
of "sprintf"s in mdadm that should probably be "snprintf", and which
should possible have extra error checking.
I susect you are hitting something that sprintfs into
char devnm[32];
in create_mddev. That should definitely be larger.
NeilBrown
>
> specifically, this is what happened from mdadm when trying. (names
> changes to protect the innocent :) )
>
> $ sudo mdadm -A /dev/md/test-volume_a-123456_123456 /dev/dm-1 /dev/dm-2
> *** buffer overflow detected ***: mdadm terminated
> ======= Backtrace: =========
> /lib64/libc.so.6(__fortify_fail+0x37)[0x7f7e50f40567]
> /lib64/libc.so.6(+0x100450)[0x7f7e50f3e450]
> /lib64/libc.so.6(+0xff8a9)[0x7f7e50f3d8a9]
> /lib64/libc.so.6(_IO_default_xsputn+0xc9)[0x7f7e50eb2639]
> /lib64/libc.so.6(_IO_vfprintf+0x41c0)[0x7f7e50e86190]
> /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x7f7e50f3d94d]
> /lib64/libc.so.6(__sprintf_chk+0x7f)[0x7f7e50f3d88f]
> mdadm[0x43068e]
> mdadm[0x417089]
> mdadm[0x4058a4]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x7f7e50e5cd5d]
> mdadm[0x402ca9]
> ======= Memory map: ========
> 00400000-0046d000 r-xp 00000000 09:00 16908296
> /sbin/mdadm
> 0066d000-00674000 rw-p 0006d000 09:00 16908296
> /sbin/mdadm
> 00674000-00687000 rw-p 00000000 00:00 0
> 00fbb000-00fdc000 rw-p 00000000 00:00 0 [heap]
> 7f7e50c28000-7f7e50c3e000 r-xp 00000000 09:00 18874642
> /lib64/libgcc_s-4.4.7-20120601.so.1
> 7f7e50c3e000-7f7e50e3d000 ---p 00016000 09:00 18874642
> /lib64/libgcc_s-4.4.7-20120601.so.1
> 7f7e50e3d000-7f7e50e3e000 rw-p 00015000 09:00 18874642
> /lib64/libgcc_s-4.4.7-20120601.so.1
> 7f7e50e3e000-7f7e50fc8000 r-xp 00000000 09:00 18874440
> /lib64/libc-2.12.so
> 7f7e50fc8000-7f7e511c8000 ---p 0018a000 09:00 18874440
> /lib64/libc-2.12.so
> 7f7e511c8000-7f7e511cc000 r--p 0018a000 09:00 18874440
> /lib64/libc-2.12.so
> 7f7e511cc000-7f7e511cd000 rw-p 0018e000 09:00 18874440
> /lib64/libc-2.12.so
> 7f7e511cd000-7f7e511d2000 rw-p 00000000 00:00 0
> 7f7e511d2000-7f7e511f2000 r-xp 00000000 09:00 18874758
> /lib64/ld-2.12.so
> 7f7e513e5000-7f7e513e8000 rw-p 00000000 00:00 0
> 7f7e513ee000-7f7e513f1000 rw-p 00000000 00:00 0
> 7f7e513f1000-7f7e513f2000 r--p 0001f000 09:00 18874758
> /lib64/ld-2.12.so
> 7f7e513f2000-7f7e513f3000 rw-p 00020000 09:00 18874758
> /lib64/ld-2.12.so
> 7f7e513f3000-7f7e513f4000 rw-p 00000000 00:00 0
> 7ffe90a1f000-7ffe90a40000 rw-p 00000000 00:00 0 [stack]
> 7ffe90ab1000-7ffe90ab3000 r--p 00000000 00:00 0 [vvar]
> 7ffe90ab3000-7ffe90ab5000 r-xp 00000000 00:00 0 [vdso]
> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
> [vsyscall]
>
> this was with kernel 4.4.8 and mdadm 3.3.2-5.el6
>
> thanks
> mike
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* STRICTLY CONFIDENTIAL.
From: Acct. Dept. Bank Of China @ 2016-05-07 6:22 UTC (permalink / raw)
I have important transaction for you as next of kin to claim US$8.37m email me at zhu.shumin@yahoo.com.hk so i can send you more details
Thanks
Mr.Zhu Shumin
(Security Code 00746igit)
= = = = = = = = = = = = =
Move to inbox
^ permalink raw reply
* [PATCH] md: make the code more readable in the for-loop
From: Tiezhu Yang @ 2016-05-08 12:56 UTC (permalink / raw)
To: shli; +Cc: linux-raid, linux-kernel
This patch modifies raid1.c, raid10.c and raid5.c
to make the code more readable in the for-loop
and also fixes the scripts/checkpatch.pl error:
ERROR: trailing statements should be on next line.
Signed-off-by: Tiezhu Yang <kernelpatch@126.com>
---
drivers/md/raid1.c | 6 +++---
drivers/md/raid10.c | 2 +-
drivers/md/raid5.c | 59 +++++++++++++++++++++++++++--------------------------
3 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index a7f2b9c..760de56 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -109,7 +109,7 @@ static void * r1buf_pool_alloc(gfp_t gfp_flags, void *data)
/*
* Allocate bios : 1 for reading, n-1 for writing
*/
- for (j = pi->raid_disks ; j-- ; ) {
+ for (j = pi->raid_disks - 1; j >= 0; j--) {
bio = bio_kmalloc(gfp_flags, RESYNC_PAGES);
if (!bio)
goto out_free_bio;
@@ -166,7 +166,7 @@ static void r1buf_pool_free(void *__r1_bio, void *data)
struct r1bio *r1bio = __r1_bio;
for (i = 0; i < RESYNC_PAGES; i++)
- for (j = pi->raid_disks; j-- ;) {
+ for (j = pi->raid_disks - 1; j >= 0; j--) {
if (j == 0 ||
r1bio->bios[j]->bi_io_vec[i].bv_page !=
r1bio->bios[0]->bi_io_vec[i].bv_page)
@@ -1976,7 +1976,7 @@ static void process_checks(struct r1bio *r1_bio)
sbio->bi_error = 0;
if (!error) {
- for (j = vcnt; j-- ; ) {
+ for (j = vcnt - 1; j >= 0; j--) {
struct page *p, *s;
p = pbio->bi_io_vec[j].bv_page;
s = sbio->bi_io_vec[j].bv_page;
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 84e24e6..52f1e07 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -157,7 +157,7 @@ static void * r10buf_pool_alloc(gfp_t gfp_flags, void *data)
/*
* Allocate bios.
*/
- for (j = nalloc ; j-- ; ) {
+ for (j = nalloc - 1; j >= 0; j--) {
bio = bio_kmalloc(gfp_flags, RESYNC_PAGES);
if (!bio)
goto out_free_bio;
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 4d31b23..db978ab 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -536,7 +536,7 @@ retry:
stripe_set_idx(sector, conf, previous, sh);
sh->state = 0;
- for (i = sh->disks; i--; ) {
+ for (i = sh->disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
if (dev->toread || dev->read || dev->towrite || dev->written ||
@@ -890,7 +890,7 @@ static void ops_run_io(struct stripe_head *sh, struct stripe_head_state *s)
if (r5l_write_stripe(conf->log, sh) == 0)
return;
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
int rw;
int replace_only = 0;
struct bio *bi, *rbi;
@@ -1175,7 +1175,7 @@ static void ops_complete_biofill(void *stripe_head_ref)
(unsigned long long)sh->sector);
/* clear completed biofills */
- for (i = sh->disks; i--; ) {
+ for (i = sh->disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
/* acknowledge completion of a biofill operation */
@@ -1216,7 +1216,7 @@ static void ops_run_biofill(struct stripe_head *sh)
pr_debug("%s: stripe %llu\n", __func__,
(unsigned long long)sh->sector);
- for (i = sh->disks; i--; ) {
+ for (i = sh->disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
if (test_bit(R5_Wantfill, &dev->flags)) {
struct bio *rbi;
@@ -1307,7 +1307,7 @@ ops_run_compute5(struct stripe_head *sh, struct raid5_percpu *percpu)
__func__, (unsigned long long)sh->sector, target);
BUG_ON(!test_bit(R5_Wantcompute, &tgt->flags));
- for (i = disks; i--; )
+ for (i = disks - 1; i >= 0; i--)
if (i != target)
xor_srcs[count++] = sh->dev[i].page;
@@ -1407,7 +1407,7 @@ ops_run_compute6_1(struct stripe_head *sh, struct raid5_percpu *percpu)
} else {
/* Compute any data- or p-drive using XOR */
count = 0;
- for (i = disks; i-- ; ) {
+ for (i = disks - 1; i >= 0; i--) {
if (i == target || i == qd_idx)
continue;
blocks[count++] = sh->dev[i].page;
@@ -1492,7 +1492,7 @@ ops_run_compute6_2(struct stripe_head *sh, struct raid5_percpu *percpu)
data_target = target;
count = 0;
- for (i = disks; i-- ; ) {
+ for (i = disks - 1; i >= 0; i--) {
if (i == data_target || i == qd_idx)
continue;
blocks[count++] = sh->dev[i].page;
@@ -1554,7 +1554,7 @@ ops_run_prexor5(struct stripe_head *sh, struct raid5_percpu *percpu,
pr_debug("%s: stripe %llu\n", __func__,
(unsigned long long)sh->sector);
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
/* Only process blocks that are known to be uptodate */
if (test_bit(R5_Wantdrain, &dev->flags))
@@ -1598,7 +1598,7 @@ ops_run_biodrain(struct stripe_head *sh, struct dma_async_tx_descriptor *tx)
pr_debug("%s: stripe %llu\n", __func__,
(unsigned long long)sh->sector);
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct r5dev *dev;
struct bio *chosen;
@@ -1663,13 +1663,13 @@ static void ops_complete_reconstruct(void *stripe_head_ref)
pr_debug("%s: stripe %llu\n", __func__,
(unsigned long long)sh->sector);
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
fua |= test_bit(R5_WantFUA, &sh->dev[i].flags);
sync |= test_bit(R5_SyncIO, &sh->dev[i].flags);
discard |= test_bit(R5_Discard, &sh->dev[i].flags);
}
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
if (dev->written || i == pd_idx || i == qd_idx) {
@@ -1734,14 +1734,14 @@ again:
if (head_sh->reconstruct_state == reconstruct_state_prexor_drain_run) {
prexor = 1;
xor_dest = xor_srcs[count++] = sh->dev[pd_idx].page;
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
if (head_sh->dev[i].written)
xor_srcs[count++] = dev->page;
}
} else {
xor_dest = sh->dev[pd_idx].page;
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
if (i != pd_idx)
xor_srcs[count++] = dev->page;
@@ -1872,7 +1872,7 @@ static void ops_run_check_p(struct stripe_head *sh, struct raid5_percpu *percpu)
count = 0;
xor_dest = sh->dev[pd_idx].page;
xor_srcs[count++] = xor_dest;
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
if (i == pd_idx || i == qd_idx)
continue;
xor_srcs[count++] = sh->dev[i].page;
@@ -1970,7 +1970,7 @@ static void raid_run_ops(struct stripe_head *sh, unsigned long ops_request)
}
if (overlap_clear && !sh->batch_head)
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
if (test_and_clear_bit(R5_Overlap, &dev->flags))
wake_up(&sh->raid_conf->wait_for_overlap);
@@ -2861,7 +2861,7 @@ schedule_reconstruction(struct stripe_head *sh, struct stripe_head_state *s,
if (rcw) {
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
if (dev->towrite) {
@@ -2897,7 +2897,7 @@ schedule_reconstruction(struct stripe_head *sh, struct stripe_head_state *s,
(!(test_bit(R5_UPTODATE, &sh->dev[qd_idx].flags) ||
test_bit(R5_Wantcompute, &sh->dev[qd_idx].flags))));
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
if (i == pd_idx || i == qd_idx)
continue;
@@ -3072,7 +3072,7 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
{
int i;
BUG_ON(sh->batch_head);
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct bio *bi;
int bitmap_end = 0;
@@ -3386,7 +3386,7 @@ static int fetch_block(struct stripe_head *sh, struct stripe_head_state *s,
* do it if failed >= 2
*/
int other;
- for (other = disks; other--; ) {
+ for (other = disks - 1; other >= 0; other--) {
if (other == disk_idx)
continue;
if (!test_bit(R5_UPTODATE,
@@ -3433,7 +3433,7 @@ static void handle_stripe_fill(struct stripe_head *sh,
*/
if (!test_bit(STRIPE_COMPUTE_RUN, &sh->state) && !sh->check_state &&
!sh->reconstruct_state)
- for (i = disks; i--; )
+ for (i = disks - 1; i >= 0; i--)
if (fetch_block(sh, s, i, disks))
break;
set_bit(STRIPE_HANDLE, &sh->state);
@@ -3455,7 +3455,7 @@ static void handle_stripe_clean_event(struct r5conf *conf,
struct stripe_head *head_sh = sh;
bool do_endio = false;
- for (i = disks; i--; )
+ for (i = disks - 1; i >= 0; i--)
if (sh->dev[i].written) {
dev = &sh->dev[i];
if (!test_bit(R5_LOCKED, &dev->flags) &&
@@ -3573,7 +3573,8 @@ static void handle_stripe_dirtying(struct r5conf *conf,
pr_debug("force RCW rmw_level=%u, recovery_cp=%llu sh->sector=%llu\n",
conf->rmw_level, (unsigned long long)recovery_cp,
(unsigned long long)sh->sector);
- } else for (i = disks; i--; ) {
+ } else
+ for (i = disks - 1; i >= 0; i--) {
/* would I have to read this buffer for read_modify_write */
struct r5dev *dev = &sh->dev[i];
if ((dev->towrite || i == sh->pd_idx || i == sh->qd_idx) &&
@@ -3606,7 +3607,7 @@ static void handle_stripe_dirtying(struct r5conf *conf,
blk_add_trace_msg(conf->mddev->queue,
"raid5 rmw %llu %d",
(unsigned long long)sh->sector, rmw);
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
if ((dev->towrite || i == sh->pd_idx || i == sh->qd_idx) &&
!test_bit(R5_LOCKED, &dev->flags) &&
@@ -3631,7 +3632,7 @@ static void handle_stripe_dirtying(struct r5conf *conf,
/* want reconstruct write, but need to get some data */
int qread =0;
rcw = 0;
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
if (!test_bit(R5_OVERWRITE, &dev->flags) &&
i != sh->pd_idx && i != sh->qd_idx &&
@@ -4021,7 +4022,7 @@ static void analyse_stripe(struct stripe_head *sh, struct stripe_head_state *s)
/* Now to look around and see what can be done */
rcu_read_lock();
- for (i=disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct md_rdev *rdev;
sector_t first_bad;
int bad_sectors;
@@ -4391,7 +4392,7 @@ static void handle_stripe(struct stripe_head *sh)
BUG_ON(sh->qd_idx >= 0 &&
!test_bit(R5_UPTODATE, &sh->dev[sh->qd_idx].flags) &&
!test_bit(R5_Discard, &sh->dev[sh->qd_idx].flags));
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct r5dev *dev = &sh->dev[i];
if (test_bit(R5_LOCKED, &dev->flags) &&
(i == sh->pd_idx || i == sh->qd_idx ||
@@ -4539,7 +4540,7 @@ static void handle_stripe(struct stripe_head *sh)
sh->reconstruct_state = reconstruct_state_idle;
clear_bit(STRIPE_EXPANDING, &sh->state);
- for (i = conf->raid_disks; i--; ) {
+ for (i = conf->raid_disks - 1; i >= 0; i--) {
set_bit(R5_Wantwrite, &sh->dev[i].flags);
set_bit(R5_LOCKED, &sh->dev[i].flags);
s.locked++;
@@ -4579,7 +4580,7 @@ finish:
}
if (s.handle_bad_blocks)
- for (i = disks; i--; ) {
+ for (i = disks - 1; i >= 0; i--) {
struct md_rdev *rdev;
struct r5dev *dev = &sh->dev[i];
if (test_and_clear_bit(R5_WriteError, &dev->flags)) {
@@ -5486,7 +5487,7 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk
/* If any of this stripe is beyond the end of the old
* array, then we need to zero those blocks
*/
- for (j=sh->disks; j--;) {
+ for (j = sh->disks - 1; j >= 0; j--) {
sector_t s;
if (j == sh->pd_idx)
continue;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 1/3] md: set MD_CHANGE_PENDING in a atomic region
From: Shaohua Li @ 2016-05-08 22:12 UTC (permalink / raw)
To: Guoqing Jiang
Cc: neilb, linux-raid, Martin Kepplinger, Andrew Morton,
Denys Vlasenko, Sasha Levin, linux-kernel
In-Reply-To: <1462328535-22566-1-git-send-email-gqjiang@suse.com>
On Tue, May 03, 2016 at 10:22:13PM -0400, Guoqing Jiang wrote:
> Some code waits for a metadata update by:
>
> 1. flagging that it is needed (MD_CHANGE_DEVS or MD_CHANGE_CLEAN)
> 2. setting MD_CHANGE_PENDING and waking the management thread
> 3. waiting for MD_CHANGE_PENDING to be cleared
>
> If the first two are done without locking, the code in md_update_sb()
> which checks if it needs to repeat might test if an update is needed
> before step 1, then clear MD_CHANGE_PENDING after step 2, resulting
> in the wait returning early.
>
> So make sure all places that set MD_CHANGE_PENDING are atomicial, and
> bit_clear_unless (suggested by Neil) is introduced for the purpose.
Applied the 3, thanks!
^ permalink raw reply
* Re: Write to the degraded raid5 will trigger the call trace dump when skip_copy is enabled
From: Shaohua Li @ 2016-05-08 22:23 UTC (permalink / raw)
To: Joey Liao; +Cc: linux-raid
In-Reply-To: <CAHvN=intgqwK+Cw=sUb9wBSfF1wimGkbRBrxKOTtd_oZOH2M0w@mail.gmail.com>
On Wed, May 04, 2016 at 11:21:59AM +0800, Joey Liao wrote:
> Any suggestion for my question in the last e-mail?
> Should the WARN_ON() be exist or not?
>
> It is also related to skip_copy feature and I think it seems make
> sense that maybe R5_UPTODATE should not be set in this case.
> But I'm not really sure if my thinking is correct or not.
>
> However, if it does not have to exist, would you mind delete it as
> well or just modify the code?
>
>
>
> 2016-05-02 22:45 GMT+08:00 Joey Liao <joeyliao@qnap.com>:
> > Hi Shaohua,
> >
> > Many thanks for your reply.
> >
> > How about the following WARN_ON() in handle_stripe_clean_event()???
> >
> > if (test_and_clear_bit(R5_SkipCopy, &dev->flags)) {
> > WARN_ON(test_bit(R5_UPTODATE, &dev->flags));
> > }
> >
> > Sometimes it will be triggered as well but I can't find the exactly
> > way to reproduce it.
> > I would like to know if it is suitable to remove it as well or not.
This one isn't false alarm. If the dev->flags has R5_SkipCopy, we don't copy
data to stripe cache, so stripe cache shouldn't have R5_UPTODATE. So this
warning indicates a bug. If you can reproduce it, I'd be happy to debug.
Thanks,
Shaohua
^ permalink raw reply
* Re: [PATCH] md: make the code more readable in the for-loop
From: Shaohua Li @ 2016-05-08 23:03 UTC (permalink / raw)
To: Tiezhu Yang; +Cc: linux-raid, linux-kernel
In-Reply-To: <318e71b0.3d4e.1549071292b.Coremail.kernelpatch@126.com>
On Sun, May 08, 2016 at 08:56:55PM +0800, Tiezhu Yang wrote:
> This patch modifies raid1.c, raid10.c and raid5.c
> to make the code more readable in the for-loop
> and also fixes the scripts/checkpatch.pl error:
> ERROR: trailing statements should be on next line.
>
> Signed-off-by: Tiezhu Yang <kernelpatch@126.com>
> @@ -3573,7 +3573,8 @@ static void handle_stripe_dirtying(struct r5conf *conf,
> pr_debug("force RCW rmw_level=%u, recovery_cp=%llu sh->sector=%llu\n",
> conf->rmw_level, (unsigned long long)recovery_cp,
> (unsigned long long)sh->sector);
> - } else for (i = disks; i--; ) {
> + } else
> + for (i = disks - 1; i >= 0; i--) {
> /* would I have to read this buffer for read_modify_write */
> struct r5dev *dev = &sh->dev[i];
> if ((dev->towrite || i == sh->pd_idx || i == sh->qd_idx) &&
Applied. I move the for statement to be in a {} of else statement.
^ permalink raw reply
* Re: [PATCH] md: make the code more readable in the for-loop
From: Eyal Lebedinsky @ 2016-05-08 23:33 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <318e71b0.3d4e.1549071292b.Coremail.kernelpatch@126.com>
I do not see how this change makes it clearer. The original form is actually a very common and clear
scan an array in reverse order
Eyal
On 08/05/16 22:56, Tiezhu Yang wrote:
> This patch modifies raid1.c, raid10.c and raid5.c
> to make the code more readable in the for-loop
> and also fixes the scripts/checkpatch.pl error:
> ERROR: trailing statements should be on next line.
>
> Signed-off-by: Tiezhu Yang <kernelpatch@126.com>
> ---
> drivers/md/raid1.c | 6 +++---
> drivers/md/raid10.c | 2 +-
> drivers/md/raid5.c | 59 +++++++++++++++++++++++++++--------------------------
> 3 files changed, 34 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index a7f2b9c..760de56 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -109,7 +109,7 @@ static void * r1buf_pool_alloc(gfp_t gfp_flags, void *data)
> /*
> * Allocate bios : 1 for reading, n-1 for writing
> */
> - for (j = pi->raid_disks ; j-- ; ) {
> + for (j = pi->raid_disks - 1; j >= 0; j--) {
> bio = bio_kmalloc(gfp_flags, RESYNC_PAGES);
> if (!bio)
> goto out_free_bio;
> @@ -166,7 +166,7 @@ static void r1buf_pool_free(void *__r1_bio, void *data)
> struct r1bio *r1bio = __r1_bio;
>
> for (i = 0; i < RESYNC_PAGES; i++)
> - for (j = pi->raid_disks; j-- ;) {
> + for (j = pi->raid_disks - 1; j >= 0; j--) {
> if (j == 0 ||
> r1bio->bios[j]->bi_io_vec[i].bv_page !=
> r1bio->bios[0]->bi_io_vec[i].bv_page)
> @@ -1976,7 +1976,7 @@ static void process_checks(struct r1bio *r1_bio)
> sbio->bi_error = 0;
>
> if (!error) {
> - for (j = vcnt; j-- ; ) {
> + for (j = vcnt - 1; j >= 0; j--) {
> struct page *p, *s;
> p = pbio->bi_io_vec[j].bv_page;
> s = sbio->bi_io_vec[j].bv_page;
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index 84e24e6..52f1e07 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -157,7 +157,7 @@ static void * r10buf_pool_alloc(gfp_t gfp_flags, void *data)
> /*
> * Allocate bios.
> */
> - for (j = nalloc ; j-- ; ) {
> + for (j = nalloc - 1; j >= 0; j--) {
> bio = bio_kmalloc(gfp_flags, RESYNC_PAGES);
> if (!bio)
> goto out_free_bio;
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 4d31b23..db978ab 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -536,7 +536,7 @@ retry:
> stripe_set_idx(sector, conf, previous, sh);
> sh->state = 0;
>
> - for (i = sh->disks; i--; ) {
> + for (i = sh->disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
>
> if (dev->toread || dev->read || dev->towrite || dev->written ||
> @@ -890,7 +890,7 @@ static void ops_run_io(struct stripe_head *sh, struct stripe_head_state *s)
>
> if (r5l_write_stripe(conf->log, sh) == 0)
> return;
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> int rw;
> int replace_only = 0;
> struct bio *bi, *rbi;
> @@ -1175,7 +1175,7 @@ static void ops_complete_biofill(void *stripe_head_ref)
> (unsigned long long)sh->sector);
>
> /* clear completed biofills */
> - for (i = sh->disks; i--; ) {
> + for (i = sh->disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
>
> /* acknowledge completion of a biofill operation */
> @@ -1216,7 +1216,7 @@ static void ops_run_biofill(struct stripe_head *sh)
> pr_debug("%s: stripe %llu\n", __func__,
> (unsigned long long)sh->sector);
>
> - for (i = sh->disks; i--; ) {
> + for (i = sh->disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
> if (test_bit(R5_Wantfill, &dev->flags)) {
> struct bio *rbi;
> @@ -1307,7 +1307,7 @@ ops_run_compute5(struct stripe_head *sh, struct raid5_percpu *percpu)
> __func__, (unsigned long long)sh->sector, target);
> BUG_ON(!test_bit(R5_Wantcompute, &tgt->flags));
>
> - for (i = disks; i--; )
> + for (i = disks - 1; i >= 0; i--)
> if (i != target)
> xor_srcs[count++] = sh->dev[i].page;
>
> @@ -1407,7 +1407,7 @@ ops_run_compute6_1(struct stripe_head *sh, struct raid5_percpu *percpu)
> } else {
> /* Compute any data- or p-drive using XOR */
> count = 0;
> - for (i = disks; i-- ; ) {
> + for (i = disks - 1; i >= 0; i--) {
> if (i == target || i == qd_idx)
> continue;
> blocks[count++] = sh->dev[i].page;
> @@ -1492,7 +1492,7 @@ ops_run_compute6_2(struct stripe_head *sh, struct raid5_percpu *percpu)
> data_target = target;
>
> count = 0;
> - for (i = disks; i-- ; ) {
> + for (i = disks - 1; i >= 0; i--) {
> if (i == data_target || i == qd_idx)
> continue;
> blocks[count++] = sh->dev[i].page;
> @@ -1554,7 +1554,7 @@ ops_run_prexor5(struct stripe_head *sh, struct raid5_percpu *percpu,
> pr_debug("%s: stripe %llu\n", __func__,
> (unsigned long long)sh->sector);
>
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
> /* Only process blocks that are known to be uptodate */
> if (test_bit(R5_Wantdrain, &dev->flags))
> @@ -1598,7 +1598,7 @@ ops_run_biodrain(struct stripe_head *sh, struct dma_async_tx_descriptor *tx)
> pr_debug("%s: stripe %llu\n", __func__,
> (unsigned long long)sh->sector);
>
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct r5dev *dev;
> struct bio *chosen;
>
> @@ -1663,13 +1663,13 @@ static void ops_complete_reconstruct(void *stripe_head_ref)
> pr_debug("%s: stripe %llu\n", __func__,
> (unsigned long long)sh->sector);
>
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> fua |= test_bit(R5_WantFUA, &sh->dev[i].flags);
> sync |= test_bit(R5_SyncIO, &sh->dev[i].flags);
> discard |= test_bit(R5_Discard, &sh->dev[i].flags);
> }
>
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
>
> if (dev->written || i == pd_idx || i == qd_idx) {
> @@ -1734,14 +1734,14 @@ again:
> if (head_sh->reconstruct_state == reconstruct_state_prexor_drain_run) {
> prexor = 1;
> xor_dest = xor_srcs[count++] = sh->dev[pd_idx].page;
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
> if (head_sh->dev[i].written)
> xor_srcs[count++] = dev->page;
> }
> } else {
> xor_dest = sh->dev[pd_idx].page;
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
> if (i != pd_idx)
> xor_srcs[count++] = dev->page;
> @@ -1872,7 +1872,7 @@ static void ops_run_check_p(struct stripe_head *sh, struct raid5_percpu *percpu)
> count = 0;
> xor_dest = sh->dev[pd_idx].page;
> xor_srcs[count++] = xor_dest;
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> if (i == pd_idx || i == qd_idx)
> continue;
> xor_srcs[count++] = sh->dev[i].page;
> @@ -1970,7 +1970,7 @@ static void raid_run_ops(struct stripe_head *sh, unsigned long ops_request)
> }
>
> if (overlap_clear && !sh->batch_head)
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
> if (test_and_clear_bit(R5_Overlap, &dev->flags))
> wake_up(&sh->raid_conf->wait_for_overlap);
> @@ -2861,7 +2861,7 @@ schedule_reconstruction(struct stripe_head *sh, struct stripe_head_state *s,
>
> if (rcw) {
>
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
>
> if (dev->towrite) {
> @@ -2897,7 +2897,7 @@ schedule_reconstruction(struct stripe_head *sh, struct stripe_head_state *s,
> (!(test_bit(R5_UPTODATE, &sh->dev[qd_idx].flags) ||
> test_bit(R5_Wantcompute, &sh->dev[qd_idx].flags))));
>
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
> if (i == pd_idx || i == qd_idx)
> continue;
> @@ -3072,7 +3072,7 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
> {
> int i;
> BUG_ON(sh->batch_head);
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct bio *bi;
> int bitmap_end = 0;
>
> @@ -3386,7 +3386,7 @@ static int fetch_block(struct stripe_head *sh, struct stripe_head_state *s,
> * do it if failed >= 2
> */
> int other;
> - for (other = disks; other--; ) {
> + for (other = disks - 1; other >= 0; other--) {
> if (other == disk_idx)
> continue;
> if (!test_bit(R5_UPTODATE,
> @@ -3433,7 +3433,7 @@ static void handle_stripe_fill(struct stripe_head *sh,
> */
> if (!test_bit(STRIPE_COMPUTE_RUN, &sh->state) && !sh->check_state &&
> !sh->reconstruct_state)
> - for (i = disks; i--; )
> + for (i = disks - 1; i >= 0; i--)
> if (fetch_block(sh, s, i, disks))
> break;
> set_bit(STRIPE_HANDLE, &sh->state);
> @@ -3455,7 +3455,7 @@ static void handle_stripe_clean_event(struct r5conf *conf,
> struct stripe_head *head_sh = sh;
> bool do_endio = false;
>
> - for (i = disks; i--; )
> + for (i = disks - 1; i >= 0; i--)
> if (sh->dev[i].written) {
> dev = &sh->dev[i];
> if (!test_bit(R5_LOCKED, &dev->flags) &&
> @@ -3573,7 +3573,8 @@ static void handle_stripe_dirtying(struct r5conf *conf,
> pr_debug("force RCW rmw_level=%u, recovery_cp=%llu sh->sector=%llu\n",
> conf->rmw_level, (unsigned long long)recovery_cp,
> (unsigned long long)sh->sector);
> - } else for (i = disks; i--; ) {
> + } else
> + for (i = disks - 1; i >= 0; i--) {
> /* would I have to read this buffer for read_modify_write */
> struct r5dev *dev = &sh->dev[i];
> if ((dev->towrite || i == sh->pd_idx || i == sh->qd_idx) &&
> @@ -3606,7 +3607,7 @@ static void handle_stripe_dirtying(struct r5conf *conf,
> blk_add_trace_msg(conf->mddev->queue,
> "raid5 rmw %llu %d",
> (unsigned long long)sh->sector, rmw);
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
> if ((dev->towrite || i == sh->pd_idx || i == sh->qd_idx) &&
> !test_bit(R5_LOCKED, &dev->flags) &&
> @@ -3631,7 +3632,7 @@ static void handle_stripe_dirtying(struct r5conf *conf,
> /* want reconstruct write, but need to get some data */
> int qread =0;
> rcw = 0;
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
> if (!test_bit(R5_OVERWRITE, &dev->flags) &&
> i != sh->pd_idx && i != sh->qd_idx &&
> @@ -4021,7 +4022,7 @@ static void analyse_stripe(struct stripe_head *sh, struct stripe_head_state *s)
>
> /* Now to look around and see what can be done */
> rcu_read_lock();
> - for (i=disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct md_rdev *rdev;
> sector_t first_bad;
> int bad_sectors;
> @@ -4391,7 +4392,7 @@ static void handle_stripe(struct stripe_head *sh)
> BUG_ON(sh->qd_idx >= 0 &&
> !test_bit(R5_UPTODATE, &sh->dev[sh->qd_idx].flags) &&
> !test_bit(R5_Discard, &sh->dev[sh->qd_idx].flags));
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct r5dev *dev = &sh->dev[i];
> if (test_bit(R5_LOCKED, &dev->flags) &&
> (i == sh->pd_idx || i == sh->qd_idx ||
> @@ -4539,7 +4540,7 @@ static void handle_stripe(struct stripe_head *sh)
>
> sh->reconstruct_state = reconstruct_state_idle;
> clear_bit(STRIPE_EXPANDING, &sh->state);
> - for (i = conf->raid_disks; i--; ) {
> + for (i = conf->raid_disks - 1; i >= 0; i--) {
> set_bit(R5_Wantwrite, &sh->dev[i].flags);
> set_bit(R5_LOCKED, &sh->dev[i].flags);
> s.locked++;
> @@ -4579,7 +4580,7 @@ finish:
> }
>
> if (s.handle_bad_blocks)
> - for (i = disks; i--; ) {
> + for (i = disks - 1; i >= 0; i--) {
> struct md_rdev *rdev;
> struct r5dev *dev = &sh->dev[i];
> if (test_and_clear_bit(R5_WriteError, &dev->flags)) {
> @@ -5486,7 +5487,7 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk
> /* If any of this stripe is beyond the end of the old
> * array, then we need to zero those blocks
> */
> - for (j=sh->disks; j--;) {
> + for (j = sh->disks - 1; j >= 0; j--) {
> sector_t s;
> if (j == sh->pd_idx)
> continue;
>
--
Eyal Lebedinsky (eyal@eyal.emu.id.au)
^ permalink raw reply
* [PATCH] super1: make the check for NodeNumUpdate more accurate
From: Guoqing Jiang @ 2016-05-09 2:22 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-raid, Guoqing Jiang
We missed to check the version is BITMAP_MAJOR_CLUSTERED
or not, otherwise mdadm can't create array with other 1.x
metadatas (1.0 and 1.1).
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
super1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/super1.c b/super1.c
index 972b470..fa93367 100644
--- a/super1.c
+++ b/super1.c
@@ -2389,7 +2389,7 @@ static int write_bitmap1(struct supertype *st, int fd, enum bitmap_update update
break;
case NodeNumUpdate:
/* cluster md only supports superblock 1.2 now */
- if (st->minor_version != 2) {
+ if (st->minor_version != 2 && bms->version == BITMAP_MAJOR_CLUSTERED) {
pr_err("Warning: cluster md only works with superblock 1.2\n");
return -EINVAL;
}
--
2.6.2
^ permalink raw reply related
* Re: [PATCH] md: make the code more readable in the for-loop
From: Shaohua Li @ 2016-05-09 3:53 UTC (permalink / raw)
To: Eyal Lebedinsky; +Cc: linux-raid
In-Reply-To: <572FCCD3.4070907@eyal.emu.id.au>
On Mon, May 09, 2016 at 09:33:39AM +1000, Eyal Lebedinsky wrote:
> I do not see how this change makes it clearer. The original form is actually a very common and clear
> scan an array in reverse order
People always have different opinions for this stuff. When I read '--j' or
'j--', I always think extra time what the value of j is. So for me the change
actually makes the code more readable :)
Thanks,
Shaohua
> On 08/05/16 22:56, Tiezhu Yang wrote:
> >This patch modifies raid1.c, raid10.c and raid5.c
> >to make the code more readable in the for-loop
> >and also fixes the scripts/checkpatch.pl error:
> >ERROR: trailing statements should be on next line.
> >
> >Signed-off-by: Tiezhu Yang <kernelpatch@126.com>
> >---
> > drivers/md/raid1.c | 6 +++---
> > drivers/md/raid10.c | 2 +-
> > drivers/md/raid5.c | 59 +++++++++++++++++++++++++++--------------------------
> > 3 files changed, 34 insertions(+), 33 deletions(-)
> >
> >diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> >index a7f2b9c..760de56 100644
> >--- a/drivers/md/raid1.c
> >+++ b/drivers/md/raid1.c
> >@@ -109,7 +109,7 @@ static void * r1buf_pool_alloc(gfp_t gfp_flags, void *data)
> > /*
> > * Allocate bios : 1 for reading, n-1 for writing
> > */
> >- for (j = pi->raid_disks ; j-- ; ) {
> >+ for (j = pi->raid_disks - 1; j >= 0; j--) {
> > bio = bio_kmalloc(gfp_flags, RESYNC_PAGES);
> > if (!bio)
> > goto out_free_bio;
> >@@ -166,7 +166,7 @@ static void r1buf_pool_free(void *__r1_bio, void *data)
> > struct r1bio *r1bio = __r1_bio;
> >
> > for (i = 0; i < RESYNC_PAGES; i++)
> >- for (j = pi->raid_disks; j-- ;) {
> >+ for (j = pi->raid_disks - 1; j >= 0; j--) {
> > if (j == 0 ||
> > r1bio->bios[j]->bi_io_vec[i].bv_page !=
> > r1bio->bios[0]->bi_io_vec[i].bv_page)
> >@@ -1976,7 +1976,7 @@ static void process_checks(struct r1bio *r1_bio)
> > sbio->bi_error = 0;
> >
> > if (!error) {
> >- for (j = vcnt; j-- ; ) {
> >+ for (j = vcnt - 1; j >= 0; j--) {
> > struct page *p, *s;
> > p = pbio->bi_io_vec[j].bv_page;
> > s = sbio->bi_io_vec[j].bv_page;
> >diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> >index 84e24e6..52f1e07 100644
> >--- a/drivers/md/raid10.c
> >+++ b/drivers/md/raid10.c
> >@@ -157,7 +157,7 @@ static void * r10buf_pool_alloc(gfp_t gfp_flags, void *data)
> > /*
> > * Allocate bios.
> > */
> >- for (j = nalloc ; j-- ; ) {
> >+ for (j = nalloc - 1; j >= 0; j--) {
> > bio = bio_kmalloc(gfp_flags, RESYNC_PAGES);
> > if (!bio)
> > goto out_free_bio;
> >diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> >index 4d31b23..db978ab 100644
> >--- a/drivers/md/raid5.c
> >+++ b/drivers/md/raid5.c
> >@@ -536,7 +536,7 @@ retry:
> > stripe_set_idx(sector, conf, previous, sh);
> > sh->state = 0;
> >
> >- for (i = sh->disks; i--; ) {
> >+ for (i = sh->disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> >
> > if (dev->toread || dev->read || dev->towrite || dev->written ||
> >@@ -890,7 +890,7 @@ static void ops_run_io(struct stripe_head *sh, struct stripe_head_state *s)
> >
> > if (r5l_write_stripe(conf->log, sh) == 0)
> > return;
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > int rw;
> > int replace_only = 0;
> > struct bio *bi, *rbi;
> >@@ -1175,7 +1175,7 @@ static void ops_complete_biofill(void *stripe_head_ref)
> > (unsigned long long)sh->sector);
> >
> > /* clear completed biofills */
> >- for (i = sh->disks; i--; ) {
> >+ for (i = sh->disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> >
> > /* acknowledge completion of a biofill operation */
> >@@ -1216,7 +1216,7 @@ static void ops_run_biofill(struct stripe_head *sh)
> > pr_debug("%s: stripe %llu\n", __func__,
> > (unsigned long long)sh->sector);
> >
> >- for (i = sh->disks; i--; ) {
> >+ for (i = sh->disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> > if (test_bit(R5_Wantfill, &dev->flags)) {
> > struct bio *rbi;
> >@@ -1307,7 +1307,7 @@ ops_run_compute5(struct stripe_head *sh, struct raid5_percpu *percpu)
> > __func__, (unsigned long long)sh->sector, target);
> > BUG_ON(!test_bit(R5_Wantcompute, &tgt->flags));
> >
> >- for (i = disks; i--; )
> >+ for (i = disks - 1; i >= 0; i--)
> > if (i != target)
> > xor_srcs[count++] = sh->dev[i].page;
> >
> >@@ -1407,7 +1407,7 @@ ops_run_compute6_1(struct stripe_head *sh, struct raid5_percpu *percpu)
> > } else {
> > /* Compute any data- or p-drive using XOR */
> > count = 0;
> >- for (i = disks; i-- ; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > if (i == target || i == qd_idx)
> > continue;
> > blocks[count++] = sh->dev[i].page;
> >@@ -1492,7 +1492,7 @@ ops_run_compute6_2(struct stripe_head *sh, struct raid5_percpu *percpu)
> > data_target = target;
> >
> > count = 0;
> >- for (i = disks; i-- ; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > if (i == data_target || i == qd_idx)
> > continue;
> > blocks[count++] = sh->dev[i].page;
> >@@ -1554,7 +1554,7 @@ ops_run_prexor5(struct stripe_head *sh, struct raid5_percpu *percpu,
> > pr_debug("%s: stripe %llu\n", __func__,
> > (unsigned long long)sh->sector);
> >
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> > /* Only process blocks that are known to be uptodate */
> > if (test_bit(R5_Wantdrain, &dev->flags))
> >@@ -1598,7 +1598,7 @@ ops_run_biodrain(struct stripe_head *sh, struct dma_async_tx_descriptor *tx)
> > pr_debug("%s: stripe %llu\n", __func__,
> > (unsigned long long)sh->sector);
> >
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct r5dev *dev;
> > struct bio *chosen;
> >
> >@@ -1663,13 +1663,13 @@ static void ops_complete_reconstruct(void *stripe_head_ref)
> > pr_debug("%s: stripe %llu\n", __func__,
> > (unsigned long long)sh->sector);
> >
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > fua |= test_bit(R5_WantFUA, &sh->dev[i].flags);
> > sync |= test_bit(R5_SyncIO, &sh->dev[i].flags);
> > discard |= test_bit(R5_Discard, &sh->dev[i].flags);
> > }
> >
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> >
> > if (dev->written || i == pd_idx || i == qd_idx) {
> >@@ -1734,14 +1734,14 @@ again:
> > if (head_sh->reconstruct_state == reconstruct_state_prexor_drain_run) {
> > prexor = 1;
> > xor_dest = xor_srcs[count++] = sh->dev[pd_idx].page;
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> > if (head_sh->dev[i].written)
> > xor_srcs[count++] = dev->page;
> > }
> > } else {
> > xor_dest = sh->dev[pd_idx].page;
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> > if (i != pd_idx)
> > xor_srcs[count++] = dev->page;
> >@@ -1872,7 +1872,7 @@ static void ops_run_check_p(struct stripe_head *sh, struct raid5_percpu *percpu)
> > count = 0;
> > xor_dest = sh->dev[pd_idx].page;
> > xor_srcs[count++] = xor_dest;
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > if (i == pd_idx || i == qd_idx)
> > continue;
> > xor_srcs[count++] = sh->dev[i].page;
> >@@ -1970,7 +1970,7 @@ static void raid_run_ops(struct stripe_head *sh, unsigned long ops_request)
> > }
> >
> > if (overlap_clear && !sh->batch_head)
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> > if (test_and_clear_bit(R5_Overlap, &dev->flags))
> > wake_up(&sh->raid_conf->wait_for_overlap);
> >@@ -2861,7 +2861,7 @@ schedule_reconstruction(struct stripe_head *sh, struct stripe_head_state *s,
> >
> > if (rcw) {
> >
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> >
> > if (dev->towrite) {
> >@@ -2897,7 +2897,7 @@ schedule_reconstruction(struct stripe_head *sh, struct stripe_head_state *s,
> > (!(test_bit(R5_UPTODATE, &sh->dev[qd_idx].flags) ||
> > test_bit(R5_Wantcompute, &sh->dev[qd_idx].flags))));
> >
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> > if (i == pd_idx || i == qd_idx)
> > continue;
> >@@ -3072,7 +3072,7 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
> > {
> > int i;
> > BUG_ON(sh->batch_head);
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct bio *bi;
> > int bitmap_end = 0;
> >
> >@@ -3386,7 +3386,7 @@ static int fetch_block(struct stripe_head *sh, struct stripe_head_state *s,
> > * do it if failed >= 2
> > */
> > int other;
> >- for (other = disks; other--; ) {
> >+ for (other = disks - 1; other >= 0; other--) {
> > if (other == disk_idx)
> > continue;
> > if (!test_bit(R5_UPTODATE,
> >@@ -3433,7 +3433,7 @@ static void handle_stripe_fill(struct stripe_head *sh,
> > */
> > if (!test_bit(STRIPE_COMPUTE_RUN, &sh->state) && !sh->check_state &&
> > !sh->reconstruct_state)
> >- for (i = disks; i--; )
> >+ for (i = disks - 1; i >= 0; i--)
> > if (fetch_block(sh, s, i, disks))
> > break;
> > set_bit(STRIPE_HANDLE, &sh->state);
> >@@ -3455,7 +3455,7 @@ static void handle_stripe_clean_event(struct r5conf *conf,
> > struct stripe_head *head_sh = sh;
> > bool do_endio = false;
> >
> >- for (i = disks; i--; )
> >+ for (i = disks - 1; i >= 0; i--)
> > if (sh->dev[i].written) {
> > dev = &sh->dev[i];
> > if (!test_bit(R5_LOCKED, &dev->flags) &&
> >@@ -3573,7 +3573,8 @@ static void handle_stripe_dirtying(struct r5conf *conf,
> > pr_debug("force RCW rmw_level=%u, recovery_cp=%llu sh->sector=%llu\n",
> > conf->rmw_level, (unsigned long long)recovery_cp,
> > (unsigned long long)sh->sector);
> >- } else for (i = disks; i--; ) {
> >+ } else
> >+ for (i = disks - 1; i >= 0; i--) {
> > /* would I have to read this buffer for read_modify_write */
> > struct r5dev *dev = &sh->dev[i];
> > if ((dev->towrite || i == sh->pd_idx || i == sh->qd_idx) &&
> >@@ -3606,7 +3607,7 @@ static void handle_stripe_dirtying(struct r5conf *conf,
> > blk_add_trace_msg(conf->mddev->queue,
> > "raid5 rmw %llu %d",
> > (unsigned long long)sh->sector, rmw);
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> > if ((dev->towrite || i == sh->pd_idx || i == sh->qd_idx) &&
> > !test_bit(R5_LOCKED, &dev->flags) &&
> >@@ -3631,7 +3632,7 @@ static void handle_stripe_dirtying(struct r5conf *conf,
> > /* want reconstruct write, but need to get some data */
> > int qread =0;
> > rcw = 0;
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> > if (!test_bit(R5_OVERWRITE, &dev->flags) &&
> > i != sh->pd_idx && i != sh->qd_idx &&
> >@@ -4021,7 +4022,7 @@ static void analyse_stripe(struct stripe_head *sh, struct stripe_head_state *s)
> >
> > /* Now to look around and see what can be done */
> > rcu_read_lock();
> >- for (i=disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct md_rdev *rdev;
> > sector_t first_bad;
> > int bad_sectors;
> >@@ -4391,7 +4392,7 @@ static void handle_stripe(struct stripe_head *sh)
> > BUG_ON(sh->qd_idx >= 0 &&
> > !test_bit(R5_UPTODATE, &sh->dev[sh->qd_idx].flags) &&
> > !test_bit(R5_Discard, &sh->dev[sh->qd_idx].flags));
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct r5dev *dev = &sh->dev[i];
> > if (test_bit(R5_LOCKED, &dev->flags) &&
> > (i == sh->pd_idx || i == sh->qd_idx ||
> >@@ -4539,7 +4540,7 @@ static void handle_stripe(struct stripe_head *sh)
> >
> > sh->reconstruct_state = reconstruct_state_idle;
> > clear_bit(STRIPE_EXPANDING, &sh->state);
> >- for (i = conf->raid_disks; i--; ) {
> >+ for (i = conf->raid_disks - 1; i >= 0; i--) {
> > set_bit(R5_Wantwrite, &sh->dev[i].flags);
> > set_bit(R5_LOCKED, &sh->dev[i].flags);
> > s.locked++;
> >@@ -4579,7 +4580,7 @@ finish:
> > }
> >
> > if (s.handle_bad_blocks)
> >- for (i = disks; i--; ) {
> >+ for (i = disks - 1; i >= 0; i--) {
> > struct md_rdev *rdev;
> > struct r5dev *dev = &sh->dev[i];
> > if (test_and_clear_bit(R5_WriteError, &dev->flags)) {
> >@@ -5486,7 +5487,7 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk
> > /* If any of this stripe is beyond the end of the old
> > * array, then we need to zero those blocks
> > */
> >- for (j=sh->disks; j--;) {
> >+ for (j = sh->disks - 1; j >= 0; j--) {
> > sector_t s;
> > if (j == sh->pd_idx)
> > continue;
> >
>
> --
> Eyal Lebedinsky (eyal@eyal.emu.id.au)
> --
> 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] md: make the code more readable in the for-loop
From: NeilBrown @ 2016-05-09 6:31 UTC (permalink / raw)
To: Shaohua Li, Eyal Lebedinsky; +Cc: linux-raid
In-Reply-To: <20160509035319.GA57828@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
On Mon, May 09 2016, Shaohua Li wrote:
> On Mon, May 09, 2016 at 09:33:39AM +1000, Eyal Lebedinsky wrote:
>> I do not see how this change makes it clearer. The original form is actually a very common and clear
>> scan an array in reverse order
>
> People always have different opinions for this stuff. When I read '--j' or
> 'j--', I always think extra time what the value of j is. So for me the change
> actually makes the code more readable :)
If the goal is to make the code more readable, you may as well make it:
for (j = 0; i < ->raid_disk; j++)
That will be clearer to most people than the current code, which I don't
think is very much clearer than the original (maybe a little bit).
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* [PATCH] md: raid5: add prerequisite to run underneath dm-raid
From: heinzm @ 2016-05-09 15:50 UTC (permalink / raw)
To: linux-raid; +Cc: Heinz Mauelshagen
From: Heinz Mauelshagen <heinzm@redhat.com>
In case md runs underneath the dm-raid target, the mddev does not have
a request queue or gendisk, thus avoid accesses.
This patch adds a missing conditional to the raid5 personality.
Signed-of-by: Heinz Mauelshagen <heinzm@redhat.com>
---
drivers/md/raid5.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 8ab8b65..ce79ce6 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -7574,8 +7574,10 @@ static void raid5_finish_reshape(struct mddev *mddev)
if (mddev->delta_disks > 0) {
md_set_array_sectors(mddev, raid5_size(mddev, 0, 0));
- set_capacity(mddev->gendisk, mddev->array_sectors);
- revalidate_disk(mddev->gendisk);
+ if (mddev->queue) {
+ set_capacity(mddev->gendisk, mddev->array_sectors);
+ revalidate_disk(mddev->gendisk);
+ }
} else {
int d;
spin_lock_irq(&conf->device_lock);
--
2.5.5
^ 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