* livelock on MD RAID5
From: Mikulas Patocka @ 2015-01-20 3:24 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid, dm-devel
Hi Neil
I saw your patch "md/raid5: avoid livelock caused by non-aligned writes".
That patch is only for RAID 6, but we are seeing similar livelock on RAID5
(mdX_raid5 is constantly looping in
raid5d/handle_active_stripes/handle_stripe/ops_run_io and some submitted
bios get stuck). The livelock happens when we issue I/O and simulate disk
failure.
Do you think that the same issue could happen on RAID5 too?
Do you think that the patch "md/raid5: fetch_block must fetch all the
blocks handle_stripe_dirtying wants." could fix it?
Mikulas
^ permalink raw reply
* [PATCH RESEND] md:Remove no longer needed fix me comment in dm-region-hash.c for removing the structure pointer, *rh from the definiton of dm_region
From: Nicholas Krause @ 2015-01-20 3:16 UTC (permalink / raw)
To: agk; +Cc: linux-raid, dm-devel, linux-kernel, snitzer
Removes the no longer needed fix me comment questioning if we need to remove
the structure pointer,rh as defined as a structure of type dsm_region_hash
from the definition of the structure, dm_region. Furthermore this pointer is
needed in order for various functions to run and build successfully in the file,
dm-region-hash.c.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
---
drivers/md/dm-region-hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-region-hash.c b/drivers/md/dm-region-hash.c
index b929fd5..823d56f 100644
--- a/drivers/md/dm-region-hash.c
+++ b/drivers/md/dm-region-hash.c
@@ -99,7 +99,7 @@ struct dm_region_hash {
};
struct dm_region {
- struct dm_region_hash *rh; /* FIXME: can we get rid of this ? */
+ struct dm_region_hash *rh;
region_t key;
int state;
--
2.1.0
^ permalink raw reply related
* Re: kernel refuses devices mdadm -E accepts
From: Roger Heflin @ 2015-01-19 23:52 UTC (permalink / raw)
To: Wesley W. Terpstra; +Cc: Linux RAID
In-Reply-To: <CAA-O0XjoD3fQaMpYYmy4kpBSxD+K9TKX_QGr9mcNVuye43XWHg@mail.gmail.com>
cat /proc/mdstat
if the device is in use mdadm -E will work but you cannot create a
device because one already has it.
On Mon, Jan 19, 2015 at 5:01 PM, Wesley W. Terpstra <wesley@terpstra.ca> wrote:
> I have a raid5 array for which every disk, when examined with "mdadm
> -E /dev/sd[abcd]4" shows a Version: 1.2 superblock with a valid
> checksum.
>
> However, when I try:
> mdadm -A /dev/md/backing /dev/sd[abcd]4
> mdadm says:
> mdadm: failed to add /dev/sdc4 to /dev/md/backing: Invalid argument
> mdadm: failed to add /dev/sdb4 to /dev/md/backing: Invalid argument
> mdadm: failed to add /dev/sda4 to /dev/md/backing: Invalid argument
> mdadm: failed to add /dev/sdd4 to /dev/md/backing: Invalid argument
> mdadm: /dev/md/backing assembled from 0 drives - need all 4 to start
> it (use --run to insist)
> The kernel says:
> md: sdc4 does not have a valid v1.2 superblock, not importing!
> md: md_import_device returned -22
> md: sdb4 does not have a valid v1.2 superblock, not importing!
> md: md_import_device returned -22
> md: sda4 does not have a valid v1.2 superblock, not importing!
> md: md_import_device returned -22
> md: sdd4 does not have a valid v1.2 superblock, not importing!
> md: md_import_device returned -22
>
> I was in the middle of a reshape of this 4-disk raid5 when something
> rebooted the computer. The system seems otherwise fine, and I suspect
> someone in the house.
>
> What is the correct next step? Should I try --run ? I would obviously
> prefer not to lose the data on this array. I expect that the reshape
> was NOT complete, so just recreating the array will probably corrupt
> its contents.
>
> Kernel version 3.17.8 and mdadm version 3.3.2.
>
> Thanks for any help. If I lose this array, I am going to face a lot of grief...
> --
> 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
* kernel refuses devices mdadm -E accepts
From: Wesley W. Terpstra @ 2015-01-19 23:01 UTC (permalink / raw)
To: linux-raid
I have a raid5 array for which every disk, when examined with "mdadm
-E /dev/sd[abcd]4" shows a Version: 1.2 superblock with a valid
checksum.
However, when I try:
mdadm -A /dev/md/backing /dev/sd[abcd]4
mdadm says:
mdadm: failed to add /dev/sdc4 to /dev/md/backing: Invalid argument
mdadm: failed to add /dev/sdb4 to /dev/md/backing: Invalid argument
mdadm: failed to add /dev/sda4 to /dev/md/backing: Invalid argument
mdadm: failed to add /dev/sdd4 to /dev/md/backing: Invalid argument
mdadm: /dev/md/backing assembled from 0 drives - need all 4 to start
it (use --run to insist)
The kernel says:
md: sdc4 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
md: sdb4 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
md: sda4 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
md: sdd4 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22
I was in the middle of a reshape of this 4-disk raid5 when something
rebooted the computer. The system seems otherwise fine, and I suspect
someone in the house.
What is the correct next step? Should I try --run ? I would obviously
prefer not to lose the data on this array. I expect that the reshape
was NOT complete, so just recreating the array will probably corrupt
its contents.
Kernel version 3.17.8 and mdadm version 3.3.2.
Thanks for any help. If I lose this array, I am going to face a lot of grief...
^ permalink raw reply
* Re: RAID1 removing failed disk returns EBUSY
From: Joe Lawrence @ 2015-01-19 17:56 UTC (permalink / raw)
To: Xiao Ni; +Cc: NeilBrown, linux-raid, Bill Kuzeja
In-Reply-To: <1924199853.11308787.1421634830810.JavaMail.zimbra@redhat.com>
On Sun, 18 Jan 2015 21:33:50 -0500
Xiao Ni <xni@redhat.com> wrote:
>
>
> ----- Original Message -----
> > From: "Joe Lawrence" <joe.lawrence@stratus.com>
> > To: "Xiao Ni" <xni@redhat.com>
> > Cc: "NeilBrown" <neilb@suse.de>, linux-raid@vger.kernel.org, "Bill Kuzeja" <william.kuzeja@stratus.com>
> > Sent: Friday, January 16, 2015 11:10:31 PM
> > Subject: Re: RAID1 removing failed disk returns EBUSY
> >
> > On Fri, 16 Jan 2015 00:20:12 -0500
> > Xiao Ni <xni@redhat.com> wrote:
> > >
> > > Hi Joe
> > >
> > > Thanks for reminding me. I didn't do that. Now it can remove
> > > successfully after writing
> > > "idle" to sync_action.
> > >
> > > I thought wrongly that the patch referenced in this mail is fixed for
> > > the problem.
> >
> > So it sounds like even with 3.18 and a new mdadm, this bug still
> > persists?
> >
> > -- Joe
> >
> > --
>
> Hi Joe
>
> I'm a little confused now. Does the patch 45eaf45dfa4850df16bc2e8e7903d89021137f40 from linux-stable
> resolve the problem?
>
> My environment is:
>
> [root@dhcp-12-133 mdadm]# mdadm --version
> mdadm - v3.3.2-18-g93d3bd3 - 18th December 2014 (this is the newest upstream)
> [root@dhcp-12-133 mdadm]# uname -r
> 3.18.2
>
>
> My steps are:
>
> [root@dhcp-12-133 mdadm]# lsblk
> sdb 8:16 0 931.5G 0 disk
> └─sdb1 8:17 0 5G 0 part
> sdc 8:32 0 186.3G 0 disk
> sdd 8:48 0 931.5G 0 disk
> └─sdd1 8:49 0 5G 0 part
> [root@dhcp-12-133 mdadm]# mdadm -CR /dev/md0 -l1 -n2 /dev/sdb1 /dev/sdd1 --assume-clean
> mdadm: Note: this array has metadata at the start and
> may not be suitable as a boot device. If you plan to
> store '/boot' on this device please ensure that
> your boot-loader understands md/v1.x metadata, or use
> --metadata=0.90
> mdadm: Defaulting to version 1.2 metadata
> mdadm: array /dev/md0 started.
>
> Then I unplug the disk.
>
> [root@dhcp-12-133 mdadm]# lsblk
> sdc 8:32 0 186.3G 0 disk
> sdd 8:48 0 931.5G 0 disk
> └─sdd1 8:49 0 5G 0 part
> └─md0 9:0 0 5G 0 raid1
> [root@dhcp-12-133 mdadm]# echo faulty > /sys/block/md0/md/dev-sdb1/state
> [root@dhcp-12-133 mdadm]# echo remove > /sys/block/md0/md/dev-sdb1/state
> -bash: echo: write error: Device or resource busy
> [root@dhcp-12-133 mdadm]# echo idle > /sys/block/md0/md/sync_action
> [root@dhcp-12-133 mdadm]# echo remove > /sys/block/md0/md/dev-sdb1/state
>
>
> Now after I set idle to sync_action, it can be removed as you said in the mail.
> It's a good workaround. Is this OK?
>
> Best Regards
> Xiao
Hi Xiao,
According to my notes, the "idle" sync_action was always a viable
workaround, with or with this change.
Neil's patch should have made it possible to issue only a
"faulty" and "remove" to remove the RAID component.
I don't have an exact version, but it appears that my mdadm version was
an upstream git from Oct 27-th timeframe.
-- Joe
--
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
* Interesse
From: Peter Wong @ 2015-01-19 11:22 UTC (permalink / raw)
Jeg vil foreslå relasjoner som er av felles interesse. Det er overføring
av en stor sum penger.Jeg skriver til deg fordi du har blitt anbefalt til
meg som en som kan være egnet for mitt prosjekt.
Ta kontakt med meg på min personlige e-postadresse; en rask respons, ville
jeg stor pris på det.
Med våre beste ønsker
Peter Wong
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RAID1 removing failed disk returns EBUSY
From: Xiao Ni @ 2015-01-19 2:33 UTC (permalink / raw)
To: Joe Lawrence; +Cc: NeilBrown, linux-raid, Bill Kuzeja
In-Reply-To: <20150116101031.30c04df3@jlaw-desktop.mno.stratus.com>
----- Original Message -----
> From: "Joe Lawrence" <joe.lawrence@stratus.com>
> To: "Xiao Ni" <xni@redhat.com>
> Cc: "NeilBrown" <neilb@suse.de>, linux-raid@vger.kernel.org, "Bill Kuzeja" <william.kuzeja@stratus.com>
> Sent: Friday, January 16, 2015 11:10:31 PM
> Subject: Re: RAID1 removing failed disk returns EBUSY
>
> On Fri, 16 Jan 2015 00:20:12 -0500
> Xiao Ni <xni@redhat.com> wrote:
> >
> > Hi Joe
> >
> > Thanks for reminding me. I didn't do that. Now it can remove
> > successfully after writing
> > "idle" to sync_action.
> >
> > I thought wrongly that the patch referenced in this mail is fixed for
> > the problem.
>
> So it sounds like even with 3.18 and a new mdadm, this bug still
> persists?
>
> -- Joe
>
> --
Hi Joe
I'm a little confused now. Does the patch 45eaf45dfa4850df16bc2e8e7903d89021137f40 from linux-stable
resolve the problem?
My environment is:
[root@dhcp-12-133 mdadm]# mdadm --version
mdadm - v3.3.2-18-g93d3bd3 - 18th December 2014 (this is the newest upstream)
[root@dhcp-12-133 mdadm]# uname -r
3.18.2
My steps are:
[root@dhcp-12-133 mdadm]# lsblk
sdb 8:16 0 931.5G 0 disk
└─sdb1 8:17 0 5G 0 part
sdc 8:32 0 186.3G 0 disk
sdd 8:48 0 931.5G 0 disk
└─sdd1 8:49 0 5G 0 part
[root@dhcp-12-133 mdadm]# mdadm -CR /dev/md0 -l1 -n2 /dev/sdb1 /dev/sdd1 --assume-clean
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
Then I unplug the disk.
[root@dhcp-12-133 mdadm]# lsblk
sdc 8:32 0 186.3G 0 disk
sdd 8:48 0 931.5G 0 disk
└─sdd1 8:49 0 5G 0 part
└─md0 9:0 0 5G 0 raid1
[root@dhcp-12-133 mdadm]# echo faulty > /sys/block/md0/md/dev-sdb1/state
[root@dhcp-12-133 mdadm]# echo remove > /sys/block/md0/md/dev-sdb1/state
-bash: echo: write error: Device or resource busy
[root@dhcp-12-133 mdadm]# echo idle > /sys/block/md0/md/sync_action
[root@dhcp-12-133 mdadm]# echo remove > /sys/block/md0/md/dev-sdb1/state
Now after I set idle to sync_action, it can be removed as you said in the mail.
It's a good workaround. Is this OK?
Best Regards
Xiao
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Corrupted Cisco NSS4000 raid
From: Valentijn Sessink @ 2015-01-17 17:27 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <54BA7E8F.1090601@excello.cz>
Hello Jan,
On 17-01-15 16:23, Jan Hejl wrote:
> right after finish rebuilding faulty, but still usable, RAID array on
> Cisco NSS4000 NAS box, array stopped working completly.
I'd go for
mdadm --assemble --force --run /dev/md666 $sdb $sdc $sdd
... because sdb, sdc and sdd seem to have the same number of "events" -
and sde has a lower number. However, sdc is a "spare" according to the
mdadm information, so that may not work, in which case you could try to
assemble sdb, sdd and sde and then later on try to recreate the array
with sdc in it.
sdb..d are variables in my "assemble" command, because I'd NEVER do this
on a live disk. Please see my posting about what I did to "clone" the
disks with dmsetup: http://valentijn.sessink.nl/?p=557 (I'm sure there
are other ways - having a disk image with "dd" would also help).
For dd to fill unreadable sectors of the source disks with zeroes,
you'll need a few options, otherwise dd will stop, or, even worse, just
"ignore" unreadable sectors like this: 01234xxx89 -> becomes 0123489 at
the target disk. What you want is 0123400089 (unreadable, but not
truncated). "conv=sync,noerror" is, IIRC, the right option but please
check this (I didn't)
Using 3 out of 4 disks will not help you work around read errors on the
disks themselves, so you may want to use smartctl first to see what the
disk statuses are. Using /dev/sde in the array could work, but as it has
a lower "events" count, you can expect to lose some data.
I woudn't go for 4 out of 4 disks, because that will start rebuilding
the array as soon as you have it read/write and you don't want to change
data on any one of the disks.
If "assemble" doesn't work, you could use "create". Please note that
different versions of mdadm have different ideas about "Data Offset",
and only the newest mdadm can handle a user defined data offset, with
the "--data-offset" option. So your best bet for now is using
assemble+force, although I have seen situations where mdadm will just
not assemble the array due to one or more disks having different
information than mdadm expects.
I hope this helps. Good luck.
Best regards,
Valentijn
^ permalink raw reply
* Corrupted Cisco NSS4000 raid
From: Jan Hejl @ 2015-01-17 15:23 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1.1: Type: text/plain, Size: 630 bytes --]
Hello everyone,
right after finish rebuilding faulty, but still usable, RAID array on
Cisco NSS4000 NAS box, array stopped working completly.
I took all 4 drives (1TB each) out and connected to my linux machine to
take a look what happened. You can find raid-status (mdadm --examine
/dev/sd[bcde]) attached.
After reading this page
https://raid.wiki.kernel.org/index.php/RAID_Recovery I'm considering to
try recreate array, as soon as dd ends with image backup of these
drives, but before I screw something I would to ask you RAID wizards for
help. Was anyone solving similiar issue?
Thanks for help
Jan
[-- Attachment #1.2: raid-status --]
[-- Type: text/plain, Size: 3246 bytes --]
/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : c5e32635:d1ed305c:c7804bbe:d0dd962d
Name : 0
Creation Time : Mon Feb 11 16:58:03 2013
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953524896 (931.51 GiB 1000.20 GB)
Array Size : 2930287296 (2794.54 GiB 3000.61 GB)
Used Dev Size : 1953524864 (931.51 GiB 1000.20 GB)
Data Offset : 272 sectors
Super Offset : 8 sectors
State : clean
Device UUID : bbd560dd:768ade9f:dd15ef88:53d2dd62
Update Time : Wed Jan 14 17:24:39 2015
Checksum : 1e255442 - correct
Events : 1190
Layout : left-symmetric
Chunk Size : 32K
Device Role : Active device 3
Array State : A..A ('A' == active, '.' == missing)
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : c5e32635:d1ed305c:c7804bbe:d0dd962d
Name : 0
Creation Time : Mon Feb 11 16:58:03 2013
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953524896 (931.51 GiB 1000.20 GB)
Array Size : 2930287296 (2794.54 GiB 3000.61 GB)
Used Dev Size : 1953524864 (931.51 GiB 1000.20 GB)
Data Offset : 272 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 0c7f1826:b250a6da:fcdeef79:bb3845ad
Update Time : Wed Jan 14 17:24:39 2015
Checksum : dd0cf356 - correct
Events : 1190
Layout : left-symmetric
Chunk Size : 32K
Device Role : spare
Array State : A..A ('A' == active, '.' == missing)
/dev/sdd:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : c5e32635:d1ed305c:c7804bbe:d0dd962d
Name : 0
Creation Time : Mon Feb 11 16:58:03 2013
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953524896 (931.51 GiB 1000.20 GB)
Array Size : 2930287296 (2794.54 GiB 3000.61 GB)
Used Dev Size : 1953524864 (931.51 GiB 1000.20 GB)
Data Offset : 272 sectors
Super Offset : 8 sectors
State : clean
Device UUID : ba398ff8:329c83c3:4e9a58be:5e3ea83e
Update Time : Wed Jan 14 17:24:39 2015
Checksum : 6e2cba76 - correct
Events : 1190
Layout : left-symmetric
Chunk Size : 32K
Device Role : Active device 0
Array State : A..A ('A' == active, '.' == missing)
/dev/sde:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : c5e32635:d1ed305c:c7804bbe:d0dd962d
Name : 0
Creation Time : Mon Feb 11 16:58:03 2013
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 1953524896 (931.51 GiB 1000.20 GB)
Array Size : 2930287296 (2794.54 GiB 3000.61 GB)
Used Dev Size : 1953524864 (931.51 GiB 1000.20 GB)
Data Offset : 272 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 358b8c70:0307f5df:5aeabe91:ba88e079
Update Time : Wed Jan 14 16:57:26 2015
Checksum : 113d0d6d - correct
Events : 1186
Layout : left-symmetric
Chunk Size : 32K
Device Role : Active device 1
Array State : AA.A ('A' == active, '.' == missing)
[-- Attachment #2: Elektronicky podpis S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4559 bytes --]
^ permalink raw reply
* Re: RAID1 removing failed disk returns EBUSY
From: Joe Lawrence @ 2015-01-16 15:10 UTC (permalink / raw)
To: Xiao Ni; +Cc: NeilBrown, linux-raid, Bill Kuzeja
In-Reply-To: <2054919975.10444188.1421385612513.JavaMail.zimbra@redhat.com>
On Fri, 16 Jan 2015 00:20:12 -0500
Xiao Ni <xni@redhat.com> wrote:
>
> Hi Joe
>
> Thanks for reminding me. I didn't do that. Now it can remove successfully after writing
> "idle" to sync_action.
>
> I thought wrongly that the patch referenced in this mail is fixed for the problem.
So it sounds like even with 3.18 and a new mdadm, this bug still
persists?
-- Joe
^ permalink raw reply
* Re: RAID1 removing failed disk returns EBUSY
From: Xiao Ni @ 2015-01-16 5:20 UTC (permalink / raw)
To: Joe Lawrence; +Cc: NeilBrown, linux-raid, Bill Kuzeja
In-Reply-To: <20150115082210.31bd3ea5@jlaw-desktop.mno.stratus.com>
----- Original Message -----
> From: "Joe Lawrence" <joe.lawrence@stratus.com>
> To: "XiaoNi" <xni@redhat.com>
> Cc: "NeilBrown" <neilb@suse.de>, linux-raid@vger.kernel.org, "Bill Kuzeja" <william.kuzeja@stratus.com>
> Sent: Thursday, January 15, 2015 9:22:10 PM
> Subject: Re: RAID1 removing failed disk returns EBUSY
>
> On Wed, 14 Jan 2015 20:41:16 +0800
> XiaoNi <xni@redhat.com> wrote:
>
> > On 11/17/2014 07:03 AM, NeilBrown wrote:
> > > On Thu, 13 Nov 2014 09:05:49 -0500 Joe Lawrence<joe.lawrence@stratus.com>
> > > wrote:
> > >
> > >> On Wed, 29 Oct 2014 13:36:04 -0400
> > >> Joe Lawrence<joe.lawrence@stratus.com> wrote:
> > >>
> > >>> On Wed, 29 Oct 2014 08:41:13 +1100
> > >>> NeilBrown<neilb@suse.de> wrote:
> > >>>
> > >>>> On Mon, 27 Oct 2014 16:27:48 -0400 Joe
> > >>>> Lawrence<joe.lawrence@stratus.com>
> > >>>> wrote:
> > >>>>
> > >>>>> Hi Neil,
> > >>>>>
> > >>>>> We've encountered changes in MD and mdadm that have broken our
> > >>>>> automated
> > >>>>> disk removal script. In the past, we've been able to run the
> > >>>>> following
> > >>>>> after a RAID1 disk component removal:
> > >>>>>
> > >>>>> % echo fail> /sys/block/md3/md/dev-sdr5/state
> > >>>>> % echo remove> /sys/block/md3/md/dev-sdr5/state
> > >>>>>
> > >>>>> However, the latest RHEL6.6 code drop has rebased to sufficiently
> > >>>>> recent
> > >>>>> MD kernel and mdadm changes, in which the previous commands
> > >>>>> occasionally
> > >>>>> fail like so:
> > >>>>>
> > >>>>> * MD array is usually resyncing or checking
> > >>>>> * Component disk /dev/sdr removed via HBA sysfs PCI removal
> > >>>>> * Following UDEV rule fires:
> > >>>>>
> > >>>>> SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}=="?*", \
> > >>>>> RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"
> > >>>>>
> > >>>>> % mdadm --detail /dev/md3
> > >>>>> /dev/md3:
> > >>>>> Version : 1.1
> > >>>>> Creation Time : Tue Oct 14 17:31:59 2014
> > >>>>> Raid Level : raid1
> > >>>>> Array Size : 25149440 (23.98 GiB 25.75 GB)
> > >>>>> Used Dev Size : 25149440 (23.98 GiB 25.75 GB)
> > >>>>> Raid Devices : 2
> > >>>>> Total Devices : 2
> > >>>>> Persistence : Superblock is persistent
> > >>>>>
> > >>>>> Intent Bitmap : Internal
> > >>>>>
> > >>>>> Update Time : Wed Oct 15 14:22:34 2014
> > >>>>> State : active, degraded
> > >>>>> Active Devices : 1
> > >>>>> Working Devices : 1
> > >>>>> Failed Devices : 1
> > >>>>> Spare Devices : 0
> > >>>>>
> > >>>>> Name : localhost.localdomain:3
> > >>>>> UUID : 40ed68ee:ba41d4cd:28c361ed:be7470b8
> > >>>>> Events : 142
> > >>>>>
> > >>>>> Number Major Minor RaidDevice State
> > >>>>> 0 65 21 0 faulty
> > >>>>> 1 65 5 1 active sync /dev/sdj5
> > >>>>>
> > >>>>> All attempts to remove this device fail:
> > >>>>>
> > >>>>> % echo remove> /sys/block/md3/md/dev-sdr5/state
> > >>>>> -bash: echo: write error: Device or resource busy
> > >>>>>
> > >>>>> This can be traced to state_store():
> > >>>>>
> > >>>>> } else if (cmd_match(buf, "remove")) {
> > >>>>> if (rdev->raid_disk>= 0)
> > >>>>> err = -EBUSY;
> > >>>>>
> > >>>>> After much debugging and systemtapping, I think I've figured out that
> > >>>>> the
> > >>>>> sysfs scripting may fail after the following combination of changes:
> > >>>>>
> > >>>>> mdadm 8af530b07fce "Enhance incremental removal."
> > >>>>> kernel 30b8feb730f9 "md/raid5: avoid deadlock when raid5 array has
> > >>>>> unack
> > >>>>> badblocks during md_stop_writes"
> > >>>>>
> > >>>>> With these two changes:
> > >>>>>
> > >>>>> 1 - On the user side, mdadm is trying to set the array_state to
> > >>>>> read-auto
> > >>>>> on incremental removal (as invoked by UDEV rule).
> > >>>>>
> > >>>>> 2 - Kernel side, md_set_readonly() will set the MD_RECOVERY_FROZEN
> > >>>>> flag,
> > >>>>> wake up the mddev->thread and if there is a sync_thread, it will
> > >>>>> set
> > >>>>> MD_RECOVERY_INTR and then wait until the sync_thread is set to
> > >>>>> NULL.
> > >>>>>
> > >>>>> When md_check_recovery() gets a chance to run as part of the
> > >>>>> raid1d() mddev->thread, it may or may not ever get to
> > >>>>> an invocation of remove_and_add_spares(), for there are but
> > >>>>> *many*
> > >>>>> conditional early exits along the way -- for example, if
> > >>>>> MD_RECOVERY_FROZEN is set, the following condition will bounce
> > >>>>> out of
> > >>>>> the routine:
> > >>>>>
> > >>>>> if
> > >>>>> (!test_and_clear_bit(MD_RECOVERY_NEEDED,&mddev->recovery)
> > >>>>> ||
> > >>>>> test_bit(MD_RECOVERY_FROZEN,&mddev->recovery))
> > >>>>> goto unlock;
> > >>>>>
> > >>>>> the next time around, MD_RECOVERY_NEEDED will have been cleared,
> > >>>>> so
> > >>>>> all future tests will return 0 and the negation will always take
> > >>>>> the
> > >>>>> early exit path.
> > >>>>>
> > >>>>> Back in md_set_readonly(), it may notice that the MD is still in
> > >>>>> use,
> > >>>>> so it clears the MD_RECOVERY_FROZEN and then returns -EBUSY,
> > >>>>> without
> > >>>>> setting mddev->ro. But the damage has been done as conditions
> > >>>>> have
> > >>>>> been set such that md_check_recovery() will never call
> > >>>>> remove_and_add_spares().
> > >>>>>
> > >>>>> This would also explain why an "idle" sync_action clears the wedge:
> > >>>>> it
> > >>>>> sets MD_RECOVERY_NEEDED allowing md_check_recovery() to continue
> > >>>>> executing
> > >>>>> to remove_and_add_spares().
> > >>>>>
> > >>>>> As far as I can tell, this is what is happening to prevent the
> > >>>>> "remove"
> > >>>>> write to /sys/block/md3/md/dev-sdr5/state from succeeding. There are
> > >>>>> certainly a lot of little bit-states between disk removal, UDEV
> > >>>>> mdadm, and
> > >>>>> various MD kernel threads, so apologies if I missed an important
> > >>>>> transition.
> > >>>>>
> > >>>>> Would you consider writing "idle" to the MD array sync_action file as
> > >>>>> a
> > >>>>> safe and reasonable intermediate workaround step for our script?
> > >>>>>
> > >>>>> And of course, any suggestions to whether this is intended behavior
> > >>>>> (ie,
> > >>>>> the removed component disk is failed, but stuck in the array)?
> > >>>>>
> > >>>>> This is fairly easy for us to reproduce with multiple MD arrays per
> > >>>>> disk
> > >>>>> (one per partition) and interrupting a raid check on all of them
> > >>>>> (especially when they are delayed waiting for the first to finish) by
> > >>>>> removing the component disk via sysfs PCI removal. We can provide
> > >>>>> additional debug or testing if required.
> > >>>>>
> > >>>> Hi Joe,
> > >>>> thanks for the details analysis!!
> > >>>>
> > >>>> I think the correct fix would be that MD_RECOVERY_NEEDED should be set
> > >>>> after
> > >>>> clearing MD_RECOVERY_FROZEN, like the patch below.
> > >>>> Can you confirm that it works for you?
> > >>>>
> > >>>> Writing 'idle' should in general be safe, so that could be used as an
> > >>>> interim.
> > >>>>
> > >>>> Thanks,
> > >>>> NeilBrown
> > >>>>
> > >>>> diff --git a/drivers/md/md.c b/drivers/md/md.c
> > >>>> index c03d87b6890a..2c73fcb82593 100644
> > >>>> --- a/drivers/md/md.c
> > >>>> +++ b/drivers/md/md.c
> > >>>> @@ -5261,6 +5261,7 @@ static int md_set_readonly(struct mddev *mddev,
> > >>>> struct block_device *bdev)
> > >>>> printk("md: %s still in use.\n",mdname(mddev));
> > >>>> if (did_freeze) {
> > >>>> clear_bit(MD_RECOVERY_FROZEN,&mddev->recovery);
> > >>>> + set_bit(MD_RECOVERY_NEEDED,&mddev->recovery);
> > >>>> md_wakeup_thread(mddev->thread);
> > >>>> }
> > >>>> err = -EBUSY;
> > >>>> @@ -5275,6 +5276,8 @@ static int md_set_readonly(struct mddev *mddev,
> > >>>> struct block_device *bdev)
> > >>>> mddev->ro = 1;
> > >>>> set_disk_ro(mddev->gendisk, 1);
> > >>>> clear_bit(MD_RECOVERY_FROZEN,&mddev->recovery);
> > >>>> + set_bit(MD_RECOVERY_NEEDED,&mddev->recovery);
> > >>>> + md_wakeup_thread(mddev->thread);
> > >>>> sysfs_notify_dirent_safe(mddev->sysfs_state);
> > >>>> err = 0;
> > >>>> }
> > >>>> @@ -5318,6 +5321,7 @@ static int do_md_stop(struct mddev *mddev, int
> > >>>> mode,
> > >>>> mutex_unlock(&mddev->open_mutex);
> > >>>> if (did_freeze) {
> > >>>> clear_bit(MD_RECOVERY_FROZEN,&mddev->recovery);
> > >>>> + set_bit(MD_RECOVERY_NEEDED,&mddev->recovery);
> > >>>> md_wakeup_thread(mddev->thread);
> > >>>> }
> > >>>> return -EBUSY;
> > >>> Hi Neil,
> > >>>
> > >>> In my tests, the UDEV "mdadm -If" invocation fails *and* removes the
> > >>> pulled disk from the MD array. This is okay for our intentions, but I
> > >>> wanted to make sure that it's okay to skip any failed-but-not-removed
> > >>> state.
> > >>>
> > >>> Tested-by: Joe Lawrence<joe.lawrence@stratus.com>
> > >>>
> > >>> and should this have a
> > >>>
> > >>> Fixes: 30b8feb730f9 ("md/raid5: avoid deadlock when raid5 array has
> > >>> unack badblocks during md_stop_writes")
> > >>>
> > >>> tag to mark for stable?
> > >>
> > >> Hi Neil,
> > >>
> > >> Would you like me to write up a proper patch, or is this one in the
> > >> queue?
> > >>
> > > Several times over the last week I've thought that I should probably push
> > > that patch along ... but each time something else seemed more
> > > interesting.
> > > But it's a new week now. I've just posted a pull request.
> > >
> > > Thanks for the prompt (and the report and testing of course).
> > >
> > > NeilBrown
> > Hi Neil and Joe
> >
> > Any update for this? I tried this with 3.18.2 and the problem still
> > exists.
> >
> > When it tried to remove the failed disk. it find the Blocked flag in
> > rdev->flags is
> > set. So it can't remove the disk. Is this the right reason?
>
> Hi Xiao,
>
> It's been a while since I've looked at this patch, but it looks like it
> made it into 3.18, so it should be present on 3.18.2.
>
> What version of mdadm are you running?
>
> Does writing an "idle" sync_action clear this condition?
>
> Regards,
>
> -- Joe
>
> --
> 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
>
Hi Joe
Thanks for reminding me. I didn't do that. Now it can remove successfully after writing
"idle" to sync_action.
I thought wrongly that the patch referenced in this mail is fixed for the problem.
Best Regards
Xiao
^ permalink raw reply
* Re: RAID1 removing failed disk returns EBUSY
From: Joe Lawrence @ 2015-01-15 13:22 UTC (permalink / raw)
To: XiaoNi; +Cc: NeilBrown, linux-raid, Bill Kuzeja
In-Reply-To: <54B663EC.8090607@redhat.com>
On Wed, 14 Jan 2015 20:41:16 +0800
XiaoNi <xni@redhat.com> wrote:
> On 11/17/2014 07:03 AM, NeilBrown wrote:
> > On Thu, 13 Nov 2014 09:05:49 -0500 Joe Lawrence<joe.lawrence@stratus.com>
> > wrote:
> >
> >> On Wed, 29 Oct 2014 13:36:04 -0400
> >> Joe Lawrence<joe.lawrence@stratus.com> wrote:
> >>
> >>> On Wed, 29 Oct 2014 08:41:13 +1100
> >>> NeilBrown<neilb@suse.de> wrote:
> >>>
> >>>> On Mon, 27 Oct 2014 16:27:48 -0400 Joe Lawrence<joe.lawrence@stratus.com>
> >>>> wrote:
> >>>>
> >>>>> Hi Neil,
> >>>>>
> >>>>> We've encountered changes in MD and mdadm that have broken our automated
> >>>>> disk removal script. In the past, we've been able to run the following
> >>>>> after a RAID1 disk component removal:
> >>>>>
> >>>>> % echo fail> /sys/block/md3/md/dev-sdr5/state
> >>>>> % echo remove> /sys/block/md3/md/dev-sdr5/state
> >>>>>
> >>>>> However, the latest RHEL6.6 code drop has rebased to sufficiently recent
> >>>>> MD kernel and mdadm changes, in which the previous commands occasionally
> >>>>> fail like so:
> >>>>>
> >>>>> * MD array is usually resyncing or checking
> >>>>> * Component disk /dev/sdr removed via HBA sysfs PCI removal
> >>>>> * Following UDEV rule fires:
> >>>>>
> >>>>> SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}=="?*", \
> >>>>> RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"
> >>>>>
> >>>>> % mdadm --detail /dev/md3
> >>>>> /dev/md3:
> >>>>> Version : 1.1
> >>>>> Creation Time : Tue Oct 14 17:31:59 2014
> >>>>> Raid Level : raid1
> >>>>> Array Size : 25149440 (23.98 GiB 25.75 GB)
> >>>>> Used Dev Size : 25149440 (23.98 GiB 25.75 GB)
> >>>>> Raid Devices : 2
> >>>>> Total Devices : 2
> >>>>> Persistence : Superblock is persistent
> >>>>>
> >>>>> Intent Bitmap : Internal
> >>>>>
> >>>>> Update Time : Wed Oct 15 14:22:34 2014
> >>>>> State : active, degraded
> >>>>> Active Devices : 1
> >>>>> Working Devices : 1
> >>>>> Failed Devices : 1
> >>>>> Spare Devices : 0
> >>>>>
> >>>>> Name : localhost.localdomain:3
> >>>>> UUID : 40ed68ee:ba41d4cd:28c361ed:be7470b8
> >>>>> Events : 142
> >>>>>
> >>>>> Number Major Minor RaidDevice State
> >>>>> 0 65 21 0 faulty
> >>>>> 1 65 5 1 active sync /dev/sdj5
> >>>>>
> >>>>> All attempts to remove this device fail:
> >>>>>
> >>>>> % echo remove> /sys/block/md3/md/dev-sdr5/state
> >>>>> -bash: echo: write error: Device or resource busy
> >>>>>
> >>>>> This can be traced to state_store():
> >>>>>
> >>>>> } else if (cmd_match(buf, "remove")) {
> >>>>> if (rdev->raid_disk>= 0)
> >>>>> err = -EBUSY;
> >>>>>
> >>>>> After much debugging and systemtapping, I think I've figured out that the
> >>>>> sysfs scripting may fail after the following combination of changes:
> >>>>>
> >>>>> mdadm 8af530b07fce "Enhance incremental removal."
> >>>>> kernel 30b8feb730f9 "md/raid5: avoid deadlock when raid5 array has unack
> >>>>> badblocks during md_stop_writes"
> >>>>>
> >>>>> With these two changes:
> >>>>>
> >>>>> 1 - On the user side, mdadm is trying to set the array_state to read-auto
> >>>>> on incremental removal (as invoked by UDEV rule).
> >>>>>
> >>>>> 2 - Kernel side, md_set_readonly() will set the MD_RECOVERY_FROZEN flag,
> >>>>> wake up the mddev->thread and if there is a sync_thread, it will set
> >>>>> MD_RECOVERY_INTR and then wait until the sync_thread is set to NULL.
> >>>>>
> >>>>> When md_check_recovery() gets a chance to run as part of the
> >>>>> raid1d() mddev->thread, it may or may not ever get to
> >>>>> an invocation of remove_and_add_spares(), for there are but *many*
> >>>>> conditional early exits along the way -- for example, if
> >>>>> MD_RECOVERY_FROZEN is set, the following condition will bounce out of
> >>>>> the routine:
> >>>>>
> >>>>> if (!test_and_clear_bit(MD_RECOVERY_NEEDED,&mddev->recovery) ||
> >>>>> test_bit(MD_RECOVERY_FROZEN,&mddev->recovery))
> >>>>> goto unlock;
> >>>>>
> >>>>> the next time around, MD_RECOVERY_NEEDED will have been cleared, so
> >>>>> all future tests will return 0 and the negation will always take the
> >>>>> early exit path.
> >>>>>
> >>>>> Back in md_set_readonly(), it may notice that the MD is still in use,
> >>>>> so it clears the MD_RECOVERY_FROZEN and then returns -EBUSY, without
> >>>>> setting mddev->ro. But the damage has been done as conditions have
> >>>>> been set such that md_check_recovery() will never call
> >>>>> remove_and_add_spares().
> >>>>>
> >>>>> This would also explain why an "idle" sync_action clears the wedge: it
> >>>>> sets MD_RECOVERY_NEEDED allowing md_check_recovery() to continue executing
> >>>>> to remove_and_add_spares().
> >>>>>
> >>>>> As far as I can tell, this is what is happening to prevent the "remove"
> >>>>> write to /sys/block/md3/md/dev-sdr5/state from succeeding. There are
> >>>>> certainly a lot of little bit-states between disk removal, UDEV mdadm, and
> >>>>> various MD kernel threads, so apologies if I missed an important
> >>>>> transition.
> >>>>>
> >>>>> Would you consider writing "idle" to the MD array sync_action file as a
> >>>>> safe and reasonable intermediate workaround step for our script?
> >>>>>
> >>>>> And of course, any suggestions to whether this is intended behavior (ie,
> >>>>> the removed component disk is failed, but stuck in the array)?
> >>>>>
> >>>>> This is fairly easy for us to reproduce with multiple MD arrays per disk
> >>>>> (one per partition) and interrupting a raid check on all of them
> >>>>> (especially when they are delayed waiting for the first to finish) by
> >>>>> removing the component disk via sysfs PCI removal. We can provide
> >>>>> additional debug or testing if required.
> >>>>>
> >>>> Hi Joe,
> >>>> thanks for the details analysis!!
> >>>>
> >>>> I think the correct fix would be that MD_RECOVERY_NEEDED should be set after
> >>>> clearing MD_RECOVERY_FROZEN, like the patch below.
> >>>> Can you confirm that it works for you?
> >>>>
> >>>> Writing 'idle' should in general be safe, so that could be used as an interim.
> >>>>
> >>>> Thanks,
> >>>> NeilBrown
> >>>>
> >>>> diff --git a/drivers/md/md.c b/drivers/md/md.c
> >>>> index c03d87b6890a..2c73fcb82593 100644
> >>>> --- a/drivers/md/md.c
> >>>> +++ b/drivers/md/md.c
> >>>> @@ -5261,6 +5261,7 @@ static int md_set_readonly(struct mddev *mddev, struct block_device *bdev)
> >>>> printk("md: %s still in use.\n",mdname(mddev));
> >>>> if (did_freeze) {
> >>>> clear_bit(MD_RECOVERY_FROZEN,&mddev->recovery);
> >>>> + set_bit(MD_RECOVERY_NEEDED,&mddev->recovery);
> >>>> md_wakeup_thread(mddev->thread);
> >>>> }
> >>>> err = -EBUSY;
> >>>> @@ -5275,6 +5276,8 @@ static int md_set_readonly(struct mddev *mddev, struct block_device *bdev)
> >>>> mddev->ro = 1;
> >>>> set_disk_ro(mddev->gendisk, 1);
> >>>> clear_bit(MD_RECOVERY_FROZEN,&mddev->recovery);
> >>>> + set_bit(MD_RECOVERY_NEEDED,&mddev->recovery);
> >>>> + md_wakeup_thread(mddev->thread);
> >>>> sysfs_notify_dirent_safe(mddev->sysfs_state);
> >>>> err = 0;
> >>>> }
> >>>> @@ -5318,6 +5321,7 @@ static int do_md_stop(struct mddev *mddev, int mode,
> >>>> mutex_unlock(&mddev->open_mutex);
> >>>> if (did_freeze) {
> >>>> clear_bit(MD_RECOVERY_FROZEN,&mddev->recovery);
> >>>> + set_bit(MD_RECOVERY_NEEDED,&mddev->recovery);
> >>>> md_wakeup_thread(mddev->thread);
> >>>> }
> >>>> return -EBUSY;
> >>> Hi Neil,
> >>>
> >>> In my tests, the UDEV "mdadm -If" invocation fails *and* removes the
> >>> pulled disk from the MD array. This is okay for our intentions, but I
> >>> wanted to make sure that it's okay to skip any failed-but-not-removed
> >>> state.
> >>>
> >>> Tested-by: Joe Lawrence<joe.lawrence@stratus.com>
> >>>
> >>> and should this have a
> >>>
> >>> Fixes: 30b8feb730f9 ("md/raid5: avoid deadlock when raid5 array has unack badblocks during md_stop_writes")
> >>>
> >>> tag to mark for stable?
> >>
> >> Hi Neil,
> >>
> >> Would you like me to write up a proper patch, or is this one in the queue?
> >>
> > Several times over the last week I've thought that I should probably push
> > that patch along ... but each time something else seemed more interesting.
> > But it's a new week now. I've just posted a pull request.
> >
> > Thanks for the prompt (and the report and testing of course).
> >
> > NeilBrown
> Hi Neil and Joe
>
> Any update for this? I tried this with 3.18.2 and the problem still
> exists.
>
> When it tried to remove the failed disk. it find the Blocked flag in
> rdev->flags is
> set. So it can't remove the disk. Is this the right reason?
Hi Xiao,
It's been a while since I've looked at this patch, but it looks like it
made it into 3.18, so it should be present on 3.18.2.
What version of mdadm are you running?
Does writing an "idle" sync_action clear this condition?
Regards,
-- Joe
^ permalink raw reply
* Re: RAID1 removing failed disk returns EBUSY
From: XiaoNi @ 2015-01-14 12:41 UTC (permalink / raw)
To: NeilBrown; +Cc: Joe Lawrence, linux-raid, Bill Kuzeja
In-Reply-To: <20141117100349.1d1ae1fa@notabene.brown>
On 11/17/2014 07:03 AM, NeilBrown wrote:
> On Thu, 13 Nov 2014 09:05:49 -0500 Joe Lawrence<joe.lawrence@stratus.com>
> wrote:
>
>> On Wed, 29 Oct 2014 13:36:04 -0400
>> Joe Lawrence<joe.lawrence@stratus.com> wrote:
>>
>>> On Wed, 29 Oct 2014 08:41:13 +1100
>>> NeilBrown<neilb@suse.de> wrote:
>>>
>>>> On Mon, 27 Oct 2014 16:27:48 -0400 Joe Lawrence<joe.lawrence@stratus.com>
>>>> wrote:
>>>>
>>>>> Hi Neil,
>>>>>
>>>>> We've encountered changes in MD and mdadm that have broken our automated
>>>>> disk removal script. In the past, we've been able to run the following
>>>>> after a RAID1 disk component removal:
>>>>>
>>>>> % echo fail> /sys/block/md3/md/dev-sdr5/state
>>>>> % echo remove> /sys/block/md3/md/dev-sdr5/state
>>>>>
>>>>> However, the latest RHEL6.6 code drop has rebased to sufficiently recent
>>>>> MD kernel and mdadm changes, in which the previous commands occasionally
>>>>> fail like so:
>>>>>
>>>>> * MD array is usually resyncing or checking
>>>>> * Component disk /dev/sdr removed via HBA sysfs PCI removal
>>>>> * Following UDEV rule fires:
>>>>>
>>>>> SUBSYSTEM=="block", ACTION=="remove", ENV{ID_PATH}=="?*", \
>>>>> RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}"
>>>>>
>>>>> % mdadm --detail /dev/md3
>>>>> /dev/md3:
>>>>> Version : 1.1
>>>>> Creation Time : Tue Oct 14 17:31:59 2014
>>>>> Raid Level : raid1
>>>>> Array Size : 25149440 (23.98 GiB 25.75 GB)
>>>>> Used Dev Size : 25149440 (23.98 GiB 25.75 GB)
>>>>> Raid Devices : 2
>>>>> Total Devices : 2
>>>>> Persistence : Superblock is persistent
>>>>>
>>>>> Intent Bitmap : Internal
>>>>>
>>>>> Update Time : Wed Oct 15 14:22:34 2014
>>>>> State : active, degraded
>>>>> Active Devices : 1
>>>>> Working Devices : 1
>>>>> Failed Devices : 1
>>>>> Spare Devices : 0
>>>>>
>>>>> Name : localhost.localdomain:3
>>>>> UUID : 40ed68ee:ba41d4cd:28c361ed:be7470b8
>>>>> Events : 142
>>>>>
>>>>> Number Major Minor RaidDevice State
>>>>> 0 65 21 0 faulty
>>>>> 1 65 5 1 active sync /dev/sdj5
>>>>>
>>>>> All attempts to remove this device fail:
>>>>>
>>>>> % echo remove> /sys/block/md3/md/dev-sdr5/state
>>>>> -bash: echo: write error: Device or resource busy
>>>>>
>>>>> This can be traced to state_store():
>>>>>
>>>>> } else if (cmd_match(buf, "remove")) {
>>>>> if (rdev->raid_disk>= 0)
>>>>> err = -EBUSY;
>>>>>
>>>>> After much debugging and systemtapping, I think I've figured out that the
>>>>> sysfs scripting may fail after the following combination of changes:
>>>>>
>>>>> mdadm 8af530b07fce "Enhance incremental removal."
>>>>> kernel 30b8feb730f9 "md/raid5: avoid deadlock when raid5 array has unack
>>>>> badblocks during md_stop_writes"
>>>>>
>>>>> With these two changes:
>>>>>
>>>>> 1 - On the user side, mdadm is trying to set the array_state to read-auto
>>>>> on incremental removal (as invoked by UDEV rule).
>>>>>
>>>>> 2 - Kernel side, md_set_readonly() will set the MD_RECOVERY_FROZEN flag,
>>>>> wake up the mddev->thread and if there is a sync_thread, it will set
>>>>> MD_RECOVERY_INTR and then wait until the sync_thread is set to NULL.
>>>>>
>>>>> When md_check_recovery() gets a chance to run as part of the
>>>>> raid1d() mddev->thread, it may or may not ever get to
>>>>> an invocation of remove_and_add_spares(), for there are but *many*
>>>>> conditional early exits along the way -- for example, if
>>>>> MD_RECOVERY_FROZEN is set, the following condition will bounce out of
>>>>> the routine:
>>>>>
>>>>> if (!test_and_clear_bit(MD_RECOVERY_NEEDED,&mddev->recovery) ||
>>>>> test_bit(MD_RECOVERY_FROZEN,&mddev->recovery))
>>>>> goto unlock;
>>>>>
>>>>> the next time around, MD_RECOVERY_NEEDED will have been cleared, so
>>>>> all future tests will return 0 and the negation will always take the
>>>>> early exit path.
>>>>>
>>>>> Back in md_set_readonly(), it may notice that the MD is still in use,
>>>>> so it clears the MD_RECOVERY_FROZEN and then returns -EBUSY, without
>>>>> setting mddev->ro. But the damage has been done as conditions have
>>>>> been set such that md_check_recovery() will never call
>>>>> remove_and_add_spares().
>>>>>
>>>>> This would also explain why an "idle" sync_action clears the wedge: it
>>>>> sets MD_RECOVERY_NEEDED allowing md_check_recovery() to continue executing
>>>>> to remove_and_add_spares().
>>>>>
>>>>> As far as I can tell, this is what is happening to prevent the "remove"
>>>>> write to /sys/block/md3/md/dev-sdr5/state from succeeding. There are
>>>>> certainly a lot of little bit-states between disk removal, UDEV mdadm, and
>>>>> various MD kernel threads, so apologies if I missed an important
>>>>> transition.
>>>>>
>>>>> Would you consider writing "idle" to the MD array sync_action file as a
>>>>> safe and reasonable intermediate workaround step for our script?
>>>>>
>>>>> And of course, any suggestions to whether this is intended behavior (ie,
>>>>> the removed component disk is failed, but stuck in the array)?
>>>>>
>>>>> This is fairly easy for us to reproduce with multiple MD arrays per disk
>>>>> (one per partition) and interrupting a raid check on all of them
>>>>> (especially when they are delayed waiting for the first to finish) by
>>>>> removing the component disk via sysfs PCI removal. We can provide
>>>>> additional debug or testing if required.
>>>>>
>>>> Hi Joe,
>>>> thanks for the details analysis!!
>>>>
>>>> I think the correct fix would be that MD_RECOVERY_NEEDED should be set after
>>>> clearing MD_RECOVERY_FROZEN, like the patch below.
>>>> Can you confirm that it works for you?
>>>>
>>>> Writing 'idle' should in general be safe, so that could be used as an interim.
>>>>
>>>> Thanks,
>>>> NeilBrown
>>>>
>>>> diff --git a/drivers/md/md.c b/drivers/md/md.c
>>>> index c03d87b6890a..2c73fcb82593 100644
>>>> --- a/drivers/md/md.c
>>>> +++ b/drivers/md/md.c
>>>> @@ -5261,6 +5261,7 @@ static int md_set_readonly(struct mddev *mddev, struct block_device *bdev)
>>>> printk("md: %s still in use.\n",mdname(mddev));
>>>> if (did_freeze) {
>>>> clear_bit(MD_RECOVERY_FROZEN,&mddev->recovery);
>>>> + set_bit(MD_RECOVERY_NEEDED,&mddev->recovery);
>>>> md_wakeup_thread(mddev->thread);
>>>> }
>>>> err = -EBUSY;
>>>> @@ -5275,6 +5276,8 @@ static int md_set_readonly(struct mddev *mddev, struct block_device *bdev)
>>>> mddev->ro = 1;
>>>> set_disk_ro(mddev->gendisk, 1);
>>>> clear_bit(MD_RECOVERY_FROZEN,&mddev->recovery);
>>>> + set_bit(MD_RECOVERY_NEEDED,&mddev->recovery);
>>>> + md_wakeup_thread(mddev->thread);
>>>> sysfs_notify_dirent_safe(mddev->sysfs_state);
>>>> err = 0;
>>>> }
>>>> @@ -5318,6 +5321,7 @@ static int do_md_stop(struct mddev *mddev, int mode,
>>>> mutex_unlock(&mddev->open_mutex);
>>>> if (did_freeze) {
>>>> clear_bit(MD_RECOVERY_FROZEN,&mddev->recovery);
>>>> + set_bit(MD_RECOVERY_NEEDED,&mddev->recovery);
>>>> md_wakeup_thread(mddev->thread);
>>>> }
>>>> return -EBUSY;
>>> Hi Neil,
>>>
>>> In my tests, the UDEV "mdadm -If" invocation fails *and* removes the
>>> pulled disk from the MD array. This is okay for our intentions, but I
>>> wanted to make sure that it's okay to skip any failed-but-not-removed
>>> state.
>>>
>>> Tested-by: Joe Lawrence<joe.lawrence@stratus.com>
>>>
>>> and should this have a
>>>
>>> Fixes: 30b8feb730f9 ("md/raid5: avoid deadlock when raid5 array has unack badblocks during md_stop_writes")
>>>
>>> tag to mark for stable?
>>
>> Hi Neil,
>>
>> Would you like me to write up a proper patch, or is this one in the queue?
>>
> Several times over the last week I've thought that I should probably push
> that patch along ... but each time something else seemed more interesting.
> But it's a new week now. I've just posted a pull request.
>
> Thanks for the prompt (and the report and testing of course).
>
> NeilBrown
Hi Neil and Joe
Any update for this? I tried this with 3.18.2 and the problem still
exists.
When it tried to remove the failed disk. it find the Blocked flag in
rdev->flags is
set. So it can't remove the disk. Is this the right reason?
Best Regards
Xiao
^ permalink raw reply
* RE: md_raid5 using 100% CPU and hang with status resync=PENDING, if a drive is removed during initialization
From: Manibalan P @ 2015-01-14 10:24 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: neilb@suse.de, linux-raid
In-Reply-To: <20141231164800.GL19091@reaktio.net>
Dear Pasi,
Could you able to find something on this issue.
Thanks,
Manibalan.
-----Original Message-----
From: Manibalan P
Sent: Friday, January 2, 2015 12:08 PM
To: 'Pasi Kärkkäinen'
Cc: neilb@suse.de; linux-raid
Subject: RE: md_raid5 using 100% CPU and hang with status resync=PENDING, if a drive is removed during initialization
Dear Pasi,
I have add the bug in https://bugzilla.redhat.com/show_bug.cgi?id=1178080
Thanks,
Manibalan.
-----Original Message-----
From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
Sent: Wednesday, December 31, 2014 10:18 PM
To: Manibalan P
Cc: neilb@suse.de; linux-raid
Subject: Re: md_raid5 using 100% CPU and hang with status resync=PENDING, if a drive is removed during initialization
On Tue, Dec 30, 2014 at 11:06:47AM +0000, Manibalan P wrote:
> Dear Neil,
>
Hello,
> Few this for you kind attention,
> 1. I tried the same test with FC11 (2.6.32 kernel before MD code
> change). And the issue is not there 2. But with Centos 6.4 (2.6.32 kernel after MD code change). I am getting this issue.. and also even with the latest kernel, able to reproduce the issue.
>
> Also, a bug has been raise with RHEL regarding this issue. Please find the bug link "https://access.redhat.com/support/cases/#/case/01320319"
>
That support case URL can only be accessed by you and Redhat. Do you happen to have a public bugzilla link?
Thanks,
-- Pasi
> Thanks,
> Manibalan.
>
> -----Original Message-----
> From: Manibalan P
> Sent: Wednesday, December 24, 2014 12:15 PM
> To: neilb@suse.de; 'linux-raid'
> Cc: 'NeilBrown'
> Subject: RE: md_raid5 using 100% CPU and hang with status
> resync=PENDING, if a drive is removed during initialization
>
>
> Dear Neil,
>
> Few this for you kind attention,
> 1. I tried the same tesst with FC11 (2.6 kernel before MD code change). And the issue is not there 2. But with Centos 6.4 (2.6 after MD code change). I am getting this issue.. and also even with the latest kernel, able to reproduce the issue.
>
> Thanks,
> Manibalan.
>
> -----Original Message-----
> From: Manibalan P
> Sent: Thursday, December 18, 2014 11:38 AM
> To: 'linux-raid'
> Cc: 'NeilBrown'; Vijayarankan Muthirisavengopal; Dinakaran N
> Subject: RE: md_raid5 using 100% CPU and hang with status
> resync=PENDING, if a drive is removed during initialization
>
> Dear neil,
>
> I also compiled the latest 3.18 kernel on CentOS 6.4 with GIT MD pull patches form 3.19, that also ran in to the same issue after removing a drive during resync.
>
> Dec 17 19:07:32 ITX002590129362 kernel: Linux version 3.18.0 (root@mycentos6) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Dec 17 15:59:09 EST 2014 Dec 17 19:07:32 ITX002590129362 kernel: Command line: ro root=/dev/md255 rd_NO_LVM rd_NO_DM rhgb quiet md_mod.start_ro=1 nmi_watchdog=1 md_mod.start_dirty_degraded=1 ??? Dec 17 19:10:15 ITX002590129362 kernel: md: bind<sda6> Dec 17 19:10:15 ITX002590129362 kernel: md: bind<sdb6> Dec 17 19:10:15 ITX002590129362 kernel: md: bind<sdc6> Dec 17 19:10:15 ITX002590129362 kernel: md: bind<sdh6> Dec 17 19:10:15 ITX002590129362 kernel: md: bind<sdi6> Dec 17 19:10:15 ITX002590129362 kernel: md: bind<sdj6> Dec 17 19:10:15 ITX002590129362 kernel: async_tx: api initialized (async) Dec 17 19:10:15 ITX002590129362 kernel: xor: measuring software checksum speed
> Dec 17 19:10:15 ITX002590129362 kernel: prefetch64-sse: 10048.000 MB/sec
> Dec 17 19:10:15 ITX002590129362 kernel: generic_sse: 8824.000 MB/sec
> Dec 17 19:10:15 ITX002590129362 kernel: xor: using function: prefetch64-sse (10048.000 MB/sec)
> Dec 17 19:10:15 ITX002590129362 kernel: raid6: sse2x1 5921 MB/s
> Dec 17 19:10:15 ITX002590129362 kernel: raid6: sse2x2 6933 MB/s
> Dec 17 19:10:15 ITX002590129362 kernel: raid6: sse2x4 7476 MB/s
> Dec 17 19:10:15 ITX002590129362 kernel: raid6: using algorithm sse2x4
> (7476 MB/s) Dec 17 19:10:15 ITX002590129362 kernel: raid6: using
> ssse3x2 recovery algorithm Dec 17 19:10:15 ITX002590129362 kernel: md:
> raid6 personality registered for level 6 Dec 17 19:10:15
> ITX002590129362 kernel: md: raid5 personality registered for level 5
> Dec 17 19:10:15 ITX002590129362 kernel: md: raid4 personality
> registered for level 4 Dec 17 19:10:15 ITX002590129362 kernel:
> md/raid:md0: not clean -- starting background reconstruction Dec 17
> 19:10:15 ITX002590129362 kernel: md/raid:md0: device sdj6 operational
> as raid disk 5 Dec 17 19:10:15 ITX002590129362 kernel: md/raid:md0:
> device sdi6 operational as raid disk 4 Dec 17 19:10:15 ITX002590129362
> kernel: md/raid:md0: device sdh6 operational as raid disk 3 Dec 17
> 19:10:15 ITX002590129362 kernel: md/raid:md0: device sdc6 operational
> as raid disk 2 Dec 17 19:10:15 ITX002590129362 kernel: md/raid:md0:
> device sdb6 operational as raid disk 1 Dec 17 19:10:15 ITX002590129362
> kernel: md/ra
> id:md0: device sda6 operational as raid disk 0 Dec 17 19:10:15 ITX002590129362 kernel: md/raid:md0: allocated 0kB Dec 17 19:10:15 ITX002590129362 kernel: md/raid:md0: raid level 5 active with 6 out of 6 devices, algorithm 2 Dec 17 19:10:15 ITX002590129362 kernel: md0: detected capacity change from 0 to 2361059573760 Dec 17 19:10:15 ITX002590129362 kernel: md0: unknown partition table Dec 17 19:10:35 ITX002590129362 kernel: md: md0 switched to read-write mode.
> Dec 17 19:10:35 ITX002590129362 kernel: md: resync of RAID array md0 Dec 17 19:10:35 ITX002590129362 kernel: md: minimum _guaranteed_ speed: 10000 KB/sec/disk.
> Dec 17 19:10:35 ITX002590129362 kernel: md: using maximum available idle IO bandwidth (but not more than 30000 KB/sec) for resync.
> Dec 17 19:10:35 ITX002590129362 kernel: md: using 128k window, over a total of 461144448k.
> ???
> Started IOs using fio tool.
>
> ./fio --name=md0 --filename=/dev/md0 --thread --numjobs=10 --direct=1
> --group_reporting --unlink=0 --loops=1 --offset=0 --randrepeat=1
> --norandommap --scramble_buffers=1 --stonewall --ioengine=libaio
> --rw=randwrite --bs=8704 --iodepth=4000 --runtime=3000
> --blockalign=512
>
> ???
> Removed a drive form the system..
>
> Dec 17 19:13:23 ITX002590129362 kernel: mpt2sas0: log_info(0x31120101): originator(PL), code(0x12), sub_code(0x0101) Dec 17 19:13:23 ITX002590129362 kernel: mpt2sas0: log_info(0x31120101): originator(PL), code(0x12), sub_code(0x0101) Dec 17 19:13:23 ITX002590129362 kernel: mpt2sas0: log_info(0x31120101): originator(PL), code(0x12), sub_code(0x0101) Dec 17 19:13:23 ITX002590129362 kernel: mpt2sas0: log_info(0x31120101): originator(PL), code(0x12), sub_code(0x0101) ..
> Dec 17 19:13:23 ITX002590129362 kernel: sd 0:0:7:0: [sdh] Dec 17 19:13:23 ITX002590129362 kernel: Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK Dec 17 19:13:23 ITX002590129362 kernel: sd 0:0:7:0: [sdh] CDB:
> Dec 17 19:13:23 ITX002590129362 kernel: Read(10): 28 00 02 69 03 70 00 00 10 00 Dec 17 19:13:23 ITX002590129362 kernel: blk_update_request: I/O error, dev sdh, sector 40436592 Dec 17 19:13:23 ITX002590129362 kernel: sd 0:0:7:0: [sdh] Dec 17 19:13:23 ITX002590129362 kernel: Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK Dec 17 19:13:23 ITX002590129362 kernel: sd 0:0:7:0: [sdh] CDB:
> Dec 17 19:13:23 ITX002590129362 kernel: Read(10): 28 00 0c 51 b3 d0 00 00 18 00 Dec 17 19:13:23 ITX002590129362 kernel: blk_update_request: I/O error, dev sdh, sector 206681040 Dec 17 19:13:23 ITX002590129362 kernel: sd 0:0:7:0: [sdh] Dec 17 19:13:23 ITX002590129362 kernel: Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK Dec 17 19:13:23 ITX002590129362 kernel: sd 0:0:7:0: [sdh] CDB:
> Dec 17 19:13:23 ITX002590129362 kernel: Read(10): 28 00 0c 3a f3 40 00 00 18 00 Dec 17 19:13:23 ITX002590129362 kernel: blk_update_request: I/O error, dev sdh, sector 205189952 Dec 17 19:13:23 ITX002590129362 kernel: sd 0:0:7:0: [sdh] Dec 17 19:13:23 ITX002590129362 kernel: Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK ??? Dec 17 19:13:25 ITX002590129362 kernel: sd 0:0:7:0: [sdh] CDB:
> Dec 17 19:13:25 ITX002590129362 kernel: Read(10): 28 00 26 8d eb 00 00 00 08 00 Dec 17 19:13:25 ITX002590129362 kernel: sd 0:0:7:0: [sdh] Dec 17 19:13:25 ITX002590129362 kernel: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK Dec 17 19:13:25 ITX002590129362 kernel: sd 0:0:7:0: [sdh] CDB:
> Dec 17 19:13:25 ITX002590129362 kernel: Read(10): 28 00 26 8d eb f0 00 00 10 00 Dec 17 19:13:25 ITX002590129362 aghswap: devpath [0:0:7:0] action [remove] devtype [scsi_disk] Dec 17 19:13:25 ITX002590129362 aghswap: MHSA: Sent event 0 0 7 0 remove scsi_disk Dec 17 19:13:25 ITX002590129362 kernel: mpt2sas0: removing handle(0x0011), sas_addr(0x500605ba0101e305) Dec 17 19:13:25 ITX002590129362 kernel: md/raid:md0: Disk failure on sdh6, disabling device.
> Dec 17 19:13:25 ITX002590129362 kernel: md/raid:md0: Operation continuing on 5 devices.
> Dec 17 19:13:25 ITX002590129362 kernel: md: md0: resync interrupted.
> Dec 17 19:13:25 ITX002590129362 kernel: md: checkpointing resync of md0.
> ..
> Log messages after enabling debufgs on raid5.c, it is getting repeated continuously.
>
> __get_priority_stripe: handle: busy hold: empty full_writes: 0
> bypass_count: 0
> __get_priority_stripe: handle: busy hold: empty full_writes: 0
> bypass_count: 0
> __get_priority_stripe: handle: busy hold: empty full_writes: 0
> bypass_count: 0
> __get_priority_stripe: handle: busy hold: empty full_writes: 0
> bypass_count: 0
> __get_priority_stripe: handle: busy hold: empty full_writes: 0 bypass_count: 0 handling stripe 273480328, state=0x2041 cnt=1, pd_idx=5, qd_idx=-1 , check:0, reconstruct:0
> check 5: state 0x10 read (null) write (null) written (null)
> check 4: state 0x11 read (null) write (null) written (null)
> check 3: state 0x0 read (null) write (null) written (null)
> check 2: state 0x11 read (null) write (null) written (null)
> check 1: state 0x11 read (null) write (null) written (null)
> check 0: state 0x18 read (null) write ffff8808029b6b00 written (null)
> locked=0 uptodate=3 to_read=0 to_write=1 failed=1 failed_num=3,-1 force RCW max_degraded=1, recovery_cp=7036944 sh->sector=273480328 for sector 273480328, rmw=2 rcw=1 handling stripe 65238568, state=0x2041 cnt=1, pd_idx=5, qd_idx=-1 , check:0, reconstruct:0
> check 5: state 0x10 read (null) write (null) written (null)
> check 4: state 0x11 read (null) write (null) written (null)
> check 3: state 0x0 read (null) write (null) written (null)
> check 2: state 0x18 read (null) write ffff88081a956b00 written (null)
> check 1: state 0x11 read (null) write (null) written (null)
> check 0: state 0x11 read (null) write (null) written (null)
> locked=0 uptodate=3 to_read=0 to_write=1 failed=1 failed_num=3,-1 force RCW max_degraded=1, recovery_cp=7036944 sh->sector=65238568 for sector 65238568, rmw=2 rcw=1 handling stripe 713868672, state=0x2041 cnt=1, pd_idx=4, qd_idx=-1 , check:0, reconstruct:0
> check 5: state 0x11 read (null) write (null) written (null)
> check 4: state 0x10 read (null) write (null) written (null)
> check 3: state 0x0 read (null) write (null) written (null)
> check 2: state 0x18 read (null) write ffff88081f020100 written (null)
> check 1: state 0x11 read (null) write (null) written (null)
> check 0: state 0x11 read (null) write (null) written (null)
> locked=0 uptodate=3 to_read=0 to_write=1 failed=1 failed_num=3,-1 force RCW max_degraded=1, recovery_cp=7036944 sh->sector=713868672 for sector 713868672, rmw=2 rcw=1 handling stripe 729622496, state=0x2041 cnt=1, pd_idx=2, qd_idx=-1 , check:0, reconstruct:0
> check 5: state 0x11 read (null) write (null) written (null)
> check 4: state 0x11 read (null) write (null) written (null)
> check 3: state 0x0 read (null) write (null) written (null)
> check 2: state 0x10 read (null) write (null) written (null)
> check 1: state 0x18 read (null) write ffff88081b9bae00 written (null)
> check 0: state 0x11 read (null) write (null) written (null)
> locked=0 uptodate=3 to_read=0 to_write=1 failed=1 failed_num=3,-1 force RCW max_degraded=1, recovery_cp=7036944 sh->sector=729622496 for sector 729622496, rmw=2 rcw=1 handling stripe 729622504, state=0x2041 cnt=1, pd_idx=2, qd_idx=-1 , check:0, reconstruct:0
> check 5: state 0x11 read (null) write (null) written (null)
> check 4: state 0x11 read (null) write (null) written (null)
> check 3: state 0x0 read (null) write (null) written (null)
> check 2: state 0x10 read (null) write (null) written (null)
> check 1: state 0x18 read (null) write ffff88081b9bae00 written (null)
> check 0: state 0x11 read (null) write (null) written (null)
> locked=0 uptodate=3 to_read=0 to_write=1 failed=1 failed_num=3,-1 force RCW max_degraded=1, recovery_cp=7036944 sh->sector=729622504 for sector 729622504, rmw=2 rcw=1 handling stripe 245773680, state=0x2041 cnt=1, pd_idx=0, qd_idx=-1 , check:0, reconstruct:0
> check 5: state 0x11 read (null) write (null) written (null)
> check 4: state 0x11 read (null) write (null) written (null)
> check 3: state 0x0 read (null) write (null) written (null)
> check 2: state 0x11 read (null) write (null) written (null)
> check 1: state 0x18 read (null) write ffff88081cab7a00 written (null)
> check 0: state 0x10 read (null) write (null) written (null)
> locked=0 uptodate=3 to_read=0 to_write=1 failed=1 failed_num=3,-1 force RCW max_degraded=1, recovery_cp=7036944 sh->sector=245773680 for sector 245773680, rmw=2 rcw=1 handling stripe 867965560, state=0x2041 cnt=1, pd_idx=1, qd_idx=-1 , check:0, reconstruct:0
> check 5: state 0x11 read (null) write (null) written (null)
> check 4: state 0x11 read (null) write (null) written (null)
> check 3: state 0x0 read (null) write (null) written (null)
> check 2: state 0x18 read (null) write ffff880802b2bf00 written (null)
> check 1: state 0x10 read (null) write (null) written (null)
> check 0: state 0x11 read (null) write (null) written (null)
> locked=0 uptodate=3 to_read=0 to_write=1 failed=1 failed_num=3,-1 force RCW max_degraded=1, recovery_cp=7036944 sh->sector=867965560 for sector 867965560, rmw=2 rcw=1 handling stripe 550162280, state=0x2041 cnt=1, pd_idx=2, qd_idx=-1 , check:0, reconstruct:0
> check 5: state 0x11 read (null) write (null) written (null)
> check 4: state 0x18 read (null) write ffff880802b08800 written (null)
> check 3: state 0x0 read (null) write (null) written (null)
> check 2: state 0x10 read (null) write (null) written (null)
> check 1: state 0x11 read (null) write (null) written (null)
> check 0: state 0x11 read (null) write (null) written (null)
> locked=0 uptodate=3 to_read=0 to_write=1 failed=1 failed_num=3,-1
> force RCW max_degraded=1, recovery_cp=7036944 sh->sector=550162280 for
> sector 550162280, rmw=2 rcw=1
>
>
> Thanks,
> Manibalan
>
>
> -----Original Message-----
> From: Manibalan P
> Sent: Wednesday, December 17, 2014 12:11 PM
> To: 'linux-raid'
> Cc: 'NeilBrown'; Vijayarankan Muthirisavengopal; Dinakaran N
> Subject: RE: md_raid5 using 100% CPU and hang with status
> resync=PENDING, if a drive is removed during initialization
>
> Dear Neil,
>
> The same Issue is reproducible in the latest upstream kernel also.
>
> Tested in "3.17.6" latest stable upstream kernel and find the same issue.
>
> [root@root ~]# modinfo raid456
> filename: /lib/modules/3.17.6/kernel/drivers/md/raid456.ko
> alias: raid6
> alias: raid5
> alias: md-level-6
> alias: md-raid6
> alias: md-personality-8
> alias: md-level-4
> alias: md-level-5
> alias: md-raid4
> alias: md-raid5
> alias: md-personality-4
> description: RAID4/5/6 (striping with parity) personality for MD
> license: GPL
> srcversion: 0EEF680023FDC7410F7989A
> depends: async_raid6_recov,async_pq,async_tx,async_memcpy,async_xor
> intree: Y
> vermagic: 3.17.6 SMP mod_unload modversions
> parm: devices_handle_discard_safely:Set to Y if all devices in each array reliably return zeroes on reads from discarded regions (bool)
>
> Thanks,
> Manibalan.
>
> -----Original Message-----
> From: Manibalan P
> Sent: Wednesday, December 17, 2014 12:01 PM
> To: 'linux-raid'
> Cc: 'NeilBrown'
> Subject: RE: md_raid5 using 100% CPU and hang with status
> resync=PENDING, if a drive is removed during initialization
>
> Dear Neil,
>
> We are facing IO struck issue with raid5 in the following scenario.
> (please see the attachment for the complete information) In RAID5
> array, if a drive is removed while initialization and the same time if
> IO is happening to that md. Then IO is getting struck, and md_raid5
> thread is using 100 % of CPU. Also the md state showing as
> resync=PENDING
>
> Kernel : Issue found in the following kernels RHEL 6.5
> (2.6.32-431.el6.x86_64) CentOS 7 (kernel-3.10.0-123.13.1.el7.x86_64)
>
> Steps to Reproduce the issue:
>
> 1. Created a raid 5 md with 4 drives using the below mdadm command.
> mdadm -C /dev/md0 -c 64 -l 5 -f -n 4 -e 1.2 /dev/sdb6 /dev/sdc6
> /dev/sdd6 /dev/sde6
>
> 2. Make the md writable
> mdadm ???readwrite /dev/md0
>
> 3. Now md will start initialization
>
> 4. Run FIO Tool, the the below said configuration /usr/bin/fio
> --name=md0 --filename=/dev/md0 --thread --numjobs=10 --direct=1
> --group_reporting --unlink=0 --loops=1 --offset=0 --randrepeat=1
> --norandommap --scramble_buffers=1 --stonewall --ioengine=libaio
> --rw=randwrite --bs=8704 --iodepth=4000 --runtime=3000
> --blockalign=512
>
> 4. During MD initialzing, remove a drive(either using MDADM set
> faulty/remove or remove manually)
>
> 5. Now the IO will struck, and cat /proc/mdstat shows states with
> resync=PENDING
> ----------------------------------------------------------------------
> ----------------------- top - output show, md_raid5 using 100% cpu
>
> top - 17:55:06 up 1:09, 3 users, load average: 11.98, 8.53, 3.99
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 2690 root 20 0 0 0 0 R 100.0 0.0 6:44.41 md0_raid5
> ----------------------------------------------------------------------
> -----------------------
> dmesg - show the stack trace
>
> INFO: task fio:2715 blocked for more than 120 seconds.
> Not tainted 2.6.32-431.el6.x86_64 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> fio D 000000000000000a 0 2715 2654 0x00000080
> ffff88043b623598 0000000000000082 0000000000000000 ffffffff81058d53
> ffff88043b623548 ffff880230e49cc0 ffff8802389aa228 ffff88043b2ad1b8
> ffff88043b40b098 ffff88043b623fd8 000000000000fbc8 ffff88043b40b098 Call Trace:
> [<ffffffff81058d53>] ? __wake_up+0x53/0x70 [<ffffffffa0304146>]
> get_active_stripe+0x236/0x830 [raid456] [<ffffffff81065df0>] ?
> default_wake_function+0x0/0x20 [<ffffffff8109b5ce>] ?
> prepare_to_wait+0x4e/0x80 [<ffffffffa0308e15>]
> make_request+0x1b5/0xc6c [raid456] [<ffffffff8109b2a0>] ?
> autoremove_wake_function+0x0/0x40 [<ffffffff8140fa39>] ?
> md_wakeup_thread+0x39/0x70 [<ffffffff81415b41>]
> md_make_request+0xe1/0x230 [<ffffffffa0308f66>] ?
> make_request+0x306/0xc6c [raid456] [<ffffffff81266c50>]
> generic_make_request+0x240/0x5a0 [<ffffffff811220e5>] ?
> mempool_alloc_slab+0x15/0x20 [<ffffffff81122283>] ?
> mempool_alloc+0x63/0x140 [<ffffffff81267020>] submit_bio+0x70/0x120
> [<ffffffff811c767a>] do_direct_IO+0x7ca/0xfa0 [<ffffffff811c8196>]
> __blockdev_direct_IO_newtrunc+0x346/0x1270
> [<ffffffff811c4330>] ? blkdev_get_block+0x0/0x20 [<ffffffff811c9137>]
> __blockdev_direct_IO+0x77/0xe0 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff811c53b7>]
> blkdev_direct_IO+0x57/0x60 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff81120552>]
> generic_file_direct_write+0xc2/0x190
> [<ffffffff81121e71>] __generic_file_aio_write+0x3a1/0x490
> [<ffffffff811d64c0>] ? aio_read_evt+0xa0/0x170 [<ffffffff811c490c>]
> blkdev_aio_write+0x3c/0xa0 [<ffffffff811c48d0>] ?
> blkdev_aio_write+0x0/0xa0 [<ffffffff811d4f64>]
> aio_rw_vect_retry+0x84/0x200 [<ffffffff811d6924>]
> aio_run_iocb+0x64/0x170 [<ffffffff811d7d51>] do_io_submit+0x291/0x920
> [<ffffffff811d83f0>] sys_io_submit+0x10/0x20 [<ffffffff8100b072>]
> system_call_fastpath+0x16/0x1b
> INFO: task fio:2717 blocked for more than 120 seconds.
> Not tainted 2.6.32-431.el6.x86_64 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> fio D 0000000000000004 0 2717 2654 0x00000080
> ffff880439e97698 0000000000000082 ffff880439e97628 ffffffff81058d53
> ffff880439e97648 ffff880230e49cc0 ffff8802389aa228 ffff88043b2ad1b8
> ffff88043b0adab8 ffff880439e97fd8 000000000000fbc8 ffff88043b0adab8 Call Trace:
> [<ffffffff81058d53>] ? __wake_up+0x53/0x70 [<ffffffffa030334b>] ?
> md_raid5_unplug_device+0x7b/0x100 [raid456] [<ffffffffa0304146>]
> get_active_stripe+0x236/0x830 [raid456] [<ffffffff81065df0>] ?
> default_wake_function+0x0/0x20 [<ffffffff8109b5ce>] ?
> prepare_to_wait+0x4e/0x80 [<ffffffffa0308e15>]
> make_request+0x1b5/0xc6c [raid456] [<ffffffff8109b2a0>] ?
> autoremove_wake_function+0x0/0x40 [<ffffffff811220e5>] ?
> mempool_alloc_slab+0x15/0x20 [<ffffffff81415b41>]
> md_make_request+0xe1/0x230 [<ffffffff811c32f0>] ?
> __bio_add_page+0x110/0x230 [<ffffffff81266c50>]
> generic_make_request+0x240/0x5a0 [<ffffffff811c742c>] ?
> do_direct_IO+0x57c/0xfa0 [<ffffffff81267020>] submit_bio+0x70/0x120
> [<ffffffff811c8e50>] __blockdev_direct_IO_newtrunc+0x1000/0x1270
> [<ffffffff811c4330>] ? blkdev_get_block+0x0/0x20 [<ffffffff811c9137>]
> __blockdev_direct_IO+0x77/0xe0 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff811c53b7>]
> blkdev_direct_IO+0x57/0x60 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff81120552>]
> generic_file_direct_write+0xc2/0x190
> [<ffffffff81121e71>] __generic_file_aio_write+0x3a1/0x490
> [<ffffffff811d64c0>] ? aio_read_evt+0xa0/0x170 [<ffffffff811c490c>]
> blkdev_aio_write+0x3c/0xa0 [<ffffffff811c48d0>] ?
> blkdev_aio_write+0x0/0xa0 [<ffffffff811d4f64>]
> aio_rw_vect_retry+0x84/0x200 [<ffffffff811d6924>]
> aio_run_iocb+0x64/0x170 [<ffffffff811d7d51>] do_io_submit+0x291/0x920
> [<ffffffff811d83f0>] sys_io_submit+0x10/0x20 [<ffffffff8100b072>]
> system_call_fastpath+0x16/0x1b
> INFO: task fio:2718 blocked for more than 120 seconds.
> Not tainted 2.6.32-431.el6.x86_64 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> fio D 0000000000000005 0 2718 2654 0x00000080
> ffff88043bc13698 0000000000000082 ffff88043bc13628 ffffffff81058d53
> ffff88043bc13648 ffff880230e49cc0 ffff8802389aa228 ffff88043b2ad1b8
> ffff88043b0ad058 ffff88043bc13fd8 000000000000fbc8 ffff88043b0ad058 Call Trace:
> [<ffffffff81058d53>] ? __wake_up+0x53/0x70 [<ffffffffa030334b>] ?
> md_raid5_unplug_device+0x7b/0x100 [raid456] [<ffffffffa0304146>]
> get_active_stripe+0x236/0x830 [raid456] [<ffffffff81065df0>] ?
> default_wake_function+0x0/0x20 [<ffffffff8109b5ce>] ?
> prepare_to_wait+0x4e/0x80 [<ffffffffa0308e15>]
> make_request+0x1b5/0xc6c [raid456] [<ffffffff8109b2a0>] ?
> autoremove_wake_function+0x0/0x40 [<ffffffff811220e5>] ?
> mempool_alloc_slab+0x15/0x20 [<ffffffff81415b41>]
> md_make_request+0xe1/0x230 [<ffffffff811c3fd2>] ?
> bvec_alloc_bs+0x62/0x110 [<ffffffff811c32f0>] ?
> __bio_add_page+0x110/0x230 [<ffffffff81266c50>]
> generic_make_request+0x240/0x5a0 [<ffffffff811c742c>] ?
> do_direct_IO+0x57c/0xfa0 [<ffffffff81267020>] submit_bio+0x70/0x120
> [<ffffffff811c8e50>] __blockdev_direct_IO_newtrunc+0x1000/0x1270
> [<ffffffff811c4330>] ? blkdev_get_block+0x0/0x20 [<ffffffff811c9137>]
> __blockdev_direct_IO+0x77/0xe0 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff811c53b7>]
> blkdev_direct_IO+0x57/0x60 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff81120552>]
> generic_file_direct_write+0xc2/0x190
> [<ffffffff81121e71>] __generic_file_aio_write+0x3a1/0x490
> [<ffffffff811d64c0>] ? aio_read_evt+0xa0/0x170 [<ffffffff811c490c>]
> blkdev_aio_write+0x3c/0xa0 [<ffffffff811c48d0>] ?
> blkdev_aio_write+0x0/0xa0 [<ffffffff811d4f64>]
> aio_rw_vect_retry+0x84/0x200 [<ffffffff811d6924>]
> aio_run_iocb+0x64/0x170 [<ffffffff811d7d51>] do_io_submit+0x291/0x920
> [<ffffffff811d83f0>] sys_io_submit+0x10/0x20 [<ffffffff8100b072>]
> system_call_fastpath+0x16/0x1b
> INFO: task fio:2719 blocked for more than 120 seconds.
> Not tainted 2.6.32-431.el6.x86_64 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> fio D 0000000000000001 0 2719 2654 0x00000080
> ffff880439ebb698 0000000000000082 ffff880439ebb628 ffffffff81058d53
> ffff880439ebb648 ffff880230e49cc0 ffff8802389aa228 ffff88043b2ad1b8
> ffff88043b0ac5f8 ffff880439ebbfd8 000000000000fbc8 ffff88043b0ac5f8 Call Trace:
> [<ffffffff81058d53>] ? __wake_up+0x53/0x70 [<ffffffffa030334b>] ?
> md_raid5_unplug_device+0x7b/0x100 [raid456] [<ffffffffa0304146>]
> get_active_stripe+0x236/0x830 [raid456] [<ffffffff81065df0>] ?
> default_wake_function+0x0/0x20 [<ffffffff8109b5ce>] ?
> prepare_to_wait+0x4e/0x80 [<ffffffffa0308e15>]
> make_request+0x1b5/0xc6c [raid456] [<ffffffff8109b2a0>] ?
> autoremove_wake_function+0x0/0x40 [<ffffffff811220e5>] ?
> mempool_alloc_slab+0x15/0x20 [<ffffffff81415b41>]
> md_make_request+0xe1/0x230 [<ffffffff811c3fd2>] ?
> bvec_alloc_bs+0x62/0x110 [<ffffffff811c32f0>] ?
> __bio_add_page+0x110/0x230 [<ffffffff81266c50>]
> generic_make_request+0x240/0x5a0 [<ffffffff811c742c>] ?
> do_direct_IO+0x57c/0xfa0 [<ffffffff81267020>] submit_bio+0x70/0x120
> [<ffffffff811c8acd>] __blockdev_direct_IO_newtrunc+0xc7d/0x1270
> [<ffffffff811c4330>] ? blkdev_get_block+0x0/0x20 [<ffffffff811c9137>]
> __blockdev_direct_IO+0x77/0xe0 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff811c53b7>]
> blkdev_direct_IO+0x57/0x60 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff81120552>]
> generic_file_direct_write+0xc2/0x190
> [<ffffffff81121e71>] __generic_file_aio_write+0x3a1/0x490
> [<ffffffff811d64c0>] ? aio_read_evt+0xa0/0x170 [<ffffffff811c490c>]
> blkdev_aio_write+0x3c/0xa0 [<ffffffff811c48d0>] ?
> blkdev_aio_write+0x0/0xa0 [<ffffffff811d4f64>]
> aio_rw_vect_retry+0x84/0x200 [<ffffffff811d6924>]
> aio_run_iocb+0x64/0x170 [<ffffffff811d7d51>] do_io_submit+0x291/0x920
> [<ffffffff811d83f0>] sys_io_submit+0x10/0x20 [<ffffffff8100b072>]
> system_call_fastpath+0x16/0x1b
> INFO: task fio:2720 blocked for more than 120 seconds.
> Not tainted 2.6.32-431.el6.x86_64 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> fio D 0000000000000008 0 2720 2654 0x00000080
> ffff88043b8cf698 0000000000000082 ffff88043b8cf628 ffffffff81058d53
> ffff88043b8cf648 ffff880230e49cc0 ffff8802389aa228 ffff88043b2ad1b8
> ffff880439e89af8 ffff88043b8cffd8 000000000000fbc8 ffff880439e89af8 Call Trace:
> [<ffffffff81058d53>] ? __wake_up+0x53/0x70 [<ffffffffa030334b>] ?
> md_raid5_unplug_device+0x7b/0x100 [raid456] [<ffffffffa0304146>]
> get_active_stripe+0x236/0x830 [raid456] [<ffffffff81065df0>] ?
> default_wake_function+0x0/0x20 [<ffffffff8109b5ce>] ?
> prepare_to_wait+0x4e/0x80 [<ffffffffa0308e15>]
> make_request+0x1b5/0xc6c [raid456] [<ffffffff8109b2a0>] ?
> autoremove_wake_function+0x0/0x40 [<ffffffff811220e5>] ?
> mempool_alloc_slab+0x15/0x20 [<ffffffff81415b41>]
> md_make_request+0xe1/0x230 [<ffffffff811c3fd2>] ?
> bvec_alloc_bs+0x62/0x110 [<ffffffff811c32f0>] ?
> __bio_add_page+0x110/0x230 [<ffffffff81266c50>]
> generic_make_request+0x240/0x5a0 [<ffffffff811c742c>] ?
> do_direct_IO+0x57c/0xfa0 [<ffffffff81267020>] submit_bio+0x70/0x120
> [<ffffffff811c8acd>] __blockdev_direct_IO_newtrunc+0xc7d/0x1270
> [<ffffffff811c4330>] ? blkdev_get_block+0x0/0x20 [<ffffffff811c9137>]
> __blockdev_direct_IO+0x77/0xe0 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff811c53b7>]
> blkdev_direct_IO+0x57/0x60 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff81120552>]
> generic_file_direct_write+0xc2/0x190
> [<ffffffff81121e71>] __generic_file_aio_write+0x3a1/0x490
> [<ffffffff811d64c0>] ? aio_read_evt+0xa0/0x170 [<ffffffff811c490c>]
> blkdev_aio_write+0x3c/0xa0 [<ffffffff811c48d0>] ?
> blkdev_aio_write+0x0/0xa0 [<ffffffff811d4f64>]
> aio_rw_vect_retry+0x84/0x200 [<ffffffff811d6924>]
> aio_run_iocb+0x64/0x170 [<ffffffff811d7d51>] do_io_submit+0x291/0x920
> [<ffffffff811d83f0>] sys_io_submit+0x10/0x20 [<ffffffff8100b072>]
> system_call_fastpath+0x16/0x1b
> INFO: task fio:2721 blocked for more than 120 seconds.
> Not tainted 2.6.32-431.el6.x86_64 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> fio D 0000000000000000 0 2721 2654 0x00000080
> ffff88043b047698 0000000000000082 ffff88043b047628 ffffffff81058d53
> ffff88043b047648 ffff880230e49cc0 ffff8802389aa228 ffff88043b2ad1b8
> ffff880439e89098 ffff88043b047fd8 000000000000fbc8 ffff880439e89098 Call Trace:
> [<ffffffff81058d53>] ? __wake_up+0x53/0x70 [<ffffffffa030334b>] ?
> md_raid5_unplug_device+0x7b/0x100 [raid456] [<ffffffffa0304146>]
> get_active_stripe+0x236/0x830 [raid456] [<ffffffff81065df0>] ?
> default_wake_function+0x0/0x20 [<ffffffff8109b5ce>] ?
> prepare_to_wait+0x4e/0x80 [<ffffffffa0308e15>]
> make_request+0x1b5/0xc6c [raid456] [<ffffffff8109b2a0>] ?
> autoremove_wake_function+0x0/0x40 [<ffffffff811220e5>] ?
> mempool_alloc_slab+0x15/0x20 [<ffffffff81415b41>]
> md_make_request+0xe1/0x230 [<ffffffff811c3fd2>] ?
> bvec_alloc_bs+0x62/0x110 [<ffffffff811c32f0>] ?
> __bio_add_page+0x110/0x230 [<ffffffff81266c50>]
> generic_make_request+0x240/0x5a0 [<ffffffff811c742c>] ?
> do_direct_IO+0x57c/0xfa0 [<ffffffff81267020>] submit_bio+0x70/0x120
> [<ffffffff811c8acd>] __blockdev_direct_IO_newtrunc+0xc7d/0x1270
> [<ffffffff811c4330>] ? blkdev_get_block+0x0/0x20 [<ffffffff811c9137>]
> __blockdev_direct_IO+0x77/0xe0 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff811c53b7>]
> blkdev_direct_IO+0x57/0x60 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff81120552>]
> generic_file_direct_write+0xc2/0x190
> [<ffffffff81121e71>] __generic_file_aio_write+0x3a1/0x490
> [<ffffffff811d64c0>] ? aio_read_evt+0xa0/0x170 [<ffffffff811c490c>]
> blkdev_aio_write+0x3c/0xa0 [<ffffffff811c48d0>] ?
> blkdev_aio_write+0x0/0xa0 [<ffffffff811d4f64>]
> aio_rw_vect_retry+0x84/0x200 [<ffffffff811d6924>]
> aio_run_iocb+0x64/0x170 [<ffffffff811d7d51>] do_io_submit+0x291/0x920
> [<ffffffff811d83f0>] sys_io_submit+0x10/0x20 [<ffffffff8100b072>]
> system_call_fastpath+0x16/0x1b
> INFO: task fio:2722 blocked for more than 120 seconds.
> Not tainted 2.6.32-431.el6.x86_64 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> fio D 0000000000000000 0 2722 2654 0x00000080
> ffff880439ea3698 0000000000000082 ffff880439ea3628 ffffffff81058d53
> ffff880439ea3648 ffff880230e49cc0 ffff8802389aa228 ffff88043b2ad1b8
> ffff880439e88638 ffff880439ea3fd8 000000000000fbc8 ffff880439e88638 Call Trace:
> [<ffffffff81058d53>] ? __wake_up+0x53/0x70 [<ffffffffa030334b>] ?
> md_raid5_unplug_device+0x7b/0x100 [raid456] [<ffffffffa0304146>]
> get_active_stripe+0x236/0x830 [raid456] [<ffffffff81065df0>] ?
> default_wake_function+0x0/0x20 [<ffffffff8109b5ce>] ?
> prepare_to_wait+0x4e/0x80 [<ffffffffa0308e15>]
> make_request+0x1b5/0xc6c [raid456] [<ffffffff8109b2a0>] ?
> autoremove_wake_function+0x0/0x40 [<ffffffff811220e5>] ?
> mempool_alloc_slab+0x15/0x20 [<ffffffff81415b41>]
> md_make_request+0xe1/0x230 [<ffffffff811c3fd2>] ?
> bvec_alloc_bs+0x62/0x110 [<ffffffff811c32f0>] ?
> __bio_add_page+0x110/0x230 [<ffffffff81266c50>]
> generic_make_request+0x240/0x5a0 [<ffffffff811c742c>] ?
> do_direct_IO+0x57c/0xfa0 [<ffffffff81267020>] submit_bio+0x70/0x120
> [<ffffffff811c8acd>] __blockdev_direct_IO_newtrunc+0xc7d/0x1270
> [<ffffffff811c4330>] ? blkdev_get_block+0x0/0x20 [<ffffffff811c9137>]
> __blockdev_direct_IO+0x77/0xe0 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff811c53b7>]
> blkdev_direct_IO+0x57/0x60 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff81120552>]
> generic_file_direct_write+0xc2/0x190
> [<ffffffff81121e71>] __generic_file_aio_write+0x3a1/0x490
> [<ffffffff811d64c0>] ? aio_read_evt+0xa0/0x170 [<ffffffff811c490c>]
> blkdev_aio_write+0x3c/0xa0 [<ffffffff811c48d0>] ?
> blkdev_aio_write+0x0/0xa0 [<ffffffff811d4f64>]
> aio_rw_vect_retry+0x84/0x200 [<ffffffff811d6924>]
> aio_run_iocb+0x64/0x170 [<ffffffff811d7d51>] do_io_submit+0x291/0x920
> [<ffffffff811d83f0>] sys_io_submit+0x10/0x20 [<ffffffff8100b072>]
> system_call_fastpath+0x16/0x1b
> INFO: task fio:2723 blocked for more than 120 seconds.
> Not tainted 2.6.32-431.el6.x86_64 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> fio D 0000000000000006 0 2723 2654 0x00000080
> ffff88043bf5f698 0000000000000082 ffff88043bf5f628 ffffffff81058d53
> ffff88043bf5f648 ffff880230e49cc0 ffff8802389aa228 ffff88043b2ad1b8
> ffff88043a183ab8 ffff88043bf5ffd8 000000000000fbc8 ffff88043a183ab8 Call Trace:
> [<ffffffff81058d53>] ? __wake_up+0x53/0x70 [<ffffffffa030334b>] ?
> md_raid5_unplug_device+0x7b/0x100 [raid456] [<ffffffffa0304146>]
> get_active_stripe+0x236/0x830 [raid456] [<ffffffff81065df0>] ?
> default_wake_function+0x0/0x20 [<ffffffff8109b5ce>] ?
> prepare_to_wait+0x4e/0x80 [<ffffffffa0308e15>]
> make_request+0x1b5/0xc6c [raid456] [<ffffffff8109b2a0>] ?
> autoremove_wake_function+0x0/0x40 [<ffffffff811220e5>] ?
> mempool_alloc_slab+0x15/0x20 [<ffffffff81415b41>]
> md_make_request+0xe1/0x230 [<ffffffff811c3fd2>] ?
> bvec_alloc_bs+0x62/0x110 [<ffffffff811c32f0>] ?
> __bio_add_page+0x110/0x230 [<ffffffff81266c50>]
> generic_make_request+0x240/0x5a0 [<ffffffff811c742c>] ?
> do_direct_IO+0x57c/0xfa0 [<ffffffff81267020>] submit_bio+0x70/0x120
> [<ffffffff811c8acd>] __blockdev_direct_IO_newtrunc+0xc7d/0x1270
> [<ffffffff811c4330>] ? blkdev_get_block+0x0/0x20 [<ffffffff811c9137>]
> __blockdev_direct_IO+0x77/0xe0 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff811c53b7>]
> blkdev_direct_IO+0x57/0x60 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff81120552>]
> generic_file_direct_write+0xc2/0x190
> [<ffffffff81121e71>] __generic_file_aio_write+0x3a1/0x490
> [<ffffffff811d64c0>] ? aio_read_evt+0xa0/0x170 [<ffffffff811c490c>]
> blkdev_aio_write+0x3c/0xa0 [<ffffffff811c48d0>] ?
> blkdev_aio_write+0x0/0xa0 [<ffffffff811d4f64>]
> aio_rw_vect_retry+0x84/0x200 [<ffffffff811d6924>]
> aio_run_iocb+0x64/0x170 [<ffffffff811d7d51>] do_io_submit+0x291/0x920
> [<ffffffff811d83f0>] sys_io_submit+0x10/0x20 [<ffffffff8100b072>]
> system_call_fastpath+0x16/0x1b
> INFO: task fio:2724 blocked for more than 120 seconds.
> Not tainted 2.6.32-431.el6.x86_64 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> fio D 000000000000000b 0 2724 2654 0x00000080
> ffff88043be05698 0000000000000082 ffff88043be05628 ffffffff81058d53
> ffff88043be05648 ffff880230e49cc0 ffff8802389aa228 ffff88043b2ad1b8
> ffff88043a183058 ffff88043be05fd8 000000000000fbc8 ffff88043a183058 Call Trace:
> [<ffffffff81058d53>] ? __wake_up+0x53/0x70 [<ffffffffa030334b>] ?
> md_raid5_unplug_device+0x7b/0x100 [raid456] [<ffffffffa0304146>]
> get_active_stripe+0x236/0x830 [raid456] [<ffffffff81065df0>] ?
> default_wake_function+0x0/0x20 [<ffffffff8109b5ce>] ?
> prepare_to_wait+0x4e/0x80 [<ffffffffa0308e15>]
> make_request+0x1b5/0xc6c [raid456] [<ffffffff8109b2a0>] ?
> autoremove_wake_function+0x0/0x40 [<ffffffff811220e5>] ?
> mempool_alloc_slab+0x15/0x20 [<ffffffff81415b41>]
> md_make_request+0xe1/0x230 [<ffffffff811c3fd2>] ?
> bvec_alloc_bs+0x62/0x110 [<ffffffff811c32f0>] ?
> __bio_add_page+0x110/0x230 [<ffffffff81266c50>]
> generic_make_request+0x240/0x5a0 [<ffffffff811c742c>] ?
> do_direct_IO+0x57c/0xfa0 [<ffffffff81267020>] submit_bio+0x70/0x120
> [<ffffffff811c8acd>] __blockdev_direct_IO_newtrunc+0xc7d/0x1270
> [<ffffffff811c4330>] ? blkdev_get_block+0x0/0x20 [<ffffffff811c9137>]
> __blockdev_direct_IO+0x77/0xe0 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff811c53b7>]
> blkdev_direct_IO+0x57/0x60 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff81120552>]
> generic_file_direct_write+0xc2/0x190
> [<ffffffff81121e71>] __generic_file_aio_write+0x3a1/0x490
> [<ffffffff811d64c0>] ? aio_read_evt+0xa0/0x170 [<ffffffff811c490c>]
> blkdev_aio_write+0x3c/0xa0 [<ffffffff811c48d0>] ?
> blkdev_aio_write+0x0/0xa0 [<ffffffff811d4f64>]
> aio_rw_vect_retry+0x84/0x200 [<ffffffff811d6924>]
> aio_run_iocb+0x64/0x170 [<ffffffff811d7d51>] do_io_submit+0x291/0x920
> [<ffffffff811d83f0>] sys_io_submit+0x10/0x20 [<ffffffff8100b072>]
> system_call_fastpath+0x16/0x1b
> INFO: task fio:2725 blocked for more than 120 seconds.
> Not tainted 2.6.32-431.el6.x86_64 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> fio D 0000000000000003 0 2725 2654 0x00000080
> ffff88043be07698 0000000000000082 ffff88043be07628 ffffffff81058d53
> ffff88043be07648 ffff880230e49cc0 ffff8802389aa228 ffff88043b2ad1b8
> ffff88043a1825f8 ffff88043be07fd8 000000000000fbc8 ffff88043a1825f8 Call Trace:
> [<ffffffff81058d53>] ? __wake_up+0x53/0x70 [<ffffffffa030334b>] ?
> md_raid5_unplug_device+0x7b/0x100 [raid456] [<ffffffffa0304146>]
> get_active_stripe+0x236/0x830 [raid456] [<ffffffff81065df0>] ?
> default_wake_function+0x0/0x20 [<ffffffff8109b5ce>] ?
> prepare_to_wait+0x4e/0x80 [<ffffffffa0308e15>]
> make_request+0x1b5/0xc6c [raid456] [<ffffffff8109b2a0>] ?
> autoremove_wake_function+0x0/0x40 [<ffffffff811220e5>] ?
> mempool_alloc_slab+0x15/0x20 [<ffffffff81415b41>]
> md_make_request+0xe1/0x230 [<ffffffff811c3fd2>] ?
> bvec_alloc_bs+0x62/0x110 [<ffffffff811c32f0>] ?
> __bio_add_page+0x110/0x230 [<ffffffff81266c50>]
> generic_make_request+0x240/0x5a0 [<ffffffff811c742c>] ?
> do_direct_IO+0x57c/0xfa0 [<ffffffff81267020>] submit_bio+0x70/0x120
> [<ffffffff811c8acd>] __blockdev_direct_IO_newtrunc+0xc7d/0x1270
> [<ffffffff811c4330>] ? blkdev_get_block+0x0/0x20 [<ffffffff811c9137>]
> __blockdev_direct_IO+0x77/0xe0 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff811c53b7>]
> blkdev_direct_IO+0x57/0x60 [<ffffffff811c4330>] ?
> blkdev_get_block+0x0/0x20 [<ffffffff81120552>]
> generic_file_direct_write+0xc2/0x190
> [<ffffffff81121e71>] __generic_file_aio_write+0x3a1/0x490
> [<ffffffff811d64c0>] ? aio_read_evt+0xa0/0x170 [<ffffffff811c490c>]
> blkdev_aio_write+0x3c/0xa0 [<ffffffff811c48d0>] ?
> blkdev_aio_write+0x0/0xa0 [<ffffffff811d4f64>]
> aio_rw_vect_retry+0x84/0x200 [<ffffffff811d6924>]
> aio_run_iocb+0x64/0x170 [<ffffffff811d7d51>] do_io_submit+0x291/0x920
> [<ffffffff811d83f0>] sys_io_submit+0x10/0x20 [<ffffffff8100b072>]
> system_call_fastpath+0x16/0x1b
>
> [root@root ~]# cat /proc/2690/stack
> [<ffffffff810686da>] __cond_resched+0x2a/0x40 [<ffffffffa030361c>]
> ops_run_io+0x2c/0x920 [raid456] [<ffffffffa03052cc>]
> handle_stripe+0x9cc/0x2980 [raid456] [<ffffffffa03078a4>]
> raid5d+0x624/0x850 [raid456] [<ffffffff81416f05>]
> md_thread+0x115/0x150 [<ffffffff8109aef6>] kthread+0x96/0xa0
> [<ffffffff8100c20a>] child_rip+0xa/0x20 [<ffffffffffffffff>]
> 0xffffffffffffffff
>
> [root@root ~]# cat /proc/2690/stat
> 2690 (md0_raid5) R 2 0 0 0 -1 2149613632 0 0 0 0 0 68495 0 0 20 0 1 0
> 350990 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483391 256 0 0 0 17
> 2 0 0 6855 0 0 [root@root ~]# cat /proc/2690/statm
> 0 0 0 0 0 0 0
> [root@root ~]# cat /proc/2690/stat
> stat statm status
> [root@root ~]# cat /proc/2690/status
> Name: md0_raid5
> State: R (running)
> Tgid: 2690
> Pid: 2690
> PPid: 2
> TracerPid: 0
> Uid: 0 0 0 0
> Gid: 0 0 0 0
> Utrace: 0
> FDSize: 64
> Groups:
> Threads: 1
> SigQ: 2/128402
> SigPnd: 0000000000000000
> ShdPnd: 0000000000000000
> SigBlk: 0000000000000000
> SigIgn: fffffffffffffeff
> SigCgt: 0000000000000100
> CapInh: 0000000000000000
> CapPrm: ffffffffffffffff
> CapEff: fffffffffffffeff
> CapBnd: ffffffffffffffff
> Cpus_allowed: ffffff
> Cpus_allowed_list: 0-23
> Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003
> Mems_allowed_list: 0-1
> voluntary_ctxt_switches: 5411612
> nonvoluntary_ctxt_switches: 257032
>
>
> Thanks,
> Manibalan.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] md:Remove no longer needed fix me comment in dm-region-hash.c for removing the structure pointer, *rh from the definiton of dm_region
From: Nicholas Krause @ 2015-01-13 3:30 UTC (permalink / raw)
To: agk; +Cc: linux-raid, dm-devel, linux-kernel, snitzer
Removes the no longer needed fix me comment questioning if we need to remove
the structure pointer,rh as defined as a structure of type dsm_region_hash
from the definition of the structure, dm_region. Furthermore this pointer is
needed in order for various functions to run and build successfully in the file,
dm-region-hash.c.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
---
drivers/md/dm-region-hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-region-hash.c b/drivers/md/dm-region-hash.c
index b929fd5..823d56f 100644
--- a/drivers/md/dm-region-hash.c
+++ b/drivers/md/dm-region-hash.c
@@ -99,7 +99,7 @@ struct dm_region_hash {
};
struct dm_region {
- struct dm_region_hash *rh; /* FIXME: can we get rid of this ? */
+ struct dm_region_hash *rh;
region_t key;
int state;
--
2.1.0
^ permalink raw reply related
* Re: mdadm RAID6 "active" with spares and failed disks; need help
From: Wols Lists @ 2015-01-12 16:35 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <54B305B2.6000702@lentijn.sess.ink>
On 11/01/15 23:22, Valentijn Sessink wrote:
> Also, I would not have dared to run all these statements on "live" (or
> dead, for that matter ;-) disks.
I'm no expert either, but looking at the blog, I'm worried he might have
trashed the array with almost the first thing he did :-(
"add" says it will add a drive as spare if it didn't originally belong
to the array. If it adds a spare to a degraded array, the array will
immediately start to repair itself.
OOPS!!! As it sounds like exactly this could have happened - mdadm
didn't recognise the disk as it added it.
Just speculating, but unfortunately this seems quite likely :-(
Cheers,
Wol
^ permalink raw reply
* [PATCH v2 7/9] block: kill merge_bvec_fn() completely
From: Dongsu Park @ 2015-01-12 11:49 UTC (permalink / raw)
To: linux-kernel
Cc: Christoph Hellwig, Kent Overstreet, Jens Axboe, Lars Ellenberg,
drbd-user, Jiri Kosina, Yehuda Sadeh, Sage Weil, Alex Elder,
ceph-devel, Alasdair Kergon, Mike Snitzer, dm-devel, Neil Brown,
linux-raid, Martin K. Petersen, Dongsu Park
In-Reply-To: <cover.1421052745.git.dongsu.park@profitbricks.com>
From: Kent Overstreet <kmo@daterainc.com>
As generic_make_request() is now able to handle arbitrarily sized bios,
it's no longer necessary for each individual block driver to define its
own ->merge_bvec_fn() callback. Remove every invocation completely.
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Lars Ellenberg <drbd-dev@lists.linbit.com>
Cc: drbd-user@lists.linbit.com
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Yehuda Sadeh <yehuda@inktank.com>
Cc: Sage Weil <sage@inktank.com>
Cc: Alex Elder <elder@kernel.org>
Cc: ceph-devel@vger.kernel.org
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: dm-devel@redhat.com
Cc: Neil Brown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Signed-off-by: Kent Overstreet <kmo@daterainc.com>
[dpark: also remove ->merge_bvec_fn() in dm-thin as well as
dm-era-target, and resolve merge conflicts]
Signed-off-by: Dongsu Park <dongsu.park@profitbricks.com>
---
block/blk-merge.c | 17 +-----
block/blk-settings.c | 22 --------
drivers/block/drbd/drbd_int.h | 1 -
drivers/block/drbd/drbd_main.c | 1 -
drivers/block/drbd/drbd_req.c | 35 ------------
drivers/block/pktcdvd.c | 21 -------
drivers/block/rbd.c | 47 ----------------
drivers/md/dm-cache-target.c | 21 -------
drivers/md/dm-crypt.c | 16 ------
drivers/md/dm-era-target.c | 15 -----
drivers/md/dm-flakey.c | 16 ------
drivers/md/dm-linear.c | 16 ------
drivers/md/dm-snap.c | 15 -----
drivers/md/dm-stripe.c | 21 -------
drivers/md/dm-table.c | 8 ---
drivers/md/dm-thin.c | 31 -----------
drivers/md/dm-verity.c | 16 ------
drivers/md/dm.c | 120 +---------------------------------------
drivers/md/dm.h | 2 -
drivers/md/linear.c | 46 ----------------
drivers/md/md.c | 2 -
drivers/md/md.h | 8 ---
drivers/md/multipath.c | 21 -------
drivers/md/raid0.c | 57 -------------------
drivers/md/raid0.h | 2 -
drivers/md/raid1.c | 59 +-------------------
drivers/md/raid10.c | 122 +----------------------------------------
drivers/md/raid5.c | 28 ----------
include/linux/blkdev.h | 10 ----
include/linux/device-mapper.h | 4 --
30 files changed, 9 insertions(+), 791 deletions(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 3bc2068..8cd7a83 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -69,24 +69,13 @@ static struct bio *blk_bio_segment_split(struct request_queue *q,
struct bio *split;
struct bio_vec bv = { 0 }, bvprv = { 0 };
struct bvec_iter iter;
- unsigned seg_size = 0, nsegs = 0;
+ unsigned seg_size = 0, nsegs = 0, sectors = 0;
int prev = 0;
- struct bvec_merge_data bvm = {
- .bi_bdev = bio->bi_bdev,
- .bi_sector = bio->bi_iter.bi_sector,
- .bi_size = 0,
- .bi_rw = bio->bi_rw,
- };
-
bio_for_each_segment(bv, bio, iter) {
- if (q->merge_bvec_fn &&
- q->merge_bvec_fn(q, &bvm, &bv) < (int) bv.bv_len)
- goto split;
-
- bvm.bi_size += bv.bv_len;
+ sectors += bv.bv_len >> 9;
- if (bvm.bi_size >> 9 > queue_max_sectors(q))
+ if (sectors > queue_max_sectors(q))
goto split;
if (prev && blk_queue_cluster(q)) {
diff --git a/block/blk-settings.c b/block/blk-settings.c
index 6ed2cbe..463a10a 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -53,28 +53,6 @@ void blk_queue_unprep_rq(struct request_queue *q, unprep_rq_fn *ufn)
}
EXPORT_SYMBOL(blk_queue_unprep_rq);
-/**
- * blk_queue_merge_bvec - set a merge_bvec function for queue
- * @q: queue
- * @mbfn: merge_bvec_fn
- *
- * Usually queues have static limitations on the max sectors or segments that
- * we can put in a request. Stacking drivers may have some settings that
- * are dynamic, and thus we have to query the queue whether it is ok to
- * add a new bio_vec to a bio at a given offset or not. If the block device
- * has such limitations, it needs to register a merge_bvec_fn to control
- * the size of bio's sent to it. Note that a block device *must* allow a
- * single page to be added to an empty bio. The block device driver may want
- * to use the bio_split() function to deal with these bio's. By default
- * no merge_bvec_fn is defined for a queue, and only the fixed limits are
- * honored.
- */
-void blk_queue_merge_bvec(struct request_queue *q, merge_bvec_fn *mbfn)
-{
- q->merge_bvec_fn = mbfn;
-}
-EXPORT_SYMBOL(blk_queue_merge_bvec);
-
void blk_queue_softirq_done(struct request_queue *q, softirq_done_fn *fn)
{
q->softirq_done_fn = fn;
diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h
index b905e98..63ce2b0 100644
--- a/drivers/block/drbd/drbd_int.h
+++ b/drivers/block/drbd/drbd_int.h
@@ -1449,7 +1449,6 @@ extern void do_submit(struct work_struct *ws);
extern void __drbd_make_request(struct drbd_device *, struct bio *, unsigned long);
extern void drbd_make_request(struct request_queue *q, struct bio *bio);
extern int drbd_read_remote(struct drbd_device *device, struct drbd_request *req);
-extern int drbd_merge_bvec(struct request_queue *q, struct bvec_merge_data *bvm, struct bio_vec *bvec);
extern int is_valid_ar_handle(struct drbd_request *, sector_t);
diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index 1fc8342..f49f53e 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -2775,7 +2775,6 @@ enum drbd_ret_code drbd_create_device(struct drbd_config_context *adm_ctx, unsig
This triggers a max_bio_size message upon first attach or connect */
blk_queue_max_hw_sectors(q, DRBD_MAX_BIO_SIZE_SAFE >> 8);
blk_queue_bounce_limit(q, BLK_BOUNCE_ANY);
- blk_queue_merge_bvec(q, drbd_merge_bvec);
q->queue_lock = &resource->req_lock;
device->md_io.page = alloc_page(GFP_KERNEL);
diff --git a/drivers/block/drbd/drbd_req.c b/drivers/block/drbd/drbd_req.c
index dee706d..b57d30b 100644
--- a/drivers/block/drbd/drbd_req.c
+++ b/drivers/block/drbd/drbd_req.c
@@ -1509,41 +1509,6 @@ void drbd_make_request(struct request_queue *q, struct bio *bio)
__drbd_make_request(device, bio, start_jif);
}
-/* This is called by bio_add_page().
- *
- * q->max_hw_sectors and other global limits are already enforced there.
- *
- * We need to call down to our lower level device,
- * in case it has special restrictions.
- *
- * We also may need to enforce configured max-bio-bvecs limits.
- *
- * As long as the BIO is empty we have to allow at least one bvec,
- * regardless of size and offset, so no need to ask lower levels.
- */
-int drbd_merge_bvec(struct request_queue *q, struct bvec_merge_data *bvm, struct bio_vec *bvec)
-{
- struct drbd_device *device = (struct drbd_device *) q->queuedata;
- unsigned int bio_size = bvm->bi_size;
- int limit = DRBD_MAX_BIO_SIZE;
- int backing_limit;
-
- if (bio_size && get_ldev(device)) {
- unsigned int max_hw_sectors = queue_max_hw_sectors(q);
- struct request_queue * const b =
- device->ldev->backing_bdev->bd_disk->queue;
- if (b->merge_bvec_fn) {
- bvm->bi_bdev = device->ldev->backing_bdev;
- backing_limit = b->merge_bvec_fn(b, bvm, bvec);
- limit = min(limit, backing_limit);
- }
- put_ldev(device);
- if ((limit >> 9) > max_hw_sectors)
- limit = max_hw_sectors << 9;
- }
- return limit;
-}
-
void request_timer_fn(unsigned long data)
{
struct drbd_device *device = (struct drbd_device *) data;
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index ea10bd9..85eac23 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2505,26 +2505,6 @@ end_io:
-static int pkt_merge_bvec(struct request_queue *q, struct bvec_merge_data *bmd,
- struct bio_vec *bvec)
-{
- struct pktcdvd_device *pd = q->queuedata;
- sector_t zone = get_zone(bmd->bi_sector, pd);
- int used = ((bmd->bi_sector - zone) << 9) + bmd->bi_size;
- int remaining = (pd->settings.size << 9) - used;
- int remaining2;
-
- /*
- * A bio <= PAGE_SIZE must be allowed. If it crosses a packet
- * boundary, pkt_make_request() will split the bio.
- */
- remaining2 = PAGE_SIZE - bmd->bi_size;
- remaining = max(remaining, remaining2);
-
- BUG_ON(remaining < 0);
- return remaining;
-}
-
static void pkt_init_queue(struct pktcdvd_device *pd)
{
struct request_queue *q = pd->disk->queue;
@@ -2532,7 +2512,6 @@ static void pkt_init_queue(struct pktcdvd_device *pd)
blk_queue_make_request(q, pkt_make_request);
blk_queue_logical_block_size(q, CD_FRAMESIZE);
blk_queue_max_hw_sectors(q, PACKET_MAX_SECTORS);
- blk_queue_merge_bvec(q, pkt_merge_bvec);
q->queuedata = pd;
}
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index 3ec85df..0c0e2d0 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -3459,52 +3459,6 @@ static void rbd_request_fn(struct request_queue *q)
queue_work(rbd_wq, &rbd_dev->rq_work);
}
-/*
- * a queue callback. Makes sure that we don't create a bio that spans across
- * multiple osd objects. One exception would be with a single page bios,
- * which we handle later at bio_chain_clone_range()
- */
-static int rbd_merge_bvec(struct request_queue *q, struct bvec_merge_data *bmd,
- struct bio_vec *bvec)
-{
- struct rbd_device *rbd_dev = q->queuedata;
- sector_t sector_offset;
- sector_t sectors_per_obj;
- sector_t obj_sector_offset;
- int ret;
-
- /*
- * Find how far into its rbd object the partition-relative
- * bio start sector is to offset relative to the enclosing
- * device.
- */
- sector_offset = get_start_sect(bmd->bi_bdev) + bmd->bi_sector;
- sectors_per_obj = 1 << (rbd_dev->header.obj_order - SECTOR_SHIFT);
- obj_sector_offset = sector_offset & (sectors_per_obj - 1);
-
- /*
- * Compute the number of bytes from that offset to the end
- * of the object. Account for what's already used by the bio.
- */
- ret = (int) (sectors_per_obj - obj_sector_offset) << SECTOR_SHIFT;
- if (ret > bmd->bi_size)
- ret -= bmd->bi_size;
- else
- ret = 0;
-
- /*
- * Don't send back more than was asked for. And if the bio
- * was empty, let the whole thing through because: "Note
- * that a block device *must* allow a single page to be
- * added to an empty bio."
- */
- rbd_assert(bvec->bv_len <= PAGE_SIZE);
- if (ret > (int) bvec->bv_len || !bmd->bi_size)
- ret = (int) bvec->bv_len;
-
- return ret;
-}
-
static void rbd_free_disk(struct rbd_device *rbd_dev)
{
struct gendisk *disk = rbd_dev->disk;
@@ -3771,7 +3725,6 @@ static int rbd_init_disk(struct rbd_device *rbd_dev)
q->limits.max_discard_sectors = segment_size / SECTOR_SIZE;
q->limits.discard_zeroes_data = 1;
- blk_queue_merge_bvec(q, rbd_merge_bvec);
disk->queue = q;
q->queuedata = rbd_dev;
diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index 1e96d78..72fd9d3 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -3277,26 +3277,6 @@ static int cache_iterate_devices(struct dm_target *ti,
return r;
}
-/*
- * We assume I/O is going to the origin (which is the volume
- * more likely to have restrictions e.g. by being striped).
- * (Looking up the exact location of the data would be expensive
- * and could always be out of date by the time the bio is submitted.)
- */
-static int cache_bvec_merge(struct dm_target *ti,
- struct bvec_merge_data *bvm,
- struct bio_vec *biovec, int max_size)
-{
- struct cache *cache = ti->private;
- struct request_queue *q = bdev_get_queue(cache->origin_dev->bdev);
-
- if (!q->merge_bvec_fn)
- return max_size;
-
- bvm->bi_bdev = cache->origin_dev->bdev;
- return min(max_size, q->merge_bvec_fn(q, bvm, biovec));
-}
-
static void set_discard_limits(struct cache *cache, struct queue_limits *limits)
{
/*
@@ -3340,7 +3320,6 @@ static struct target_type cache_target = {
.status = cache_status,
.message = cache_message,
.iterate_devices = cache_iterate_devices,
- .merge = cache_bvec_merge,
.io_hints = cache_io_hints,
};
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 08981be..723c176 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -1951,21 +1951,6 @@ error:
return -EINVAL;
}
-static int crypt_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
- struct bio_vec *biovec, int max_size)
-{
- struct crypt_config *cc = ti->private;
- struct request_queue *q = bdev_get_queue(cc->dev->bdev);
-
- if (!q->merge_bvec_fn)
- return max_size;
-
- bvm->bi_bdev = cc->dev->bdev;
- bvm->bi_sector = cc->start + dm_target_offset(ti, bvm->bi_sector);
-
- return min(max_size, q->merge_bvec_fn(q, bvm, biovec));
-}
-
static int crypt_iterate_devices(struct dm_target *ti,
iterate_devices_callout_fn fn, void *data)
{
@@ -1986,7 +1971,6 @@ static struct target_type crypt_target = {
.preresume = crypt_preresume,
.resume = crypt_resume,
.message = crypt_message,
- .merge = crypt_merge,
.iterate_devices = crypt_iterate_devices,
};
diff --git a/drivers/md/dm-era-target.c b/drivers/md/dm-era-target.c
index ad913cd..0119ebf 100644
--- a/drivers/md/dm-era-target.c
+++ b/drivers/md/dm-era-target.c
@@ -1673,20 +1673,6 @@ static int era_iterate_devices(struct dm_target *ti,
return fn(ti, era->origin_dev, 0, get_dev_size(era->origin_dev), data);
}
-static int era_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
- struct bio_vec *biovec, int max_size)
-{
- struct era *era = ti->private;
- struct request_queue *q = bdev_get_queue(era->origin_dev->bdev);
-
- if (!q->merge_bvec_fn)
- return max_size;
-
- bvm->bi_bdev = era->origin_dev->bdev;
-
- return min(max_size, q->merge_bvec_fn(q, bvm, biovec));
-}
-
static void era_io_hints(struct dm_target *ti, struct queue_limits *limits)
{
struct era *era = ti->private;
@@ -1717,7 +1703,6 @@ static struct target_type era_target = {
.status = era_status,
.message = era_message,
.iterate_devices = era_iterate_devices,
- .merge = era_merge,
.io_hints = era_io_hints
};
diff --git a/drivers/md/dm-flakey.c b/drivers/md/dm-flakey.c
index b257e46..d955b3e 100644
--- a/drivers/md/dm-flakey.c
+++ b/drivers/md/dm-flakey.c
@@ -387,21 +387,6 @@ static int flakey_ioctl(struct dm_target *ti, unsigned int cmd, unsigned long ar
return r ? : __blkdev_driver_ioctl(dev->bdev, dev->mode, cmd, arg);
}
-static int flakey_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
- struct bio_vec *biovec, int max_size)
-{
- struct flakey_c *fc = ti->private;
- struct request_queue *q = bdev_get_queue(fc->dev->bdev);
-
- if (!q->merge_bvec_fn)
- return max_size;
-
- bvm->bi_bdev = fc->dev->bdev;
- bvm->bi_sector = flakey_map_sector(ti, bvm->bi_sector);
-
- return min(max_size, q->merge_bvec_fn(q, bvm, biovec));
-}
-
static int flakey_iterate_devices(struct dm_target *ti, iterate_devices_callout_fn fn, void *data)
{
struct flakey_c *fc = ti->private;
@@ -419,7 +404,6 @@ static struct target_type flakey_target = {
.end_io = flakey_end_io,
.status = flakey_status,
.ioctl = flakey_ioctl,
- .merge = flakey_merge,
.iterate_devices = flakey_iterate_devices,
};
diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c
index 53e848c..7dd5fc8 100644
--- a/drivers/md/dm-linear.c
+++ b/drivers/md/dm-linear.c
@@ -130,21 +130,6 @@ static int linear_ioctl(struct dm_target *ti, unsigned int cmd,
return r ? : __blkdev_driver_ioctl(dev->bdev, dev->mode, cmd, arg);
}
-static int linear_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
- struct bio_vec *biovec, int max_size)
-{
- struct linear_c *lc = ti->private;
- struct request_queue *q = bdev_get_queue(lc->dev->bdev);
-
- if (!q->merge_bvec_fn)
- return max_size;
-
- bvm->bi_bdev = lc->dev->bdev;
- bvm->bi_sector = linear_map_sector(ti, bvm->bi_sector);
-
- return min(max_size, q->merge_bvec_fn(q, bvm, biovec));
-}
-
static int linear_iterate_devices(struct dm_target *ti,
iterate_devices_callout_fn fn, void *data)
{
@@ -162,7 +147,6 @@ static struct target_type linear_target = {
.map = linear_map,
.status = linear_status,
.ioctl = linear_ioctl,
- .merge = linear_merge,
.iterate_devices = linear_iterate_devices,
};
diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 864b03f..2e6bb7e 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -2234,20 +2234,6 @@ static void origin_status(struct dm_target *ti, status_type_t type,
}
}
-static int origin_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
- struct bio_vec *biovec, int max_size)
-{
- struct dm_origin *o = ti->private;
- struct request_queue *q = bdev_get_queue(o->dev->bdev);
-
- if (!q->merge_bvec_fn)
- return max_size;
-
- bvm->bi_bdev = o->dev->bdev;
-
- return min(max_size, q->merge_bvec_fn(q, bvm, biovec));
-}
-
static int origin_iterate_devices(struct dm_target *ti,
iterate_devices_callout_fn fn, void *data)
{
@@ -2265,7 +2251,6 @@ static struct target_type origin_target = {
.map = origin_map,
.resume = origin_resume,
.status = origin_status,
- .merge = origin_merge,
.iterate_devices = origin_iterate_devices,
};
diff --git a/drivers/md/dm-stripe.c b/drivers/md/dm-stripe.c
index f8b37d4..09bb2fe 100644
--- a/drivers/md/dm-stripe.c
+++ b/drivers/md/dm-stripe.c
@@ -412,26 +412,6 @@ static void stripe_io_hints(struct dm_target *ti,
blk_limits_io_opt(limits, chunk_size * sc->stripes);
}
-static int stripe_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
- struct bio_vec *biovec, int max_size)
-{
- struct stripe_c *sc = ti->private;
- sector_t bvm_sector = bvm->bi_sector;
- uint32_t stripe;
- struct request_queue *q;
-
- stripe_map_sector(sc, bvm_sector, &stripe, &bvm_sector);
-
- q = bdev_get_queue(sc->stripe[stripe].dev->bdev);
- if (!q->merge_bvec_fn)
- return max_size;
-
- bvm->bi_bdev = sc->stripe[stripe].dev->bdev;
- bvm->bi_sector = sc->stripe[stripe].physical_start + bvm_sector;
-
- return min(max_size, q->merge_bvec_fn(q, bvm, biovec));
-}
-
static struct target_type stripe_target = {
.name = "striped",
.version = {1, 5, 1},
@@ -443,7 +423,6 @@ static struct target_type stripe_target = {
.status = stripe_status,
.iterate_devices = stripe_iterate_devices,
.io_hints = stripe_io_hints,
- .merge = stripe_merge,
};
int __init dm_stripe_init(void)
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 3afae9e..6c14cb4 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -443,14 +443,6 @@ static int dm_set_device_limits(struct dm_target *ti, struct dm_dev *dev,
q->limits.alignment_offset,
(unsigned long long) start << SECTOR_SHIFT);
- /*
- * Check if merge fn is supported.
- * If not we'll force DM to use PAGE_SIZE or
- * smaller I/O, just to be safe.
- */
- if (dm_queue_merge_is_compulsory(q) && !ti->type->merge)
- blk_limits_max_hw_sectors(limits,
- (unsigned int) (PAGE_SIZE >> 9));
return 0;
}
diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
index 4934789..2a4b677 100644
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
@@ -3566,20 +3566,6 @@ static int pool_iterate_devices(struct dm_target *ti,
return fn(ti, pt->data_dev, 0, ti->len, data);
}
-static int pool_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
- struct bio_vec *biovec, int max_size)
-{
- struct pool_c *pt = ti->private;
- struct request_queue *q = bdev_get_queue(pt->data_dev->bdev);
-
- if (!q->merge_bvec_fn)
- return max_size;
-
- bvm->bi_bdev = pt->data_dev->bdev;
-
- return min(max_size, q->merge_bvec_fn(q, bvm, biovec));
-}
-
static void set_discard_limits(struct pool_c *pt, struct queue_limits *limits)
{
struct pool *pool = pt->pool;
@@ -3671,7 +3657,6 @@ static struct target_type pool_target = {
.resume = pool_resume,
.message = pool_message,
.status = pool_status,
- .merge = pool_merge,
.iterate_devices = pool_iterate_devices,
.io_hints = pool_io_hints,
};
@@ -3996,21 +3981,6 @@ err:
DMEMIT("Error");
}
-static int thin_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
- struct bio_vec *biovec, int max_size)
-{
- struct thin_c *tc = ti->private;
- struct request_queue *q = bdev_get_queue(tc->pool_dev->bdev);
-
- if (!q->merge_bvec_fn)
- return max_size;
-
- bvm->bi_bdev = tc->pool_dev->bdev;
- bvm->bi_sector = dm_target_offset(ti, bvm->bi_sector);
-
- return min(max_size, q->merge_bvec_fn(q, bvm, biovec));
-}
-
static int thin_iterate_devices(struct dm_target *ti,
iterate_devices_callout_fn fn, void *data)
{
@@ -4045,7 +4015,6 @@ static struct target_type thin_target = {
.presuspend = thin_presuspend,
.postsuspend = thin_postsuspend,
.status = thin_status,
- .merge = thin_merge,
.iterate_devices = thin_iterate_devices,
};
diff --git a/drivers/md/dm-verity.c b/drivers/md/dm-verity.c
index 7a7bab8..25d76a8 100644
--- a/drivers/md/dm-verity.c
+++ b/drivers/md/dm-verity.c
@@ -564,21 +564,6 @@ static int verity_ioctl(struct dm_target *ti, unsigned cmd,
cmd, arg);
}
-static int verity_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
- struct bio_vec *biovec, int max_size)
-{
- struct dm_verity *v = ti->private;
- struct request_queue *q = bdev_get_queue(v->data_dev->bdev);
-
- if (!q->merge_bvec_fn)
- return max_size;
-
- bvm->bi_bdev = v->data_dev->bdev;
- bvm->bi_sector = verity_map_sector(v, bvm->bi_sector);
-
- return min(max_size, q->merge_bvec_fn(q, bvm, biovec));
-}
-
static int verity_iterate_devices(struct dm_target *ti,
iterate_devices_callout_fn fn, void *data)
{
@@ -872,7 +857,6 @@ static struct target_type verity_target = {
.map = verity_map,
.status = verity_status,
.ioctl = verity_ioctl,
- .merge = verity_merge,
.iterate_devices = verity_iterate_devices,
.io_hints = verity_io_hints,
};
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index fe1e9b7..90777df 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -116,9 +116,8 @@ EXPORT_SYMBOL_GPL(dm_get_rq_mapinfo);
#define DMF_FREEING 3
#define DMF_DELETING 4
#define DMF_NOFLUSH_SUSPENDING 5
-#define DMF_MERGE_IS_OPTIONAL 6
-#define DMF_DEFERRED_REMOVE 7
-#define DMF_SUSPENDED_INTERNALLY 8
+#define DMF_DEFERRED_REMOVE 6
+#define DMF_SUSPENDED_INTERNALLY 7
/*
* A dummy definition to make RCU happy.
@@ -1586,60 +1585,6 @@ static void __split_and_process_bio(struct mapped_device *md,
* CRUD END
*---------------------------------------------------------------*/
-static int dm_merge_bvec(struct request_queue *q,
- struct bvec_merge_data *bvm,
- struct bio_vec *biovec)
-{
- struct mapped_device *md = q->queuedata;
- struct dm_table *map = dm_get_live_table_fast(md);
- struct dm_target *ti;
- sector_t max_sectors;
- int max_size = 0;
-
- if (unlikely(!map))
- goto out;
-
- ti = dm_table_find_target(map, bvm->bi_sector);
- if (!dm_target_is_valid(ti))
- goto out;
-
- /*
- * Find maximum amount of I/O that won't need splitting
- */
- max_sectors = min(max_io_len(bvm->bi_sector, ti),
- (sector_t) queue_max_sectors(q));
- max_size = (max_sectors << SECTOR_SHIFT) - bvm->bi_size;
- if (unlikely(max_size < 0)) /* this shouldn't _ever_ happen */
- max_size = 0;
-
- /*
- * merge_bvec_fn() returns number of bytes
- * it can accept at this offset
- * max is precomputed maximal io size
- */
- if (max_size && ti->type->merge)
- max_size = ti->type->merge(ti, bvm, biovec, max_size);
- /*
- * If the target doesn't support merge method and some of the devices
- * provided their merge_bvec method (we know this by looking for the
- * max_hw_sectors that dm_set_device_limits may set), then we can't
- * allow bios with multiple vector entries. So always set max_size
- * to 0, and the code below allows just one page.
- */
- else if (queue_max_hw_sectors(q) <= PAGE_SIZE >> 9)
- max_size = 0;
-
-out:
- dm_put_live_table_fast(md);
- /*
- * Always allow an entire first page
- */
- if (max_size <= biovec->bv_len && !(bvm->bi_size >> SECTOR_SHIFT))
- max_size = biovec->bv_len;
-
- return max_size;
-}
-
/*
* The request function that just remaps the bio built up by
* dm_merge_bvec.
@@ -2030,7 +1975,6 @@ static void dm_init_md_queue(struct mapped_device *md)
md->queue->backing_dev_info.congested_data = md;
blk_queue_make_request(md->queue, dm_request);
blk_queue_bounce_limit(md->queue, BLK_BOUNCE_ANY);
- blk_queue_merge_bvec(md->queue, dm_merge_bvec);
}
/*
@@ -2241,59 +2185,6 @@ static void __set_size(struct mapped_device *md, sector_t size)
}
/*
- * Return 1 if the queue has a compulsory merge_bvec_fn function.
- *
- * If this function returns 0, then the device is either a non-dm
- * device without a merge_bvec_fn, or it is a dm device that is
- * able to split any bios it receives that are too big.
- */
-int dm_queue_merge_is_compulsory(struct request_queue *q)
-{
- struct mapped_device *dev_md;
-
- if (!q->merge_bvec_fn)
- return 0;
-
- if (q->make_request_fn == dm_request) {
- dev_md = q->queuedata;
- if (test_bit(DMF_MERGE_IS_OPTIONAL, &dev_md->flags))
- return 0;
- }
-
- return 1;
-}
-
-static int dm_device_merge_is_compulsory(struct dm_target *ti,
- struct dm_dev *dev, sector_t start,
- sector_t len, void *data)
-{
- struct block_device *bdev = dev->bdev;
- struct request_queue *q = bdev_get_queue(bdev);
-
- return dm_queue_merge_is_compulsory(q);
-}
-
-/*
- * Return 1 if it is acceptable to ignore merge_bvec_fn based
- * on the properties of the underlying devices.
- */
-static int dm_table_merge_is_optional(struct dm_table *table)
-{
- unsigned i = 0;
- struct dm_target *ti;
-
- while (i < dm_table_get_num_targets(table)) {
- ti = dm_table_get_target(table, i++);
-
- if (ti->type->iterate_devices &&
- ti->type->iterate_devices(ti, dm_device_merge_is_compulsory, NULL))
- return 0;
- }
-
- return 1;
-}
-
-/*
* Returns old map, which caller must destroy.
*/
static struct dm_table *__bind(struct mapped_device *md, struct dm_table *t,
@@ -2302,7 +2193,6 @@ static struct dm_table *__bind(struct mapped_device *md, struct dm_table *t,
struct dm_table *old_map;
struct request_queue *q = md->queue;
sector_t size;
- int merge_is_optional;
size = dm_table_get_size(t);
@@ -2328,17 +2218,11 @@ static struct dm_table *__bind(struct mapped_device *md, struct dm_table *t,
__bind_mempools(md, t);
- merge_is_optional = dm_table_merge_is_optional(t);
-
old_map = rcu_dereference_protected(md->map, lockdep_is_held(&md->suspend_lock));
rcu_assign_pointer(md->map, t);
md->immutable_target_type = dm_table_get_immutable_target_type(t);
dm_table_set_restrictions(t, q, limits);
- if (merge_is_optional)
- set_bit(DMF_MERGE_IS_OPTIONAL, &md->flags);
- else
- clear_bit(DMF_MERGE_IS_OPTIONAL, &md->flags);
if (old_map)
dm_sync_table(md);
diff --git a/drivers/md/dm.h b/drivers/md/dm.h
index 84b0f9e4..08f47fc 100644
--- a/drivers/md/dm.h
+++ b/drivers/md/dm.h
@@ -76,8 +76,6 @@ bool dm_table_request_based(struct dm_table *t);
void dm_table_free_md_mempools(struct dm_table *t);
struct dm_md_mempools *dm_table_get_md_mempools(struct dm_table *t);
-int dm_queue_merge_is_compulsory(struct request_queue *q);
-
void dm_lock_md_type(struct mapped_device *md);
void dm_unlock_md_type(struct mapped_device *md);
void dm_set_md_type(struct mapped_device *md, unsigned type);
diff --git a/drivers/md/linear.c b/drivers/md/linear.c
index 64713b7..d831a5b 100644
--- a/drivers/md/linear.c
+++ b/drivers/md/linear.c
@@ -52,51 +52,6 @@ static inline struct dev_info *which_dev(struct mddev *mddev, sector_t sector)
return conf->disks + lo;
}
-/**
- * linear_mergeable_bvec -- tell bio layer if two requests can be merged
- * @q: request queue
- * @bvm: properties of new bio
- * @biovec: the request that could be merged to it.
- *
- * Return amount of bytes we can take at this offset
- */
-static int linear_mergeable_bvec(struct request_queue *q,
- struct bvec_merge_data *bvm,
- struct bio_vec *biovec)
-{
- struct mddev *mddev = q->queuedata;
- struct dev_info *dev0;
- unsigned long maxsectors, bio_sectors = bvm->bi_size >> 9;
- sector_t sector = bvm->bi_sector + get_start_sect(bvm->bi_bdev);
- int maxbytes = biovec->bv_len;
- struct request_queue *subq;
-
- rcu_read_lock();
- dev0 = which_dev(mddev, sector);
- maxsectors = dev0->end_sector - sector;
- subq = bdev_get_queue(dev0->rdev->bdev);
- if (subq->merge_bvec_fn) {
- bvm->bi_bdev = dev0->rdev->bdev;
- bvm->bi_sector -= dev0->end_sector - dev0->rdev->sectors;
- maxbytes = min(maxbytes, subq->merge_bvec_fn(subq, bvm,
- biovec));
- }
- rcu_read_unlock();
-
- if (maxsectors < bio_sectors)
- maxsectors = 0;
- else
- maxsectors -= bio_sectors;
-
- if (maxsectors <= (PAGE_SIZE >> 9 ) && bio_sectors == 0)
- return maxbytes;
-
- if (maxsectors > (maxbytes >> 9))
- return maxbytes;
- else
- return maxsectors << 9;
-}
-
static int linear_congested(void *data, int bits)
{
struct mddev *mddev = data;
@@ -217,7 +172,6 @@ static int linear_run (struct mddev *mddev)
mddev->private = conf;
md_set_array_sectors(mddev, linear_size(mddev, 0, 0));
- blk_queue_merge_bvec(mddev->queue, linear_mergeable_bvec);
mddev->queue->backing_dev_info.congested_fn = linear_congested;
mddev->queue->backing_dev_info.congested_data = mddev;
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 48234eb..0e34b76 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -5033,7 +5033,6 @@ static void md_clean(struct mddev *mddev)
mddev->changed = 0;
mddev->degraded = 0;
mddev->safemode = 0;
- mddev->merge_check_needed = 0;
mddev->bitmap_info.offset = 0;
mddev->bitmap_info.default_offset = 0;
mddev->bitmap_info.default_space = 0;
@@ -5201,7 +5200,6 @@ static int do_md_stop(struct mddev *mddev, int mode,
__md_stop_writes(mddev);
__md_stop(mddev);
- mddev->queue->merge_bvec_fn = NULL;
mddev->queue->backing_dev_info.congested_fn = NULL;
/* tell userspace to handle 'inactive' */
diff --git a/drivers/md/md.h b/drivers/md/md.h
index 03cec5b..4932445 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -132,10 +132,6 @@ enum flag_bits {
Bitmap_sync, /* ..actually, not quite In_sync. Need a
* bitmap-based recovery to get fully in sync
*/
- Unmerged, /* device is being added to array and should
- * be considerred for bvec_merge_fn but not
- * yet for actual IO
- */
WriteMostly, /* Avoid reading if at all possible */
AutoDetected, /* added by auto-detect */
Blocked, /* An error occurred but has not yet
@@ -366,10 +362,6 @@ struct mddev {
int degraded; /* whether md should consider
* adding a spare
*/
- int merge_check_needed; /* at least one
- * member device
- * has a
- * merge_bvec_fn */
atomic_t recovery_active; /* blocks scheduled, but not written */
wait_queue_head_t recovery_wait;
diff --git a/drivers/md/multipath.c b/drivers/md/multipath.c
index 399272f..2f82954 100644
--- a/drivers/md/multipath.c
+++ b/drivers/md/multipath.c
@@ -261,18 +261,6 @@ static int multipath_add_disk(struct mddev *mddev, struct md_rdev *rdev)
disk_stack_limits(mddev->gendisk, rdev->bdev,
rdev->data_offset << 9);
- /* as we don't honour merge_bvec_fn, we must never risk
- * violating it, so limit ->max_segments to one, lying
- * within a single page.
- * (Note: it is very unlikely that a device with
- * merge_bvec_fn will be involved in multipath.)
- */
- if (q->merge_bvec_fn) {
- blk_queue_max_segments(mddev->queue, 1);
- blk_queue_segment_boundary(mddev->queue,
- PAGE_CACHE_SIZE - 1);
- }
-
spin_lock_irq(&conf->device_lock);
mddev->degraded--;
rdev->raid_disk = path;
@@ -436,15 +424,6 @@ static int multipath_run (struct mddev *mddev)
disk_stack_limits(mddev->gendisk, rdev->bdev,
rdev->data_offset << 9);
- /* as we don't honour merge_bvec_fn, we must never risk
- * violating it, not that we ever expect a device with
- * a merge_bvec_fn to be involved in multipath */
- if (rdev->bdev->bd_disk->queue->merge_bvec_fn) {
- blk_queue_max_segments(mddev->queue, 1);
- blk_queue_segment_boundary(mddev->queue,
- PAGE_CACHE_SIZE - 1);
- }
-
if (!test_bit(Faulty, &rdev->flags))
working_disks++;
}
diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index ba6b85d..bc4c0b6 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -195,9 +195,6 @@ static int create_strip_zones(struct mddev *mddev, struct r0conf **private_conf)
disk_stack_limits(mddev->gendisk, rdev1->bdev,
rdev1->data_offset << 9);
- if (rdev1->bdev->bd_disk->queue->merge_bvec_fn)
- conf->has_merge_bvec = 1;
-
if (!smallest || (rdev1->sectors < smallest->sectors))
smallest = rdev1;
cnt++;
@@ -354,59 +351,6 @@ static struct md_rdev *map_sector(struct mddev *mddev, struct strip_zone *zone,
+ sector_div(sector, zone->nb_dev)];
}
-/**
- * raid0_mergeable_bvec -- tell bio layer if two requests can be merged
- * @q: request queue
- * @bvm: properties of new bio
- * @biovec: the request that could be merged to it.
- *
- * Return amount of bytes we can accept at this offset
- */
-static int raid0_mergeable_bvec(struct request_queue *q,
- struct bvec_merge_data *bvm,
- struct bio_vec *biovec)
-{
- struct mddev *mddev = q->queuedata;
- struct r0conf *conf = mddev->private;
- sector_t sector = bvm->bi_sector + get_start_sect(bvm->bi_bdev);
- sector_t sector_offset = sector;
- int max;
- unsigned int chunk_sectors = mddev->chunk_sectors;
- unsigned int bio_sectors = bvm->bi_size >> 9;
- struct strip_zone *zone;
- struct md_rdev *rdev;
- struct request_queue *subq;
-
- if (is_power_of_2(chunk_sectors))
- max = (chunk_sectors - ((sector & (chunk_sectors-1))
- + bio_sectors)) << 9;
- else
- max = (chunk_sectors - (sector_div(sector, chunk_sectors)
- + bio_sectors)) << 9;
- if (max < 0)
- max = 0; /* bio_add cannot handle a negative return */
- if (max <= biovec->bv_len && bio_sectors == 0)
- return biovec->bv_len;
- if (max < biovec->bv_len)
- /* too small already, no need to check further */
- return max;
- if (!conf->has_merge_bvec)
- return max;
-
- /* May need to check subordinate device */
- sector = sector_offset;
- zone = find_zone(mddev->private, §or_offset);
- rdev = map_sector(mddev, zone, sector, §or_offset);
- subq = bdev_get_queue(rdev->bdev);
- if (subq->merge_bvec_fn) {
- bvm->bi_bdev = rdev->bdev;
- bvm->bi_sector = sector_offset + zone->dev_start +
- rdev->data_offset;
- return min(max, subq->merge_bvec_fn(subq, bvm, biovec));
- } else
- return max;
-}
-
static sector_t raid0_size(struct mddev *mddev, sector_t sectors, int raid_disks)
{
sector_t array_sectors = 0;
@@ -471,7 +415,6 @@ static int raid0_run(struct mddev *mddev)
mddev->queue->backing_dev_info.ra_pages = 2* stripe;
}
- blk_queue_merge_bvec(mddev->queue, raid0_mergeable_bvec);
dump_zones(mddev);
ret = md_integrity_register(mddev);
diff --git a/drivers/md/raid0.h b/drivers/md/raid0.h
index 05539d9..7127a62 100644
--- a/drivers/md/raid0.h
+++ b/drivers/md/raid0.h
@@ -12,8 +12,6 @@ struct r0conf {
struct md_rdev **devlist; /* lists of rdevs, pointed to
* by strip_zone->dev */
int nr_strip_zones;
- int has_merge_bvec; /* at least one member has
- * a merge_bvec_fn */
};
#endif
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 40b35be..c2f236c 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -551,7 +551,6 @@ static int read_balance(struct r1conf *conf, struct r1bio *r1_bio, int *max_sect
rdev = rcu_dereference(conf->mirrors[disk].rdev);
if (r1_bio->bios[disk] == IO_BLOCKED
|| rdev == NULL
- || test_bit(Unmerged, &rdev->flags)
|| test_bit(Faulty, &rdev->flags))
continue;
if (!test_bit(In_sync, &rdev->flags) &&
@@ -701,39 +700,6 @@ static int read_balance(struct r1conf *conf, struct r1bio *r1_bio, int *max_sect
return best_disk;
}
-static int raid1_mergeable_bvec(struct request_queue *q,
- struct bvec_merge_data *bvm,
- struct bio_vec *biovec)
-{
- struct mddev *mddev = q->queuedata;
- struct r1conf *conf = mddev->private;
- sector_t sector = bvm->bi_sector + get_start_sect(bvm->bi_bdev);
- int max = biovec->bv_len;
-
- if (mddev->merge_check_needed) {
- int disk;
- rcu_read_lock();
- for (disk = 0; disk < conf->raid_disks * 2; disk++) {
- struct md_rdev *rdev = rcu_dereference(
- conf->mirrors[disk].rdev);
- if (rdev && !test_bit(Faulty, &rdev->flags)) {
- struct request_queue *q =
- bdev_get_queue(rdev->bdev);
- if (q->merge_bvec_fn) {
- bvm->bi_sector = sector +
- rdev->data_offset;
- bvm->bi_bdev = rdev->bdev;
- max = min(max, q->merge_bvec_fn(
- q, bvm, biovec));
- }
- }
- }
- rcu_read_unlock();
- }
- return max;
-
-}
-
int md_raid1_congested(struct mddev *mddev, int bits)
{
struct r1conf *conf = mddev->private;
@@ -1266,8 +1232,7 @@ read_again:
break;
}
r1_bio->bios[i] = NULL;
- if (!rdev || test_bit(Faulty, &rdev->flags)
- || test_bit(Unmerged, &rdev->flags)) {
+ if (!rdev || test_bit(Faulty, &rdev->flags)) {
if (i < conf->raid_disks)
set_bit(R1BIO_Degraded, &r1_bio->state);
continue;
@@ -1611,7 +1576,6 @@ static int raid1_add_disk(struct mddev *mddev, struct md_rdev *rdev)
struct raid1_info *p;
int first = 0;
int last = conf->raid_disks - 1;
- struct request_queue *q = bdev_get_queue(rdev->bdev);
if (mddev->recovery_disabled == conf->recovery_disabled)
return -EBUSY;
@@ -1619,11 +1583,6 @@ static int raid1_add_disk(struct mddev *mddev, struct md_rdev *rdev)
if (rdev->raid_disk >= 0)
first = last = rdev->raid_disk;
- if (q->merge_bvec_fn) {
- set_bit(Unmerged, &rdev->flags);
- mddev->merge_check_needed = 1;
- }
-
for (mirror = first; mirror <= last; mirror++) {
p = conf->mirrors+mirror;
if (!p->rdev) {
@@ -1655,19 +1614,6 @@ static int raid1_add_disk(struct mddev *mddev, struct md_rdev *rdev)
break;
}
}
- if (err == 0 && test_bit(Unmerged, &rdev->flags)) {
- /* Some requests might not have seen this new
- * merge_bvec_fn. We must wait for them to complete
- * before merging the device fully.
- * First we make sure any code which has tested
- * our function has submitted the request, then
- * we wait for all outstanding requests to complete.
- */
- synchronize_sched();
- freeze_array(conf, 0);
- unfreeze_array(conf);
- clear_bit(Unmerged, &rdev->flags);
- }
md_integrity_add_rdev(rdev, mddev);
if (mddev->queue && blk_queue_discard(bdev_get_queue(rdev->bdev)))
queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, mddev->queue);
@@ -2810,8 +2756,6 @@ static struct r1conf *setup_conf(struct mddev *mddev)
goto abort;
disk->rdev = rdev;
q = bdev_get_queue(rdev->bdev);
- if (q->merge_bvec_fn)
- mddev->merge_check_needed = 1;
disk->head_position = 0;
disk->seq_start = MaxSector;
@@ -2957,7 +2901,6 @@ static int run(struct mddev *mddev)
if (mddev->queue) {
mddev->queue->backing_dev_info.congested_fn = raid1_congested;
mddev->queue->backing_dev_info.congested_data = mddev;
- blk_queue_merge_bvec(mddev->queue, raid1_mergeable_bvec);
if (discard_supported)
queue_flag_set_unlocked(QUEUE_FLAG_DISCARD,
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 4a40354..08772a9 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -672,94 +672,6 @@ static sector_t raid10_find_virt(struct r10conf *conf, sector_t sector, int dev)
return (vchunk << geo->chunk_shift) + offset;
}
-/**
- * raid10_mergeable_bvec -- tell bio layer if a two requests can be merged
- * @q: request queue
- * @bvm: properties of new bio
- * @biovec: the request that could be merged to it.
- *
- * Return amount of bytes we can accept at this offset
- * This requires checking for end-of-chunk if near_copies != raid_disks,
- * and for subordinate merge_bvec_fns if merge_check_needed.
- */
-static int raid10_mergeable_bvec(struct request_queue *q,
- struct bvec_merge_data *bvm,
- struct bio_vec *biovec)
-{
- struct mddev *mddev = q->queuedata;
- struct r10conf *conf = mddev->private;
- sector_t sector = bvm->bi_sector + get_start_sect(bvm->bi_bdev);
- int max;
- unsigned int chunk_sectors;
- unsigned int bio_sectors = bvm->bi_size >> 9;
- struct geom *geo = &conf->geo;
-
- chunk_sectors = (conf->geo.chunk_mask & conf->prev.chunk_mask) + 1;
- if (conf->reshape_progress != MaxSector &&
- ((sector >= conf->reshape_progress) !=
- conf->mddev->reshape_backwards))
- geo = &conf->prev;
-
- if (geo->near_copies < geo->raid_disks) {
- max = (chunk_sectors - ((sector & (chunk_sectors - 1))
- + bio_sectors)) << 9;
- if (max < 0)
- /* bio_add cannot handle a negative return */
- max = 0;
- if (max <= biovec->bv_len && bio_sectors == 0)
- return biovec->bv_len;
- } else
- max = biovec->bv_len;
-
- if (mddev->merge_check_needed) {
- struct {
- struct r10bio r10_bio;
- struct r10dev devs[conf->copies];
- } on_stack;
- struct r10bio *r10_bio = &on_stack.r10_bio;
- int s;
- if (conf->reshape_progress != MaxSector) {
- /* Cannot give any guidance during reshape */
- if (max <= biovec->bv_len && bio_sectors == 0)
- return biovec->bv_len;
- return 0;
- }
- r10_bio->sector = sector;
- raid10_find_phys(conf, r10_bio);
- rcu_read_lock();
- for (s = 0; s < conf->copies; s++) {
- int disk = r10_bio->devs[s].devnum;
- struct md_rdev *rdev = rcu_dereference(
- conf->mirrors[disk].rdev);
- if (rdev && !test_bit(Faulty, &rdev->flags)) {
- struct request_queue *q =
- bdev_get_queue(rdev->bdev);
- if (q->merge_bvec_fn) {
- bvm->bi_sector = r10_bio->devs[s].addr
- + rdev->data_offset;
- bvm->bi_bdev = rdev->bdev;
- max = min(max, q->merge_bvec_fn(
- q, bvm, biovec));
- }
- }
- rdev = rcu_dereference(conf->mirrors[disk].replacement);
- if (rdev && !test_bit(Faulty, &rdev->flags)) {
- struct request_queue *q =
- bdev_get_queue(rdev->bdev);
- if (q->merge_bvec_fn) {
- bvm->bi_sector = r10_bio->devs[s].addr
- + rdev->data_offset;
- bvm->bi_bdev = rdev->bdev;
- max = min(max, q->merge_bvec_fn(
- q, bvm, biovec));
- }
- }
- }
- rcu_read_unlock();
- }
- return max;
-}
-
/*
* This routine returns the disk from which the requested read should
* be done. There is a per-array 'next expected sequential IO' sector
@@ -822,12 +734,10 @@ retry:
disk = r10_bio->devs[slot].devnum;
rdev = rcu_dereference(conf->mirrors[disk].replacement);
if (rdev == NULL || test_bit(Faulty, &rdev->flags) ||
- test_bit(Unmerged, &rdev->flags) ||
r10_bio->devs[slot].addr + sectors > rdev->recovery_offset)
rdev = rcu_dereference(conf->mirrors[disk].rdev);
if (rdev == NULL ||
- test_bit(Faulty, &rdev->flags) ||
- test_bit(Unmerged, &rdev->flags))
+ test_bit(Faulty, &rdev->flags))
continue;
if (!test_bit(In_sync, &rdev->flags) &&
r10_bio->devs[slot].addr + sectors > rdev->recovery_offset)
@@ -1336,11 +1246,9 @@ retry_write:
blocked_rdev = rrdev;
break;
}
- if (rdev && (test_bit(Faulty, &rdev->flags)
- || test_bit(Unmerged, &rdev->flags)))
+ if (rdev && (test_bit(Faulty, &rdev->flags)))
rdev = NULL;
- if (rrdev && (test_bit(Faulty, &rrdev->flags)
- || test_bit(Unmerged, &rrdev->flags)))
+ if (rrdev && (test_bit(Faulty, &rrdev->flags)))
rrdev = NULL;
r10_bio->devs[i].bio = NULL;
@@ -1787,7 +1695,6 @@ static int raid10_add_disk(struct mddev *mddev, struct md_rdev *rdev)
int mirror;
int first = 0;
int last = conf->geo.raid_disks - 1;
- struct request_queue *q = bdev_get_queue(rdev->bdev);
if (mddev->recovery_cp < MaxSector)
/* only hot-add to in-sync arrays, as recovery is
@@ -1800,11 +1707,6 @@ static int raid10_add_disk(struct mddev *mddev, struct md_rdev *rdev)
if (rdev->raid_disk >= 0)
first = last = rdev->raid_disk;
- if (q->merge_bvec_fn) {
- set_bit(Unmerged, &rdev->flags);
- mddev->merge_check_needed = 1;
- }
-
if (rdev->saved_raid_disk >= first &&
conf->mirrors[rdev->saved_raid_disk].rdev == NULL)
mirror = rdev->saved_raid_disk;
@@ -1843,19 +1745,6 @@ static int raid10_add_disk(struct mddev *mddev, struct md_rdev *rdev)
rcu_assign_pointer(p->rdev, rdev);
break;
}
- if (err == 0 && test_bit(Unmerged, &rdev->flags)) {
- /* Some requests might not have seen this new
- * merge_bvec_fn. We must wait for them to complete
- * before merging the device fully.
- * First we make sure any code which has tested
- * our function has submitted the request, then
- * we wait for all outstanding requests to complete.
- */
- synchronize_sched();
- freeze_array(conf, 0);
- unfreeze_array(conf);
- clear_bit(Unmerged, &rdev->flags);
- }
md_integrity_add_rdev(rdev, mddev);
if (mddev->queue && blk_queue_discard(bdev_get_queue(rdev->bdev)))
queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, mddev->queue);
@@ -2404,7 +2293,6 @@ static void fix_read_error(struct r10conf *conf, struct mddev *mddev, struct r10
d = r10_bio->devs[sl].devnum;
rdev = rcu_dereference(conf->mirrors[d].rdev);
if (rdev &&
- !test_bit(Unmerged, &rdev->flags) &&
test_bit(In_sync, &rdev->flags) &&
is_badblock(rdev, r10_bio->devs[sl].addr + sect, s,
&first_bad, &bad_sectors) == 0) {
@@ -2458,7 +2346,6 @@ static void fix_read_error(struct r10conf *conf, struct mddev *mddev, struct r10
d = r10_bio->devs[sl].devnum;
rdev = rcu_dereference(conf->mirrors[d].rdev);
if (!rdev ||
- test_bit(Unmerged, &rdev->flags) ||
!test_bit(In_sync, &rdev->flags))
continue;
@@ -3657,8 +3544,6 @@ static int run(struct mddev *mddev)
disk->rdev = rdev;
}
q = bdev_get_queue(rdev->bdev);
- if (q->merge_bvec_fn)
- mddev->merge_check_needed = 1;
diff = (rdev->new_data_offset - rdev->data_offset);
if (!mddev->reshape_backwards)
diff = -diff;
@@ -3757,7 +3642,6 @@ static int run(struct mddev *mddev)
stripe /= conf->geo.near_copies;
if (mddev->queue->backing_dev_info.ra_pages < 2 * stripe)
mddev->queue->backing_dev_info.ra_pages = 2 * stripe;
- blk_queue_merge_bvec(mddev->queue, raid10_mergeable_bvec);
}
if (md_integrity_register(mddev))
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 40e464c..6008a30 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -4103,32 +4103,6 @@ static int raid5_congested(void *data, int bits)
md_raid5_congested(mddev, bits);
}
-/* We want read requests to align with chunks where possible,
- * but write requests don't need to.
- */
-static int raid5_mergeable_bvec(struct request_queue *q,
- struct bvec_merge_data *bvm,
- struct bio_vec *biovec)
-{
- struct mddev *mddev = q->queuedata;
- sector_t sector = bvm->bi_sector + get_start_sect(bvm->bi_bdev);
- int max;
- unsigned int chunk_sectors = mddev->chunk_sectors;
- unsigned int bio_sectors = bvm->bi_size >> 9;
-
- if ((bvm->bi_rw & 1) == WRITE)
- return biovec->bv_len; /* always allow writes to be mergeable */
-
- if (mddev->new_chunk_sectors < mddev->chunk_sectors)
- chunk_sectors = mddev->new_chunk_sectors;
- max = (chunk_sectors - ((sector & (chunk_sectors - 1)) + bio_sectors)) << 9;
- if (max < 0) max = 0;
- if (max <= biovec->bv_len && bio_sectors == 0)
- return biovec->bv_len;
- else
- return max;
-}
-
static int in_chunk_boundary(struct mddev *mddev, struct bio *bio)
{
sector_t sector = bio->bi_iter.bi_sector + get_start_sect(bio->bi_bdev);
@@ -6152,8 +6126,6 @@ static int run(struct mddev *mddev)
if (mddev->queue->backing_dev_info.ra_pages < 2 * stripe)
mddev->queue->backing_dev_info.ra_pages = 2 * stripe;
- blk_queue_merge_bvec(mddev->queue, raid5_mergeable_bvec);
-
mddev->queue->backing_dev_info.congested_data = mddev;
mddev->queue->backing_dev_info.congested_fn = raid5_congested;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index c03e37a..7a8c95c 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -239,14 +239,6 @@ typedef int (prep_rq_fn) (struct request_queue *, struct request *);
typedef void (unprep_rq_fn) (struct request_queue *, struct request *);
struct bio_vec;
-struct bvec_merge_data {
- struct block_device *bi_bdev;
- sector_t bi_sector;
- unsigned bi_size;
- unsigned long bi_rw;
-};
-typedef int (merge_bvec_fn) (struct request_queue *, struct bvec_merge_data *,
- struct bio_vec *);
typedef void (softirq_done_fn)(struct request *);
typedef int (dma_drain_needed_fn)(struct request *);
typedef int (lld_busy_fn) (struct request_queue *q);
@@ -327,7 +319,6 @@ struct request_queue {
make_request_fn *make_request_fn;
prep_rq_fn *prep_rq_fn;
unprep_rq_fn *unprep_rq_fn;
- merge_bvec_fn *merge_bvec_fn;
softirq_done_fn *softirq_done_fn;
rq_timed_out_fn *rq_timed_out_fn;
dma_drain_needed_fn *dma_drain_needed;
@@ -1036,7 +1027,6 @@ extern void blk_queue_lld_busy(struct request_queue *q, lld_busy_fn *fn);
extern void blk_queue_segment_boundary(struct request_queue *, unsigned long);
extern void blk_queue_prep_rq(struct request_queue *, prep_rq_fn *pfn);
extern void blk_queue_unprep_rq(struct request_queue *, unprep_rq_fn *ufn);
-extern void blk_queue_merge_bvec(struct request_queue *, merge_bvec_fn *);
extern void blk_queue_dma_alignment(struct request_queue *, int);
extern void blk_queue_update_dma_alignment(struct request_queue *, int);
extern void blk_queue_softirq_done(struct request_queue *, softirq_done_fn *);
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index ca6d2acc..2f7f2df 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -77,9 +77,6 @@ typedef int (*dm_message_fn) (struct dm_target *ti, unsigned argc, char **argv);
typedef int (*dm_ioctl_fn) (struct dm_target *ti, unsigned int cmd,
unsigned long arg);
-typedef int (*dm_merge_fn) (struct dm_target *ti, struct bvec_merge_data *bvm,
- struct bio_vec *biovec, int max_size);
-
/*
* These iteration functions are typically used to check (and combine)
* properties of underlying devices.
@@ -153,7 +150,6 @@ struct target_type {
dm_status_fn status;
dm_message_fn message;
dm_ioctl_fn ioctl;
- dm_merge_fn merge;
dm_busy_fn busy;
dm_iterate_devices_fn iterate_devices;
dm_io_hints_fn io_hints;
--
2.1.0
^ permalink raw reply related
* [PATCH v2 6/9] md/raid5: get rid of bio_fits_rdev()
From: Dongsu Park @ 2015-01-12 11:49 UTC (permalink / raw)
To: linux-kernel
Cc: Christoph Hellwig, Kent Overstreet, Jens Axboe, Neil Brown,
linux-raid, Dongsu Park
In-Reply-To: <cover.1421052745.git.dongsu.park@profitbricks.com>
From: Kent Overstreet <kmo@daterainc.com>
Remove bio_fits_rdev() completely, because ->merge_bvec_fn() has now
gone. There's no point in calling bio_fits_rdev() only for ensuring
aligned read from rdev.
Cc: Neil Brown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Signed-off-by: Kent Overstreet <kmo@daterainc.com>
[dpark: add more description in commit message]
Signed-off-by: Dongsu Park <dongsu.park@profitbricks.com>
---
drivers/md/raid5.c | 23 +----------------------
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index c1b0d52..40e464c 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -4218,25 +4218,6 @@ static void raid5_align_endio(struct bio *bi, int error)
add_bio_to_retry(raid_bi, conf);
}
-static int bio_fits_rdev(struct bio *bi)
-{
- struct request_queue *q = bdev_get_queue(bi->bi_bdev);
-
- if (bio_sectors(bi) > queue_max_sectors(q))
- return 0;
- blk_recount_segments(q, bi);
- if (bi->bi_phys_segments > queue_max_segments(q))
- return 0;
-
- if (q->merge_bvec_fn)
- /* it's too hard to apply the merge_bvec_fn at this stage,
- * just just give up
- */
- return 0;
-
- return 1;
-}
-
static int chunk_aligned_read(struct mddev *mddev, struct bio * raid_bio)
{
struct r5conf *conf = mddev->private;
@@ -4290,11 +4271,9 @@ static int chunk_aligned_read(struct mddev *mddev, struct bio * raid_bio)
align_bi->bi_bdev = rdev->bdev;
__clear_bit(BIO_SEG_VALID, &align_bi->bi_flags);
- if (!bio_fits_rdev(align_bi) ||
- is_badblock(rdev, align_bi->bi_iter.bi_sector,
+ if (is_badblock(rdev, align_bi->bi_iter.bi_sector,
bio_sectors(align_bi),
&first_bad, &bad_sectors)) {
- /* too big in some way, or has a known bad block */
bio_put(align_bi);
rdev_dec_pending(rdev, mddev);
return 0;
--
2.1.0
^ permalink raw reply related
* [PATCH v2 5/7] md/raid10: make sync_request_write() call bio_copy_data()
From: Dongsu Park @ 2015-01-12 11:44 UTC (permalink / raw)
To: linux-kernel
Cc: Christoph Hellwig, Kent Overstreet, Jens Axboe, Neil Brown,
linux-raid, Dongsu Park
In-Reply-To: <cover.1421052656.git.dongsu.park@profitbricks.com>
From: Kent Overstreet <kmo@daterainc.com>
Refactor sync_request_write() of md/raid10 to use bio_copy_data()
instead of open coding bio_vec iterations.
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Neil Brown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Signed-off-by: Kent Overstreet <kmo@daterainc.com>
[dpark: add more description in commit message]
Signed-off-by: Dongsu Park <dongsu.park@profitbricks.com>
---
drivers/md/raid10.c | 20 +++++---------------
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 32e282f..4a40354 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2107,18 +2107,11 @@ static void sync_request_write(struct mddev *mddev, struct r10bio *r10_bio)
tbio->bi_vcnt = vcnt;
tbio->bi_iter.bi_size = r10_bio->sectors << 9;
tbio->bi_rw = WRITE;
- tbio->bi_private = r10_bio;
tbio->bi_iter.bi_sector = r10_bio->devs[i].addr;
-
- for (j=0; j < vcnt ; j++) {
- tbio->bi_io_vec[j].bv_offset = 0;
- tbio->bi_io_vec[j].bv_len = PAGE_SIZE;
-
- memcpy(page_address(tbio->bi_io_vec[j].bv_page),
- page_address(fbio->bi_io_vec[j].bv_page),
- PAGE_SIZE);
- }
tbio->bi_end_io = end_sync_write;
+ tbio->bi_private = r10_bio;
+
+ bio_copy_data(tbio, fbio);
d = r10_bio->devs[i].devnum;
atomic_inc(&conf->mirrors[d].rdev->nr_pending);
@@ -2134,17 +2127,14 @@ static void sync_request_write(struct mddev *mddev, struct r10bio *r10_bio)
* that are active
*/
for (i = 0; i < conf->copies; i++) {
- int j, d;
+ int d;
tbio = r10_bio->devs[i].repl_bio;
if (!tbio || !tbio->bi_end_io)
continue;
if (r10_bio->devs[i].bio->bi_end_io != end_sync_write
&& r10_bio->devs[i].bio != fbio)
- for (j = 0; j < vcnt; j++)
- memcpy(page_address(tbio->bi_io_vec[j].bv_page),
- page_address(fbio->bi_io_vec[j].bv_page),
- PAGE_SIZE);
+ bio_copy_data(tbio, fbio);
d = r10_bio->devs[i].devnum;
atomic_inc(&r10_bio->remaining);
md_sync_acct(conf->mirrors[d].replacement->bdev,
--
2.1.0
^ permalink raw reply related
* Re: mdadm RAID6 "active" with spares and failed disks; need help
From: Valentijn Sessink @ 2015-01-11 23:22 UTC (permalink / raw)
To: Matt Callaghan, linux-raid
In-Reply-To: <BLU437-SMTP96782B2C74C634FDED13D681420@phx.gbl>
Hi Matt,
I'm by no means a specialist, but I have been saving a few arrays
lately, so here's my 2 cents. From what I see, I'd say you're almost
there, but you didn't use "--bitmap=none" in your create-statement and
as far as I can see, there is no bitmap specified in the original raid
blocks but there is one in the newly created one. I may be wrong
though!, please take my advice with a grain of salt and at your own risk.
Also, I would not have dared to run all these statements on "live" (or
dead, for that matter ;-) disks. See my posting (that is unfinished, but
I'll add info as I have time) at
http://valentijn.sessink.nl/?p=557 where I use "dmsetup" to create a few
virtual disks - all writes are redirected to another device. Fun thing
is, that after that, you can mess up all you want. You just remove the
virtual disk and poof, everything is as it was before (failed raid and
all, isn't that funny? :)
I hope this helps.
Best regards,
Valentijn
On 11-01-15 21:26, Matt Callaghan wrote:
> Updating this e-mail thread. I got the latest mdadm version that
> supports data offset variance per device and attempted to reconstruct
> RAID6 according to previous data, but so far no luck.
> As far as I a can tell (sadly), all of my data is lost. I've updated the
> forum thread with the final details and failures.
> http://www.linuxquestions.org/questions/linux-server-73/mdadm-raid6-active-with-spares-and-failed-disks%3B-need-help-4175530127/
--
✉ v@lentijn.sess.ink ☏ +31777777713 (31 7x7 13)
⌂ durgerdamstraat 29 zaandam
--
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: mdadm RAID6 "active" with spares and failed disks; need help
From: Matt Callaghan @ 2015-01-11 20:26 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <BLU436-SMTP156F9ECC68035EAC3DFB5F181460@phx.gbl>
Updating this e-mail thread. I got the latest mdadm version that
supports data offset variance per device and attempted to reconstruct
RAID6 according to previous data, but so far no luck.
As far as I a can tell (sadly), all of my data is lost. I've updated the
forum thread with the final details and failures.
http://www.linuxquestions.org/questions/linux-server-73/mdadm-raid6-active-with-spares-and-failed-disks%3B-need-help-4175530127/
I'll leave the drives "in this state" until end of the month in hopes
that someone has another idea on how to recover.
NOTE: I will pay $$$ if there is a person that helps me to recover the
data :)
~Matt
-------- Original Message --------
From: Matt Callaghan <matt_callaghan@sympatico.ca>
Sent: Wed 07 Jan 2015 08:34:01 AM EST
To: linux-raid@vger.kernel.org
Cc:
Subject: Re: mdadm RAID6 "active" with spares and failed disks; need help
> Just to give a small update (I realize many people may still be on
holidays)
I've tried to work with a few people on IRC, and in conjunction with
lots of reading from others' experiences attempting to recover the array
but no luck yet.
I /hope/ I haven't ruined anything.
The forum post referenced below has full details, but here's a summary
of "what happened"
notice how some drives are "moving" around :( [either due to a mistake I
made, or the server haulting/lockup during rebuilds, I'm not sure]
{{{
-------------------------------------------------------------------------------------------
| | Device Role #
-------------------------------------------------------------------------------------------
| DEVICE | COMMENTS | Dec GOOD | Jan4 6:28AM | 12:10PM | 12:40PM |
Jan5 12:30AM | 12:50AM | 8:30AM | 6:34PM | Jan6 6:45AM |
-------------------------------------------------------------------------------------------
| /dev/sdi | | 4 | 4 | 4 | 4 |
4 | 4 | 4 | 4 | 4 |
| /dev/sdj | failing | 5 | 5 FAIL | ( ) | 8 |
8 | 8 FAIL | ( ) | ( ) | ( ) |
| /dev/sdk | failing? | 0 | 0 | 0 | 0 |
0 | 0 | 0 | 0 FAIL | 0 FAIL |
| /dev/sdl | | 6 | 6 | 6 | 6 |
6 | 6 | 6 | 6 | 6 |
| /dev/sdm | | 1 | 1 | 1 | 1 | (
) | ( ) | ( ) | 8 | 8 SPARE |
| /dev/sdn | | 2 | 2 | 2 | 2 |
2 | 2 | 2 | 2 | 2 |
| /dev/sdo | | 3 | 3 | 3 | 3 |
3 | 3 | 3 | 3 | 3 |
| /dev/sdp | | 7 | 7 | 7 | 7 |
7 | 7 | 7 | 7 | 7 |
-------------------------------------------------------------------------------------------
}}}
Full details from my e-mail notifications of /proc/mdstat (although
unfortunately I don't have FULL mdadm --detail/examine information per
state transition)
{{{
Dec GOOD
md2000 : active raid6 sdo1[3] sdj1[5] sdk1[0] sdi1[4] sdn1[2] sdm1[1]
sdp1[7] sdl1[6]
11721080448 blocks super 1.1 level 6, 64k chunk, algorithm 2
[8/8] [UUUUUUUU]
FAIL EVENT on Jan 4th @ 6:28AM
md2000 : active raid6 sdo1[3] sdj1[5](F) sdk1[0] sdi1[4] sdn1[2] sdm1[1]
sdp1[7] sdl1[6]
11721080448 blocks super 1.1 level 6, 64k chunk, algorithm 2
[8/7] [UUUU_UUU]
[==============>......] check = 73.6% (1439539228/1953513408)
finish=536.6min speed=15960K/sec
DEGRADED EVENT on Jan 4th @ 6:39AM
md2000 : active raid6 sdo1[3] sdj1[5](F) sdk1[0] sdi1[4] sdn1[2] sdm1[1]
sdp1[7] sdl1[6]
11721080448 blocks super 1.1 level 6, 64k chunk, algorithm 2
[8/7] [UUUU_UUU]
[==============>......] check = 73.6% (1439539228/1953513408)
finish=5091.8min speed=1682K/sec
DEGRADED EVENT on Jan 4th @ 12:10PM
md2000 : active raid6 sdo1[3] sdn1[2] sdi1[4] sdm1[1] sdk1[0] sdp1[7]
sdl1[6]
11721080448 blocks super 1.1 level 6, 64k chunk, algorithm 2
[8/7] [UUUU_UUU]
DEGRADED EVENT on Jan 4th @ 12:21PM
md2000 : active raid6 sdk1[0] sdo1[3] sdm1[1] sdn1[2] sdi1[4] sdp1[7]
sdl1[6]
11721080448 blocks super 1.1 level 6, 64k chunk, algorithm 2
[8/7] [UUUU_UUU]
DEGRADED EVENT on Jan 4th @ 12:40PM
md2000 : active raid6 sdj1[8] sdm1[1] sdo1[3] sdn1[2] sdk1[0] sdi1[4]
sdp1[7] sdl1[6]
11721080448 blocks super 1.1 level 6, 64k chunk, algorithm 2
[8/7] [UUUU_UUU]
[>....................] recovery = 0.2% (5137892/1953513408)
finish=921.7min speed=35227K/sec
DEGRADED EVENT on Jan 5th @ 12:30AM
md2000 : active raid6 sdk1[0] sdo1[3] sdn1[2] sdj1[8] sdi1[4] sdl1[6]
sdp1[7]
11721080448 blocks super 1.1 level 6, 64k chunk, algorithm 2
[8/6] [U_UU_UUU]
[============>........] recovery = 62.9% (1229102028/1953513408)
finish=259.8min speed=46466K/sec
FAIL SPARE EVENT on Jan 5th @ 12:50AM
md2000 : active raid6 sdk1[0] sdo1[3] sdn1[2] sdj1[8](F) sdi1[4] sdl1[6]
sdp1[7]
11721080448 blocks super 1.1 level 6, 64k chunk, algorithm 2
[8/6] [U_UU_UUU]
[=============>.......] recovery = 68.1% (1332029020/1953513408)
finish=150.3min speed=68897K/sec
DEGRADED EVENT on Jan 5th @ 6:43AM
md2000 : active raid6 sdk1[0] sdo1[3] sdn1[2] sdj1[8](F) sdi1[4] sdl1[6]
sdp1[7]
11721080448 blocks super 1.1 level 6, 64k chunk, algorithm 2
[8/6] [U_UU_UUU]
[=============>.......] recovery = 68.1% (1332029020/1953513408)
finish=76028.6min speed=136K/sec
TEST MESSAGE on Jan 5th @ 8:30AM
md2000 : active raid6 sdo1[3] sdi1[4] sdn1[2] sdk1[0] sdl1[6] sdp1[7]
11721080448 blocks super 1.1 level 6, 64k chunk, algorithm 2
[8/6] [U_UU_UUU]
}}}
I've tried mdadm --create --assume-clean for several combinations of the
"device role # ordering", but so far none have exposed a usable ext4
partition for /dev/md2000.
Was speaking with someone on IRC, and it's been shown that the data
offset for the devices has changed over time in mdadm, so I need to
recompile mdadm 3.3.x and attempt it that way.
I'll update when I get to trying that.
~Fermmy
-------- Original Message --------
From: Matt Callaghan <matt_callaghan@sympatico.ca>
Sent: Tue 06 Jan 2015 09:16:52 AM EST
To: linux-raid@vger.kernel.org
Cc:
Subject: mdadm RAID6 "active" with spares and failed disks; need help
I think I'm in a really bad state. Could an expert w/ mdadm please
help?
I have a RAID6 mdadm device, and it got really messed up with spares:
{{{
md2000 : active raid6 sdm1[8](S) sdo1[3] sdi1[4] sdn1[2] sdk1[0](F)
sdl1[6] sdp1[7]
11721080448 blocks super 1.1 level 6, 64k chunk, algorithm 2
[8/5] [__UU_UUU]
}}}
And is now really broken (inactive)
{{{
md2000 : inactive sdn1[2](S) sdm1[8](S) sdl1[6](S) sdp1[7](S) sdi1[4](S)
sdo1[3](S) sdk1[0](S)
13674593976 blocks super 1.1
}}}
I have a forum post going w/ full details
http://www.linuxquestions.org/questions/linux-server-73/mdadm-raid6-active-with-spares-and-failed-disks%3B-need-help-4175530127/
I /think/ I need to force re-assembly here, but I'd like some review
from the experts before proceeding.
Thank you in advance for your time,
~Matt/Fermulator
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] dm mpath: simplify failure path of dm_miltipath_init()
From: Johannes Thumshirn @ 2015-01-11 11:45 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, dm-devel, Neil Brown
Cc: linux-raid, linux-kernel, Johannes Thumshirn
simplify failure path of dm_miltipath_init(). Currently the cleanup of all error
cases are open-coded. Introduce a common exit path and lables.
Signed-off-by: Johannes Thumshirn <morbidrsa@gmail.com>
---
drivers/md/dm-mpath.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
index 7b6b0f0..5cc3438 100644
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -1694,16 +1694,15 @@ static int __init dm_multipath_init(void)
r = dm_register_target(&multipath_target);
if (r < 0) {
DMERR("register failed %d", r);
- kmem_cache_destroy(_mpio_cache);
- return -EINVAL;
+ r = -EINVAL;
+ goto out_mpio_cache;
}
kmultipathd = alloc_workqueue("kmpathd", WQ_MEM_RECLAIM, 0);
if (!kmultipathd) {
DMERR("failed to create workqueue kmpathd");
- dm_unregister_target(&multipath_target);
- kmem_cache_destroy(_mpio_cache);
- return -ENOMEM;
+ r = -ENOMEM;
+ goto out_kmultipathd;
}
/*
@@ -1716,16 +1715,23 @@ static int __init dm_multipath_init(void)
WQ_MEM_RECLAIM);
if (!kmpath_handlerd) {
DMERR("failed to create workqueue kmpath_handlerd");
- destroy_workqueue(kmultipathd);
- dm_unregister_target(&multipath_target);
- kmem_cache_destroy(_mpio_cache);
- return -ENOMEM;
+ r = -ENOMEM;
+ goto out_kmpath_handlerd;
}
DMINFO("version %u.%u.%u loaded",
multipath_target.version[0], multipath_target.version[1],
multipath_target.version[2]);
+ return 0;
+
+out_kmpath_handlerd:
+ destroy_workqueue(kmultipathd);
+out_kmultipathd:
+ dm_unregister_target(&multipath_target);
+out_mpio_cache:
+ kmem_cache_destroy(_mpio_cache);
+
return r;
}
--
2.1.0
^ permalink raw reply related
* superfluous md_wakeup_thread()
From: Jes Sorensen @ 2015-01-08 22:53 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
Neil,
I was looking over some md patches, and in
commit 67f455486d2ea20b2d94d6adf5b9b783d079e321
Author: NeilBrown <neilb@suse.de>
Date: Wed May 28 13:39:22 2014 +1000
md/raid56: Don't perform reads to support writes until stripe is ready.
You add the following:
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index ad1b9be..c1e8607 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -292,9 +292,12 @@ static void do_release_stripe(struct r5conf *conf, struct stripe_head *sh,
BUG_ON(atomic_read(&conf->active_stripes)==0);
if (test_bit(STRIPE_HANDLE, &sh->state)) {
if (test_bit(STRIPE_DELAYED, &sh->state) &&
- !test_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
+ !test_bit(STRIPE_PREREAD_ACTIVE, &sh->state)) {
list_add_tail(&sh->lru, &conf->delayed_list);
- else if (test_bit(STRIPE_BIT_DELAY, &sh->state) &&
+ if (atomic_read(&conf->preread_active_stripes)
+ < IO_THRESHOLD)
+ md_wakeup_thread(conf->mddev->thread);
+ } else if (test_bit(STRIPE_BIT_DELAY, &sh->state) &&
sh->bm_seq - conf->seq_write > 0)
list_add_tail(&sh->lru, &conf->bitmap_list);
else {
However the additional md_wakeup_thread() seems unecessary as the
resulting code now reads (pasted from current upstream):
static void do_release_stripe(struct r5conf *conf, struct stripe_head *sh,
struct list_head *temp_inactive_list)
{
BUG_ON(!list_empty(&sh->lru));
BUG_ON(atomic_read(&conf->active_stripes)==0);
if (test_bit(STRIPE_HANDLE, &sh->state)) {
if (test_bit(STRIPE_DELAYED, &sh->state) &&
!test_bit(STRIPE_PREREAD_ACTIVE, &sh->state)) {
list_add_tail(&sh->lru, &conf->delayed_list);
if (atomic_read(&conf->preread_active_stripes)
< IO_THRESHOLD)
md_wakeup_thread(conf->mddev->thread);
} else if (test_bit(STRIPE_BIT_DELAY, &sh->state) &&
sh->bm_seq - conf->seq_write > 0)
list_add_tail(&sh->lru, &conf->bitmap_list);
else {
clear_bit(STRIPE_DELAYED, &sh->state);
clear_bit(STRIPE_BIT_DELAY, &sh->state);
if (conf->worker_cnt_per_group == 0) {
list_add_tail(&sh->lru, &conf->handle_list);
} else {
raid5_wakeup_stripe_thread(sh);
return;
}
}
md_wakeup_thread(conf->mddev->thread);
Is there a reason to wake the thread twice?
Cheers,
Jes
^ permalink raw reply related
* raid5 hard lockup
From: Terry Hardie @ 2015-01-08 20:02 UTC (permalink / raw)
To: linux-raid
I'm still trying to get discard on ext4 and RAID5 to work reliably. I
got a new hard lockup today:
[506487.336582] ------------[ cut here ]------------
[506487.336591] WARNING: CPU: 4 PID: 22829 at
/usr/local/src/linux-lts-trusty-3.13.0/kernel/watchdog.c:245
watchdog_overflow_callback+0x9a/0xc0()
[506487.336592] Watchdog detected hard LOCKUP on cpu 4
[506487.336593] Modules linked in: ast gpio_ich ttm drm_kms_helper drm
sysimgblt sysfillrect syscopyarea mei_me lpc_ich shpchp mei joydev
ioatdma wmi ipmi_si acpi_power_meter acpi_pad mac_hid lp parport
raid10 raid456 async_pq async_xor xor async_memcpy async_raid6_recov
hid_generic usbhid hid igb mpt3sas(OX) dca configfs i2c_algo_bit
scsi_transport_sas ptp ahci libahci pps_core raid_class raid6_pq
async_tx raid1 raid0 multipath linear
[506487.336624] CPU: 4 PID: 22829 Comm: md3_raid5 Tainted: G
IOX 3.13.0-43-generic #72~precise1
[506487.336626] Hardware name: Supermicro SYS-2028TP-HC1R/X10DRT-P,
BIOS 1.0a 08/28/2014
[506487.336627] 00000000000000f5 ffff88103fc86ba8 ffffffff81757f91
0000000000000007
[506487.336631] ffff88103fc86bf8 ffff88103fc86be8 ffffffff8106afcc
0000000000000000
[506487.336634] ffff881028ca8000 0000000000000000 ffff88103fc86d18
0000000000000000
[506487.336637] Call Trace:
[506487.336638] <NMI> [<ffffffff81757f91>] dump_stack+0x46/0x58
[506487.336649] [<ffffffff8106afcc>] warn_slowpath_common+0x8c/0xc0
[506487.336652] [<ffffffff8106b0b6>] warn_slowpath_fmt+0x46/0x50
[506487.336654] [<ffffffff811142aa>] watchdog_overflow_callback+0x9a/0xc0
[506487.336659] [<ffffffff8114ed08>] __perf_event_overflow+0x98/0x230
[506487.336664] [<ffffffff8102b188>] ? x86_perf_event_set_period+0xd8/0x150
[506487.336667] [<ffffffff8114f604>] perf_event_overflow+0x14/0x20
[506487.336671] [<ffffffff81032bc9>] intel_pmu_handle_irq+0x1d9/0x2d0
[506487.336675] [<ffffffff81193711>] ? unmap_kernel_range_noflush+0x11/0x20
[506487.336681] [<ffffffff8143df34>] ? ghes_copy_tofrom_phys+0x114/0x210
[506487.336685] [<ffffffff81766674>] perf_event_nmi_handler+0x34/0x60
[506487.336688] [<ffffffff81765dca>] nmi_handle.isra.3+0x8a/0x1a0
[506487.336690] [<ffffffff8143eff0>] ?
ghes_print_estatus.constprop.10+0x70/0x70
[506487.336692] [<ffffffff81765fc8>] default_do_nmi+0x58/0x240
[506487.336695] [<ffffffff81766240>] do_nmi+0x90/0xd0
[506487.336697] [<ffffffff817651e1>] end_repeat_nmi+0x1e/0x2e
[506487.336700] [<ffffffff817644c9>] ? _raw_spin_lock_irqsave+0x49/0x60
[506487.336702] [<ffffffff817644c9>] ? _raw_spin_lock_irqsave+0x49/0x60
[506487.336704] [<ffffffff817644c9>] ? _raw_spin_lock_irqsave+0x49/0x60
[506487.336705] <<EOE>> [<ffffffffa0142890>]
release_inactive_stripe_list+0x50/0x160 [raid456]
[506487.336714] [<ffffffffa014b12f>]
handle_active_stripes.isra.38+0x7f/0x190 [raid456]
[506487.336718] [<ffffffffa014b758>] raid5d+0x198/0x2f0 [raid456]
[506487.336722] [<ffffffff815d30a7>] md_thread+0x117/0x150
[506487.336727] [<ffffffff810affe0>] ? __wake_up_sync+0x20/0x20
[506487.336729] [<ffffffff815d2f90>] ? md_rdev_init+0x110/0x110
[506487.336732] [<ffffffff8108fb59>] kthread+0xc9/0xe0
[506487.336735] [<ffffffff8108fa90>] ? flush_kthread_worker+0xb0/0xb0
[506487.336737] [<ffffffff8176d5bc>] ret_from_fork+0x7c/0xb0
[506487.336740] [<ffffffff8108fa90>] ? flush_kthread_worker+0xb0/0xb0
[506487.336741] ---[ end trace 4423aa98b23bcd0f ]---
^ permalink raw reply
* Neil Brown is on leave
From: NeilBrown @ 2015-01-07 20:27 UTC (permalink / raw)
To: linux-raid
Cc: Artur Paszkiewicz, Manibalan P, 董杨, Anthony Wright,
Matt Callaghan
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
Hi,
various people have asked my things of late and may be a bit bothered by my
continuing silence.
I'm on leave at the moment and won't be thinking about RAID if I can help it
until I return to work in late January. If you haven't heard from me by the
second week of Feb, please ask again, but I will try to catch up by then.
I'll be at linux.conf.au and would be happy to chat about RAID in person
there, but otherwise I'm leaving it all until after Australia Day.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox