* resize a 'far' RAID10 ?
From: Wolfgang Denk @ 2015-03-24 13:48 UTC (permalink / raw)
To: linux-raid
Hello all,
I am aware that it has been impossible to resize a 'far' RAID10; at
least for v3.4 or so - see for example [1]
Has this restriction been listed in the meantime?
If not: I have swapped disk drives for larger models and would like to
make use of the additional size. Is creating another RAID on the free
space the only available option?
Thanks in advance.
[1] http://www.spinics.net/lists/raid/msg38491.html
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Everything should be made as simple as possible, but not simpler."
- Albert Einstein
^ permalink raw reply
* Re: [PATCH 1/1] Make bm_blocks to match previous semantic
From: Goldwyn Rodrigues @ 2015-03-24 14:27 UTC (permalink / raw)
To: NeilBrown, Guoqing Jiang; +Cc: jgq516, linux-raid
In-Reply-To: <20150321093750.1f8c4075@notabene.brown>
On 03/20/2015 05:37 PM, NeilBrown wrote:
> On Thu, 19 Mar 2015 11:50:05 +0800 Guoqing Jiang <GQJiang@suse.com> wrote:
>
>> Hi Neil,
>>
>> NeilBrown wrote:
>>> On Tue, 17 Mar 2015 10:40:30 +0800 jgq516@gmail.com wrote:
>>>
>>>
>>>> From: Guoqing Jiang <gqjiang@suse.com>
>>>>
>>>> The bm_blocks is modified by commit fe60ce (md/bitmap: use
>>>> sector_div for sector_t divisions), but it makes bm_blocks
>>>> has different value which is changed from like "a/b" to "a%b",
>>>> need to correct this to make sure cluster-md still works.
>>>>
>>>
>>> One of us is confused here.
>>>
>>> This code is trying to find the start of the bitmap relevant to this host in
>>> a table of multiple bitmaps. So it first needs to find out the size of each
>>> bitmap. It then multiples the size by the index number of this host to get
>>> an offset.
>>>
>>>
>> Thanks for detailed description, it really helps. I quoted related lines
>> from bitmap.c.
>>
>> 574 sector_t bm_blocks;
>> 575 sector_t resync_sectors =
>> bitmap->mddev->resync_max_sectors;
>> 576
>> 577 bm_blocks = sector_div(resync_sectors,
>> 578
>> bitmap->mddev->bitmap_info.chunksize >> 9);
>> 579 bm_blocks = bm_blocks << 3;
>> 580 bm_blocks = DIV_ROUND_UP_SECTOR_T(bm_blocks, 4096);
>> 581 bitmap->mddev->bitmap_info.offset +=
>> bitmap->cluster_slot * (bm_blocks << 3);
>>
>>> So it take the total number of sectors (resync_max_sectors), divides by the
>>> chunksize (in sectors) to get a number of chunks. This is the number of bits.
>>>
>>>
>> L577 is supposed to do above job.
>>> Then it should div-round-up by 8 to get a number of bytes.
>>>
>> I guess what you mean is about L579, while it used "<<3" rather than
>> ">>3" now.
>>> Then div-round-up by 4096 to get number of 4-K blocks, because the bitmaps
>>> are always 4K aligned.
>>>
>> L580 did the job.
>>> Then this number is multiplied by 8 (or shifted by 3) to get a number of
>>> sectors to add to the start of the table.
>>>
>> L581 is for this, right? Is the shifted by 3 is to match the bitmap
>> format for each
>> nodes? Seems the relationship between slot and the bitmap region of the node
>> is like n <-----> [8*nK, 8*(n+1)K]. How about the following changes?
>>
>> diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
>> index 501f83f..b2a241b 100644
>> --- a/drivers/md/bitmap.c
>> +++ b/drivers/md/bitmap.c
>> @@ -571,12 +571,10 @@ static int bitmap_read_sb(struct bitmap *bitmap)
>> re_read:
>> /* If cluster_slot is set, the cluster is setup */
>> if (bitmap->cluster_slot >= 0) {
>> - sector_t bm_blocks;
>> - sector_t resync_sectors = bitmap->mddev->resync_max_sectors;
>> + sector_t bm_blocks = bitmap->mddev->resync_max_sectors;
>>
>> - bm_blocks = sector_div(resync_sectors,
>> -
>> bitmap->mddev->bitmap_info.chunksize >> 9);
>> - bm_blocks = bm_blocks << 3;
>> + sector_div(bm_blocks,
>> bitmap->mddev->bitmap_info.chunksize >> 9);
>
> Yes, of course. sector_div returns the remainder doesn't it!
> I was thinking that it returned the quotient and set the first arg to the
> remainder - and wonder why you wanted the remainder :-(
>
> I've updated the patch to do the right thing and credited you.
> Thanks.
>
>> + bm_blocks = bm_blocks >> 3;
>> bm_blocks = DIV_ROUND_UP_SECTOR_T(bm_blocks, 4096);
>>> So the original code in commit b97e92574c0bf335db1cd2ec491d8ff5cd5d0b49
>>> is wrong because it uses sector_div in a way which destroys
>>> resync_max_sectors.
>>> And is wrong because it multiplies by 8 (<<3) instead of divides by 8 to
>>> convert from bits to bytes.
>>>
>>> commit f9209a323547f054c7439a3bf67c45e64a054bd
>>> removes the abuse of sector_div, which is good, but uses a simple "a/b"
>>> division, which isn't allowed in the kernel.
>>>
>>> commit fe60ce80488a2a481ac175c4ff98f90df22e1e46
>>> then does the right thing with sector_div, but the "<< 3" is still the wrong
>>> way around.
>>>
>>> If you still think your code is correct, please explain in detail why.
>>>
>>> Goldwyn: if you agree that "<< 3" should be ">> 3" or even
>>> DIV_ROUND_UP_SECTOR_T( , 8);
>>> please send a patch. If you don't think so, please explain why.
>>>
>>>
>> But anyway, it is better wait for Goldwyn's back from vacation, :)
>
> I'll leave the other change (<<3 or >>8) until then.
Yes, you are right. It is working for small bitmaps which were covered
in 1 4k blocks, but was breaking for ones where the bitmap is larger.
It should be (bm_blocks+7) >> 3 or DV_ROUND_UP_SECTOR_T( ,8). Also, it
should account for bitmap_super_t size as well. I will send a patch
shortly to mimic how the userspace tools calculate it.
--
Goldwyn
^ permalink raw reply
* [PATCH] Fix bitmap offset calculations
From: Goldwyn Rodrigues @ 2015-03-24 16:29 UTC (permalink / raw)
To: neilb; +Cc: linux-raid
The calculations of bitmap offset is incorrect with respect to bits to bytes
conversion.
Also, remove an irrelevant duplicate message.
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
---
diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index ac79fef..e98db04 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -575,7 +575,9 @@ re_read:
sector_div(bm_blocks,
bitmap->mddev->bitmap_info.chunksize >> 9);
- bm_blocks = bm_blocks << 3;
+ /* bits to bytes */
+ bm_blocks = ((bm_blocks+7) >> 3) + sizeof(bitmap_super_t);
+ /* to 4k blocks */
bm_blocks = DIV_ROUND_UP_SECTOR_T(bm_blocks, 4096);
bitmap->mddev->bitmap_info.offset += bitmap->cluster_slot * (bm_blocks << 3);
pr_info("%s:%d bm slot: %d offset: %llu\n", __func__, __LINE__,
@@ -672,9 +674,6 @@ out:
goto out_no_sb;
}
bitmap->cluster_slot = md_cluster_ops->slot_number(bitmap->mddev);
- pr_info("%s:%d bm slot: %d offset: %llu\n", __func__, __LINE__,
- bitmap->cluster_slot,
- (unsigned long long)bitmap->mddev->bitmap_info.offset);
goto re_read;
}
^ permalink raw reply related
* Re: [RFC PATCH 0/7] evacuate struct page from the block layer
From: Rik van Riel @ 2015-03-24 16:57 UTC (permalink / raw)
To: Boaz Harrosh, Matthew Wilcox, Andrew Morton
Cc: Dan Williams, linux-kernel, linux-arch, axboe, linux-nvdimm,
Dave Hansen, linux-raid, mgorman, hch, linux-fsdevel,
Michael S. Tsirkin
In-Reply-To: <55113151.7090304@plexistor.com>
On 03/24/2015 05:41 AM, Boaz Harrosh wrote:
> On 03/23/2015 05:19 PM, Rik van Riel wrote:
>> There are two things going on here:
>>
>> 1) You want to keep using struct page for now, while there are
>> subsystems that require it. This is perfectly legitimate.
>>
>> 2) Matthew and Dan are changing over some subsystems to no longer
>> require struct page. This is perfectly legitimate.
>>
>
> How is this legitimate when you need to Interface the [1] subsystems
> under the [2] subsystem? A subsystem that expects pages is now not
> usable by [2].
>
> Today *All* the Kernel subsystems are [1] Period.
That's not true. In the graphics subsystem it is very normal to
mmap graphics memory without ever using a struct page. There are
other callers of remap_pfn_range() too.
In these cases, refcounting is done by keeping a refcount on the
entire object, not on individual pages (since we have none).
> How does it become
> legitimate to now start *two* competing, do the same differently, abstraction,
> in our kernel. We have two much diversity not to little.
We are already able to refcount either the whole object, or an
individual page.
One issue is that not every subsystem can do the whole object
refcounting, and that it would be nice to have the refcounting
done by one single interface.
If we want the code to be the same everywhere, we could achieve
that just as well with an abstraction as with a single data
structure.
Maybe even something as simplistic as these, with the internals
automatically taking and releasing a refcount on the proper object:
get_reference(file, memory_address)
put_reference(file, memory_address)
--
All rights reversed
^ permalink raw reply
* Monitor new badblocks
From: Serge Bartosh @ 2015-03-24 17:30 UTC (permalink / raw)
To: linux-raid
Hello all,
since md started to support of BadBlockList(Log) I'm trying to find
answer to question:
- is there a possibility to get alarm when md discovers new bad blocks?
Please correct me if I'm wrong but I suspect that answer will be "no".
According to man page possible Events are:
DeviceDisappeared, RebuildStarted, RebuildNN, RebuildFinished, Fail,
FailSpare, SpareActive, NewArray, DegradedArray, MoveSpare,
SparesMissing, TestMessage
There is no special event for new badblocks discover and I've checked
today that bad blocks existence is not the reason to mark device "Fail".
I've made experiments with dmsetup simulating "bad surface": even when
new disk containing 90 percents of unusable sectors is added to array md
makes and finishes recover without kicking disk out. Last event is
SpareActive. Syslog does not contain lines about md found bad blocks on
new disk. Array is clean and active.
I understand that manual command "mdadm --examine-badblocks" reveals
such hidden problem.
But is there a way to make "mdadm --monitor" to warn about bad blocks?
PS. System is Debian Jessie RC1
root@linux-test-vb:~# mdadm --version
mdadm - v3.3.2 - 21st August 2014
root@linux-test-vb:~# uname -a
Linux linux-test-vb 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1
(2015-03-01) x86_64 GNU/Linux
root@linux-test-vb:~# cat /etc/debian_version
8.0
PPS. Script used for experiments:
-----8<-----
#!/bin/bash
MDNAME=/dev/md999
DISKSZ=$((64*1024*1024))
#cleanup
echo cleanup
mdadm --stop $MDNAME
dmsetup remove bad_disk4
echo making files and loops
for i in `seq 1 4` ; do
losetup -d /dev/loop$i;
dd if=/dev/zero of=f$i bs=1M count=$((DISKSZ/1024/1024))
losetup /dev/loop$i f$i;
done
echo
echo making faulty disk4 with bb somewhere in the middle...
DEV=/dev/loop4
SECTORS=`blockdev --getsz $DEV` #size in sectors
SECTSZ=`blockdev --getss $DEV` #size of sector
BBPOS=$((SECTORS/2)) #bad block position
BBLEN=$((SECTORS/4)) #bad block region length
echo badblock region from $BBPOS to $((BBPOS+BBLEN)) of $SECTORS
dmsetup create bad_disk4 << EOF
0 $BBPOS linear /dev/loop4 0
$BBPOS $BBLEN error
$((BBPOS+BBLEN)) $((SECTORS-BBLEN-BBPOS)) linear /dev/loop4
$((BBPOS+BBLEN))
EOF
echo
echo making initially degraded raid6
mdadm --create $MDNAME -l 6 -n 4 /dev/loop[123] missing
echo waiting for recover finish...
while [ `cat /sys/block/md999/md/sync_action` != 'idle' ]
do
sleep 1
done
echo adding bb disk
mdadm --add $MDNAME /dev/mapper/bad_disk4
-----8<-----
--
WBR,
Serge Bartosh
^ permalink raw reply
* missing arrays after OS upgrade
From: Daniel Sanabria @ 2015-03-24 22:48 UTC (permalink / raw)
To: linux-raid
Hi,
One of our servers went trough an OS upgrade (from fedora20 to
fedora21) and althou some of the arrays seem to be auto-detected one
of them seem to be missing.
I have some info related to the array in question:
115 /dev/md2:
116 Version : 0.90
117 Creation Time : Mon Feb 11 07:54:36 2013
118 Raid Level : raid5
119 Array Size : 511999872 (488.28 GiB 524.29 GB)
120 Used Dev Size : 255999936 (244.14 GiB 262.14 GB)
121 Raid Devices : 3
122 Total Devices : 3
123 Preferred Minor : 2
124 Persistence : Superblock is persistent
125
126 Update Time : Sun Mar 22 18:23:38 2015
127 State : clean
128 Active Devices : 3
129 Working Devices : 3
130 Failed Devices : 0
131 Spare Devices : 0
132
133 Layout : left-symmetric
134 Chunk Size : 64K
135
136 UUID : 2cff15d1:e411447b:fd5d4721:03e44022 (local to
host lamachine)
137 Events : 0.478
138
139 Number Major Minor RaidDevice State
140 0 8 3 0 active sync /dev/sda3
141 1 8 18 1 active sync /dev/sdb2
142 2 8 34 2 active sync /dev/sdc2
I haven't taken any actions to try to re-assemble the array and wanted
to check for ideas/suggestions here first.
Any advice you might regarding the steps to take to get the array up
and runnign again is higy appreciated.
Thanks in advance,
Daniel
^ permalink raw reply
* Re: missing arrays after OS upgrade
From: Phil Turmel @ 2015-03-25 0:03 UTC (permalink / raw)
To: Daniel Sanabria, linux-raid
In-Reply-To: <CAHscji03jWu3EF0KUG45Hv4Y2t5beJmEoe9uWMfR=wGz_dkBbw@mail.gmail.com>
On 03/24/2015 06:48 PM, Daniel Sanabria wrote:
> Hi,
>
> One of our servers went trough an OS upgrade (from fedora20 to
> fedora21) and althou some of the arrays seem to be auto-detected one
> of them seem to be missing.
You may have had some device names reordered. Building a config that
relies on the names is common but unwise.
With such a thin report, there's not much to go on. Please run lsdrv
[1] and paste its output in a reply.
Then add the contents of /proc/mdstat, the relevant-looking parts of
dmesg, and your mdadm.conf file.
We may need more later, but this will permit intelligent follow-up
questions.
Phil
[1] https://github.com/pturmel/lsdrv
^ permalink raw reply
* MD request counter broken on 4.0-rc5 RAID1
From: Simon Kirby @ 2015-03-25 0:04 UTC (permalink / raw)
To: linux-raid
Hello :)
I'm seeing "iostat -x -k 1" print this after a RAID1 rebuild on 4.0-rc5.
It's not abnormal other than it's 3-disk, with one being SSD (sdc) and
the other two being write-mostly:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 345.00 0.00 0.00 0.00 0.00 100.00
md2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 58779.00 0.00 0.00 0.00 0.00 100.00
md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12.00 0.00 0.00 0.00 0.00 100.00
This was working on 3.18. Shall I bisect, or is it obvious?
It seems to just be leaking as the counters were going up gradually while
it was rebuilding.
Personalities : [linear] [raid0] [raid1] [raid10]
md1 : active raid1 sdb2[1](W) sda2[0](W) sdc2[2]
530048 blocks [3/3] [UUU]
md2 : active raid1 sdb3[0](W) sdc3[2] sda3[1](W)
153613440 blocks [3/3] [UUU]
md0 : active raid1 sdb1[0](W) sdc1[2] sda1[1](W)
2104384 blocks [3/3] [UUU]
unused devices: <none>
Simo-
^ permalink raw reply
* Re: MD request counter broken on 4.0-rc5 RAID1
From: NeilBrown @ 2015-03-25 0:46 UTC (permalink / raw)
To: Simon Kirby; +Cc: linux-raid
In-Reply-To: <20150325000403.GA27368@hostway.ca>
[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]
On Tue, 24 Mar 2015 17:04:03 -0700 Simon Kirby <sim@hostway.ca> wrote:
> Hello :)
>
> I'm seeing "iostat -x -k 1" print this after a RAID1 rebuild on 4.0-rc5.
> It's not abnormal other than it's 3-disk, with one being SSD (sdc) and
> the other two being write-mostly:
>
> Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
> sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
> sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
> sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
> md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 345.00 0.00 0.00 0.00 0.00 100.00
> md2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 58779.00 0.00 0.00 0.00 0.00 100.00
> md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12.00 0.00 0.00 0.00 0.00 100.00
>
> This was working on 3.18. Shall I bisect, or is it obvious?
Almost certainly 18c0b223cf9901727ef3b02da6711ac930b4e5d4 in 3.19.
It adds 'part_inc_in_flight' and never decrements it.
Complain to the author.
Thanks,
NeilBrown
>
> It seems to just be leaking as the counters were going up gradually while
> it was rebuilding.
>
> Personalities : [linear] [raid0] [raid1] [raid10]
> md1 : active raid1 sdb2[1](W) sda2[0](W) sdc2[2]
> 530048 blocks [3/3] [UUU]
>
> md2 : active raid1 sdb3[0](W) sdc3[2] sda3[1](W)
> 153613440 blocks [3/3] [UUU]
>
> md0 : active raid1 sdb1[0](W) sdc1[2] sda1[1](W)
> 2104384 blocks [3/3] [UUU]
>
> unused devices: <none>
>
> Simo-
> --
> 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: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix bitmap offset calculations
From: NeilBrown @ 2015-03-25 2:15 UTC (permalink / raw)
To: Goldwyn Rodrigues; +Cc: linux-raid
In-Reply-To: <20150324162905.GA16104@shrek.lan>
[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]
On Tue, 24 Mar 2015 11:29:05 -0500 Goldwyn Rodrigues <rgoldwyn@suse.de> wrote:
> The calculations of bitmap offset is incorrect with respect to bits to bytes
> conversion.
>
> Also, remove an irrelevant duplicate message.
>
> Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
> ---
> diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
> index ac79fef..e98db04 100644
> --- a/drivers/md/bitmap.c
> +++ b/drivers/md/bitmap.c
> @@ -575,7 +575,9 @@ re_read:
>
> sector_div(bm_blocks,
> bitmap->mddev->bitmap_info.chunksize >> 9);
> - bm_blocks = bm_blocks << 3;
> + /* bits to bytes */
> + bm_blocks = ((bm_blocks+7) >> 3) + sizeof(bitmap_super_t);
> + /* to 4k blocks */
> bm_blocks = DIV_ROUND_UP_SECTOR_T(bm_blocks, 4096);
> bitmap->mddev->bitmap_info.offset += bitmap->cluster_slot * (bm_blocks << 3);
> pr_info("%s:%d bm slot: %d offset: %llu\n", __func__, __LINE__,
> @@ -672,9 +674,6 @@ out:
> goto out_no_sb;
> }
> bitmap->cluster_slot = md_cluster_ops->slot_number(bitmap->mddev);
> - pr_info("%s:%d bm slot: %d offset: %llu\n", __func__, __LINE__,
> - bitmap->cluster_slot,
> - (unsigned long long)bitmap->mddev->bitmap_info.offset);
> goto re_read;
> }
>
Applied, thanks.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* /dev/md0 can't be created
From: Xiao Ni @ 2015-03-25 6:15 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <1215809785.2787621.1427263359309.JavaMail.zimbra@redhat.com>
Hi all
I have encountered so many times, the raid device is created successfully, but the directory
/dev/md0 can't be created. It can't reproduce 100%.
[root@intel-sugarbay-do-01 create_assemble]# cat /proc/mdstat
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid10 loop7[7](S) loop6[6] loop5[5] loop4[4] loop3[3] loop2[2] loop1[1] loop0[0]
1788416 blocks super 1.2 512K chunks 2 near-copies [7/7] [UUUUUUU]
bitmap: 0/1 pages [0KB], 65536KB chunk
unused devices: <none>
[root@intel-sugarbay-do-01 create_assemble]# ls /dev/md0
ls: cannot access /dev/md0: No such file or directory
The underline devices are loop devices which are created with big file.
The kernel I used is RHEL7 (3.10.0-234.el7.x86_64.debug, mdadm - v3.3.2 - 21st August 2014)
I'll try to reproduce this with upstream kernel and mdadm. But I think it shouldn't be the problem about kernel.
What do you think I should check for this? And which tool is responsible for creating the directory? Maybe
I can add some log to it to find the reason.
Best Regards
Xiao
^ permalink raw reply
* Re: /dev/md0 can't be created
From: NeilBrown @ 2015-03-25 6:35 UTC (permalink / raw)
To: Xiao Ni; +Cc: linux-raid
In-Reply-To: <12135556.2792023.1427264134774.JavaMail.zimbra@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]
On Wed, 25 Mar 2015 02:15:34 -0400 (EDT) Xiao Ni <xni@redhat.com> wrote:
> Hi all
>
> I have encountered so many times, the raid device is created successfully, but the directory
> /dev/md0 can't be created. It can't reproduce 100%.
>
> [root@intel-sugarbay-do-01 create_assemble]# cat /proc/mdstat
> Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
> md0 : active raid10 loop7[7](S) loop6[6] loop5[5] loop4[4] loop3[3] loop2[2] loop1[1] loop0[0]
> 1788416 blocks super 1.2 512K chunks 2 near-copies [7/7] [UUUUUUU]
> bitmap: 0/1 pages [0KB], 65536KB chunk
>
> unused devices: <none>
> [root@intel-sugarbay-do-01 create_assemble]# ls /dev/md0
> ls: cannot access /dev/md0: No such file or directory
>
> The underline devices are loop devices which are created with big file.
>
> The kernel I used is RHEL7 (3.10.0-234.el7.x86_64.debug, mdadm - v3.3.2 - 21st August 2014)
> I'll try to reproduce this with upstream kernel and mdadm. But I think it shouldn't be the problem about kernel.
>
> What do you think I should check for this? And which tool is responsible for creating the directory? Maybe
> I can add some log to it to find the reason.
>
/dev/md0 is created by udev.
Run
udevadm monitor
to see the events that udev is processing. When and ADD event for "md0" is
processed, /dev/md0 should get created.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: missing arrays after OS upgrade
From: Daniel Sanabria @ 2015-03-25 11:49 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <5511FB3B.8030607@turmel.org>
Thank you very much Phil,
Below the output of lsdrv followed by /proc/mdstat and mdadm.conf
(will clean up dmesg a bit before attaching it here):
Again, thanks for your input on this,
Daniel
PCI [ahci] 07:00.0 SATA controller: JMicron Technology Corp. JMB363
SATA/IDE Controller (rev 02)
├scsi 0:x:x:x [Empty]
└scsi 1:x:x:x [Empty]
PCI [ata_piix] 00:1f.2 IDE interface: Intel Corporation 82801JI (ICH10
Family) 4 port SATA IDE Controller #1
├scsi 2:0:0:0 ATA WDC WD5000AAKS-0 {WD-WMAWF0085724}
│└sda 465.76g [8:0] Partitioned (dos)
│ ├sda1 199.00m [8:1] ext4 {4e51f903-37ca-4479-9197-fac7b2280557}
│ │└Mounted as /dev/sda1 @ /boot
│ ├sda2 29.30g [8:2] MD raid10,near2 (0/2) (w/ sdc1) in_sync
{9af006ca-8845-bbd3-bfe7-8010bc810f04}
│ │└md126 29.30g [9:126] MD v0.90 raid10,near2 (2) clean, 64k Chunk
{9af006ca:8845bbd3:bfe78010:bc810f04}
│ │ │ PV LVM2_member 28.03g used, 1.26g free
{cE4ePh-RWO8-Wgdy-YPOY-ehyC-KI6u-io1cyH}
│ │ └VG vg_bigblackbox 29.29g 1.26g free
{VWfuwI-5v2q-w8qf-FEbc-BdGW-3mKX-pZd7hR}
│ │ ├dm-6 7.81g [253:6] LV LogVol_opt ext4
{b08d7f5e-f15f-4241-804e-edccecab6003}
│ │ │└Mounted as /dev/mapper/vg_bigblackbox-LogVol_opt @ /opt
│ │ ├dm-0 9.77g [253:0] LV LogVol_root ext4
{4dabd6b0-b1a3-464d-8ed7-0aab93fab6c3}
│ │ │└Mounted as /dev/mapper/vg_bigblackbox-LogVol_root @ /
│ │ ├dm-8 1.95g [253:8] LV LogVol_tmp ext4
{f6b46363-170b-4038-83bd-2c5f9f6a1973}
│ │ │└Mounted as /dev/mapper/vg_bigblackbox-LogVol_tmp @ /tmp
│ │ └dm-4 8.50g [253:4] LV LogVol_var ext4
{ab165c61-3d62-4c55-8639-6c2c2bf4b021}
│ │ └Mounted as /dev/mapper/vg_bigblackbox-LogVol_var @ /var
│ ├sda3 244.14g [8:3] MD raid5 (3) inactive
{2cff15d1-e411-447b-fd5d-472103e44022}
│ ├sda4 1.00k [8:4] Partitioned (dos)
│ ├sda5 30.00g [8:5] MD raid0 (0/3) (w/ sdb5,sdc5) in_sync
'reading.homeunix.com:3' {acd5374f-7262-8c93-6a90-6c4b5f675ce5}
│ │└md124 90.00g [9:124] MD v1.2 raid0 (3) clean, 512k Chunk, None
(None) None {acd5374f:72628c93:6a906c4b:5f675ce5}
│ │ │ PV LVM2_member 86.00g used, 3.99g free
{VmsWRd-8qHt-bauf-lvAn-FC97-KyH5-gk89ox}
│ │ └VG libvirt_lvm 89.99g 3.99g free {t8GQck-f2Eu-iD2V-fnJQ-kBm6-QyKw-dR31PB}
│ │ ├dm-9 8.00g [253:9] LV builder Partitioned (dos)
│ │ ├dm-10 8.00g [253:10] LV builder2 Partitioned (dos)
│ │ ├dm-11 8.00g [253:11] LV builder3 Partitioned (dos)
│ │ ├dm-13 8.00g [253:13] LV builder5.3 Partitioned (dos)
│ │ ├dm-12 8.00g [253:12] LV builder5.6 Partitioned (dos)
│ │ ├dm-5 8.00g [253:5] LV centos_updt Partitioned (dos)
│ │ ├dm-7 8.00g [253:7] LV cms Partitioned (dos)
│ │ └dm-2 30.00g [253:2] LV win7 Partitioned (dos)
│ └sda6 3.39g [8:6] Empty/Unknown
├scsi 2:0:1:0 ATA WDC WD5000AAKS-0 {WD-WCASY7694185}
│└sdb 465.76g [8:16] Partitioned (dos)
│ ├sdb2 244.14g [8:18] MD raid5 (3) inactive
{2cff15d1-e411-447b-fd5d-472103e44022}
│ ├sdb3 7.81g [8:19] swap {9194f492-881a-4fc3-ac09-ca4e1cc2985a}
│ ├sdb4 1.00k [8:20] Partitioned (dos)
│ ├sdb5 30.00g [8:21] MD raid0 (1/3) (w/ sda5,sdc5) in_sync
'reading.homeunix.com:3' {acd5374f-7262-8c93-6a90-6c4b5f675ce5}
│ │└md124 90.00g [9:124] MD v1.2 raid0 (3) clean, 512k Chunk, None
(None) None {acd5374f:72628c93:6a906c4b:5f675ce5}
│ │ PV LVM2_member 86.00g used, 3.99g free
{VmsWRd-8qHt-bauf-lvAn-FC97-KyH5-gk89ox}
│ └sdb6 3.39g [8:22] Empty/Unknown
├scsi 3:0:0:0 ATA WDC WD5000AAKS-0 {WD-WCASZ0505379}
│└sdc 465.76g [8:32] Partitioned (dos)
│ ├sdc1 29.30g [8:33] MD raid10,near2 (1/2) (w/ sda2) in_sync
{9af006ca-8845-bbd3-bfe7-8010bc810f04}
│ │└md126 29.30g [9:126] MD v0.90 raid10,near2 (2) clean, 64k Chunk
{9af006ca:8845bbd3:bfe78010:bc810f04}
│ │ PV LVM2_member 28.03g used, 1.26g free
{cE4ePh-RWO8-Wgdy-YPOY-ehyC-KI6u-io1cyH}
│ ├sdc2 244.14g [8:34] MD raid5 (3) inactive
{2cff15d1-e411-447b-fd5d-472103e44022}
│ ├sdc3 1.00k [8:35] Partitioned (dos)
│ ├sdc5 30.00g [8:37] MD raid0 (2/3) (w/ sda5,sdb5) in_sync
'reading.homeunix.com:3' {acd5374f-7262-8c93-6a90-6c4b5f675ce5}
│ │└md124 90.00g [9:124] MD v1.2 raid0 (3) clean, 512k Chunk, None
(None) None {acd5374f:72628c93:6a906c4b:5f675ce5}
│ │ PV LVM2_member 86.00g used, 3.99g free
{VmsWRd-8qHt-bauf-lvAn-FC97-KyH5-gk89ox}
│ └sdc6 3.39g [8:38] Empty/Unknown
└scsi 3:0:1:0 ATA WDC WD30EZRX-00D {WD-WCC4N1294906}
└sdd 2.73t [8:48] Partitioned (gpt)
├sdd1 2.00t [8:49] MD raid5 (0/3) (w/ sde1,sdf1) in_sync
'lamachine:128' {f2372cb9-d381-6fd6-ce86-d826882ec82e}
│└md127 4.00t [9:127] MD v1.2 raid5 (3) read-auto, 512k Chunk
{f2372cb9:d3816fd6:ce86d826:882ec82e}
│ │ PV LVM2_member 3.50t used, 511.75g free
{NrF3vV-nS1f-wtjY-SfZk-xwUE-YbSB-TWWdLu}
│ └VG vg_media 4.00t 511.75g free {cPGpZK-OdZ6-sW71-8Rtf-x23f-BgEU-WGEmid}
│ └dm-1 3.50t [253:1] LV lv_media ext4 {ef90c386-76e6-4843-a427-88412948d49f}
└sdd2 500.00g [8:50] MD raid0 (0/3) (w/ sde2,sdf2) in_sync
'lamachine:129' {895dae98-d1a4-96de-4f59-0b8bcb8ac12a}
└md125 1.46t [9:125] MD v1.2 raid0 (3) clean, 512k Chunk, None
(None) None {895dae98:d1a496de:4f590b8b:cb8ac12a}
│ PV LVM2_member 512.00g used, 987.62g free
{70aHF7-aTfj-X2y6-qYXF-szQu-QBFW-q4UlfG}
└VG vg_virt_dir 1.46t 987.62g free {SQXqhD-j5dR-Xsdh-NBoR-YMqk-YwfF-hyf9ur}
└dm-3 512.00g [253:3] LV lv_virt_dir1 ext4
{1929e452-ae83-4766-bf0e-8575a7d1a3c8}
PCI [ata_piix] 00:1f.5 IDE interface: Intel Corporation 82801JI (ICH10
Family) 2 port SATA IDE Controller #2
├scsi 4:0:0:0 ATA WDC WD30EZRX-00D {WD-WCC4NCWT13RF}
│└sde 2.73t [8:64] Partitioned (gpt)
│ ├sde1 2.00t [8:65] MD raid5 (1/3) (w/ sdd1,sdf1) in_sync
'lamachine:128' {f2372cb9-d381-6fd6-ce86-d826882ec82e}
│ │└md127 4.00t [9:127] MD v1.2 raid5 (3) read-auto, 512k Chunk
{f2372cb9:d3816fd6:ce86d826:882ec82e}
│ │ PV LVM2_member 3.50t used, 511.75g free
{NrF3vV-nS1f-wtjY-SfZk-xwUE-YbSB-TWWdLu}
│ └sde2 500.00g [8:66] MD raid0 (1/3) (w/ sdd2,sdf2) in_sync
'lamachine:129' {895dae98-d1a4-96de-4f59-0b8bcb8ac12a}
│ └md125 1.46t [9:125] MD v1.2 raid0 (3) clean, 512k Chunk, None
(None) None {895dae98:d1a496de:4f590b8b:cb8ac12a}
│ PV LVM2_member 512.00g used, 987.62g free
{70aHF7-aTfj-X2y6-qYXF-szQu-QBFW-q4UlfG}
└scsi 5:0:0:0 ATA WDC WD30EZRX-00D {WD-WCC4NPRDD6D7}
└sdf 2.73t [8:80] Partitioned (gpt)
├sdf1 2.00t [8:81] MD raid5 (2/3) (w/ sdd1,sde1) in_sync
'lamachine:128' {f2372cb9-d381-6fd6-ce86-d826882ec82e}
│└md127 4.00t [9:127] MD v1.2 raid5 (3) read-auto, 512k Chunk
{f2372cb9:d3816fd6:ce86d826:882ec82e}
│ PV LVM2_member 3.50t used, 511.75g free
{NrF3vV-nS1f-wtjY-SfZk-xwUE-YbSB-TWWdLu}
└sdf2 500.00g [8:82] MD raid0 (2/3) (w/ sdd2,sde2) in_sync
'lamachine:129' {895dae98-d1a4-96de-4f59-0b8bcb8ac12a}
└md125 1.46t [9:125] MD v1.2 raid0 (3) clean, 512k Chunk, None
(None) None {895dae98:d1a496de:4f590b8b:cb8ac12a}
PV LVM2_member 512.00g used, 987.62g free
{70aHF7-aTfj-X2y6-qYXF-szQu-QBFW-q4UlfG}
PCI [pata_jmicron] 07:00.1 IDE interface: JMicron Technology Corp.
JMB363 SATA/IDE Controller (rev 02)
├scsi 6:x:x:x [Empty]
└scsi 7:x:x:x [Empty]
[root@localhost ~]# cat /proc/mdstat
Personalities : [raid10] [raid0] [raid6] [raid5] [raid4]
md124 : active raid0 sda5[0] sdb5[1] sdc5[2]
94367232 blocks super 1.2 512k chunks
md125 : active raid0 sdf2[2] sdd2[0] sde2[1]
1572470784 blocks super 1.2 512k chunks
md127 : active (auto-read-only) raid5 sdf1[3] sde1[1] sdd1[0]
4294705152 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
bitmap: 0/16 pages [0KB], 65536KB chunk
md126 : active raid10 sda2[0] sdc1[1]
30719936 blocks 2 near-copies [2/2] [UU]
unused devices: <none>
[root@localhost ~]# cat /etc/mdadm.conf
# mdadm.conf written out by anaconda
MAILADDR root
AUTO +imsm +1.x -all
ARRAY /dev/md/126 level=raid10 num-devices=2
UUID=9af006ca:8845bbd3:bfe78010:bc810f04
On 25 March 2015 at 00:03, Phil Turmel <philip@turmel.org> wrote:
> On 03/24/2015 06:48 PM, Daniel Sanabria wrote:
>> Hi,
>>
>> One of our servers went trough an OS upgrade (from fedora20 to
>> fedora21) and althou some of the arrays seem to be auto-detected one
>> of them seem to be missing.
>
> You may have had some device names reordered. Building a config that
> relies on the names is common but unwise.
>
> With such a thin report, there's not much to go on. Please run lsdrv
> [1] and paste its output in a reply.
>
> Then add the contents of /proc/mdstat, the relevant-looking parts of
> dmesg, and your mdadm.conf file.
>
> We may need more later, but this will permit intelligent follow-up
> questions.
>
> Phil
>
> [1] https://github.com/pturmel/lsdrv
--
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: missing arrays after OS upgrade
From: Phil Turmel @ 2015-03-25 12:15 UTC (permalink / raw)
To: Daniel Sanabria; +Cc: linux-raid
In-Reply-To: <CAHscji1spYx8vvUQ2=PsU4VRCb4+kOqAstJqyK0SbYJ6=OSYiQ@mail.gmail.com>
Hi Daniel,
{Convention on kernel.org is to trim quotes, then interleave replies or
bottom-post.}
On 03/25/2015 07:49 AM, Daniel Sanabria wrote:
> Thank you very much Phil,
>
> Below the output of lsdrv followed by /proc/mdstat and mdadm.conf
> (will clean up dmesg a bit before attaching it here):
When you do, turn off line wrap. I forgot to suggest that.
> PCI [ahci] 07:00.0 SATA controller: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 02)
> ├scsi 0:x:x:x [Empty]
> └scsi 1:x:x:x [Empty]
> PCI [ata_piix] 00:1f.2 IDE interface: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller #1
> ├scsi 2:0:0:0 ATA WDC WD5000AAKS-0 {WD-WMAWF0085724}
> │└sda 465.76g [8:0] Partitioned (dos)
> │ ├sda1 199.00m [8:1] ext4 {4e51f903-37ca-4479-9197-fac7b2280557}
> │ │└Mounted as /dev/sda1 @ /boot
> │ ├sda2 29.30g [8:2] MD raid10,near2 (0/2) (w/ sdc1) in_sync {9af006ca-8845-bbd3-bfe7-8010bc810f04}
> │ │└md126 29.30g [9:126] MD v0.90 raid10,near2 (2) clean, 64k Chunk {9af006ca:8845bbd3:bfe78010:bc810f04}
> │ │ │ PV LVM2_member 28.03g used, 1.26g free {cE4ePh-RWO8-Wgdy-YPOY-ehyC-KI6u-io1cyH}
> │ │ └VG vg_bigblackbox 29.29g 1.26g free {VWfuwI-5v2q-w8qf-FEbc-BdGW-3mKX-pZd7hR}
> │ │ ├dm-6 7.81g [253:6] LV LogVol_opt ext4 {b08d7f5e-f15f-4241-804e-edccecab6003}
> │ │ │└Mounted as /dev/mapper/vg_bigblackbox-LogVol_opt @ /opt
> │ │ ├dm-0 9.77g [253:0] LV LogVol_root ext4 {4dabd6b0-b1a3-464d-8ed7-0aab93fab6c3}
> │ │ │└Mounted as /dev/mapper/vg_bigblackbox-LogVol_root @ /
> │ │ ├dm-8 1.95g [253:8] LV LogVol_tmp ext4 {f6b46363-170b-4038-83bd-2c5f9f6a1973}
> │ │ │└Mounted as /dev/mapper/vg_bigblackbox-LogVol_tmp @ /tmp
> │ │ └dm-4 8.50g [253:4] LV LogVol_var ext4 {ab165c61-3d62-4c55-8639-6c2c2bf4b021}
> │ │ └Mounted as /dev/mapper/vg_bigblackbox-LogVol_var @ /var
> │ ├sda3 244.14g [8:3] MD raid5 (3) inactive {2cff15d1-e411-447b-fd5d-472103e44022}
> │ ├sda4 1.00k [8:4] Partitioned (dos)
> │ ├sda5 30.00g [8:5] MD raid0 (0/3) (w/ sdb5,sdc5) in_sync 'reading.homeunix.com:3' {acd5374f-7262-8c93-6a90-6c4b5f675ce5}
> │ │└md124 90.00g [9:124] MD v1.2 raid0 (3) clean, 512k Chunk, None (None) None {acd5374f:72628c93:6a906c4b:5f675ce5}
> │ │ │ PV LVM2_member 86.00g used, 3.99g free {VmsWRd-8qHt-bauf-lvAn-FC97-KyH5-gk89ox}
> │ │ └VG libvirt_lvm 89.99g 3.99g free {t8GQck-f2Eu-iD2V-fnJQ-kBm6-QyKw-dR31PB}
> │ │ ├dm-9 8.00g [253:9] LV builder Partitioned (dos)
> │ │ ├dm-10 8.00g [253:10] LV builder2 Partitioned (dos)
> │ │ ├dm-11 8.00g [253:11] LV builder3 Partitioned (dos)
> │ │ ├dm-13 8.00g [253:13] LV builder5.3 Partitioned (dos)
> │ │ ├dm-12 8.00g [253:12] LV builder5.6 Partitioned (dos)
> │ │ ├dm-5 8.00g [253:5] LV centos_updt Partitioned (dos)
> │ │ ├dm-7 8.00g [253:7] LV cms Partitioned (dos)
> │ │ └dm-2 30.00g [253:2] LV win7 Partitioned (dos)
> │ └sda6 3.39g [8:6] Empty/Unknown
> ├scsi 2:0:1:0 ATA WDC WD5000AAKS-0 {WD-WCASY7694185}
> │└sdb 465.76g [8:16] Partitioned (dos)
> │ ├sdb2 244.14g [8:18] MD raid5 (3) inactive {2cff15d1-e411-447b-fd5d-472103e44022}
> │ ├sdb3 7.81g [8:19] swap {9194f492-881a-4fc3-ac09-ca4e1cc2985a}
> │ ├sdb4 1.00k [8:20] Partitioned (dos)
> │ ├sdb5 30.00g [8:21] MD raid0 (1/3) (w/ sda5,sdc5) in_sync 'reading.homeunix.com:3' {acd5374f-7262-8c93-6a90-6c4b5f675ce5}
> │ │└md124 90.00g [9:124] MD v1.2 raid0 (3) clean, 512k Chunk, None (None) None {acd5374f:72628c93:6a906c4b:5f675ce5}
> │ │ PV LVM2_member 86.00g used, 3.99g free {VmsWRd-8qHt-bauf-lvAn-FC97-KyH5-gk89ox}
> │ └sdb6 3.39g [8:22] Empty/Unknown
> ├scsi 3:0:0:0 ATA WDC WD5000AAKS-0 {WD-WCASZ0505379}
> │└sdc 465.76g [8:32] Partitioned (dos)
> │ ├sdc1 29.30g [8:33] MD raid10,near2 (1/2) (w/ sda2) in_sync {9af006ca-8845-bbd3-bfe7-8010bc810f04}
> │ │└md126 29.30g [9:126] MD v0.90 raid10,near2 (2) clean, 64k Chunk {9af006ca:8845bbd3:bfe78010:bc810f04}
> │ │ PV LVM2_member 28.03g used, 1.26g free {cE4ePh-RWO8-Wgdy-YPOY-ehyC-KI6u-io1cyH}
> │ ├sdc2 244.14g [8:34] MD raid5 (3) inactive {2cff15d1-e411-447b-fd5d-472103e44022}
> │ ├sdc3 1.00k [8:35] Partitioned (dos)
> │ ├sdc5 30.00g [8:37] MD raid0 (2/3) (w/ sda5,sdb5) in_sync 'reading.homeunix.com:3' {acd5374f-7262-8c93-6a90-6c4b5f675ce5}
> │ │└md124 90.00g [9:124] MD v1.2 raid0 (3) clean, 512k Chunk, None (None) None {acd5374f:72628c93:6a906c4b:5f675ce5}
> │ │ PV LVM2_member 86.00g used, 3.99g free {VmsWRd-8qHt-bauf-lvAn-FC97-KyH5-gk89ox}
> │ └sdc6 3.39g [8:38] Empty/Unknown
> └scsi 3:0:1:0 ATA WDC WD30EZRX-00D {WD-WCC4N1294906}
> └sdd 2.73t [8:48] Partitioned (gpt)
> ├sdd1 2.00t [8:49] MD raid5 (0/3) (w/ sde1,sdf1) in_sync 'lamachine:128' {f2372cb9-d381-6fd6-ce86-d826882ec82e}
> │└md127 4.00t [9:127] MD v1.2 raid5 (3) read-auto, 512k Chunk {f2372cb9:d3816fd6:ce86d826:882ec82e}
> │ │ PV LVM2_member 3.50t used, 511.75g free {NrF3vV-nS1f-wtjY-SfZk-xwUE-YbSB-TWWdLu}
> │ └VG vg_media 4.00t 511.75g free {cPGpZK-OdZ6-sW71-8Rtf-x23f-BgEU-WGEmid}
> │ └dm-1 3.50t [253:1] LV lv_media ext4 {ef90c386-76e6-4843-a427-88412948d49f}
> └sdd2 500.00g [8:50] MD raid0 (0/3) (w/ sde2,sdf2) in_sync 'lamachine:129' {895dae98-d1a4-96de-4f59-0b8bcb8ac12a}
> └md125 1.46t [9:125] MD v1.2 raid0 (3) clean, 512k Chunk, None (None) None {895dae98:d1a496de:4f590b8b:cb8ac12a}
> │ PV LVM2_member 512.00g used, 987.62g free {70aHF7-aTfj-X2y6-qYXF-szQu-QBFW-q4UlfG}
> └VG vg_virt_dir 1.46t 987.62g free {SQXqhD-j5dR-Xsdh-NBoR-YMqk-YwfF-hyf9ur}
> └dm-3 512.00g [253:3] LV lv_virt_dir1 ext4 {1929e452-ae83-4766-bf0e-8575a7d1a3c8}
> PCI [ata_piix] 00:1f.5 IDE interface: Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE Controller #2
> ├scsi 4:0:0:0 ATA WDC WD30EZRX-00D {WD-WCC4NCWT13RF}
> │└sde 2.73t [8:64] Partitioned (gpt)
> │ ├sde1 2.00t [8:65] MD raid5 (1/3) (w/ sdd1,sdf1) in_sync 'lamachine:128' {f2372cb9-d381-6fd6-ce86-d826882ec82e}
> │ │└md127 4.00t [9:127] MD v1.2 raid5 (3) read-auto, 512k Chunk {f2372cb9:d3816fd6:ce86d826:882ec82e}
> │ │ PV LVM2_member 3.50t used, 511.75g free {NrF3vV-nS1f-wtjY-SfZk-xwUE-YbSB-TWWdLu}
> │ └sde2 500.00g [8:66] MD raid0 (1/3) (w/ sdd2,sdf2) in_sync 'lamachine:129' {895dae98-d1a4-96de-4f59-0b8bcb8ac12a}
> │ └md125 1.46t [9:125] MD v1.2 raid0 (3) clean, 512k Chunk, None (None) None {895dae98:d1a496de:4f590b8b:cb8ac12a}
> │ PV LVM2_member 512.00g used, 987.62g free {70aHF7-aTfj-X2y6-qYXF-szQu-QBFW-q4UlfG}
> └scsi 5:0:0:0 ATA WDC WD30EZRX-00D {WD-WCC4NPRDD6D7}
> └sdf 2.73t [8:80] Partitioned (gpt)
> ├sdf1 2.00t [8:81] MD raid5 (2/3) (w/ sdd1,sde1) in_sync 'lamachine:128' {f2372cb9-d381-6fd6-ce86-d826882ec82e}
> │└md127 4.00t [9:127] MD v1.2 raid5 (3) read-auto, 512k Chunk {f2372cb9:d3816fd6:ce86d826:882ec82e}
> │ PV LVM2_member 3.50t used, 511.75g free {NrF3vV-nS1f-wtjY-SfZk-xwUE-YbSB-TWWdLu}
> └sdf2 500.00g [8:82] MD raid0 (2/3) (w/ sdd2,sde2) in_sync 'lamachine:129' {895dae98-d1a4-96de-4f59-0b8bcb8ac12a}
> └md125 1.46t [9:125] MD v1.2 raid0 (3) clean, 512k Chunk, None (None) None {895dae98:d1a496de:4f590b8b:cb8ac12a}
> PV LVM2_member 512.00g used, 987.62g free {70aHF7-aTfj-X2y6-qYXF-szQu-QBFW-q4UlfG}
> PCI [pata_jmicron] 07:00.1 IDE interface: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 02)
> ├scsi 6:x:x:x [Empty]
> └scsi 7:x:x:x [Empty]
>
> [root@localhost ~]# cat /proc/mdstat
> Personalities : [raid10] [raid0] [raid6] [raid5] [raid4]
> md124 : active raid0 sda5[0] sdb5[1] sdc5[2]
> 94367232 blocks super 1.2 512k chunks
>
> md125 : active raid0 sdf2[2] sdd2[0] sde2[1]
> 1572470784 blocks super 1.2 512k chunks
>
> md127 : active (auto-read-only) raid5 sdf1[3] sde1[1] sdd1[0]
> 4294705152 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
> bitmap: 0/16 pages [0KB], 65536KB chunk
>
> md126 : active raid10 sda2[0] sdc1[1]
> 30719936 blocks 2 near-copies [2/2] [UU]
>
> unused devices: <none>
> [root@localhost ~]# cat /etc/mdadm.conf
> # mdadm.conf written out by anaconda
> MAILADDR root
> AUTO +imsm +1.x -all
> ARRAY /dev/md/126 level=raid10 num-devices=2 UUID=9af006ca:8845bbd3:bfe78010:bc810f04
Ok. Your array didn't assemble because mdadm.conf said not to. The
AUTO clause is excluding unidentified v0.90 metadata. The UUID
....:bc810f04 was called out explicitly, so it assembled.
You should be safe to just assemble the array normally:
mdadm -A /dev/md2 /dev/sd{a3,b2,c2}
Then you need to create a new mdadm.conf. I suggest you use "AUTO -all"
and explicitly list all of your arrays. You only need the device name
and the UUID on each ARRAY line. You can run "mdadm -Es
>>..../mdadm.conf" to add live arrays to the file, then trim out the
unnecessary details.
When mdadm.conf has your arrays, with the names you want them to keep,
update your initramfs. (Command varies by distro.)
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
* RAID6 won't reassemble after disk controller failure
From: Scott Sinno @ 2015-03-25 15:19 UTC (permalink / raw)
To: linux-raid
Cc: Vaughan, Garrison (GSFC-606.2)[INTERNATIONAL TECHNOLOGY COALITION, INC]
JBOD controller failed this morning - we've replaced it, and all
drives are being presented to the system again, however 'mdadm' refuses
to assemble the ARRAY. I've tried assembling with '--force' flags but
it still won't...any help most appreciated. I'm guessing I'll need to
recreate with '--assemble-clean'
[root@dsfs01 ~]cat /etc/redhat-release
CentOS release 6.6 (Final)
[root@dsfs01 ~]mdadm --version
mdadm - v3.3 - 3rd September 2013
[root@dsfs01 ~]uname -r
3.14.33
[root@dsfs01 ~]mdadm -A --force --verbose /dev/md10 /dev/sdbj /dev/sdbk
/dev/sdbl /dev/sdbm /dev/sdbn /dev/sdbo /dev/sdbp /dev/sdbq /dev/sdbi
/dev/sdbr /dev/sdbs /dev/sdbt
mdadm: looking for devices for /dev/md10
mdadm: /dev/sdbj is identified as a member of /dev/md10, slot 0.
mdadm: /dev/sdbk is identified as a member of /dev/md10, slot 1.
mdadm: /dev/sdbl is identified as a member of /dev/md10, slot 2.
mdadm: /dev/sdbm is identified as a member of /dev/md10, slot 3.
mdadm: /dev/sdbn is identified as a member of /dev/md10, slot 4.
mdadm: /dev/sdbo is identified as a member of /dev/md10, slot 5.
mdadm: /dev/sdbp is identified as a member of /dev/md10, slot 6.
mdadm: /dev/sdbq is identified as a member of /dev/md10, slot 7.
mdadm: /dev/sdbi is identified as a member of /dev/md10, slot 8.
mdadm: /dev/sdbr is identified as a member of /dev/md10, slot 9.
mdadm: /dev/sdbs is identified as a member of /dev/md10, slot 10.
mdadm: /dev/sdbt is identified as a member of /dev/md10, slot 11.
mdadm: added /dev/sdbk to /dev/md10 as 1
mdadm: added /dev/sdbl to /dev/md10 as 2
mdadm: added /dev/sdbm to /dev/md10 as 3
mdadm: added /dev/sdbn to /dev/md10 as 4
mdadm: added /dev/sdbo to /dev/md10 as 5
mdadm: added /dev/sdbp to /dev/md10 as 6 (possibly out of date)
mdadm: added /dev/sdbq to /dev/md10 as 7 (possibly out of date)
mdadm: added /dev/sdbi to /dev/md10 as 8 (possibly out of date)
mdadm: added /dev/sdbr to /dev/md10 as 9 (possibly out of date)
mdadm: added /dev/sdbs to /dev/md10 as 10 (possibly out of date)
mdadm: added /dev/sdbt to /dev/md10 as 11 (possibly out of date)
mdadm: added /dev/sdbj to /dev/md10 as 0
mdadm -E /dev/sdbj
/dev/sdbj:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : clean
Device UUID : 3bd0e7f2:cfc24add:122a7354:049efe95
Update Time : Wed Mar 25 08:21:34 2015
Checksum : 4a952f6a - correct
Events : 7641
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 0
Array State : AAAAAA...... ('A' == active, '.' == missing, 'R' ==
replacing)
mdadm -E /dev/sdbk
/dev/sdbk:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : clean
Device UUID : 4ebd5ec0:24367c71:bd5d3b52:3910ebcb
Update Time : Wed Mar 25 08:21:34 2015
Checksum : dfec35ad - correct
Events : 7641
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 1
Array State : AAAA........ ('A' == active, '.' == missing, 'R' ==
replacing)
mdadm -E /dev/sdbl
/dev/sdbl:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : clean
Device UUID : 8cf70b24:9cd55339:08f408d7:7719469b
Update Time : Wed Mar 25 08:21:34 2015
Checksum : 5f99aeed - correct
Events : 7641
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 2
Array State : AAAA........ ('A' == active, '.' == missing, 'R' ==
replacing)
mdadm -E /dev/sdbm
/dev/sdbm:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : clean
Device UUID : 59816854:0a6eb50b:b8cb756e:497c2d77
Update Time : Wed Mar 25 08:21:34 2015
Checksum : d5ac0baa - correct
Events : 7641
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 3
Array State : AAAA........ ('A' == active, '.' == missing, 'R' ==
replacing)
mdadm -E /dev/sdbn
/dev/sdbn:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : active
Device UUID : 52c08937:e782b635:05d7f31c:7e7fa2ae
Update Time : Wed Mar 25 08:21:30 2015
Checksum : c8e56e1f - correct
Events : 7641
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 4
Array State : AAAAAAAAAAAA ('A' == active, '.' == missing, 'R' ==
replacing)
mdadm -E /dev/sdbo
/dev/sdbo:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : active
Device UUID : 2902c7b0:e0e0b31e:70e94404:1d8f10c4
Update Time : Wed Mar 25 08:21:30 2015
Checksum : 27df2ffb - correct
Events : 7641
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 5
Array State : AAAAAAAAAAAA ('A' == active, '.' == missing, 'R' ==
replacing)
mdadm -E /dev/sdbp
/dev/sdbp:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : active
Device UUID : d83bf256:a2f59330:e3209784:ee201d00
Update Time : Wed Mar 25 08:21:30 2015
Checksum : 9c4947ad - correct
Events : 7638
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 6
Array State : AAAAAAAAAAAA ('A' == active, '.' == missing, 'R' ==
replacing)
mdadm -E /dev/sdbq
/dev/sdbq:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : active
Device UUID : d2556b61:a6fa2608:7ad69e55:ff09a3f7
Update Time : Wed Mar 25 08:21:30 2015
Checksum : 46e30555 - correct
Events : 7638
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 7
Array State : AAAAAAAAAAAA ('A' == active, '.' == missing, 'R' ==
replacing)
mdadm -E /dev/sdbi
/dev/sdbi:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : active
Device UUID : 4a19a417:b2c5909e:496d5266:23228c19
Update Time : Wed Mar 25 08:21:30 2015
Checksum : c62242cc - correct
Events : 7638
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 8
Array State : AAAAAAAAAAAA ('A' == active, '.' == missing, 'R' ==
replacing)
mdadm -E /dev/sdbr
/dev/sdbr:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : active
Device UUID : 1074ca9b:d9db5522:17055a3c:b6e69869
Update Time : Wed Mar 25 08:21:30 2015
Checksum : f422101b - correct
Events : 7638
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 9
Array State : AAAAAAAAAAAA ('A' == active, '.' == missing, 'R' ==
replacing)
mdadm -E /dev/sdbs
/dev/sdbs:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : active
Device UUID : 13afb79f:7d24a231:b5e165ab:6faff1c7
Update Time : Wed Mar 25 08:21:30 2015
Checksum : d4c0391b - correct
Events : 7638
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 10
Array State : AAAAAAAAAAAA ('A' == active, '.' == missing, 'R' ==
replacing)
mdadm -E /dev/sdbt
/dev/sdbt:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 903cfc6d:921b0a84:c0b4bc7e:27e28c86
Name : dsfs01:10 (local to host dsfs01)
Creation Time : Tue Nov 5 03:37:14 2013
Raid Level : raid6
Raid Devices : 12
Avail Dev Size : 7813775024 (3725.90 GiB 4000.65 GB)
Array Size : 39068871680 (37258.98 GiB 40006.52 GB)
Used Dev Size : 7813774336 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=688 sectors
State : active
Device UUID : 3cc36ae5:6965ba18:d5ed98bb:ec757657
Update Time : Wed Mar 25 08:21:30 2015
Checksum : a14360ce - correct
Events : 7638
Layout : left-symmetric
Chunk Size : 256K
Device Role : Active device 11
Array State : AAAAAAAAAAAA ('A' == active, '.' == missing, 'R' ==
replacing)
^ permalink raw reply
* Re: RAID6 won't reassemble after disk controller failure
From: Mikael Abrahamsson @ 2015-03-25 15:22 UTC (permalink / raw)
To: Scott Sinno
Cc: linux-raid,
Vaughan, Garrison (GSFC-606.2)[INTERNATIONAL TECHNOLOGY COALITION, INC]
In-Reply-To: <5512D21E.1010506@sinno.net>
On Wed, 25 Mar 2015, Scott Sinno wrote:
> JBOD controller failed this morning - we've replaced it, and all
> drives are being presented to the system again, however 'mdadm' refuses
> to assemble the ARRAY. I've tried assembling with '--force' flags but
> it still won't...any help most appreciated. I'm guessing I'll need to
> recreate with '--assemble-clean'
I would recommend you to not do that unless there is no other way out.
Please post dmesg output from the --assemble --force attempt, it might
contain reason why the assembly was unsuccessful.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: RAID6 won't reassemble after disk controller failure
From: Scott Sinno @ 2015-03-25 15:26 UTC (permalink / raw)
To: Mikael Abrahamsson
Cc: linux-raid,
Vaughan, Garrison (GSFC-606.2)[INTERNATIONAL TECHNOLOGY COALITION, INC]
In-Reply-To: <alpine.DEB.2.02.1503251621390.20507@uplift.swm.pp.se>
Mikael Abrahamsson wrote:
> I would recommend you to not do that unless there is no other way out.
Wholeheartedly agreed, thus looking to this list for guidance first :-)
>
> Please post dmesg output from the --assemble --force attempt, it might
> contain reason why the assembly was unsuccessful.
>
It doesn't appear to be very telling. Note that per the provided
'-E'(examine) output, event count is off a bit on some of the drives,
and several report 'missing'
#dmesg output
md: bind<sdbk>
md: bind<sdbl>
md: bind<sdbm>
md: bind<sdbn>
md: bind<sdbo>
md: bind<sdbp>
md: bind<sdbq>
md: bind<sdbi>
md: bind<sdbr>
md: bind<sdbs>
md: bind<sdbt>
md: bind<sdbj>
md: md10 stopped.
md: unbind<sdbj>
md: export_rdev(sdbj)
md: unbind<sdbt>
md: export_rdev(sdbt)
md: unbind<sdbs>
md: export_rdev(sdbs)
md: unbind<sdbr>
md: export_rdev(sdbr)
md: unbind<sdbi>
md: export_rdev(sdbi)
md: unbind<sdbq>
md: export_rdev(sdbq)
md: unbind<sdbp>
md: export_rdev(sdbp)
md: unbind<sdbo>
md: export_rdev(sdbo)
md: unbind<sdbn>
md: export_rdev(sdbn)
md: unbind<sdbm>
md: export_rdev(sdbm)
md: unbind<sdbl>
md: export_rdev(sdbl)
md: unbind<sdbk>
md: export_rdev(sdbk)
md: md10 stopped.
md: bind<sdbk>
md: bind<sdbl>
md: bind<sdbm>
md: bind<sdbn>
md: bind<sdbo>
md: bind<sdbp>
md: bind<sdbq>
md: bind<sdbi>
md: bind<sdbr>
md: bind<sdbs>
md: bind<sdbt>
md: bind<sdbj>
md: md10 stopped.
md: unbind<sdbj>
md: export_rdev(sdbj)
md: unbind<sdbt>
md: export_rdev(sdbt)
md: unbind<sdbs>
md: export_rdev(sdbs)
md: unbind<sdbr>
md: export_rdev(sdbr)
md: unbind<sdbi>
md: export_rdev(sdbi)
md: unbind<sdbq>
md: export_rdev(sdbq)
md: unbind<sdbp>
md: export_rdev(sdbp)
md: unbind<sdbo>
md: export_rdev(sdbo)
md: unbind<sdbn>
md: export_rdev(sdbn)
md: unbind<sdbm>
md: export_rdev(sdbm)
md: unbind<sdbl>
md: export_rdev(sdbl)
md: unbind<sdbk>
md: export_rdev(sdbk)
^ permalink raw reply
* Re: RAID6 won't reassemble after disk controller failure
From: Scott Sinno @ 2015-03-25 15:29 UTC (permalink / raw)
To: Mikael Abrahamsson
Cc: linux-raid,
Vaughan, Garrison (GSFC-606.2)[INTERNATIONAL TECHNOLOGY COALITION, INC]
In-Reply-To: <5512D3AA.5000003@sinno.net>
Scott Sinno wrote:
> It doesn't appear to be very telling. Note that per the provided
> '-E'(examine) output, event count is off a bit on some of the drives,
> and several report 'missing'
Clarification - the drives themselves are not 'missing', they're healthy
and present, 'mdadm -E' reports some components missing in the 'Array
State' field.
^ permalink raw reply
* Re: RAID6 won't reassemble after disk controller failure
From: Mikael Abrahamsson @ 2015-03-25 15:30 UTC (permalink / raw)
To: Scott Sinno
Cc: linux-raid,
Vaughan, Garrison (GSFC-606.2)[INTERNATIONAL TECHNOLOGY COALITION, INC]
In-Reply-To: <5512D3AA.5000003@sinno.net>
On Wed, 25 Mar 2015, Scott Sinno wrote:
> It doesn't appear to be very telling. Note that per the provided
> '-E'(examine) output, event count is off a bit on some of the drives,
> and several report 'missing'
Ok, next thing to recommend would be to get the latest mdadm from Niels
git repo and try with that one. I know some who have fixed similar
problems to yours by doing this.
"git clone git://neil.brown.name/mdadm mdadm" and compile that and see if
--assemble --force works.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: RAID6 won't reassemble after disk controller failure
From: Scott Sinno @ 2015-03-25 15:43 UTC (permalink / raw)
To: Mikael Abrahamsson
Cc: linux-raid,
Vaughan, Garrison (GSFC-606.2)[INTERNATIONAL TECHNOLOGY COALITION, INC]
In-Reply-To: <alpine.DEB.2.02.1503251628120.20507@uplift.swm.pp.se>
Mikael Abrahamsson wrote:
> Ok, next thing to recommend would be to get the latest mdadm from Niels
> git repo and try with that one. I know some who have fixed similar
> problems to yours by doing this.
>
> "git clone git://neil.brown.name/mdadm mdadm" and compile that and see
> if --assemble --force works.
>
That constitutes a huge step forward. Was able to assemble the array
with all 12 drives using this binary! Thanks so much!!!
However, after stopping and re-assembling the array, using the 'stock'
CentOS version, it yields this complaint unless '--force' is also used.
I'm inclined to believe I should simply fail /dev/sdbt and move on, yes?
[root@dsfs01 ~/mdadm]./mdadm -A /dev/md10
mdadm: ignoring /dev/sdbk as it reports /dev/sdbt as failed
mdadm: ignoring /dev/sdbl as it reports /dev/sdbt as failed
mdadm: ignoring /dev/sdbm as it reports /dev/sdbt as failed
mdadm: /dev/md10 assembled from 9 drives - not enough to start the array.
[root@dsfs01 ~/mdadm]mdadm
[root@dsfs01 ~/mdadm]./mdadm -A --force /dev/md10
mdadm: /dev/md10 has been started with 12 drives.
[root@dsfs01 ~/mdadm]mdadm -S /dev/md10
mdadm: stopped /dev/md10
[root@dsfs01 ~/mdadm]mdadm -A /dev/md10
mdadm: ignoring /dev/sdbk as it reports /dev/sdbt as failed
mdadm: ignoring /dev/sdbl as it reports /dev/sdbt as failed
mdadm: ignoring /dev/sdbm as it reports /dev/sdbt as failed
mdadm: /dev/md10 assembled from 9 drives - not enough to start the array.
[root@dsfs01 ~/mdadm]mdadm -A --force /dev/md10
mdadm: /dev/md10 has been started with 12 drives.
^ permalink raw reply
* Re: RAID6 won't reassemble after disk controller failure
From: Mikael Abrahamsson @ 2015-03-25 16:09 UTC (permalink / raw)
To: Scott Sinno
Cc: linux-raid,
Vaughan, Garrison (GSFC-606.2)[INTERNATIONAL TECHNOLOGY COALITION, INC]
In-Reply-To: <5512D79B.704@sinno.net>
On Wed, 25 Mar 2015, Scott Sinno wrote:
> Mikael Abrahamsson wrote:
>> Ok, next thing to recommend would be to get the latest mdadm from Niels
>> git repo and try with that one. I know some who have fixed similar
>> problems to yours by doing this.
>>
>> "git clone git://neil.brown.name/mdadm mdadm" and compile that and see
>> if --assemble --force works.
>>
>
> That constitutes a huge step forward. Was able to assemble the array
> with all 12 drives using this binary! Thanks so much!!!
>
> However, after stopping and re-assembling the array, using the 'stock'
> CentOS version, it yields this complaint unless '--force' is also used.
> I'm inclined to believe I should simply fail /dev/sdbt and move on, yes?
I will not make any more recommendations on how to proceed with this, it
sounds like failing sdbt houldn't be needed and if I were you, I would
assemble the array, keep it running until someone else who knows more can
potentially help you with what might be wrong with your older version of
mdadm (or the newer one might not do everything it should, or it's
something your kernel is doing wrong).
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: RAID6 won't reassemble after disk controller failure
From: Scott Sinno @ 2015-03-25 16:16 UTC (permalink / raw)
To: Mikael Abrahamsson
Cc: linux-raid,
Vaughan, Garrison (GSFC-606.2)[INTERNATIONAL TECHNOLOGY COALITION, INC]
In-Reply-To: <alpine.DEB.2.02.1503251707440.20507@uplift.swm.pp.se>
Mikael Abrahamsson wrote:
> I will not make any more recommendations on how to proceed with this, it
> sounds like failing sdbt houldn't be needed and if I were you, I would
> assemble the array, keep it running until someone else who knows more
> can potentially help you with what might be wrong with your older
> version of mdadm (or the newer one might not do everything it should, or
> it's something your kernel is doing wrong).
>
Understood. Many thanks again for the assist!!! I'm certainly intent
on rolling out a newer version of mdadm now..will proceed on that
endeavor with prudent caution.
^ permalink raw reply
* [PATCH] Fix minor typo in mdadm manpage.
From: Andrew Burgess @ 2015-03-25 17:17 UTC (permalink / raw)
To: linux-raid; +Cc: Andrew Burgess
Appologies if this is the wrong mailing list for this patch.
This is a very small patch for the manual page for the mdadm utility.
Thanks,
Andrew
---
Change 'is and of' to 'is one of' in mdadm manual page.
Signed-off-by: Andrew Burgess <andrew.burgess@embecosm.com>
---
mdadm.8.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mdadm.8.in b/mdadm.8.in
index a630310..b4a21d9 100644
--- a/mdadm.8.in
+++ b/mdadm.8.in
@@ -214,7 +214,7 @@ to detect and assemble arrays \(em possibly in an
.P
If a device is given before any options, or if the first option is
-and of
+one of
.BR \-\-add ,
.BR \-\-re\-add ,
.BR \-\-add\-spare ,
--
2.2.2
^ permalink raw reply related
* Badblocks and degraded array.
From: Wakko Warner @ 2015-03-25 23:14 UTC (permalink / raw)
To: linux-raid
Firstly, I'm not in need of assistance, just looking for information.
I had a system with 4x 500gb disks in raid 5. One drive (slot 2) was
kicked. I removed and reseated the drive (which is OK). During rebuild, it
hit a bad block on another drive (slot 1) which it kicked. Is it possible
that if there's no redundancy to not kick a drive if it has a bad block?
In the end, my solution was to create a dm target using linear and zero as
needed (zero where the bad block was) then a snapshot target ontop of that
since there was no possibility to write to that section that was a zero
target. I had LVM on top of the raid and my /usr was the one in the bad
block. Fortunately, no files were in that bad block. I dumped the usr
volume elsewhere, removed all the mappings (md, dm, and lvm), assembled the
array again and dumped the volume back which corrected the bad sector. All
this was done using another installation.
This system will be retired anyway so the data isn't really useful. But
having the experience is.
On a side note, it seems that everytime I encounter a bad sector on a drive,
it's always 8 sectors. Does anyone know if hard drives have been 4k
sectored longer than AF drives? This disk is 512 physical according to
fdisk. I've even noticed this on IDE drives.
--
Microsoft has beaten Volkswagen's world record. Volkswagen only created 22
million bugs.
^ permalink raw reply
* Re: Badblocks and degraded array.
From: NeilBrown @ 2015-03-25 23:50 UTC (permalink / raw)
To: Wakko Warner; +Cc: linux-raid
In-Reply-To: <20150325231400.GA9242@animx.eu.org>
[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]
On Wed, 25 Mar 2015 19:14:00 -0400 Wakko Warner <wakko@animx.eu.org> wrote:
> Firstly, I'm not in need of assistance, just looking for information.
>
> I had a system with 4x 500gb disks in raid 5. One drive (slot 2) was
> kicked. I removed and reseated the drive (which is OK). During rebuild, it
> hit a bad block on another drive (slot 1) which it kicked. Is it possible
> that if there's no redundancy to not kick a drive if it has a bad block?
Only if you have bad-block-logs enabled. This is a relatively new feature.
>
> In the end, my solution was to create a dm target using linear and zero as
> needed (zero where the bad block was) then a snapshot target ontop of that
> since there was no possibility to write to that section that was a zero
> target. I had LVM on top of the raid and my /usr was the one in the bad
> block. Fortunately, no files were in that bad block. I dumped the usr
> volume elsewhere, removed all the mappings (md, dm, and lvm), assembled the
> array again and dumped the volume back which corrected the bad sector. All
> this was done using another installation.
>
> This system will be retired anyway so the data isn't really useful. But
> having the experience is.
>
> On a side note, it seems that everytime I encounter a bad sector on a drive,
> it's always 8 sectors. Does anyone know if hard drives have been 4k
> sectored longer than AF drives? This disk is 512 physical according to
> fdisk. I've even noticed this on IDE drives.
>
Linux tends to do IO in multiples of 4k so it is unlikely to report a smaller
block. That may or may not be relevant for your particular experiences.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox