From: NeilBrown <neilb@suse.de>
To: Killian De Volder <killian.de.volder@megasoft.be>
Cc: linux-raid@vger.kernel.org
Subject: Re: Unable to reduce raid size.
Date: Fri, 18 Jul 2014 20:48:08 +1000 [thread overview]
Message-ID: <20140718204808.5cbbe0cb@notabene.brown> (raw)
In-Reply-To: <53C8EFC1.1050105@megasoft.be>
[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]
On Fri, 18 Jul 2014 11:58:25 +0200 Killian De Volder
<killian.de.volder@megasoft.be> wrote:
> Bytes are cheap, but screens are small (you'll have to scroll more).
>
> "This condition isn't treated as an error by mdadm, so it isn't the cause."
> This is not an error, but if the size isn't changed, the end result will be
> component size of /dev/md125 unchanged at 2858285568K (skimmed the source code of mdadm, might have gotten it wrong though)
>
> Full Strace below
Thanks. It doesn't actually contain any surprises, but having seen it I
easily found the bug..... hard to explain.
The "SET_ARRAY_INFO" ioctl can be used to set the 'size' of the array, but
only
if the size fits in a signed int as a positive number.
However mdadm tests if it fits in an *unsigned* int.
So any size between 2^31 and 2^32 K can not effectively be set by mdadm.
I think this patch to mdadm will fix it - can you test?
diff --git a/Grow.c b/Grow.c
index ea9cc60e1f18..af59347ca75e 100644
--- a/Grow.c
+++ b/Grow.c
@@ -1813,7 +1813,7 @@ int Grow_reshape(char *devname, int fd,
if (s->size == MAX_SIZE)
s->size = 0;
array.size = s->size;
- if ((unsigned)array.size != s->size) {
+ if (array.size != (signed long long)s->size) {
/* got truncated to 32bit, write to
* component_size instead
*/
The code that is reporting an error is setting the used size of each
individual device.
If you make the devices in an array bigger (typically if they are LVM volumes
and you resize them), then you cannot make the array bigger without first
telling md that the devices have changed size.
So mdadm first tells the kernel that the devices are big enough. If they
were already that big, the kernel will return EBUSY, and mdadm will ignore it.
If the aren't really that big, the kernel will round down to the real size.
In your case the underlying devices hadn't changed size so mdadm was doing
something unnecessary and got an error which it ignored.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2014-07-18 10:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-18 8:50 Unable to reduce raid size Killian De Volder
2014-07-18 9:40 ` NeilBrown
2014-07-18 9:58 ` Killian De Volder
2014-07-18 10:48 ` NeilBrown [this message]
2014-07-18 11:19 ` Killian De Volder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140718204808.5cbbe0cb@notabene.brown \
--to=neilb@suse.de \
--cc=killian.de.volder@megasoft.be \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).