* Best tool to partition Drives with new sector geometry - (WAS: Need Help with crashed RAID5 (that was rebuilding and then had SATA error on another drive))
From: Benjammin2068 @ 2016-09-18 17:13 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <57C41A47.5050506@youngman.org.uk>
In a followup question to my arrays, I have a question about the new WDs with the larger sector size geometry but support 512B sectors.
I bought some WD Reds (WD10EFRX) drives.
When I let the linux "Disk Utility" (palimpest <- who the heck named that anyway?) do the RAID management with a new drive, it partitions on cyls and not sectors.
So it makes a partition and then complains to me it's off by 512bytes which could affect performance.
Gee. Thanks.
So I can use g/parted -- or fdisk....
but I thought I'd get any suggestions for the preferred tool and any pitfalls to watch out for.
Thanks,
-Ben
^ permalink raw reply
* Re: Question about commit f9a67b1182e5 ("md/bitmap: clear bitmap if bitmap_create failed").
From: Guoqing Jiang @ 2016-09-18 9:19 UTC (permalink / raw)
To: Marion & Christophe JAILLET, Shaohua Li; +Cc: linux-raid, linux-kernel
In-Reply-To: <5e0b941c-1536-3242-eb26-a500e5bb4ff6@wanadoo.fr>
On 09/14/2016 04:39 PM, Marion & Christophe JAILLET wrote:
>
> I don't share your feeling.
> bitmap_create() can return ERR_PTR(-ENOMEM) or ERR_PTR(-EINVAL).
>
> In such cases 'if (!bitmap)' will not be helpful.
>
> Maybe it should be turned into 'if (IS_ERR_OR_NULL(bitmap))' to handle
> errors returned by bitmap_create.
> Maybe just removing the call to 'bitmap_free(bitmap)' is enough.
>
I agreed we can remove it, if so, seems we are not consistent with the
previous comment of bitmap_create.
/*
* initialize the bitmap structure
* if this returns an error, bitmap_destroy must be called to do clean up
*/
What about revert it and re-use v1 patch? see
http://www.spinics.net/lists/raid/msg51819.html.
Thanks,
Guoqing
^ permalink raw reply
* Re: lots of "md: export_rdev(sde)" printed after create IMSM RAID10 with missing
From: Yi Zhang @ 2016-09-18 2:53 UTC (permalink / raw)
To: Jes Sorensen, Artur Paszkiewicz; +Cc: Shaohua Li, linux-raid
In-Reply-To: <wrfjtwdgqb49.fsf@redhat.com>
Hello Artur
I have test the patch you provided and that works, thanks.
Best Regards,
Yi Zhang
----- Original Message -----
From: "Jes Sorensen" <Jes.Sorensen@redhat.com>
To: "Artur Paszkiewicz" <artur.paszkiewicz@intel.com>
Cc: "Shaohua Li" <shli@kernel.org>, "Yi Zhang" <yizhan@redhat.com>, linux-raid@vger.kernel.org
Sent: Friday, September 16, 2016 8:31:50 PM
Subject: Re: lots of "md: export_rdev(sde)" printed after create IMSM RAID10 with missing
Artur Paszkiewicz <artur.paszkiewicz@intel.com> writes:
> On 09/14/2016 11:05 PM, Jes Sorensen wrote:
>> Artur,
>>
>> You were too fast :) Did you intend to post a patch with a commit
>> message?
>>
>> Cheers,
>> Jes
>>
>
> Hi Jes,
>
> I wanted to wait for feedback from Yi first. I just sent a proper patch
> with a commit message.
Thats great, much appreciated!
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] mdadm: replace hard coded string length
From: Jes Sorensen @ 2016-09-17 21:06 UTC (permalink / raw)
To: Song Liu; +Cc: linux-raid
In-Reply-To: <1474041111-4029795-1-git-send-email-songliubraving@fb.com>
Song Liu <songliubraving@fb.com> writes:
> This patch replaces hard coded 32 with sizeof(sb->set_name) in a
> couple places.
>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
> super1.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/super1.c b/super1.c
> index 9f62d23..729596f 100644
> --- a/super1.c
> +++ b/super1.c
> @@ -1030,7 +1030,7 @@ static void getinfo_super1(struct supertype *st, struct mdinfo *info, char *map)
>
> memcpy(info->uuid, sb->set_uuid, 16);
>
> - strncpy(info->name, sb->set_name, 32);
> + strncpy(info->name, sb->set_name, sizeof(info->name) - 1);
> info->name[32] = 0;
>
> if ((__le32_to_cpu(sb->feature_map)&MD_FEATURE_REPLACEMENT)) {
> @@ -1124,7 +1124,7 @@ static int update_super1(struct supertype *st, struct mdinfo *info,
> if (c)
> strncpy(info->name, c+1, 31 - (c-sb->set_name));
> else
> - strncpy(info->name, sb->set_name, 32);
> + strncpy(info->name, sb->set_name, sizeof(info->name) - 1);
> info->name[32] = 0;
> }
I had to check why this was OK, and technically it is, but I think you
should change the 'info->name[32] = 0' lines as well, to say
'info->name[sizeof(info->name) -1] = '\0'' too.
Sorry for the nitpicking, but I think it's better to be consistent
here.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH -next] dm cache policy smq: remove duplicated include from dm-cache-policy-smq.c
From: Mike Snitzer @ 2016-09-17 14:37 UTC (permalink / raw)
To: Wei Yongjun
Cc: Alasdair Kergon, Shaohua Li, Wei Yongjun, dm-devel, linux-raid
In-Reply-To: <1474087703-22600-1-git-send-email-weiyj.lk@gmail.com>
On Sat, Sep 17 2016 at 12:48P -0400,
Wei Yongjun <weiyj.lk@gmail.com> wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Remove duplicated include.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/md/dm-cache-policy-smq.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/md/dm-cache-policy-smq.c b/drivers/md/dm-cache-policy-smq.c
> index 8de5bd9..c33f4a6 100644
> --- a/drivers/md/dm-cache-policy-smq.c
> +++ b/drivers/md/dm-cache-policy-smq.c
> @@ -14,7 +14,6 @@
> #include <linux/mutex.h>
> #include <linux/vmalloc.h>
> #include <linux/math64.h>
> -#include <linux/hash.h>
>
> #define DM_MSG_PREFIX "cache-policy-smq"
I resolved this by fixing the original commit (where I added hash.h
without realizing it was already included).
But thanks for the report.
^ permalink raw reply
* [PATCH -next] dm cache policy smq: remove duplicated include from dm-cache-policy-smq.c
From: Wei Yongjun @ 2016-09-17 4:48 UTC (permalink / raw)
To: Alasdair Kergon, Mike Snitzer, Shaohua Li
Cc: Wei Yongjun, dm-devel, linux-raid
From: Wei Yongjun <weiyongjun1@huawei.com>
Remove duplicated include.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/md/dm-cache-policy-smq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/md/dm-cache-policy-smq.c b/drivers/md/dm-cache-policy-smq.c
index 8de5bd9..c33f4a6 100644
--- a/drivers/md/dm-cache-policy-smq.c
+++ b/drivers/md/dm-cache-policy-smq.c
@@ -14,7 +14,6 @@
#include <linux/mutex.h>
#include <linux/vmalloc.h>
#include <linux/math64.h>
-#include <linux/hash.h>
#define DM_MSG_PREFIX "cache-policy-smq"
^ permalink raw reply related
* [PATCH v2] mdadm: replace hard coded string length
From: Song Liu @ 2016-09-16 15:51 UTC (permalink / raw)
To: linux-raid; +Cc: Jes.Sorensen, Song Liu
This patch replaces hard coded 32 with sizeof(sb->set_name) in a
couple places.
Signed-off-by: Song Liu <songliubraving@fb.com>
---
super1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/super1.c b/super1.c
index 9f62d23..729596f 100644
--- a/super1.c
+++ b/super1.c
@@ -1030,7 +1030,7 @@ static void getinfo_super1(struct supertype *st, struct mdinfo *info, char *map)
memcpy(info->uuid, sb->set_uuid, 16);
- strncpy(info->name, sb->set_name, 32);
+ strncpy(info->name, sb->set_name, sizeof(info->name) - 1);
info->name[32] = 0;
if ((__le32_to_cpu(sb->feature_map)&MD_FEATURE_REPLACEMENT)) {
@@ -1124,7 +1124,7 @@ static int update_super1(struct supertype *st, struct mdinfo *info,
if (c)
strncpy(info->name, c+1, 31 - (c-sb->set_name));
else
- strncpy(info->name, sb->set_name, 32);
+ strncpy(info->name, sb->set_name, sizeof(info->name) - 1);
info->name[32] = 0;
}
--
2.8.0.rc2
^ permalink raw reply related
* Re: [PATCH] imsm: remove redundant characters from some error messages
From: Jes Sorensen @ 2016-09-16 13:51 UTC (permalink / raw)
To: Artur Paszkiewicz; +Cc: linux-raid
In-Reply-To: <20160916132514.29226-1-artur.paszkiewicz@intel.com>
Artur Paszkiewicz <artur.paszkiewicz@intel.com> writes:
> Fix the cases that produced messages like "mdadm: : The message".
>
> Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> ---
> super-intel.c | 26 +++++++++++++-------------
> 1 file changed, 13 insertions(+), 13 deletions(-)
Applied!
Thanks,
Jes
^ permalink raw reply
* [PATCH] imsm: remove redundant characters from some error messages
From: Artur Paszkiewicz @ 2016-09-16 13:25 UTC (permalink / raw)
To: jes.sorensen; +Cc: linux-raid, Artur Paszkiewicz
Fix the cases that produced messages like "mdadm: : The message".
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
---
super-intel.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/super-intel.c b/super-intel.c
index 92817e9..c96c6bc 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -5678,7 +5678,7 @@ active_arrays_by_format(char *name, char* hba, struct md_list **devlist,
if (num > 0)
fd = open(path, O_RDONLY, 0);
if ((num <= 0) || (fd < 0)) {
- pr_vrb(": Cannot open %s: %s\n",
+ pr_vrb("Cannot open %s: %s\n",
dev->name, strerror(errno));
}
free(path);
@@ -5808,7 +5808,7 @@ count_volumes_list(struct md_list *devlist, char *homehost,
*found = 0;
st = match_metadata_desc_imsm("imsm");
if (st == NULL) {
- pr_vrb(": cannot allocate memory for imsm supertype\n");
+ pr_vrb("cannot allocate memory for imsm supertype\n");
return 0;
}
@@ -5821,7 +5821,7 @@ count_volumes_list(struct md_list *devlist, char *homehost,
continue;
tst = dup_super(st);
if (tst == NULL) {
- pr_vrb(": cannot allocate memory for imsm supertype\n");
+ pr_vrb("cannot allocate memory for imsm supertype\n");
goto err_1;
}
tmpdev->container = 0;
@@ -6047,14 +6047,14 @@ validate_geometry_imsm_orom(struct intel_super *super, int level, int layout,
{
/* check/set platform and metadata limits/defaults */
if (super->orom && raiddisks > super->orom->dpa) {
- pr_vrb(": platform supports a maximum of %d disks per array\n",
+ pr_vrb("platform supports a maximum of %d disks per array\n",
super->orom->dpa);
return 0;
}
/* capabilities of OROM tested - copied from validate_geometry_imsm_volume */
if (!is_raid_level_supported(super->orom, level, raiddisks)) {
- pr_vrb(": platform does not support raid%d with %d disk%s\n",
+ pr_vrb("platform does not support raid%d with %d disk%s\n",
level, raiddisks, raiddisks > 1 ? "s" : "");
return 0;
}
@@ -6063,24 +6063,24 @@ validate_geometry_imsm_orom(struct intel_super *super, int level, int layout,
*chunk = imsm_default_chunk(super->orom);
if (super->orom && !imsm_orom_has_chunk(super->orom, *chunk)) {
- pr_vrb(": platform does not support a chunk size of: %d\n", *chunk);
+ pr_vrb("platform does not support a chunk size of: %d\n", *chunk);
return 0;
}
if (layout != imsm_level_to_layout(level)) {
if (level == 5)
- pr_vrb(": imsm raid 5 only supports the left-asymmetric layout\n");
+ pr_vrb("imsm raid 5 only supports the left-asymmetric layout\n");
else if (level == 10)
- pr_vrb(": imsm raid 10 only supports the n2 layout\n");
+ pr_vrb("imsm raid 10 only supports the n2 layout\n");
else
- pr_vrb(": imsm unknown layout %#x for this raid level %d\n",
+ pr_vrb("imsm unknown layout %#x for this raid level %d\n",
layout, level);
return 0;
}
if (super->orom && (super->orom->attr & IMSM_OROM_ATTR_2TB) == 0 &&
(calc_array_size(level, raiddisks, layout, *chunk, size) >> 32) > 0) {
- pr_vrb(": platform does not support a volume size over 2TB\n");
+ pr_vrb("platform does not support a volume size over 2TB\n");
return 0;
}
@@ -6251,7 +6251,7 @@ static int validate_geometry_imsm_volume(struct supertype *st, int level,
int count = count_volumes(super->hba,
super->orom->dpa, verbose);
if (super->orom->vphba <= count) {
- pr_vrb(": platform does not support more than %d raid volumes.\n",
+ pr_vrb("platform does not support more than %d raid volumes.\n",
super->orom->vphba);
return 0;
}
@@ -6407,7 +6407,7 @@ static int validate_geometry_imsm(struct supertype *st, int level, int layout,
count = count_volumes(super->hba,
super->orom->dpa, verbose);
if (super->orom->vphba <= count) {
- pr_vrb(": platform does not support more than %d raid volumes.\n",
+ pr_vrb("platform does not support more than %d raid volumes.\n",
super->orom->vphba);
return 0;
}
@@ -10582,7 +10582,7 @@ static int imsm_manage_reshape(
}
/* Only one volume can migrate at the same time */
if (migr_vol_qan != 1) {
- pr_err(": %s", migr_vol_qan ?
+ pr_err("%s", migr_vol_qan ?
"Number of migrating volumes greater than 1\n" :
"There is no volume during migrationg\n");
goto abort;
--
2.10.0
^ permalink raw reply related
* Re: [PATCH] mdadm: replace hard coded string length
From: Jes Sorensen @ 2016-09-16 12:38 UTC (permalink / raw)
To: Adam Goryachev; +Cc: Thomas Fjellstrom, linux-raid
In-Reply-To: <4115566d-9994-b90a-12cb-83e54c01baba@websitemanagers.com.au>
Adam Goryachev <mailinglists@websitemanagers.com.au> writes:
> On 16/09/16 04:10, Thomas Fjellstrom wrote:
>> On Thursday, September 15, 2016 12:15:30 PM MDT Jes Sorensen wrote:
>>> I was about to apply this, but this is actually wrong. You need to use
>>> the size of the destination, not of the source as the limit.
>>>
>>> Sorry for the hassle.
>> I'm not aware of the full details, but either they are the same size, or they
>> aren't, and you need to use the minimum size of both to avoid any kind of
>> overflow (source or dest, read and write). I presume the destination is
>> smaller?
> I'm not a programmer, but I think the size of the source is
> irrelevant. If the source is 10 bytes, you can safely copy that to a
> destination of 30 bytes. The only problem is if the source content is
> bigger than the destination. Hence, you should copy only based on the
> destination size.
>
> I'm not sure, but it may be a good idea to confirm that all of the
> source content has been copied, or else there may be unexpected
> results when operating on a truncated value. I'm sure someone else
> who is an actual programmer can jump in and advise...
Technically you are correct. However if we start adding such checks,
there's a full time job running through the code fixing up cases like
these. This for cases where we know it won't go wrong. It would also be
a large amount of patch churn for no gain.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH] mdadm: replace hard coded string length
From: Jes Sorensen @ 2016-09-16 12:34 UTC (permalink / raw)
To: Thomas Fjellstrom; +Cc: linux-raid
In-Reply-To: <5328253.xG1N6xNRzL@natasha>
Thomas Fjellstrom <thomas@fjellstrom.ca> writes:
> On Thursday, September 15, 2016 12:15:30 PM MDT Jes Sorensen wrote:
>> Song Liu <songliubraving@fb.com> writes:
>> > @@ -1124,7 +1124,7 @@ static int update_super1(struct supertype *st,
>> > struct mdinfo *info,>
>> > if (c)
>> >
>> > strncpy(info->name, c+1, 31 - (c-sb->set_name));
>> >
>> > else
>> >
>> > - strncpy(info->name, sb->set_name, 32);
>> > + strncpy(info->name, sb->set_name, sizeof(sb->set_name));
>> >
>> > info->name[32] = 0;
>> >
>> > }
>>
>> I was about to apply this, but this is actually wrong. You need to use
>> the size of the destination, not of the source as the limit.
>>
>> Sorry for the hassle.
>
> I'm not aware of the full details, but either they are the same size, or they
> aren't, and you need to use the minimum size of both to avoid any kind of
> overflow (source or dest, read and write). I presume the destination is
> smaller?
When copying a null terminated string, you need to check against the
size of the destination, not the source. It may happen to be they are
the same size here, but if code is later moved around you could get into
a situation where that is no longer the case. Checking against the size
of the destination is the correct way.
Second, when you reply to a mailing list posting, kindly refrain from
removing the person you respond to from the CC list.
Jes
^ permalink raw reply
* Re: lots of "md: export_rdev(sde)" printed after create IMSM RAID10 with missing
From: Jes Sorensen @ 2016-09-16 12:31 UTC (permalink / raw)
To: Artur Paszkiewicz; +Cc: Shaohua Li, Yi Zhang, linux-raid
In-Reply-To: <d4b81424-a77f-5ee9-446c-119657a3fb26@intel.com>
Artur Paszkiewicz <artur.paszkiewicz@intel.com> writes:
> On 09/14/2016 11:05 PM, Jes Sorensen wrote:
>> Artur,
>>
>> You were too fast :) Did you intend to post a patch with a commit
>> message?
>>
>> Cheers,
>> Jes
>>
>
> Hi Jes,
>
> I wanted to wait for feedback from Yi first. I just sent a proper patch
> with a commit message.
Thats great, much appreciated!
Jes
^ permalink raw reply
* Re: [PATCH] mdadm: replace hard coded string length
From: Adam Goryachev @ 2016-09-15 23:34 UTC (permalink / raw)
To: Thomas Fjellstrom; +Cc: linux-raid
In-Reply-To: <5328253.xG1N6xNRzL@natasha>
On 16/09/16 04:10, Thomas Fjellstrom wrote:
> On Thursday, September 15, 2016 12:15:30 PM MDT Jes Sorensen wrote:
>> Song Liu <songliubraving@fb.com> writes:
>>> This patch replaces hard coded 32 with sizeof(sb->set_name) in a
>>> couple places.
>>>
>>> Signed-off-by: Song Liu <songliubraving@fb.com>
>>> ---
>>>
>>> super1.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/super1.c b/super1.c
>>> index 9f62d23..7d03b1f 100644
>>> --- a/super1.c
>>> +++ b/super1.c
>>> @@ -1030,7 +1030,7 @@ static void getinfo_super1(struct supertype *st,
>>> struct mdinfo *info, char *map)>
>>> memcpy(info->uuid, sb->set_uuid, 16);
>>>
>>> - strncpy(info->name, sb->set_name, 32);
>>> + strncpy(info->name, sb->set_name, sizeof(sb->set_name));
>>>
>>> info->name[32] = 0;
>>>
>>> if ((__le32_to_cpu(sb->feature_map)&MD_FEATURE_REPLACEMENT)) {
>>>
>>> @@ -1124,7 +1124,7 @@ static int update_super1(struct supertype *st,
>>> struct mdinfo *info,>
>>> if (c)
>>>
>>> strncpy(info->name, c+1, 31 - (c-sb->set_name));
>>>
>>> else
>>>
>>> - strncpy(info->name, sb->set_name, 32);
>>> + strncpy(info->name, sb->set_name, sizeof(sb->set_name));
>>>
>>> info->name[32] = 0;
>>>
>>> }
>> I was about to apply this, but this is actually wrong. You need to use
>> the size of the destination, not of the source as the limit.
>>
>> Sorry for the hassle.
> I'm not aware of the full details, but either they are the same size, or they
> aren't, and you need to use the minimum size of both to avoid any kind of
> overflow (source or dest, read and write). I presume the destination is
> smaller?
I'm not a programmer, but I think the size of the source is irrelevant.
If the source is 10 bytes, you can safely copy that to a destination of
30 bytes. The only problem is if the source content is bigger than the
destination. Hence, you should copy only based on the destination size.
I'm not sure, but it may be a good idea to confirm that all of the
source content has been copied, or else there may be unexpected results
when operating on a truncated value.
I'm sure someone else who is an actual programmer can jump in and advise...
Regards,
Adam
--
Adam Goryachev Website Managers www.websitemanagers.com.au
^ permalink raw reply
* Re: [PATCH] mdadm: replace hard coded string length
From: Thomas Fjellstrom @ 2016-09-15 18:10 UTC (permalink / raw)
Cc: linux-raid
In-Reply-To: <wrfjr38lxhp9.fsf@redhat.com>
On Thursday, September 15, 2016 12:15:30 PM MDT Jes Sorensen wrote:
> Song Liu <songliubraving@fb.com> writes:
> > This patch replaces hard coded 32 with sizeof(sb->set_name) in a
> > couple places.
> >
> > Signed-off-by: Song Liu <songliubraving@fb.com>
> > ---
> >
> > super1.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/super1.c b/super1.c
> > index 9f62d23..7d03b1f 100644
> > --- a/super1.c
> > +++ b/super1.c
> > @@ -1030,7 +1030,7 @@ static void getinfo_super1(struct supertype *st,
> > struct mdinfo *info, char *map)>
> > memcpy(info->uuid, sb->set_uuid, 16);
> >
> > - strncpy(info->name, sb->set_name, 32);
> > + strncpy(info->name, sb->set_name, sizeof(sb->set_name));
> >
> > info->name[32] = 0;
> >
> > if ((__le32_to_cpu(sb->feature_map)&MD_FEATURE_REPLACEMENT)) {
> >
> > @@ -1124,7 +1124,7 @@ static int update_super1(struct supertype *st,
> > struct mdinfo *info,>
> > if (c)
> >
> > strncpy(info->name, c+1, 31 - (c-sb->set_name));
> >
> > else
> >
> > - strncpy(info->name, sb->set_name, 32);
> > + strncpy(info->name, sb->set_name, sizeof(sb->set_name));
> >
> > info->name[32] = 0;
> >
> > }
>
> I was about to apply this, but this is actually wrong. You need to use
> the size of the destination, not of the source as the limit.
>
> Sorry for the hassle.
I'm not aware of the full details, but either they are the same size, or they
aren't, and you need to use the minimum size of both to avoid any kind of
overflow (source or dest, read and write). I presume the destination is
smaller?
> Jes
> --
> 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
--
Thomas Fjellstrom
thomas@fjellstrom.ca
^ permalink raw reply
* Re: [PATCH] imsm: do not activate spares for uninitialized member arrays
From: Jes Sorensen @ 2016-09-15 16:16 UTC (permalink / raw)
To: Artur Paszkiewicz; +Cc: linux-raid
In-Reply-To: <20160915075358.16948-1-artur.paszkiewicz@intel.com>
Artur Paszkiewicz <artur.paszkiewicz@intel.com> writes:
> This fixes some issues when a member array is created with "missing"
> devices in a container that has more devices than used in the member
> array.
>
> Reported-by: Yi Zhang <yizhan@redhat.com>
> Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> ---
> super-intel.c | 5 +++++
> 1 file changed, 5 insertions(+)
Applied!
Thanks,
Jes
> diff --git a/super-intel.c b/super-intel.c
> index 92817e9..032ef00 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -7789,6 +7789,11 @@ static struct mdinfo *imsm_activate_spare(struct active_array *a,
> IMSM_T_STATE_DEGRADED)
> return NULL;
>
> + if (get_imsm_map(dev, MAP_0)->map_state == IMSM_T_STATE_UNINITIALIZED) {
> + dprintf("imsm: No spare activation allowed. Volume is not initialized.\n");
> + return NULL;
> + }
> +
> /*
> * If there are any failed disks check state of the other volume.
> * Block rebuild if the another one is failed until failed disks
^ permalink raw reply
* Re: [PATCH] mdadm: replace hard coded string length
From: Jes Sorensen @ 2016-09-15 16:15 UTC (permalink / raw)
To: Song Liu; +Cc: linux-raid
In-Reply-To: <1473898407-3049094-1-git-send-email-songliubraving@fb.com>
Song Liu <songliubraving@fb.com> writes:
> This patch replaces hard coded 32 with sizeof(sb->set_name) in a
> couple places.
>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
> super1.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/super1.c b/super1.c
> index 9f62d23..7d03b1f 100644
> --- a/super1.c
> +++ b/super1.c
> @@ -1030,7 +1030,7 @@ static void getinfo_super1(struct supertype *st, struct mdinfo *info, char *map)
>
> memcpy(info->uuid, sb->set_uuid, 16);
>
> - strncpy(info->name, sb->set_name, 32);
> + strncpy(info->name, sb->set_name, sizeof(sb->set_name));
> info->name[32] = 0;
>
> if ((__le32_to_cpu(sb->feature_map)&MD_FEATURE_REPLACEMENT)) {
> @@ -1124,7 +1124,7 @@ static int update_super1(struct supertype *st, struct mdinfo *info,
> if (c)
> strncpy(info->name, c+1, 31 - (c-sb->set_name));
> else
> - strncpy(info->name, sb->set_name, 32);
> + strncpy(info->name, sb->set_name, sizeof(sb->set_name));
> info->name[32] = 0;
> }
I was about to apply this, but this is actually wrong. You need to use
the size of the destination, not of the source as the limit.
Sorry for the hassle.
Jes
^ permalink raw reply
* lening bieden 3%
From: Lloyds TSB Bank PLC @ 2016-09-15 9:25 UTC (permalink / raw)
Goede dag,
Dit is Lloyd's TSB Bank plc leningen aan te bieden.
Lloyds TSB biedt flexibele en betaalbare leningen voor welk doel u te helpen uw doelen te bereiken. we lening tegen lage rente van 3%. Hier zijn een aantal belangrijke kenmerken van de persoonlijke lening aangeboden door Lloyd's TSB. Hier zijn de Loan Factoren we werken met de toonaangevende Britse makelaars die toegang hebben tot de top kredietverstrekkers hebben en in staat zijn om de beste financiële oplossing tegen een betaalbare price.Please vinden als u geïnteresseerd bent vriendelijk contact met ons op via deze e-mail: lloyds26tsb@gmail.com
Na de reactie, zal u een aanvraag voor een lening te vullen ontvangen. Geen sociale zekerheid en geen credit check, 100% gegarandeerd.
Het zal ons een eer zijn als u ons toelaten om u van dienst zijn.
INFORMATIE NODIG
Jullie namen:
Adres: ...........
Telefoon: ...........
Benodigd ........
Duur: ...............
Bezetting: ...........
Maandelijks Inkomen Level: ........
Geslacht: ...............
Geboortedatum: ........
Staat: ..................
Land: ..........
Doel: .........
Ontmoeting uw financiële behoeften is onze trots.
Dr.John Mahama.
^ permalink raw reply
* Re: Inactive arrays
From: Brad Campbell @ 2016-09-15 9:21 UTC (permalink / raw)
To: Wols Lists, Daniel Sanabria, Chris Murphy; +Cc: Linux-RAID
In-Reply-To: <57D99A2A.8000006@youngman.org.uk>
On 15/09/16 02:42, Wols Lists wrote:
> The tl;dr version of the problem with Greens (and any other desktop
> drive for that matter), if you haven't read it up yet, is that when the
> kernel requests a read from a dodgy drive, it just sits there,
> *unresponsive*, until the read succeeds or the drive times out. And the
> drive will time out in its own good time.
Yep. I've had great results using Greens but the trick is either TLER or
adjusted timeout, *and* disable head parking & spindown.
I'm lucky in that all my Greens are old enough they still have TLER.
These are the oldest ones with power on hours taken from SMART:
/dev/sdq - WDC WD20EARS-60MVWB0 - 5 years 157 days
/dev/sdi - WDC WD20EARS-60MVWB0 - 5 years 157 days
/dev/sdl - WDC WD20EARS-60MVWB0 - 5 years 157 days
/dev/sdm - WDC WD20EARS-60MVWB0 - 5 years 157 days
/dev/sdp - WDC WD20EARS-60MVWB0 - 5 years 157 days
/dev/sdn - WDC WD20EARS-60MVWB0 - 5 years 157 days
/dev/sdg - WDC WD20EARS-60MVWB0 - 5 years 158 days
I have one that is only 3 years 242 days (replacement for an early
failure), and anything newer than that is a Red. I started with 10
Greens and 7 are still humming along nicely.
Like any commodity drive, get your timeouts right and keep them spinning.
Regards,
Brad.
^ permalink raw reply
* lening bieden 3%
From: Lloyds TSB Bank PLC @ 2016-09-15 9:03 UTC (permalink / raw)
Goede dag,
Dit is Lloyd's TSB Bank plc leningen aan te bieden.
Lloyds TSB biedt flexibele en betaalbare leningen voor welk doel u te helpen uw doelen te bereiken. we lening tegen lage rente van 3%. Hier zijn een aantal belangrijke kenmerken van de persoonlijke lening aangeboden door Lloyd's TSB. Hier zijn de Loan Factoren we werken met de toonaangevende Britse makelaars die toegang hebben tot de top kredietverstrekkers hebben en in staat zijn om de beste financiële oplossing tegen een betaalbare price.Please vinden als u geïnteresseerd bent vriendelijk contact met ons op via deze e-mail: lloyds26tsb@gmail.com
Na de reactie, zal u een aanvraag voor een lening te vullen ontvangen. Geen sociale zekerheid en geen credit check, 100% gegarandeerd.
Het zal ons een eer zijn als u ons toelaten om u van dienst zijn.
INFORMATIE NODIG
Jullie namen:
Adres: ...........
Telefoon: ...........
Benodigd ........
Duur: ...............
Bezetting: ...........
Maandelijks Inkomen Level: ........
Geslacht: ...............
Geboortedatum: ........
Staat: ..................
Land: ..........
Doel: .........
Ontmoeting uw financiële behoeften is onze trots.
Dr.John Mahama.
^ permalink raw reply
* lening bieden 3%
From: Lloyds TSB Bank PLC @ 2016-09-15 8:59 UTC (permalink / raw)
Goede dag,
Dit is Lloyd's TSB Bank plc leningen aan te bieden.
Lloyds TSB biedt flexibele en betaalbare leningen voor welk doel u te helpen uw doelen te bereiken. we lening tegen lage rente van 3%. Hier zijn een aantal belangrijke kenmerken van de persoonlijke lening aangeboden door Lloyd's TSB. Hier zijn de Loan Factoren we werken met de toonaangevende Britse makelaars die toegang hebben tot de top kredietverstrekkers hebben en in staat zijn om de beste financiële oplossing tegen een betaalbare price.Please vinden als u geïnteresseerd bent vriendelijk contact met ons op via deze e-mail: lloyds26tsb@gmail.com
Na de reactie, zal u een aanvraag voor een lening te vullen ontvangen. Geen sociale zekerheid en geen credit check, 100% gegarandeerd.
Het zal ons een eer zijn als u ons toelaten om u van dienst zijn.
INFORMATIE NODIG
Jullie namen:
Adres: ...........
Telefoon: ...........
Benodigd ........
Duur: ...............
Bezetting: ...........
Maandelijks Inkomen Level: ........
Geslacht: ...............
Geboortedatum: ........
Staat: ..................
Land: ..........
Doel: .........
Ontmoeting uw financiële behoeften is onze trots.
Dr.John Mahama.
^ permalink raw reply
* Re: lots of "md: export_rdev(sde)" printed after create IMSM RAID10 with missing
From: Artur Paszkiewicz @ 2016-09-15 8:01 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Shaohua Li, Yi Zhang, linux-raid
In-Reply-To: <wrfjy42u2nvm.fsf@redhat.com>
On 09/14/2016 11:05 PM, Jes Sorensen wrote:
> Artur,
>
> You were too fast :) Did you intend to post a patch with a commit
> message?
>
> Cheers,
> Jes
>
Hi Jes,
I wanted to wait for feedback from Yi first. I just sent a proper patch
with a commit message.
Artur
^ permalink raw reply
* [PATCH] imsm: do not activate spares for uninitialized member arrays
From: Artur Paszkiewicz @ 2016-09-15 7:53 UTC (permalink / raw)
To: jes.sorensen; +Cc: linux-raid, Artur Paszkiewicz
This fixes some issues when a member array is created with "missing"
devices in a container that has more devices than used in the member
array.
Reported-by: Yi Zhang <yizhan@redhat.com>
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
---
super-intel.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/super-intel.c b/super-intel.c
index 92817e9..032ef00 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -7789,6 +7789,11 @@ static struct mdinfo *imsm_activate_spare(struct active_array *a,
IMSM_T_STATE_DEGRADED)
return NULL;
+ if (get_imsm_map(dev, MAP_0)->map_state == IMSM_T_STATE_UNINITIALIZED) {
+ dprintf("imsm: No spare activation allowed. Volume is not initialized.\n");
+ return NULL;
+ }
+
/*
* If there are any failed disks check state of the other volume.
* Block rebuild if the another one is failed until failed disks
--
2.10.0
^ permalink raw reply related
* Re: moving spares into group and checking spares
From: Chris Murphy @ 2016-09-15 3:51 UTC (permalink / raw)
To: scar; +Cc: Linux-RAID
In-Reply-To: <nrd5ak$e8c$1@blaine.gmane.org>
On Wed, Sep 14, 2016 at 9:42 PM, scar <scar@drigon.com> wrote:
> 00 80 00
> Sep 12 08:05:34 hind kernel: [1350051.023847] end_request: critical medium
> error, dev sdk, sector 598457896
> Sep 12 08:05:35 hind kernel: [1350051.385810] md/raid:md0: read error
> corrected (8 sectors at 598455848 on sdk1)
> Sep 12 08:05:35 hind kernel: [1350051.385826] md/raid:md0: read error
> corrected (8 sectors at 598455856 on sdk1)
> Sep 12 08:05:35 hind kernel: [1350051.385834] md/raid:md0: read error
> corrected (8 sectors at 598455864 on sdk1)
> Sep 12 08:05:35 hind kernel: [1350051.385840] md/raid:md0: read error
> corrected (8 sectors at 598455872 on sdk1)
> Sep 12 08:05:35 hind kernel: [1350051.385847] md/raid:md0: read error
> corrected (8 sectors at 598455880 on sdk1)
> Sep 12 08:05:35 hind kernel: [1350051.385853] md/raid:md0: read error
> corrected (8 sectors at 598455888 on sdk1)
> Sep 12 08:05:35 hind kernel: [1350051.385859] md/raid:md0: read error
> corrected (8 sectors at 598455896 on sdk1)
> Sep 12 08:05:35 hind kernel: [1350051.385865] md/raid:md0: read error
> corrected (8 sectors at 598455904 on sdk1)
> Sep 12 08:05:35 hind kernel: [1350051.385873] md/raid:md0: read error
> corrected (8 sectors at 598455912 on sdk1)
> Sep 12 08:05:35 hind kernel: [1350051.385880] md/raid:md0: read error
> corrected (8 sectors at 598455920 on sdk1)
> Sep 12 13:39:43 hind kernel: [1370087.022160] md: md0: data-check done.
>
>
> so it seems to be working? although the sector reported by libata is
> different than what md corrected
Looks like it replaced the entire chunk that includes the bad sector.
Is the chunk size 32KiB?
--
Chris Murphy
^ permalink raw reply
* Re: moving spares into group and checking spares
From: scar @ 2016-09-15 3:42 UTC (permalink / raw)
To: linux-raid-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAJCQCtQ1GHdQtShbW3U1o-fmXhT3fHrC7S9BxsxrrOG=0H_p3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Chris Murphy wrote on 09/14/2016 04:15 PM:
>it
> ought to work.
i had this happen the other day:
Sep 12 05:57:01 hind kernel: [1342342.663516] RAID conf printout:
Sep 12 05:57:01 hind kernel: [1342342.663528] --- level:5 rd:11 wd:11
Sep 12 05:57:01 hind kernel: [1342342.663535] disk 0, o:1, dev:sdb1
Sep 12 05:57:01 hind kernel: [1342342.663540] disk 1, o:1, dev:sdc1
Sep 12 05:57:01 hind kernel: [1342342.663544] disk 2, o:1, dev:sdd1
Sep 12 05:57:01 hind kernel: [1342342.663548] disk 3, o:1, dev:sde1
Sep 12 05:57:01 hind kernel: [1342342.663552] disk 4, o:1, dev:sdf1
Sep 12 05:57:01 hind kernel: [1342342.663556] disk 5, o:1, dev:sdg1
Sep 12 05:57:01 hind kernel: [1342342.663560] disk 6, o:1, dev:sdh1
Sep 12 05:57:01 hind kernel: [1342342.663564] disk 7, o:1, dev:sdi1
Sep 12 05:57:01 hind kernel: [1342342.663568] disk 8, o:1, dev:sdj1
Sep 12 05:57:01 hind kernel: [1342342.663572] disk 9, o:1, dev:sdk1
Sep 12 05:57:01 hind kernel: [1342342.663576] disk 10, o:1, dev:sdl1
Sep 12 05:57:01 hind kernel: [1342342.663735] md: data-check of RAID
array md0
Sep 12 05:57:01 hind kernel: [1342342.663751] md: minimum _guaranteed_
speed: 1000 KB/sec/disk.
Sep 12 05:57:01 hind kernel: [1342342.663757] md: using maximum
available idle IO bandwidth (but not more than 200000 KB/sec) for
data-check.
Sep 12 05:57:01 hind kernel: [1342342.663793] md: using 128k window,
over a total of 976629760k.
Sep 12 08:05:29 hind kernel: [1350045.526546] mptbase: ioc1:
LogInfo(0x31080000): Originator={PL}, Code={SATA NCQ Fail All Commands
After Error}, SubCode(0x0000) cb_idx mptscsih_io_done
Sep 12 08:05:29 hind kernel: [1350045.527460] sd 3:0:1:0: [sdk]
Unhandled sense code
Sep 12 08:05:29 hind kernel: [1350045.527478] sd 3:0:1:0: [sdk]
Sep 12 08:05:29 hind kernel: [1350045.527485] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
Sep 12 08:05:29 hind kernel: [1350045.527492] sd 3:0:1:0: [sdk]
Sep 12 08:05:29 hind kernel: [1350045.527499] Sense Key : Medium Error
[current]
Sep 12 08:05:29 hind kernel: [1350045.527512] Info fld=0x23abbe32
Sep 12 08:05:29 hind kernel: [1350045.527518] sd 3:0:1:0: [sdk]
Sep 12 08:05:29 hind kernel: [1350045.527525] Add. Sense: Unrecovered
read error
Sep 12 08:05:29 hind kernel: [1350045.527532] sd 3:0:1:0: [sdk] CDB:
Sep 12 08:05:29 hind kernel: [1350045.527537] Read(10): 28 00 23 ab bc
c8 00 04 00 00
Sep 12 08:05:29 hind kernel: [1350045.527554] end_request: critical
medium error, dev sdk, sector 598457896
Sep 12 08:05:34 hind kernel: [1350051.022308] mptbase: ioc1:
LogInfo(0x31080000): Originator={PL}, Code={SATA NCQ Fail All Commands
After Error}, SubCode(0x0000) cb_idx mptscsih_io_done
Sep 12 08:05:34 hind kernel: [1350051.022524] mptbase: ioc1:
LogInfo(0x31080000): Originator={PL}, Code={SATA NCQ Fail All Commands
After Error}, SubCode(0x0000) cb_idx mptscsih_io_done
Sep 12 08:05:34 hind kernel: [1350051.022745] mptbase: ioc1:
LogInfo(0x31080000): Originator={PL}, Code={SATA NCQ Fail All Commands
After Error}, SubCode(0x0000) cb_idx mptscsih_io_done
Sep 12 08:05:34 hind kernel: [1350051.022969] mptbase: ioc1:
LogInfo(0x31080000): Originator={PL}, Code={SATA NCQ Fail All Commands
After Error}, SubCode(0x0000) cb_idx mptscsih_io_done
Sep 12 08:05:34 hind kernel: [1350051.023190] mptbase: ioc1:
LogInfo(0x31080000): Originator={PL}, Code={SATA NCQ Fail All Commands
After Error}, SubCode(0x0000) cb_idx mptscsih_io_done
Sep 12 08:05:34 hind kernel: [1350051.023743] sd 3:0:1:0: [sdk]
Unhandled sense code
Sep 12 08:05:34 hind kernel: [1350051.023772] sd 3:0:1:0: [sdk]
Sep 12 08:05:34 hind kernel: [1350051.023779] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
Sep 12 08:05:34 hind kernel: [1350051.023786] sd 3:0:1:0: [sdk]
Sep 12 08:05:34 hind kernel: [1350051.023792] Sense Key : Medium Error
[current]
Sep 12 08:05:34 hind kernel: [1350051.023806] Info fld=0x23abbe32
Sep 12 08:05:34 hind kernel: [1350051.023813] sd 3:0:1:0: [sdk]
Sep 12 08:05:34 hind kernel: [1350051.023819] Add. Sense: Unrecovered
read error
Sep 12 08:05:34 hind kernel: [1350051.023826] sd 3:0:1:0: [sdk] CDB:
Sep 12 08:05:34 hind kernel: [1350051.023830] Read(10): 28 00 23 ab be
28 00 00 80 00
Sep 12 08:05:34 hind kernel: [1350051.023847] end_request: critical
medium error, dev sdk, sector 598457896
Sep 12 08:05:35 hind kernel: [1350051.385810] md/raid:md0: read error
corrected (8 sectors at 598455848 on sdk1)
Sep 12 08:05:35 hind kernel: [1350051.385826] md/raid:md0: read error
corrected (8 sectors at 598455856 on sdk1)
Sep 12 08:05:35 hind kernel: [1350051.385834] md/raid:md0: read error
corrected (8 sectors at 598455864 on sdk1)
Sep 12 08:05:35 hind kernel: [1350051.385840] md/raid:md0: read error
corrected (8 sectors at 598455872 on sdk1)
Sep 12 08:05:35 hind kernel: [1350051.385847] md/raid:md0: read error
corrected (8 sectors at 598455880 on sdk1)
Sep 12 08:05:35 hind kernel: [1350051.385853] md/raid:md0: read error
corrected (8 sectors at 598455888 on sdk1)
Sep 12 08:05:35 hind kernel: [1350051.385859] md/raid:md0: read error
corrected (8 sectors at 598455896 on sdk1)
Sep 12 08:05:35 hind kernel: [1350051.385865] md/raid:md0: read error
corrected (8 sectors at 598455904 on sdk1)
Sep 12 08:05:35 hind kernel: [1350051.385873] md/raid:md0: read error
corrected (8 sectors at 598455912 on sdk1)
Sep 12 08:05:35 hind kernel: [1350051.385880] md/raid:md0: read error
corrected (8 sectors at 598455920 on sdk1)
Sep 12 13:39:43 hind kernel: [1370087.022160] md: md0: data-check done.
so it seems to be working? although the sector reported by libata is
different than what md corrected
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] mdadm: replace hard coded string length
From: Song Liu @ 2016-09-15 0:13 UTC (permalink / raw)
To: linux-raid; +Cc: Jes.Sorensen, Song Liu
This patch replaces hard coded 32 with sizeof(sb->set_name) in a
couple places.
Signed-off-by: Song Liu <songliubraving@fb.com>
---
super1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/super1.c b/super1.c
index 9f62d23..7d03b1f 100644
--- a/super1.c
+++ b/super1.c
@@ -1030,7 +1030,7 @@ static void getinfo_super1(struct supertype *st, struct mdinfo *info, char *map)
memcpy(info->uuid, sb->set_uuid, 16);
- strncpy(info->name, sb->set_name, 32);
+ strncpy(info->name, sb->set_name, sizeof(sb->set_name));
info->name[32] = 0;
if ((__le32_to_cpu(sb->feature_map)&MD_FEATURE_REPLACEMENT)) {
@@ -1124,7 +1124,7 @@ static int update_super1(struct supertype *st, struct mdinfo *info,
if (c)
strncpy(info->name, c+1, 31 - (c-sb->set_name));
else
- strncpy(info->name, sb->set_name, 32);
+ strncpy(info->name, sb->set_name, sizeof(sb->set_name));
info->name[32] = 0;
}
--
2.8.0.rc2
^ permalink raw reply related
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