* Re: deprecating /proc/mdstat (was: Re: mdadm bad blocks list)
From: Shaohua Li @ 2016-01-28 18:21 UTC (permalink / raw)
To: Jens-U. Mozdzen; +Cc: NeilBrown, linux-raid
In-Reply-To: <20160128124121.Horde.YKtbZL0CUYKTuEkxLcmmhQ4@www3.nde.ag>
On Thu, Jan 28, 2016 at 12:41:21PM +0100, Jens-U. Mozdzen wrote:
> Hello Neil & *,
>
> Zitat von NeilBrown <nfbrown@novell.com>:
> >[...]
> >I'd like to deprecate /proc/mdstat. It is not really easy to extend.
>
> while I understand that /proc/mdstat's format might be considered "frozen"
> as in "do not confuse old scripts by new formats", I'd hate to see
> /proc/mdstat go away without a similar replacement: calling "mdadm" (or any
> other CLI) to gather that information is unruly expensive when all you have
> to do is "watch cat /proc/mdstat" to manually monitor critical operations.
That will not happen soon. Deprecating an interface takes years.
> >I'd recommend using "mdadm" to get status of an array, or examine file
> >in /sys.
>
> If there's to be a "new mdstat" in /sys, I'd be fine with that. That would
> help migration for those "old scripts grep'ing /proc/mdstat" you rightfully
> care about.
>
> I suggest to include a file format version information on line 1
> "/sys/.../mdstat", that way any client parsing such an interface could
> verify the file format first, and bail out if it doesn't support the
> currently presented format.
All the info you can get from /proc/mdstat can be found in /sys/xxx. There
isn't a central mdstat file in sysfs entry, each sysfs entry only export single
type info. Version info is uncessary, if we need add new info, we'd just add a
new sysfs entry.
though the /proc/mdstat will not be deprecated soon, it's highly encouraged app
switches to /sys. sysfs entry is easy to parse. And as Neil said, /proc/mdstat
is hard to extend, so new info will likely only appear in sysfs.
Thanks,
Shaohua
^ permalink raw reply
* Re: Problem with array raid10 array resync on 4.4.0 (keeps reyncing each reboot)
From: Shaohua Li @ 2016-01-28 18:25 UTC (permalink / raw)
To: Eric Valette; +Cc: linux-raid
In-Reply-To: <56A870AD.4070400@free.fr>
On Wed, Jan 27, 2016 at 08:24:29AM +0100, Eric Valette wrote:
> On 27/01/2016 00:31, Shaohua Li wrote:
> >On Tue, Jan 26, 2016 at 03:49:42PM +0100, Eric Valette wrote:
> >>Hi,
> >>
> >>My raid 10 array (5 disk with one spare) was doing a resync after an
> >>upgrade to 4.4.0 from 4.1.15. The resync progress was steady and at the end
> >>the /proc/mdstat was apparently complete but when rebooting, it started
> >>resycing over and over. I noticed my dmesg was totally filled with raid10
> >>conf printout message so it was impossible to trace anything else.
> >>
> >>Did a resync test with 3.14.58 (because I knew it had worked for resync
> >>before and was still available as a boot option) and the array was
> >>correctly rebuild.
> >>Runs fine with 4.1.16 now.
> >>
> >>Please CC me as I'm not subscribed.
> >
> >Could you please provide more info, like mdadm -D /dev/md0 in v4.4? If you run
> >a stop/reassemble, does the resync start?
>
> I'm not going to retry kernel 4.4.0 on this device as I'm no more confident
> about raid10 support with this 4.4 version.
Thanks! I know switching to a kernel which is not working well is risky, but
the info from 4.1 doesn't have enough info for debuging. I also tried to
reproduce the issue locally, but no success. Did you have any other info which
could help debugging, for example special config?
Thanks,
Shaohua
^ permalink raw reply
* Re: Problem with array raid10 array resync on 4.4.0 (keeps reyncing each reboot)
From: Eric Valette @ 2016-01-28 19:52 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-raid
In-Reply-To: <20160128182522.GB23378@kernel.org>
On 28/01/2016 19:25, Shaohua Li wrote:
> On Wed, Jan 27, 2016 at 08:24:29AM +0100, Eric Valette wrote:
>> On 27/01/2016 00:31, Shaohua Li wrote:
>>> On Tue, Jan 26, 2016 at 03:49:42PM +0100, Eric Valette wrote:
>>>> Hi,
>>>>
>>>> My raid 10 array (5 disk with one spare) was doing a resync after an
>>>> upgrade to 4.4.0 from 4.1.15. The resync progress was steady and at the end
>>>> the /proc/mdstat was apparently complete but when rebooting, it started
>>>> resycing over and over. I noticed my dmesg was totally filled with raid10
>>>> conf printout message so it was impossible to trace anything else.
>>>>
>>>> Did a resync test with 3.14.58 (because I knew it had worked for resync
>>>> before and was still available as a boot option) and the array was
>>>> correctly rebuild.
>>>> Runs fine with 4.1.16 now.
>>>>
>>>> Please CC me as I'm not subscribed.
>>>
>>> Could you please provide more info, like mdadm -D /dev/md0 in v4.4? If you run
>>> a stop/reassemble, does the resync start?
>>
>> I'm not going to retry kernel 4.4.0 on this device as I'm no more confident
>> about raid10 support with this 4.4 version.
>
> Thanks! I know switching to a kernel which is not working well is risky, but
> the info from 4.1 doesn't have enough info for debuging. I also tried to
> reproduce the issue locally, but no success. Did you have any other info which
> could help debugging, for example special config?
If really needed can rebuild a 4.4 kernel and boot it. What do you mean
by special config? I can send you my kernel .config once rebuild
(oldconfig from 4.1.16)
But I doubt the problem will show up now that the array is correctly
rebuild. From memory I used 4.4 kernel without problem for a few days,
until it decided to resync the array for an unknown reason (standard
periodic rebuild, disk block read/write error detected, other?).
NB: I have a disk on the array with 56 sectors in error reported by
smart and noticed read error/SATA reset sequence during first array
rebuild sequence, but not in any later resync afterward. It did not even
decided to use the spare disk...
Let me know how I can help debugging further...
-- eric
^ permalink raw reply
* Re: [PATCH/RFC/RFT] md: allow resync to go faster when there is competing IO.
From: Shaohua Li @ 2016-01-28 20:56 UTC (permalink / raw)
To: NeilBrown; +Cc: Chien Lee, linux-raid, owner-linux-raid
In-Reply-To: <87wpqu1jrl.fsf@notabene.neil.brown.name>
On Thu, Jan 28, 2016 at 02:10:38PM +1100, Neil Brown wrote:
> On Wed, Jan 27 2016, Chien Lee wrote:
>
> > 2016-01-27 6:12 GMT+08:00 NeilBrown <neilb@suse.com>:
> >> On Tue, Jan 26 2016, Chien Lee wrote:
> >>
> >>> Hello,
> >>>
> >>> Recently we find a bug about this patch (commit No. is
> >>> ac8fa4196d205ac8fff3f8932bddbad4f16e4110 ).
> >>>
> >>> We know that this patch committed after Linux kernel 4.1.x is intended
> >>> to allowing resync to go faster when there is competing IO. However,
> >>> we find the performance of random read on syncing Raid6 will come up
> >>> with a huge drop in this case. The following is our testing detail.
> >>>
> >>> The OS what we choose in our test is CentOS Linux release 7.1.1503
> >>> (Core) and the kernel image will be replaced for testing. In our
> >>> testing result, the 4K random read performance on syncing raid6 in
> >>> Kernel 4.2.8 is much lower than in Kernel 3.19.8. In order to find out
> >>> the root cause, we try to rollback this patch in Kernel 4.2.8, and we
> >>> find the 4K random read performance on syncing Raid6 will be improved
> >>> and go back to as what it should be in Kernel 3.19.8.
> >>>
> >>> Nevertheless, it seems that it will not affect some other read/write
> >>> patterns. In our testing result, the 1M sequential read/write, 4K
> >>> random write performance in Kernel 4.2.8 is performed almost the same
> >>> as in Kernel 3.19.8.
> >>>
> >>> It seems that although this patch increases the resync speed, the
> >>> logic of !is_mddev_idle() cause the sync request wait too short and
> >>> reduce the chance for raid5d to handle the random read I/O.
> >>
> >> This has been raised before.
> >> Can you please try the patch at the end of
> >>
> >> http://permalink.gmane.org/gmane.linux.raid/51002
> >>
> >> and let me know if it makes any difference. If it isn't sufficient I
> >> will explore further.
> >>
> >> Thanks,
> >> NeilBrown
> >
> >
> > Hello Neil,
> >
> > I try the patch (http://permalink.gmane.org/gmane.linux.raid/51002) in
> > Kernel 4.2.8. Here are the test results:
> >
> >
> > Part I. SSD (4 x 240GB Intel SSD create Raid6(syncing))
> >
> > a. 4K Random Read, numjobs=64
> >
> > Average Throughput Average IOPS
> >
> > Kernel 4.2.8 Patch 601249KB/s 150312
> >
> >
> > b. 4K Random Read, numjobs=1
> >
> > Average Throughput Average IOPS
> >
> > Kernel 4.2.8 Patch 1166.4KB/s 291
> >
> >
> >
> > Part II. HDD (4 x 1TB TOSHIBA HDD create Raid6(syncing))
> >
> > a. 4K Random Read, numjobs=64
> >
> > Average Throughput Average IOPS
> >
> > Kernel 4.2.8 Patch 2946.4KB/s 736
> >
> >
> > b. 4K Random Read, numjobs=1
> >
> > Average Throughput Average IOPS
> >
> > Kernel 4.2.8 Patch 119199 B/s 28
> >
> >
> > Although the performance that compare to the original Kernel 4.2.8
> > test results is increased, the patch
> > (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac8fa4196d205ac8fff3f8932bddbad4f16e4110)
> > rollback still has the best performance. I also observe the sync speed
> > at numjobs=64 almost drop to the sync_speed_min, but sync speed at
> > numjobs=1 almost keep in the original speed.
> >
> >>From my test results, I think this patch isn't sufficient that maybe
> > Neil can explore further and give me some advice.
> >
> >
> > Thanks,
> > Chien Lee
> >
> >
> >>>
> >>>
> >>> Following is our test environment and some testing results:
> >>>
> >>>
> >>> OS: CentOS Linux release 7.1.1503 (Core)
> >>>
> >>> CPU: Intel(R) Xeon(R) CPU E3-1245 v3 @ 3.40GHz
> >>>
> >>> Processor number: 8
> >>>
> >>> Memory: 12GB
> >>>
> >>> fio command:
> >>>
> >>> 1. (for numjobs=64):
> >>>
> >>> fio --filename=/dev/md2 --sync=0 --direct=0 --rw=randread --bs=4K
> >>> --runtime=180 --size=50G --name=test-read --ioengine=libaio
> >>> --numjobs=64 --iodepth=1 --group_reporting
> >>>
> >>> 2. (for numjobs=1):
> >>>
> >>> fio --filename=/dev/md2 --sync=0 --direct=0 --rw=randread --bs=4K
> >>> --runtime=180 --size=50G --name=test-read --ioengine=libaio
> >>> --numjobs=1 --iodepth=1 --group_reporting
> >>>
> >>>
> >>>
> >>> Here are test results:
> >>>
> >>>
> >>> Part I. SSD (4 x 240GB Intel SSD create Raid6(syncing))
> >>>
> >>>
> >>> a. 4K Random Read, numjobs=64
> >>>
> >>> Average Throughput Average IOPS
> >>>
> >>> Kernel 3.19.8 715937KB/s 178984
> >>>
> >>> Kernel 4.2.8 489874KB/s 122462
> >>>
> >>> Kernel 4.2.8 Patch Rollback 717377KB/s 179344
> >>>
> >>>
> >>>
> >>> b. 4K Random Read, numjobs=1
> >>>
> >>> Average Throughput Average IOPS
> >>>
> >>> Kernel 3.19.8 32203KB/s 8051
> >>>
> >>> Kernel 4.2.8 2535.7KB/s 633
> >>>
> >>> Kernel 4.2.8 Patch Rollback 31861KB/s 7965
> >>>
> >>>
> >>>
> >>>
> >>> Part II. HDD (4 x 1TB TOSHIBA HDD create Raid6(syncing))
> >>>
> >>>
> >>> a. 4K Random Read, numjobs=64
> >>>
> >>> Average Throughput Average IOPS
> >>>
> >>> Kernel 3.19.8 2976.6KB/s 744
> >>>
> >>> Kernel 4.2.8 2915.8KB/s 728
> >>>
> >>> Kernel 4.2.8 Patch Rollback 2973.3KB/s 743
> >>>
> >>>
> >>>
> >>> b. 4K Random Read, numjobs=1
> >>>
> >>> Average Throughput Average IOPS
> >>>
> >>> Kernel 3.19.8 481844 B/s 117
> >>>
> >>> Kernel 4.2.8 24718 B/s 5
> >>>
> >>> Kernel 4.2.8 Patch Rollback 460090 B/s 112
> >>>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> --
> >>>
> >>> Chien Lee
>
> Thanks for testing.
>
> I'd like to suggest that these results are fairly reasonable for the
> numjobs=64 case. Certainly read-speed is reduced by presumably resync
> speed is increased.
> The numbers for numjob=1 are appalling though. That would generally
> affect any synchronous load. As the synchronous load doesn't interfere
> much with the resync load, the delays that are inserted won't be very
> long.
>
> I feel there must be an answer here - I just cannot find it.
> I'd like to be able to dynamically estimate the bandwidth of the array
> and use (say) 10% of that, but I cannot think of a way to do that at all
> reliably.
Had a hack, something like this?
diff --git a/drivers/md/md.c b/drivers/md/md.c
index e55e6cf..7fee8e6 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8060,12 +8060,34 @@ void md_do_sync(struct md_thread *thread)
goto repeat;
}
if (!is_mddev_idle(mddev, 0)) {
+ unsigned long start = jiffies;
+ int recov = atomic_read(&mddev->recovery_active);
+ int last_sect, new_sect;
+ int sleep_time = 0;
+
+ last_sect = (int)part_stat_read(&mddev->gendisk->part0, sectors[0]) +
+ (int)part_stat_read(&mddev->gendisk->part0, sectors[1]);
+
/*
* Give other IO more of a chance.
* The faster the devices, the less we wait.
*/
wait_event(mddev->recovery_wait,
!atomic_read(&mddev->recovery_active));
+
+ new_sect = (int)part_stat_read(&mddev->gendisk->part0, sectors[0]) +
+ (int)part_stat_read(&mddev->gendisk->part0, sectors[1]);
+
+ if (recov * 10 > new_sect - last_sect)
+ sleep_time = 9 * (jiffies - start) /
+ ((new_sect - last_sect) /
+ (recov + 1) + 1);
+
+ sleep_time = jiffies_to_msecs(sleep_time);
+ if (sleep_time > 500)
+ sleep_time = 500;
+
+ msleep(sleep_time);
}
}
}
^ permalink raw reply related
* [PATCH/mdadm] super1: Fix bblog_size accesses on big-ending machines.
From: NeilBrown @ 2016-01-29 1:35 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-raid
[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]
bblog_size is 16bit so using le32_to_cpu on it is not wise
and leads to errors on big-endian machines.
Change all such calls to use le16.
Bug was introduced in mdadm-3.3
Signed-off-by: NeilBrown <neilb@suse.com>
---
Hi Jes,
when you are ready to start queuing patches for mdadm, this will make
sure you have something to work with:-)
Thanks,
NeilBrown
super1.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/super1.c b/super1.c
index 8bcaa2fe02c8..9b877e504c4b 100644
--- a/super1.c
+++ b/super1.c
@@ -730,12 +730,12 @@ static int copy_metadata1(struct supertype *st, int from, int to)
}
if (super.bblog_size != 0 &&
- __le32_to_cpu(super.bblog_size) <= 100 &&
+ __le16_to_cpu(super.bblog_size) <= 100 &&
super.bblog_offset != 0 &&
(super.feature_map & __le32_to_cpu(MD_FEATURE_BAD_BLOCKS))) {
/* There is a bad block log */
unsigned long long bb_offset = sb_offset;
- int bytes = __le32_to_cpu(super.bblog_size) * 512;
+ int bytes = __le16_to_cpu(super.bblog_size) * 512;
int written = 0;
struct align_fd afrom, ato;
@@ -832,7 +832,7 @@ static int examine_badblocks_super1(struct supertype *st, int fd, char *devname)
__u64 *bbl, *bbp;
int i;
- if (!sb->bblog_size || __le32_to_cpu(sb->bblog_size) > 100
+ if (!sb->bblog_size || __le16_to_cpu(sb->bblog_size) > 100
|| !sb->bblog_offset){
printf("No bad-blocks list configured on %s\n", devname);
return 0;
@@ -843,7 +843,7 @@ static int examine_badblocks_super1(struct supertype *st, int fd, char *devname)
return 0;
}
- size = __le32_to_cpu(sb->bblog_size)* 512;
+ size = __le16_to_cpu(sb->bblog_size)* 512;
if (posix_memalign((void**)&bbl, 4096, size) != 0) {
pr_err("could not allocate badblocks list\n");
return 0;
@@ -986,7 +986,7 @@ static void getinfo_super1(struct supertype *st, struct mdinfo *info, char *map)
if (sb->bblog_offset && sb->bblog_size) {
unsigned long long bbend = super_offset;
bbend += (int32_t)__le32_to_cpu(sb->bblog_offset);
- bbend += __le32_to_cpu(sb->bblog_size);
+ bbend += __le16_to_cpu(sb->bblog_size);
if (bbend > earliest)
earliest = bbend;
}
--
2.7.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply related
* Re: [dm-devel] reinstate dm target local ioctl support
From: Joe Thornber @ 2016-01-29 13:55 UTC (permalink / raw)
To: device-mapper development
Cc: Alasdair Kergon, Mike Snitzer, Christoph Hellwig, linux-kernel,
Neil Brown, linux-raid, mohan_srinivasan, Andy Whitcroft,
Tim Gardner
In-Reply-To: <1453989019-24300-1-git-send-email-apw@canonical.com>
On Thu, Jan 28, 2016 at 01:50:19PM +0000, Andy Whitcroft wrote:
> How would we feel about carrying something like the patch below in
> mainline to allow for such target local ioctls.
You can send a dm message to individual targets. No need for target
specific ioctls.
- Joe
^ permalink raw reply
* Re: reinstate dm target local ioctl support
From: Alasdair G Kergon @ 2016-01-29 13:57 UTC (permalink / raw)
To: Andy Whitcroft
Cc: Alasdair Kergon, Mike Snitzer, Christoph Hellwig,
mohan_srinivasan, dm-devel, Neil Brown, linux-raid, linux-kernel,
Tim Gardner
In-Reply-To: <1453989019-24300-1-git-send-email-apw@canonical.com>
On Thu, Jan 28, 2016 at 01:50:19PM +0000, Andy Whitcroft wrote:
> However this also removed the possibility of a dm target having target
> specific ioctls. Currently this is not used by any in-tree targets but
> was utilised by the flashcache out-of-tree module.
What data is being passed in and out?
The method we support is passing it through DM_TARGET_MSG (as text).
For examples look at dm-switch.c and dm-stats.c, which handled
pretty large quantities of data.
Would that work?
Alasdair
^ permalink raw reply
* Re: reinstate dm target local ioctl support
From: Andy Whitcroft @ 2016-01-29 14:35 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, Christoph Hellwig,
mohan_srinivasan, dm-devel, Neil Brown, linux-raid, linux-kernel,
Tim Gardner
In-Reply-To: <20160129135712.GA7201@agk-dp.fab.redhat.com>
On Fri, Jan 29, 2016 at 01:57:12PM +0000, Alasdair G Kergon wrote:
> On Thu, Jan 28, 2016 at 01:50:19PM +0000, Andy Whitcroft wrote:
> > However this also removed the possibility of a dm target having target
> > specific ioctls. Currently this is not used by any in-tree targets but
> > was utilised by the flashcache out-of-tree module.
>
> What data is being passed in and out?
>
> The method we support is passing it through DM_TARGET_MSG (as text).
> For examples look at dm-switch.c and dm-stats.c, which handled
> pretty large quantities of data.
>
> Would that work?
That sounds like it has all the bits one would need indeed. I will
investigate that. Thanks for the info.
-apw
^ permalink raw reply
* [LSF/MM ATTEND][LSF/MM TOPIC] SMR/Zoned devices IO
From: Adrian Palmer @ 2016-01-29 21:41 UTC (permalink / raw)
To: lsf-pc
Cc: linux-ide, linux-scsi, linux-block,
Linux Filesystem Development List, linux-raid
Greetings:
I would like to attend LSF/MM to continue discussion related to SMR.
Besides the SMRFFS, we've been developing a zoned device mapper (ZDM).
I would like to gather feedback and direction. I can provide a quick
explanation of the architecture. This will enable existing software
to work on zoned devices. Our work will initially focus on workloads
provided by mdraid.
Also, I would like to discuss the storage of the zone information in
the kernel. It makes little sense for the drive to be continuously
probed, or for each app to maintain it own, possibly un-synced, copy
of the zone information. I'll bring along our work and
recommendations of a solution based on Hannes' work in this area. I
believe we need a common stackable interface to pass along this
information, both up the kernel, and to userland.
Lastly, we are still exploring the need for an additional elevator
besides the no-op that orders not only by time, but also zone aware
location. I'll have some test results by lsf/mm that we can discuss.
Adrian Palmer
Firmware Engineer II
R&D Firmware
Seagate, Longmont Colorado
720-684-1307
adrian.palmer@seagate.com
^ permalink raw reply
* Reshape stuck immediately, backup file all nulls
From: Björn Augustsson @ 2016-01-30 12:21 UTC (permalink / raw)
To: linux-raid
Folks,
I wanted to add another disk to a RAID6 array I have. So I ran
$ mdadm --add /dev/md127 /dev/sdj1
$ mdadm --grow --raid-devices=8 --backup-file=/boot/grow_md127.bak /dev/md127
This appeared to work right, but looking at /proc/mdstat, it says
$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid6 sdd1[8] sdj[6] sdg[0] sdk[4] sdh[1] sdi[2] sdc[5] sda1[7]
14650675200 blocks super 1.2 level 6, 512k chunk, algorithm 2
[8/8] [UUUUUUUU]
[>....................] reshape = 0.0% (1/2930135040)
finish=445893299483.7min speed=0K/sec
unused devices: <none>
That is, it's stuck. And it's been that way since (about 36h now)
Looking at some logs, I found this in messages:
Jan 28 20:24:27 ooo systemd: Created slice
system-mdadm\x2dgrow\x2dcontinue.slice.
Jan 28 20:24:27 ooo audit: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=mdadm-grow-continue@md127 comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
Jan 28 20:24:27 ooo systemd: Starting system-mdadm\x2dgrow\x2dcontinue.slice.
Jan 28 20:24:28 ooo audit: AVC avc: denied { write } for pid=11103
comm="mdadm" name="grow_md127.bak" dev="sdf1" ino=426
scontext=system_u:system_r:mdadm_t:s0
tcontext=unconfined_u:object_r:boot_t:s0 tclass=file permissive=0
Jan 28 20:24:28 ooo audit: SYSCALL arch=c000003e syscall=2 success=no
exit=-13 a0=ec1fc0 a1=242 a2=180 a3=7800 items=0 ppid=1 pid=11103
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294
967295 comm="mdadm" exe="/usr/sbin/mdadm"
subj=system_u:system_r:mdadm_t:s0 key=(null)
Jan 28 20:24:28 ooo systemd: mdadm-grow-continue@md127.service: Main
process exited, code=exited, status=1/FAILURE
Jan 28 20:24:28 ooo systemd: mdadm-grow-continue@md127.service: Unit
entered failed state.
Jan 28 20:24:28 ooo audit: SERVICE_STOP pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=mdadm-grow-continue@md127 comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=failed'
Jan 28 20:24:28 ooo systemd: mdadm-grow-continue@md127.service: Failed
with result 'exit-code'.
Jan 28 20:24:32 ooo setroubleshoot: SELinux is preventing
/usr/sbin/mdadm from write access on the file grow_md127.bak. For
complete SELinux messages. run sealert -l
43815f80-8b00-40d9-86a3-4a6a432f3e05
Jan 28 20:24:32 ooo python3: SELinux is preventing /usr/sbin/mdadm
from write access on the file grow_md127.bak.#012#012***** Plugin
kernel_modules (91.4 confidence) suggests
********************#012#012If you do not think m
dadm should try write access on grow_md127.bak.#012Then you may be
under attack by a hacker, since confined applications should not need
this access.#012Do#012contact your security administrator and report
this issue.#012#012**
*** Plugin catchall (9.59 confidence) suggests
**************************#012#012If you believe that mdadm should be
allowed write access on the grow_md127.bak file by default.#012Then
you should report this as a bug.#012You
can generate a local policy module to allow this
access.#012Do#012allow this access for now by executing:#012# grep
mdadm /var/log/audit/audit.log | audit2allow -M mypol#012# semodule -i
mypol.pp#012
So it seems selinux is preventing writes to the backup file I specified.
(I put it in /boot, since that's the only file system I have that's
not on the array.)
Interestingly, the file exists
$ ls -l /boot/grow_md127.bak
-rw-------. 1 root root 15732736 Jan 28 20:24 /boot/grow_md127.bak
$
but it's all nulls (as in the case at
http://www.spinics.net/lists/raid/msg40771.html )
The question is, what kind of state am in now? And how should I recover?
Will just adding a policy to allow access to that file, and then
mdadm --grow --continue /dev/md127
fix it? Is the broken backup file going to be a problem?
The system is an uptodate Fedora 23, x86_64, with kernel
4.3.3-303.fc23.x86_64 and mdadm-3.3.4-2.fc23.x86_64.
Thanks,
/August.
--
Wrong on most accounts. const Foo *foo; and Foo const *foo; mean the same: foo
being a pointer to const Foo. const Foo const *foo; would mean the same but is
illegal (double const). You are confusing this with Foo * const foo; and const
Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system
^ permalink raw reply
* Re: Reshape stuck immediately, backup file all nulls
From: Phil Turmel @ 2016-01-30 17:09 UTC (permalink / raw)
To: Björn Augustsson, linux-raid
In-Reply-To: <CABRqA0i7bAB3Xca1a29u2JYOF2UaE_w1sY73se3menp+ExWWKA@mail.gmail.com>
Hi Björn,
On 01/30/2016 07:21 AM, Björn Augustsson wrote:
> The question is, what kind of state am in now?
The kernel is waiting for mdmon (mdadm as a background task) to step
through the stripes. mdmon died and the kernel will wait forever.
> And how should I recover?
> Will just adding a policy to allow access to that file, and then
> mdadm --grow --continue /dev/md127
> fix it?
Probably. Others have fixed this by disabling selinux for the reshape.
Don't forget to specify --backup-file again on the command line. (I
don't use selinux myself, so I can't be more specific.)
In the future, consider not using a backup file at all -- mdadm
generally leaves enough dead space on devices to avoid the need.
> Is the broken backup file going to be a problem?
Shouldn't be. Report back if it is.
Phil
--
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: Reshape stuck immediately, backup file all nulls
From: Mikael Abrahamsson @ 2016-01-30 18:13 UTC (permalink / raw)
To: Björn Augustsson; +Cc: linux-raid
In-Reply-To: <CABRqA0i7bAB3Xca1a29u2JYOF2UaE_w1sY73se3menp+ExWWKA@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 280 bytes --]
On Sat, 30 Jan 2016, Björn Augustsson wrote:
> That is, it's stuck. And it's been that way since (about 36h now)
Look in the list archives. Some people have had luck with issuing
--continue to the array to get it going again.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: mdadm bad blocks list
From: Sarah Newman @ 2016-01-30 18:22 UTC (permalink / raw)
To: NeilBrown, linux-raid
In-Reply-To: <56A99118.2080508@prgmr.com>
On 01/27/2016 07:55 PM, Sarah Newman wrote:
> On 01/27/2016 07:19 PM, NeilBrown wrote:
>> On Thu, Jan 28 2016, Sarah Newman wrote:
>>
>>> I experienced the following problems with the mdadm bad blocks list:
>>>
>>> 1. Additions to the bad block list do not cause an email to be sent by the mdadm monitor. Expected behavior is for an email to be sent as soon as the
>>> bad blocks list becomes non-empty.
>>
>> Yes, that would be a good idea. If you do develop patches, please post
>> them.
>
> Will do, but I don't have a definite time frame for it.
Since patches will not immediately propagate, I wrote an ansible role https://github.com/prgmrcom/ansible-role-mdadm-bad-blocks which contains the
script https://github.com/prgmrcom/ansible-role-mdadm-bad-blocks/blob/master/files/usr/local/bin/raid-bad-blocks . Feedback welcome.
^ permalink raw reply
* Re: Reshape stuck immediately, backup file all nulls
From: Björn Augustsson @ 2016-01-31 14:59 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <56ACEE63.6070108@turmel.org>
On Sat, Jan 30, 2016 at 6:09 PM, Phil Turmel <philip@turmel.org> wrote:
> Hi Björn,
>
> On 01/30/2016 07:21 AM, Björn Augustsson wrote:
>
>> The question is, what kind of state am in now?
>
> The kernel is waiting for mdmon (mdadm as a background task) to step
> through the stripes. mdmon died and the kernel will wait forever.
OK. So I think the root cause here is that my invocation of mdadm was
unconfined,
because I was running it interactively. So it could create the backup file.
But the background version starts via systemd, and runs as mdadm_t, which
can't read that file (because it's in /boot). And poof.
I'll file a bug vs the fedora selinux policy for this, too.
>> And how should I recover?
>> Will just adding a policy to allow access to that file, and then
>> mdadm --grow --continue /dev/md127
>> fix it?
>
> Probably. Others have fixed this by disabling selinux for the reshape.
> Don't forget to specify --backup-file again on the command line. (I
> don't use selinux myself, so I can't be more specific.)
Yeah, this seems to be working.
mdadm --grow --continue --backup-file=/boot/grow_md127.bak /dev/md127
is running, and the counters in /proc/mdstat started moving. It's going to be
a day or two for this to complete, but right now things are looking good.
Thanks for the help!
/August.
> In the future, consider not using a backup file at all -- mdadm
> generally leaves enough dead space on devices to avoid the need.
>
>> Is the broken backup file going to be a problem?
>
> Shouldn't be. Report back if it is.
>
> Phil
--
Wrong on most accounts. const Foo *foo; and Foo const *foo; mean the same: foo
being a pointer to const Foo. const Foo const *foo; would mean the same but is
illegal (double const). You are confusing this with Foo * const foo; and const
Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system
--
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: Problem with array raid10 array resync on 4.4.0 (keeps reyncing each reboot)
From: Eric Valette @ 2016-01-31 23:00 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-raid
In-Reply-To: <56AA7176.1020508@free.fr>
On 28/01/2016 20:52, Eric Valette wrote:
> On 28/01/2016 19:25, Shaohua Li wrote:
>
> If really needed can rebuild a 4.4 kernel and boot it. What do you mean
> by special config? I can send you my kernel .config once rebuild
> (oldconfig from 4.1.16)
Linux nas2 4.4.1 #1 SMP Sun Jan 31 23:46:26 CET 2016 x86_64 GNU/Linux
mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Jun 20 23:56:59 2012
Raid Level : raid10
Array Size : 5860268032 (5588.79 GiB 6000.91 GB)
Used Dev Size : 2930134016 (2794.39 GiB 3000.46 GB)
Raid Devices : 4
Total Devices : 5
Persistence : Superblock is persistent
Update Time : Sun Jan 31 23:51:44 2016
State : active, resyncing
Active Devices : 4
Working Devices : 5
Failed Devices : 0
Spare Devices : 1
Layout : near=2
Chunk Size : 512K
Resync Status : 0% complete
Name : nas2:0 (local to host nas2)
UUID : 6abe1f20:90c629de:fadd8dc0:ca14c928
Events : 488
Number Major Minor RaidDevice State
0 8 17 0 active sync set-A /dev/sdb1
1 8 33 1 active sync set-B /dev/sdc1
2 8 49 2 active sync set-A /dev/sdd1
3 8 65 3 active sync set-B /dev/sde1
4 8 81 - spare /dev/sdf1
So it starts again rechecking the array
mdadm -E /dev/sd[b-f]1
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6abe1f20:90c629de:fadd8dc0:ca14c928
Name : nas2:0 (local to host nas2)
Creation Time : Wed Jun 20 23:56:59 2012
Raid Level : raid10
Raid Devices : 4
Avail Dev Size : 5860268943 (2794.39 GiB 3000.46 GB)
Array Size : 5860268032 (5588.79 GiB 6000.91 GB)
Used Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=911 sectors
State : active
Device UUID : ce9d878a:37a4f3a3:936bd905:c4ed9970
Update Time : Sun Jan 31 23:56:38 2016
Checksum : c92206ec - correct
Events : 489
Layout : near=2
Chunk Size : 512K
Device Role : Active device 0
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6abe1f20:90c629de:fadd8dc0:ca14c928
Name : nas2:0 (local to host nas2)
Creation Time : Wed Jun 20 23:56:59 2012
Raid Level : raid10
Raid Devices : 4
Avail Dev Size : 5860268943 (2794.39 GiB 3000.46 GB)
Array Size : 5860268032 (5588.79 GiB 6000.91 GB)
Used Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=911 sectors
State : active
Device UUID : 8c89bdf8:4f3f8ace:c15b5634:7a874071
Update Time : Sun Jan 31 23:56:38 2016
Checksum : 911217a8 - correct
Events : 489
Layout : near=2
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6abe1f20:90c629de:fadd8dc0:ca14c928
Name : nas2:0 (local to host nas2)
Creation Time : Wed Jun 20 23:56:59 2012
Raid Level : raid10
Raid Devices : 4
Avail Dev Size : 5860268943 (2794.39 GiB 3000.46 GB)
Array Size : 5860268032 (5588.79 GiB 6000.91 GB)
Used Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=911 sectors
State : active
Device UUID : 9c0655c3:dca7722e:8ecc1a17:fb4d9089
Update Time : Sun Jan 31 23:56:38 2016
Checksum : b6a6bcd3 - correct
Events : 489
Layout : near=2
Chunk Size : 512K
Device Role : Active device 2
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6abe1f20:90c629de:fadd8dc0:ca14c928
Name : nas2:0 (local to host nas2)
Creation Time : Wed Jun 20 23:56:59 2012
Raid Level : raid10
Raid Devices : 4
Avail Dev Size : 5860268943 (2794.39 GiB 3000.46 GB)
Array Size : 5860268032 (5588.79 GiB 6000.91 GB)
Used Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=911 sectors
State : active
Device UUID : c97b767a:84d2e7e2:52557d30:51c39784
Update Time : Sun Jan 31 23:56:38 2016
Checksum : 36a6d284 - correct
Events : 489
Layout : near=2
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6abe1f20:90c629de:fadd8dc0:ca14c928
Name : nas2:0 (local to host nas2)
Creation Time : Wed Jun 20 23:56:59 2012
Raid Level : raid10
Raid Devices : 4
Avail Dev Size : 5860268943 (2794.39 GiB 3000.46 GB)
Array Size : 5860268032 (5588.79 GiB 6000.91 GB)
Used Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=911 sectors
State : active
Device UUID : 82667e81:a6158319:85e0282e:845eec1c
Update Time : Sun Jan 31 23:51:44 2016
Checksum : a4a259e - correct
Events : 488
Layout : near=2
Chunk Size : 512K
Device Role : spare
Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
root@nas2:~#
-- eric
^ permalink raw reply
* Re: Reshape stuck immediately, backup file all nulls
From: George Rapp @ 2016-02-01 1:02 UTC (permalink / raw)
To: Björn Augustsson; +Cc: Phil Turmel, Linux-RAID
In-Reply-To: <CABRqA0jXMyH+TO8Nd47DTAj8RkyFC5bpg07uhXXRb7aU-twHfA@mail.gmail.com>
On Sun, Jan 31, 2016 at 9:59 AM, Björn Augustsson <oggust@gmail.com> wrote:
>
> On Sat, Jan 30, 2016 at 6:09 PM, Phil Turmel <philip@turmel.org> wrote:
> > Hi Björn,
> >
> > The kernel is waiting for mdmon (mdadm as a background task) to step
> > through the stripes. mdmon died and the kernel will wait forever.
>
> OK. So I think the root cause here is that my invocation of mdadm was
> unconfined,
> because I was running it interactively. So it could create the backup file.
> But the background version starts via systemd, and runs as mdadm_t, which
> can't read that file (because it's in /boot). And poof.
>
> I'll file a bug vs the fedora selinux policy for this, too.
Thanks for researching the SELinux vs. mdadm conflict in Fedora that
bit me as well (http://marc.info/?l=linux-raid&m=145349072305613&w=2).
If your Fedora selinux bug ticket makes it into general distribution,
lots of other users will be helped.
George
--
George Rapp (Pataskala, OH) Home: george.rapp -- at -- gmail.com
LinkedIn profile: https://www.linkedin.com/in/georgerapp
Phone: +1 740 936 RAPP (740 936 7277)
--
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: Reshape stuck immediately, backup file all nulls
From: Björn Augustsson @ 2016-02-01 18:45 UTC (permalink / raw)
To: George Rapp; +Cc: Phil Turmel, Linux-RAID
In-Reply-To: <CAF-KpgZy4+PGLGV8=x1mq+sXL8KDcGkyHsfuv6OSSxuZAwsHyw@mail.gmail.com>
On Mon, Feb 1, 2016 at 2:02 AM, George Rapp <george.rapp@gmail.com> wrote:
> On Sun, Jan 31, 2016 at 9:59 AM, Björn Augustsson <oggust@gmail.com> wrote:
>>
>> On Sat, Jan 30, 2016 at 6:09 PM, Phil Turmel <philip@turmel.org> wrote:
>> > Hi Björn,
>> >
>> > The kernel is waiting for mdmon (mdadm as a background task) to step
>> > through the stripes. mdmon died and the kernel will wait forever.
>>
>> OK. So I think the root cause here is that my invocation of mdadm was
>> unconfined,
>> because I was running it interactively. So it could create the backup file.
>> But the background version starts via systemd, and runs as mdadm_t, which
>> can't read that file (because it's in /boot). And poof.
>>
>> I'll file a bug vs the fedora selinux policy for this, too.
>
>
> Thanks for researching the SELinux vs. mdadm conflict in Fedora that
> bit me as well (http://marc.info/?l=linux-raid&m=145349072305613&w=2).
> If your Fedora selinux bug ticket makes it into general distribution,
> lots of other users will be helped.
marc.info appears to be down, at least for me.
Searching some more I found this though, and I guess it's it - it
sounds like exactly the same problem:
http://www.spinics.net/lists/raid/msg50735.html
I filed the bug with Fedora, at
https://bugzilla.redhat.com/show_bug.cgi?id=1303650
Let's hope this gets resolved. Storage/RAID issues like this make me nervous.
/August.
> George
> --
> George Rapp (Pataskala, OH) Home: george.rapp -- at -- gmail.com
> LinkedIn profile: https://www.linkedin.com/in/georgerapp
> Phone: +1 740 936 RAPP (740 936 7277)
--
Wrong on most accounts. const Foo *foo; and Foo const *foo; mean the same: foo
being a pointer to const Foo. const Foo const *foo; would mean the same but is
illegal (double const). You are confusing this with Foo * const foo; and const
Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system
--
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
* 我的交友主页是
From: 我的交友主页是 @ 2016-02-01 21:22 UTC (permalink / raw)
To: linux-raid
你的老朋友邀你来Q群:343257759
^ permalink raw reply
* Re: mdadm bad blocks list
From: Sarah Newman @ 2016-02-02 2:40 UTC (permalink / raw)
To: NeilBrown, linux-raid
In-Reply-To: <87twly1jc7.fsf@notabene.neil.brown.name>
On 01/27/2016 07:19 PM, NeilBrown wrote:
> On Thu, Jan 28 2016, Sarah Newman wrote:
>
>> Kernel: CentOS 6 Xen4CentOS 3.18.21-17
>> mdadm: CentOS 6 v3.3.2
>>
>> With the above behavior, I consider the bad blocks list to be actively harmful. If it's expected behavior in the current version, please consider
>> disabling the bad blocks list by default.
>
> You can do this yourself by putting
>
> CREATE bbl=no
>
> in /etc/mdadm.conf. That doesn't help others though.
FYI, I tried adding that line and if it is present when trying to add to an array that currently has a bad blocks list, I get the error message
md: sdi1 does not have a valid v1.0 superblock, not importing!
Is this expected?
Thanks, Sarah
^ permalink raw reply
* [PATCH resend] [dm]fix NULL pointer when create dm device
From: DingXiang @ 2016-02-02 4:29 UTC (permalink / raw)
To: agk, snitzer; +Cc: dm-devel, linux-raid, linux-kernel, DingXiang
In some conditions(such as umount fs failed),origin path or origin bdev or both of the two is same
as cow's.If this happens, origin dev will be freed when get cow dev in function "dm_get_device" ,
then "s->origin->dev" which used by "dm_exception_store_set_chunk_size" will be a NULL pointer.
Here is my call trace
dracut-initqueue[2614]: mount: unknown filesystem type 'squashfs'
dracut-initqueue[2614]: umount: /run/initramfs/squashfs: not mounted
Unable to handle kernel NULL pointer dereference at virtual address 00000098
pgd = ffffffc038c3d000
[00000098] *pgd=0000000000000000, *pud=0000000000000000
Internal error: Oops: 96000005 [#1] SMP
Modules linked in:
CPU: 20 PID: 6389 Comm: dmsetup Not tainted 3.19.8+ #19
Hardware name: Huawei Taishan 2160 /BC11SPCA, BIOS 1.16 01/13/2016
task: ffffffdfb3e060c0 ti: ffffffc038600000 task.ti: ffffffc038600000
PC is at dm_exception_store_set_chunk_size+0x6c/0x124
LR is at dm_exception_store_set_chunk_size+0x68/0x124
pc : [<ffffffc00060b4d8>] lr : [<ffffffc00060b4d4>] pstate: 40000145
sp : ffffffc038603a90
x29: ffffffc038603a90 x28: ffffffc038600000
x27: ffffffefab3b7630 x26: 0000000000000001
x25: ffffffc000c9e030 x24: ffffffdfb2187740
x23: ffffffc038603b94 x22: ffffffefab3b7730
x21: ffffff80003dd088 x20: ffffffdfb2187740
x19: 0000000000000008 x18: 0000007fac97383c
x17: 0000007fac8b9cb0 x16: ffffffc0001ae79c
x15: 0000007fac9a00b0 x14: 0000007fac9a00b0
x13: 0000000000000001 x12: 0000000000000020
x11: 0000000000000008 x10: 0000000000000000
x9 : 000000000000000a x8 : 0000000000000008
x7 : ffffffefa95f4179 x6 : 0000000000000008
x5 : 0000000000000008 x4 : 0000000000000007
x3 : 0000000000000008 x2 : ffffff80003dd088
x1 : 0000000000000008 x0 : 0000000000000000
Process dmsetup (pid: 6389, stack limit = 0xffffffc038600058)
Stack: (0xffffffc038603a90 to 0xffffffc038604000)
3a80: 38603ac0 ffffffc0 0060b6fc ffffffc0
3aa0: 00000000 00000000 003dd040 ffffff80 ab3b7600 ffffffef 00000008 00000000
3ac0: 38603b20 ffffffc0 0060a944 ffffffc0 b2187700 ffffffdf 003dd040 ffffff80
3ae0: ab3b7600 ffffffef ab3b7730 ffffffef 00000002 00000000 0081e000 ffffffc0
3b00: 00cc6000 ffffffc0 38600000 ffffffc0 38603b20 ffffffc0 b2187b58 00000008
3b20: 38603bb0 ffffffc0 005f6378 ffffffc0 003dd040 ffffff80 ab3b7800 ffffffef
3b40: 00000000 00000000 a95f4150 ffffffef 00000000 00000000 003dd040 ffffff80
3b60: a95f4000 ffffffef a95f4000 ffffffef 00c58000 ffffffc0 38600000 ffffffc0
3b80: 00000000 00000000 a95f416b ffffffef a95f4000 ffffffef 005f62d4 ffffffc0
3ba0: 003dd040 ffffff80 005f5f68 00000008 38603c10 ffffffc0 005f98cc ffffffc0
3bc0: a95f4138 ffffffef a95f8000 ffffffef 00000000 00000000 b41b2400 ffffffdf
3be0: ab3b7800 ffffffef 00000000 00000000 a95f4160 ffffffef 00100000 00000000
3c00: 38603c10 00000004 b2187700 ffffffdf 38603c70 ffffffc0 005fa484 ffffffc0
3c20: c7e1d2d0 0000007f 00000000 00000000 00004000 00000000 00000009 00000000
3c40: 00000001 00000000 005f97bc ffffffc0 00000000 00000000 00000000 00000000
3c60: 00000000 00000000 ab3b7800 ffffffef 38603e00 ffffffc0 005fa758 ffffffc0
3c80: b7e82c00 ffffffdf c7e1d2d0 0000007f b87e6e88 ffffffef 00000003 00000000
3ca0: c7e1d2d0 0000007f c138fd09 00000000 0000011a 00000000 0000001d 00000000
3cc0: 00000020 00000000 00000004 0000001d 00000000 00004000 00000138 00000001
3ce0: 00000000 00000004 00000000 00000000 00000000 00000000 6576696c 0077722d
3d00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3da0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3dc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3de0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3e00: 38603e10 ffffffc0 001ae54c ffffffc0 38603e90 ffffffc0 001ae820 ffffffc0
3e20: 00000000 00000000 b7e82c00 ffffffdf b7e82c00 ffffffdf 00000003 00000000
3e40: 00cbb000 ffffffc0 b3e060c0 ffffffdf 80000000 00000000 00000015 00000000
3e60: 00000000 00000000 00000000 00000000 38603e80 ffffffc0 001b88e4 ffffffc0
3e80: 38603e90 ffffffc0 001ae7dc ffffffc0 c6e64c40 0000007f 00086430 ffffffc0
3ea0: 00000000 00000000 c7e1d2d0 0000007f ffffffff ffffffff ac8b9cbc 0000007f
3ec0: 60000000 00000000 00000015 00000000 00000003 00000000 c138fd09 00000000
3ee0: c7e1d2d0 0000007f 00000007 00000000 ac9a73e8 0000007f c6e64aa0 0000007f
3f00: 37770e00 3c220354 c7e1d300 0000007f 0000001d 00000000 ffffffe8 ffffff80
3f20: c6e64b90 0000007f c6e64b90 0000007f ac9a00b0 0000007f ac9a00b0 0000007f
3f40: ac9a00b0 0000007f ac9a00b0 0000007f ac9bec98 0000007f ac8b9cb0 0000007f
3f60: ac97383c 0000007f c7e1d200 0000007f c7e1d2d0 0000007f c7e1d300 0000007f
3f80: ac9a6000 0000007f c7e1d380 0000007f ac9a00b0 0000007f ac9a00b0 0000007f
3fa0: 00000000 00000000 ac9be000 0000007f ac9a00b0 0000007f c6e64c40 0000007f
3fc0: ac99e1d4 0000007f c6e64b90 0000007f ac8b9cbc 0000007f 60000000 00000000
3fe0: 00000003 00000000 0000001d 00000000 00000000 00000000 00000000 00000000
Call trace:
[<ffffffc00060b4d8>] dm_exception_store_set_chunk_size+0x6c/0x124
[<ffffffc00060b6f8>] dm_exception_store_create+0x168/0x1c4
[<ffffffc00060a940>] snapshot_ctr+0x168/0x5ec
[<ffffffc0005f6374>] dm_table_add_target+0x114/0x360
[<ffffffc0005f98c8>] table_load+0x10c/0x314
[<ffffffc0005fa480>] ctl_ioctl+0x1f8/0x4bc
[<ffffffc0005fa754>] dm_ctl_ioctl+0x10/0x20
[<ffffffc0001ae548>] do_vfs_ioctl+0x360/0x5b4
[<ffffffc0001ae81c>] SyS_ioctl+0x80/0x98
And I think the BUG https://bugzilla.redhat.com/show_bug.cgi?id=1195899
should be the same reason.
Signed-off-by:Ding Xiang <dingxiang@huawei.com>
---
drivers/md/dm-snap.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 3766386..ccf97d8 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -1102,6 +1102,7 @@ static void stop_merge(struct dm_snapshot *s)
static int snapshot_ctr(struct dm_target *ti, unsigned int argc, char **argv)
{
struct dm_snapshot *s;
+ struct block_device *origin_bdev, *cow_bdev;
int i;
int r = -EINVAL;
char *origin_path, *cow_path;
@@ -1136,10 +1137,19 @@ static int snapshot_ctr(struct dm_target *ti, unsigned int argc, char **argv)
goto bad_origin;
}
+ origin_bdev = s->origin->bdev;
cow_path = argv[0];
argv++;
argc--;
+ /*check cow dev is available*/
+ cow_bdev = lookup_bdev(cow_path);
+ if(cow_bdev->bd_dev == origin_bdev->bd_dev){
+ ti->error = "Invalid COW device";
+ r = -EINVAL;
+ goto bad_cow;
+ }
+
r = dm_get_device(ti, cow_path, dm_table_get_mode(ti->table), &s->cow);
if (r) {
ti->error = "Cannot get COW device";
--
1.7.1
^ permalink raw reply related
* Re: WANTED new maintainer for Linux/md (and mdadm)
From: Jes Sorensen @ 2016-02-02 12:19 UTC (permalink / raw)
To: NeilBrown; +Cc: Artur Paszkiewicz, linux-raid, dm-devel, LKML, Shaohua Li
In-Reply-To: <87powo2ber.fsf@notabene.neil.brown.name>
NeilBrown <neilb@suse.com> writes:
> On Wed, Jan 20 2016, Artur Paszkiewicz wrote:
>>
>> Hi Neil,
>>
>> Thank you for your work and time spent on maintaining MD/mdadm. I would also
>> like to offer help for the emerging maintainership team. I've been
>> working with
>> MD RAID for more than 4 years, mostly testing and developing the IMSM-related
>> parts on behalf of my employer - Intel. I realize that I was not very visible
>> on this mailing list, but I think I have a pretty good knowledge about mdadm
>> and the MD drivers. Now I have Intel's approval to take on maintaining MD RAID
>> as part of my job, not focusing primarily on IMSM. I definitely feel more
>> confident with maintaining mdadm, but I would certainly like to learn more
>> about the kernel MD stack and help with it as much as I can.
>
> Hi Arthur,
> thanks for all your IMSM work over the years! It is great that you can
> continue contributing and do so more broadly.
>
> For the moment Jes Serensen will be co-ordinating mdadm (once I make a
> release ... tomorrow?) and Shaohua Li will be looking after the
> kernel/md side. I'm sure there is plenty of room for you too though.
> Only one person (at a time) can queue patches, but several can
> collaborate at development and support and bug fixing and testing and
> ....
> I suggest you find ways to co-ordinate with them.
>
> This:
> https://bugzilla.kernel.org/show_bug.cgi?id=108741
> is currently most important in my mind, but there are other things to
> do.
Hi Arthur,
I have setup a git repository for mdadm here:
git://git.kernel.org/pub/scm/utils/mdadm/mdadm.git
I'll be relying heavily on your contributions in managing this now that
Neil is leaving it to us. I'll do my best to maintain it in a similar
manner to Neil, albeit I am probably going to screw up a lot more often.
Please fire away those patches and do not be afraid to yell at me if I
get something wrong!
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH/mdadm] super1: Fix bblog_size accesses on big-ending machines.
From: Jes Sorensen @ 2016-02-02 12:20 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <87d1sl182i.fsf@notabene.neil.brown.name>
NeilBrown <neilb@suse.com> writes:
> bblog_size is 16bit so using le32_to_cpu on it is not wise
> and leads to errors on big-endian machines.
> Change all such calls to use le16.
>
> Bug was introduced in mdadm-3.3
>
> Signed-off-by: NeilBrown <neilb@suse.com>
> ---
>
> Hi Jes,
> when you are ready to start queuing patches for mdadm, this will make
> sure you have something to work with:-)
>
> Thanks,
> NeilBrown
Applied!
Thanks,
Jes
>
> super1.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/super1.c b/super1.c
> index 8bcaa2fe02c8..9b877e504c4b 100644
> --- a/super1.c
> +++ b/super1.c
> @@ -730,12 +730,12 @@ static int copy_metadata1(struct supertype *st, int from, int to)
> }
>
> if (super.bblog_size != 0 &&
> - __le32_to_cpu(super.bblog_size) <= 100 &&
> + __le16_to_cpu(super.bblog_size) <= 100 &&
> super.bblog_offset != 0 &&
> (super.feature_map & __le32_to_cpu(MD_FEATURE_BAD_BLOCKS))) {
> /* There is a bad block log */
> unsigned long long bb_offset = sb_offset;
> - int bytes = __le32_to_cpu(super.bblog_size) * 512;
> + int bytes = __le16_to_cpu(super.bblog_size) * 512;
> int written = 0;
> struct align_fd afrom, ato;
>
> @@ -832,7 +832,7 @@ static int examine_badblocks_super1(struct supertype *st, int fd, char *devname)
> __u64 *bbl, *bbp;
> int i;
>
> - if (!sb->bblog_size || __le32_to_cpu(sb->bblog_size) > 100
> + if (!sb->bblog_size || __le16_to_cpu(sb->bblog_size) > 100
> || !sb->bblog_offset){
> printf("No bad-blocks list configured on %s\n", devname);
> return 0;
> @@ -843,7 +843,7 @@ static int examine_badblocks_super1(struct supertype *st, int fd, char *devname)
> return 0;
> }
>
> - size = __le32_to_cpu(sb->bblog_size)* 512;
> + size = __le16_to_cpu(sb->bblog_size)* 512;
> if (posix_memalign((void**)&bbl, 4096, size) != 0) {
> pr_err("could not allocate badblocks list\n");
> return 0;
> @@ -986,7 +986,7 @@ static void getinfo_super1(struct supertype *st, struct mdinfo *info, char *map)
> if (sb->bblog_offset && sb->bblog_size) {
> unsigned long long bbend = super_offset;
> bbend += (int32_t)__le32_to_cpu(sb->bblog_offset);
> - bbend += __le32_to_cpu(sb->bblog_size);
> + bbend += __le16_to_cpu(sb->bblog_size);
> if (bbend > earliest)
> earliest = bbend;
> }
^ permalink raw reply
* Re: deprecating /proc/mdstat
From: Jes Sorensen @ 2016-02-02 14:33 UTC (permalink / raw)
To: Shaohua Li; +Cc: Jens-U. Mozdzen, NeilBrown, linux-raid
In-Reply-To: <20160128182102.GA23378@kernel.org>
Shaohua Li <shli@kernel.org> writes:
> On Thu, Jan 28, 2016 at 12:41:21PM +0100, Jens-U. Mozdzen wrote:
>> If there's to be a "new mdstat" in /sys, I'd be fine with that. That would
>> help migration for those "old scripts grep'ing /proc/mdstat" you rightfully
>> care about.
>>
>> I suggest to include a file format version information on line 1
>> "/sys/.../mdstat", that way any client parsing such an interface could
>> verify the file format first, and bail out if it doesn't support the
>> currently presented format.
>
> All the info you can get from /proc/mdstat can be found in /sys/xxx. There
> isn't a central mdstat file in sysfs entry, each sysfs entry only export single
> type info. Version info is uncessary, if we need add new info, we'd just add a
> new sysfs entry.
>
> though the /proc/mdstat will not be deprecated soon, it's highly encouraged app
> switches to /sys. sysfs entry is easy to parse. And as Neil said, /proc/mdstat
> is hard to extend, so new info will likely only appear in sysfs.
I think the strong argument for /proc/mdstat is that it's easy for
visual inspection, but should not be scripted. I certainly use it quite
regularly, but maybe I am just old and lazy :)
Cheers,
Jes
^ permalink raw reply
* Bogus entry in mdadm bad blocks list and question about particular commit
From: Sarah Newman @ 2016-02-02 20:34 UTC (permalink / raw)
To: linux-raid
I added some more drives to a raid 1 last night where some devices had existing bad block entries. There was nothing of particular interest in
/var/log/messages. Afterwards there is:
$ sudo /sbin/mdadm --examine-badblocks /dev/sdl1
Bad-blocks on /dev/sdl1:
11986270392325491 for 51 sectors
The total number of sectors on the drive is 3907029168.
The start sector in the bad blocks list is 2a95730cea9573 in hex, I don't know if that string has any special significance or not.
$ sudo /sbin/mdadm --examine /dev/sdl1
/dev/sdl1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x8
Raid Level : raid1
Raid Devices : 11
Avail Dev Size : 20971368 (10.00 GiB 10.74 GB)
Array Size : 10485632 (10.00 GiB 10.74 GB)
Used Dev Size : 20971264 (10.00 GiB 10.74 GB)
Super Offset : 20971504 sectors
Unused Space : before=0 sectors, after=232 sectors
State : clean
Update Time : Tue Feb 2 10:50:33 2016
Bad Block Log : 512 entries available at offset -8 sectors - bad blocks present.
Checksum : 4092aabf - correct
Events : 143560
Device Role : Active device 9
Array State : AAAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)
The kernel is built from the Xen4CentOS 3.18.21-17 kernel, but there are no changes related to md in the code.
I looked for differences in between 3.18.21 and stable 3.18.y and the only interesting thing looked like e9206476ace "md/raid1: submit_bio_wait()
returns 0 on success". I don't think that's a smoking gun for the bogus bad blocks entry. But without that commit, mdadm with bad blocks enabled is
completely broken if there are write errors such that successful writes are reported as errors and vice versa, is that correct?
Thanks, Sarah
^ permalink raw reply
* Re: Bogus entry in mdadm bad blocks list and question about particular commit
From: Jes Sorensen @ 2016-02-02 20:46 UTC (permalink / raw)
To: Sarah Newman; +Cc: linux-raid
In-Reply-To: <56B112F3.9010609@prgmr.com>
Sarah Newman <srn@prgmr.com> writes:
> I added some more drives to a raid 1 last night where some devices had existing bad block entries. There was nothing of particular interest in
> /var/log/messages. Afterwards there is:
>
> $ sudo /sbin/mdadm --examine-badblocks /dev/sdl1
> Bad-blocks on /dev/sdl1:
> 11986270392325491 for 51 sectors
>
> The total number of sectors on the drive is 3907029168.
>
> The start sector in the bad blocks list is 2a95730cea9573 in hex, I don't know if that string has any special significance or not.
>
> $ sudo /sbin/mdadm --examine /dev/sdl1
> /dev/sdl1:
> Magic : a92b4efc
> Version : 1.0
> Feature Map : 0x8
>
> Raid Level : raid1
> Raid Devices : 11
>
> Avail Dev Size : 20971368 (10.00 GiB 10.74 GB)
> Array Size : 10485632 (10.00 GiB 10.74 GB)
> Used Dev Size : 20971264 (10.00 GiB 10.74 GB)
> Super Offset : 20971504 sectors
> Unused Space : before=0 sectors, after=232 sectors
> State : clean
>
> Update Time : Tue Feb 2 10:50:33 2016
> Bad Block Log : 512 entries available at offset -8 sectors - bad blocks present.
> Checksum : 4092aabf - correct
> Events : 143560
>
>
> Device Role : Active device 9
> Array State : AAAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)
>
> The kernel is built from the Xen4CentOS 3.18.21-17 kernel, but there
> are no changes related to md in the code.
>
> I looked for differences in between 3.18.21 and stable 3.18.y and the
> only interesting thing looked like e9206476ace "md/raid1:
> submit_bio_wait() returns 0 on success". I don't think that's a
> smoking gun for the bogus bad blocks entry. But without that commit,
> mdadm with bad blocks enabled is completely broken if there are write
> errors such that successful writes are reported as errors and vice
> versa, is that correct?
Sarah,
If I remember correctly, yes then badblocks handling was pretty wedged
without that patch since it broke the narrowing down of the problem. If
you have to run such an old kernel, you really ought to backport
681ab4696062f5aa939c9e04d058732306a97176 and
203d27b0226a05202438ddb39ef0ef1acb14a759 if you have raid1 and/or raid10
arrays.
Jes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox