* Re: [PATCH RESEND] Monitor: fix for regression with container devices
From: NeilBrown @ 2015-02-11 4:38 UTC (permalink / raw)
To: Artur Paszkiewicz; +Cc: linux-raid, pawel.baldysiak
In-Reply-To: <1423476830-15635-1-git-send-email-artur.paszkiewicz@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2426 bytes --]
On Mon, 9 Feb 2015 11:13:50 +0100 Artur Paszkiewicz
<artur.paszkiewicz@intel.com> wrote:
> This patch fixes 2 problems introduced by commit 9a518d8: not closing a
> file descriptor and ignoring container devices. Array state is always
> "inactive" for containers, so we make sure that the device is not a
> container by reading also the "level" sysfs entry.
>
> Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> Reviewed-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
> ---
> Monitor.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/Monitor.c b/Monitor.c
> index 971d2ec..66d67ba 100644
> --- a/Monitor.c
> +++ b/Monitor.c
> @@ -483,11 +483,17 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
> strncmp(buf,"inact",5) == 0) {
> if (fd >= 0)
> close(fd);
> - if (!st->err)
> - alert("DeviceDisappeared", dev, NULL, ainfo);
> - st->err++;
> - return 0;
> + fd = sysfs_open(st->devnm, NULL, "level");
> + if (fd < 0 || read(fd, buf, 10) != 0) {
> + if (fd >= 0)
> + close(fd);
> + if (!st->err)
> + alert("DeviceDisappeared", dev, NULL, ainfo);
> + st->err++;
> + return 0;
> + }
> }
> + close(fd);
> }
> fd = open(dev, O_RDONLY);
> if (fd < 0) {
Thanks for the patch.
I don't think I agree with the logic of using 'level' though.
For the sort of arrays that I need to ignore here, 'level' will be empty.
It would make sense to test 'metadata' though. If that starts 'external:',
then we don't want to ignore the array.
Could you confirm that this works please?
Thanks,
NeilBrown
diff --git a/Monitor.c b/Monitor.c
index 971d2ecbea72..6e085cb24993 100644
--- a/Monitor.c
+++ b/Monitor.c
@@ -483,11 +483,18 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
strncmp(buf,"inact",5) == 0) {
if (fd >= 0)
close(fd);
- if (!st->err)
- alert("DeviceDisappeared", dev, NULL, ainfo);
- st->err++;
- return 0;
+ fd = sysfs_open(st->devnm, NULL, "metadata");
+ if (fd < 0 || read(fd, buf, 9) != 9 ||
+ strncmp(buf, "external:", 9) != 0) {
+ if (fd >= 0)
+ close(fd);
+ if (!st->err)
+ alert("DeviceDisappeared", dev, NULL, ainfo);
+ st->err++;
+ return 0;
+ }
}
+ close(fd);
}
fd = open(dev, O_RDONLY);
if (fd < 0) {
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply related
* Re: Wierd: Degrading while recovering raid5
From: Kyle Logue @ 2015-02-11 6:23 UTC (permalink / raw)
To: linux-raid
Phil:
For a while I really thought that was going to work. I swapped out the
sata cable and set the timeout to 10 minutes. At about 70% rebuilt I
got the following dmesg which seems to indicate the death of my sdc
drive.
Here is my question: I still have this sde that I manually failed and
hasn't been touched. Can i force re-add it to the array and just take
the data corruption hit?
I'd rather have to revert part of my data than all of it. The drive
counts are significantly different now, but I haven't mounted the
drives since the beginning. I haven't tried it but I saw someone else
online get a message like 'raid has failed so using --add cannot work
and might destroy data'. Is there a force add? What are my chances?
The dmesg in question. I started rebuilding at 20:24.
[Tue Feb 10 20:23:59 2015] md: md0 stopped.
[Tue Feb 10 20:23:59 2015] md: unbind<sdf1>
[Tue Feb 10 20:23:59 2015] md: export_rdev(sdf1)
[Tue Feb 10 20:23:59 2015] md: unbind<sde1>
[Tue Feb 10 20:23:59 2015] md: export_rdev(sde1)
[Tue Feb 10 20:23:59 2015] md: unbind<sdd1>
[Tue Feb 10 20:23:59 2015] md: export_rdev(sdd1)
[Tue Feb 10 20:23:59 2015] md: unbind<sdc1>
[Tue Feb 10 20:23:59 2015] md: export_rdev(sdc1)
[Tue Feb 10 20:23:59 2015] md: unbind<sdb1>
[Tue Feb 10 20:23:59 2015] md: export_rdev(sdb1)
[Tue Feb 10 20:23:59 2015] md: unbind<sda1>
[Tue Feb 10 20:23:59 2015] md: export_rdev(sda1)
[Tue Feb 10 20:24:59 2015] md: md0 stopped.
[Tue Feb 10 20:24:59 2015] md: bind<sdd1>
[Tue Feb 10 20:24:59 2015] md: bind<sde1>
[Tue Feb 10 20:24:59 2015] md: bind<sdf1>
[Tue Feb 10 20:24:59 2015] md: bind<sdb1>
[Tue Feb 10 20:24:59 2015] md: bind<sda1>
[Tue Feb 10 20:24:59 2015] md: bind<sdc1>
[Tue Feb 10 20:24:59 2015] md: kicking non-fresh sde1 from array!
[Tue Feb 10 20:24:59 2015] md: unbind<sde1>
[Tue Feb 10 20:24:59 2015] md: export_rdev(sde1)
[Tue Feb 10 20:24:59 2015] md/raid:md0: device sdc1 operational as raid disk 0
[Tue Feb 10 20:24:59 2015] md/raid:md0: device sdb1 operational as raid disk 4
[Tue Feb 10 20:24:59 2015] md/raid:md0: device sdf1 operational as raid disk 3
[Tue Feb 10 20:24:59 2015] md/raid:md0: device sdd1 operational as raid disk 1
[Tue Feb 10 20:24:59 2015] md/raid:md0: allocated 0kB
[Tue Feb 10 20:24:59 2015] md/raid:md0: raid level 5 active with 4 out
of 5 devices, algorithm 2
[Tue Feb 10 20:24:59 2015] RAID conf printout:
[Tue Feb 10 20:24:59 2015] --- level:5 rd:5 wd:4
[Tue Feb 10 20:24:59 2015] disk 0, o:1, dev:sdc1
[Tue Feb 10 20:24:59 2015] disk 1, o:1, dev:sdd1
[Tue Feb 10 20:24:59 2015] disk 3, o:1, dev:sdf1
[Tue Feb 10 20:24:59 2015] disk 4, o:1, dev:sdb1
[Tue Feb 10 20:24:59 2015] md0: Warning: Device sda1 is misaligned
[Tue Feb 10 20:24:59 2015] md0: Warning: Device sdb1 is misaligned
[Tue Feb 10 20:24:59 2015] md0: Warning: Device sdb1 is misaligned
[Tue Feb 10 20:24:59 2015] md0: detected capacity change from 0 to 8001584889856
[Tue Feb 10 20:24:59 2015] RAID conf printout:
[Tue Feb 10 20:24:59 2015] --- level:5 rd:5 wd:4
[Tue Feb 10 20:24:59 2015] disk 0, o:1, dev:sdc1
[Tue Feb 10 20:24:59 2015] disk 1, o:1, dev:sdd1
[Tue Feb 10 20:24:59 2015] disk 2, o:1, dev:sda1
[Tue Feb 10 20:24:59 2015] disk 3, o:1, dev:sdf1
[Tue Feb 10 20:24:59 2015] disk 4, o:1, dev:sdb1
[Tue Feb 10 20:24:59 2015] md: recovery of RAID array md0
[Tue Feb 10 20:24:59 2015] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
[Tue Feb 10 20:24:59 2015] md: using maximum available idle IO
bandwidth (but not more than 200000 KB/sec) for recovery.
[Tue Feb 10 20:24:59 2015] md: using 128k window, over a total of 1953511936k.
[Tue Feb 10 20:24:59 2015] md0: unknown partition table
[Tue Feb 10 20:35:34 2015] perf samples too long (2505 > 2500),
lowering kernel.perf_event_max_sample_rate to 50000
[Wed Feb 11 01:02:15 2015] ata5.00: exception Emask 0x0 SAct 0x30 SErr
0x0 action 0x0
[Wed Feb 11 01:02:15 2015] ata5.00: irq_stat 0x40000008
[Wed Feb 11 01:02:15 2015] ata5.00: failed command: READ FPDMA QUEUED
[Wed Feb 11 01:02:15 2015] ata5.00: cmd
60/00:20:18:1d:1c/04:00:a4:00:00/40 tag 4 ncq 524288 in
[Wed Feb 11 01:02:15 2015] res
41/40:00:e8:1d:1c/00:04:a4:00:00/00 Emask 0x409 (media error) <F>
[Wed Feb 11 01:02:15 2015] ata5.00: status: { DRDY ERR }
[Wed Feb 11 01:02:15 2015] ata5.00: error: { UNC }
[Wed Feb 11 01:02:15 2015] ata5.00: configured for UDMA/133
[Wed Feb 11 01:02:15 2015] sd 4:0:0:0: [sdc] Unhandled sense code
[Wed Feb 11 01:02:15 2015] sd 4:0:0:0: [sdc]
[Wed Feb 11 01:02:15 2015] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Wed Feb 11 01:02:15 2015] sd 4:0:0:0: [sdc]
[Wed Feb 11 01:02:15 2015] Sense Key : Medium Error [current] [descriptor]
[Wed Feb 11 01:02:15 2015] Descriptor sense data with sense
descriptors (in hex):
[Wed Feb 11 01:02:15 2015] 72 03 11 04 00 00 00 0c 00 0a 80 00
00 00 00 00
[Wed Feb 11 01:02:15 2015] a4 1c 1d e8
[Wed Feb 11 01:02:15 2015] sd 4:0:0:0: [sdc]
[Wed Feb 11 01:02:15 2015] Add. Sense: Unrecovered read error - auto
reallocate failed
[Wed Feb 11 01:02:15 2015] sd 4:0:0:0: [sdc] CDB:
[Wed Feb 11 01:02:15 2015] Read(10): 28 00 a4 1c 1d 18 00 04 00 00
[Wed Feb 11 01:02:15 2015] end_request: I/O error, dev sdc, sector 2753306088
[Wed Feb 11 01:02:15 2015] md/raid:md0: read error not correctable
(sector 2753304040 on sdc1).
[Wed Feb 11 01:02:15 2015] md/raid:md0: read error not correctable
(sector 2753304048 on sdc1).
[Wed Feb 11 01:02:15 2015] md/raid:md0: read error not correctable
(sector 2753304056 on sdc1).
[Wed Feb 11 01:02:15 2015] md/raid:md0: read error not correctable
(sector 2753304064 on sdc1).
[Wed Feb 11 01:02:15 2015] md/raid:md0: read error not correctable
(sector 2753304072 on sdc1).
[Wed Feb 11 01:02:15 2015] md/raid:md0: read error not correctable
(sector 2753304080 on sdc1).
[Wed Feb 11 01:02:15 2015] md/raid:md0: read error not correctable
(sector 2753304088 on sdc1).
[Wed Feb 11 01:02:15 2015] md/raid:md0: read error not correctable
(sector 2753304096 on sdc1).
[Wed Feb 11 01:02:15 2015] md/raid:md0: read error not correctable
(sector 2753304104 on sdc1).
[Wed Feb 11 01:02:15 2015] md/raid:md0: read error not correctable
(sector 2753304112 on sdc1).
[Wed Feb 11 01:02:15 2015] ata5: EH complete
[Wed Feb 11 01:02:18 2015] ata5.00: exception Emask 0x0 SAct 0xff80
SErr 0x0 action 0x0
[Wed Feb 11 01:02:18 2015] ata5.00: irq_stat 0x40000008
[Wed Feb 11 01:02:18 2015] ata5.00: failed command: READ FPDMA QUEUED
[Wed Feb 11 01:02:18 2015] ata5.00: cmd
60/80:38:e8:1d:1c/00:00:a4:00:00/40 tag 7 ncq 65536 in
[Wed Feb 11 01:02:18 2015] res
41/40:80:e8:1d:1c/00:00:a4:00:00/00 Emask 0x409 (media error) <F>
[Wed Feb 11 01:02:18 2015] ata5.00: status: { DRDY ERR }
[Wed Feb 11 01:02:18 2015] ata5.00: error: { UNC }
[Wed Feb 11 01:02:18 2015] ata5.00: configured for UDMA/133
[Wed Feb 11 01:02:18 2015] sd 4:0:0:0: [sdc] Unhandled sense code
[Wed Feb 11 01:02:18 2015] sd 4:0:0:0: [sdc]
[Wed Feb 11 01:02:18 2015] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Wed Feb 11 01:02:18 2015] sd 4:0:0:0: [sdc]
[Wed Feb 11 01:02:18 2015] Sense Key : Medium Error [current] [descriptor]
[Wed Feb 11 01:02:18 2015] Descriptor sense data with sense
descriptors (in hex):
[Wed Feb 11 01:02:18 2015] 72 03 11 04 00 00 00 0c 00 0a 80 00
00 00 00 00
[Wed Feb 11 01:02:18 2015] a4 1c 1d e8
[Wed Feb 11 01:02:18 2015] sd 4:0:0:0: [sdc]
[Wed Feb 11 01:02:18 2015] Add. Sense: Unrecovered read error - auto
reallocate failed
[Wed Feb 11 01:02:18 2015] sd 4:0:0:0: [sdc] CDB:
[Wed Feb 11 01:02:18 2015] Read(10): 28 00 a4 1c 1d e8 00 00 80 00
[Wed Feb 11 01:02:18 2015] end_request: I/O error, dev sdc, sector 2753306088
[Wed Feb 11 01:02:18 2015] md/raid:md0: Disk failure on sdc1, disabling device.
[Wed Feb 11 01:02:18 2015] md/raid:md0: Operation continuing on 3 devices.
[Wed Feb 11 01:02:18 2015] ata5: EH complete
[Wed Feb 11 01:02:18 2015] md: md0: recovery interrupted.
[Wed Feb 11 01:02:18 2015] RAID conf printout:
[Wed Feb 11 01:02:18 2015] --- level:5 rd:5 wd:3
[Wed Feb 11 01:02:18 2015] disk 0, o:0, dev:sdc1
[Wed Feb 11 01:02:18 2015] disk 1, o:1, dev:sdd1
[Wed Feb 11 01:02:18 2015] disk 2, o:1, dev:sda1
[Wed Feb 11 01:02:18 2015] disk 3, o:1, dev:sdf1
[Wed Feb 11 01:02:18 2015] disk 4, o:1, dev:sdb1
[Wed Feb 11 01:02:18 2015] RAID conf printout:
[Wed Feb 11 01:02:18 2015] --- level:5 rd:5 wd:3
[Wed Feb 11 01:02:18 2015] disk 1, o:1, dev:sdd1
[Wed Feb 11 01:02:18 2015] disk 2, o:1, dev:sda1
[Wed Feb 11 01:02:18 2015] disk 3, o:1, dev:sdf1
[Wed Feb 11 01:02:18 2015] disk 4, o:1, dev:sdb1
[Wed Feb 11 01:02:18 2015] RAID conf printout:
[Wed Feb 11 01:02:18 2015] --- level:5 rd:5 wd:3
[Wed Feb 11 01:02:18 2015] disk 1, o:1, dev:sdd1
[Wed Feb 11 01:02:18 2015] disk 2, o:1, dev:sda1
[Wed Feb 11 01:02:18 2015] disk 3, o:1, dev:sdf1
[Wed Feb 11 01:02:18 2015] disk 4, o:1, dev:sdb1
[Wed Feb 11 01:02:18 2015] RAID conf printout:
[Wed Feb 11 01:02:18 2015] --- level:5 rd:5 wd:3
[Wed Feb 11 01:02:18 2015] disk 1, o:1, dev:sdd1
[Wed Feb 11 01:02:18 2015] disk 3, o:1, dev:sdf1
[Wed Feb 11 01:02:18 2015] disk 4, o:1, dev:sdb1
Thanks again,
Kyle L
On Tue, Feb 10, 2015 at 9:14 PM, Phil Turmel <philip@turmel.org> wrote:
>
> Hi Kyle,
>
> { Convention on kernel.org lists is reply-to-all, trim replies, and
> either bottom post or interleave }
>
> On 02/10/2015 04:50 PM, Kyle Logue wrote:
> > Phil:
> >
> > Thanks for your detailed response. That link does seem to describe my
> > problem and I do understand that desktop grade drives are sub-optimal.
> > It was many years ago when I first set up this array on my home
> > theater pc. Until now I had no idea about the cron job - I'll make
> > sure to implement that. I am preparing to move to 6 tb disks sometime
> > soon and i'll definitely go enterprise this time.
> >
> > Regarding the drive timeout: I understand that I need to increase it
> > from 30 seconds to something larger (2+ min) but am unaware how to do
> > this. Is it a kernel variable? I'll keep googling but this seems like
> > it's whats going to save me.
> >
> > tl;dr: How do I change the drive timeout?
>
> Put something like this in /etc/rc.local or wherever your distro suggests:
>
> for x in /sys/block/sd[a-f]/device/timeout ; do
> echo 180 > $x
> done
>
> Where the [a-f] is adjusted to suit your needs, and only for non-raid
> non-scterc drives.
>
> Phil
^ permalink raw reply
* RAID 1 metadata - keep separate from mirror disks ?
From: Suresh Babu Kandukuru @ 2015-02-11 12:14 UTC (permalink / raw)
To: linux-raid
Hi There,
On the RAID 1 metadata: is there any way to keep the metadata separate from the mirror disks? Could you guide us on this ?, please. In general, we need to keep all metadata off the device itself, leaving all the device available for user data. This is particularly important in the migration case, where we want to take an existing LUN and add a second leg to it to create the mirror device without changing any of the data or metadata on the LUN.
Thanks
/Suresh
^ permalink raw reply
* Re: Wierd: Degrading while recovering raid5
From: Phil Turmel @ 2015-02-11 14:28 UTC (permalink / raw)
To: Kyle Logue, linux-raid
In-Reply-To: <CAP7a4URzYsvw9aEd117FAs9_AE4fk1FuHQAmQQqreb3Y1yvOdg@mail.gmail.com>
On 02/11/2015 01:23 AM, Kyle Logue wrote:
> Phil:
>
> For a while I really thought that was going to work. I swapped out the
> sata cable and set the timeout to 10 minutes. At about 70% rebuilt I
> got the following dmesg which seems to indicate the death of my sdc
> drive.
Ten minutes is way overkill. The three minutes I suggested is already
extreme, and most drives will only need two minutes.
> Here is my question: I still have this sde that I manually failed and
> hasn't been touched. Can i force re-add it to the array and just take
> the data corruption hit?
No, sde is being replaced by sda, so it's no help for sdc. If you put
it back into service, it would have to take the role of sda. (Forced
assembly, though, not a re-add.) If the array was in use during your
first replacement attempt, the differences could be substantial.
I'm not sure how MD will handle the rebuild status in this case.
Hopefully, it will take you back to a working, non-rebuilding array. If
you try this, you should test with a set of overlay devices as described
on the wiki.
> I'd rather have to revert part of my data than all of it. The drive
> counts are significantly different now, but I haven't mounted the
> drives since the beginning. I haven't tried it but I saw someone else
> online get a message like 'raid has failed so using --add cannot work
> and might destroy data'. Is there a force add? What are my chances?
The right answer here depends on whether the array was in use. If it
wasn't, I'd try to use sde in place of sda to get back to a
non-rebuilding array. If the test run succeeds, undo the overlays and
do it for real. Then zero the superblock on sda, add it back as a
spare, then --replace sdc.
If the trial doesn't work (or the changes to sda too great), the
alternative is to ddrescue sdc onto a spare disk (sde would be available
at that point, if it's useless for assembly). Then manually reassemble
and let the rebuild finish. If you run into more errors on the other
members, you may have to repeat the ddrescue process for each.
Whichever path you take, when done, consider switching to raid6 using
the extra drive. That's far more secure than a hot spare (if a little
slower).
I did notice one other issue in your posted dmesg: misaligned
partitions. This cripples MD's ability to fix UREs on the fly or during
a scrub. You *must* rebuild your array with properly aligned partitions
before you quit.
Phil
^ permalink raw reply
* Re: RAID 1 metadata - keep separate from mirror disks ?
From: Phil Turmel @ 2015-02-11 14:49 UTC (permalink / raw)
To: Suresh Babu Kandukuru, linux-raid
In-Reply-To: <79c7cd53-bb6c-4058-95ad-7ebd56cf1056@default>
Good morning Suresh,
On 02/11/2015 07:14 AM, Suresh Babu Kandukuru wrote:
> Hi There,
>
> On the RAID 1 metadata: is there any way to keep the metadata
> separate from the mirror disks? Could you guide us on this ?,
> please. In general, we need to keep all metadata off the device
> itself, leaving all the device available for user data. This is
> particularly important in the migration case, where we want to take
> an existing LUN and add a second leg to it to create the mirror
> device without changing any of the data or metadata on the LUN.
If you look at "man 4 md" you'll see some options. If a legacy array
type meets your needs, you can operate without metadata at all. Use
"mdadm --build" to assemble your raid at each boot.
Or, if your storage server can insert a leg ahead of you current LUN,
you can then create the array with an explicit data offset matching the
size of the inserted leg. Create it degraded with the existing LUN,
then add (a) LUN(s) to start mirroring. This process will leave you the
option to resize with more legs later.
Or you can add a leg to the end and create your array with version 1.0
metadata, which is placed at the end of the device.
Finally, you could write your own metadata container service for use
with mdmon. (That's a bit beyond my ability, sorry.)
Phil
^ permalink raw reply
* Re: [PATCH 00/24] Clustered MD RAID1
From: Goldwyn Rodrigues @ 2015-02-11 17:25 UTC (permalink / raw)
To: NeilBrown; +Cc: lzhong, linux-raid
In-Reply-To: <20150211151709.510005d2@notabene.brown>
Hi Neil,
On 02/10/2015 10:17 PM, NeilBrown wrote:
> On Tue, 10 Feb 2015 11:00:31 -0600 Goldwyn Rodrigues <rgoldwyn@suse.de> wrote:
>
>> Hi Neil,
>>
>>>
>>>
>>> hi Goldwyn,
>>> thanks for these - and sorry for the long delay. Lots of leave over
>>> southern summer, and the lots of email etc to deal with.
>>>
>>> This patch set is very close and I am tempted to just apply it and then
>>> fix things up with subsequent patches. In order to allow that, could you
>>> please:
>>> - rebase against current upstream
>>> - fix the checkpatch.pl errors and warnings.
>>> The "WARNING: line over 80 characters" are often a judgement call
>>> so I'm not particularly worried about those. Most, if not all, of
>>> the others should be followed just to have consistent layout.
>>
>> Done.
>
> ERROR: code indent should use tabs where possible
>
> when you use spaces, they show up in red for me!!
> Ditto for
> WARNING: please, no space before tabs
>
> WARNING: quoted string split across lines
> It really is best to fix those, even though it makes the line long.
> When grepping to find out where a message comes from, it is very annoying
> if the grep fails because the line was split.
>
> WARNING: Missing a blank line after declarations
> Worth fixing I think.
>
> WARNING: printk() should include KERN_ facility level
> Definitely should be fixed, maybe make it pr_warn()??
>
Ok, my review was not good. I have incorporated all of these and put
them in the same branch. Sorry for the trouble.
> "Introduce md_cluster_info" moves 'bast' to a new location in
> dlm_lock_resource for no apparent reason.
> Also 'leave()' has a parameter which is changed from 'md' to 'mddev',
> as does 'join'.
>
> "Add node recovery callbacks" adds a comment to the 'nodes' field of 'struct
> mddev'. Why not add the comment when the field is added?
> Oh, and it mis-spells "unmber".
>
>
> In "Gather on-going resync information of other nodes" you have:
>
> static struct md_cluster_operations cluster_ops = {
> .join = join,
> .leave = leave,
> - .slot_number = slot_number
> + .slot_number = slot_number,
> + .resync_info_update = resync_info_update
> };
>
>
> It is really best to put a comma at the end of each entry, even the last.
> Then the patch would have been:
>
> static struct md_cluster_operations cluster_ops = {
> .join = join,
> .leave = leave,
> .slot_number = slot_number,
> + .resync_info_update = resync_info_update,
> };
>
> which is much nicer to read. You finally get this right in
> "Suspend writes in RAID1 if within range" :-)
Ok, I have fixed them in all the patches.
>>>
>>> - I'm a bit concerned about the behaviour on node failure.
>>> When a node fails, two things must happen w.r.t the bits in that node's
>>> bitmap.
>>> 1/ The corresponding regions of the array need to be resynced. You do have
>>> code to do this.
>>> 2/ Other nodes must avoid read-balancing on those regions until the
>>> resync has completed.
>>>
>>> You do have code for this second bit, but it looks wrong. It avoids
>>> read-balancing if ->area_resyncing(). That isn't sufficient.
>>> The "area_resyncing" is always (I assume) a relatively small region of
>>> the array which will be completely resynced quite quickly. It must be
>>> because writes are blocked to this area. However the region in which
>>> we must disable re-balancing can be much larger. It covers *all* bits
>>> that are set in any unsynced bitmap. So it isn't just the area that is
>>> currently being synced, but all areas that will be synced.
>>
>> What are unsynced bitmaps? Are they bitmaps which are associated with an
>> active node or dirty bitmaps with dead nodes? If it is the former, I
>> agree this is not enough. If it is latter, all nodes maintain a linked
>> list of all the nodes which are currently performing resync (probably
>> because of multiple nodes died simultaneously). One node performs the
>> recovery (aka bitmap resync) of exactly one "dead" node at a time.
>> area_resyncing goes through all the nodes which are performing resync.
>
> The later - bitmaps associated with a dead node.
> Bitmaps associated with an active node contain transient information, and the
> filesystem will ensure that it never reads from somewhere that someone else
> might be writing (or if it does, it will know that the data cannot be
> trusted).
>
> I looked at the code again, and discovered that I had the problem backwards.
> But there is still a problem.
>
> when any node is resyncing, your code blocks writes for the entire span of the
> array from where-ever the resync is up to, to the end of the device.
> So a write to a location near the end of the device will hang until all
> resyncs finish. This could be a much longer time than you would like writes
> to hang for.
>
> I think that the resyncing host should only report that it is resyncing a
> relatively small range of the array, maybe 100Meg. Maybe 1G.
> Then that would only block access to that small part of the array, which
> should clear in just a few seconds at most.
>
> This information on the range being synced is not enough to limit
> read-balancing.
> I imagined that *every* node would read the bitmap for a failed node, and
> would use that information to limit read-balancing. There are some
> complexities in this though.
>
>
> So the current code isn't "wrong" exactly, but it think it could cause sever
> delays in some (unusual) circumstances.
I thought about this as well and this is what I think we should do for a
node failure:
Attempt a PW lock (DLM_LKF_NOQUEUE) on the failed nodes bitmap. If
successful:
a. Read the bitmap.
b. Update the bitmap LVB with the resync details.
c. Send the RESYNCING message
d. Perform the resync and update the LVB as we proceed. (This means we
will have to write another resync function independent of md_do_sync)
area_resyncing:
a. Check the resyncing node list. If not found, or is out of range,
return 0.
b. If an entry exists with overlapping range of I/O, take a CR lock on
bitmap-<nodenum>.
c. Read the LVB for limits and update limits in the resyncing node list.
d. If read/write range is not within new range details, unlock CR and
return 0
e. If read/write is within range, read the bitmap and check for
interfering bitmaps. If not interfering return 0 else return 1. Perhaps
we could reserve the bitmap.
Using step c,d may make it a wee bit faster without the need to going to
the disk.
The problem I see in this approach is cascading failures. What should we
do if the node performing the resync for a recently failed node also
fails? How do we detect that the failed node was performing a resync for
another node? One option is we could add that information in the
RESYNCING message. Can you think of something better?
The way it is being done now is that we aggressively (no NOQUEUE) take
the bitmap lock and the resyncing node copies the bits into its own
bitmap and clears the failed bitmap before releasing the bitmap lock.
Finally, should we put some sort of versioning in the messages for
rolling upgrades? (One node is on a higher kernel version with respect
to the rest of the nodes)
--
Goldwyn
^ permalink raw reply
* please help - raid 1 degraded
From: sunruh @ 2015-02-11 18:04 UTC (permalink / raw)
To: linux-raid
centos 6.6
2x 240gig ssd in raid1
this is a live running production machine and the raid1 is for /u of
users home dirs.
1 ssd went totally offline and i replaced it after noticing the firmware
levels are not the same. the new ssd has the same level firmware.
/dev/sdb is the good ssd
/dev/sdc is the new blank ssd
when working it was /u1 from /dev/md127p1 and /u2 from /dev/md127p2
p1 is 80gig and p2 is 160gig for the full 240gig size of the ssd
> ls -al /dev/md*
brw-rw---- 1 root disk 9, 127 Feb 11 11:09 /dev/md127
brw-rw---- 1 root disk 259, 0 Feb 10 20:23 /dev/md127p1
brw-rw---- 1 root disk 259, 1 Feb 10 20:23 /dev/md127p2
/dev/md:
total 8
drwxr-xr-x 2 root root 140 Feb 10 20:24 .
drwxr-xr-x 20 root root 3980 Feb 10 20:24 ..
lrwxrwxrwx 1 root root 8 Feb 11 11:09 240ssd_0 -> ../md127
lrwxrwxrwx 1 root root 10 Feb 10 20:23 240ssd_0p1 -> ../md127p1
lrwxrwxrwx 1 root root 10 Feb 10 20:23 240ssd_0p2 -> ../md127p2
-rw-r--r-- 1 root root 5 Feb 10 20:24 autorebuild.pid
-rw------- 1 root root 63 Feb 10 20:23 md-device-map
> ps -eaf | grep mdadm
root 2188 1 0 Feb10 ? 00:00:00 mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid
how do i rebuild /dev/sdc into the mirror of /dev/sdb?
and thanks much for the help!
steve
^ permalink raw reply
* Re: dead RAID6 array on CentOS6.6 / kernel 3.19
From: Adam Thompson @ 2015-02-11 18:21 UTC (permalink / raw)
To: NeilBrown, Phil Turmel; +Cc: linux-raid, Cordes, Trevor
In-Reply-To: <20150211152605.0c1bf94e@notabene.brown>
On 2015-02-10 10:26 PM, NeilBrown wrote:
>>> Also, kernel 3.19, which I mentioned we're running, pretty much *is* my
>>> definition of an up-to-date kernel... how much newer do you want me to
>>> try, and where would you recommend I find such a thing in a bootable image?
>> You're right, 3.19 should be fine. I'm stumped. Looks like a bug.
>> Adding Neil ....
> I think it is an mdadm bug. I don't see a mention of mdadm version number
> (but I didn't look very hard).
> If you are using 3.3, update to at least 3.3.1
>
> (just
> cd /tmp
> git clone git://neil.brown.name/mdadm
> cd mdadm
> make
> ./mdadm --assemble --force /dev/md127 .....
> )
>
> NeilBrown
So, I'm already running mdadm v3.3 from CentOS 6.6 (the precise package
version# is in the original message).
I've tried building the latest-and-greatest, but fail on the RUN_DIR
check. Looks like it can be disabled with no downside... yup, compiles
with no errors now.
Yay! mdadm from git was able to reassemble the array:
(I find it interesting that it bumped the event count up to 26307...
*again*. Old v3.3 mdadm already claims to have done exactly that.)
> [root@muug mdadm]# ./mdadm --verbose --assemble --force /dev/md127
> /dev/sd[a-l]
> mdadm: looking for devices for /dev/md127
> mdadm: failed to get exclusive lock on mapfile - continue anyway...
> mdadm: /dev/sda is identified as a member of /dev/md127, slot 11.
> mdadm: /dev/sdb is identified as a member of /dev/md127, slot 2.
> mdadm: /dev/sdc is identified as a member of /dev/md127, slot 1.
> mdadm: /dev/sdd is identified as a member of /dev/md127, slot 3.
> mdadm: /dev/sde is identified as a member of /dev/md127, slot 5.
> mdadm: /dev/sdf is identified as a member of /dev/md127, slot 6.
> mdadm: /dev/sdg is identified as a member of /dev/md127, slot 7.
> mdadm: /dev/sdh is identified as a member of /dev/md127, slot 4.
> mdadm: /dev/sdi is identified as a member of /dev/md127, slot 8.
> mdadm: /dev/sdj is identified as a member of /dev/md127, slot 9.
> mdadm: /dev/sdk is identified as a member of /dev/md127, slot 10.
> mdadm: /dev/sdl is identified as a member of /dev/md127, slot 0.
> mdadm: forcing event count in /dev/sdf(6) from 26263 upto 26307
> mdadm: forcing event count in /dev/sdg(7) from 26263 upto 26307
> mdadm: forcing event count in /dev/sda(11) from 26263 upto 26307
> mdadm: clearing FAULTY flag for device 5 in /dev/md127 for /dev/sdf
> mdadm: clearing FAULTY flag for device 6 in /dev/md127 for /dev/sdg
> mdadm: clearing FAULTY flag for device 0 in /dev/md127 for /dev/sda
> mdadm: Marking array /dev/md127 as 'clean'
> mdadm: added /dev/sdc to /dev/md127 as 1
> mdadm: added /dev/sdb to /dev/md127 as 2
> mdadm: added /dev/sdd to /dev/md127 as 3
> mdadm: added /dev/sdh to /dev/md127 as 4
> mdadm: added /dev/sde to /dev/md127 as 5
> mdadm: added /dev/sdf to /dev/md127 as 6
> mdadm: added /dev/sdg to /dev/md127 as 7
> mdadm: added /dev/sdi to /dev/md127 as 8
> mdadm: added /dev/sdj to /dev/md127 as 9
> mdadm: added /dev/sdk to /dev/md127 as 10
> mdadm: added /dev/sda to /dev/md127 as 11
> mdadm: added /dev/sdl to /dev/md127 as 0
> mdadm: /dev/md127 has been started with 12 drives.
> [root@muug mdadm]# cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4] [raid10]
> md127 : active raid6 sdl[12] sda[13] sdk[10] sdj[9] sdi[8] sdg[7]
> sdf[6] sde[5] sdh[4] sdd[3] sdb[2] sdc[1]
> 39068875120 blocks super 1.2 level 6, 4k chunk, algorithm 2
> [12/12] [UUUUUUUUUUUU]
> bitmap: 0/30 pages [0KB], 65536KB chunk
>
> md0 : active raid1 sdm1[0] sdn1[1]
> 1048512 blocks super 1.0 [2/2] [UU]
> bitmap: 0/1 pages [0KB], 65536KB chunk
>
> unused devices: <none>
Kernel messages accompanying this:
> Feb 11 11:53:46 muug kernel: md: md127 stopped.
> Feb 11 11:53:47 muug kernel: md: bind<sdc>
> Feb 11 11:53:47 muug kernel: md: bind<sdb>
> Feb 11 11:53:47 muug kernel: md: bind<sdd>
> Feb 11 11:53:47 muug kernel: md: bind<sdh>
> Feb 11 11:53:47 muug kernel: md: bind<sde>
> Feb 11 11:53:47 muug kernel: md: bind<sdf>
> Feb 11 11:53:47 muug kernel: md: bind<sdg>
> Feb 11 11:53:47 muug kernel: md: bind<sdi>
> Feb 11 11:53:47 muug kernel: md: bind<sdj>
> Feb 11 11:53:47 muug kernel: md: bind<sdk>
> Feb 11 11:53:47 muug kernel: md: bind<sda>
> Feb 11 11:53:47 muug kernel: md: bind<sdl>
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sdl operational as
> raid disk 0
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sda operational as
> raid disk 11
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sdk operational as
> raid disk 10
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sdj operational as
> raid disk 9
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sdi operational as
> raid disk 8
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sdg operational as
> raid disk 7
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sdf operational as
> raid disk 6
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sde operational as
> raid disk 5
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sdh operational as
> raid disk 4
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sdd operational as
> raid disk 3
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sdb operational as
> raid disk 2
> Feb 11 11:53:47 muug kernel: md/raid:md127: device sdc operational as
> raid disk 1
> Feb 11 11:53:47 muug kernel: md/raid:md127: allocated 0kB
> Feb 11 11:53:47 muug kernel: md/raid:md127: raid level 6 active with
> 12 out of 12 devices, algorithm 2
> Feb 11 11:53:47 muug kernel: created bitmap (30 pages) for device md127
> Feb 11 11:53:47 muug kernel: md127: bitmap initialized from disk: read
> 2 pages, set 280 of 59615 bits
> Feb 11 11:53:48 muug kernel: md127: detected capacity change from 0 to
> 40006528122880
> Feb 11 11:53:48 muug kernel: md127: unknown partition table
Then, since it's an LVM PV:
> [root@muug ~]# pvscan
> PV /dev/sdm2 VG vg00 lvm2 [110.79 GiB / 0 free]
> PV /dev/sdn2 VG vg00 lvm2 [110.79 GiB / 24.00 MiB free]
> PV /dev/md127 VG vg00 lvm2 [36.39 TiB / 0 free]
> Total: 3 [36.60 TiB] / in use: 3 [36.60 TiB] / in no VG: 0 [0 ]
> [root@muug ~]# vgscan
> Reading all physical volumes. This may take a while...
> Found volume group "vg00" using metadata type lvm2
> [root@muug ~]# lvscan
> ACTIVE '/dev/vg00/root' [64.00 GiB] inherit
> ACTIVE '/dev/vg00/swap' [32.00 GiB] inherit
> inactive '/dev/vg00/ARRAY' [36.39 TiB] inherit
> inactive '/dev/vg00/cache' [30.71 GiB] inherit
> [root@muug ~]# lvchange -a y /dev/vg00/ARRAY
> Feb 11 12:04:15 muug kernel: md/raid1:mdX: active with 2 out of 2 mirrors
> Feb 11 12:04:15 muug kernel: created bitmap (31 pages) for device mdX
> Feb 11 12:04:15 muug kernel: mdX: bitmap initialized from disk: read 2
> pages, set 636 of 62904 bits
> Feb 11 12:04:15 muug kernel: md/raid1:mdX: active with 2 out of 2 mirrors
> Feb 11 12:04:15 muug kernel: created bitmap (1 pages) for device mdX
> Feb 11 12:04:15 muug kernel: mdX: bitmap initialized from disk: read 1
> pages, set 1 of 64 bits
> Feb 11 12:04:15 muug kernel: device-mapper: cache-policy-mq: version
> 1.3.0 loaded
> Feb 11 12:04:16 muug lvm[1418]: Monitoring RAID device
> vg00-cache_cdata for events.
> Feb 11 12:04:16 muug lvm[1418]: Monitoring RAID device
> vg00-cache_cmeta for events.
> [root@muug ~]# lvs
> LV VG Attr LSize Pool Origin Data% Meta% Move
> Log Cpy%Sync Convert
> ARRAY vg00 Cwi-a-C--- 36.39t cache [ARRAY_corig]
> cache vg00 Cwi---C--- 30.71g
> root vg00 rwi-aor---
> 64.00g 100.00
> swap vg00 -wi-ao---- 32.00g
> [root@muug ~]# mount -oro /dev/vg00/ARRAY /ARRAY
> Feb 11 12:04:37 muug kernel: XFS (dm-17): Mounting V4 Filesystem
> Feb 11 12:04:38 muug kernel: XFS (dm-17): Ending clean mount
> [root@muug ~]# umount /ARRAY
> [root@muug ~]# mount /ARRAY
> Feb 11 12:04:45 muug kernel: XFS (dm-17): Mounting V4 Filesystem
> Feb 11 12:04:45 muug kernel: XFS (dm-17): Ending clean mount
> [root@muug ~]# df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/vg00-root
> 63G 22G 39G 36% /
> tmpfs 16G 0 16G 0% /dev/shm
> /dev/md0 1008M , 278M 680M 29% /boot
> /dev/mapper/vg00-ARRAY
> 37T 16T 21T 43% /ARRAY
Wow... xfs_check (xfs_db, actually) needed ~40GB of RAM to check the
filesystem... but it thinks everything's OK.
The big question I have now:
If it's a bug in:
mdadm v3.3 and/or
CentOS 6.6 rc scripts and/or
kernel 3.19,
what should I do to prevent future re-occurrences of the same
problem? I don't want to have to keep buying new underwear... ;-)
--
-Adam Thompson
athompso@athompso.net
+1 (204) 291-7950 - cell
+1 (204) 489-6515 - fax
^ permalink raw reply
* [PATCH 0/1] RFC: Use /dev/md/X as default name
From: Jes.Sorensen @ 2015-02-11 19:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, Jes Sorensen
From: Jes Sorensen <Jes.Sorensen@redhat.com>
I have received some issues for when creating an array using a
/dev/mdX name, the matching symlink in /dev/md/X isn't
created. Whereas if you create /dev/md/X, /dev/mdX is created
automatically.
I was trying to see if there was a better way of dealing with this,
but I couldn't find one. If you have suggestions for a better solution
I am all ears.
Thoughts?
Jes
Jes Sorensen (1):
mddev_create(): choose /dev/md/ name over /dev/mdX
mdopen.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--
2.1.0
^ permalink raw reply
* [PATCH 1/1] mddev_create(): choose /dev/md/ name over /dev/mdX
From: Jes.Sorensen @ 2015-02-11 19:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, Jes Sorensen
In-Reply-To: <1423684389-10977-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
/dev/mdX is created automatically if we create /dev/md/X, but
/dev/md/X isn't created automatically if we create /dev/mdX.
By chosing /dev/md/X as the default name from /dev/mdX, we achieve
consistency when creating new arrays.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
mdopen.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mdopen.c b/mdopen.c
index 2c9d745..db75d09 100644
--- a/mdopen.c
+++ b/mdopen.c
@@ -338,7 +338,11 @@ int create_mddev(char *dev, char *name, int autof, int trustworthy,
sprintf(devname, "/dev/%s", devnm);
- if (dev && dev[0] == '/')
+ if (dev && strncmp(dev, "/dev/md", 7) == 0 &&
+ dev[7] != '/' && strlen(dev) > 7) {
+ strcpy(chosen, "/dev/md/");
+ strcpy(chosen + 8, dev + 7);
+ } else if (dev && dev[0] == '/')
strcpy(chosen, dev);
else if (cname[0] == 0)
strcpy(chosen, devname);
--
2.1.0
^ permalink raw reply related
* All drive in Raid 5 are in 'spare' mode
From: Dush @ 2015-02-11 19:56 UTC (permalink / raw)
To: linux-raid@vger.kernel.org
Hi,
I have a RAID 5 composed by 4x 500Go hdd but for some days, it's 'inactive'.
I'm not raid expert and I prefer asking before doing an unrecoverable mistake...
Is it possible to fix this raid (md126)?
Is it possible to recover data on it?
Do I have a disk to change or it's "just" a desynchronization between disks?
Thanks for your help
# mdadm --version
mdadm - v3.3.2 - 21st August 2014
Linux Kernel: 3.18.2-2
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdd2[2] sde2[1] sdc2[0] sdb2[3]
16530624 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
md126 : inactive sde3[1](S) sdd3[4](S) sdc3[0](S) sdb3[3](S)
1929888000 blocks
unused devices: <none>
# mdadm --examine /dev/sd[a-z]3
mdadm: No md superblock detected on /dev/sda3.
/dev/sdb3:
Magic : a92b4efc
Version : 0.90.00
UUID : 3327f442:a00b59b2:1397f3c2:236c0edf
Creation Time : Tue Jan 27 13:03:52 2009
Raid Level : raid5
Used Dev Size : 482472000 (460.12 GiB 494.05 GB)
Array Size : 1447416000 (1380.36 GiB 1482.15 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 126
Update Time : Wed Jan 21 20:55:48 2015
State : active
Active Devices : 3
Working Devices : 4
Failed Devices : 1
Spare Devices : 1
Checksum : 6e656c69 - correct
Events : 49656
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 3 8 19 3 active sync /dev/sdb3
0 0 8 35 0 active sync /dev/sdc3
1 1 8 67 1 active sync /dev/sde3
2 2 0 0 2 faulty removed
3 3 8 19 3 active sync /dev/sdb3
4 4 8 51 4 spare /dev/sdd3
/dev/sdc3:
Magic : a92b4efc
Version : 0.90.00
UUID : 3327f442:a00b59b2:1397f3c2:236c0edf
Creation Time : Tue Jan 27 13:03:52 2009
Raid Level : raid5
Used Dev Size : 482472000 (460.12 GiB 494.05 GB)
Array Size : 1447416000 (1380.36 GiB 1482.15 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 126
Update Time : Wed Jan 21 23:34:52 2015
State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 2
Spare Devices : 1
Checksum : 6e6653d5 - correct
Events : 49666
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 0 8 35 0 active sync /dev/sdc3
0 0 8 35 0 active sync /dev/sdc3
1 1 8 67 1 active sync /dev/sde3
2 2 0 0 2 faulty removed
3 3 0 0 3 faulty removed
4 4 8 51 4 spare /dev/sdd3
/dev/sdd3:
Magic : a92b4efc
Version : 0.90.00
UUID : 3327f442:a00b59b2:1397f3c2:236c0edf
Creation Time : Tue Jan 27 13:03:52 2009
Raid Level : raid5
Used Dev Size : 482472000 (460.12 GiB 494.05 GB)
Array Size : 1447416000 (1380.36 GiB 1482.15 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 126
Update Time : Wed Jan 21 23:34:52 2015
State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 2
Spare Devices : 1
Checksum : 6e6653e7 - correct
Events : 49666
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 4 8 51 4 spare /dev/sdd3
0 0 8 35 0 active sync /dev/sdc3
1 1 8 67 1 active sync /dev/sde3
2 2 0 0 2 faulty removed
3 3 0 0 3 faulty removed
4 4 8 51 4 spare /dev/sdd3
/dev/sde3:
Magic : a92b4efc
Version : 0.90.00
UUID : 3327f442:a00b59b2:1397f3c2:236c0edf
Creation Time : Tue Jan 27 13:03:52 2009
Raid Level : raid5
Used Dev Size : 482472000 (460.12 GiB 494.05 GB)
Array Size : 1447416000 (1380.36 GiB 1482.15 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 126
Update Time : Wed Jan 21 23:34:52 2015
State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 2
Spare Devices : 1
Checksum : 6e6653f7 - correct
Events : 49666
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 1 8 67 1 active sync /dev/sde3
0 0 8 35 0 active sync /dev/sdc3
1 1 8 67 1 active sync /dev/sde3
2 2 0 0 2 faulty removed
3 3 0 0 3 faulty removed
4 4 8 51 4 spare /dev/sdd3
^ permalink raw reply
* [PATCH RESEND] Change way of printing name of a process
From: Pawel Baldysiak @ 2015-02-11 21:25 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, pawel.baldysiak, artur.paszkiewicz
Sometimes mdadm prints messages with wrong name "mdmon",
and vice versa.
This patch solves this problem by changing method of determining
process name.
Now "Name" will be set in const at start of a program,
previously was hardcoded as #define.
Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
---
Grow.c | 18 +++++++++---------
Incremental.c | 4 ++--
Monitor.c | 4 ++--
ReadMe.c | 2 +-
mdadm.c | 7 ++++---
mdadm.h | 6 +++---
mdmon.c | 2 ++
mdmon.h | 3 +--
super-intel.c | 2 +-
sysfs.c | 8 ++++----
xmalloc.c | 12 ++++++++----
11 files changed, 37 insertions(+), 31 deletions(-)
diff --git a/Grow.c b/Grow.c
index 6ff225a..4a01a31 100644
--- a/Grow.c
+++ b/Grow.c
@@ -1919,7 +1919,7 @@ size_change_error:
int err;
err = remove_disks_for_takeover(st, sra, array.layout);
if (err) {
- dprintf(Name": Array cannot be reshaped\n");
+ dprintf("%s: Array cannot be reshaped\n", Name);
if (cfd > -1)
close(cfd);
rv = 1;
@@ -2133,7 +2133,7 @@ static int verify_reshape_position(struct mdinfo *info, int level)
char *ep;
unsigned long long position = strtoull(buf, &ep, 0);
- dprintf(Name": Read sync_max sysfs entry is: %s\n", buf);
+ dprintf("%s: Read sync_max sysfs entry is: %s\n", Name, buf);
if (!(ep == buf || (*ep != 0 && *ep != '\n' && *ep != ' '))) {
position *= get_data_disks(level,
info->new_layout,
@@ -3494,8 +3494,8 @@ int reshape_container(char *container, char *devname,
return 1;
default: /* parent */
if (!freeze_reshape)
- printf(Name ": multi-array reshape continues"
- " in background\n");
+ printf("%s: multi-array reshape continues"
+ " in background\n", Name);
return 0;
case 0: /* child */
map_fork();
@@ -3557,8 +3557,8 @@ int reshape_container(char *container, char *devname,
fd = open_dev(mdstat->devnm);
if (fd < 0) {
- printf(Name ": Device %s cannot be opened for reshape.",
- adev);
+ printf("%s: Device %s cannot be opened for reshape.",
+ Name, adev);
break;
}
@@ -3573,8 +3573,8 @@ int reshape_container(char *container, char *devname,
* This is possibly interim until the behaviour of
* reshape_array is resolved().
*/
- printf(Name ": Multiple reshape execution detected for "
- "device %s.", adev);
+ printf("%s: Multiple reshape execution detected for "
+ "device %s.", Name, adev);
close(fd);
break;
}
@@ -4611,7 +4611,7 @@ int Grow_restart(struct supertype *st, struct mdinfo *info, int *fdlist, int cnt
st->ss->free_super(st);
offsets[j] = dinfo.data_offset * 512;
}
- printf(Name ": restoring critical section\n");
+ printf("%s: restoring critical section\n", Name);
if (restore_stripes(fdlist, offsets,
info->array.raid_disks,
diff --git a/Incremental.c b/Incremental.c
index 13b68bc..38c9989 100644
--- a/Incremental.c
+++ b/Incremental.c
@@ -1710,9 +1710,9 @@ int IncrementalRemove(char *devname, char *id_path, int verbose)
char buf[32];
if (!id_path)
- dprintf(Name ": incremental removal without --path <id_path> "
+ dprintf("%s: incremental removal without --path <id_path> "
"lacks the possibility to re-add new device in this "
- "port\n");
+ "port\n", Name);
if (strchr(devname, '/')) {
pr_err("incremental removal requires a "
diff --git a/Monitor.c b/Monitor.c
index 971d2ec..7a5203c 100644
--- a/Monitor.c
+++ b/Monitor.c
@@ -381,14 +381,14 @@ static void alert(char *event, char *dev, char *disc, struct alert_info *info)
if (info->mailfrom)
fprintf(mp, "From: %s\n", info->mailfrom);
else
- fprintf(mp, "From: " Name " monitoring <root>\n");
+ fprintf(mp, "From: %s monitoring <root>\n", Name);
fprintf(mp, "To: %s\n", info->mailaddr);
fprintf(mp, "Subject: %s event on %s:%s\n\n",
event, dev, hname);
fprintf(mp,
"This is an automatically generated"
- " mail message from " Name "\n");
+ " mail message from %s\n", Name);
fprintf(mp, "running on %s\n\n", hname);
fprintf(mp,
diff --git a/ReadMe.c b/ReadMe.c
index 445c388..87a4916 100644
--- a/ReadMe.c
+++ b/ReadMe.c
@@ -30,7 +30,7 @@
#ifndef VERS_DATE
#define VERS_DATE "21st August 2014"
#endif
-char Version[] = Name " - v" VERSION " - " VERS_DATE "\n";
+char Version[] = "mdadm - v" VERSION " - " VERS_DATE "\n";
/*
* File: ReadMe.c
diff --git a/mdadm.c b/mdadm.c
index c856fcd..475c71c 100644
--- a/mdadm.c
+++ b/mdadm.c
@@ -38,6 +38,7 @@ static int misc_list(struct mddev_dev *devlist,
struct mddev_ident *ident,
char *dump_directory,
struct supertype *ss, struct context *c);
+const char Name[] = "mdadm";
int main(int argc, char *argv[])
{
@@ -771,12 +772,12 @@ int main(int argc, char *argv[])
if (strcmp(c.update,"?") == 0 ||
strcmp(c.update, "help") == 0) {
outf = stdout;
- fprintf(outf, Name ": ");
+ fprintf(outf, "%s: ", Name);
} else {
outf = stderr;
fprintf(outf,
- Name ": '--update=%s' is invalid. ",
- c.update);
+ "%s: '--update=%s' is invalid. ",
+ Name, c.update);
}
fprintf(outf, "Valid --update options are:\n"
" 'sparc2.2', 'super-minor', 'uuid', 'name', 'resync',\n"
diff --git a/mdadm.h b/mdadm.h
index fc1fd31..c8d079c 100644
--- a/mdadm.h
+++ b/mdadm.h
@@ -180,6 +180,8 @@ extern __off64_t lseek64 __P ((int __fd, __off64_t __offset, int __whence));
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
+extern const char Name[];
+
/* general information that might be extracted from a superblock */
struct mdinfo {
mdu_array_info_t array;
@@ -262,8 +264,6 @@ struct createinfo {
struct supertype *supertype;
};
-#define Name "mdadm"
-
enum mode {
ASSEMBLE=1,
BUILD,
@@ -1457,7 +1457,7 @@ static inline int xasprintf(char **strp, const char *fmt, ...) {
return ret;
}
-#define pr_err(fmt ...) fprintf(stderr, Name ": " fmt)
+#define pr_err(fmt, args...) fprintf(stderr, "%s: "fmt, Name, ##args)
#define cont_err(fmt ...) fprintf(stderr, " " fmt)
void *xmalloc(size_t len);
diff --git a/mdmon.c b/mdmon.c
index 27045a1..ee12b7c 100644
--- a/mdmon.c
+++ b/mdmon.c
@@ -67,6 +67,8 @@
#include "mdadm.h"
#include "mdmon.h"
+char const Name[] = "mdmon";
+
struct active_array *discard_this;
struct active_array *pending_discard;
diff --git a/mdmon.h b/mdmon.h
index 5a8e120..aa750c6 100644
--- a/mdmon.h
+++ b/mdmon.h
@@ -18,8 +18,7 @@
* 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
*/
-#undef pr_err
-#define pr_err(fmt ...) fprintf(stderr, "mdmon: " fmt)
+extern const char Name[];
enum array_state { clear, inactive, suspended, readonly, read_auto,
clean, active, write_pending, active_idle, bad_word};
diff --git a/super-intel.c b/super-intel.c
index 4b23b9a..d900339 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -1386,7 +1386,7 @@ static int imsm_check_attributes(__u32 attributes)
}
if (not_supported)
- dprintf(Name "(IMSM): Unknown attributes : %x\n", not_supported);
+ dprintf("%s (IMSM): Unknown attributes : %x\n", Name, not_supported);
ret_val = 0;
}
diff --git a/sysfs.c b/sysfs.c
index 9a1d856..ceab27f 100644
--- a/sysfs.c
+++ b/sysfs.c
@@ -413,8 +413,8 @@ int sysfs_set_str(struct mdinfo *sra, struct mdinfo *dev,
n = write(fd, val, strlen(val));
close(fd);
if (n != strlen(val)) {
- dprintf(Name ": failed to write '%s' to '%s' (%s)\n",
- val, fname, strerror(errno));
+ dprintf("%s: failed to write '%s' to '%s' (%s)\n",
+ Name, val, fname, strerror(errno));
return -1;
}
return 0;
@@ -450,8 +450,8 @@ int sysfs_uevent(struct mdinfo *sra, char *event)
n = write(fd, event, strlen(event));
close(fd);
if (n != (int)strlen(event)) {
- dprintf(Name ": failed to write '%s' to '%s' (%s)\n",
- event, fname, strerror(errno));
+ dprintf("%s: failed to write '%s' to '%s' (%s)\n",
+ Name, event, fname, strerror(errno));
return -1;
}
return 0;
diff --git a/xmalloc.c b/xmalloc.c
index 8d42a7c..75ae4e2 100644
--- a/xmalloc.c
+++ b/xmalloc.c
@@ -37,7 +37,8 @@ void *xmalloc(size_t len)
char *msg;
if (rv)
return rv;
- msg = Name ": memory allocation failure - aborting\n";
+ msg = ": memory allocation failure - aborting\n";
+ write(2, Name, strlen(Name));
exit(4+!!write(2, msg, strlen(msg)));
}
@@ -47,7 +48,8 @@ void *xrealloc(void *ptr, size_t len)
char *msg;
if (rv)
return rv;
- msg = Name ": memory allocation failure - aborting\n";
+ msg = ": memory allocation failure - aborting\n";
+ write(2, Name, strlen(Name));
exit(4+!!write(2, msg, strlen(msg)));
}
@@ -57,7 +59,8 @@ void *xcalloc(size_t num, size_t size)
char *msg;
if (rv)
return rv;
- msg = Name ": memory allocation failure - aborting\n";
+ msg = ": memory allocation failure - aborting\n";
+ write(2, Name, strlen(Name));
exit(4+!!write(2, msg, strlen(msg)));
}
@@ -67,6 +70,7 @@ char *xstrdup(const char *str)
char *msg;
if (rv)
return rv;
- msg = Name ": memory allocation failure - aborting\n";
+ msg = ": memory allocation failure - aborting\n";
+ write(2, Name, strlen(Name));
exit(4+!!write(2, msg, strlen(msg)));
}
^ permalink raw reply related
* Re: Wierd: Degrading while recovering raid5
From: Kyle Logue @ 2015-02-11 22:12 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <54DB6707.5030901@turmel.org>
Good news phil. Under the hypothesis that the new disk that I added
didn't fully replace my sde I omitted it from my assemble. The array
went full UUUUU, then I echo'd check > /sys/block/md0/md/sync_action
Much later it kicked out the faulty disk (previously sdc) and now i
have a _UUUU.
So hopefully this is the final question, but should I just evacuate as
much data as possible immediately? Or try to add another spare and
rebuild?
Thanks for the help,
Kyle L
^ permalink raw reply
* Re: please help - raid 1 degraded
From: Adam Goryachev @ 2015-02-11 22:12 UTC (permalink / raw)
To: sunruh, linux-raid
In-Reply-To: <20150211180403.GA14805@fnord.prismnet.com>
On 12/02/15 05:04, sunruh@prismnet.com wrote:
> centos 6.6
> 2x 240gig ssd in raid1
> this is a live running production machine and the raid1 is for /u of
> users home dirs.
>
> 1 ssd went totally offline and i replaced it after noticing the firmware
> levels are not the same. the new ssd has the same level firmware.
>
> /dev/sdb is the good ssd
> /dev/sdc is the new blank ssd
>
> when working it was /u1 from /dev/md127p1 and /u2 from /dev/md127p2
> p1 is 80gig and p2 is 160gig for the full 240gig size of the ssd
>
>> ls -al /dev/md*
> brw-rw---- 1 root disk 9, 127 Feb 11 11:09 /dev/md127
> brw-rw---- 1 root disk 259, 0 Feb 10 20:23 /dev/md127p1
> brw-rw---- 1 root disk 259, 1 Feb 10 20:23 /dev/md127p2
>
> /dev/md:
> total 8
> drwxr-xr-x 2 root root 140 Feb 10 20:24 .
> drwxr-xr-x 20 root root 3980 Feb 10 20:24 ..
> lrwxrwxrwx 1 root root 8 Feb 11 11:09 240ssd_0 -> ../md127
> lrwxrwxrwx 1 root root 10 Feb 10 20:23 240ssd_0p1 -> ../md127p1
> lrwxrwxrwx 1 root root 10 Feb 10 20:23 240ssd_0p2 -> ../md127p2
> -rw-r--r-- 1 root root 5 Feb 10 20:24 autorebuild.pid
> -rw------- 1 root root 63 Feb 10 20:23 md-device-map
>
>> ps -eaf | grep mdadm
> root 2188 1 0 Feb10 ? 00:00:00 mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid
>
> how do i rebuild /dev/sdc into the mirror of /dev/sdb?
>
Please send the output of fdisk -lu /dev/sd[bc] and cat /proc/mdstat
(preferably both when it was working and current).
In general, when replacing a failed RAID1 disk, and assuming you
configured it the way I think you did:
1) fdisk -lu /dev/sdb
Find out the exact partition sizes
2) fdisk /dev/sdc
Create the new partitions exactly the same as /dev/sdb
3) mdadm --manage /dev/md127 --add /dev/sdb1
Add the partition to the array
4) cat /proc/mdstat
Watch the rebuild progress, once it is complete, relax.
PS, steps 1 and 2 may not be needed if you are using the full block
device instead of a partition. Also, change the command in step 3 to
"mdadm --manage /dev/md127 --add /dev/sdb"
PPS, if this is a bootable disk, you will probably also need to do
something with your boot manager to get that installed onto the new disk
as well.
Hope this helps, otherwise, please provide more information.
Regards,
Adam
--
Adam Goryachev Website Managers www.websitemanagers.com.au
^ permalink raw reply
* Re: please help - raid 1 degraded
From: sunruh @ 2015-02-12 0:09 UTC (permalink / raw)
To: Adam Goryachev; +Cc: sunruh, linux-raid
In-Reply-To: <54DBD3E2.80701@websitemanagers.com.au>
On Thu, Feb 12, 2015 at 09:12:50AM +1100, Adam Goryachev wrote:
> On 12/02/15 05:04, sunruh@prismnet.com wrote:
> > centos 6.6
> > 2x 240gig ssd in raid1
> > this is a live running production machine and the raid1 is for /u of
> > users home dirs.
> >
> > 1 ssd went totally offline and i replaced it after noticing the firmware
> > levels are not the same. the new ssd has the same level firmware.
> >
> > /dev/sdb is the good ssd
> > /dev/sdc is the new blank ssd
> >
> > when working it was /u1 from /dev/md127p1 and /u2 from /dev/md127p2
> > p1 is 80gig and p2 is 160gig for the full 240gig size of the ssd
> >
> >> ls -al /dev/md*
> > brw-rw---- 1 root disk 9, 127 Feb 11 11:09 /dev/md127
> > brw-rw---- 1 root disk 259, 0 Feb 10 20:23 /dev/md127p1
> > brw-rw---- 1 root disk 259, 1 Feb 10 20:23 /dev/md127p2
> >
> > /dev/md:
> > total 8
> > drwxr-xr-x 2 root root 140 Feb 10 20:24 .
> > drwxr-xr-x 20 root root 3980 Feb 10 20:24 ..
> > lrwxrwxrwx 1 root root 8 Feb 11 11:09 240ssd_0 -> ../md127
> > lrwxrwxrwx 1 root root 10 Feb 10 20:23 240ssd_0p1 -> ../md127p1
> > lrwxrwxrwx 1 root root 10 Feb 10 20:23 240ssd_0p2 -> ../md127p2
> > -rw-r--r-- 1 root root 5 Feb 10 20:24 autorebuild.pid
> > -rw------- 1 root root 63 Feb 10 20:23 md-device-map
> >
> >> ps -eaf | grep mdadm
> > root 2188 1 0 Feb10 ? 00:00:00 mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid
> >
> > how do i rebuild /dev/sdc into the mirror of /dev/sdb?
> >
>
> Please send the output of fdisk -lu /dev/sd[bc] and cat /proc/mdstat
> (preferably both when it was working and current).
>
> In general, when replacing a failed RAID1 disk, and assuming you
> configured it the way I think you did:
> 1) fdisk -lu /dev/sdb
> Find out the exact partition sizes
> 2) fdisk /dev/sdc
> Create the new partitions exactly the same as /dev/sdb
> 3) mdadm --manage /dev/md127 --add /dev/sdb1
> Add the partition to the array
> 4) cat /proc/mdstat
> Watch the rebuild progress, once it is complete, relax.
>
> PS, steps 1 and 2 may not be needed if you are using the full block
> device instead of a partition. Also, change the command in step 3 to
> "mdadm --manage /dev/md127 --add /dev/sdb"
>
> PPS, if this is a bootable disk, you will probably also need to do
> something with your boot manager to get that installed onto the new disk
> as well.
>
> Hope this helps, otherwise, please provide more information.
>
>
> Regards,
> Adam
>
> --
> Adam Goryachev Website Managers www.websitemanagers.com.au
Adam (and anybody else that can help),
after issue i do not have before. and no they are not bootable.
[root@shell ~]# fdisk -lu /dev/sd[bc]
Disk /dev/sdb: 240.1 GB, 240057409536 bytes
255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0001a740
Disk /dev/sdc: 240.1 GB, 240057409536 bytes
255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
[root@shell ~]# cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sdb[2]
234299840 blocks super 1.2 [2/1] [U_]
unused devices: <none>
[root@shell ~]# fdisk -lu /dev/sdb
Disk /dev/sdb: 240.1 GB, 240057409536 bytes
255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0001a740
i dont seem to be seeing the partition sizes or im stupid.
couldnt i just dd if=/dev/sdb of=/dev/sdc bs=1G count=240 and then do the
mdadm?
^ permalink raw reply
* Re: Wierd: Degrading while recovering raid5
From: Phil Turmel @ 2015-02-12 0:15 UTC (permalink / raw)
To: Kyle Logue; +Cc: linux-raid
In-Reply-To: <CAP7a4UR1HzJ9AueEr1e=Zh5+p0=QgODA4=_Bp7bfQ=f2CwPhYg@mail.gmail.com>
On 02/11/2015 05:12 PM, Kyle Logue wrote:
> Good news phil. Under the hypothesis that the new disk that I added
> didn't fully replace my sde I omitted it from my assemble. The array
> went full UUUUU, then I echo'd check > /sys/block/md0/md/sync_action
>
> Much later it kicked out the faulty disk (previously sdc) and now i
> have a _UUUU.
>
> So hopefully this is the final question, but should I just evacuate as
> much data as possible immediately? Or try to add another spare and
> rebuild?
So long as you haven't mounted it yet, I suggest you do another forced
assembly to get back to UUUUU, then kick off another check. When many
UREs are allowed to accumulate, mdadm can hit its read error rate limit
and kick the drive. If it hasn't been mounted, you can keep doing it
until you get through the entire check.
But, you also had misaligned partitions. If sdcN is one of them, the
above won't work, and you should get your backups ASAP. And then make a
new array from scratch.
If you do succeed in completing a check scrub, you can use --replace to
put the array on properly aligned partitions.
Phil
^ permalink raw reply
* Re: please help - raid 1 degraded
From: Adam Goryachev @ 2015-02-12 0:36 UTC (permalink / raw)
To: sunruh; +Cc: linux-raid
In-Reply-To: <20150212000940.GA49579@eris.prismnet.com>
On 12/02/15 11:09, sunruh@prismnet.com wrote:
> On Thu, Feb 12, 2015 at 09:12:50AM +1100, Adam Goryachev wrote:
>> On 12/02/15 05:04, sunruh@prismnet.com wrote:
>>> centos 6.6
>>> 2x 240gig ssd in raid1
>>> this is a live running production machine and the raid1 is for /u of
>>> users home dirs.
>>>
>>> 1 ssd went totally offline and i replaced it after noticing the firmware
>>> levels are not the same. the new ssd has the same level firmware.
>>>
>>> /dev/sdb is the good ssd
>>> /dev/sdc is the new blank ssd
>>>
>>> when working it was /u1 from /dev/md127p1 and /u2 from /dev/md127p2
>>> p1 is 80gig and p2 is 160gig for the full 240gig size of the ssd
>>>
>>>> ls -al /dev/md*
>>> brw-rw---- 1 root disk 9, 127 Feb 11 11:09 /dev/md127
>>> brw-rw---- 1 root disk 259, 0 Feb 10 20:23 /dev/md127p1
>>> brw-rw---- 1 root disk 259, 1 Feb 10 20:23 /dev/md127p2
>>>
>>> /dev/md:
>>> total 8
>>> drwxr-xr-x 2 root root 140 Feb 10 20:24 .
>>> drwxr-xr-x 20 root root 3980 Feb 10 20:24 ..
>>> lrwxrwxrwx 1 root root 8 Feb 11 11:09 240ssd_0 -> ../md127
>>> lrwxrwxrwx 1 root root 10 Feb 10 20:23 240ssd_0p1 -> ../md127p1
>>> lrwxrwxrwx 1 root root 10 Feb 10 20:23 240ssd_0p2 -> ../md127p2
>>> -rw-r--r-- 1 root root 5 Feb 10 20:24 autorebuild.pid
>>> -rw------- 1 root root 63 Feb 10 20:23 md-device-map
>>>
>>>> ps -eaf | grep mdadm
>>> root 2188 1 0 Feb10 ? 00:00:00 mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid
>>>
>>> how do i rebuild /dev/sdc into the mirror of /dev/sdb?
>>>
>> Please send the output of fdisk -lu /dev/sd[bc] and cat /proc/mdstat
>> (preferably both when it was working and current).
>>
>> In general, when replacing a failed RAID1 disk, and assuming you
>> configured it the way I think you did:
>> 1) fdisk -lu /dev/sdb
>> Find out the exact partition sizes
>> 2) fdisk /dev/sdc
>> Create the new partitions exactly the same as /dev/sdb
>> 3) mdadm --manage /dev/md127 --add /dev/sdb1
>> Add the partition to the array
>> 4) cat /proc/mdstat
>> Watch the rebuild progress, once it is complete, relax.
>>
>> PS, steps 1 and 2 may not be needed if you are using the full block
>> device instead of a partition. Also, change the command in step 3 to
>> "mdadm --manage /dev/md127 --add /dev/sdb"
>>
>> PPS, if this is a bootable disk, you will probably also need to do
>> something with your boot manager to get that installed onto the new disk
>> as well.
>>
>> Hope this helps, otherwise, please provide more information.
>>
>>
>> Regards,
>> Adam
>>
>> --
>> Adam Goryachev Website Managers www.websitemanagers.com.au
> Adam (and anybody else that can help),
> after issue i do not have before. and no they are not bootable.
>
> [root@shell ~]# fdisk -lu /dev/sd[bc]
>
> Disk /dev/sdb: 240.1 GB, 240057409536 bytes
> 255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x0001a740
>
>
> Disk /dev/sdc: 240.1 GB, 240057409536 bytes
> 255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
> [root@shell ~]# cat /proc/mdstat
> Personalities : [raid1]
> md127 : active raid1 sdb[2]
> 234299840 blocks super 1.2 [2/1] [U_]
>
> unused devices: <none>
> i dont seem to be seeing the partition sizes or im stupid.
> couldnt i just dd if=/dev/sdb of=/dev/sdc bs=1G count=240 and then do the
> mdadm?
OK, so you aren't using partitioned disks, so it is as simple as what I
said above (with one minor correction):
"mdadm --manage /dev/md127 --add /dev/sdc"
/dev/sdc is the new blank ssd, so that is the one to add, the above
command with /dev/sdb wouldn't have done anything at all .... So just
run that command, and then do "watch cat /proc/mdstat" until the good
stuff is completed.
Regards,
Adam
--
Adam Goryachev Website Managers www.websitemanagers.com.au
^ permalink raw reply
* Re: please help - raid 1 degraded
From: sunruh @ 2015-02-12 1:02 UTC (permalink / raw)
To: Adam Goryachev; +Cc: sunruh, linux-raid
In-Reply-To: <54DBF587.6050004@websitemanagers.com.au>
On Thu, Feb 12, 2015 at 11:36:23AM +1100, Adam Goryachev wrote:
> On 12/02/15 11:09, sunruh@prismnet.com wrote:
> > On Thu, Feb 12, 2015 at 09:12:50AM +1100, Adam Goryachev wrote:
> >> On 12/02/15 05:04, sunruh@prismnet.com wrote:
> >>> centos 6.6
> >>> 2x 240gig ssd in raid1
> >>> this is a live running production machine and the raid1 is for /u of
> >>> users home dirs.
> >>>
> >>> 1 ssd went totally offline and i replaced it after noticing the firmware
> >>> levels are not the same. the new ssd has the same level firmware.
> >>>
> >>> /dev/sdb is the good ssd
> >>> /dev/sdc is the new blank ssd
> >>>
> >>> when working it was /u1 from /dev/md127p1 and /u2 from /dev/md127p2
> >>> p1 is 80gig and p2 is 160gig for the full 240gig size of the ssd
> >>>
> >>>> ls -al /dev/md*
> >>> brw-rw---- 1 root disk 9, 127 Feb 11 11:09 /dev/md127
> >>> brw-rw---- 1 root disk 259, 0 Feb 10 20:23 /dev/md127p1
> >>> brw-rw---- 1 root disk 259, 1 Feb 10 20:23 /dev/md127p2
> >>>
> >>> /dev/md:
> >>> total 8
> >>> drwxr-xr-x 2 root root 140 Feb 10 20:24 .
> >>> drwxr-xr-x 20 root root 3980 Feb 10 20:24 ..
> >>> lrwxrwxrwx 1 root root 8 Feb 11 11:09 240ssd_0 -> ../md127
> >>> lrwxrwxrwx 1 root root 10 Feb 10 20:23 240ssd_0p1 -> ../md127p1
> >>> lrwxrwxrwx 1 root root 10 Feb 10 20:23 240ssd_0p2 -> ../md127p2
> >>> -rw-r--r-- 1 root root 5 Feb 10 20:24 autorebuild.pid
> >>> -rw------- 1 root root 63 Feb 10 20:23 md-device-map
> >>>
> >>>> ps -eaf | grep mdadm
> >>> root 2188 1 0 Feb10 ? 00:00:00 mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid
> >>>
> >>> how do i rebuild /dev/sdc into the mirror of /dev/sdb?
> >>>
> >> Please send the output of fdisk -lu /dev/sd[bc] and cat /proc/mdstat
> >> (preferably both when it was working and current).
> >>
> >> In general, when replacing a failed RAID1 disk, and assuming you
> >> configured it the way I think you did:
> >> 1) fdisk -lu /dev/sdb
> >> Find out the exact partition sizes
> >> 2) fdisk /dev/sdc
> >> Create the new partitions exactly the same as /dev/sdb
> >> 3) mdadm --manage /dev/md127 --add /dev/sdb1
> >> Add the partition to the array
> >> 4) cat /proc/mdstat
> >> Watch the rebuild progress, once it is complete, relax.
> >>
> >> PS, steps 1 and 2 may not be needed if you are using the full block
> >> device instead of a partition. Also, change the command in step 3 to
> >> "mdadm --manage /dev/md127 --add /dev/sdb"
> >>
> >> PPS, if this is a bootable disk, you will probably also need to do
> >> something with your boot manager to get that installed onto the new disk
> >> as well.
> >>
> >> Hope this helps, otherwise, please provide more information.
> >>
> >>
> >> Regards,
> >> Adam
> >>
> >> --
> >> Adam Goryachev Website Managers www.websitemanagers.com.au
> > Adam (and anybody else that can help),
> > after issue i do not have before. and no they are not bootable.
> >
> > [root@shell ~]# fdisk -lu /dev/sd[bc]
> >
> > Disk /dev/sdb: 240.1 GB, 240057409536 bytes
> > 255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
> > Units = sectors of 1 * 512 = 512 bytes
> > Sector size (logical/physical): 512 bytes / 512 bytes
> > I/O size (minimum/optimal): 512 bytes / 512 bytes
> > Disk identifier: 0x0001a740
> >
> >
> > Disk /dev/sdc: 240.1 GB, 240057409536 bytes
> > 255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
> > Units = sectors of 1 * 512 = 512 bytes
> > Sector size (logical/physical): 512 bytes / 512 bytes
> > I/O size (minimum/optimal): 512 bytes / 512 bytes
> > Disk identifier: 0x00000000
> >
> > [root@shell ~]# cat /proc/mdstat
> > Personalities : [raid1]
> > md127 : active raid1 sdb[2]
> > 234299840 blocks super 1.2 [2/1] [U_]
> >
> > unused devices: <none>
>
> > i dont seem to be seeing the partition sizes or im stupid.
> > couldnt i just dd if=/dev/sdb of=/dev/sdc bs=1G count=240 and then do the
> > mdadm?
> OK, so you aren't using partitioned disks, so it is as simple as what I
> said above (with one minor correction):
>
> "mdadm --manage /dev/md127 --add /dev/sdc"
>
>
> /dev/sdc is the new blank ssd, so that is the one to add, the above
> command with /dev/sdb wouldn't have done anything at all .... So just
> run that command, and then do "watch cat /proc/mdstat" until the good
> stuff is completed.
>
> Regards,
> Adam
>
> --
> Adam Goryachev Website Managers www.websitemanagers.com.au
awesome sauce!
it is recovering and at a fast pace too. says it will be done in 16mins.
ok, so now the really important questions:
once done, what files/stats do i need to save off for the next time it
craters?
^ permalink raw reply
* Re: please help - raid 1 degraded
From: Adam Goryachev @ 2015-02-12 1:10 UTC (permalink / raw)
To: sunruh; +Cc: linux-raid
In-Reply-To: <20150212010200.GA51009@eris.prismnet.com>
On 12/02/15 12:02, sunruh@prismnet.com wrote:
> ok, so now the really important questions: once done, what files/stats
> do i need to save off for the next time it craters?
I think the usual information requested is the following:
fdisk -lu /dev/sd?
mdadm --manage --query /dev/sd?
mdadm --manage --detail /dev/md*
mdadm --manage --examine /dev/sd?
cat /proc/mdstat
ls -l /dev/disk/by-id/
If you can keep a copy of all those things, then you will be much
further ahead than many people. Of course, RAID1 is just so much
easier/simpler than RAID5/RAID6, so usually you won't need any of that.
RAID1 is simple mirror, so if you have two disks, one with data, one
without, then you just need to decide which disk has the data, and start
with that.
It is even possible to start two MD arrays, one from each disk, and then
compare the contents to decide which one you want to keep.
Or, you can simply mount the device directly (skipping any MD data at
the beginning if needed).
Like I said, RAID1 is by far the simplest type of RAID if you want
redundancy and can fit your dataset onto a single device.
Glad you had a successful recovery :)
Regards,
Adam
--
Adam Goryachev Website Managers www.websitemanagers.com.au
^ permalink raw reply
* Re: All drive in Raid 5 are in 'spare' mode
From: Phil Turmel @ 2015-02-12 1:41 UTC (permalink / raw)
To: Dush, linux-raid@vger.kernel.org
In-Reply-To: <CAL7hTOctZ4tAoPSbO3iFEohRyXuvcY4=6yQj8U-FpoAhV6sT0w@mail.gmail.com>
Hi Dush,
On 02/11/2015 02:56 PM, Dush wrote:
> Hi,
>
> I have a RAID 5 composed by 4x 500Go hdd but for some days, it's 'inactive'.
>
> I'm not raid expert and I prefer asking before doing an unrecoverable mistake...
>
> Is it possible to fix this raid (md126)?
> Is it possible to recover data on it?
Probably. Very good report, btw.
> Do I have a disk to change or it's "just" a desynchronization between disks?
One disk is now truly a spare (/dev/sdd3), which suggests you already
tried to '--add' it and didn't get anywhere.
Step one: collect some forensics for later. syslog or dmesg containing
your failure events. Can be trimmed to just device and md stuff.
"smartctl -x /dev/sdX" for each drive involved in the arrays.
Then, we'll try the simple stuff.
Make sure the array is stopped with:
mdadm --stop /dev/md126
Then, force assemble it without sdd:
mdadm --assemble --force --verbose --run /dev/md126 /dev/sd[bce]3
If that works, mount it and catch a backup of critical files.
Then add your /dev/sdd3 back to the array and let it rebuild:
mdadm --add /dev/md126 /dev/sdd3
It may not make it through the rebuild if you have the common timeout
mismatch problem.[1] Show the dmesg and smartctl data (pasted inline is
preferred) and we'll see.
Phil
Recent typical case:
[1] http://marc.info/?l=linux-raid&m=142353387024935&w=1
^ permalink raw reply
* Re: [PATCH RESEND] Change way of printing name of a process
From: NeilBrown @ 2015-02-12 2:54 UTC (permalink / raw)
To: Pawel Baldysiak; +Cc: linux-raid, artur.paszkiewicz
In-Reply-To: <20150211212401.14402.5228.stgit@gklab-154-222.intel.com>
[-- Attachment #1: Type: text/plain, Size: 10493 bytes --]
On Wed, 11 Feb 2015 22:25:03 +0100 Pawel Baldysiak
<pawel.baldysiak@intel.com> wrote:
> Sometimes mdadm prints messages with wrong name "mdmon",
> and vice versa.
> This patch solves this problem by changing method of determining
> process name.
> Now "Name" will be set in const at start of a program,
> previously was hardcoded as #define.
>
> Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
> Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> ---
> Grow.c | 18 +++++++++---------
> Incremental.c | 4 ++--
> Monitor.c | 4 ++--
> ReadMe.c | 2 +-
> mdadm.c | 7 ++++---
> mdadm.h | 6 +++---
> mdmon.c | 2 ++
> mdmon.h | 3 +--
> super-intel.c | 2 +-
> sysfs.c | 8 ++++----
> xmalloc.c | 12 ++++++++----
> 11 files changed, 37 insertions(+), 31 deletions(-)
>
> diff --git a/Grow.c b/Grow.c
> index 6ff225a..4a01a31 100644
> --- a/Grow.c
> +++ b/Grow.c
> @@ -1919,7 +1919,7 @@ size_change_error:
> int err;
> err = remove_disks_for_takeover(st, sra, array.layout);
> if (err) {
> - dprintf(Name": Array cannot be reshaped\n");
> + dprintf("%s: Array cannot be reshaped\n", Name);
> if (cfd > -1)
> close(cfd);
> rv = 1;
> @@ -2133,7 +2133,7 @@ static int verify_reshape_position(struct mdinfo *info, int level)
> char *ep;
> unsigned long long position = strtoull(buf, &ep, 0);
>
> - dprintf(Name": Read sync_max sysfs entry is: %s\n", buf);
> + dprintf("%s: Read sync_max sysfs entry is: %s\n", Name, buf);
> if (!(ep == buf || (*ep != 0 && *ep != '\n' && *ep != ' '))) {
> position *= get_data_disks(level,
> info->new_layout,
> @@ -3494,8 +3494,8 @@ int reshape_container(char *container, char *devname,
> return 1;
> default: /* parent */
> if (!freeze_reshape)
> - printf(Name ": multi-array reshape continues"
> - " in background\n");
> + printf("%s: multi-array reshape continues"
> + " in background\n", Name);
> return 0;
> case 0: /* child */
> map_fork();
> @@ -3557,8 +3557,8 @@ int reshape_container(char *container, char *devname,
>
> fd = open_dev(mdstat->devnm);
> if (fd < 0) {
> - printf(Name ": Device %s cannot be opened for reshape.",
> - adev);
> + printf("%s: Device %s cannot be opened for reshape.",
> + Name, adev);
> break;
> }
>
> @@ -3573,8 +3573,8 @@ int reshape_container(char *container, char *devname,
> * This is possibly interim until the behaviour of
> * reshape_array is resolved().
> */
> - printf(Name ": Multiple reshape execution detected for "
> - "device %s.", adev);
> + printf("%s: Multiple reshape execution detected for "
> + "device %s.", Name, adev);
> close(fd);
> break;
> }
> @@ -4611,7 +4611,7 @@ int Grow_restart(struct supertype *st, struct mdinfo *info, int *fdlist, int cnt
> st->ss->free_super(st);
> offsets[j] = dinfo.data_offset * 512;
> }
> - printf(Name ": restoring critical section\n");
> + printf("%s: restoring critical section\n", Name);
>
> if (restore_stripes(fdlist, offsets,
> info->array.raid_disks,
> diff --git a/Incremental.c b/Incremental.c
> index 13b68bc..38c9989 100644
> --- a/Incremental.c
> +++ b/Incremental.c
> @@ -1710,9 +1710,9 @@ int IncrementalRemove(char *devname, char *id_path, int verbose)
> char buf[32];
>
> if (!id_path)
> - dprintf(Name ": incremental removal without --path <id_path> "
> + dprintf("%s: incremental removal without --path <id_path> "
> "lacks the possibility to re-add new device in this "
> - "port\n");
> + "port\n", Name);
>
> if (strchr(devname, '/')) {
> pr_err("incremental removal requires a "
> diff --git a/Monitor.c b/Monitor.c
> index 971d2ec..7a5203c 100644
> --- a/Monitor.c
> +++ b/Monitor.c
> @@ -381,14 +381,14 @@ static void alert(char *event, char *dev, char *disc, struct alert_info *info)
> if (info->mailfrom)
> fprintf(mp, "From: %s\n", info->mailfrom);
> else
> - fprintf(mp, "From: " Name " monitoring <root>\n");
> + fprintf(mp, "From: %s monitoring <root>\n", Name);
> fprintf(mp, "To: %s\n", info->mailaddr);
> fprintf(mp, "Subject: %s event on %s:%s\n\n",
> event, dev, hname);
>
> fprintf(mp,
> "This is an automatically generated"
> - " mail message from " Name "\n");
> + " mail message from %s\n", Name);
> fprintf(mp, "running on %s\n\n", hname);
>
> fprintf(mp,
> diff --git a/ReadMe.c b/ReadMe.c
> index 445c388..87a4916 100644
> --- a/ReadMe.c
> +++ b/ReadMe.c
> @@ -30,7 +30,7 @@
> #ifndef VERS_DATE
> #define VERS_DATE "21st August 2014"
> #endif
> -char Version[] = Name " - v" VERSION " - " VERS_DATE "\n";
> +char Version[] = "mdadm - v" VERSION " - " VERS_DATE "\n";
>
> /*
> * File: ReadMe.c
> diff --git a/mdadm.c b/mdadm.c
> index c856fcd..475c71c 100644
> --- a/mdadm.c
> +++ b/mdadm.c
> @@ -38,6 +38,7 @@ static int misc_list(struct mddev_dev *devlist,
> struct mddev_ident *ident,
> char *dump_directory,
> struct supertype *ss, struct context *c);
> +const char Name[] = "mdadm";
>
> int main(int argc, char *argv[])
> {
> @@ -771,12 +772,12 @@ int main(int argc, char *argv[])
> if (strcmp(c.update,"?") == 0 ||
> strcmp(c.update, "help") == 0) {
> outf = stdout;
> - fprintf(outf, Name ": ");
> + fprintf(outf, "%s: ", Name);
> } else {
> outf = stderr;
> fprintf(outf,
> - Name ": '--update=%s' is invalid. ",
> - c.update);
> + "%s: '--update=%s' is invalid. ",
> + Name, c.update);
> }
> fprintf(outf, "Valid --update options are:\n"
> " 'sparc2.2', 'super-minor', 'uuid', 'name', 'resync',\n"
> diff --git a/mdadm.h b/mdadm.h
> index fc1fd31..c8d079c 100644
> --- a/mdadm.h
> +++ b/mdadm.h
> @@ -180,6 +180,8 @@ extern __off64_t lseek64 __P ((int __fd, __off64_t __offset, int __whence));
>
> #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
>
> +extern const char Name[];
> +
> /* general information that might be extracted from a superblock */
> struct mdinfo {
> mdu_array_info_t array;
> @@ -262,8 +264,6 @@ struct createinfo {
> struct supertype *supertype;
> };
>
> -#define Name "mdadm"
> -
> enum mode {
> ASSEMBLE=1,
> BUILD,
> @@ -1457,7 +1457,7 @@ static inline int xasprintf(char **strp, const char *fmt, ...) {
> return ret;
> }
>
> -#define pr_err(fmt ...) fprintf(stderr, Name ": " fmt)
> +#define pr_err(fmt, args...) fprintf(stderr, "%s: "fmt, Name, ##args)
> #define cont_err(fmt ...) fprintf(stderr, " " fmt)
>
> void *xmalloc(size_t len);
> diff --git a/mdmon.c b/mdmon.c
> index 27045a1..ee12b7c 100644
> --- a/mdmon.c
> +++ b/mdmon.c
> @@ -67,6 +67,8 @@
> #include "mdadm.h"
> #include "mdmon.h"
>
> +char const Name[] = "mdmon";
> +
> struct active_array *discard_this;
> struct active_array *pending_discard;
>
> diff --git a/mdmon.h b/mdmon.h
> index 5a8e120..aa750c6 100644
> --- a/mdmon.h
> +++ b/mdmon.h
> @@ -18,8 +18,7 @@
> * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
> */
>
> -#undef pr_err
> -#define pr_err(fmt ...) fprintf(stderr, "mdmon: " fmt)
> +extern const char Name[];
>
> enum array_state { clear, inactive, suspended, readonly, read_auto,
> clean, active, write_pending, active_idle, bad_word};
> diff --git a/super-intel.c b/super-intel.c
> index 4b23b9a..d900339 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -1386,7 +1386,7 @@ static int imsm_check_attributes(__u32 attributes)
> }
>
> if (not_supported)
> - dprintf(Name "(IMSM): Unknown attributes : %x\n", not_supported);
> + dprintf("%s (IMSM): Unknown attributes : %x\n", Name, not_supported);
>
> ret_val = 0;
> }
> diff --git a/sysfs.c b/sysfs.c
> index 9a1d856..ceab27f 100644
> --- a/sysfs.c
> +++ b/sysfs.c
> @@ -413,8 +413,8 @@ int sysfs_set_str(struct mdinfo *sra, struct mdinfo *dev,
> n = write(fd, val, strlen(val));
> close(fd);
> if (n != strlen(val)) {
> - dprintf(Name ": failed to write '%s' to '%s' (%s)\n",
> - val, fname, strerror(errno));
> + dprintf("%s: failed to write '%s' to '%s' (%s)\n",
> + Name, val, fname, strerror(errno));
> return -1;
> }
> return 0;
> @@ -450,8 +450,8 @@ int sysfs_uevent(struct mdinfo *sra, char *event)
> n = write(fd, event, strlen(event));
> close(fd);
> if (n != (int)strlen(event)) {
> - dprintf(Name ": failed to write '%s' to '%s' (%s)\n",
> - event, fname, strerror(errno));
> + dprintf("%s: failed to write '%s' to '%s' (%s)\n",
> + Name, event, fname, strerror(errno));
> return -1;
> }
> return 0;
> diff --git a/xmalloc.c b/xmalloc.c
> index 8d42a7c..75ae4e2 100644
> --- a/xmalloc.c
> +++ b/xmalloc.c
> @@ -37,7 +37,8 @@ void *xmalloc(size_t len)
> char *msg;
> if (rv)
> return rv;
> - msg = Name ": memory allocation failure - aborting\n";
> + msg = ": memory allocation failure - aborting\n";
> + write(2, Name, strlen(Name));
> exit(4+!!write(2, msg, strlen(msg)));
> }
>
> @@ -47,7 +48,8 @@ void *xrealloc(void *ptr, size_t len)
> char *msg;
> if (rv)
> return rv;
> - msg = Name ": memory allocation failure - aborting\n";
> + msg = ": memory allocation failure - aborting\n";
> + write(2, Name, strlen(Name));
> exit(4+!!write(2, msg, strlen(msg)));
> }
>
> @@ -57,7 +59,8 @@ void *xcalloc(size_t num, size_t size)
> char *msg;
> if (rv)
> return rv;
> - msg = Name ": memory allocation failure - aborting\n";
> + msg = ": memory allocation failure - aborting\n";
> + write(2, Name, strlen(Name));
> exit(4+!!write(2, msg, strlen(msg)));
> }
>
> @@ -67,6 +70,7 @@ char *xstrdup(const char *str)
> char *msg;
> if (rv)
> return rv;
> - msg = Name ": memory allocation failure - aborting\n";
> + msg = ": memory allocation failure - aborting\n";
> + write(2, Name, strlen(Name));
> exit(4+!!write(2, msg, strlen(msg)));
> }
Thanks.
I applied this patch, then made a number of other changes so some of it isn't
needed.
In particular, dprintf now always includes the Name and __func__, and pr_err
now always includes the Name.
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: please help - raid 1 degraded
From: Eyal Lebedinsky @ 2015-02-12 3:12 UTC (permalink / raw)
Cc: linux-raid
In-Reply-To: <54DBFD91.7080507@websitemanagers.com.au>
On 12/02/15 12:10, Adam Goryachev wrote:
> On 12/02/15 12:02, sunruh@prismnet.com wrote:
>> ok, so now the really important questions: once done, what files/stats do i need to save off for the next time it craters?
>
> I think the usual information requested is the following:
> fdisk -lu /dev/sd?
> mdadm --manage --query /dev/sd?
> mdadm --manage --detail /dev/md*
> mdadm --manage --examine /dev/sd?
Maybe
mdadm --misc --query /dev/md*
mdadm --misc --detail /dev/md*
mdadm --misc --examine /dev/sd*
> cat /proc/mdstat
> ls -l /dev/disk/by-id/
>
> If you can keep a copy of all those things, then you will be much further ahead than many people. Of course, RAID1 is just so much easier/simpler than RAID5/RAID6, so usually you won't need any of that. RAID1 is simple mirror, so if you have two disks, one with data, one without, then you just need to decide which disk has the data, and start with that.
> It is even possible to start two MD arrays, one from each disk, and then compare the contents to decide which one you want to keep.
> Or, you can simply mount the device directly (skipping any MD data at the beginning if needed).
>
> Like I said, RAID1 is by far the simplest type of RAID if you want redundancy and can fit your dataset onto a single device.
>
> Glad you had a successful recovery :)
>
> Regards,
> Adam
>
--
Eyal Lebedinsky (eyal@eyal.emu.id.au)
^ permalink raw reply
* [GIT PULL REQUEST] md updates for 3.20
From: NeilBrown @ 2015-02-12 3:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: lkml, linux RAID, Xiao Ni, Hannes Reinecke, Jes Sorensen,
Jan Beulich, Dan Carpenter
[-- Attachment #1: Type: text/plain, Size: 3577 bytes --]
Hi Linus,
20 is a big number ... is it time for 4.0 yet :-)
anyway, herewith is my pull request for 3.20. It has been sitting in
-next for a while, and Dan's scripts only found 2 bugs - now fixed.
Thanks,
NeilBrown
The following changes since commit d95901433436aeb921eac58bfd8a2aa77f110384:
md/bitmap: fix a might_sleep() warning. (2015-02-02 17:08:03 +1100)
are available in the git repository at:
git://neil.brown.name/md tags/md/3.20
for you to fetch changes up to 53a6ab4d3f6d6dc87ec8f14998b4b5536ee2968c:
md/raid10: fix conversion from RAID0 to RAID10 (2015-02-12 14:09:57 +1100)
----------------------------------------------------------------
md updates for 3.20
- assorted locking changes so that access to /proc/mdstat
and much of /sys/block/mdXX/md/* is protected by a spinlock
rather than a mutex and will never block indefinitely.
- Make an 'if' condition in RAID5 - which has been implicated
in recent bugs - more readable.
- misc minor fixes
----------------------------------------------------------------
Hannes Reinecke (1):
md: wakeup thread upon rdev_dec_pending()
Jan Beulich (1):
x86/raid6: correctly check for assembler capabilities
Jes Sorensen (1):
md: do_release_stripe(): No need to call md_wakeup_thread() twice
NeilBrown (25):
md/raid5: separate large if clause out of fetch_block().
md/raid5: separate out the easy conditions in need_this_block.
md/raid5: need_this_block: start simplifying the last two conditions.
md/raid5: need_this_block: tidy/fix last condition.
md: rename mddev->write_lock to mddev->lock
md: make ->congested robust against personality changes.
md: make merge_bvec_fn more robust in face of personality changes.
md/linear: remove rcu protections in favour of suspend/resume
md: split detach operation out from ->stop.
md: rename ->stop to ->free
md: level_store: group all important changes into one place.
md: protect ->pers changes with mddev->lock
md/bitmap: protect clearing of ->bitmap by mddev->lock
md: remove need for mddev_lock() in md_seq_show()
md/raid5: use ->lock to protect accessing raid5 sysfs attributes.
md: remove mddev_lock() from md_attr_show()
md: remove mddev_lock from rdev_attr_show()
md: remove unnecessary 'buf' from get_bitmap_file.
md: tidy up set_bitmap_file
md: move GET_BITMAP_FILE ioctl out from mddev_lock.
md: minor cleanup in safe_delay_store.
md: use mddev->lock to protect updates to resync_{min,max}.
md: move mddev_lock and related to md.h
md: make reconfig_mutex optional for writes to md sysfs files.
md/raid10: fix conversion from RAID0 to RAID10
arch/x86/Makefile | 1 +
drivers/md/bitmap.c | 15 +-
drivers/md/dm-raid.c | 8 +-
drivers/md/faulty.c | 8 +-
drivers/md/linear.c | 67 ++--
drivers/md/md.c | 816 ++++++++++++++++++++++++++++++------------------
drivers/md/md.h | 57 +++-
drivers/md/multipath.c | 22 +-
drivers/md/raid0.c | 29 +-
drivers/md/raid1.c | 52 +--
drivers/md/raid1.h | 3 -
drivers/md/raid10.c | 49 +--
drivers/md/raid10.h | 3 -
drivers/md/raid5.c | 334 ++++++++++++--------
drivers/md/raid5.h | 1 -
lib/raid6/algos.c | 2 +-
lib/raid6/recov_avx2.c | 2 +-
lib/raid6/recov_ssse3.c | 6 +
18 files changed, 867 insertions(+), 608 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: please help - raid 1 degraded
From: Roaming @ 2015-02-12 10:11 UTC (permalink / raw)
To: sunruh; +Cc: linux-raid
In-Reply-To: <20150212000940.GA49579@eris.prismnet.com>
On 12/02/2015 00:09, sunruh@prismnet.com wrote:
> i dont seem to be seeing the partition sizes or im stupid.
> couldnt i just dd if=/dev/sdb of=/dev/sdc bs=1G count=240 and then do the
> mdadm?
NOT a good idea. I don't know what it would do in your case, where you
are using the entire disk, but if you're using a partition table you
would suddenly end up with a bunch of duplicate GUIDs. Bearing in mind
the "GU" stands for "globally unique", your management tools are likely
to get confused ... not a good idea especially wrt raid.
Cheers,
Wol
^ permalink raw reply
* RE: RAID 1 metadata - keep separate from mirror disks ?
From: Suresh Babu Kandukuru @ 2015-02-12 11:42 UTC (permalink / raw)
To: Phil Turmel, linux-raid
In-Reply-To: <54DB6BF0.3040309@turmel.org>
Thanks Phil . This helps.
/Suresh
-----Original Message-----
From: Phil Turmel [mailto:philip@turmel.org]
Sent: Wednesday, February 11, 2015 8:19 PM
To: Suresh Babu Kandukuru; linux-raid@vger.kernel.org
Subject: Re: RAID 1 metadata - keep separate from mirror disks ?
Good morning Suresh,
On 02/11/2015 07:14 AM, Suresh Babu Kandukuru wrote:
> Hi There,
>
> On the RAID 1 metadata: is there any way to keep the metadata
> separate from the mirror disks? Could you guide us on this ?,
> please. In general, we need to keep all metadata off the device
> itself, leaving all the device available for user data. This is
> particularly important in the migration case, where we want to take an
> existing LUN and add a second leg to it to create the mirror device
> without changing any of the data or metadata on the LUN.
If you look at "man 4 md" you'll see some options. If a legacy array type meets your needs, you can operate without metadata at all. Use "mdadm --build" to assemble your raid at each boot.
Or, if your storage server can insert a leg ahead of you current LUN, you can then create the array with an explicit data offset matching the size of the inserted leg. Create it degraded with the existing LUN, then add (a) LUN(s) to start mirroring. This process will leave you the option to resize with more legs later.
Or you can add a leg to the end and create your array with version 1.0 metadata, which is placed at the end of the device.
Finally, you could write your own metadata container service for use with mdmon. (That's a bit beyond my ability, sorry.)
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
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