* recovery from selinux blocking --backup-file during RAID5->6
From: Noah Beck @ 2016-04-05 3:16 UTC (permalink / raw)
To: linux-raid
I see a similar problem has been discussed at least once before at
https://marc.info/?t=144970286700004&r=1&w=2
In my case, this was a RAID5 array with 4 active devices and one
spare. I wanted to switch this to a 5-device RAID6 instead. Ran the
following:
mdadm --grow /dev/md127 --raid-devices 5 --level 6 --backup-file
/root/raid_migration_file
Two things went wrong:
1) selinux jumped in and blocked access to the --backup-file. From journalctl:
SELinux is preventing mdadm from getattr access on the file
/root/raid_migration_file
This can be fixed with a "setenforce 0" in the future. The
/root/raid_migration_file did get created (25MB) but hexdump says it
is all zeros so I believe no useful data was placed in this file.
2) Turns out my spare device in the old RAID5 was actually ready to
die. This corresponds to what was previously the spare in my RAID5:
ata4.00: revalidation failed (errno=-2)
ata4.00: disabled
ata4: EH complete
blk_update_request: I/O error, dev sdb, sector 0
blk_update_request: I/O error, dev sdb, sector 3907023935
md: super_written gets error=-5
md/raid:md127: Disk failure on sdb1, disabling device.
md/raid:md127: Operation continuing on 4 devices.
Since /dev/sdb1 was marked as failed in the array I removed it. I
tried zeroing it out with dd if=/dev/zero of=/dev/sdb1 to see what it
would do and then that disk completely died. So I'll get a new disk
tomorrow. In the meantime the system still seems to be running fine.
/proc/mdstat shows this now:
md127 : active raid6 sde1[3] sda1[2] sdd1[0] sdf1[1]
5860535808 blocks super 0.91 level 6, 64k chunk, algorithm 18
[5/4] [UUUU_]
[>....................] reshape = 0.0% (1/1953511936)
finish=722.0min speed=43680K/sec
The previous thread resulted in a patch (in
https://marc.info/?l=linux-raid&m=145187378405337&w=2 ). If I want to
go back to having a 4-device RAID5 array before I shut this system
down to replace the bad disk, is the right thing to do still to apply
that patch to mdadm, stop /dev/md127, and assemble again with
--update=revert-reshape? Or does the info above indicate I should use
any different solution?
Thanks,
Noah
^ permalink raw reply
* Re: [PATCH] Consistent use of IEC 80000-13 prefix in manpage
From: Anthonys Lists @ 2016-04-03 19:19 UTC (permalink / raw)
Cc: linux-raid
In-Reply-To: <wrfjio028nxk.fsf@redhat.com>
On 31/03/2016 20:09, Jes Sorensen wrote:
> I am not very much in favor of this patch. Any normal sane person still
> refers to megabytes and kilobytes as referring to 1024 base sizes,
> despite the pointless standard trying to mess them up to accommodate the
> harddrive vendors. Nobody normal knows what a kibibyte is.
Nobody normal knows that kilo actually means 2^10 ...
Yes I know us computer people regularly abuse the term, but nowadays the
majority of computer lusers are familiar with the fact kilo has *always*
meant 10^3.
After all, isn't a billion one million squared? (10^12) ... :-) It's
only the Americans who think it's 1000^3 :-)
Cheers,
Wol
^ permalink raw reply
* Hilsener.
From: fu.zhongjun @ 2016-04-03 1:12 UTC (permalink / raw)
To: Recipients
God dag,
Jeg trenger en utenlandsk partner for en gjensidig virksomhet forslag, som er relatert til overføring av en stor sum penger til en utenlandsk konto, som mottaker av midlene. Alt om denne transaksjonen vil bli gjort lovlig uten bro av økonomisk autoritet både i mitt land og yours.I wil hengi deg til å observere ytterste skjønn i alle saker knyttet til dette problemet. Hvis du er interessert, kan du svare tilbake via min private e-postadresse er skrevet under, vil jeg gi deg mer informasjon om meg selv med finans institusjonen jeg representerte og faktiske beløpene innebærer om prosjektet så snart jeg får positiv respons.
Privat e-post:zhongjunfu@yahoo.com.hk
Vennlig hilsen,
Daglig leder.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/4] scatterlist: Introduce some helper functions
From: Robert Jarzmik @ 2016-04-02 15:00 UTC (permalink / raw)
To: Baolin Wang
Cc: herbert, davem, agk, snitzer, axboe, dm-devel, akpm,
david.s.gordon, thomas.lendacky, yamada.masahiro, smueller,
tadeusz.struk, standby24x7, shli, broonie, linus.walleij, arnd,
linux-kernel, linux-crypto, linux-raid
In-Reply-To: <9442060edaca12f520bcbb76545ad33a52346e58.1458023698.git.baolin.wang@linaro.org>
Baolin Wang <baolin.wang@linaro.org> writes:
> +/**
> + * sg_is_contiguous - Check if the scatterlists are contiguous
> + * @sga: SG entry
> + * @sgb: SG entry
> + *
> + * Description:
> + * If the sga scatterlist is contiguous with the sgb scatterlist,
> + * that means they can be merged together.
> + *
> + **/
> +static inline bool sg_is_contiguous(struct scatterlist *sga,
> + struct scatterlist *sgb)
> +{
> + return *(unsigned long *)sg_virt(sga) + sga->length ==
> + *(unsigned long *)sg_virt(sgb);
As I already said, I don't like casts.
But let's take some height : you're needing this function to decide to merge
scatterlists. That means that you think the probability of having 2 scatterlist
mergeable is not meaningless, ie. 50% or more.
I suppose your scatterlists are allocated through kmalloc(). I'd like to know,
through your testing, what is the success rate of sg_is_contiguous(), ie. I'd
like to know how many times sg_is_contiguous() was called, and amongst these
calls how many times it returned true.
That will tell me how "worth" is this optimization.
> + * sg_add_sg_to_table - Add one scatterlist into sg table
> + * @sgt: The sg table header to use
> + * @src: The sg need to be added into sg table
> + *
> + * Description:
> + * The 'nents' member indicates how many mapped scatterlists has been added
> + * in the dynamic sg table. The 'orig_nents' member indicates the size of the
> + * dynamic sg table.
> + *
> + * Copy one mapped @src@ scatterlist into the dynamic sg table and increase
> + * 'nents' member.
> + *
> + **/
Okay, I still believe this one is wrong, because we don't understand each other.
So let's take an example :
sg_table = {
.sgl = {
{
.page_link = PAGE_48,
.offset = 0,
.length = 2048,
.dma_address = 0x30000,
.dma_length = 4096,
},
{
.page_link = PAGE_48 | 0x02,
.offset = 2048,
.length = 2048,
.dma_address = 0,
.dma_length = 0,
},
},
.nents = 1,
.orig_nents = 2,
};
In this example, by sheer luck the 2 scatterlist entries were physically
contiguous, and the mapping function coallesced the 2 entries into only one
(dma_address, dma_length) entry. That could also happen with an IOMMU by the
way. Therefore, sg_table.nents = 1.
If I understand your function correctly, it will erase sg_table.sgl[1], and that
looks incorrect to me. This is why I can't understand how your code can be
correct, and why I say you add a new "meaning" to sg_table->nents, which is not
consistent with the meaning I understand.
Cheers.
--
Robert
^ permalink raw reply
* Re: [PATCH v2] Consistent use of metric prefix in manpage
From: Jes Sorensen @ 2016-04-01 20:11 UTC (permalink / raw)
To: Marko Hauptvogel; +Cc: linux-raid
In-Reply-To: <56FDA301.1080304@googlemail.com>
Marko Hauptvogel <marko.hauptvogel@googlemail.com> writes:
> On 31.03.2016 21:09, Jes Sorensen wrote:
>> Marko Hauptvogel <marko.hauptvogel@googlemail.com> writes:
>>> > From: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
>>> >
>>> > Added the optional K suffix for completeness, as it
>>> > is allowed by util.c's parse_size(char*).
>>> >
>>> > Signed-off-by: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
>> I am not very much in favor of this patch. Any normal sane person still
>> refers to megabytes and kilobytes as referring to 1024 base sizes,
>> despite the pointless standard trying to mess them up to accommodate the
>> harddrive vendors. Nobody normal knows what a kibibyte is.
>>
>> Jes
>>
>
> I am fine either way, but it should be used consistently throughout
> the man page. The mix up was what made me cringe.
Works for me!
Cheers,
Jes
>
> Greetings
>
> --------
>
> From eaad00be960ff1d60861cba75cc7e5eb07f7e330 Mon Sep 17 00:00:00 2001
> From: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
> Date: Fri, 1 Apr 2016 00:13:44 +0200
> Subject: [PATCH] Consistent use of metric prefix in manpage
>
> Added the optional K suffix for completeness, as it
> is allowed by util.c's parse_size(char*).
>
> Signed-off-by: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
> ---
> mdadm.8.in | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/mdadm.8.in b/mdadm.8.in
> index 50be1aa..1a04bd1 100644
> --- a/mdadm.8.in
> +++ b/mdadm.8.in
> @@ -459,7 +459,7 @@ number of spare devices.
>
> .TP
> .BR \-z ", " \-\-size=
> -Amount (in Kibibytes) of space to use from each drive in RAID levels 1/4/5/6.
> +Amount (in Kilobytes) of space to use from each drive in RAID levels 1/4/5/6.
> This must be a multiple of the chunk size, and must leave about 128Kb
> of space at the end of the drive for the RAID superblock.
> If this is not specified
> @@ -467,7 +467,7 @@ If this is not specified
> size, though if there is a variance among the drives of greater than
> 1%, a warning is
> issued.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
> Gigabytes respectively.
>
> Sometimes a replacement drive can be a little smaller than the
> @@ -534,7 +534,7 @@ problems the array can be made bigger again with
> no loss with another
> .B "\-\-grow \-\-array\-size="
> command.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
> Gigabytes respectively.
> A value of
> .B max
> @@ -543,7 +543,7 @@ amount of available space is.
>
> .TP
> .BR \-c ", " \-\-chunk=
> -Specify chunk size of kibibytes. The default when creating an
> +Specify chunk size of kilobytes. The default when creating an
> array is 512KB. To ensure compatibility with earlier versions, the
> default when building an array with no persistent metadata is 64KB.
> This is only meaningful for RAID0, RAID4, RAID5, RAID6, and RAID10.
> @@ -551,7 +551,7 @@ This is only meaningful for RAID0, RAID4, RAID5,
> RAID6, and RAID10.
> RAID4, RAID5, RAID6, and RAID10 require the chunk size to be a power
> of 2. In any case it must be a multiple of 4KB.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
> Gigabytes respectively.
>
> .TP
> @@ -737,7 +737,7 @@ When using an
> bitmap, the chunksize defaults to 64Meg, or larger if necessary to
> fit the bitmap into the available space.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
> Gigabytes respectively.
>
> .TP
> @@ -808,7 +808,8 @@ an array which was originally created using a
> different version of
> which computed a different offset.
>
> Setting the offset explicitly over-rides the default. The value given
> -is in Kilobytes unless an 'M' or 'G' suffix is given.
> +is in Kilobytes unless a suffix of 'K', 'M' or 'G' is used to explicitly
> +indicate Kilobytes, Megabytes or Gigabytes respectively.
>
> Since Linux 3.4,
> .B \-\-data\-offset
^ permalink raw reply
* Re: [V2 PATCH] md/bitmap: clear bitmap if bitmap_create failed
From: Shaohua Li @ 2016-04-01 20:04 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: neilb, linux-raid
In-Reply-To: <1459501729-19224-1-git-send-email-gqjiang@suse.com>
On Fri, Apr 01, 2016 at 05:08:49PM +0800, Guoqing Jiang wrote:
> If bitmap_create returns an error, we need to call
> either bitmap_destroy or bitmap_free to do clean up,
> and the selection is based on mddev->bitmap is set
> or not.
>
> And the sysfs_put(bitmap->sysfs_can_clear) is moved
> from bitmap_destroy to bitmap_free, and the comment
> of bitmap_create is changed as well.
Applied, thanks!
^ permalink raw reply
* Re: Recovery after failed chunk size change
From: Benjamin Meier @ 2016-04-01 20:03 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <87a8ldrjcr.fsf@notabene.neil.brown.name>
Hi,
Am 01.04.2016 um 07:25 schrieb NeilBrown:
> mdadm --assemble --force --update=revert-reshape --invalid-backup
> --backup-file=/whatever /dev/md/TA /dev/list-of-devices using mdadm 3.4.
Thanks. Now my array is online again and working.
> If someone can provide a recipe for how to reproduce the problem (e.g.
> using loop-back devices) I'll happily look into fixing it, or
> identifying which kernel it is already fixed in. Neilbrown
I could reproduce the issue with my current kernel. I also tried the
debian unstable kernel 4.4 and mdadm 3.4 - it looks like the bug is
still there. Most of the time it is not reshaping any block. As I
executed the commands by hand I could see that sometimes the process
stops after only one block and sometimes the process stops in the
middle. You can use the script that I wrote to make the reproduction
easier. Maybe it is also working with smaller files than 1GiB.
Good luck for the bug hunting!
--
#!/bin/bash
# Create a seven disk RAID6 array with sparse files (1GiB each)
declare -a LO_DEVICES
for x in 0 1 2 3 4 5 6; do
dd if=/dev/zero of=sparse$x bs=1G count=0 seek=1
losetup -f sparse${x}
LO_DEVICES[$x]=$(losetup -a|grep sparse${x}|cut -f1 -d" "|sed "s/://")
done
mdadm --create /dev/md/TestMD --chunk=4096 --bitmap=internal --level=6
--raid-devices=7 \
${LO_DEVICES[*]}
mdadm --wait /dev/md/TestMD
# Provocate BUG.
# Tested with Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4
(2016-02-29) x86_64 GNU/Linux
# mdadm - v3.3.2 - 21st August 2014
mdadm --grow /dev/md/TestMD --chunk=64 --backup-file=backup.file
^ permalink raw reply
* Re: [BUG] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev
From: Eric Wheeler @ 2016-04-01 18:14 UTC (permalink / raw)
To: Sebastian Roesner
Cc: Shaohua Li, Ming Lei, linux-bcache, linux-raid, Ming Lin,
Vlad-Cosmin Miu, rjones, Kent Overstreet, jmoyer, axboe
In-Reply-To: <20160328181059.GA83819@kernel.org>
On Mon, 28 Mar 2016, Shaohua Li wrote:
> On Sat, Mar 26, 2016 at 05:46:16PM +0100, Sebastian Roesner wrote:
> > Hello Ming, Eric,
> >
> > Am 26.03.2016 um 16:40 schrieb Ming Lei:
> > I was able to reproduce it on a non-productive system, but only after
> > copying the bcache superblocks/partition starts from the original system,
> > with new created ones it worked fine.
Hey Sebastian,
Have you had a chance to test the patch below from Shaohua Li?
--
Eric Wheeler
> >
> > Full trace and check_bio output can be found here:
> >
> > http://pastebin.com/ngvGGHBZ
>
> 320 bvecs exceeds what bio-clone_set can handle. Could you please try below patch?
>
> commit 92761dad7ff6e1bf25de247e0064dd398e797599
> Author: Shaohua Li <shli@fb.com>
> Date: Mon Mar 28 10:54:35 2016 -0700
>
> block: don't make BLK_DEF_MAX_SECTORS too big
>
> bio_alloc_bioset() allocates bvecs from bvec_slabs which can only allocate
> maximum 256 bvec (eg, 1M for 4k pages). We can't bump BLK_DEF_MAX_SECTORS to
> exceed this value otherwise bio_alloc_bioset will fail.
>
> This fixes commit 30e2bc08b2bb7c069. We probably should make the bvec_slabs
> hold bigger bvecs if bigger bio size is required.
>
> Signed-off-by: Shaohua Li <shli@fb.com>
>
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 7e5d7e0..da64325 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -1153,7 +1153,11 @@ extern int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm);
> enum blk_default_limits {
> BLK_MAX_SEGMENTS = 128,
> BLK_SAFE_MAX_SECTORS = 255,
> - BLK_DEF_MAX_SECTORS = 2560,
> + /*
> + * if you change this, please also change bvec_alloc and BIO_MAX_PAGES.
> + * Otherwise bio_alloc_bioset will break.
> + */
> + BLK_DEF_MAX_SECTORS = BIO_MAX_SECTORS,
> BLK_MAX_SEGMENT_SIZE = 65536,
> BLK_SEG_BOUNDARY_MASK = 0xFFFFFFFFUL,
> };
>
^ permalink raw reply
* [V2 PATCH] md/bitmap: clear bitmap if bitmap_create failed
From: Guoqing Jiang @ 2016-04-01 9:08 UTC (permalink / raw)
To: shli; +Cc: neilb, linux-raid, Guoqing Jiang
In-Reply-To: <1458903614-21498-1-git-send-email-gqjiang@suse.com>
If bitmap_create returns an error, we need to call
either bitmap_destroy or bitmap_free to do clean up,
and the selection is based on mddev->bitmap is set
or not.
And the sysfs_put(bitmap->sysfs_can_clear) is moved
from bitmap_destroy to bitmap_free, and the comment
of bitmap_create is changed as well.
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/bitmap.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index a624792..062ac99 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -1697,6 +1697,9 @@ static void bitmap_free(struct bitmap *bitmap)
if (!bitmap) /* there was no bitmap */
return;
+ if (bitmap->sysfs_can_clear)
+ sysfs_put(bitmap->sysfs_can_clear);
+
if (mddev_is_clustered(bitmap->mddev) && bitmap->mddev->cluster_info &&
bitmap->cluster_slot == md_cluster_ops->slot_number(bitmap->mddev))
md_cluster_stop(bitmap->mddev);
@@ -1736,15 +1739,13 @@ void bitmap_destroy(struct mddev *mddev)
if (mddev->thread)
mddev->thread->timeout = MAX_SCHEDULE_TIMEOUT;
- if (bitmap->sysfs_can_clear)
- sysfs_put(bitmap->sysfs_can_clear);
-
bitmap_free(bitmap);
}
/*
* initialize the bitmap structure
* if this returns an error, bitmap_destroy must be called to do clean up
+ * once mddev->bitmap is set
*/
struct bitmap *bitmap_create(struct mddev *mddev, int slot)
{
@@ -1889,8 +1890,10 @@ int bitmap_copy_from_slot(struct mddev *mddev, int slot,
struct bitmap_counts *counts;
struct bitmap *bitmap = bitmap_create(mddev, slot);
- if (IS_ERR(bitmap))
+ if (IS_ERR(bitmap)) {
+ bitmap_free(bitmap);
return PTR_ERR(bitmap);
+ }
rv = bitmap_init_from_disk(bitmap, 0);
if (rv)
@@ -2223,14 +2226,14 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
else {
mddev->bitmap = bitmap;
rv = bitmap_load(mddev);
- if (rv) {
- bitmap_destroy(mddev);
+ if (rv)
mddev->bitmap_info.offset = 0;
- }
}
mddev->pers->quiesce(mddev, 0);
- if (rv)
+ if (rv) {
+ bitmap_destroy(mddev);
return rv;
+ }
}
}
}
--
2.6.2
^ permalink raw reply related
* Re: Probable bug in md with rdev->new_data_offset
From: Étienne Buira @ 2016-04-01 6:15 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <877fghrj2n.fsf@notabene.neil.brown.name>
On Fri, Apr 01, 2016 at 04:31:28PM +1100, NeilBrown wrote:
> On Tue, Mar 29 2016, Étienne Buira wrote:
../..
>
> I guess sb->new_offset should be called sb->delta_offset. If you look
> in md_p.h you will see:
>
> __le32 new_offset; /* signed number to add to data_offset in new
> * layout. 0 == no-change. This can be
> * different on each device in the array.
> */
>
> which goes some way to explaining the situation.
>
> NeilBrown
Hi Neil,
Thank you for the explanation, i have also looked at the sb loading
counterpart, and indeed, PAX did catch a false positive here.
For the record, the bug have been reported on Gentoo bugtracker [1].
[1] https://bugs.gentoo.org/show_bug.cgi?id=578502
Regards.
--
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: Probable bug in md with rdev->new_data_offset
From: NeilBrown @ 2016-04-01 5:31 UTC (permalink / raw)
To: Étienne Buira, linux-raid
In-Reply-To: <20160329110750.GA2529@rcKGHUlyQfVFW>
[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]
On Tue, Mar 29 2016, Étienne Buira wrote:
> Sorry, forgot to reply to list as well, resending for completeness.
>
> On Mon, Mar 28, 2016 at 08:19:12AM -0400, Phil Turmel wrote:
>> On 03/28/2016 06:31 AM, Étienne Buira wrote:
>
> ../..
>
>> > After printking the values for rdev->new_data_offset and
>> > rdev->data_offset in the
>> > if (rdev->new_data_offset != rdev->data_offset) { ...
>> > block of super_1_sync, i found that new_data_offset (252928 in my case)
>> > where smaller than data_offset (258048), thus, the substraction to
>> > compute sb->new_data_offset yielded an insanely high value.
>>
>> Modern mdadm and kernels avoid the use of backup files by adjusting the
>> data offset. The lowered offset you see is normal.
>>
>> I suspect the grsecurity kernels haven't kept up with this. If you can
>> reproduce a problem with a vanilla kernel, please report back here.
>> Otherwise you'll have to report to your kernel provider.
>>
>> Phil
>
> Hi,
>
> Thank you for the answer.
>
> I tried to reproduce the case with vanilla 4.4.6, but couldn't enter the
> above said 'if', so i'm giving up on this topic.
>
> However, i'm still surprised that sb->new_offset gets assigned a
> 'negative' (well, high, because it is computed unsigned) value.
>
I guess sb->new_offset should be called sb->delta_offset. If you look
in md_p.h you will see:
__le32 new_offset; /* signed number to add to data_offset in new
* layout. 0 == no-change. This can be
* different on each device in the array.
*/
which goes some way to explaining the situation.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: Recovery after failed chunk size change
From: NeilBrown @ 2016-04-01 5:25 UTC (permalink / raw)
To: Benjamin Meier, linux-raid
In-Reply-To: <56FD7B92.1030102@ferienwohnung-altenbeken.de>
[-- Attachment #1: Type: text/plain, Size: 2869 bytes --]
On Fri, Apr 01 2016, Benjamin Meier wrote:
> Hi there,
>
> I tried to do a chunk size change from 4096k to 64k on a 7-disk RAID6
> array. I am using Debian Jessie with kernel 3.16 and mdadm 3.3.2. After
> I initiated the change the process staled immediately. I could watch it
> in /proc/mdadm that there has not been any progress at all. The
> backup-file hasn't been touched for days now.
>
> So I decided to backup all data from that device in case it isn't
> starting at next reboot. Accidentally the system was restarted before
> the backup was finished. And now the array is not assembling any more,
> even with the correct --backup-file. I get "mdadm: Failed to restore
> critical section for reshape, sorry.".
>
> So the first question is: How can I access the data again? I think there
> is no damage at this time- I appended an output from --examine at the
> end of this message. All seven drives giving me the same output in all
> relevant topics. Especially "Chunk Size", "New Chunksize" and "Reshape
> pos'n" is all the same.
> What is the best way now that I do not damage any data?
mdadm --assemble --force --update=revert-reshape --invalid-backup
--backup-file=/whatever /dev/md/TA /dev/list-of-devices
using mdadm 3.4.
>
> Second question: Is the problem with the level change a known bug?
Yes, this has been happening to a few people. The shape doesn't really
start properly.
If someone can provide a recipe for how to reproduce the problem
(e.g. using loop-back devices) I'll happily look into fixing it, or
identifying which kernel it is already fixed in.
Neilbrown
>
> Thanks for reading!
>
> --
> /dev/disk/by-partlabel/hyper_TA_1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x5
> Name : hyper:TA (local to host hyper)
> Raid Level : raid6
> Raid Devices : 7
>
> Avail Dev Size : 3434725376 (1637.80 GiB 1758.58 GB)
> Array Size : 8586813440 (8189.02 GiB 8792.90 GB)
> Data Offset : 147456 sectors
> Super Offset : 8 sectors
> Unused Space : before=147368 sectors, after=0 sectors
> State : clean
>
> Internal Bitmap : 8 sectors from superblock
> Reshape pos'n : 0
> New Chunksize : 64K
>
> Update Time : Thu Mar 31 17:57:01 2016
> Bad Block Log : 512 entries available at offset 72 sectors
> Checksum : e7172c1f - correct
> Events : 527046
>
> Layout : left-symmetric
> Chunk Size : 4096K
>
> Device Role : Active device 5
> Array State : AAAAAAA ('A' == active, '.' == missing, 'R' == replacing)
>
> --
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: Bug#796624: mdadm: Has init script in runlevel S but no matching service file
From: Dimitri John Ledkov @ 2016-03-31 22:53 UTC (permalink / raw)
To: Jes Sorensen, 796624; +Cc: Felipe Sateler, linux-raid@vger.kernel.org
In-Reply-To: <wrfjegaq8nry.fsf@redhat.com>
On 31 March 2016 at 20:12, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> Felipe Sateler <fsateler@debian.org> writes:
>> Hello upstream mdadm.
>>
>> I'm adding you to CC to resolve the issue of an init script that
>> current debian uses, that might possibly be redundant. Please see my
>> below diagnosis
>>
>> On 24 December 2015 at 16:10, Felipe Sateler <fsateler@debian.org> wrote:
>>>
>>> On Sat, 22 Aug 2015 22:32:00 -0300 fsateler@debian.org wrote:
>>> > Hi,
>>> >
>>> > Your package mdadm has an initscript that is enabled in runlevel S,
>>> > but it does not provide a corresponding systemd service unit.
>>>
>>> It seems that the mdadm-raid init script (which triggered this bug
>>> report) is not useful on a udev system (which all systemd systems
>>> are[1]). The file /lib/udev/rules.d/64-md-raid-assembly.rules assembles
>>> the arrays incrementally as devices are known to udev, and so running
>>> a separate assembly step should be superfluous. If this is not true,
>>> then maybe this should be reported upstream, as there is a systemd
>>> service missing.
>>
>> For reference, the init script in question can be seen in the souces
>> site[1]. On boot, it invokes mdadm --assemble and reports some status
>> messages for each md device.
>>
>> So, the questions are: is this init script redundant on a udev system?
>> If not, isn't an equivalent systemd unit missing upstream?
>
> I haven't looked at Debian's scripts here, but whatever Debian uses as
> init scripts to control mdadm startup is decided by the Debian mdadm
> maintainer. We do carry a set of system files for mdadm in the
> mdadm/systemd directory, so if something is missing, it may be that the
> Debian maintainer forgot to include it.
>
In Debian we have multiple configuration that we support:
* initramfs-tools based initrd without udev
* initramfs-tools based initrd with udev
* regular userspace with systemd
* regular userspace without systemd (sysv init based, with udev)
I believe some of the initscripts are specific to second & last cases,
and indeed quite debian (and debian derivatives) specific rather than
upstream worthy.
In the udev present and systemd available cases packaging is (or
should be trying to anyway) to follow upstream set of units/udev
rules.
But due to supporting the two extra cases listed above we have
initscripts without equivalent systemd unit, whichi imho should be
just fine. If there is a problem with that, I don't see a reason to
report it to mdadm upstream / linux-raid mailing list...
Apart from aesthetics, is there an actual problem with shipping extra
initscripts on debian?
--
Regards,
Dimitri.
^ permalink raw reply
* [PATCH v2] Consistent use of metric prefix in manpage
From: Marko Hauptvogel @ 2016-03-31 22:21 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-raid
In-Reply-To: <wrfjio028nxk.fsf@redhat.com>
On 31.03.2016 21:09, Jes Sorensen wrote:
> Marko Hauptvogel <marko.hauptvogel@googlemail.com> writes:
>> > From: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
>> >
>> > Added the optional K suffix for completeness, as it
>> > is allowed by util.c's parse_size(char*).
>> >
>> > Signed-off-by: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
> I am not very much in favor of this patch. Any normal sane person still
> refers to megabytes and kilobytes as referring to 1024 base sizes,
> despite the pointless standard trying to mess them up to accommodate the
> harddrive vendors. Nobody normal knows what a kibibyte is.
>
> Jes
>
I am fine either way, but it should be used consistently throughout the man page. The mix up was what made me cringe.
Greetings
--------
From eaad00be960ff1d60861cba75cc7e5eb07f7e330 Mon Sep 17 00:00:00 2001
From: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
Date: Fri, 1 Apr 2016 00:13:44 +0200
Subject: [PATCH] Consistent use of metric prefix in manpage
Added the optional K suffix for completeness, as it
is allowed by util.c's parse_size(char*).
Signed-off-by: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
---
mdadm.8.in | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/mdadm.8.in b/mdadm.8.in
index 50be1aa..1a04bd1 100644
--- a/mdadm.8.in
+++ b/mdadm.8.in
@@ -459,7 +459,7 @@ number of spare devices.
.TP
.BR \-z ", " \-\-size=
-Amount (in Kibibytes) of space to use from each drive in RAID levels 1/4/5/6.
+Amount (in Kilobytes) of space to use from each drive in RAID levels 1/4/5/6.
This must be a multiple of the chunk size, and must leave about 128Kb
of space at the end of the drive for the RAID superblock.
If this is not specified
@@ -467,7 +467,7 @@ If this is not specified
size, though if there is a variance among the drives of greater than 1%, a warning is
issued.
-A suffix of 'M' or 'G' can be given to indicate Megabytes or
+A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
Gigabytes respectively.
Sometimes a replacement drive can be a little smaller than the
@@ -534,7 +534,7 @@ problems the array can be made bigger again with no loss with another
.B "\-\-grow \-\-array\-size="
command.
-A suffix of 'M' or 'G' can be given to indicate Megabytes or
+A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
Gigabytes respectively.
A value of
.B max
@@ -543,7 +543,7 @@ amount of available space is.
.TP
.BR \-c ", " \-\-chunk=
-Specify chunk size of kibibytes. The default when creating an
+Specify chunk size of kilobytes. The default when creating an
array is 512KB. To ensure compatibility with earlier versions, the
default when building an array with no persistent metadata is 64KB.
This is only meaningful for RAID0, RAID4, RAID5, RAID6, and RAID10.
@@ -551,7 +551,7 @@ This is only meaningful for RAID0, RAID4, RAID5, RAID6, and RAID10.
RAID4, RAID5, RAID6, and RAID10 require the chunk size to be a power
of 2. In any case it must be a multiple of 4KB.
-A suffix of 'M' or 'G' can be given to indicate Megabytes or
+A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
Gigabytes respectively.
.TP
@@ -737,7 +737,7 @@ When using an
bitmap, the chunksize defaults to 64Meg, or larger if necessary to
fit the bitmap into the available space.
-A suffix of 'M' or 'G' can be given to indicate Megabytes or
+A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
Gigabytes respectively.
.TP
@@ -808,7 +808,8 @@ an array which was originally created using a different version of
which computed a different offset.
Setting the offset explicitly over-rides the default. The value given
-is in Kilobytes unless an 'M' or 'G' suffix is given.
+is in Kilobytes unless a suffix of 'K', 'M' or 'G' is used to explicitly
+indicate Kilobytes, Megabytes or Gigabytes respectively.
Since Linux 3.4,
.B \-\-data\-offset
--
2.8.0
^ permalink raw reply related
* Re: mdadm: Has init script in runlevel S but no matching service file
From: Felipe Sateler @ 2016-03-31 19:43 UTC (permalink / raw)
To: Jes Sorensen; +Cc: 796624, linux-raid
In-Reply-To: <wrfjegaq8nry.fsf@redhat.com>
Hi,
On 31 March 2016 at 16:12, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> Felipe Sateler <fsateler@debian.org> writes:
>> Hello upstream mdadm.
>>
>> I'm adding you to CC to resolve the issue of an init script that
>> current debian uses, that might possibly be redundant. Please see my
>> below diagnosis
>>
>> On 24 December 2015 at 16:10, Felipe Sateler <fsateler@debian.org> wrote:
>>>
>>> On Sat, 22 Aug 2015 22:32:00 -0300 fsateler@debian.org wrote:
>>> > Hi,
>>> >
>>> > Your package mdadm has an initscript that is enabled in runlevel S,
>>> > but it does not provide a corresponding systemd service unit.
>>>
>>> It seems that the mdadm-raid init script (which triggered this bug
>>> report) is not useful on a udev system (which all systemd systems
>>> are[1]). The file /lib/udev/rules.d/64-md-raid-assembly.rules assembles
>>> the arrays incrementally as devices are known to udev, and so running
>>> a separate assembly step should be superfluous. If this is not true,
>>> then maybe this should be reported upstream, as there is a systemd
>>> service missing.
>>
>> For reference, the init script in question can be seen in the souces
>> site[1]. On boot, it invokes mdadm --assemble and reports some status
>> messages for each md device.
>>
>> So, the questions are: is this init script redundant on a udev system?
>> If not, isn't an equivalent systemd unit missing upstream?
>
> I haven't looked at Debian's scripts here, but whatever Debian uses as
> init scripts to control mdadm startup is decided by the Debian mdadm
> maintainer. We do carry a set of system files for mdadm in the
> mdadm/systemd directory, so if something is missing, it may be that the
> Debian maintainer forgot to include it.
I may have been a bit unclear, and omitted important information. The
systemd units are in fact shipped by mdadm:
mdadm: /lib/systemd/system-shutdown/mdadm.shutdown
mdadm: /lib/systemd/system/mdadm-grow-continue@.service
mdadm: /lib/systemd/system/mdadm-last-resort@.service
mdadm: /lib/systemd/system/mdadm-last-resort@.timer
mdadm: /lib/systemd/system/mdadm-waitidle.service
mdadm: /lib/systemd/system/mdadm.service
mdadm: /lib/systemd/system/mdmon@.service
mdadm: /lib/systemd/system/mdmonitor.service
mdadm.service and mdadm-waitidle.service are symlinks to /dev/null, to
mask the (debian-specific) sysv init scripts. However, there is still
one init script left that is not masked. This init script calls mdadm
--assemble --scan --auto=yes --symlink=no (and a bit more, full script
linked in the original message). None of the upstream units invoke
mdadm --assemble, probably because the udev rules assemble the arrays
incrementally via mdadm --incremental.
....
But now that I reviewed the rules file again, I find that the rules
are modified in debian to disable the incremental assembly. So, the
script would still be needed, but due to a deviation from upstream.
This discussion should then continue on the debian bug report only.
Thanks and sorry for the noise.
--
Saludos,
Felipe Sateler
^ permalink raw reply
* Recovery after failed chunk size change
From: Benjamin Meier @ 2016-03-31 19:33 UTC (permalink / raw)
To: linux-raid
Hi there,
I tried to do a chunk size change from 4096k to 64k on a 7-disk RAID6
array. I am using Debian Jessie with kernel 3.16 and mdadm 3.3.2. After
I initiated the change the process staled immediately. I could watch it
in /proc/mdadm that there has not been any progress at all. The
backup-file hasn't been touched for days now.
So I decided to backup all data from that device in case it isn't
starting at next reboot. Accidentally the system was restarted before
the backup was finished. And now the array is not assembling any more,
even with the correct --backup-file. I get "mdadm: Failed to restore
critical section for reshape, sorry.".
So the first question is: How can I access the data again? I think there
is no damage at this time- I appended an output from --examine at the
end of this message. All seven drives giving me the same output in all
relevant topics. Especially "Chunk Size", "New Chunksize" and "Reshape
pos'n" is all the same.
What is the best way now that I do not damage any data?
Second question: Is the problem with the level change a known bug?
Thanks for reading!
--
/dev/disk/by-partlabel/hyper_TA_1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x5
Name : hyper:TA (local to host hyper)
Raid Level : raid6
Raid Devices : 7
Avail Dev Size : 3434725376 (1637.80 GiB 1758.58 GB)
Array Size : 8586813440 (8189.02 GiB 8792.90 GB)
Data Offset : 147456 sectors
Super Offset : 8 sectors
Unused Space : before=147368 sectors, after=0 sectors
State : clean
Internal Bitmap : 8 sectors from superblock
Reshape pos'n : 0
New Chunksize : 64K
Update Time : Thu Mar 31 17:57:01 2016
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : e7172c1f - correct
Events : 527046
Layout : left-symmetric
Chunk Size : 4096K
Device Role : Active device 5
Array State : AAAAAAA ('A' == active, '.' == missing, 'R' == replacing)
^ permalink raw reply
* Re: mdadm: Has init script in runlevel S but no matching service file
From: Jes Sorensen @ 2016-03-31 19:12 UTC (permalink / raw)
To: Felipe Sateler; +Cc: 796624, linux-raid
In-Reply-To: <CAAfdZj8eoXxr_fU8OU+G2S1s4RnJrTB7fAtLxwwtsjeN+BXj=g@mail.gmail.com>
Felipe Sateler <fsateler@debian.org> writes:
> Hello upstream mdadm.
>
> I'm adding you to CC to resolve the issue of an init script that
> current debian uses, that might possibly be redundant. Please see my
> below diagnosis
>
> On 24 December 2015 at 16:10, Felipe Sateler <fsateler@debian.org> wrote:
>>
>> On Sat, 22 Aug 2015 22:32:00 -0300 fsateler@debian.org wrote:
>> > Hi,
>> >
>> > Your package mdadm has an initscript that is enabled in runlevel S,
>> > but it does not provide a corresponding systemd service unit.
>>
>> It seems that the mdadm-raid init script (which triggered this bug
>> report) is not useful on a udev system (which all systemd systems
>> are[1]). The file /lib/udev/rules.d/64-md-raid-assembly.rules assembles
>> the arrays incrementally as devices are known to udev, and so running
>> a separate assembly step should be superfluous. If this is not true,
>> then maybe this should be reported upstream, as there is a systemd
>> service missing.
>
> For reference, the init script in question can be seen in the souces
> site[1]. On boot, it invokes mdadm --assemble and reports some status
> messages for each md device.
>
> So, the questions are: is this init script redundant on a udev system?
> If not, isn't an equivalent systemd unit missing upstream?
I haven't looked at Debian's scripts here, but whatever Debian uses as
init scripts to control mdadm startup is decided by the Debian mdadm
maintainer. We do carry a set of system files for mdadm in the
mdadm/systemd directory, so if something is missing, it may be that the
Debian maintainer forgot to include it.
Jes
^ permalink raw reply
* Re: [PATCH] Consistent use of IEC 80000-13 prefix in manpage
From: Jes Sorensen @ 2016-03-31 19:09 UTC (permalink / raw)
To: Marko Hauptvogel; +Cc: linux-raid
In-Reply-To: <56FC2DAA.2020605@googlemail.com>
Marko Hauptvogel <marko.hauptvogel@googlemail.com> writes:
> From: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
>
> Added the optional K suffix for completeness, as it
> is allowed by util.c's parse_size(char*).
>
> Signed-off-by: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
I am not very much in favor of this patch. Any normal sane person still
refers to megabytes and kilobytes as referring to 1024 base sizes,
despite the pointless standard trying to mess them up to accommodate the
harddrive vendors. Nobody normal knows what a kibibyte is.
Jes
> ---
> mdadm.8.in | 21 +++++++++++----------
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/mdadm.8.in b/mdadm.8.in
> index 50be1aa..80b0826 100644
> --- a/mdadm.8.in
> +++ b/mdadm.8.in
> @@ -467,8 +467,8 @@ If this is not specified
> size, though if there is a variance among the drives of greater than
> 1%, a warning is
> issued.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> -Gigabytes respectively.
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
> Mebibytes or
> +Gibibytes respectively.
>
> Sometimes a replacement drive can be a little smaller than the
> original drives though this should be minimised by IDEMA standards.
> @@ -534,8 +534,8 @@ problems the array can be made bigger again with no
> loss with another
> .B "\-\-grow \-\-array\-size="
> command.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> -Gigabytes respectively.
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
> Mebibytes or
> +Gibibytes respectively.
> A value of
> .B max
> restores the apparent size of the array to be whatever the real
> @@ -551,8 +551,8 @@ This is only meaningful for RAID0, RAID4, RAID5,
> RAID6, and RAID10.
> RAID4, RAID5, RAID6, and RAID10 require the chunk size to be a power
> of 2. In any case it must be a multiple of 4KB.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> -Gigabytes respectively.
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
> Mebibytes or
> +Gibibytes respectively.
>
> .TP
> .BR \-\-rounding=
> @@ -729,7 +729,7 @@ beneficial. This can be suppressed with
> .TP
> .BR \-\-bitmap\-chunk=
> Set the chunksize of the bitmap. Each bit corresponds to that many
> -Kilobytes of storage.
> +Kibibytes of storage.
> When using a file based bitmap, the default is to use the smallest
> size that is at-least 4 and requires no more than 2^21 chunks.
> When using an
> @@ -737,8 +737,8 @@ When using an
> bitmap, the chunksize defaults to 64Meg, or larger if necessary to
> fit the bitmap into the available space.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> -Gigabytes respectively.
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
> Mebibytes or
> +Gibibytes respectively.
>
> .TP
> .BR \-W ", " \-\-write\-mostly
> @@ -808,7 +808,8 @@ an array which was originally created using a
> different version of
> which computed a different offset.
>
> Setting the offset explicitly over-rides the default. The value given
> -is in Kilobytes unless an 'M' or 'G' suffix is given.
> +is in Kibibytes unless a suffix of 'K', 'M' or 'G' is given to indicate
> +Kibibytes, Mebibytes or Gibibytes respectively.
>
> Since Linux 3.4,
> .B \-\-data\-offset
^ permalink raw reply
* To Your Attention
From: Elder I Frank @ 2016-03-31 13:30 UTC (permalink / raw)
To: Recipients
To Your Attention,
On behalf of the board and management of International Monetary Committees it was resolved by the federal executive council and agreed that your Inheritance/Contract Fund valued at $10.5M would be released to you via DIPLOMATIC CHANNEL immediately your attention is received so you are advice to confirm the following information.send your reply to: elderifrank@gmail.com
Your Name,===============
Address,===================
Next of kin.==============
Your Occupation=============
A scanned copy of your ID or passport.=============
Direct TelePhone Number===================
Regards
Elder Idris Frank
Federal Ministry of Finance
Email:elderifrank@gmail.com
^ permalink raw reply
* Re: mdadm: Has init script in runlevel S but no matching service file
From: Felipe Sateler @ 2016-03-31 13:08 UTC (permalink / raw)
To: 796624, linux-raid
In-Reply-To: <CAAfdZj_hDJOS2-Q9BchbnBhsprUOn_EmftGLXR-t_b7BOidUYw@mail.gmail.com>
Hello upstream mdadm.
I'm adding you to CC to resolve the issue of an init script that
current debian uses, that might possibly be redundant. Please see my
below diagnosis
On 24 December 2015 at 16:10, Felipe Sateler <fsateler@debian.org> wrote:
>
> On Sat, 22 Aug 2015 22:32:00 -0300 fsateler@debian.org wrote:
> > Hi,
> >
> > Your package mdadm has an initscript that is enabled in runlevel S,
> > but it does not provide a corresponding systemd service unit.
>
> It seems that the mdadm-raid init script (which triggered this bug
> report) is not useful on a udev system (which all systemd systems
> are[1]). The file /lib/udev/rules.d/64-md-raid-assembly.rules assembles
> the arrays incrementally as devices are known to udev, and so running
> a separate assembly step should be superfluous. If this is not true,
> then maybe this should be reported upstream, as there is a systemd
> service missing.
For reference, the init script in question can be seen in the souces
site[1]. On boot, it invokes mdadm --assemble and reports some status
messages for each md device.
So, the questions are: is this init script redundant on a udev system?
If not, isn't an equivalent systemd unit missing upstream?
[1] http://sources.debian.net/src/mdadm/3.4-1/debian/mdadm-raid/
--
Saludos,
Felipe Sateler
^ permalink raw reply
* Fwd: Urgent- Quotations Needed
From: Nethaji road @ 2016-03-31 7:59 UTC (permalink / raw)
In-Reply-To: <243313206.418853.1459409843137.JavaMail.root@muthoottumini.com>
Dear Sir,
FYI kindly send us proforma ASAP for the attached purchase order.
Thanks
Carmen Rodriguez
^ permalink raw reply
* Re: Raid 6 failing to assemble after machine power loss now, with 1 disk only failed, seems to think its a raid0 array
From: Adam Goryachev @ 2016-03-31 7:01 UTC (permalink / raw)
To: Peter Knight, Phil Turmel; +Cc: linux-raid
In-Reply-To: <CAAgcXJFm=c8kGBrvnoHYOTmpV42_gb+0yRvSNN7p-U-Q7Y_OCg@mail.gmail.com>
Try the following:
mdadm --stop /dev/md126
Check /proc/mdstat and make sure there is nothing there
Check dmesg output and note the last line, you will need to paste
everything after this line into your next email
madam --assemble /dev/md126 /dev/sd[abcdef]1
Adjust the devices listed above as applicable
Post the output of the above command, the dmesg output, and also
/proc/mdstat afterwards.
You can also try stopping the array/clearing it again, and then try
adding --force to the above command. Make sure to post the results.
Regards,
Adam
On 31/03/2016 17:09, Peter Knight wrote:
> Thank you for the reply Phil.
>
> Unfortunately that didn't work, I get the following message:
>
>
> root@Wheal-Peevor:~# mdadm --run /dev/md126
> mdadm: failed to start array /dev/md126: Input/output error
>
>
> Thanks
>
> Peter
>
> On 30 March 2016 at 23:17, Phil Turmel <philip@turmel.org> wrote:
>> On 03/30/2016 05:19 PM, Peter Knight wrote:
>>> Hi,
>>>
>>> I hope someone can explain what is going on and hopefully help me
>>> recover my data.
>>> What is causing this? and how can I get it reassembled so I can read the data?
>> When mdadm assembles an array during boot that has fewer devices than
>> when it was last shut down (cleanly), it generally declines to start it.
>>
>> Probably, all you need is:
>>
>> mdadm --run /dev/md126
>>
>> { --detail may not be accurate on an inactive device. The member
>> --examine data is trustworthy. }
>>
>> 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: Raid 6 failing to assemble after machine power loss now, with 1 disk only failed, seems to think its a raid0 array
From: Peter Knight @ 2016-03-31 6:09 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <56FC5060.4020502@turmel.org>
Thank you for the reply Phil.
Unfortunately that didn't work, I get the following message:
root@Wheal-Peevor:~# mdadm --run /dev/md126
mdadm: failed to start array /dev/md126: Input/output error
Thanks
Peter
On 30 March 2016 at 23:17, Phil Turmel <philip@turmel.org> wrote:
> On 03/30/2016 05:19 PM, Peter Knight wrote:
>> Hi,
>>
>> I hope someone can explain what is going on and hopefully help me
>> recover my data.
>
>> What is causing this? and how can I get it reassembled so I can read the data?
>
> When mdadm assembles an array during boot that has fewer devices than
> when it was last shut down (cleanly), it generally declines to start it.
>
> Probably, all you need is:
>
> mdadm --run /dev/md126
>
> { --detail may not be accurate on an inactive device. The member
> --examine data is trustworthy. }
>
> Phil
^ permalink raw reply
* Re: Unable to handle kernel NULL pointer dereference in super_written
From: Xiao Ni @ 2016-03-31 3:30 UTC (permalink / raw)
To: shli; +Cc: linux-raid, Jes Sorensen, Neil Brown
In-Reply-To: <56FC0C77.7000006@gmail.com>
----- Original Message -----
> From: "Shaohua Li" <shlikernel@gmail.com>
> To: "Xiao Ni" <xni@redhat.com>, "Shaohua Li" <shli@kernel.org>
> Cc: "linux-raid" <linux-raid@vger.kernel.org>, "Jes Sorensen" <Jes.Sorensen@redhat.com>, "Neil Brown" <neilb@suse.de>
> Sent: Thursday, March 31, 2016 1:27:19 AM
> Subject: Re: Unable to handle kernel NULL pointer dereference in super_written
>
>
>
> On 03/30/2016 12:44 AM, Xiao Ni wrote:
> >
> > ----- Original Message -----
> >> From: "Shaohua Li" <shli@kernel.org>
> >> To: "Xiao Ni" <xni@redhat.com>
> >> Cc: "linux-raid" <linux-raid@vger.kernel.org>, "Jes Sorensen"
> >> <Jes.Sorensen@redhat.com>, "Neil Brown" <neilb@suse.de>
> >> Sent: Wednesday, March 30, 2016 5:37:31 AM
> >> Subject: Re: Unable to handle kernel NULL pointer dereference in
> >> super_written
> >>
> >> On Tue, Mar 29, 2016 at 08:22:00AM -0400, Xiao Ni wrote:
> >>> Hi all
> >>>
> >>> I encountered one NULL pointer dereference problem.
> >>>
> >>> The environment：
> >>> latest linux-stable and mdadm codes
> >>> aarch64 platform
> >>> the md device is created with loop devices
> >>>
> >>> It's a test case to check date integrity. I added the test script as the
> >>> attachment.
> >> Could you please try this patch:
> > Thanks for the patch, I'm running test and will give the result. It need to
> > run
> > more than 300 iterations to reproduce this.
Hi Shaohua
The test have run for more than 1000 times. The patch fixed the bug.
> >
> >>
> >> From b86d9e1724184c79ad1ea63901aec802492b861c Mon Sep 17 00:00:00 2001
> >> Message-Id:
> >> <b86d9e1724184c79ad1ea63901aec802492b861c.1459285706.git.shli@fb.com>
> >> From: Shaohua Li <shli@fb.com>
> >> Date: Tue, 29 Mar 2016 14:00:19 -0700
> >> Subject: [PATCH] MD: add rdev reference for super write
> >>
> >> md_super_write() and corresponding md_super_wait() generally are called
> >> with reconfig_mutex locked, which prevents disk disappears. There is one
> >> case this rule is broken. write_sb_page of bitmap.c doesn't hold the
> >> mutex. next_active_rdev does increase rdev reference, but it decreases
> >> the reference too early (eg, before IO finish). disk can disappear at
> >> the window. We unconditionally increase rdev reference in
> >> md_super_write() to avoid the race.
> > In the path hot_remove_disk, the write_sb_page is protected by
> > reconfig_mutex.
> > It shouldn't submit bio to the leg which is already set FAULTY. Could you
> > give
> > an example to show how the buy happen?
>
> Not sure if I understand your question correctly, but I try to answer.
> When a disk is reported faulty with md_error we don't immediately remove
> the disk as there is risk for example some IO is running in the rdev. We
> increase rdev reference in every IO and decrease the reference after IO
> finishes. You can find this in raid5.c for example. We only delete the
> rdev after the reference is 0, please see remove_and_add_spares(). So
> it's possible you will find disk with FAULTY set, but it's still in rdev
> list.
I'm sorry that I didn't describe clearly.
I just want to know how the bug happen. At first I just focus my attention
on the hot_remove_disk. I think it shouldn't write superblock to the device
which is already removed by md_kick_rdev_from_array.
I read the comments from the patch and the codes again. Now I think I understand
clearly.
It's because the bitmap_deamon_work->write_page->write_sb_page->md_super_write
which is called by md_check_recovery. It doesn't protected by reconfig_mutex.
So there is a chance that the disk is removed (rdev->mddev = NULL) when the
super io is flighting. Is it right?
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: Raid 6 failing to assemble after machine power loss now, with 1 disk only failed, seems to think its a raid0 array
From: Phil Turmel @ 2016-03-30 22:17 UTC (permalink / raw)
To: Peter Knight, linux-raid
In-Reply-To: <CAAgcXJEgLxSaa7x3YO=CuMXS9hPPfPMiUtebQ4RB4F6dmQPd1g@mail.gmail.com>
On 03/30/2016 05:19 PM, Peter Knight wrote:
> Hi,
>
> I hope someone can explain what is going on and hopefully help me
> recover my data.
> What is causing this? and how can I get it reassembled so I can read the data?
When mdadm assembles an array during boot that has fewer devices than
when it was last shut down (cleanly), it generally declines to start it.
Probably, all you need is:
mdadm --run /dev/md126
{ --detail may not be accurate on an inactive device. The member
--examine data is trustworthy. }
Phil
^ 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