* Re: dmadm question
[not found] <661E720A-B65C-4C24-B6A4-A4439596DEB9@lukeodom.com>
@ 2014-09-15 0:31 ` NeilBrown
2014-09-15 14:07 ` Luke Odom
0 siblings, 1 reply; 4+ messages in thread
From: NeilBrown @ 2014-09-15 0:31 UTC (permalink / raw)
To: Luke Odom; +Cc: linux-raid
[-- Attachment #1: Type: text/plain, Size: 3409 bytes --]
On 12 Sep 2014 18:49:54 -0700 Luke Odom <luke@lukeodom.com> wrote:
> I had a raid1 subarray running within an imsm container. One of the drives died so I replaced it. I can get the new drive into the imsm container but I can’t add it to the raid1 array within that container. I’ve read the man page and can’t see to figure it out. Any help would be greatly appreciated. Using mdadm 3.2.5 on debian squeeze.
This should just happen automatically. As soon as you add the device to the
container, mdmon notices and adds it to the raid1.
However it appears not to have happened...
I assume the new drive is exactly the same size as the old drive?
Try removing the new device from md127, run "mdadm --zero" on it, then add it
back again.
Do any messages appear in the kernel logs when you do that?
Is "mdmon md127" running?
NeilBrown
>
>
>
>
> root@ds6790:~# cat /proc/mdstat
> Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
> md126 : active raid1 sda[0]
> 976759808 blocks super external:/md127/0 [2/1] [U_]
>
>
>
>
> md127 : inactive sdb[0](S) sda[1](S)
> 4901 blocks super external:imsm
>
>
>
>
> unused devices: <none>
>
>
>
>
>
>
> root@ds6790:~# mdadm --detail /dev/md126
> /dev/md126:
> Container : /dev/md127, member 0
> Raid Level : raid1
> Array Size : 976759808 (931.51 GiB 1000.20 GB)
> Used Dev Size : 976759940 (931.51 GiB 1000.20 GB)
> Raid Devices : 2
> Total Devices : 1
>
>
>
>
> State : active, degraded
> Active Devices : 1
> Working Devices : 1
> Failed Devices : 0
> Spare Devices : 0
>
>
>
>
>
>
>
>
> UUID : 1be60edf:5c16b945:86434b6b:2714fddb
> Number Major Minor RaidDevice State
> 0 8 0 0 active sync /dev/sda
> 1 0 0 1 removed
>
>
>
>
>
>
> root@ds6790:~# mdadm --examine /dev/md127
> /dev/md127:
> Magic : Intel Raid ISM Cfg Sig.
> Version : 1.1.00
> Orig Family : 6e37aa48
> Family : 6e37aa48
> Generation : 00640a43
> Attributes : All supported
> UUID : ac27ba68:f8a3618d:3810d44f:25031c07
> Checksum : 513ef1f6 correct
> MPB Sectors : 1
> Disks : 2
> RAID Devices : 1
>
>
>
>
> Disk00 Serial : 9XG3RTL0
> State : active
> Id : 00000002
> Usable Size : 1953519880 (931.51 GiB 1000.20 GB)
>
>
>
>
> [Volume0]:
> UUID : 1be60edf:5c16b945:86434b6b:2714fddb
> RAID Level : 1
> Members : 2
> Slots : [U_]
> Failed disk : 1
> This Slot : 0
> Array Size : 1953519616 (931.51 GiB 1000.20 GB)
> Per Dev Size : 1953519880 (931.51 GiB 1000.20 GB)
> Sector Offset : 0
> Num Stripes : 7630936
> Chunk Size : 64 KiB
> Reserved : 0
> Migrate State : idle
> Map State : degraded
> Dirty State : dirty
>
>
>
>
> Disk01 Serial : XG3RWMF
> State : failed
> Id : ffffffff
> Usable Size : 1953519880 (931.51 GiB 1000.20 GB)
>
>
>
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: dmadm question
2014-09-15 0:31 ` dmadm question NeilBrown
@ 2014-09-15 14:07 ` Luke Odom
2014-09-29 17:38 ` Dan Williams
0 siblings, 1 reply; 4+ messages in thread
From: Luke Odom @ 2014-09-15 14:07 UTC (permalink / raw)
To: NeilBrown; +Cc: Luke Odom, linux-raid
Drive is exact same model as old one. Output of requested commands:
# mdadm --manage /dev/md127 --remove /dev/sdb
mdadm: hot removed /dev/sdb from /dev/md127
# mdadm --zero /dev/sdb
# mdadm --manage /dev/md127 --add /dev/sdb
mdadm: added /dev/sdb
# ps aux | grep mdmon
root 1937 0.0 0.1 10492 10484 ? SLsl 14:04 0:00 mdmon md127
root 2055 0.0 0.0 2420 928 pts/0 S+ 14:06 0:00 grep mdmon
md: unbind<sdb>
md: export_rdev(sdb)
md: bind<sdb>
On Sun, September 14, 2014 5:31 pm, NeilBrown wrote:
> On 12 Sep 2014 18:49:54 -0700 Luke Odom <luke@lukeodom.com> wrote:
>
>> I had a raid1 subarray running within an imsm container. One of the
>> drives died so I replaced it. I can get the new drive into the imsm
>> container but I can’t add it to the raid1 array within that
>> container. I’ve read the man page and can’t see to figure it out.
>> Any help would be greatly appreciated. Using mdadm 3.2.5 on debian
>> squeeze.Â
>
> This should just happen automatically. As soon as you add the device to
> the
> container, mdmon notices and adds it to the raid1.
>
> However it appears not to have happened...
>
> I assume the new drive is exactly the same size as the old drive?
> Try removing the new device from md127, run "mdadm --zero" on it, then add
> it
> back again.
> Do any messages appear in the kernel logs when you do that?
>
> Is "mdmon md127" running?
>
> NeilBrown
>
>
>>
>>
>>
>>
>> root@ds6790:~# cat /proc/mdstat
>> Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
>> md126 : active raid1 sda[0]
>> Â Â Â 976759808 blocks super external:/md127/0 [2/1] [U_]
>>
>>
>>
>>
>> md127 : inactive sdb[0](S) sda[1](S)
>> Â Â Â 4901 blocks super external:imsm
>>
>>
>>
>>
>> unused devices: <none>
>>
>>
>>
>>
>>
>>
>> root@ds6790:~# mdadm --detail /dev/md126
>> /dev/md126:
>> Â Â Â Container : /dev/md127, member 0
>> Â Â Â Raid Level : raid1
>> Â Â Â Array Size : 976759808 (931.51 GiB 1000.20 GB)
>> Â Used Dev Size : 976759940 (931.51 GiB 1000.20 GB)
>> Â Â Raid Devices : 2
>> Â Total Devices : 1
>>
>>
>>
>>
>> Â Â Â Â Â State : active, degradedÂ
>> Â Active Devices : 1
>> Working Devices : 1
>> Â Failed Devices : 0
>> Â Spare Devices : 0
>>
>>
>>
>>
>>
>>
>>
>>
>> Â Â Â Â Â Â UUID : 1be60edf:5c16b945:86434b6b:2714fddb
>>   Number  Major  Minor  RaidDevice State
>> Â Â Â Â 0 Â Â Â 8 Â Â Â Â 0 Â Â Â Â 0 Â Â Â active sync Â
>> /dev/sda
>> Â Â Â Â 1 Â Â Â 0 Â Â Â Â 0 Â Â Â Â 1 Â Â Â removed
>>
>>
>>
>>
>>
>>
>> root@ds6790:~# mdadm --examine /dev/md127
>> /dev/md127:
>> Â Â Â Â Â Magic : Intel Raid ISM Cfg Sig.
>> Â Â Â Â Version : 1.1.00
>> Â Â Orig Family : 6e37aa48
>> Â Â Â Â Â Family : 6e37aa48
>> Â Â Â Generation : 00640a43
>> Â Â Â Attributes : All supported
>> Â Â Â Â Â Â UUID : ac27ba68:f8a3618d:3810d44f:25031c07
>> Â Â Â Â Checksum : 513ef1f6 correct
>> Â Â MPB Sectors : 1
>> Â Â Â Â Â Disks : 2
>> Â Â RAID Devices : 1
>>
>>
>>
>>
>> Â Disk00 Serial : 9XG3RTL0
>> Â Â Â Â Â State : active
>> Â Â Â Â Â Â Â Id : 00000002
>> Â Â Usable Size : 1953519880 (931.51 GiB 1000.20 GB)
>>
>>
>>
>>
>> [Volume0]:
>> Â Â Â Â Â Â UUID : 1be60edf:5c16b945:86434b6b:2714fddb
>> Â Â Â RAID Level : 1
>> Â Â Â Â Members : 2
>> Â Â Â Â Â Slots : [U_]
>> Â Â Failed disk : 1
>> Â Â Â This Slot : 0
>> Â Â Â Array Size : 1953519616 (931.51 GiB 1000.20 GB)
>> Â Â Per Dev Size : 1953519880 (931.51 GiB 1000.20 GB)
>> Â Sector Offset : 0
>> Â Â Num Stripes : 7630936
>> Â Â Â Chunk Size : 64 KiB
>> Â Â Â Â Reserved : 0
>> Â Migrate State : idle
>> Â Â Â Map State : degraded
>> Â Â Dirty State : dirty
>>
>>
>>
>>
>> Â Disk01 Serial : XG3RWMF
>> Â Â Â Â Â State : failed
>> Â Â Â Â Â Â Â Id : ffffffff
>> Â Â Usable Size : 1953519880 (931.51 GiB 1000.20 GB)
>>
>>
>>
>>
>>
>
>
--
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 [flat|nested] 4+ messages in thread
* Re: dmadm question
2014-09-15 14:07 ` Luke Odom
@ 2014-09-29 17:38 ` Dan Williams
2014-09-29 21:30 ` NeilBrown
0 siblings, 1 reply; 4+ messages in thread
From: Dan Williams @ 2014-09-29 17:38 UTC (permalink / raw)
To: luke; +Cc: NeilBrown, linux-raid, Artur Paszkiewicz
Hmm, I wonder if this is a regression. The last time I saw this
problem I introduced commit:
commit b276dd33c74a51598e37fc72e6fb8f5ebd6620f2
Author: Dan Williams <dan.j.williams@intel.com>
Date: Thu Aug 25 19:14:24 2011 -0700
imsm: fix reserved sectors for spares
Different OROMs reserve different amounts of space for the migration area.
When activating a spare minimize the reserved space otherwise a valid spare
can be prevented from joining an array with a migration area smaller than
IMSM_RESERVED_SECTORS.
This may result in an array that cannot be reshaped, but that is less
surprising than not being able to rebuild a degraded array.
imsm_reserved_sectors() already reports the minimal value which adds to
the confusion when trying rebuild an array because mdadm -E indicates
that the device has enough space.
Cc: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
...but I notice now the logic was replaced with:
commit b81221b74eba9fd7f670a8d3d4bfbda43ec91993
Author: Czarnowska, Anna <anna.czarnowska@intel.com>
Date: Mon Sep 19 12:57:48 2011 +0000
imsm: Calculate reservation for a spare based on active disks in container
New function to calculate minimum reservation to expect from a spare
is introduced.
The required amount of space at the end of the disk depends on what we
plan to do with the spare and what array we want to use it in.
For creating new subarray in an empty container the full reservation of
MPB_SECTOR_COUNT + IMSM_RESERVED_SECTORS is required.
For recovery or OLCE on a volume using new metadata format at least
MPB_SECTOR_CNT + NUM_BLOCKS_DIRTY_STRIPE_REGION is required.
The additional space for migration optimization included in
IMSM_RESERVED_SECTORS is not necessary and is not reserved by some oroms.
MPB_SECTOR_CNT alone is not sufficient as it does not include the
reservation at the end of subarray.
However if the real reservation on active disks is smaller than this
(when the array uses old metadata format) we should use the real value.
This will allow OLCE and recovery to start on the spare even if the volume
doesn't have the reservation we normally use for new volumes.
Signed-off-by: Anna Czarnowska <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
...which raises the absolute minimum reserved sectors to a number >
MPB_SECTOR_CNT.
My thought is that we should always favor spare replacement over
features like reshape, and dirty-stripe-log. Commit b81221b74eba
appears to favor the latter.
On Mon, Sep 15, 2014 at 7:07 AM, Luke Odom <luke@lukeodom.com> wrote:
> Drive is exact same model as old one. Output of requested commands:
>
> # mdadm --manage /dev/md127 --remove /dev/sdb
> mdadm: hot removed /dev/sdb from /dev/md127
> # mdadm --zero /dev/sdb
> # mdadm --manage /dev/md127 --add /dev/sdb
> mdadm: added /dev/sdb
> # ps aux | grep mdmon
> root 1937 0.0 0.1 10492 10484 ? SLsl 14:04 0:00 mdmon md127
> root 2055 0.0 0.0 2420 928 pts/0 S+ 14:06 0:00 grep mdmon
>
> md: unbind<sdb>
> md: export_rdev(sdb)
> md: bind<sdb>
>
>
>
> On Sun, September 14, 2014 5:31 pm, NeilBrown wrote:
>> On 12 Sep 2014 18:49:54 -0700 Luke Odom <luke@lukeodom.com> wrote:
>>
>>> I had a raid1 subarray running within an imsm container. One of the
>>> drives died so I replaced it. I can get the new drive into the imsm
>>> container but I can’t add it to the raid1 array within that
>>> container. I’ve read the man page and can’t see to figure it out.
>>> Any help would be greatly appreciated. Using mdadm 3.2.5 on debian
>>> squeeze.
>>
>> This should just happen automatically. As soon as you add the device to
>> the
>> container, mdmon notices and adds it to the raid1.
>>
>> However it appears not to have happened...
>>
>> I assume the new drive is exactly the same size as the old drive?
>> Try removing the new device from md127, run "mdadm --zero" on it, then add
>> it
>> back again.
>> Do any messages appear in the kernel logs when you do that?
>>
>> Is "mdmon md127" running?
>>
>> NeilBrown
>>
>>
>>>
>>>
>>>
>>>
>>> root@ds6790:~# cat /proc/mdstat
>>> Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
>>> md126 : active raid1 sda[0]
>>> 976759808 blocks super external:/md127/0 [2/1] [U_]
>>>
>>>
>>>
>>>
>>> md127 : inactive sdb[0](S) sda[1](S)
>>> 4901 blocks super external:imsm
>>>
>>>
>>>
>>>
>>> unused devices: <none>
>>>
>>>
>>>
>>>
>>>
>>>
>>> root@ds6790:~# mdadm --detail /dev/md126
>>> /dev/md126:
>>> Container : /dev/md127, member 0
>>> Raid Level : raid1
>>> Array Size : 976759808 (931.51 GiB 1000.20 GB)
>>> Used Dev Size : 976759940 (931.51 GiB 1000.20 GB)
>>> Raid Devices : 2
>>> Total Devices : 1
>>>
>>>
>>>
>>>
>>> State : active, degraded
>>> Active Devices : 1
>>> Working Devices : 1
>>> Failed Devices : 0
>>> Spare Devices : 0
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> UUID : 1be60edf:5c16b945:86434b6b:2714fddb
>>> Number Major Minor RaidDevice State
>>> 0 8 0 0 active sync
>>> /dev/sda
>>> 1 0 0 1 removed
>>>
>>>
>>>
>>>
>>>
>>>
>>> root@ds6790:~# mdadm --examine /dev/md127
>>> /dev/md127:
>>> Magic : Intel Raid ISM Cfg Sig.
>>> Version : 1.1.00
>>> Orig Family : 6e37aa48
>>> Family : 6e37aa48
>>> Generation : 00640a43
>>> Attributes : All supported
>>> UUID : ac27ba68:f8a3618d:3810d44f:25031c07
>>> Checksum : 513ef1f6 correct
>>> MPB Sectors : 1
>>> Disks : 2
>>> RAID Devices : 1
>>>
>>>
>>>
>>>
>>> Disk00 Serial : 9XG3RTL0
>>> State : active
>>> Id : 00000002
>>> Usable Size : 1953519880 (931.51 GiB 1000.20 GB)
>>>
>>>
>>>
>>>
>>> [Volume0]:
>>> UUID : 1be60edf:5c16b945:86434b6b:2714fddb
>>> RAID Level : 1
>>> Members : 2
>>> Slots : [U_]
>>> Failed disk : 1
>>> This Slot : 0
>>> Array Size : 1953519616 (931.51 GiB 1000.20 GB)
>>> Per Dev Size : 1953519880 (931.51 GiB 1000.20 GB)
>>> Sector Offset : 0
>>> Num Stripes : 7630936
>>> Chunk Size : 64 KiB
>>> Reserved : 0
>>> Migrate State : idle
>>> Map State : degraded
>>> Dirty State : dirty
>>>
>>>
>>>
>>>
>>> Disk01 Serial : XG3RWMF
>>> State : failed
>>> Id : ffffffff
>>> Usable Size : 1953519880 (931.51 GiB 1000.20 GB)
>>>
>>>
>>>
>>>
>>>
>>
>>
>
> --
> 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
--
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 [flat|nested] 4+ messages in thread
* Re: dmadm question
2014-09-29 17:38 ` Dan Williams
@ 2014-09-29 21:30 ` NeilBrown
0 siblings, 0 replies; 4+ messages in thread
From: NeilBrown @ 2014-09-29 21:30 UTC (permalink / raw)
To: Dan Williams; +Cc: luke, linux-raid, Artur Paszkiewicz
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
On Mon, 29 Sep 2014 10:38:03 -0700 Dan Williams <dan.j.williams@intel.com>
wrote:
> Hmm, I wonder if this is a regression. The last time I saw this
> problem I introduced commit:
>
Maybe...
Luke, can you change get_extents() in super-intel.c like this:
if (dl->index == -1)
+ reservation = MPB_SECTOR_CNT;
- reservation = imsm_min_reserved_sectors(super);
else
reservation = MPB_SECTOR_CNT + IMSM_RESERVED_SECTORS;
i.e. replace imsm_min_reserved_sectors(super) with MPB_SECTOR_CNT
and 'make install'.
Then see if your problem goes away?
Thanks,
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-09-29 21:30 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <661E720A-B65C-4C24-B6A4-A4439596DEB9@lukeodom.com>
2014-09-15 0:31 ` dmadm question NeilBrown
2014-09-15 14:07 ` Luke Odom
2014-09-29 17:38 ` Dan Williams
2014-09-29 21:30 ` NeilBrown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).