* Re: Linear device of two arrays
From: Andreas Klauer @ 2017-07-07 22:33 UTC (permalink / raw)
To: Roman Mamedov; +Cc: Veljko, linux-raid
In-Reply-To: <20170708025318.216210e7@natsu>
On Sat, Jul 08, 2017 at 02:53:18AM +0500, Roman Mamedov wrote:
> however it requires a shrinkable filesystem, and XFS cannot be shrunk.
And an easy way to adapt may be thus:
Just backup the last 100M of the filesystem. Then you can consider
the filesystem to be shrunk by 100M. Not really, but it covers
the space that will be lost in the LVM conversion (two extents).
When the conversion is done, you grow the LV back to original size,
(now that's using two extents on another PV you have to provide)
and restore the 100M you backed up to the LV.
The conversion is an offline operation anyways so it doesn't matter
whether you really shrank the filesystem or not, as long as you can
provide enough space for an LV of the original partition size.
Regards
Andreas Klauer
^ permalink raw reply
* Re: Linear device of two arrays
From: Andreas Klauer @ 2017-07-07 22:20 UTC (permalink / raw)
To: Roman Mamedov; +Cc: Veljko, linux-raid
In-Reply-To: <20170708025318.216210e7@natsu>
On Sat, Jul 08, 2017 at 02:53:18AM +0500, Roman Mamedov wrote:
> however it requires a shrinkable filesystem, and XFS cannot be shrunk.
There's a description of the manual process here:
https://wiki.ubuntuusers.de/Howto/LVM_nachtr%C3%A4glich_einrichten/
(Sorry it's in German)
You have to adapt it to use two extents on another PV instead
of shrinking the filesystem or growing the existing blockdevice.
It can be done, but yeah it's a bit of voodoo.
Copying is safer.
Regards
Andreas Klauer
^ permalink raw reply
* Re: Linear device of two arrays
From: Roman Mamedov @ 2017-07-07 21:53 UTC (permalink / raw)
To: Andreas Klauer; +Cc: Veljko, linux-raid
In-Reply-To: <20170707212036.GA26305@metamorpher.de>
On Fri, 7 Jul 2017 23:20:36 +0200
Andreas Klauer <Andreas.Klauer@metamorpher.de> wrote:
> Put LVM on top?
>
> You could create LVM on the new array, copy your files over, then extend.
>
> If you know LVM _really_ well, it's also possible to convert existing
> filesystems without moving data (other than relocating the parts
> occupied/unusable by LVM, i.e. one extent-size worth of data at
> start and end of disk).
There is this tool which can convert filesystems/partitions to LVM in-place:
https://github.com/g2p/blocks
however it requires a shrinkable filesystem, and XFS cannot be shrunk.
(Also it appears unmaintained with a number of long-standing unresolved
issues).
--
With respect,
Roman
^ permalink raw reply
* Re: Linear device of two arrays
From: Andreas Klauer @ 2017-07-07 21:20 UTC (permalink / raw)
To: Veljko; +Cc: linux-raid
In-Reply-To: <CALee7hZqmLK19tSEEFBgSWMKm9TRoUqLBCxUmbNJpwmM45BjTQ@mail.gmail.com>
On Fri, Jul 07, 2017 at 10:26:28PM +0200, Veljko wrote:
> So my question is still, how can an existing array be added to linear
> device, and it's file system expanded over the second array.
Put LVM on top?
You could create LVM on the new array, copy your files over, then extend.
If you know LVM _really_ well, it's also possible to convert existing
filesystems without moving data (other than relocating the parts
occupied/unusable by LVM, i.e. one extent-size worth of data at
start and end of disk).
Or find a way to use more than one filesystem.
> And there is also question of spare drive.
Spares can be shared/moved if you use spare-groups.
From the manpage:
| As well as reporting events, mdadm may move a spare drive from one
| array to another if they are in the same spare-group or domain and if
| the destination array has a failed drive but no spares.
Regards
Andreas Klauer
^ permalink raw reply
* Re: Linear device of two arrays
From: Veljko @ 2017-07-07 20:26 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <595D2ADA.8010907@youngman.org.uk>
I just noticed that I replied to Wol insted to list.
On Wed, Jul 5, 2017 at 8:07 PM, Wols Lists <antlists@youngman.org.uk> wrote:
> On 05/07/17 17:42, Roman Mamedov wrote:
>> On Wed, 5 Jul 2017 17:34:09 +0200
>> Veljko <veljko3@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I have a RAID10 device which I have formated using the mkfs.xfs
>>> defaults (Stan helped me with this few years back). I reached 88%
>>> capacity and it is time to expand it. I bought 4 more drives to create
>>> another RIAD10 array. I would like to create linear device out of
>>> those two and grow XFS across the 2nd device. How can this be done
>>> without loosing the existing device's data? I would also like to add a
>>> spare HDD. Do I have to have a separate spare HDD for each array or
>>> one can be used by both of them?
>>
>> Why make another RAID10? With modern versions of mdadm and kernel you should
>> be able to simply reshape the current RAID10 to increase the number of
>> devices used from 4 to 8.
>>
>>
> I was thinking of replying, but isn't that not possible for some
> versions of RAID-10?
>
> My feeling was, if you can't just add drives to the existing raid 10,
> create a new one which you can expand, migrate the fs across (btrfs
> would let you do that live, I believe, so xfs probably can too), then
> you can scrap the old raid-10 and add the drives into the new one.
>
> Cheers,
> Wol
Thanks for your input, Roman and Wol.
Expanding existing RAID is one of the options, but I was advised by
Stan Hoeppner to do it this way and I tend to believe him on this
subject. With my metadata heavy backup workload, this will provide
better performance.
So my question is still, how can an existing array be added to linear
device, and it's file system expanded over the second array.
And there is also question of spare drive.
Regards,
Veljko
^ permalink raw reply
* Re: Linear device of two arrays
From: Nix @ 2017-07-07 11:07 UTC (permalink / raw)
To: Wols Lists; +Cc: Roman Mamedov, Veljko, linux-raid
In-Reply-To: <595D2ADA.8010907@youngman.org.uk>
On 5 Jul 2017, Wols Lists spake thusly:
> My feeling was, if you can't just add drives to the existing raid 10,
> create a new one which you can expand, migrate the fs across (btrfs
> would let you do that live, I believe, so xfs probably can too), then
> you can scrap the old raid-10 and add the drives into the new one.
In extremis you can always connect multiple block devices into one, or
indeed multiple *pieces* of them into one, using dmsetup with the linear
table. (However, this is not persistent, so you'd need to script redoing
it on every boot.)
--
NULL && (void)
^ permalink raw reply
* (unknown),
From: een @ 2017-07-06 14:11 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: EMAIL_938012525_linux-raid.zip --]
[-- Type: application/zip, Size: 4285 bytes --]
^ permalink raw reply
* Re: Disk Monitoring
From: NeilBrown @ 2017-07-06 3:31 UTC (permalink / raw)
To: Johannes Truschnigg, Gandalf Corvotempesta; +Cc: linux-raid
In-Reply-To: <20170628104545.z7anvliygsjrhqax@vault.lan>
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
On Wed, Jun 28 2017, Johannes Truschnigg wrote:
> Hi Gandalf,
>
> On Wed, Jun 28, 2017 at 12:25:55PM +0200, Gandalf Corvotempesta wrote:
>> Hi to all
>> I always used hardwre raid but with my next server I would like to use mdadm.
>>
>> Some questions:
>>
>> 1) all raid controllers have proactive monitoring features, like
>> patrol read, consistency check and (more or less) some SMART
>> integration.
>> Any counterpart in mdadm?
>
> mdmon(8) is what you seek. Also, monitoring the kernel debug ringbuffer I can
> highly recommend.
Not mdmon(8).
Possible you mean "mdadm --monitor".
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* (unknown),
From: een @ 2017-07-05 21:18 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: EMAIL_3767374_linux-raid.zip --]
[-- Type: application/zip, Size: 5044 bytes --]
^ permalink raw reply
* Re: Linear device of two arrays
From: Wols Lists @ 2017-07-05 18:07 UTC (permalink / raw)
To: Roman Mamedov, Veljko; +Cc: linux-raid
In-Reply-To: <20170705214250.0ea99538@natsu>
On 05/07/17 17:42, Roman Mamedov wrote:
> On Wed, 5 Jul 2017 17:34:09 +0200
> Veljko <veljko3@gmail.com> wrote:
>
>> Hello,
>>
>> I have a RAID10 device which I have formated using the mkfs.xfs
>> defaults (Stan helped me with this few years back). I reached 88%
>> capacity and it is time to expand it. I bought 4 more drives to create
>> another RIAD10 array. I would like to create linear device out of
>> those two and grow XFS across the 2nd device. How can this be done
>> without loosing the existing device's data? I would also like to add a
>> spare HDD. Do I have to have a separate spare HDD for each array or
>> one can be used by both of them?
>
> Why make another RAID10? With modern versions of mdadm and kernel you should
> be able to simply reshape the current RAID10 to increase the number of
> devices used from 4 to 8.
>
>
I was thinking of replying, but isn't that not possible for some
versions of RAID-10?
My feeling was, if you can't just add drives to the existing raid 10,
create a new one which you can expand, migrate the fs across (btrfs
would let you do that live, I believe, so xfs probably can too), then
you can scrap the old raid-10 and add the drives into the new one.
Cheers,
Wol
^ permalink raw reply
* Re: Linear device of two arrays
From: Roman Mamedov @ 2017-07-05 16:42 UTC (permalink / raw)
To: Veljko; +Cc: linux-raid
In-Reply-To: <CALee7hZYgLNO2siDJNtFge_BoocTXX-9BSgRHmMJH8MaH6V3LA@mail.gmail.com>
On Wed, 5 Jul 2017 17:34:09 +0200
Veljko <veljko3@gmail.com> wrote:
> Hello,
>
> I have a RAID10 device which I have formated using the mkfs.xfs
> defaults (Stan helped me with this few years back). I reached 88%
> capacity and it is time to expand it. I bought 4 more drives to create
> another RIAD10 array. I would like to create linear device out of
> those two and grow XFS across the 2nd device. How can this be done
> without loosing the existing device's data? I would also like to add a
> spare HDD. Do I have to have a separate spare HDD for each array or
> one can be used by both of them?
Why make another RAID10? With modern versions of mdadm and kernel you should
be able to simply reshape the current RAID10 to increase the number of
devices used from 4 to 8.
--
With respect,
Roman
^ permalink raw reply
* Linear device of two arrays
From: Veljko @ 2017-07-05 15:34 UTC (permalink / raw)
To: linux-raid
Hello,
I have a RAID10 device which I have formated using the mkfs.xfs
defaults (Stan helped me with this few years back). I reached 88%
capacity and it is time to expand it. I bought 4 more drives to create
another RIAD10 array. I would like to create linear device out of
those two and grow XFS across the 2nd device. How can this be done
without loosing the existing device's data? I would also like to add a
spare HDD. Do I have to have a separate spare HDD for each array or
one can be used by both of them?
Regards,
Veljko
^ permalink raw reply
* [MD PATCH 1/1 -v2] Raid5 should update rdev->sectors after reshape
From: Xiao Ni @ 2017-07-05 9:34 UTC (permalink / raw)
To: linux-raid; +Cc: ncroxon, tbskyd, shli, gqjiang
The raid5 md device is created by the disks which we don't use the total size. For example,
the size of the device is 5G and it just uses 3G of the devices to create one raid5 device.
Then change the chunksize and wait reshape to finish. After reshape finishing stop the raid
and assemble it again. It fails.
mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --size=3G --chunk=32 --assume-clean
mdadm /dev/md0 --grow --chunk=64
wait reshape to finish
mdadm -S /dev/md0
mdadm -As
The error messages:
[197519.814302] md: loop1 does not have a valid v1.2 superblock, not importing!
[197519.821686] md: md_import_device returned -22
After reshape the data offset is changed. It selects backwards direction in this condition.
In function super_1_load it compares the available space of the underlying device with
sb->data_size. The new data offset gets bigger after reshape. So super_1_load returns -EINVAL.
rdev->sectors is updated in md_finish_reshape. Then sb->data_size is set in super_1_sync based
on rdev->sectors. So add md_finish_reshape in end_reshape.
Signed-off-by: Xiao Ni <xni@redhat.com>
---
drivers/md/raid5.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index ec0f951..e7f527c 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -7947,12 +7947,10 @@ static void end_reshape(struct r5conf *conf)
{
if (!test_bit(MD_RECOVERY_INTR, &conf->mddev->recovery)) {
- struct md_rdev *rdev;
spin_lock_irq(&conf->device_lock);
conf->previous_raid_disks = conf->raid_disks;
- rdev_for_each(rdev, conf->mddev)
- rdev->data_offset = rdev->new_data_offset;
+ md_finish_reshape(conf->mddev);
smp_wmb();
conf->reshape_progress = MaxSector;
conf->mddev->reshape_position = MaxSector;
--
2.7.4
^ permalink raw reply related
* Re: [MD PATCH 1/1] Raid5 should update rdev->sectors after reshape
From: Xiao Ni @ 2017-07-05 9:27 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: linux-raid, ncroxon, tbskyd, shli
In-Reply-To: <5ae7006a-ae4f-d5c2-7d89-93535457d570@suse.com>
----- Original Message -----
> From: "Guoqing Jiang" <gqjiang@suse.com>
> To: "Xiao Ni" <xni@redhat.com>, linux-raid@vger.kernel.org
> Cc: ncroxon@redhat.com, tbskyd@gmail.com, shli@kernel.org
> Sent: Wednesday, July 5, 2017 4:51:59 PM
> Subject: Re: [MD PATCH 1/1] Raid5 should update rdev->sectors after reshape
>
>
>
> On 07/04/2017 02:29 PM, Xiao Ni wrote:
> > The raid5 md device is created by the disks which we don't use the total
> > size. For example,
> > the size of the device is 5G and it just uses 3G of the devices to create
> > one raid5 device.
> > Then change the chunksize and wait reshape to finish. After reshape
> > finishing stop the raid
> > and assemble it again. It fails.
> > mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --size=3G --chunk=32
> > --assume-clean
> > mdadm /dev/md0 --grow --chunk=64
> > wait reshape to finish
> > mdadm -S /dev/md0
> > mdadm -As
> > The error messages:
> > [197519.814302] md: loop1 does not have a valid v1.2 superblock, not
> > importing!
> > [197519.821686] md: md_import_device returned -22
> >
> > After reshape the data offset is changed. It selects backwards direction in
> > this condition.
> > In function super_1_load it compares the available space of the underlying
> > device with
> > sb->data_size. The new data offset gets bigger after reshape. So
> > super_1_load returns -EINVAL.
> > sb->data_size is updated in md_finish_reshape. So add md_finish_reshape in
> > end_reshape.
>
> IMO, md_finish_reshape doesn't update sb->data_size directly, but it
> updates rdev->sectors,
> then super_1_sync sets sb->data_size based on rdev->sectors.
Ah yes, thanks for pointing this. It should be rdev->sectors is updated
in md_finish_reshape.
Regards
Xiao
>
> Acked-by: Guoqing Jiang <gqjiang@suse.com>
>
> Thanks,
> Guoqing
>
> > Signed-off-by: Xiao Ni <xni@redhat.com>
> > ---
> > drivers/md/raid5.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> > index ec0f951..e7f527c 100644
> > --- a/drivers/md/raid5.c
> > +++ b/drivers/md/raid5.c
> > @@ -7947,12 +7947,10 @@ static void end_reshape(struct r5conf *conf)
> > {
> >
> > if (!test_bit(MD_RECOVERY_INTR, &conf->mddev->recovery)) {
> > - struct md_rdev *rdev;
> >
> > spin_lock_irq(&conf->device_lock);
> > conf->previous_raid_disks = conf->raid_disks;
> > - rdev_for_each(rdev, conf->mddev)
> > - rdev->data_offset = rdev->new_data_offset;
> > + md_finish_reshape(conf->mddev);
> > smp_wmb();
> > conf->reshape_progress = MaxSector;
> > conf->mddev->reshape_position = MaxSector;
>
> --
> 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: [MD PATCH 1/1] Raid5 should update rdev->sectors after reshape
From: Guoqing Jiang @ 2017-07-05 8:51 UTC (permalink / raw)
To: Xiao Ni, linux-raid; +Cc: ncroxon, tbskyd, shli
In-Reply-To: <1499149794-7309-1-git-send-email-xni@redhat.com>
On 07/04/2017 02:29 PM, Xiao Ni wrote:
> The raid5 md device is created by the disks which we don't use the total size. For example,
> the size of the device is 5G and it just uses 3G of the devices to create one raid5 device.
> Then change the chunksize and wait reshape to finish. After reshape finishing stop the raid
> and assemble it again. It fails.
> mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --size=3G --chunk=32 --assume-clean
> mdadm /dev/md0 --grow --chunk=64
> wait reshape to finish
> mdadm -S /dev/md0
> mdadm -As
> The error messages:
> [197519.814302] md: loop1 does not have a valid v1.2 superblock, not importing!
> [197519.821686] md: md_import_device returned -22
>
> After reshape the data offset is changed. It selects backwards direction in this condition.
> In function super_1_load it compares the available space of the underlying device with
> sb->data_size. The new data offset gets bigger after reshape. So super_1_load returns -EINVAL.
> sb->data_size is updated in md_finish_reshape. So add md_finish_reshape in end_reshape.
IMO, md_finish_reshape doesn't update sb->data_size directly, but it
updates rdev->sectors,
then super_1_sync sets sb->data_size based on rdev->sectors.
Acked-by: Guoqing Jiang <gqjiang@suse.com>
Thanks,
Guoqing
> Signed-off-by: Xiao Ni <xni@redhat.com>
> ---
> drivers/md/raid5.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index ec0f951..e7f527c 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -7947,12 +7947,10 @@ static void end_reshape(struct r5conf *conf)
> {
>
> if (!test_bit(MD_RECOVERY_INTR, &conf->mddev->recovery)) {
> - struct md_rdev *rdev;
>
> spin_lock_irq(&conf->device_lock);
> conf->previous_raid_disks = conf->raid_disks;
> - rdev_for_each(rdev, conf->mddev)
> - rdev->data_offset = rdev->new_data_offset;
> + md_finish_reshape(conf->mddev);
> smp_wmb();
> conf->reshape_progress = MaxSector;
> conf->mddev->reshape_position = MaxSector;
^ permalink raw reply
* Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
From: Xiao Ni @ 2017-07-05 3:24 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: linux-raid, ncroxon, jes sorensen
In-Reply-To: <937c54e7-272d-ba24-d977-35a62ca6b684@suse.com>
----- Original Message -----
> From: "Guoqing Jiang" <gqjiang@suse.com>
> To: "Xiao Ni" <xni@redhat.com>
> Cc: linux-raid@vger.kernel.org, ncroxon@redhat.com, "jes sorensen" <jes.sorensen@gmail.com>
> Sent: Wednesday, July 5, 2017 11:21:57 AM
> Subject: Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
>
>
>
> On 07/05/2017 10:40 AM, Xiao Ni wrote:
> >
> > ----- Original Message -----
> >> From: "Guoqing Jiang" <gqjiang@suse.com>
> >> To: "Xiao Ni" <xni@redhat.com>
> >> Cc: linux-raid@vger.kernel.org, ncroxon@redhat.com, "jes sorensen"
> >> <jes.sorensen@gmail.com>
> >> Sent: Wednesday, July 5, 2017 9:56:35 AM
> >> Subject: Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
> >>
> >>
> >>
> >> On 07/04/2017 05:55 PM, Xiao Ni wrote:
> >>> ----- Original Message -----
> >>>> From: "Guoqing Jiang" <gqjiang@suse.com>
> >>>> To: "Xiao Ni" <xni@redhat.com>, linux-raid@vger.kernel.org
> >>>> Cc: ncroxon@redhat.com, "jes sorensen" <jes.sorensen@gmail.com>
> >>>> Sent: Tuesday, July 4, 2017 5:03:30 PM
> >>>> Subject: Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
> >>>>
> >>>>
> >>>>
> >>>> On 07/04/2017 02:50 PM, Xiao Ni wrote:
> >>>>> The size of array shows wrongly. It shifs wrong number.
> >>>>>
> >>>>> Signed-off-by: Xiao Ni <xni@redhat.com>
> >>>>> ---
> >>>>> super1.c | 2 +-
> >>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/super1.c b/super1.c
> >>>>> index 86ec850..f3b864d 100644
> >>>>> --- a/super1.c
> >>>>> +++ b/super1.c
> >>>>> @@ -366,7 +366,7 @@ static void examine_super1(struct supertype *st,
> >>>>> char
> >>>>> *homehost)
> >>>>> }
> >>>>> if (ddsks) {
> >>>>> long long asize = __le64_to_cpu(sb->size);
> >>>>> - asize = (asize << 9) * ddsks / ddsks_denom;
> >>>>> + asize = (asize << 10) * ddsks / ddsks_denom;
> >>>>> printf(" Array Size : %llu%s\n",
> >>>>> asize >> 10, human_size(asize));
> >>>>> }
> >>>> IIRC, sb->size represents the num of sectors, so the shift should be 9.
> >>> Yes, it should be 9. It should pass bytes to human_size. Thanks for this.
> >>> It was introduced in d4633e06dfc01723911627fcb104af2ffb6f6a95. So there
> >>> is
> >>> the same problem in super0. Is it ok:
> >>>
> >>> diff --git a/super0.c b/super0.c
> >>> index 756cab5..4b4680c 100644
> >>> --- a/super0.c
> >>> +++ b/super0.c
> >>> @@ -131,9 +131,9 @@ static void examine_super0(struct supertype *st, char
> >>> *homehost)
> >>> }
> >>> if (ddsks) {
> >>> long long asize = sb->size;
> >>> - asize = (asize << 10) * ddsks / ddsks_denom;
> >>> + asize = (asize << 9) * ddsks / ddsks_denom;
> >>> printf(" Array Size : %llu%s\n",
> >>> - asize >> 10, human_size(asize));
> >>> + asize >> 9, human_size(asize));
> >>> }
> >> No, for 0.9 metadata, sb->size means KB not sector.
> >>
> > Thanks for this.
> >
> >>> }
> >>> printf(" Raid Devices : %d\n", sb->raid_disks);
> >>> diff --git a/super1.c b/super1.c
> >>> index 86ec850..2bb1454 100644
> >>> --- a/super1.c
> >>> +++ b/super1.c
> >>> @@ -368,7 +368,7 @@ static void examine_super1(struct supertype *st, char
> >>> *homehost)
> >>> long long asize = __le64_to_cpu(sb->size);
> >>> asize = (asize << 9) * ddsks / ddsks_denom;
> >>> printf(" Array Size : %llu%s\n",
> >>> - asize >> 10, human_size(asize));
> >>> + asize >> 9, human_size(asize));
> >>> }
> >>> if (sb->size != sb->data_size)
> >>> printf(" Used Dev Size : %llu%s\n",
> >> It is better that you can provide the output of "mdadm -E DISK" etc to
> >> prove
> >> current code is wrong, at least I can see correct output from my side.
> > [root@dell-per210-01 mdadm]# mdadm -E /dev/loop0
> > /dev/loop0:
> > Magic : a92b4efc
> > Version : 1.2
> > Feature Map : 0x0
> > Array UUID : 34f18365:ebf46416:ae1f365d:71cc579c
> > Name : 0
> > Creation Time : Tue Jul 4 02:09:03 2017
> > Raid Level : raid5
> > Raid Devices : 3
> >
> > Avail Dev Size : 8261632 (3.94 GiB 4.23 GB)
> > Array Size : 6291456 (6.00 GiB 6.44 GB)
> > Used Dev Size : 6291456 (3.00 GiB 3.22 GB)
> >
> > Ah, I know it wants to show Array Size in KB. It's a raid5 with 3 loop
> > devices.
> > I thought they are all sectors subconsciously. But it's better to show
> > sizes with
> > the same unit. Right?
>
> Perhaps that is why the human_size is used here.
But it's really too strange that Array Size is same with Used Dev Size. It's
easy to get confused.
Regards
Xiao
>
> Thanks,
> Guoqing
> --
> 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: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
From: Guoqing Jiang @ 2017-07-05 3:21 UTC (permalink / raw)
To: Xiao Ni; +Cc: linux-raid, ncroxon, jes sorensen
In-Reply-To: <961848702.28655534.1499222431603.JavaMail.zimbra@redhat.com>
On 07/05/2017 10:40 AM, Xiao Ni wrote:
>
> ----- Original Message -----
>> From: "Guoqing Jiang" <gqjiang@suse.com>
>> To: "Xiao Ni" <xni@redhat.com>
>> Cc: linux-raid@vger.kernel.org, ncroxon@redhat.com, "jes sorensen" <jes.sorensen@gmail.com>
>> Sent: Wednesday, July 5, 2017 9:56:35 AM
>> Subject: Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
>>
>>
>>
>> On 07/04/2017 05:55 PM, Xiao Ni wrote:
>>> ----- Original Message -----
>>>> From: "Guoqing Jiang" <gqjiang@suse.com>
>>>> To: "Xiao Ni" <xni@redhat.com>, linux-raid@vger.kernel.org
>>>> Cc: ncroxon@redhat.com, "jes sorensen" <jes.sorensen@gmail.com>
>>>> Sent: Tuesday, July 4, 2017 5:03:30 PM
>>>> Subject: Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
>>>>
>>>>
>>>>
>>>> On 07/04/2017 02:50 PM, Xiao Ni wrote:
>>>>> The size of array shows wrongly. It shifs wrong number.
>>>>>
>>>>> Signed-off-by: Xiao Ni <xni@redhat.com>
>>>>> ---
>>>>> super1.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/super1.c b/super1.c
>>>>> index 86ec850..f3b864d 100644
>>>>> --- a/super1.c
>>>>> +++ b/super1.c
>>>>> @@ -366,7 +366,7 @@ static void examine_super1(struct supertype *st, char
>>>>> *homehost)
>>>>> }
>>>>> if (ddsks) {
>>>>> long long asize = __le64_to_cpu(sb->size);
>>>>> - asize = (asize << 9) * ddsks / ddsks_denom;
>>>>> + asize = (asize << 10) * ddsks / ddsks_denom;
>>>>> printf(" Array Size : %llu%s\n",
>>>>> asize >> 10, human_size(asize));
>>>>> }
>>>> IIRC, sb->size represents the num of sectors, so the shift should be 9.
>>> Yes, it should be 9. It should pass bytes to human_size. Thanks for this.
>>> It was introduced in d4633e06dfc01723911627fcb104af2ffb6f6a95. So there is
>>> the same problem in super0. Is it ok:
>>>
>>> diff --git a/super0.c b/super0.c
>>> index 756cab5..4b4680c 100644
>>> --- a/super0.c
>>> +++ b/super0.c
>>> @@ -131,9 +131,9 @@ static void examine_super0(struct supertype *st, char
>>> *homehost)
>>> }
>>> if (ddsks) {
>>> long long asize = sb->size;
>>> - asize = (asize << 10) * ddsks / ddsks_denom;
>>> + asize = (asize << 9) * ddsks / ddsks_denom;
>>> printf(" Array Size : %llu%s\n",
>>> - asize >> 10, human_size(asize));
>>> + asize >> 9, human_size(asize));
>>> }
>> No, for 0.9 metadata, sb->size means KB not sector.
>>
> Thanks for this.
>
>>> }
>>> printf(" Raid Devices : %d\n", sb->raid_disks);
>>> diff --git a/super1.c b/super1.c
>>> index 86ec850..2bb1454 100644
>>> --- a/super1.c
>>> +++ b/super1.c
>>> @@ -368,7 +368,7 @@ static void examine_super1(struct supertype *st, char
>>> *homehost)
>>> long long asize = __le64_to_cpu(sb->size);
>>> asize = (asize << 9) * ddsks / ddsks_denom;
>>> printf(" Array Size : %llu%s\n",
>>> - asize >> 10, human_size(asize));
>>> + asize >> 9, human_size(asize));
>>> }
>>> if (sb->size != sb->data_size)
>>> printf(" Used Dev Size : %llu%s\n",
>> It is better that you can provide the output of "mdadm -E DISK" etc to prove
>> current code is wrong, at least I can see correct output from my side.
> [root@dell-per210-01 mdadm]# mdadm -E /dev/loop0
> /dev/loop0:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 34f18365:ebf46416:ae1f365d:71cc579c
> Name : 0
> Creation Time : Tue Jul 4 02:09:03 2017
> Raid Level : raid5
> Raid Devices : 3
>
> Avail Dev Size : 8261632 (3.94 GiB 4.23 GB)
> Array Size : 6291456 (6.00 GiB 6.44 GB)
> Used Dev Size : 6291456 (3.00 GiB 3.22 GB)
>
> Ah, I know it wants to show Array Size in KB. It's a raid5 with 3 loop devices.
> I thought they are all sectors subconsciously. But it's better to show sizes with
> the same unit. Right?
Perhaps that is why the human_size is used here.
Thanks,
Guoqing
^ permalink raw reply
* Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
From: Xiao Ni @ 2017-07-05 2:40 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: linux-raid, ncroxon, jes sorensen
In-Reply-To: <03fe6bb9-714e-bebb-1bbe-63a9d6ccee69@suse.com>
----- Original Message -----
> From: "Guoqing Jiang" <gqjiang@suse.com>
> To: "Xiao Ni" <xni@redhat.com>
> Cc: linux-raid@vger.kernel.org, ncroxon@redhat.com, "jes sorensen" <jes.sorensen@gmail.com>
> Sent: Wednesday, July 5, 2017 9:56:35 AM
> Subject: Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
>
>
>
> On 07/04/2017 05:55 PM, Xiao Ni wrote:
> >
> > ----- Original Message -----
> >> From: "Guoqing Jiang" <gqjiang@suse.com>
> >> To: "Xiao Ni" <xni@redhat.com>, linux-raid@vger.kernel.org
> >> Cc: ncroxon@redhat.com, "jes sorensen" <jes.sorensen@gmail.com>
> >> Sent: Tuesday, July 4, 2017 5:03:30 PM
> >> Subject: Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
> >>
> >>
> >>
> >> On 07/04/2017 02:50 PM, Xiao Ni wrote:
> >>> The size of array shows wrongly. It shifs wrong number.
> >>>
> >>> Signed-off-by: Xiao Ni <xni@redhat.com>
> >>> ---
> >>> super1.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/super1.c b/super1.c
> >>> index 86ec850..f3b864d 100644
> >>> --- a/super1.c
> >>> +++ b/super1.c
> >>> @@ -366,7 +366,7 @@ static void examine_super1(struct supertype *st, char
> >>> *homehost)
> >>> }
> >>> if (ddsks) {
> >>> long long asize = __le64_to_cpu(sb->size);
> >>> - asize = (asize << 9) * ddsks / ddsks_denom;
> >>> + asize = (asize << 10) * ddsks / ddsks_denom;
> >>> printf(" Array Size : %llu%s\n",
> >>> asize >> 10, human_size(asize));
> >>> }
> >> IIRC, sb->size represents the num of sectors, so the shift should be 9.
> > Yes, it should be 9. It should pass bytes to human_size. Thanks for this.
> > It was introduced in d4633e06dfc01723911627fcb104af2ffb6f6a95. So there is
> > the same problem in super0. Is it ok:
> >
> > diff --git a/super0.c b/super0.c
> > index 756cab5..4b4680c 100644
> > --- a/super0.c
> > +++ b/super0.c
> > @@ -131,9 +131,9 @@ static void examine_super0(struct supertype *st, char
> > *homehost)
> > }
> > if (ddsks) {
> > long long asize = sb->size;
> > - asize = (asize << 10) * ddsks / ddsks_denom;
> > + asize = (asize << 9) * ddsks / ddsks_denom;
> > printf(" Array Size : %llu%s\n",
> > - asize >> 10, human_size(asize));
> > + asize >> 9, human_size(asize));
> > }
>
> No, for 0.9 metadata, sb->size means KB not sector.
>
Thanks for this.
> > }
> > printf(" Raid Devices : %d\n", sb->raid_disks);
> > diff --git a/super1.c b/super1.c
> > index 86ec850..2bb1454 100644
> > --- a/super1.c
> > +++ b/super1.c
> > @@ -368,7 +368,7 @@ static void examine_super1(struct supertype *st, char
> > *homehost)
> > long long asize = __le64_to_cpu(sb->size);
> > asize = (asize << 9) * ddsks / ddsks_denom;
> > printf(" Array Size : %llu%s\n",
> > - asize >> 10, human_size(asize));
> > + asize >> 9, human_size(asize));
> > }
> > if (sb->size != sb->data_size)
> > printf(" Used Dev Size : %llu%s\n",
>
> It is better that you can provide the output of "mdadm -E DISK" etc to prove
> current code is wrong, at least I can see correct output from my side.
[root@dell-per210-01 mdadm]# mdadm -E /dev/loop0
/dev/loop0:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 34f18365:ebf46416:ae1f365d:71cc579c
Name : 0
Creation Time : Tue Jul 4 02:09:03 2017
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 8261632 (3.94 GiB 4.23 GB)
Array Size : 6291456 (6.00 GiB 6.44 GB)
Used Dev Size : 6291456 (3.00 GiB 3.22 GB)
Ah, I know it wants to show Array Size in KB. It's a raid5 with 3 loop devices.
I thought they are all sectors subconsciously. But it's better to show sizes with
the same unit. Right?
Regards
Xiao
^ permalink raw reply
* Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
From: Guoqing Jiang @ 2017-07-05 1:56 UTC (permalink / raw)
To: Xiao Ni; +Cc: linux-raid, ncroxon, jes sorensen
In-Reply-To: <1330216631.28557919.1499162158000.JavaMail.zimbra@redhat.com>
On 07/04/2017 05:55 PM, Xiao Ni wrote:
>
> ----- Original Message -----
>> From: "Guoqing Jiang" <gqjiang@suse.com>
>> To: "Xiao Ni" <xni@redhat.com>, linux-raid@vger.kernel.org
>> Cc: ncroxon@redhat.com, "jes sorensen" <jes.sorensen@gmail.com>
>> Sent: Tuesday, July 4, 2017 5:03:30 PM
>> Subject: Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
>>
>>
>>
>> On 07/04/2017 02:50 PM, Xiao Ni wrote:
>>> The size of array shows wrongly. It shifs wrong number.
>>>
>>> Signed-off-by: Xiao Ni <xni@redhat.com>
>>> ---
>>> super1.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/super1.c b/super1.c
>>> index 86ec850..f3b864d 100644
>>> --- a/super1.c
>>> +++ b/super1.c
>>> @@ -366,7 +366,7 @@ static void examine_super1(struct supertype *st, char
>>> *homehost)
>>> }
>>> if (ddsks) {
>>> long long asize = __le64_to_cpu(sb->size);
>>> - asize = (asize << 9) * ddsks / ddsks_denom;
>>> + asize = (asize << 10) * ddsks / ddsks_denom;
>>> printf(" Array Size : %llu%s\n",
>>> asize >> 10, human_size(asize));
>>> }
>> IIRC, sb->size represents the num of sectors, so the shift should be 9.
> Yes, it should be 9. It should pass bytes to human_size. Thanks for this.
> It was introduced in d4633e06dfc01723911627fcb104af2ffb6f6a95. So there is
> the same problem in super0. Is it ok:
>
> diff --git a/super0.c b/super0.c
> index 756cab5..4b4680c 100644
> --- a/super0.c
> +++ b/super0.c
> @@ -131,9 +131,9 @@ static void examine_super0(struct supertype *st, char *homehost)
> }
> if (ddsks) {
> long long asize = sb->size;
> - asize = (asize << 10) * ddsks / ddsks_denom;
> + asize = (asize << 9) * ddsks / ddsks_denom;
> printf(" Array Size : %llu%s\n",
> - asize >> 10, human_size(asize));
> + asize >> 9, human_size(asize));
> }
No, for 0.9 metadata, sb->size means KB not sector.
> }
> printf(" Raid Devices : %d\n", sb->raid_disks);
> diff --git a/super1.c b/super1.c
> index 86ec850..2bb1454 100644
> --- a/super1.c
> +++ b/super1.c
> @@ -368,7 +368,7 @@ static void examine_super1(struct supertype *st, char *homehost)
> long long asize = __le64_to_cpu(sb->size);
> asize = (asize << 9) * ddsks / ddsks_denom;
> printf(" Array Size : %llu%s\n",
> - asize >> 10, human_size(asize));
> + asize >> 9, human_size(asize));
> }
> if (sb->size != sb->data_size)
> printf(" Used Dev Size : %llu%s\n",
It is better that you can provide the output of "mdadm -E DISK" etc to prove
current code is wrong, at least I can see correct output from my side.
Thanks,
Guoqing
^ permalink raw reply
* Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
From: Xiao Ni @ 2017-07-04 9:55 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: linux-raid, ncroxon, jes sorensen
In-Reply-To: <595B59E2.10407@suse.com>
----- Original Message -----
> From: "Guoqing Jiang" <gqjiang@suse.com>
> To: "Xiao Ni" <xni@redhat.com>, linux-raid@vger.kernel.org
> Cc: ncroxon@redhat.com, "jes sorensen" <jes.sorensen@gmail.com>
> Sent: Tuesday, July 4, 2017 5:03:30 PM
> Subject: Re: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
>
>
>
> On 07/04/2017 02:50 PM, Xiao Ni wrote:
> > The size of array shows wrongly. It shifs wrong number.
> >
> > Signed-off-by: Xiao Ni <xni@redhat.com>
> > ---
> > super1.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/super1.c b/super1.c
> > index 86ec850..f3b864d 100644
> > --- a/super1.c
> > +++ b/super1.c
> > @@ -366,7 +366,7 @@ static void examine_super1(struct supertype *st, char
> > *homehost)
> > }
> > if (ddsks) {
> > long long asize = __le64_to_cpu(sb->size);
> > - asize = (asize << 9) * ddsks / ddsks_denom;
> > + asize = (asize << 10) * ddsks / ddsks_denom;
> > printf(" Array Size : %llu%s\n",
> > asize >> 10, human_size(asize));
> > }
>
> IIRC, sb->size represents the num of sectors, so the shift should be 9.
Yes, it should be 9. It should pass bytes to human_size. Thanks for this.
It was introduced in d4633e06dfc01723911627fcb104af2ffb6f6a95. So there is
the same problem in super0. Is it ok:
diff --git a/super0.c b/super0.c
index 756cab5..4b4680c 100644
--- a/super0.c
+++ b/super0.c
@@ -131,9 +131,9 @@ static void examine_super0(struct supertype *st, char *homehost)
}
if (ddsks) {
long long asize = sb->size;
- asize = (asize << 10) * ddsks / ddsks_denom;
+ asize = (asize << 9) * ddsks / ddsks_denom;
printf(" Array Size : %llu%s\n",
- asize >> 10, human_size(asize));
+ asize >> 9, human_size(asize));
}
}
printf(" Raid Devices : %d\n", sb->raid_disks);
diff --git a/super1.c b/super1.c
index 86ec850..2bb1454 100644
--- a/super1.c
+++ b/super1.c
@@ -368,7 +368,7 @@ static void examine_super1(struct supertype *st, char *homehost)
long long asize = __le64_to_cpu(sb->size);
asize = (asize << 9) * ddsks / ddsks_denom;
printf(" Array Size : %llu%s\n",
- asize >> 10, human_size(asize));
+ asize >> 9, human_size(asize));
}
if (sb->size != sb->data_size)
printf(" Used Dev Size : %llu%s\n",
Regards
Xiao
>
> Thanks,
> Guoqing
> --
> 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: [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
From: Guoqing Jiang @ 2017-07-04 9:03 UTC (permalink / raw)
To: Xiao Ni, linux-raid; +Cc: ncroxon, jes.sorensen
In-Reply-To: <1499151006-7924-1-git-send-email-xni@redhat.com>
On 07/04/2017 02:50 PM, Xiao Ni wrote:
> The size of array shows wrongly. It shifs wrong number.
>
> Signed-off-by: Xiao Ni <xni@redhat.com>
> ---
> super1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/super1.c b/super1.c
> index 86ec850..f3b864d 100644
> --- a/super1.c
> +++ b/super1.c
> @@ -366,7 +366,7 @@ static void examine_super1(struct supertype *st, char *homehost)
> }
> if (ddsks) {
> long long asize = __le64_to_cpu(sb->size);
> - asize = (asize << 9) * ddsks / ddsks_denom;
> + asize = (asize << 10) * ddsks / ddsks_denom;
> printf(" Array Size : %llu%s\n",
> asize >> 10, human_size(asize));
> }
IIRC, sb->size represents the num of sectors, so the shift should be 9.
Thanks,
Guoqing
^ permalink raw reply
* (unknown),
From: citydesk @ 2017-07-04 8:52 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: EMAIL_77904176_linux-raid.zip --]
[-- Type: application/zip, Size: 3164 bytes --]
^ permalink raw reply
* [MDADM PATCH 1/1] Array size is wrong when run mdadm -E
From: Xiao Ni @ 2017-07-04 6:50 UTC (permalink / raw)
To: linux-raid; +Cc: ncroxon, jes.sorensen
The size of array shows wrongly. It shifs wrong number.
Signed-off-by: Xiao Ni <xni@redhat.com>
---
super1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/super1.c b/super1.c
index 86ec850..f3b864d 100644
--- a/super1.c
+++ b/super1.c
@@ -366,7 +366,7 @@ static void examine_super1(struct supertype *st, char *homehost)
}
if (ddsks) {
long long asize = __le64_to_cpu(sb->size);
- asize = (asize << 9) * ddsks / ddsks_denom;
+ asize = (asize << 10) * ddsks / ddsks_denom;
printf(" Array Size : %llu%s\n",
asize >> 10, human_size(asize));
}
--
2.7.4
^ permalink raw reply related
* [MD PATCH 1/1] Raid5 should update rdev->sectors after reshape
From: Xiao Ni @ 2017-07-04 6:29 UTC (permalink / raw)
To: linux-raid; +Cc: ncroxon, tbskyd, shli
The raid5 md device is created by the disks which we don't use the total size. For example,
the size of the device is 5G and it just uses 3G of the devices to create one raid5 device.
Then change the chunksize and wait reshape to finish. After reshape finishing stop the raid
and assemble it again. It fails.
mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --size=3G --chunk=32 --assume-clean
mdadm /dev/md0 --grow --chunk=64
wait reshape to finish
mdadm -S /dev/md0
mdadm -As
The error messages:
[197519.814302] md: loop1 does not have a valid v1.2 superblock, not importing!
[197519.821686] md: md_import_device returned -22
After reshape the data offset is changed. It selects backwards direction in this condition.
In function super_1_load it compares the available space of the underlying device with
sb->data_size. The new data offset gets bigger after reshape. So super_1_load returns -EINVAL.
sb->data_size is updated in md_finish_reshape. So add md_finish_reshape in end_reshape.
Signed-off-by: Xiao Ni <xni@redhat.com>
---
drivers/md/raid5.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index ec0f951..e7f527c 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -7947,12 +7947,10 @@ static void end_reshape(struct r5conf *conf)
{
if (!test_bit(MD_RECOVERY_INTR, &conf->mddev->recovery)) {
- struct md_rdev *rdev;
spin_lock_irq(&conf->device_lock);
conf->previous_raid_disks = conf->raid_disks;
- rdev_for_each(rdev, conf->mddev)
- rdev->data_offset = rdev->new_data_offset;
+ md_finish_reshape(conf->mddev);
smp_wmb();
conf->reshape_progress = MaxSector;
conf->mddev->reshape_position = MaxSector;
--
2.7.4
^ permalink raw reply related
* (unknown),
From: xa0ajutor @ 2017-07-04 6:01 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: EMAIL_56923235589997_linux-raid.zip --]
[-- Type: application/zip, Size: 3176 bytes --]
^ 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