* Re: Looking for the best way to do this
From: maurice @ 2011-06-23 22:06 UTC (permalink / raw)
To: Iordan Iordanov; +Cc: linux-raid
In-Reply-To: <4E03929A.8000503@cdf.toronto.edu>
On 6/23/2011 1:23 PM, Iordan Iordanov wrote:
> Hi Maurice,
>
> On 06/21/11 14:13, maurice wrote:
>> Add 3rd disk to make a 3 disk RAID1
>> Make a RAID10, missing one disk.
>
> Perhaps I misunderstand your supposition, and if I do, please correct
> me. RAID10 with mdadm does not require a minimum of 4 disks.
Yes, that was my understanding.
> For example, mdadm can do RAID10 with 2 copies on 3 disks or RAID10
> with 3 copies on 3 disks, yielding the equivalent of RAID1 in terms of
> data security. It is not confined to mirroring two pairs of disks and
> then striping across them as is the "conventional" way of doing RAID10.
Yes, I understand the principle.
>
> You can read the man-page of mdadm, where the options for "layout" of
> RAID10 are discussed. Pay particular attention to the end of the
> "--layout" option explanation.
What I do NOT know is the following:
A) Which is more RELIABLE: R1 with 3 disks or R10 with 3 disks.
B) HOW to create either the 3 disk R1 or R10, assuming an existing 2
disk R1.
--
Cheers,
Maurice Hilarius
eMail: /mhilarius@gmail.com/
^ permalink raw reply
* RE: Issues with auto assembling or RAID10 (imsm) on boot
From: Sandra Escandor @ 2011-06-23 19:45 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <C70A636B101FD44999B82525C3E92AFAD36F92@otis.burlington.evertz.tv>
In case anyone runs into the same issue that I was having, the answer to
getting mdadm 3.1.4 (built from source) to boot on startup in Ubuntu
10.10 was to create a script and place it into /etc/init.d/, then chmod
+x the new script, then run "update-rc.d mdraidstartupscript.sh
defaults".
Thanks to Phil for pointing me to the right direction!
Sandra
-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Sandra Escandor
Sent: Monday, June 20, 2011 4:28 PM
To: Phil Turmel
Cc: linux-raid@vger.kernel.org
Subject: RE: Issues with auto assembling or RAID10 (imsm) on boot
Yes, your assumption is correct that I built the mdadm package from
source. The reason why I needed mdadm 3.1.4 (instead of the one that
comes with Ubuntu 10.10) is because it supports the imsm metadata
container, which I need to be able to see the same type of RAID that
dmraid does.
I now have something to go on and will look into how the initscript and
configuration files should look like for this.
Thanks for your help!
Sandra
-----Original Message-----
From: Phil Turmel [mailto:philip@turmel.org]
Sent: Monday, June 20, 2011 4:16 PM
To: Sandra Escandor
Cc: linux-raid@vger.kernel.org
Subject: Re: Issues with auto assembling or RAID10 (imsm) on boot
On 06/20/2011 03:55 PM, Sandra Escandor wrote:
> Hi Phil,
>
> Attached is the complete dmesg. The last chunk of it is where I
manually
> assemble the RAID after boot.
>
> I just want to make sure I mention this if this is important: I built
> this from source and then I ran make install. I couldn't see any
> documentation that would suggest that I had to do anything else in
/etc/
> (such as an init script - maybe this is what I need? I don't know
enough
> about the inner workings of Linux just yet).
Based on the dmesg, you aren't using raid for your boot or root disks,
so its not really an initramfs issue (or doesn't have to be). It is
almost certainly a missing initscript, or missing runlevel configuration
for an initscript. Unfortunately, I'm not terribly familiar with the
ubuntu init system, so I can't point at anything specific to check.
By mentioning building from source, I assume you mean the mdadm package?
If so, you are probably missing the initscript and configuration files
that ubuntu packages with mdadm to make their entire system "seamless".
Is there something you need from the latest and greatest mdadm?
Also, anyone else care to jump in?
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
* clarifying what can be done during resync
From: Sandra Escandor @ 2011-06-23 19:38 UTC (permalink / raw)
To: linux-raid
Hello,
Just wanted to make sure if this was a myth or not: Is it true that when
an array is in resync status, then mounting it is not at all possible?
Thanks,
Sandra
^ permalink raw reply
* Re: Looking for the best way to do this
From: Iordan Iordanov @ 2011-06-23 19:23 UTC (permalink / raw)
To: maurice; +Cc: linux-raid
In-Reply-To: <4E00DF31.2020406@gmail.com>
Hi Maurice,
On 06/21/11 14:13, maurice wrote:
> Add 3rd disk to make a 3 disk RAID1
> Make a RAID10, missing one disk.
Perhaps I misunderstand your supposition, and if I do, please correct
me. RAID10 with mdadm does not require a minimum of 4 disks. For
example, mdadm can do RAID10 with 2 copies on 3 disks or RAID10 with 3
copies on 3 disks, yielding the equivalent of RAID1 in terms of data
security. It is not confined to mirroring two pairs of disks and then
striping across them as is the "conventional" way of doing RAID10.
You can read the man-page of mdadm, where the options for "layout" of
RAID10 are discussed. Pay particular attention to the end of the
"--layout" option explanation.
Cheers!
Iordan
^ permalink raw reply
* raid upgrade form 1.5T to 3T drives with 0.90 superblock
From: Krzysztof Adamski @ 2011-06-23 18:43 UTC (permalink / raw)
To: linux-raid
Hi All,
I have a raid6 array made out of 8 1.5T drives and I wanted to change to
use 3T drives. The array is 0.90. After reading the wiki I see that 0.90
superblock will not work with any device larger then 2T.
What are my options for a live upgrade (backup/restore is not possible)?
Thanks in advance.
K
^ permalink raw reply
* can't read superblock after switching from dmraid
From: Sandra Escandor @ 2011-06-23 18:23 UTC (permalink / raw)
To: linux-raid
Hello,
The current situation that I'm having is that when I give the command to
mount the RAID10, it reports back saying "mount: /dev/md126 can't read
superblock".
The background is that, the RAID10 that I have was initially managed by
dmraid, but I tried moving it over to mdadm. Using dmraid, the RAID10
was initially created with an imsm metadata format, and an xfs
filesystem (mkfs.xfs -f -d su=64k,sw=2 -l su=64k). The steps that I took
to move over to mdadm are as follows:
1. uninstalled dmraid.
2. Built mdadm 3.1.4 from source and installed it.
3. Edited mdadm.conf to include output of "mdadm -Es"
4. Issued "mdadm -As". After this command was issued, mdadm started a
resync of the drives.
So when I issue the command to assemble the array, mdadm reports back
saying that the container /dev/md/imsm0 has been assembled with 4
drives, and that mdadm has started /dev/md/Volume0 with 4 devices. After
a while, when I look at the output of cat /proc/mdstat, it shows that
the resync has finished and that md126 is listed as "active
(auto-read-only)".
When I look at the output of dmesg, it says "I/O error in filesystem
("md126") meta-data dev md126 block 0xaea8a9ff ("xfs_read_buf") error 5
buf count 512".
I tried doing an xfs_check on /dev/md126, but it didn't output anything.
I also did an xfs_repair on /dev/md126, and it looks like it didn't
encounter any errors.
I'm now stuck and am still searching for an answer on google. Can
someone point me to what could be wrong?
Thanks,
Sandra
^ permalink raw reply
* Legal Assistance Needed
From: Zaira Hoshiko @ 2011-06-23 11:09 UTC (permalink / raw)
My name is Zaira Hoshiko. I am contacting your firm in regards to a
divorce settlement with my ex husband Allen Hoshiko, who resides in your
jurisdiction. We had an out of court agreement (Collaborative Law
Agreement) for him to pay $950,500.00 plus legal fees. He has only paid
me $251,500.00 since. I am hereby seeking your firm`s assistance in
collecting the balance from him or litigate this matter if he fails to
pay as promised because he has delayed for too long. If you are in the
position to represent me at the moment, kindly advice immediately.
Your's truly,
Zaira Hoshiko.
^ permalink raw reply
* Re: [PATCH 0/5] misc cleanups for RAID5
From: Namhyung Kim @ 2011-06-23 7:30 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20110623105554.19c5fe09@notabene.brown>
2011-06-23 (목), 10:55 +1000, NeilBrown:
> Hi,
> thanks for these.
>
> I have applied the first and the last.
>
> The two "factor out" patches conflict with some much more substantial
> refactoring I have been doing in raid5.c. I have just pushed all of that
> into my for-next branch:
>
> git://neil.brown.name/md for-next
>
> so you can use that as a basis for any further review.
Thanks. I'll have a look at that.
>
> The r5_for_each_bio() patch I'm not 100% sure I'm happy with, and in any
> case it would have conflicted with my other changes too.
> I'm not fond of macros that hide details that could be important. A
> "for_each" macro that purely and simply walks through a list is fine. A
> "for_each" macro that does anything more complicated I start to have doubts
> about...
> However if you really do like it and want to rebase it on the for-next
> branch I'll have another look and think harder about it. Maybe I'll end up
> liking it after all, but no promises.
I don't have any strong opinion on it. It was just a suggestion that I
think it helps the code cleaner but ...
Anyway, thanks for your comment.
--
Regards,
Namhyung Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Which Disks can fail?
From: NeilBrown @ 2011-06-23 7:02 UTC (permalink / raw)
To: Jonathan Tripathy; +Cc: linux-raid
In-Reply-To: <4E00B965.1030208@abpni.co.uk>
On Tue, 21 Jun 2011 16:31:49 +0100 Jonathan Tripathy <jonnyt@abpni.co.uk>
wrote:
> So, just to confirm 2 drives could fail in my array, as long as the two
> drives weren't sda5 and sdb5, or sdc5 and sdd5. Is that correct?
Correct.
NeilBrown
^ permalink raw reply
* Re: [PATCH] Show DELAYED, PENDING status of resync process in "--detail"
From: NeilBrown @ 2011-06-23 2:07 UTC (permalink / raw)
To: Krzysztof Wojcik
Cc: linux-raid, wojciech.neubauer, adam.kwolek, dan.j.williams,
ed.ciechanowski
In-Reply-To: <20110618141035.14426.58645.stgit@gklab-128-111.igk.intel.com>
On Sat, 18 Jun 2011 16:10:35 +0200 Krzysztof Wojcik
<krzysztof.wojcik@intel.com> wrote:
> Initialy there is no proper translation mdstat's DEYALED/PENDING processes
> to "--detail" output.
> For example, if we have revover=DELAYED in mdstat, "--detail"
> shows "State: recovering" and "Rebuild Status = 0%".
> It was incorrect in case of process waiting on checkpoint different
> than 0%. In fact rebuild status is differnt than 0% and user is misled.
>
> The patch fix the problem. Current "--detail" command shows
> in the exampe: "State: recovering (DELAYED)" and no information
> about precentage.
Looks good.
Applied, thanks.
NeilBrown
>
> Signed-off-by: Krzysztof Wojcik <krzysztof.wojcik@intel.com>
> ---
> Detail.c | 18 +++++++++---------
> mdadm.h | 2 ++
> mdstat.c | 8 ++++----
> 3 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/Detail.c b/Detail.c
> index 375189d..e9f71d8 100644
> --- a/Detail.c
> +++ b/Detail.c
> @@ -372,11 +372,13 @@ int Detail(char *dev, int brief, int export, int test, char *homehost)
> else
> st = ", degraded";
>
> - printf(" State : %s%s%s%s\n",
> - (array.state&(1<<MD_SB_CLEAN))?"clean":"active",
> - st,
> - (!e || e->percent < 0) ? "" : sync_action[e->resync],
> - larray_size ? "": ", Not Started");
> + printf(" State : %s%s%s%s%s%s \n",
> + (array.state&(1<<MD_SB_CLEAN))?"clean":"active", st,
> + (!e || (e->percent < 0 && e->percent != PROCESS_PENDING &&
> + e->percent != PROCESS_DELAYED)) ? "" : sync_action[e->resync],
> + larray_size ? "": ", Not Started",
> + e->percent == PROCESS_DELAYED ? " (DELAYED)": "",
> + e->percent == PROCESS_PENDING ? " (PENDING)": "");
> }
> if (array.raid_disks)
> printf(" Active Devices : %d\n", array.active_disks);
> @@ -416,10 +418,8 @@ int Detail(char *dev, int brief, int export, int test, char *homehost)
> }
>
> if (e && e->percent >= 0) {
> - printf(" Re%s Status : %d%% complete\n",
> - (st && st->sb && info->reshape_active)?
> - "shape":"build",
> - e->percent);
> + static char *sync_action[] = {"Rebuild", "Resync", "Reshape", "Check"};
> + printf(" %s Status : %d%% complete\n", sync_action[e->resync], e->percent);
> is_rebuilding = 1;
> }
> free_mdstat(ms);
> diff --git a/mdadm.h b/mdadm.h
> index e075dd2..8bd0077 100644
> --- a/mdadm.h
> +++ b/mdadm.h
> @@ -1345,3 +1345,5 @@ static inline int xasprintf(char **strp, const char *fmt, ...) {
> #define PATH_MAX 4096
> #endif
>
> +#define PROCESS_DELAYED -2
> +#define PROCESS_PENDING -3
> diff --git a/mdstat.c b/mdstat.c
> index 3d2edad..abf6bf9 100644
> --- a/mdstat.c
> +++ b/mdstat.c
> @@ -257,10 +257,10 @@ struct mdstat_ent *mdstat_read(int hold, int start)
> if (strncmp(w, "check", 5)==0)
> ent->resync = 3;
>
> - if (l > 8 && strcmp(w+l-8, "=DELAYED"))
> - ent->percent = 0;
> - if (l > 8 && strcmp(w+l-8, "=PENDING"))
> - ent->percent = 0;
> + if (l > 8 && strcmp(w+l-8, "=DELAYED") == 0)
> + ent->percent = PROCESS_DELAYED;
> + if (l > 8 && strcmp(w+l-8, "=PENDING") == 0)
> + ent->percent = PROCESS_PENDING;
> } else if (ent->percent == -1 &&
> w[0] >= '0' &&
> w[0] <= '9' &&
^ permalink raw reply
* Re: [PATCH] mdadm --detail was incorrect for shrinking reshapes
From: NeilBrown @ 2011-06-23 1:47 UTC (permalink / raw)
To: Andrew Burgess; +Cc: linux raid mailing list
In-Reply-To: <1308586015.10185.11@hogo>
On Mon, 20 Jun 2011 09:06:55 -0700 Andrew Burgess <aab@cichlid.com> wrote:
> Since info->delta_disks is signed it doesn't need to be special-cased.
>
> This allowed my 9->8 reshape to display correctly instead of as 8->7
>
> (the "This is pretty boring" context is apparently the universe's
> opinion of my first patch!)
>
>
> mdadm> git diff
> diff --git a/Detail.c b/Detail.c
> index 375189d..40806cf 100644
> --- a/Detail.c
> +++ b/Detail.c
> @@ -430,12 +430,9 @@ This is pretty boring
> printf(" Reshape pos'n : %llu%s\n", (unsigned
> long long) info->reshape_progress<<9,
> human_size((unsigned long
> long)info->reshape_progress<<9));
> #endif
> - if (info->delta_disks > 0)
> + if (info->delta_disks != 0)
> printf(" Delta Devices : %d,
> (%d->%d)\n",
> info->delta_disks,
> array.raid_disks - info->delta_disks, array.raid_disks);
> - if (info->delta_disks < 0)
> - printf(" Delta Devices : %d,
> (%d->%d)\n",
> - info->delta_disks,
> array.raid_disks, array.raid_disks + info->delta_disks);
> if (info->new_level != array.level) {
> char *c = map_num(pers,
> info->new_level);
> printf(" New Level : %s\n",
> c?c:"-unknown-");
> --
> 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
Thanks.
BTW "format=flowed" doesn't really work for patches.. Fortunately it was
small enough that I could just apply it by hand.
I had originally planned that "raid_disk" should always be the maximum of the
"before" and "after" number of devices in the array - so that it needed
exactly "raid_disks" devices to be non-degraded etc. It seems that didn't
really work out but I never fixed this code to reflect reality.
Thanks for the patch, it is applied now.
NeilBrown
^ permalink raw reply
* Re: [PATCH 1/4] mdadm.8: change linux version 2.6.40 -> 3.0
From: NeilBrown @ 2011-06-23 1:41 UTC (permalink / raw)
To: Namhyung Kim; +Cc: linux-raid
In-Reply-To: <1308673145-8151-1-git-send-email-namhyung@gmail.com>
On Wed, 22 Jun 2011 01:19:02 +0900 Namhyung Kim <namhyung@gmail.com> wrote:
> Signed-off-by: Namhyung Kim <namhyung@gmail.com>
> ---
> Grow.c | 2 +-
> mdadm.8.in | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Grow.c b/Grow.c
> index 6e31b94..a4092b5 100644
> --- a/Grow.c
> +++ b/Grow.c
> @@ -1494,7 +1494,7 @@ int Grow_reshape(char *devname, int fd, int quiet, char *backup_file,
> goto release;
> }
> if (assume_clean) {
> - /* This will fail on kernels newer than 2.6.40 unless
> + /* This will fail on kernels newer than 3.0 unless
> * a backport has been arranged.
> */
> if (sra == NULL ||
> diff --git a/mdadm.8.in b/mdadm.8.in
> index d2d7ef2..44accc0 100644
> --- a/mdadm.8.in
> +++ b/mdadm.8.in
> @@ -706,7 +706,7 @@ facts the operator knows.
> When an array is resized to a larger size with
> .B "\-\-grow \-\-size="
> the new space is normally resynced in that same way that the whole
> -array is resynced at creation. From Linux version 2.6.40,
> +array is resynced at creation. From Linux version 3.0,
> .B \-\-assume\-clean
> can be used with that command to avoid the automatic resync.
>
Thanks for this and the other 3. They are all applied and pushed out on my
'master' branch.
Thanks,
NeilBrown
^ permalink raw reply
* RE: Looking for the best way to do this
From: Leslie Rhorer @ 2011-06-23 1:20 UTC (permalink / raw)
To: 'maurice', linux-raid
In-Reply-To: <4E00DF31.2020406@gmail.com>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of maurice
> Sent: Tuesday, June 21, 2011 1:13 PM
> To: linux-raid@vger.kernel.org
> Subject: Looking for the best way to do this
>
> Good day, and thanks in advance for any ideas and advice.
>
> I am working on a server.
> The server is normally in a remote location, not outside accessible by
> network,
> and there is no easy method to do backups on it.
> It is running Fedora 14
>
> It has 2 hard drives at present, and there are 5 partitions on each.
> From this we have 3 RAID1 md devices.
> These are for /boot, /data and /
Presumably the fourth partition is swap, and the fifth is...?
> I wish to add a 3rd disk, for enhancing the safety of the data.
> There is no space to add a 4th disk.
>
> Things I thought of doing include:
> Add 3rd disk to make a 3 disk RAID1
That's the easiest and most robust.
> Make a RAID10, missing one disk.
No, I don't think I would do that. If you need more storage, you
could fail one drive, create a 3 drive RAID5 array with one missing, copy
the data over from the remaining RAID1 member, and then make the remaining
RAID1 drive into the third member for the RAID5 array. This is a bit less
robust than the 3 member RAID1 array, but gives you twice the storage. If
you don't need the extra storage, go for the 3 member RAID1. Whatever you
do, make an off-site backup of (at a minimum) /data.
> Which do you think is the better means to enhance data safety / chances
> of surviving a hardware problem?
> One of the above, or an other configuration?
>
> And, assuming I want to preserve the existing data, what is the best way
> to do this?
Like I said, make your backup, and then either add a 3rd member to
the RAID1 array or else fail 1 of the drives, create a RAID5 array with one
missing member from the new drive and the failed drive, copy the data from
the remaining live RAID1 drive to the RAID5 array, shut down the RAID1
array, and add the drive to the RAID5 array. Since this system is going to
be bootable, you probably need to use 0.90 metadata for the /boot array.
The rest can be 1.x.
^ permalink raw reply
* Re: [PATCH 0/5] misc cleanups for RAID5
From: NeilBrown @ 2011-06-23 0:55 UTC (permalink / raw)
To: Namhyung Kim; +Cc: linux-raid
In-Reply-To: <1308718230-2536-1-git-send-email-namhyung@gmail.com>
On Wed, 22 Jun 2011 13:50:25 +0900 Namhyung Kim <namhyung@gmail.com> wrote:
> Hello,
>
> These are assorted cleanup patches for RAID5 code.
> Please take a look. Any comments are welcomed.
>
> Thanks.
>
>
> Namhyung Kim (5):
> md/raid5: use kmem_cache_zalloc()
> md/raid5: factor out dev_need_read()
> md/raid5: factor out dev_need_for_write()
> md/raid5: use r5_for_each_bio()
> md/raid5: get rid of duplicated call to bio_data_dir()
>
> drivers/md/raid5.c | 146 ++++++++++++++++++++++++++--------------------------
> 1 files changed, 73 insertions(+), 73 deletions(-)
>
Hi,
thanks for these.
I have applied the first and the last.
The two "factor out" patches conflict with some much more substantial
refactoring I have been doing in raid5.c. I have just pushed all of that
into my for-next branch:
git://neil.brown.name/md for-next
so you can use that as a basis for any further review.
The r5_for_each_bio() patch I'm not 100% sure I'm happy with, and in any
case it would have conflicted with my other changes too.
I'm not fond of macros that hide details that could be important. A
"for_each" macro that purely and simply walks through a list is fine. A
"for_each" macro that does anything more complicated I start to have doubts
about...
However if you really do like it and want to rebase it on the for-next
branch I'll have another look and think harder about it. Maybe I'll end up
liking it after all, but no promises.
Thanks,
NeilBrown
^ permalink raw reply
* [PATCH 5/5] md/raid5: get rid of duplicated call to bio_data_dir()
From: Namhyung Kim @ 2011-06-22 4:50 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
In-Reply-To: <1308718230-2536-1-git-send-email-namhyung@gmail.com>
In raid5::make_request(), once bio_data_dir(@bi) is detected
it never (and couldn't) be changed. Use the result always.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/md/raid5.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 6b92e8549e9b..ccaa1102057d 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -4016,7 +4016,7 @@ static int make_request(mddev_t *mddev, struct bio * bi)
}
}
- if (bio_data_dir(bi) == WRITE &&
+ if (rw == WRITE &&
logical_sector >= mddev->suspend_lo &&
logical_sector < mddev->suspend_hi) {
release_stripe(sh);
@@ -4034,7 +4034,7 @@ static int make_request(mddev_t *mddev, struct bio * bi)
}
if (test_bit(STRIPE_EXPANDING, &sh->state) ||
- !add_stripe_bio(sh, bi, dd_idx, (bi->bi_rw&RW_MASK))) {
+ !add_stripe_bio(sh, bi, dd_idx, rw)) {
/* Stripe is busy expanding or
* add failed due to overlap. Flush everything
* and wait a while
--
1.7.5.2
^ permalink raw reply related
* [PATCH 4/5] md/raid5: use r5_for_each_bio()
From: Namhyung Kim @ 2011-06-22 4:50 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
In-Reply-To: <1308718230-2536-1-git-send-email-namhyung@gmail.com>
There are common bio loop which could be factored out in a usual
for_each_xxx way. Add and use r5_for_each_bio() for those.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/md/raid5.c | 67 ++++++++++++++++++++++++---------------------------
1 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 12f3b939e56d..6b92e8549e9b 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -81,6 +81,18 @@
* of the current stripe+device
*/
#define r5_next_bio(bio, sect) ( ( (bio)->bi_sector + ((bio)->bi_size>>9) < sect + STRIPE_SECTORS) ? (bio)->bi_next : NULL)
+
+/*
+ * Iterates through all attached bio's to the current stripe+device.
+ * The given bio must be initialized before using this macro.
+ */
+#define r5_for_each_bio(bio, nbio, dev) \
+ for ( ; \
+ ({ if (bio) nbio = r5_next_bio(bio, (dev)->sector); \
+ (bio && (bio)->bi_sector < (dev)->sector + STRIPE_SECTORS);}); \
+ bio = nbio \
+ )
+
/*
* The following can be used to debug the driver
*/
@@ -647,15 +659,12 @@ static void ops_complete_biofill(void *stripe_head_ref)
BUG_ON(!dev->read);
rbi = dev->read;
dev->read = NULL;
- while (rbi && rbi->bi_sector <
- dev->sector + STRIPE_SECTORS) {
- rbi2 = r5_next_bio(rbi, dev->sector);
+
+ r5_for_each_bio(rbi, rbi2, dev)
if (!raid5_dec_bi_phys_segments(rbi)) {
rbi->bi_next = return_bi;
return_bi = rbi;
}
- rbi = rbi2;
- }
}
}
spin_unlock_irq(&conf->device_lock);
@@ -680,17 +689,15 @@ static void ops_run_biofill(struct stripe_head *sh)
for (i = sh->disks; i--; ) {
struct r5dev *dev = &sh->dev[i];
if (test_bit(R5_Wantfill, &dev->flags)) {
- struct bio *rbi;
+ struct bio *rbi, *rbi2;
spin_lock_irq(&conf->device_lock);
dev->read = rbi = dev->toread;
dev->toread = NULL;
spin_unlock_irq(&conf->device_lock);
- while (rbi && rbi->bi_sector <
- dev->sector + STRIPE_SECTORS) {
+
+ r5_for_each_bio(rbi, rbi2, dev)
tx = async_copy_data(0, rbi, dev->page,
dev->sector, tx);
- rbi = r5_next_bio(rbi, dev->sector);
- }
}
}
@@ -1018,7 +1025,7 @@ ops_run_biodrain(struct stripe_head *sh, struct dma_async_tx_descriptor *tx)
struct bio *chosen;
if (test_and_clear_bit(R5_Wantdrain, &dev->flags)) {
- struct bio *wbi;
+ struct bio *wbi, *wbi2;
spin_lock(&sh->lock);
chosen = dev->towrite;
@@ -1027,13 +1034,11 @@ ops_run_biodrain(struct stripe_head *sh, struct dma_async_tx_descriptor *tx)
wbi = dev->written = chosen;
spin_unlock(&sh->lock);
- while (wbi && wbi->bi_sector <
- dev->sector + STRIPE_SECTORS) {
+ r5_for_each_bio(wbi, wbi2, dev) {
if (wbi->bi_rw & REQ_FUA)
set_bit(R5_WantFUA, &dev->flags);
tx = async_copy_data(1, wbi, dev->page,
dev->sector, tx);
- wbi = r5_next_bio(wbi, dev->sector);
}
}
}
@@ -2228,7 +2233,7 @@ handle_failed_stripe(raid5_conf_t *conf, struct stripe_head *sh,
{
int i;
for (i = disks; i--; ) {
- struct bio *bi;
+ struct bio *bi, *bi2;
int bitmap_end = 0;
if (test_bit(R5_ReadError, &sh->dev[i].flags)) {
@@ -2252,31 +2257,27 @@ handle_failed_stripe(raid5_conf_t *conf, struct stripe_head *sh,
if (test_and_clear_bit(R5_Overlap, &sh->dev[i].flags))
wake_up(&conf->wait_for_overlap);
- while (bi && bi->bi_sector <
- sh->dev[i].sector + STRIPE_SECTORS) {
- struct bio *nextbi = r5_next_bio(bi, sh->dev[i].sector);
+ r5_for_each_bio(bi, bi2, &sh->dev[i]) {
clear_bit(BIO_UPTODATE, &bi->bi_flags);
if (!raid5_dec_bi_phys_segments(bi)) {
md_write_end(conf->mddev);
bi->bi_next = *return_bi;
*return_bi = bi;
}
- bi = nextbi;
}
/* and fail all 'written' */
bi = sh->dev[i].written;
sh->dev[i].written = NULL;
- if (bi) bitmap_end = 1;
- while (bi && bi->bi_sector <
- sh->dev[i].sector + STRIPE_SECTORS) {
- struct bio *bi2 = r5_next_bio(bi, sh->dev[i].sector);
+ if (bi)
+ bitmap_end = 1;
+
+ r5_for_each_bio(bi, bi2, &sh->dev[i]) {
clear_bit(BIO_UPTODATE, &bi->bi_flags);
if (!raid5_dec_bi_phys_segments(bi)) {
md_write_end(conf->mddev);
bi->bi_next = *return_bi;
*return_bi = bi;
}
- bi = bi2;
}
/* fail any reads if this device is non-operational and
@@ -2289,17 +2290,15 @@ handle_failed_stripe(raid5_conf_t *conf, struct stripe_head *sh,
sh->dev[i].toread = NULL;
if (test_and_clear_bit(R5_Overlap, &sh->dev[i].flags))
wake_up(&conf->wait_for_overlap);
- if (bi) s->to_read--;
- while (bi && bi->bi_sector <
- sh->dev[i].sector + STRIPE_SECTORS) {
- struct bio *nextbi =
- r5_next_bio(bi, sh->dev[i].sector);
+ if (bi)
+ s->to_read--;
+
+ r5_for_each_bio(bi, bi2, &sh->dev[i]) {
clear_bit(BIO_UPTODATE, &bi->bi_flags);
if (!raid5_dec_bi_phys_segments(bi)) {
bi->bi_next = *return_bi;
*return_bi = bi;
}
- bi = nextbi;
}
}
spin_unlock_irq(&conf->device_lock);
@@ -2515,16 +2514,14 @@ static void handle_stripe_clean_event(raid5_conf_t *conf,
spin_lock_irq(&conf->device_lock);
wbi = dev->written;
dev->written = NULL;
- while (wbi && wbi->bi_sector <
- dev->sector + STRIPE_SECTORS) {
- wbi2 = r5_next_bio(wbi, dev->sector);
+
+ r5_for_each_bio(wbi, wbi2, dev)
if (!raid5_dec_bi_phys_segments(wbi)) {
md_write_end(conf->mddev);
wbi->bi_next = *return_bi;
*return_bi = wbi;
}
- wbi = wbi2;
- }
+
if (dev->towrite == NULL)
bitmap_end = 1;
spin_unlock_irq(&conf->device_lock);
--
1.7.5.2
^ permalink raw reply related
* [PATCH 3/5] md/raid5: factor out dev_need_for_write()
From: Namhyung Kim @ 2011-06-22 4:50 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
In-Reply-To: <1308718230-2536-1-git-send-email-namhyung@gmail.com>
Factor out common condition checking code to dev_need_for_write()
to improve readability - please suggest a better name :)
Besides, a couple of wierd whitespace fixes are contained also.
Maybe the checkpatch hates some change but it looks more natural
to fix IMHO.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/md/raid5.c | 47 ++++++++++++++++++++++++-----------------------
1 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 892a95fe6e8f..12f3b939e56d 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2542,6 +2542,18 @@ static void handle_stripe_clean_event(raid5_conf_t *conf,
md_wakeup_thread(conf->mddev->thread);
}
+static bool dev_need_for_write(struct r5dev *dev)
+{
+ if (test_bit(R5_LOCKED, &dev->flags))
+ return false;
+
+ if (!test_bit(R5_UPTODATE, &dev->flags) &&
+ !test_bit(R5_Wantcompute, &dev->flags))
+ return true;
+
+ return false;
+}
+
static void handle_stripe_dirtying5(raid5_conf_t *conf,
struct stripe_head *sh, struct stripe_head_state *s, int disks)
{
@@ -2550,20 +2562,18 @@ static void handle_stripe_dirtying5(raid5_conf_t *conf,
/* would I have to read this buffer for read_modify_write */
struct r5dev *dev = &sh->dev[i];
if ((dev->towrite || i == sh->pd_idx) &&
- !test_bit(R5_LOCKED, &dev->flags) &&
- !(test_bit(R5_UPTODATE, &dev->flags) ||
- test_bit(R5_Wantcompute, &dev->flags))) {
+ dev_need_for_write(dev)) {
if (test_bit(R5_Insync, &dev->flags))
rmw++;
else
rmw += 2*disks; /* cannot read it */
}
/* Would I have to read this buffer for reconstruct_write */
- if (!test_bit(R5_OVERWRITE, &dev->flags) && i != sh->pd_idx &&
- !test_bit(R5_LOCKED, &dev->flags) &&
- !(test_bit(R5_UPTODATE, &dev->flags) ||
- test_bit(R5_Wantcompute, &dev->flags))) {
- if (test_bit(R5_Insync, &dev->flags)) rcw++;
+ if (!test_bit(R5_OVERWRITE, &dev->flags) &&
+ i != sh->pd_idx &&
+ dev_need_for_write(dev)) {
+ if (test_bit(R5_Insync, &dev->flags))
+ rcw++;
else
rcw += 2*disks;
}
@@ -2576,12 +2586,9 @@ static void handle_stripe_dirtying5(raid5_conf_t *conf,
for (i = disks; i--; ) {
struct r5dev *dev = &sh->dev[i];
if ((dev->towrite || i == sh->pd_idx) &&
- !test_bit(R5_LOCKED, &dev->flags) &&
- !(test_bit(R5_UPTODATE, &dev->flags) ||
- test_bit(R5_Wantcompute, &dev->flags)) &&
+ dev_need_for_write(dev) &&
test_bit(R5_Insync, &dev->flags)) {
- if (
- test_bit(STRIPE_PREREAD_ACTIVE, &sh->state)) {
+ if (test_bit(STRIPE_PREREAD_ACTIVE, &sh->state)) {
pr_debug("Read_old block "
"%d for r-m-w\n", i);
set_bit(R5_LOCKED, &dev->flags);
@@ -2599,12 +2606,9 @@ static void handle_stripe_dirtying5(raid5_conf_t *conf,
struct r5dev *dev = &sh->dev[i];
if (!test_bit(R5_OVERWRITE, &dev->flags) &&
i != sh->pd_idx &&
- !test_bit(R5_LOCKED, &dev->flags) &&
- !(test_bit(R5_UPTODATE, &dev->flags) ||
- test_bit(R5_Wantcompute, &dev->flags)) &&
+ dev_need_for_write(dev) &&
test_bit(R5_Insync, &dev->flags)) {
- if (
- test_bit(STRIPE_PREREAD_ACTIVE, &sh->state)) {
+ if (test_bit(STRIPE_PREREAD_ACTIVE, &sh->state)) {
pr_debug("Read_old block "
"%d for Reconstruct\n", i);
set_bit(R5_LOCKED, &dev->flags);
@@ -2645,15 +2649,12 @@ static void handle_stripe_dirtying6(raid5_conf_t *conf,
/* check if we haven't enough data */
if (!test_bit(R5_OVERWRITE, &dev->flags) &&
i != pd_idx && i != qd_idx &&
- !test_bit(R5_LOCKED, &dev->flags) &&
- !(test_bit(R5_UPTODATE, &dev->flags) ||
- test_bit(R5_Wantcompute, &dev->flags))) {
+ dev_need_for_write(dev)) {
rcw++;
if (!test_bit(R5_Insync, &dev->flags))
continue; /* it's a failed drive */
- if (
- test_bit(STRIPE_PREREAD_ACTIVE, &sh->state)) {
+ if (test_bit(STRIPE_PREREAD_ACTIVE, &sh->state)) {
pr_debug("Read_old stripe %llu "
"block %d for Reconstruct\n",
(unsigned long long)sh->sector, i);
--
1.7.5.2
^ permalink raw reply related
* [PATCH 2/5] md/raid5: factor out dev_need_read()
From: Namhyung Kim @ 2011-06-22 4:50 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
In-Reply-To: <1308718230-2536-1-git-send-email-namhyung@gmail.com>
Factor out common condition checking code to dev_need_read()
in the hope that it would improve readability somewhat.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/md/raid5.c | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 0f71aa9a07c5..892a95fe6e8f 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2313,6 +2313,15 @@ handle_failed_stripe(raid5_conf_t *conf, struct stripe_head *sh,
md_wakeup_thread(conf->mddev->thread);
}
+static bool dev_need_read(struct r5dev *dev)
+{
+ if (dev->toread ||
+ (dev->towrite && !test_bit(R5_OVERWRITE, &dev->flags)))
+ return true;
+
+ return false;
+}
+
/* fetch_block5 - checks the given member device to see if its data needs
* to be read or computed to satisfy a request.
*
@@ -2328,13 +2337,9 @@ static int fetch_block5(struct stripe_head *sh, struct stripe_head_state *s,
/* is the data in this block needed, and can we get it? */
if (!test_bit(R5_LOCKED, &dev->flags) &&
!test_bit(R5_UPTODATE, &dev->flags) &&
- (dev->toread ||
- (dev->towrite && !test_bit(R5_OVERWRITE, &dev->flags)) ||
+ (dev_need_read(dev) ||
s->syncing || s->expanding ||
- (s->failed &&
- (failed_dev->toread ||
- (failed_dev->towrite &&
- !test_bit(R5_OVERWRITE, &failed_dev->flags)))))) {
+ (s->failed && dev_need_read(failed_dev)))) {
/* We would like to get this block, possibly by computing it,
* otherwise read it if the backing disk is insync
*/
@@ -2401,8 +2406,7 @@ static int fetch_block6(struct stripe_head *sh, struct stripe_head_state *s,
if (!test_bit(R5_LOCKED, &dev->flags) &&
!test_bit(R5_UPTODATE, &dev->flags) &&
- (dev->toread ||
- (dev->towrite && !test_bit(R5_OVERWRITE, &dev->flags)) ||
+ (dev_need_read(dev) ||
s->syncing || s->expanding ||
(s->failed >= 1 &&
(fdev[0]->toread || s->to_write)) ||
--
1.7.5.2
^ permalink raw reply related
* [PATCH 1/5] md/raid5: use kmem_cache_zalloc()
From: Namhyung Kim @ 2011-06-22 4:50 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
In-Reply-To: <1308718230-2536-1-git-send-email-namhyung@gmail.com>
Replace kmem_cache_alloc + memset(,0,) to kmem_cache_zalloc.
I think it's not harmful since @conf->slab_cache already knows
actual size of struct stripe_head.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/md/raid5.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index b72edf35ec54..0f71aa9a07c5 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1315,10 +1315,10 @@ static void raid_run_ops(struct stripe_head *sh, unsigned long ops_request)
static int grow_one_stripe(raid5_conf_t *conf)
{
struct stripe_head *sh;
- sh = kmem_cache_alloc(conf->slab_cache, GFP_KERNEL);
+ sh = kmem_cache_zalloc(conf->slab_cache, GFP_KERNEL);
if (!sh)
return 0;
- memset(sh, 0, sizeof(*sh) + (conf->pool_size-1)*sizeof(struct r5dev));
+
sh->raid_conf = conf;
spin_lock_init(&sh->lock);
#ifdef CONFIG_MULTICORE_RAID456
@@ -1435,12 +1435,10 @@ static int resize_stripes(raid5_conf_t *conf, int newsize)
return -ENOMEM;
for (i = conf->max_nr_stripes; i; i--) {
- nsh = kmem_cache_alloc(sc, GFP_KERNEL);
+ nsh = kmem_cache_zalloc(sc, GFP_KERNEL);
if (!nsh)
break;
- memset(nsh, 0, sizeof(*nsh) + (newsize-1)*sizeof(struct r5dev));
-
nsh->raid_conf = conf;
spin_lock_init(&nsh->lock);
#ifdef CONFIG_MULTICORE_RAID456
--
1.7.5.2
^ permalink raw reply related
* [PATCH 0/5] misc cleanups for RAID5
From: Namhyung Kim @ 2011-06-22 4:50 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid
Hello,
These are assorted cleanup patches for RAID5 code.
Please take a look. Any comments are welcomed.
Thanks.
Namhyung Kim (5):
md/raid5: use kmem_cache_zalloc()
md/raid5: factor out dev_need_read()
md/raid5: factor out dev_need_for_write()
md/raid5: use r5_for_each_bio()
md/raid5: get rid of duplicated call to bio_data_dir()
drivers/md/raid5.c | 146 ++++++++++++++++++++++++++--------------------------
1 files changed, 73 insertions(+), 73 deletions(-)
--
1.7.5.2
^ permalink raw reply
* Re: reaid problem at reboot
From: Phil Turmel @ 2011-06-22 3:53 UTC (permalink / raw)
To: william L'Heureux; +Cc: linux-raid
In-Reply-To: <BAY158-w1B10F98EB9026A0F3D50CC0500@phx.gbl>
On 06/21/2011 11:34 PM, william L'Heureux wrote:
>
> /dev/sdj1 cant be first, its /dev/sda1.
'j' had the lvm metadata in the right spot. It was first. If it's not now, then your partial rebuild scrambled it. I don't think I have any more expertise to offer at this point.
> My friend made a python script. take a look.
>
> cat rebuild.py
[...]
Nice to automate the search, especially with many combinations.
> i can see the data with the combinatin below, but there is a lot of errors, sounds like a rebuild was started(beghining of the disk) then was canceled
That hurts.
> we made a snapshot, run a e2fsck on it and im still(not now, gotta sleep) add 1 missing or 2. after the e2fsck i mount the snap, look at the data, check corruption, rince and repeat with another combination of missing and not. i rate the ones with less corruption
>
> the only e2fsck working is with --->>> a,j,c,h,i,d
Good luck.
Phil
^ permalink raw reply
* RE: reaid problem at reboot
From: william L'Heureux @ 2011-06-22 3:34 UTC (permalink / raw)
To: philip; +Cc: linux-raid
In-Reply-To: <4E0153C1.1040708@turmel.org>
/dev/sdj1 cant be first, its /dev/sda1.
My friend made a python script. take a look.
cat rebuild.py
#!/usr/bin/env python
# /dev/sdj1 /dev/sdc1 /dev/sda1 /dev/sdd1 /dev/sdh1 /dev/sdi1
import os;
import time;
from itertools import permutations;
#aLetters = ( 'a', 'c', 'd', 'h', 'i', 'j' );
aLetters = ( 'j', 'c', 'h' );
j = [];
for i in permutations(aLetters):
if i[0:3] == j[0:3]: continue;
j = i;
time.sleep(0.1);
os.system("vgchange -an vgRAID60 2>/dev/null >/dev/null");
os.system("mdadm -S /dev/md127 2>/dev/null >/dev/null");
os.system("mdadm -S /dev/md126 2>/dev/null >/dev/null");
os.system("mdadm -S /dev/md0 2>/dev/null >/dev/null");
(hStdin, hStdout) = os.popen4("mdadm --create /dev/md0 --level=6 --raid-devices=6 --assume-clean --chunk=128 /dev/sda1 /dev/sd%s1 /dev/sd%s1 /dev/sd%s1 missing missing" % (i[0:3]));
hStdin.write("y\n");
hStdin.close();
hStdout.close();
time.sleep(0.5);
(hStdin, hStdout) = os.popen4("pvck /dev/md0");
sOutput = hStdout.read();
hStdin.close();
hStdout.close();
print("/dev/sdj1 /dev/sd%s1 /dev/sd%s1 /dev/sd%s1 missing missing" % (i[0:3]));
fRAID = open("/dev/md0", 'r');
try:
fRAID.seek(4608);
sLVM = fRAID.read(128);
fRAID.close();
except:
fRAID.close();
continue;
print(sLVM);
if sOutput.find("Found label") != -1:
os.system("/bin/bash");
# os.system("vgchange -ay vgRAID60 2>/dev/null >/dev/null");
# os.system("vgmknodes");
# iExit = os.system("e2fsck -n /dev/vgRAID60/data0");
# if iExit == 0:
# print("/dev/sd%s1 /dev/sd%s1 /dev/sd%s1 /dev/sd%s1 missing missing" % (i));
i can see the data with the combinatin below, but there is a lot of errors, sounds like a rebuild was started(beghining of the disk) then was canceled
we made a snapshot, run a e2fsck on it and im still(not now, gotta sleep) add 1 missing or 2. after the e2fsck i mount the snap, look at the data, check corruption, rince and repeat with another combination of missing and not. i rate the ones with less corruption
the only e2fsck working is with --->>> a,j,c,h,i,d
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RAID5: failing an active component during spare rebuild - arrays hangs
From: NeilBrown @ 2011-06-22 2:54 UTC (permalink / raw)
To: Alexander Lyakas; +Cc: linux-raid
In-Reply-To: <BANLkTinwr9UE_B+MSXfbE2nAv0wLrTvhXg@mail.gmail.com>
On Sun, 5 Jun 2011 22:41:55 +0300 Alexander Lyakas <alex.bolshoy@gmail.com>
wrote:
> Hello everybody,
> I am testing a scenario, in which I create a RAID5 with three devices:
> /dev/sd{a,b,c}. Since I don't supply --force to mdadm during creation,
> it treats the array as degraded and starts rebuilding the sdc as a
> spare. This is as documented.
>
> Then I do --fail on /dev/sda. I understand that at this point my data
> is gone, but I think should still be able to tear down the array.
>
> Sometimes I see that /dev/sda is kicked from the array as faulty, and
> /dev/sdc is also removed and marked as a spare. Then I am able to tear
> down the array.
>
> But sometimes, it looks like the system hits some kind of a deadlock.
I cannot reproduce this, either on current mainline or 2.6.38. I didn't try
the particular Ubuntu kernel that you mentioned as I don't have any Ubuntu
machines.
It is unlikely that Ubuntu have broken something, but not impossible... are
you able to compile a kernel.org kernel (preferably 2.6.39) and see if you
can reproduce.
Also, can you provide a simple script that will trigger the bug reliably for
you.
I did:
while : ; do mdadm -CR /dev/md0 -l5 -n3 /dev/sd[abc] ; sleep 5; mdadm /dev/md0 -f /dev/sda ; mdadm -Ss ; echo ; echo; done
and it has no problems at all.
Certainly a deadlock shouldn't be happening...
From the stack trace you get it looks like it is probably hanging at
wait_event(mddev->recovery_wait, !atomic_read(&mddev->recovery_active));
which suggests that so resync request started and didn't complete. I've
never seen a hang there before.
NeilBrown
^ permalink raw reply
* Re: reaid problem at reboot
From: Phil Turmel @ 2011-06-22 2:30 UTC (permalink / raw)
To: william L'Heureux; +Cc: linux-raid
In-Reply-To: <BAY158-w9526A91B9B67956C12924C0500@phx.gbl>
Hi William,
Progress!
On 06/21/2011 09:50 PM, william L'Heureux wrote:
> for x in /dev/sd[abcdefghijkm]1 ; do echo "**** $x ****" ; dd if=$x skip=2056 count=2 2>/dev/null |strings ; done
> **** /dev/sda1 ****
> **** /dev/sdb1 ****
[...]
> **** /dev/sdc1 ****
> **** /dev/sdd1 ****
> !HV]3$xK
> M1N+>
> vgRQID6 {
> *= "RUodpI-jXin-D<
> s-fC3R-$hjA=hQ4l-41dAaJ"
> seqnoV
> ctates =0["RESIZEABLE", "RE7
> ", 2WRIDE"]
> jags = []
> extent_
> ze - 81)2
> mqx_lv = 0
> max_pv = F
> phisicql_v
> 6wmes {
> pv0 {
> &"V5s1yI=XD3T-FXlB-VDYd-tUfo-eI#
> -hXAfVW2
> defice = "/dev/md1"
> atuc = K"AL\
> @ATABLE"]
> flags =
> duv_syze -V2814057984
> pe_sta
> = %12
> `e_c
> zjt = 953864
> pv6[{
> it = 2BzZs
> n-uC9b-MQne-caBo-
> Np3-)xkA=NnGeUA"
> device = "/dev
> stqtus0E"["ALLOCATABLE"]
> ags0= [M
> pize = 7814057984Z
> e_sdart0= 5!q
> pe_count = 95386
> **** /dev/sde1 ****
> **** /dev/sdf1 ****
> **** /dev/sdg1 ****
[...]
> **** /dev/sdh1 ****
> **** /dev/sdi1 ****
> "RiodpI-jXin-
> dAaJ"
> seqn
> a82j
> SIfEABLE", "R
> extent
> max_pv =
> pv0 {
> B-jDYd-tUfo-e
> /dev/md1"
> ABpE"]
> flags
> 40 7984
> pe_st
> 53864
> C9^-MQne-caBo
> deJice = "/de
> q82B
> ALpOCATABLE"]
> 781405798
> 7m!_
> _cSunt = 9538
> **** /dev/sdj1 ****
> LVM2 x[5A%r0N*>
> vgRAID60 {
> id = "RUodpI-jXin-DEjs-fS3R-4hjA-hQ4l-41dAaJ"
> seqno = 2
> status = ["RESIZEABLE", "READ", "WRITE"]
> flags = []
> extent_size = 8192
> max_lv = 0
> max_pv = 0
> physical_volumes {
> pv0 {
> id = "V5c1yI-XD3D-FXlB-VDYd-tUfo-eIUC-hXQfVW"
> device = "/dev/md1"
> status = ["ALLOCATABLE"]
> flags = []
> dev_size = 7814057984
> pe_start = 512
> pe_count = 953864
> pv1 {
> id = "BzZcan-uC9b-MQne-caBo-tYp3-9xkA-NnGuBE"
> device = "/dev/md2"
> status = ["ALLOCATABLE"]
> flags = []
> dev_size = 7814057984
> pe_start = 512
> pe_count = 953864
> **** /dev/sdk1 ****
[...]
> **** /dev/sdm1 ****
>
>
> for x in /dev/sd[abcdefghijkm]1 ; do echo "**** $x ****" ; dd if=$x skip=2048 count=1 2>/dev/null |hexdump -C ; done
> **** /dev/sda1 ****
[...] (These weren't helpful, after all.)
> btw, /dev/md1 is fine 100%
Good. That simplifies the rest.
> the drives for /dev/md0 --> 'a', 'c', 'd', 'h', 'i', 'j'
Based on the above, 'j' is almost certainly the first disk in md0, and I suspect 'i' is the 'P' parity drive, and 'd' is the 'Q' parity drive.
Stop LVM, and stop md0, then re-create (re-assembly won't fix this):
mdadm --create --assume-clean /dev/md0 --raid-devices=6 --level=6 --chunk=128 /dev/sd{j,a,c,h,i,d}1
(You must not use the [] syntax here..., and "--assume-clean" is vital.)
restart LVM, then "fsck -n" to test.
If not yet good, shuffle 'a', 'c', & 'h'.
If still not good, swap 'i' & 'd', then try the combinations of 'a', 'c', and 'h' again.
Please let us know what combination, if any, works. Absolutely do *not* attempt to mount until "fsck -n" reports no problems, or not many problems.
Phil
^ permalink raw reply
* RE: reaid problem at reboot
From: william L'Heureux @ 2011-06-22 1:50 UTC (permalink / raw)
To: philip; +Cc: linux-raid
In-Reply-To: <4E0146B6.40101@turmel.org>
for x in /dev/sd[abcdefghijkm]1 ; do echo "**** $x ****" ; dd if=$x skip=2056 count=2 2>/dev/null |strings ; done
**** /dev/sda1 ****
**** /dev/sdb1 ****
LVM2 x[5A%r0N*>
vgRAID60 {
id = "RUodpI-jXin-DEjs-fS3R-4hjA-hQ4l-41dAaJ"
seqno = 19
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id = "V5c1yI-XD3D-FXlB-VDYd-tUfo-eIUC-hXQfVW"
device = "/dev/md1"
status = ["ALLOCATABLE"]
flags = []
dev_size = 7799999488
pe_start = 512
pe_count = 952148
pv1 {
id = "BzZcan-uC9b-MQne-caBo-tYp3-9xkA-NnGuBE"
device = "/dev/md2"
status = ["ALLOCATABLE"]
flags = []
dev_size = 7799999488
pe_start = 512
pe_count = 952148
**** /dev/sdc1 ****
**** /dev/sdd1 ****
!HV]3$xK
M1N+>
vgRQID6 {
*= "RUodpI-jXin-D<
s-fC3R-$hjA=hQ4l-41dAaJ"
seqnoV
ctates =0["RESIZEABLE", "RE7
", 2WRIDE"]
jags = []
extent_
ze - 81)2
mqx_lv = 0
max_pv = F
phisicql_v
6wmes {
pv0 {
&"V5s1yI=XD3T-FXlB-VDYd-tUfo-eI#
-hXAfVW2
defice = "/dev/md1"
atuc = K"AL\
@ATABLE"]
flags =
duv_syze -V2814057984
pe_sta
= %12
`e_c
zjt = 953864
pv6[{
it = 2BzZs
n-uC9b-MQne-caBo-
Np3-)xkA=NnGeUA"
device = "/dev
stqtus0E"["ALLOCATABLE"]
ags0= [M
pize = 7814057984Z
e_sdart0= 5!q
pe_count = 95386
**** /dev/sde1 ****
**** /dev/sdf1 ****
**** /dev/sdg1 ****
LV]2 xK
A%r0N*>
vgRQID6 {
/= "RUodpI-jXin-Dz
s-fC3R-$hjA=hQ4l-41dAaJ"
seqnoV
stadus - ["RESIZEABLE", "R3
D",0"WRYTE"M
flags = []
extent)
ize0= 8!92
y_lv = 0
max_pv =.
pxysisal_f
mumes {
pv0 {
"V%c1yY-XD#D-FXlB-VDYd-tUfo-e?
C-hHQfVG"
duvice = "/dev/md1"
tates =0["A\LOCATABLE"]
flags K
tev_cize0= 7799999488
pe_st
t =0512
pe_sount = 952148
yd =0"BzJcan-uC9b-MQne-caBo[
Yp3=9xkQ-NnW
device = "/de
md22
sdatuc = ["ALLOCATABLE"]|
lagc = K]
duv_size = 779999948N
pe_ctard = %12
pe_count = 9521B
**** /dev/sdh1 ****
**** /dev/sdi1 ****
"RiodpI-jXin-
dAaJ"
seqn
a82j
SIfEABLE", "R
extent
max_pv =
pv0 {
B-jDYd-tUfo-e
/dev/md1"
ABpE"]
flags
40 7984
pe_st
53864
C9^-MQne-caBo
deJice = "/de
q82B
ALpOCATABLE"]
781405798
7m!_
_cSunt = 9538
**** /dev/sdj1 ****
LVM2 x[5A%r0N*>
vgRAID60 {
id = "RUodpI-jXin-DEjs-fS3R-4hjA-hQ4l-41dAaJ"
seqno = 2
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id = "V5c1yI-XD3D-FXlB-VDYd-tUfo-eIUC-hXQfVW"
device = "/dev/md1"
status = ["ALLOCATABLE"]
flags = []
dev_size = 7814057984
pe_start = 512
pe_count = 953864
pv1 {
id = "BzZcan-uC9b-MQne-caBo-tYp3-9xkA-NnGuBE"
device = "/dev/md2"
status = ["ALLOCATABLE"]
flags = []
dev_size = 7814057984
pe_start = 512
pe_count = 953864
**** /dev/sdk1 ****
"RiodpI-jXin-
dAaJ"
seqn
.[81Y
ESuZEABLE", "
= []
exten
max_pv
pv0 {
VDYd-tUfo-
"/dev/md1"
TA~LE"]
flags
99488
pe_s
952148
b-MQne-caB
6 pS
dYvice = "/d
"ApLOCATABLE"
_<$a
= 77999994
e__ount = 952
**** /dev/sdm1 ****
for x in /dev/sd[abcdefghijkm]1 ; do echo "**** $x ****" ; dd if=$x skip=2048 count=1 2>/dev/null |hexdump -C ; done
**** /dev/sda1 ****
00000000 00 00 c0 0f 10 00 c0 0f 20 00 c0 0f e0 02 00 20 |........ ...... |
00000010 00 00 05 00 00 00 00 00 00 00 00 00 00 20 92 26 |............. .&|
00000020 01 00 c0 0f 11 00 c0 0f 20 02 c0 0f 00 00 00 20 |........ ...... |
00000030 00 00 05 00 00 00 00 00 00 00 00 00 00 20 df 10 |............. ..|
00000040 02 00 c0 0f 12 00 c0 0f 20 04 c0 0f 00 00 00 20 |........ ...... |
00000050 00 00 05 00 00 00 00 00 00 00 00 00 00 20 b1 b1 |............. ..|
00000060 03 00 c0 0f 13 00 c0 0f 20 06 c0 0f 00 00 00 20 |........ ...... |
00000070 00 00 05 00 00 00 00 00 00 00 00 00 00 20 6a 11 |............. j.|
00000080 04 00 c0 0f 14 00 c0 0f 20 08 c0 0f 00 00 00 20 |........ ...... |
00000090 00 00 05 00 00 00 00 00 00 00 00 00 00 20 6e b3 |............. n.|
000000a0 05 00 c0 0f 15 00 c0 0f 20 0a c0 0f 00 00 00 20 |........ ...... |
000000b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 b5 13 |............. ..|
000000c0 06 00 c0 0f 16 00 c0 0f 20 0c c0 0f 00 00 00 20 |........ ...... |
000000d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 db b2 |............. ..|
000000e0 07 00 c0 0f 17 00 c0 0f 20 0e c0 0f 00 00 00 20 |........ ...... |
000000f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 00 12 |............. ..|
00000100 08 00 c0 0f 18 00 c0 0f 20 10 c0 0f 00 00 00 20 |........ ...... |
00000110 00 00 05 00 00 00 00 00 00 00 00 00 00 20 d0 b6 |............. ..|
00000120 09 00 c0 0f 19 00 c0 0f 20 12 c0 0f 00 00 00 20 |........ ...... |
00000130 00 00 05 00 00 00 00 00 00 00 00 00 00 20 0b 16 |............. ..|
00000140 0a 00 c0 0f 1a 00 c0 0f 20 14 c0 0f 00 00 00 20 |........ ...... |
00000150 00 00 05 00 00 00 00 00 00 00 00 00 00 20 65 b7 |............. e.|
00000160 0b 00 c0 0f 1b 00 c0 0f 20 16 c0 0f 00 00 00 20 |........ ...... |
00000170 00 00 05 00 00 00 00 00 00 00 00 00 00 20 be 17 |............. ..|
00000180 0c 00 c0 0f 1c 00 c0 0f 20 18 c0 0f 00 00 00 20 |........ ...... |
00000190 00 00 05 00 00 00 00 00 00 00 00 00 00 20 ba b5 |............. ..|
000001a0 0d 00 c0 0f 1d 00 c0 0f 20 1a c0 0f 00 00 00 20 |........ ...... |
000001b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 61 15 |............. a.|
000001c0 0e 00 c0 0f 1e 00 c0 0f 20 1c c0 0f 00 00 00 20 |........ ...... |
000001d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 0f b4 |............. ..|
000001e0 0f 00 c0 0f 1f 00 c0 0f 20 1e c0 0f 00 00 00 20 |........ ...... |
000001f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 d4 14 |............. ..|
00000200
**** /dev/sdb1 ****
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
**** /dev/sdc1 ****
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
**** /dev/sdd1 ****
00000000 00 00 c0 0f 10 00 c0 0f 20 00 c0 0f e0 02 00 20 |........ ...... |
00000010 00 00 05 00 00 00 00 00 00 00 00 00 00 20 92 26 |............. .&|
00000020 01 00 c0 0f 11 00 c0 0f 20 02 c0 0f 00 00 00 20 |........ ...... |
00000030 00 00 05 00 00 00 00 00 00 00 00 00 00 20 df 10 |............. ..|
00000040 02 00 c0 0f 12 00 c0 0f 20 04 c0 0f 00 00 00 20 |........ ...... |
00000050 00 00 05 00 00 00 00 00 00 00 00 00 00 20 b1 b1 |............. ..|
00000060 03 00 c0 0f 13 00 c0 0f 20 06 c0 0f 00 00 00 20 |........ ...... |
00000070 00 00 05 00 00 00 00 00 00 00 00 00 00 20 6a 11 |............. j.|
00000080 04 00 c0 0f 14 00 c0 0f 20 08 c0 0f 00 00 00 20 |........ ...... |
00000090 00 00 05 00 00 00 00 00 00 00 00 00 00 20 6e b3 |............. n.|
000000a0 05 00 c0 0f 15 00 c0 0f 20 0a c0 0f 00 00 00 20 |........ ...... |
000000b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 b5 13 |............. ..|
000000c0 06 00 c0 0f 16 00 c0 0f 20 0c c0 0f 00 00 00 20 |........ ...... |
000000d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 db b2 |............. ..|
000000e0 07 00 c0 0f 17 00 c0 0f 20 0e c0 0f 00 00 00 20 |........ ...... |
000000f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 00 12 |............. ..|
00000100 08 00 c0 0f 18 00 c0 0f 20 10 c0 0f 00 00 00 20 |........ ...... |
00000110 00 00 05 00 00 00 00 00 00 00 00 00 00 20 d0 b6 |............. ..|
00000120 09 00 c0 0f 19 00 c0 0f 20 12 c0 0f 00 00 00 20 |........ ...... |
00000130 00 00 05 00 00 00 00 00 00 00 00 00 00 20 0b 16 |............. ..|
00000140 0a 00 c0 0f 1a 00 c0 0f 20 14 c0 0f 00 00 00 20 |........ ...... |
00000150 00 00 05 00 00 00 00 00 00 00 00 00 00 20 65 b7 |............. e.|
00000160 0b 00 c0 0f 1b 00 c0 0f 20 16 c0 0f 00 00 00 20 |........ ...... |
00000170 00 00 05 00 00 00 00 00 00 00 00 00 00 20 be 17 |............. ..|
00000180 0c 00 c0 0f 1c 00 c0 0f 20 18 c0 0f 00 00 00 20 |........ ...... |
00000190 00 00 05 00 00 00 00 00 00 00 00 00 00 20 ba b5 |............. ..|
000001a0 0d 00 c0 0f 1d 00 c0 0f 20 1a c0 0f 00 00 00 20 |........ ...... |
000001b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 61 15 |............. a.|
000001c0 0e 00 c0 0f 1e 00 c0 0f 20 1c c0 0f 00 00 00 20 |........ ...... |
000001d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 0f b4 |............. ..|
000001e0 0f 00 c0 0f 1f 00 c0 0f 20 1e c0 0f 00 00 00 20 |........ ...... |
000001f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 d4 14 |............. ..|
00000200
**** /dev/sde1 ****
00000000 00 00 c0 13 10 00 c0 13 20 00 c0 13 e0 04 00 20 |........ ...... |
00000010 00 00 05 00 00 00 00 00 00 00 00 00 00 20 e0 f7 |............. ..|
00000020 01 00 c0 13 11 00 c0 13 20 02 c0 13 00 00 00 20 |........ ...... |
00000030 00 00 05 00 00 00 00 00 00 00 00 00 00 20 4e 60 |............. N`|
00000040 02 00 c0 13 12 00 c0 13 20 04 c0 13 1f 04 00 20 |........ ...... |
00000050 00 00 05 00 00 00 00 00 00 00 00 00 00 20 55 d2 |............. U.|
00000060 03 00 c0 13 13 00 c0 13 20 06 c0 13 50 00 00 20 |........ ...P.. |
00000070 00 00 05 00 00 00 00 00 00 00 00 00 00 20 ea 70 |............. .p|
00000080 04 00 c0 13 14 00 c0 13 20 08 c0 13 00 00 00 20 |........ ...... |
00000090 00 00 05 00 00 00 00 00 00 00 00 00 00 20 ff c3 |............. ..|
000000a0 05 00 c0 13 15 00 c0 13 20 0a c0 13 00 00 00 20 |........ ...... |
000000b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 24 63 |............. $c|
000000c0 06 00 c0 13 16 00 c0 13 20 0c c0 13 00 00 00 20 |........ ...... |
000000d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 4a c2 |............. J.|
000000e0 07 00 c0 13 17 00 c0 13 20 0e c0 13 7f 00 00 20 |........ ...... |
000000f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 b8 ae |............. ..|
00000100 08 00 c0 13 18 00 c0 13 20 10 c0 13 00 00 00 20 |........ ...... |
00000110 00 00 05 00 00 00 00 00 00 00 00 00 00 20 41 c6 |............. A.|
00000120 09 00 c0 13 19 00 c0 13 20 12 c0 13 00 00 00 20 |........ ...... |
00000130 00 00 05 00 00 00 00 00 00 00 00 00 00 20 9a 66 |............. .f|
00000140 0a 00 c0 13 1a 00 c0 13 20 14 c0 13 00 00 00 20 |........ ...... |
00000150 00 00 05 00 00 00 00 00 00 00 00 00 00 20 f4 c7 |............. ..|
00000160 0b 00 c0 13 1b 00 c0 13 20 16 c0 13 00 00 00 20 |........ ...... |
00000170 00 00 05 00 00 00 00 00 00 00 00 00 00 20 2f 67 |............. /g|
00000180 0c 00 c0 13 1c 00 c0 13 20 18 c0 13 00 00 00 20 |........ ...... |
00000190 00 00 05 00 00 00 00 00 00 00 00 00 00 20 2b c5 |............. +.|
000001a0 0d 00 c0 13 1d 00 c0 13 20 1a c0 13 00 00 00 20 |........ ...... |
000001b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 f0 65 |............. .e|
000001c0 0e 00 c0 13 1e 00 c0 13 20 1c c0 13 00 00 00 20 |........ ...... |
000001d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 9e c4 |............. ..|
000001e0 0f 00 c0 13 1f 00 c0 13 20 1e c0 13 00 00 00 20 |........ ...... |
000001f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 45 64 |............. Ed|
00000200
**** /dev/sdf1 ****
00000000 00 00 c0 03 10 00 c0 03 20 00 c0 03 0c 08 00 20 |........ ...... |
00000010 00 00 05 00 00 00 00 00 00 00 00 00 00 20 a7 fc |............. ..|
00000020 01 00 c0 03 11 00 c0 03 20 02 c0 03 00 00 00 20 |........ ...... |
00000030 00 00 05 00 00 00 00 00 00 00 00 00 00 20 38 cd |............. 8.|
00000040 02 00 c0 03 12 00 c0 03 20 04 c0 03 00 00 00 20 |........ ...... |
00000050 00 00 05 00 00 00 00 00 00 00 00 00 00 20 56 6c |............. Vl|
00000060 03 00 c0 03 13 00 c0 03 20 06 c0 03 00 00 00 20 |........ ...... |
00000070 00 00 05 00 00 00 00 00 00 00 00 00 00 20 8d cc |............. ..|
00000080 04 00 c0 03 14 00 c0 03 20 08 c0 03 00 00 00 20 |........ ...... |
00000090 00 00 05 00 00 00 00 00 00 00 00 00 00 20 89 6e |............. .n|
000000a0 05 00 c0 03 15 00 c0 03 20 0a c0 03 00 00 00 20 |........ ...... |
000000b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 52 ce |............. R.|
000000c0 06 00 c0 03 16 00 c0 03 20 0c c0 03 00 00 00 20 |........ ...... |
000000d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 3c 6f |............. <o|
000000e0 07 00 c0 03 17 00 c0 03 20 0e c0 03 00 00 00 20 |........ ...... |
000000f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 e7 cf |............. ..|
00000100 08 00 c0 03 18 00 c0 03 20 10 c0 03 00 00 00 20 |........ ...... |
00000110 00 00 05 00 00 00 00 00 00 00 00 00 00 20 37 6b |............. 7k|
00000120 09 00 c0 03 19 00 c0 03 20 12 c0 03 00 00 00 20 |........ ...... |
00000130 00 00 05 00 00 00 00 00 00 00 00 00 00 20 ec cb |............. ..|
00000140 0a 00 c0 03 1a 00 c0 03 20 14 c0 03 00 00 00 20 |........ ...... |
00000150 00 00 05 00 00 00 00 00 00 00 00 00 00 20 82 6a |............. .j|
00000160 0b 00 c0 03 1b 00 c0 03 20 16 c0 03 00 00 00 20 |........ ...... |
00000170 00 00 05 00 00 00 00 00 00 00 00 00 00 20 59 ca |............. Y.|
00000180 0c 00 c0 03 1c 00 c0 03 20 18 c0 03 00 00 00 20 |........ ...... |
00000190 00 00 05 00 00 00 00 00 00 00 00 00 00 20 5d 68 |............. ]h|
000001a0 0d 00 c0 03 1d 00 c0 03 20 1a c0 03 00 00 00 20 |........ ...... |
000001b0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 86 c8 |............. ..|
000001c0 0e 00 c0 03 1e 00 c0 03 20 1c c0 03 00 00 00 20 |........ ...... |
000001d0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 e8 69 |............. .i|
000001e0 0f 00 c0 03 1f 00 c0 03 20 1e c0 03 00 00 00 20 |........ ...... |
000001f0 00 00 05 00 00 00 00 00 00 00 00 00 00 20 33 c9 |............. 3.|
00000200
**** /dev/sdg1 ****
00000000 00 00 00 10 00 00 00 10 00 00 00 10 ec 0c 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 47 0b |..............G.|
00000020 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000040 00 00 00 10 00 00 00 10 00 00 00 10 1f 04 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 be |................|
00000060 00 00 00 10 00 00 00 10 00 00 00 10 50 00 00 00 |............P...|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 67 bc |..............g.|
00000080 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000000a0 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000000c0 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000000e0 00 00 00 10 00 00 00 10 00 00 00 10 7f 00 00 00 |................|
000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5f 61 |.............._a|
00000100 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000120 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000140 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000160 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000180 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000001a0 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000001c0 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
000001e0 00 00 00 10 00 00 00 10 00 00 00 10 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 ad |..............v.|
00000200
**** /dev/sdh1 ****
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
**** /dev/sdi1 ****
00000000 00 00 4e 78 80 00 4e 78 1d 00 4e 78 53 10 00 1d |..Nx..Nx..NxS...|
00000010 00 00 28 00 00 00 00 00 00 00 00 00 00 1d e4 2d |..(............-|
00000020 08 00 4e 78 88 00 4e 78 1d 10 4e 78 00 00 00 1d |..Nx..Nx..Nx....|
00000030 00 00 28 00 00 00 00 00 00 00 00 00 00 1d b6 80 |..(.............|
00000040 10 00 4e 78 90 00 4e 78 1d 20 4e 78 00 00 00 1d |..Nx..Nx. Nx....|
00000050 00 00 28 00 00 00 00 00 00 00 00 00 00 1d e1 e1 |..(.............|
00000060 18 00 4e 78 98 00 4e 78 1d 30 4e 78 00 00 00 1d |..Nx..Nx.0Nx....|
00000070 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 77 88 |..(...........w.|
00000080 20 00 4e 78 a0 00 4e 78 1d 40 4e 78 00 00 00 1d | .Nx..Nx.@Nx....|
00000090 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 57 f1 |..(...........W.|
000000a0 28 00 4e 78 a8 00 4e 78 1d 50 4e 78 00 00 00 1d |(.Nx..Nx.PNx....|
000000b0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d c1 98 |..(.............|
000000c0 30 00 4e 78 b0 00 4e 78 1d 60 4e 78 00 00 00 1d |0.Nx..Nx.`Nx....|
000000d0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 96 f9 |..(.............|
000000e0 38 00 4e 78 b8 00 4e 78 1d 70 4e 78 00 00 00 1d |8.Nx..Nx.pNx....|
000000f0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 00 90 |..(.............|
00000100 40 00 4e 78 c0 00 4e 78 1d 80 4e 78 00 00 00 1d |@.Nx..Nx..Nx....|
00000110 00 00 28 00 00 00 00 00 00 00 00 00 00 1d ce d9 |..(.............|
00000120 48 00 4e 78 c8 00 4e 78 1d 90 4e 78 00 00 00 1d |H.Nx..Nx..Nx....|
00000130 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 58 b0 |..(...........X.|
00000140 50 00 4e 78 d0 00 4e 78 1d a0 4e 78 00 00 00 1d |P.Nx..Nx..Nx....|
00000150 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 0f d1 |..(.............|
00000160 58 00 4e 78 d8 00 4e 78 1d b0 4e 78 00 00 00 1d |X.Nx..Nx..Nx....|
00000170 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 99 b8 |..(.............|
00000180 60 00 4e 78 e0 00 4e 78 1d c0 4e 78 00 00 00 1d |`.Nx..Nx..Nx....|
00000190 00 00 28 00 00 00 00 00 00 00 00 00 00 1d b9 c1 |..(.............|
000001a0 68 00 4e 78 e8 00 4e 78 1d d0 4e 78 00 00 00 1d |h.Nx..Nx..Nx....|
000001b0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 2f a8 |..(.........../.|
000001c0 70 00 4e 78 f0 00 4e 78 1d e0 4e 78 00 00 00 1d |p.Nx..Nx..Nx....|
000001d0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d 78 c9 |..(...........x.|
000001e0 78 00 4e 78 f8 00 4e 78 1d f0 4e 78 00 00 00 1d |x.Nx..Nx..Nx....|
000001f0 00 00 28 00 00 00 00 00 00 00 00 00 00 1d ee a0 |..(.............|
00000200
**** /dev/sdj1 ****
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
**** /dev/sdk1 ****
00000000 00 00 69 94 c0 00 69 94 9d 00 69 94 63 00 00 9d |..i...i...i.c...|
00000010 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d f5 3c |..<............<|
00000020 0c 00 69 94 cc 00 69 94 9d 18 69 94 00 00 00 9d |..i...i...i.....|
00000030 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d aa 34 |..<............4|
00000040 18 00 69 94 d8 00 69 94 9d 30 69 94 f8 20 00 9d |..i...i..0i.. ..|
00000050 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d d7 73 |..<............s|
00000060 14 00 69 94 d4 00 69 94 9d 28 69 94 ba 00 00 9d |..i...i..(i.....|
00000070 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 0d b0 |..<.............|
00000080 30 00 69 94 f0 00 69 94 9d 60 69 94 00 00 00 9d |0.i...i..`i.....|
00000090 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d b5 f3 |..<.............|
000000a0 3c 00 69 94 fc 00 69 94 9d 78 69 94 00 00 00 9d |<.i...i..xi.....|
000000b0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 68 20 |..<...........h |
000000c0 28 00 69 94 e8 00 69 94 9d 50 69 94 00 00 00 9d |(.i...i..Pi.....|
000000d0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 9a ff |..<.............|
000000e0 24 00 69 94 e4 00 69 94 9d 48 69 94 df 00 00 9d |$.i...i..Hi.....|
000000f0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 12 02 |..<.............|
00000100 60 00 69 94 a0 00 69 94 9d c0 69 94 00 00 00 9d |`.i...i...i.....|
00000110 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d ee cf |..<.............|
00000120 6c 00 69 94 ac 00 69 94 9d d8 69 94 00 00 00 9d |l.i...i...i.....|
00000130 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 33 1c |..<...........3.|
00000140 78 00 69 94 b8 00 69 94 9d f0 69 94 00 00 00 9d |x.i...i...i.....|
00000150 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d c1 c3 |..<.............|
00000160 74 00 69 94 b4 00 69 94 9d e8 69 94 00 00 00 9d |t.i...i...i.....|
00000170 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 1c 10 |..<.............|
00000180 50 00 69 94 90 00 69 94 9d a0 69 94 00 00 00 9d |P.i...i...i.....|
00000190 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 2c db |..<...........,.|
000001a0 5c 00 69 94 9c 00 69 94 9d b8 69 94 00 00 00 9d |\.i...i...i.....|
000001b0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d f1 08 |..<.............|
000001c0 48 00 69 94 88 00 69 94 9d 90 69 94 00 00 00 9d |H.i...i...i.....|
000001d0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d 03 d7 |..<.............|
000001e0 44 00 69 94 84 00 69 94 9d 88 69 94 00 00 00 9d |D.i...i...i.....|
000001f0 00 00 3c 00 00 00 00 00 00 00 00 00 00 9d de 04 |..<.............|
00000200
**** /dev/sdm1 ****
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
btw, /dev/md1 is fine 100%
the drives for /dev/md0 --> 'a', 'c', 'd', 'h', 'i', 'j'
--
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