* Re: Looking to pick PCIe x4/x8 4+ SATA expansion card recommendation.
From: Andreas Klauer @ 2016-03-28 19:35 UTC (permalink / raw)
To: Ram Ramesh; +Cc: Linux Raid
In-Reply-To: <56F97B91.4070302@gmail.com>
On Mon, Mar 28, 2016 at 01:44:33PM -0500, Ram Ramesh wrote:
> The recommendations typically go for PCIe x1-2port type cards
Well, an 8 port card (like HP H220 or similar) is a bit too
expensive if all you need is two more slots, and it's not
like mdadm is picky - anything goes, well, as long as it
meets minimum requirements (no I/O errors etc)...
If you're looking for something on an even larger scale,
maybe have a look at the Backblaze Storage Pod blog posts.
Although the hardware they use seems to be hard to get,
it might give you some ideas.
They actually use port multipliers, I actually wish they
were as widespread (and as cheap) as USB hubs, so we all
could simply put three or four disks to a single SATA port,
but alas...
Maybe next time.
Regards
Andreas Klauer
^ permalink raw reply
* Re: Looking to pick PCIe x4/x8 4+ SATA expansion card recommendation.
From: John Stoffel @ 2016-03-28 19:25 UTC (permalink / raw)
To: John Stoffel; +Cc: Ram Ramesh, Linux Raid
In-Reply-To: <22265.33776.226233.227426@quad.stoffel.home>
I just went back and checked, and I got the:
LSI 9211 SAS9211-8i 8port low profile 6Gb/s SAS Host Bus Adapter
which was a DELL brand controller. The 9207 is another model which is
also recommended, but this is from 2014 or even earlier. There might
be newer models out there.
I paid $123 plus shipping. Been very happy with it, not problems at
all.
^ permalink raw reply
* Re: Looking to pick PCIe x4/x8 4+ SATA expansion card recommendation.
From: John Stoffel @ 2016-03-28 19:20 UTC (permalink / raw)
To: Ram Ramesh; +Cc: Linux Raid
In-Reply-To: <56F97B91.4070302@gmail.com>
I'm using an LSI MPT2 PCIe controller myself and it's working great.
I paid around $150 on ebay a while ago for it, so the model you show
should be just fine.
I'd be careful about buying off Ebay unless you know EXACTLY what
you're getting.
And remember to buy the expander cables to go from the two ports on
the card, two two sets of four SATA controller cables.
^ permalink raw reply
* Looking to pick PCIe x4/x8 4+ SATA expansion card recommendation.
From: Ram Ramesh @ 2016-03-28 18:44 UTC (permalink / raw)
To: Linux Raid
Hi,
I have upgraded my PC with new MB and it is begging to be made in to
full blown mdam server. I asked and got several recommendation for SATA
expansion cards. The recommendations typically go for PCIe x1-2port type
cards like this one
> http://www.ebay.com/itm/PCI-E-Express-SATA3-SATA3-0-6Gb-s-eSATA-SATA-III-Card-ASMEDIA1061-/231378681315
However, I am looking for something along PCIe x4/x8 with 4+ ports like
this one
> http://www.amazon.com/SAS9211-8I-8PORT-Int-Sata-Pcie/dp/B002RL8I7M
or (similar, but cheaper)
> ww.ebay.com/itm/like/252048579357?lpid=82&chn=ps&ul_noapp=true
Any one has any experience? Are there some other recommended ones along
this line. Basically, I am looking for non raid (I do not want pay for
the HW RAID component which I will not use) easy to use expansion card
with several ports that is reliable (I have this:
www.newegg.com/Product/Product.aspx?Item=N82E16816124064 and it drops
hard drives the moment I stress it)
Ramesh
^ permalink raw reply
* Re: [BUG] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev
From: Jeff Moyer @ 2016-03-28 18:38 UTC (permalink / raw)
To: Shaohua Li
Cc: Sebastian Roesner, Ming Lei, Eric Wheeler, linux-bcache,
linux-raid, Ming Lin, Vlad-Cosmin Miu, rjones, Kent Overstreet,
axboe
In-Reply-To: <20160328181059.GA83819@kernel.org>
Shaohua Li <shli@kernel.org> writes:
> On Sat, Mar 26, 2016 at 05:46:16PM +0100, Sebastian Roesner wrote:
>> Hello Ming, Eric,
>>
>> Am 26.03.2016 um 16:40 schrieb Ming Lei:
>> > From the trace, looks the bio returned from bio_clone_mddev() is NULL,
>> >and maybe the source bio is buggy, something like the attached patch
>> >might be helpful, could you apply the attached debug patch, reproduce
>> >and post the log?
>>
>> I was able to reproduce it on a non-productive system, but only after
>> copying the bcache superblocks/partition starts from the original system,
>> with new created ones it worked fine.
>>
>> Full trace and check_bio output can be found here:
>>
>> http://pastebin.com/ngvGGHBZ
>
> 320 bvecs exceeds what bio-clone_set can handle. Could you please try
> below patch?
OK, so bvec_alloc won't allow us to allocate more than BIO_MAX_PAGES.
> commit 92761dad7ff6e1bf25de247e0064dd398e797599
> Author: Shaohua Li <shli@fb.com>
> Date: Mon Mar 28 10:54:35 2016 -0700
>
> block: don't make BLK_DEF_MAX_SECTORS too big
>
> bio_alloc_bioset() allocates bvecs from bvec_slabs which can only allocate
> maximum 256 bvec (eg, 1M for 4k pages). We can't bump BLK_DEF_MAX_SECTORS to
> exceed this value otherwise bio_alloc_bioset will fail.
>
> This fixes commit 30e2bc08b2bb7c069.
Wrong commit. You meant this one: d2be537c3ba (block: bump
BLK_DEF_MAX_SECTORS to 2560).
> We probably should make the bvec_slabs hold bigger bvecs if bigger
> bio size is required.
This change is okay with me. So long as it fixes the issue, it should
be marked for stable, too. Thanks for adding the comment, by the way!
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
> Signed-off-by: Shaohua Li <shli@fb.com>
>
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 7e5d7e0..da64325 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -1153,7 +1153,11 @@ extern int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm);
> enum blk_default_limits {
> BLK_MAX_SEGMENTS = 128,
> BLK_SAFE_MAX_SECTORS = 255,
> - BLK_DEF_MAX_SECTORS = 2560,
> + /*
> + * if you change this, please also change bvec_alloc and BIO_MAX_PAGES.
> + * Otherwise bio_alloc_bioset will break.
> + */
> + BLK_DEF_MAX_SECTORS = BIO_MAX_SECTORS,
> BLK_MAX_SEGMENT_SIZE = 65536,
> BLK_SEG_BOUNDARY_MASK = 0xFFFFFFFFUL,
> };
^ permalink raw reply
* Re: [PATCH] md/bitmap: call bitmap_destroy in case bitmap_create failed
From: Shaohua Li @ 2016-03-28 18:15 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: linux-raid, neilb
In-Reply-To: <56F8A49E.60705@suse.com>
On Mon, Mar 28, 2016 at 11:27:26AM +0800, Guoqing Jiang wrote:
>
>
> On 03/26/2016 06:02 AM, Shaohua Li wrote:
> >On Fri, Mar 25, 2016 at 07:00:14PM +0800, Guoqing Jiang wrote:
> >>If bitmap_create returns an error, bitmap_destroy must be
> >>called to do clean up.
> >>
> >>Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
> >>---
> >> drivers/md/bitmap.c | 14 ++++++++------
> >> 1 file changed, 8 insertions(+), 6 deletions(-)
> >>
> >>diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
> >>index 7df6b4f..ba908e7 100644
> >>--- a/drivers/md/bitmap.c
> >>+++ b/drivers/md/bitmap.c
> >>@@ -1865,8 +1865,10 @@ int bitmap_copy_from_slot(struct mddev *mddev, int slot,
> >> struct bitmap_counts *counts;
> >> struct bitmap *bitmap = bitmap_create(mddev, slot);
> >>- if (IS_ERR(bitmap))
> >>+ if (IS_ERR(bitmap)) {
> >>+ bitmap_destroy(mddev);
> >> return PTR_ERR(bitmap);
> >>+ }
> >bitmap_create doesn't set mddev->bitmap, so bitmap_destroy will do nothing.
> >is this because of reference leak of sysfs_can_clear?
>
> Yes, use bitmap_free should be ok here since mddev->bitmap is not set.
>
> >can we move sysfs_put(bitmap->sysfs_can_clear); to bitmap_free?
>
> Do you mean move sysfs_put from bitmap_destroy to bitmap_free?
> I guess it could be ok. Also we need make minor change to the comment.
right. Just free the reference of sysfs_can_clear and set it to NULL. I think
that will fix your issue.
> /*
> * initialize the bitmap structure
> * if this returns an error, bitmap_destroy must be called to do clean up
> + * once mddev->bitmap is set
> */
> struct bitmap *bitmap_create(struct mddev *mddev, int slot)
please also fix the comment.
Thanks,
Shaohua
^ permalink raw reply
* Re: [BUG] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev
From: Shaohua Li @ 2016-03-28 18:10 UTC (permalink / raw)
To: Sebastian Roesner
Cc: Ming Lei, Eric Wheeler, linux-bcache, linux-raid, Ming Lin,
Vlad-Cosmin Miu, rjones, Kent Overstreet, jmoyer, axboe
In-Reply-To: <56F6BCD8.70504@roesner-online.de>
On Sat, Mar 26, 2016 at 05:46:16PM +0100, Sebastian Roesner wrote:
> Hello Ming, Eric,
>
> Am 26.03.2016 um 16:40 schrieb Ming Lei:
> > From the trace, looks the bio returned from bio_clone_mddev() is NULL,
> >and maybe the source bio is buggy, something like the attached patch
> >might be helpful, could you apply the attached debug patch, reproduce
> >and post the log?
>
> I was able to reproduce it on a non-productive system, but only after
> copying the bcache superblocks/partition starts from the original system,
> with new created ones it worked fine.
>
> Full trace and check_bio output can be found here:
>
> http://pastebin.com/ngvGGHBZ
320 bvecs exceeds what bio-clone_set can handle. Could you please try below patch?
commit 92761dad7ff6e1bf25de247e0064dd398e797599
Author: Shaohua Li <shli@fb.com>
Date: Mon Mar 28 10:54:35 2016 -0700
block: don't make BLK_DEF_MAX_SECTORS too big
bio_alloc_bioset() allocates bvecs from bvec_slabs which can only allocate
maximum 256 bvec (eg, 1M for 4k pages). We can't bump BLK_DEF_MAX_SECTORS to
exceed this value otherwise bio_alloc_bioset will fail.
This fixes commit 30e2bc08b2bb7c069. We probably should make the bvec_slabs
hold bigger bvecs if bigger bio size is required.
Signed-off-by: Shaohua Li <shli@fb.com>
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 7e5d7e0..da64325 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1153,7 +1153,11 @@ extern int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm);
enum blk_default_limits {
BLK_MAX_SEGMENTS = 128,
BLK_SAFE_MAX_SECTORS = 255,
- BLK_DEF_MAX_SECTORS = 2560,
+ /*
+ * if you change this, please also change bvec_alloc and BIO_MAX_PAGES.
+ * Otherwise bio_alloc_bioset will break.
+ */
+ BLK_DEF_MAX_SECTORS = BIO_MAX_SECTORS,
BLK_MAX_SEGMENT_SIZE = 65536,
BLK_SEG_BOUNDARY_MASK = 0xFFFFFFFFUL,
};
^ permalink raw reply related
* Re: [PATCH RESEND v2 11/18] fs: Ensure the mounter of a filesystem is privileged towards its inodes
From: Seth Forshee @ 2016-03-28 16:59 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Alexander Viro, Serge Hallyn, Richard Weinberger,
Austin S Hemmelgarn, Miklos Szeredi, linux-kernel, linux-bcache,
dm-devel, linux-raid, linux-mtd, linux-fsdevel, fuse-devel,
linux-security-module, selinux
In-Reply-To: <87twkl50g5.fsf@x220.int.ebiederm.org>
On Fri, Mar 04, 2016 at 04:43:06PM -0600, Eric W. Biederman wrote:
> In general this is only an issue if uids and gids on the filesystem
> do not map into the user namespace.
>
> Therefore the general fix is to limit the logic of checking for
> capabilities in s_user_ns if we are dealing with INVALID_UID and
> INVALID_GID. For proc and kernfs that should never be the case
> so the problem becomes a non-issue.
>
> Further I would look at limiting that relaxation to just
> inode_change_ok.
Finally got around to implementing this today; is the patch below what
you had in mind?
> So that we can easily wrap that check per filesystem
> and deny the relaxation for proc and kernfs. proc and kernfs already
> have wrappers for .setattr so denying changes when !uid_vaid and
> !gid_valid would be a trivial addition, and ensure calamity does
> not ensure.
I'm confused about this part though. As you say above, proc and kernfs
will never have inodes with invalid ids, so it's not an issue. Do you
just mean this to be extra insurance against problems?
Thanks,
Seth
---
diff --git a/fs/attr.c b/fs/attr.c
index 3cfaaac4a18e..f2bcd3f7dfbb 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -16,6 +16,31 @@
#include <linux/evm.h>
#include <linux/ima.h>
+static bool chown_ok(const struct inode *inode, kuid_t uid)
+{
+ if (uid_eq(current_fsuid(), inode->i_uid) && uid_eq(uid, inode->i_uid))
+ return true;
+ if (capable_wrt_inode_uidgid(inode, CAP_CHOWN))
+ return true;
+ if (!uid_valid(inode->i_uid) &&
+ ns_capable(inode->i_sb->s_user_ns, CAP_CHOWN))
+ return true;
+ return false;
+}
+
+static bool chgrp_ok(const struct inode *inode, kgid_t gid)
+{
+ if (uid_eq(current_fsuid(), inode->i_uid) &&
+ (in_group_p(gid) || gid_eq(gid, inode->i_gid)))
+ return true;
+ if (capable_wrt_inode_uidgid(inode, CAP_CHOWN))
+ return true;
+ if (!gid_valid(inode->i_gid) &&
+ ns_capable(inode->i_sb->s_user_ns, CAP_CHOWN))
+ return true;
+ return false;
+}
+
/**
* inode_change_ok - check if attribute changes to an inode are allowed
* @inode: inode to check
@@ -58,17 +83,11 @@ int inode_change_ok(const struct inode *inode, struct iattr *attr)
return 0;
/* Make sure a caller can chown. */
- if ((ia_valid & ATTR_UID) &&
- (!uid_eq(current_fsuid(), inode->i_uid) ||
- !uid_eq(attr->ia_uid, inode->i_uid)) &&
- !capable_wrt_inode_uidgid(inode, CAP_CHOWN))
+ if ((ia_valid & ATTR_UID) && !chown_ok(inode, attr->ia_uid))
return -EPERM;
/* Make sure caller can chgrp. */
- if ((ia_valid & ATTR_GID) &&
- (!uid_eq(current_fsuid(), inode->i_uid) ||
- (!in_group_p(attr->ia_gid) && !gid_eq(attr->ia_gid, inode->i_gid))) &&
- !capable_wrt_inode_uidgid(inode, CAP_CHOWN))
+ if ((ia_valid & ATTR_GID) && !chgrp_ok(inode, attr->ia_gid))
return -EPERM;
/* Make sure a caller can chmod. */
^ permalink raw reply related
* Re: Probable bug in md with rdev->new_data_offset
From: Phil Turmel @ 2016-03-28 12:19 UTC (permalink / raw)
To: Étienne Buira, linux-raid
In-Reply-To: <20160328103123.GC8633@rcKGHUlyQfVFW>
On 03/28/2016 06:31 AM, Étienne Buira wrote:
> Hi all,
>
> Please apologise if i hit the wrong list.
This is the right list. :-)
> I searched a bit, but could not find bug report or commits that seemed
> related, please apologise if i'm wrong here.
>
> I was going to grow a raid6 array (that contained a spare), using this
> command:
> # mdadm --grow -n 7 /dev/mdx
>
> But when doing so, i got a PAX message saying that a size overflow was
> detected in super_1_sync on the decl new_offset. The array was then in
> unusable state (presumably because some locks were held).
>
> After printking the values for rdev->new_data_offset and
> rdev->data_offset in the
> if (rdev->new_data_offset != rdev->data_offset) { ...
> block of super_1_sync, i found that new_data_offset (252928 in my case)
> where smaller than data_offset (258048), thus, the substraction to
> compute sb->new_data_offset yielded an insanely high value.
Modern mdadm and kernels avoid the use of backup files by adjusting the
data offset. The lowered offset you see is normal.
I suspect the grsecurity kernels haven't kept up with this. If you can
reproduce a problem with a vanilla kernel, please report back here.
Otherwise you'll have to report to your kernel provider.
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
* Probable bug in md with rdev->new_data_offset
From: Étienne Buira @ 2016-03-28 10:31 UTC (permalink / raw)
To: linux-raid
Hi all,
Please apologise if i hit the wrong list.
I searched a bit, but could not find bug report or commits that seemed
related, please apologise if i'm wrong here.
I was going to grow a raid6 array (that contained a spare), using this
command:
# mdadm --grow -n 7 /dev/mdx
But when doing so, i got a PAX message saying that a size overflow was
detected in super_1_sync on the decl new_offset. The array was then in
unusable state (presumably because some locks were held).
After printking the values for rdev->new_data_offset and
rdev->data_offset in the
if (rdev->new_data_offset != rdev->data_offset) { ...
block of super_1_sync, i found that new_data_offset (252928 in my case)
where smaller than data_offset (258048), thus, the substraction to
compute sb->new_data_offset yielded an insanely high value.
For all partitions this array is made of, mdadm -E /dev/sdxy reports a
data offset of 258048 sectors (the value of rdev->data_offset).
IMHO, it seems a good idea to put a BUG_ON or similar if
rdev->new_data_offset is smaller than rdev->data offset at this place,
but that would not address the real issue.
I could solve my problem by setting mdadm's backup-file= option.
Kernel version was Gentoo hardened v4.4.2.
Full PAX size overflow detection line:
size overflow detected in function super_1_sync drivers/md/md.c:1683
cicus.1522_314 min, count: 158, decl: new_offset; num: 0; context:
mdp_superblock_1
Call stack (without addresses):
dump_stack
report_size_overflow
super_1_sync
? sched_clock_cpu
md_update_sb
? account_entity_dequeue
? dequeue_task_fair
? mutex_lock
? bitmap_daemon_work
md_check_recovery
raid5d
? try_to_del_timer_sync
? del_timer_sync
md_thread
? wait_woken
? find_pers
kthread
? kthread_create_on_node
ret_from_fork
? kthread_create_on_node
I am not familiar with kernel coding, so i won't create a patch, but i'm
willing to give more information if needed to track this issue.
Regards.
^ permalink raw reply
* Re: [PATCH] md/bitmap: call bitmap_destroy in case bitmap_create failed
From: Guoqing Jiang @ 2016-03-28 3:27 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-raid, neilb
In-Reply-To: <20160325220210.GA78806@kernel.org>
On 03/26/2016 06:02 AM, Shaohua Li wrote:
> On Fri, Mar 25, 2016 at 07:00:14PM +0800, Guoqing Jiang wrote:
>> If bitmap_create returns an error, bitmap_destroy must be
>> called to do clean up.
>>
>> Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
>> ---
>> drivers/md/bitmap.c | 14 ++++++++------
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
>> index 7df6b4f..ba908e7 100644
>> --- a/drivers/md/bitmap.c
>> +++ b/drivers/md/bitmap.c
>> @@ -1865,8 +1865,10 @@ int bitmap_copy_from_slot(struct mddev *mddev, int slot,
>> struct bitmap_counts *counts;
>> struct bitmap *bitmap = bitmap_create(mddev, slot);
>>
>> - if (IS_ERR(bitmap))
>> + if (IS_ERR(bitmap)) {
>> + bitmap_destroy(mddev);
>> return PTR_ERR(bitmap);
>> + }
> bitmap_create doesn't set mddev->bitmap, so bitmap_destroy will do nothing.
> is this because of reference leak of sysfs_can_clear?
Yes, use bitmap_free should be ok here since mddev->bitmap is not set.
> can we move sysfs_put(bitmap->sysfs_can_clear); to bitmap_free?
Do you mean move sysfs_put from bitmap_destroy to bitmap_free?
I guess it could be ok. Also we need make minor change to the comment.
/*
* initialize the bitmap structure
* if this returns an error, bitmap_destroy must be called to do clean up
+ * once mddev->bitmap is set
*/
struct bitmap *bitmap_create(struct mddev *mddev, int slot)
Thanks,
Guoqing
^ permalink raw reply
* Darlehen Angebot
From: info @ 2016-03-27 12:44 UTC (permalink / raw)
To: Recipients
Sie benötigen ein Darlehen niedrige Rate? Altanlage gibt aus Darlehen in günstigen Preis gilt jetzt: legacyassetgrougp@hotmail.com
--
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
* 我的照片在:
From: 我的照片在: @ 2016-03-26 19:28 UTC (permalink / raw)
To: linux-raid
你的老朋友邀你来Q群:343257759
^ permalink raw reply
* Re: [BUG] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev
From: Sebastian Roesner @ 2016-03-26 16:46 UTC (permalink / raw)
To: Ming Lei, Eric Wheeler
Cc: linux-bcache, linux-raid, Ming Lin, Vlad-Cosmin Miu, rjones,
Kent Overstreet
In-Reply-To: <CACVXFVO7ARehcQHvBuRoVHZhc0BgA5kKxaPQTqMT7Y=4Ca6urw@mail.gmail.com>
Hello Ming, Eric,
Am 26.03.2016 um 16:40 schrieb Ming Lei:
> From the trace, looks the bio returned from bio_clone_mddev() is NULL,
> and maybe the source bio is buggy, something like the attached patch
> might be helpful, could you apply the attached debug patch, reproduce
> and post the log?
I was able to reproduce it on a non-productive system, but only after
copying the bcache superblocks/partition starts from the original
system, with new created ones it worked fine.
Full trace and check_bio output can be found here:
http://pastebin.com/ngvGGHBZ
Sebastian
^ permalink raw reply
* Re: [BUG] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev
From: Ming Lei @ 2016-03-26 15:40 UTC (permalink / raw)
To: Eric Wheeler
Cc: Sebastian Roesner, linux-bcache, linux-raid, Ming Lin,
Vlad-Cosmin Miu, rjones, Kent Overstreet
In-Reply-To: <alpine.LRH.2.11.1603251954220.13440@mail.ewheeler.net>
[-- Attachment #1: Type: text/plain, Size: 3317 bytes --]
On Sat, Mar 26, 2016 at 4:44 AM, Eric Wheeler <bcache@lists.ewheeler.net> wrote:
> [ +cc's, intentional top post ]
>
> Hello linux-raid list, please see below:
>
> A problem where bio_trim() dereferences a NULL pointer via
> bio->bi_iter.bi_size (0+0x28) has been reported at least three times when
> passing DISCARDs into raid1's. I could be wrong here, but I'm guessing
> the cause of these three reports are the same:
>
> [2014-02-04] https://bugzilla.redhat.com/show_bug.cgi?id=1061339
> [2016-01-13] http://www.spinics.net/lists/linux-bcache/msg03335.html
> https://bugzilla.kernel.org/show_bug.cgi?id=110771
> [2016-03-25] http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3607 [this thread]
> https://bugzilla.kernel.org/show_bug.cgi?id=114871
>
> Is there something that needs to be done differently with DISCARD bio's,
> perhaps related to splitting? We added BUG_ON(!bio) in bcache's
> prio_io() function (see backtrace below) and didn't trip, so we know that
> bcache isn't passing null bio pointers.
>
> Perhaps there is an issue in either of blk_queue_split() or
> md_make_request() even before it gets to raid1_make_request()?
From the trace, looks the bio returned from bio_clone_mddev() is NULL,
and maybe the source bio is buggy, something like the attached patch
might be helpful, could you apply the attached debug patch, reproduce
and post the log?
thanks,
>
> Please add Cc's for anyone who might be able to help solve this problem.
>
> Thanks you for your help!
>
> --
> Eric Wheeler
>
> On Fri, 25 Mar 2016, Sebastian Roesner wrote:
>
>> Hi Eric,
>>
>> Am 25.03.2016 um 05:18 schrieb Eric Wheeler:
>> > Please send this output:
>> >
>> > tail /sys/block/md2/queue/discard_*
>>
>> # tail /sys/block/md2/queue/discard_*
>> ==> /sys/block/md2/queue/discard_granularity <==
>> 4096
>>
>> ==> /sys/block/md2/queue/discard_max_bytes <==
>> 2147450880
>>
>> ==> /sys/block/md2/queue/discard_max_hw_bytes <==
>> 2147450880
>>
>> ==> /sys/block/md2/queue/discard_zeroes_data <==
>> 0
>>
>> root@gropius:/home/sroesner# echo /dev/md2 > /sys/fs/bcache/register
>> sroesner@gropius:~$
>>
>> -> it killed my bash.
>>
>> Trace with patches and BUG_ON patch:
>>
>> [ 172.660142] BUG: unable to handle kernel NULL pointer dereference at
>> 0000000000000028
>> [ 172.660229] IP: [<ffffffff811e53b4>] bio_trim+0xf/0x2a
>> [ 172.660289] PGD 7faf3e067 PUD 7f9279067 PMD 0
>> [ 172.660399] Oops: 0000 [#1] SMP
>> [...]
>> [ 172.664780] Call Trace:
>> [ 172.664813] [<ffffffffa007f3be>] ? raid1_make_request+0x2e8/0xad7 [raid1]
>> [ 172.664846] [<ffffffff811f07da>] ? blk_queue_split+0x377/0x3d4
>> [ 172.664880] [<ffffffffa005fb5f>] ? md_make_request+0xf6/0x1e9 [md_mod]
>> [ 172.664912] [<ffffffff811eb860>] ? generic_make_request+0xb5/0x155
>> [ 172.664947] [<ffffffffa0445c89>] ? prio_io+0x85/0x95 [bcache]
>> [ 172.664981] [<ffffffffa0448252>] ? register_cache_set+0x355/0x8d0 [bcache]
>> [ 172.665016] [<ffffffffa04497d3>] ? register_bcache+0x1006/0x1174 [bcache]
>>
>> See http://pastebin.com/6CHtky2x for complete traces.
>>
>> Sebastian
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
[-- Attachment #2: raid1-check-bio.patch --]
[-- Type: text/x-patch, Size: 1400 bytes --]
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 39fb21e..956205d 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1044,6 +1044,27 @@ static void raid1_unplug(struct blk_plug_cb *cb, bool from_schedule)
kfree(plug);
}
+static void check_bio(struct bio *bio, bool check)
+{
+ struct bio_vec bvec;
+ struct bvec_iter iter = bio->bi_iter;
+ int i = 0;
+
+ if (!check)
+ return;
+
+ printk("%s: dump bio %p segs:%d f:%x max_bvecs:%d iov:%p\n",
+ __func__, bio, bio_segments(bio), bio->bi_flags,
+ bio->bi_max_vecs, bio->bi_io_vec);
+ printk("\t iter: %u %u %u\n", iter.bi_size, iter.bi_idx,
+ iter.bi_bvec_done);
+ bio_for_each_segment(bvec, bio, iter) {
+ printk("\t %4d: %u %u %lu\n",
+ i, bvec.bv_offset, bvec.bv_len,
+ (unsigned long)page_to_pfn(bvec.bv_page));
+ }
+}
+
static void raid1_make_request(struct mddev *mddev, struct bio * bio)
{
struct r1conf *conf = mddev->private;
@@ -1157,6 +1178,7 @@ read_again:
r1_bio->start_next_window = 0;
read_bio = bio_clone_mddev(bio, GFP_NOIO, mddev);
+ check_bio(bio, !read_bio);
bio_trim(read_bio, r1_bio->sector - bio->bi_iter.bi_sector,
max_sectors);
@@ -1338,6 +1360,7 @@ read_again:
continue;
mbio = bio_clone_mddev(bio, GFP_NOIO, mddev);
+ check_bio(bio, !mbio);
bio_trim(mbio, r1_bio->sector - bio->bi_iter.bi_sector, max_sectors);
if (first_clone) {
^ permalink raw reply related
* Re: [PATCH] md/bitmap: call bitmap_destroy in case bitmap_create failed
From: Shaohua Li @ 2016-03-25 22:02 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: linux-raid, neilb
In-Reply-To: <1458903614-21498-1-git-send-email-gqjiang@suse.com>
On Fri, Mar 25, 2016 at 07:00:14PM +0800, Guoqing Jiang wrote:
> If bitmap_create returns an error, bitmap_destroy must be
> called to do clean up.
>
> Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
> ---
> drivers/md/bitmap.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
> index 7df6b4f..ba908e7 100644
> --- a/drivers/md/bitmap.c
> +++ b/drivers/md/bitmap.c
> @@ -1865,8 +1865,10 @@ int bitmap_copy_from_slot(struct mddev *mddev, int slot,
> struct bitmap_counts *counts;
> struct bitmap *bitmap = bitmap_create(mddev, slot);
>
> - if (IS_ERR(bitmap))
> + if (IS_ERR(bitmap)) {
> + bitmap_destroy(mddev);
> return PTR_ERR(bitmap);
> + }
bitmap_create doesn't set mddev->bitmap, so bitmap_destroy will do nothing.
is this because of reference leak of sysfs_can_clear? can we move
sysfs_put(bitmap->sysfs_can_clear); to bitmap_free?
Thanks,
Shaohua
^ permalink raw reply
* Re: [BUG] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev
From: Eric Wheeler @ 2016-03-25 21:32 UTC (permalink / raw)
To: Sebastian Roesner
Cc: linux-bcache, linux-raid, mlin, miuvlad, ming.lei, rjones,
kent.overstreet
In-Reply-To: <alpine.LRH.2.11.1603251954220.13440@mail.ewheeler.net>
On Fri, 25 Mar 2016, Eric Wheeler wrote:
> On Fri, 25 Mar 2016, Sebastian Roesner wrote:
>
> > Hi Eric,
> >
> > Am 25.03.2016 um 05:18 schrieb Eric Wheeler:
> > > Please send this output:
> > >
> > > tail /sys/block/md2/queue/discard_*
> >
> > # tail /sys/block/md2/queue/discard_*
> > ==> /sys/block/md2/queue/discard_granularity <==
> > 4096
> >
> > ==> /sys/block/md2/queue/discard_max_bytes <==
> > 2147450880
> >
> > ==> /sys/block/md2/queue/discard_max_hw_bytes <==
> > 2147450880
> >
> > ==> /sys/block/md2/queue/discard_zeroes_data <==
> > 0
Sebastian,
This could be an upstream problem. For now you could disable discards.
One to do this might be to place the cache device under LVM and set
issue_discards=0 in lvm.conf. Then register the LV as your cachedev.
Hopefully this is an initial use case and that you don't have important
writeback data in the cache such that you can re-create it. We use LVM to
allocate our cache volumes so I know it works.
I'm not sure if /sys/block/md2/queue/discard_granularity is writable, but
if it is, you could `echo 0 > /sys/block/md2/queue/discard_granularity`
which should disable discard too.
Perhaps others can chime in on turning off discard support for block
devices if there is a better way, perhaps even something md-specific.
--
Eric Wheeler
> >
> > root@gropius:/home/sroesner# echo /dev/md2 > /sys/fs/bcache/register
> > sroesner@gropius:~$
> >
> > -> it killed my bash.
> >
> > Trace with patches and BUG_ON patch:
> >
> > [ 172.660142] BUG: unable to handle kernel NULL pointer dereference at
> > 0000000000000028
> > [ 172.660229] IP: [<ffffffff811e53b4>] bio_trim+0xf/0x2a
> > [ 172.660289] PGD 7faf3e067 PUD 7f9279067 PMD 0
> > [ 172.660399] Oops: 0000 [#1] SMP
> > [...]
> > [ 172.664780] Call Trace:
> > [ 172.664813] [<ffffffffa007f3be>] ? raid1_make_request+0x2e8/0xad7 [raid1]
> > [ 172.664846] [<ffffffff811f07da>] ? blk_queue_split+0x377/0x3d4
> > [ 172.664880] [<ffffffffa005fb5f>] ? md_make_request+0xf6/0x1e9 [md_mod]
> > [ 172.664912] [<ffffffff811eb860>] ? generic_make_request+0xb5/0x155
> > [ 172.664947] [<ffffffffa0445c89>] ? prio_io+0x85/0x95 [bcache]
> > [ 172.664981] [<ffffffffa0448252>] ? register_cache_set+0x355/0x8d0 [bcache]
> > [ 172.665016] [<ffffffffa04497d3>] ? register_bcache+0x1006/0x1174 [bcache]
> >
> > See http://pastebin.com/6CHtky2x for complete traces.
> >
> > Sebastian
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" 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
* [BUG] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev
From: Eric Wheeler @ 2016-03-25 20:44 UTC (permalink / raw)
To: Sebastian Roesner
Cc: linux-bcache, linux-raid, mlin, miuvlad, ming.lei, rjones,
kent.overstreet
In-Reply-To: <56F54712.6090202@roesner-online.de>
[ +cc's, intentional top post ]
Hello linux-raid list, please see below:
A problem where bio_trim() dereferences a NULL pointer via
bio->bi_iter.bi_size (0+0x28) has been reported at least three times when
passing DISCARDs into raid1's. I could be wrong here, but I'm guessing
the cause of these three reports are the same:
[2014-02-04] https://bugzilla.redhat.com/show_bug.cgi?id=1061339
[2016-01-13] http://www.spinics.net/lists/linux-bcache/msg03335.html
https://bugzilla.kernel.org/show_bug.cgi?id=110771
[2016-03-25] http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3607 [this thread]
https://bugzilla.kernel.org/show_bug.cgi?id=114871
Is there something that needs to be done differently with DISCARD bio's,
perhaps related to splitting? We added BUG_ON(!bio) in bcache's
prio_io() function (see backtrace below) and didn't trip, so we know that
bcache isn't passing null bio pointers.
Perhaps there is an issue in either of blk_queue_split() or
md_make_request() even before it gets to raid1_make_request()?
Please add Cc's for anyone who might be able to help solve this problem.
Thanks you for your help!
--
Eric Wheeler
On Fri, 25 Mar 2016, Sebastian Roesner wrote:
> Hi Eric,
>
> Am 25.03.2016 um 05:18 schrieb Eric Wheeler:
> > Please send this output:
> >
> > tail /sys/block/md2/queue/discard_*
>
> # tail /sys/block/md2/queue/discard_*
> ==> /sys/block/md2/queue/discard_granularity <==
> 4096
>
> ==> /sys/block/md2/queue/discard_max_bytes <==
> 2147450880
>
> ==> /sys/block/md2/queue/discard_max_hw_bytes <==
> 2147450880
>
> ==> /sys/block/md2/queue/discard_zeroes_data <==
> 0
>
> root@gropius:/home/sroesner# echo /dev/md2 > /sys/fs/bcache/register
> sroesner@gropius:~$
>
> -> it killed my bash.
>
> Trace with patches and BUG_ON patch:
>
> [ 172.660142] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000028
> [ 172.660229] IP: [<ffffffff811e53b4>] bio_trim+0xf/0x2a
> [ 172.660289] PGD 7faf3e067 PUD 7f9279067 PMD 0
> [ 172.660399] Oops: 0000 [#1] SMP
> [...]
> [ 172.664780] Call Trace:
> [ 172.664813] [<ffffffffa007f3be>] ? raid1_make_request+0x2e8/0xad7 [raid1]
> [ 172.664846] [<ffffffff811f07da>] ? blk_queue_split+0x377/0x3d4
> [ 172.664880] [<ffffffffa005fb5f>] ? md_make_request+0xf6/0x1e9 [md_mod]
> [ 172.664912] [<ffffffff811eb860>] ? generic_make_request+0xb5/0x155
> [ 172.664947] [<ffffffffa0445c89>] ? prio_io+0x85/0x95 [bcache]
> [ 172.664981] [<ffffffffa0448252>] ? register_cache_set+0x355/0x8d0 [bcache]
> [ 172.665016] [<ffffffffa04497d3>] ? register_bcache+0x1006/0x1174 [bcache]
>
> See http://pastebin.com/6CHtky2x for complete traces.
>
> Sebastian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" 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 RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns
From: Seth Forshee @ 2016-03-25 20:31 UTC (permalink / raw)
To: Miklos Szeredi
Cc: Eric W. Biederman, Alexander Viro, Serge Hallyn,
Richard Weinberger, Austin S Hemmelgarn, Kernel Mailing List,
linux-bcache, dm-devel, linux-raid, linux-mtd, Linux-Fsdevel,
fuse-devel, LSM, selinux
In-Reply-To: <CAJfpegvTuR-LZAVxeJAmojs=gcrM-t5dd-QyZM-bOYMYLRL6Dg@mail.gmail.com>
On Mon, Mar 14, 2016 at 09:58:43PM +0100, Miklos Szeredi wrote:
> On Wed, Mar 9, 2016 at 6:07 PM, Seth Forshee <seth.forshee@canonical.com> wrote:
> > On Wed, Mar 09, 2016 at 04:51:42PM +0100, Miklos Szeredi wrote:
> >> On Wed, Mar 9, 2016 at 4:25 PM, Seth Forshee <seth.forshee@canonical.com> wrote:
> >> > On Wed, Mar 09, 2016 at 03:48:22PM +0100, Miklos Szeredi wrote:
> >>
> >> >> Can't we use current_cred()->uid/gid? Or fsuid/fsgid maybe?
> >> >
> >> > That would be a departure from the current behavior in the !allow_other
> >> > case for unprivileged users. Since those mounts are done by an suid
> >> > helper all of those ids would be root in the userns, wouldn't they?
> >>
> >> Well, actually this is what the helper does:
> >>
> >> sprintf(d, "fd=%i,rootmode=%o,user_id=%u,group_id=%u",
> >> fd, rootmode, getuid(), getgid());
> >
> > Sorry, I was thinking of euid. So this may not be a problem.
> >
> >> So it just uses the current uid/gid. Apparently no reason to do this
> >> in userland, we could just as well set these in the kernel. Except
> >> for possible backward compatibility problems for things not using the
> >> helper.
> >>
> >> BUT if the mount is unprivileged or it's a userns mount, or anything
> >> previously not possible, then we are not constrained by the backward
> >> compatibility issues, and can go with the saner solution.
> >>
> >> Does that not make sense?
> >
> > But we generally do want backwards compatibility, and we want userspace
> > software to be able to expect the same behavior whether or not it's
> > running in a user namespaced container. Obviously we can't always have
> > things 100% identical, but we shouldn't break things unless we really
> > need to.
> >
> > However it may be that this isn't actually going to break assumptions of
> > existing software like I had feared. My preference is still to not
> > change any userspace-visible behaviors since we never know what software
> > might have made assumptions based on those behaviors. But if you're
> > confident that it won't break anything I'm willing to give it a try.
>
> I'm quite confident it won't make a difference.
I was just about to go make these changes and discovered that the
user_id and group_id options are already mandatory, due to this check at
the bottom of parse_fuse_opt():
if (!d->fd_present || !d->rootmode_present ||
!d->user_id_present || !d->group_id_present)
return 0;
So I'll simply drop those two lines which supply default values for
these options.
Thanks,
Seth
^ permalink raw reply
* [PATCH] md/bitmap: call bitmap_destroy in case bitmap_create failed
From: Guoqing Jiang @ 2016-03-25 11:00 UTC (permalink / raw)
To: shli; +Cc: linux-raid, neilb, Guoqing Jiang
If bitmap_create returns an error, bitmap_destroy must be
called to do clean up.
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/bitmap.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index 7df6b4f..ba908e7 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -1865,8 +1865,10 @@ int bitmap_copy_from_slot(struct mddev *mddev, int slot,
struct bitmap_counts *counts;
struct bitmap *bitmap = bitmap_create(mddev, slot);
- if (IS_ERR(bitmap))
+ if (IS_ERR(bitmap)) {
+ bitmap_destroy(mddev);
return PTR_ERR(bitmap);
+ }
rv = bitmap_init_from_disk(bitmap, 0);
if (rv)
@@ -1898,7 +1900,7 @@ int bitmap_copy_from_slot(struct mddev *mddev, int slot,
*low = lo;
*high = hi;
err:
- bitmap_free(bitmap);
+ bitmap_destroy(mddev);
return rv;
}
EXPORT_SYMBOL_GPL(bitmap_copy_from_slot);
@@ -2170,14 +2172,14 @@ location_store(struct mddev *mddev, const char *buf, size_t len)
else {
mddev->bitmap = bitmap;
rv = bitmap_load(mddev);
- if (rv) {
- bitmap_destroy(mddev);
+ if (rv)
mddev->bitmap_info.offset = 0;
- }
}
mddev->pers->quiesce(mddev, 0);
- if (rv)
+ if (rv) {
+ bitmap_destroy(mddev);
return rv;
+ }
}
}
}
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] mdadm:Add '--nodes' option in GROW mode
From: zhilong @ 2016-03-25 2:22 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Guoqing Jiang, linux-raid
In-Reply-To: <wrfj7fgr4z3g.fsf@redhat.com>
mdadm:add '--nodes' option in GROW mode, because
'Cluster nodes' is set 4 by default if the nodes
parameter is not specified when switch bitmap
from none to clustered.
Signed-off-by: Zhilong Liu <zlliu@suse.com>
---
mdadm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mdadm.c b/mdadm.c
index d2afcb2..58ac32a 100644
--- a/mdadm.c
+++ b/mdadm.c
@@ -589,6 +589,7 @@ int main(int argc, char *argv[])
ident.raid_disks = s.raiddisks;
continue;
case O(ASSEMBLE, Nodes):
+ case O(GROW, Nodes):
case O(CREATE, Nodes):
c.nodes = parse_num(optarg);
if (c.nodes <= 0) {
--
2.1.4
On 03/25/2016 12:31 AM, Jes Sorensen wrote:
> Guoqing Jiang <gqjiang@suse.com> writes:
>> On 03/23/2016 01:56 AM, Jes Sorensen wrote:
>>> zhilong <zlliu@suse.com> writes:
>>>> Bug description:
>>>> # mdadm -Cv /dev/md0 --bitmap=clustered -l1 -n2 /dev/sdd /dev/sdb
>>>> --nodes=6 --assume-clean
>>>> # mdadm --grow /dev/md0 --bitmap=none
>>>> # mdadm --grow /dev/md0 --bitmap=clustered
>>>> -> cluster nodes would be changed to 4, here is my method to
>>>> resolve it.
>>>> # mdadm --grow /dev/md0 --bitmap=clustered --nodes=6
>>>>
>>>> Patch:
>>>>
>>>> Cluster nodes is set 4 as default when switch bitmap from
>>>> none to clustered under GROW mode, so add '--nodes'
>>>> option in GROW mode.
>>>>
>>>> Signed-off-by: Zhilong Liu <zlliu@suse.com>
>>>> ---
>>>> mdadm.c | 1 +
>>>> 1 file changed, 1 insertion(+)
>>> Hi,
>>>
>>> I have a question about this, since I simply do not have the knowledge
>>> about clustering to judge this approach.
>>>
>>> If you remove the bitmap, does that 'uncluster' the array? If not,
>> Yes, remove the bitmap would 'uncluster' the array since leave()
>> will be called in kernel if switch the bitmap from 'clustered' to
>> 'none'.
>>
>>> shouldn't mdadm be fixed to not set #nodes to 4 when adding a clustered
>>> bitmap, if a number of cluster nodes is already present?
>> The nodes is set 4 by default if the 'nodes' parameter is not specified,
>> And it could be overwrite if re-create the clustered bitmap.
> Thanks for the explanation, in that case I am fine with this. It does
> raise the issue whether specifying nodes shouldn't be a required
> argument rather than defaulting to a default of 4?
>
> Second, your patch was broken due to bad whitespace formatting, could
> you please send me a fresh one.
>
> Thanks,
> 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 related
* Re: [PATCH] Change the option from NoUpdate to NodeNumUpdate
From: Jes Sorensen @ 2016-03-24 16:33 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: linux-raid
In-Reply-To: <1458813635-14175-1-git-send-email-gqjiang@suse.com>
Guoqing Jiang <gqjiang@suse.com> writes:
> Actually, we need to use NodeNumUpdate here to
> ensure there are enough spaces for those nodes.
>
> Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
> ---
> Grow.c | 2 +-
> super1.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Applied!
Thanks,
Jes
^ permalink raw reply
* Re: [PATCH] Add '--nodes' option in GROW mode
From: Jes Sorensen @ 2016-03-24 16:31 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: zhilong, linux-raid
In-Reply-To: <56F28046.9010801@suse.com>
Guoqing Jiang <gqjiang@suse.com> writes:
> On 03/23/2016 01:56 AM, Jes Sorensen wrote:
>> zhilong <zlliu@suse.com> writes:
>>> Bug description:
>>> # mdadm -Cv /dev/md0 --bitmap=clustered -l1 -n2 /dev/sdd /dev/sdb
>>> --nodes=6 --assume-clean
>>> # mdadm --grow /dev/md0 --bitmap=none
>>> # mdadm --grow /dev/md0 --bitmap=clustered
>>> -> cluster nodes would be changed to 4, here is my method to
>>> resolve it.
>>> # mdadm --grow /dev/md0 --bitmap=clustered --nodes=6
>>>
>>> Patch:
>>>
>>> Cluster nodes is set 4 as default when switch bitmap from
>>> none to clustered under GROW mode, so add '--nodes'
>>> option in GROW mode.
>>>
>>> Signed-off-by: Zhilong Liu <zlliu@suse.com>
>>> ---
>>> mdadm.c | 1 +
>>> 1 file changed, 1 insertion(+)
>> Hi,
>>
>> I have a question about this, since I simply do not have the knowledge
>> about clustering to judge this approach.
>>
>> If you remove the bitmap, does that 'uncluster' the array? If not,
>
> Yes, remove the bitmap would 'uncluster' the array since leave()
> will be called in kernel if switch the bitmap from 'clustered' to
> 'none'.
>
>> shouldn't mdadm be fixed to not set #nodes to 4 when adding a clustered
>> bitmap, if a number of cluster nodes is already present?
>
> The nodes is set 4 by default if the 'nodes' parameter is not specified,
> And it could be overwrite if re-create the clustered bitmap.
Thanks for the explanation, in that case I am fine with this. It does
raise the issue whether specifying nodes shouldn't be a required
argument rather than defaulting to a default of 4?
Second, your patch was broken due to bad whitespace formatting, could
you please send me a fresh one.
Thanks,
Jes
^ permalink raw reply
* [PATCH] Change the option from NoUpdate to NodeNumUpdate
From: Guoqing Jiang @ 2016-03-24 10:00 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-raid, Guoqing Jiang
Actually, we need to use NodeNumUpdate here to
ensure there are enough spaces for those nodes.
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
Grow.c | 2 +-
super1.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Grow.c b/Grow.c
index 5953db2..f58c753 100755
--- a/Grow.c
+++ b/Grow.c
@@ -425,7 +425,7 @@ int Grow_addbitmap(char *devname, int fd, struct context *c, struct shape *s)
bitmapsize, offset_setable,
major)
)
- st->ss->write_bitmap(st, fd2, NoUpdate);
+ st->ss->write_bitmap(st, fd2, NodeNumUpdate);
else {
pr_err("failed to create internal bitmap - chunksize problem.\n");
close(fd2);
diff --git a/super1.c b/super1.c
index baa9a96..d6f3c93 100644
--- a/super1.c
+++ b/super1.c
@@ -1867,7 +1867,7 @@ static int write_init_super1(struct supertype *st)
}
if (rv == 0 && (__le32_to_cpu(sb->feature_map) & 1))
- rv = st->ss->write_bitmap(st, di->fd, NoUpdate);
+ rv = st->ss->write_bitmap(st, di->fd, NodeNumUpdate);
close(di->fd);
di->fd = -1;
if (rv)
--
2.6.2
^ permalink raw reply related
* Re: [PATCH] Add '--nodes' option in GROW mode
From: Guoqing Jiang @ 2016-03-23 11:38 UTC (permalink / raw)
To: Jes Sorensen, zhilong; +Cc: linux-raid
In-Reply-To: <wrfjshzi9z1l.fsf@redhat.com>
On 03/23/2016 01:56 AM, Jes Sorensen wrote:
> zhilong <zlliu@suse.com> writes:
>> Bug description:
>> # mdadm -Cv /dev/md0 --bitmap=clustered -l1 -n2 /dev/sdd /dev/sdb
>> --nodes=6 --assume-clean
>> # mdadm --grow /dev/md0 --bitmap=none
>> # mdadm --grow /dev/md0 --bitmap=clustered
>> -> cluster nodes would be changed to 4, here is my method to
>> resolve it.
>> # mdadm --grow /dev/md0 --bitmap=clustered --nodes=6
>>
>> Patch:
>>
>> Cluster nodes is set 4 as default when switch bitmap from
>> none to clustered under GROW mode, so add '--nodes'
>> option in GROW mode.
>>
>> Signed-off-by: Zhilong Liu <zlliu@suse.com>
>> ---
>> mdadm.c | 1 +
>> 1 file changed, 1 insertion(+)
> Hi,
>
> I have a question about this, since I simply do not have the knowledge
> about clustering to judge this approach.
>
> If you remove the bitmap, does that 'uncluster' the array? If not,
Yes, remove the bitmap would 'uncluster' the array since leave()
will be called in kernel if switch the bitmap from 'clustered' to
'none'.
> shouldn't mdadm be fixed to not set #nodes to 4 when adding a clustered
> bitmap, if a number of cluster nodes is already present?
The nodes is set 4 by default if the 'nodes' parameter is not specified,
And it could be overwrite if re-create the clustered bitmap.
Thanks,
Guoqing
^ 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