[PATCH] mdadm.8: Disk coercion with IMSM metadata.

RnJvbTogbWFjaWVqLm5hcnVzemV3aWN6IDxtYWNpZWoubmFydXN6ZXdpY3pA aW50ZWwuY29tPgoK
QWN0dWFsIHNpemVzIG9mIGRpc2tzIGZyb20gZGlmZmVyZW50IHByb2R1Y2Vy cyBtYXkgdmFyeSwK
ZXZlbiB0aG91Z2ggdGhleSBhcmUgY2xhaW1lZCB0byBoYXZlIHRoZSBzYW1l IGFtb3VudCBvZgpz
cGFjZS4gU2luY2UgY3JlYXRpbmcgYXJyYXlzIHVzaW5nIElNU00gbWV0YWRh dGEgZG9lc24ndApz
dXBwb3J0IHJlc2l6aW5nIGFycmF5cyB5ZXQsIHRoZXJlIG1pZ2h0IGJlIHBy b2JsZW1zIHdoZW4K
cmVwbGFjaW5nIGEgZGlzayB3aXRoIGEgc2xpZ2h0bHkgc21hbGxlciBvbmUu CgpGb3IgdGhlIHRp
bWUgYmVpbmcsIGRpc2sgY29lcmNpb24gd2lsbCBub3QgYmUgaW1wbGVtZW50 ZWQKZm9yIElNU00s
IGhvd2V2ZXIgaXQgd291bGQgYmUgYSBnb29kIGlkZWEgdG8gaW5mb3JtIHRo ZQp1c2VyIGhvdyB0
byBkZWFsIHdpdGggaXQuIE91ciBzdWdnZXN0aW9uIGlzIHRvIG1lbnRpb24g aXQKaW4gdGhlIG1h
bnVhbCBwYWdlIHVuZGVyIHRoZSAteiBvcHRpb24gYW5kIGFkdmlzZSB0aGUg dXNlcgp0byBjcmVh
dGUgYXJyYXlzIHVzaW5nIGEgbGl0dGxlIGxlc3Mgc3BhY2UgdGhhbiB0aGUg ZGlza3MKaGF2ZS4K
CkFkZGl0aW9uYWxseSwgdGhlIHBhcnQgJ1RoaXMgdmFsdWUgY2FuIG5vdCBi ZSB1c2VkCndpdGgg
Q09OVEFJTkVSIG1ldGFkYXRhIHN1Y2ggYXMgRERGIGFuZCBJTVNNLicgd2Fz IG5vdApjbGVhciBh
bmQgd2FzIHJlcGxhY2VkLgoKU2lnbmVkLW9mZi1ieTogbWFjaWVqLm5hcnVz emV3aWN6IDxtYWNp
ZWoubmFydXN6ZXdpY3pAaW50ZWwuY29tPgotLS0KIG1kYWRtLjguaW4gfCAg IDEzICsrKysrKysr
KystLS0KIDEgZmlsZXMgY2hhbmdlZCwgMTAgaW5zZXJ0aW9ucygrKSwgMyBk ZWxldGlvbnMoLSkK
CmRpZmYgLS1naXQgYS9tZGFkbS44LmluIGIvbWRhZG0uOC5pbgppbmRleCA3 ZTg5ODFlLi4yNjkw
ZTJkIDEwMDY0NAotLS0gYS9tZGFkbS44LmluCisrKyBiL21kYWRtLjguaW4K QEAgLTQ0MCw5ICs0
NDAsMTYgQEAgcHJvYmxlbXMgdGhlIGFycmF5IGNhbiBiZSBtYWRlIGJpZ2dl ciBhZ2FpbiB3aXRo
IG5vIGxvc3Mgd2l0aCBhbm90aGVyCiAuQiAiXC1cLWdyb3cgXC1cLXNpemU9 IgogY29tbWFuZC4K
IAotVGhpcyB2YWx1ZSBjYW4gbm90IGJlIHVzZWQgd2l0aAotLkIgQ09OVEFJ TkVSCi1tZXRhZGF0
YSBzdWNoIGFzIERERiBhbmQgSU1TTS4KK0FjdHVhbCBzaXplcyBvZiBkaXNr cyBmcm9tIGRpZmZl
cmVudCBtYW51ZmFjdHVyZXJzIG1heSBzbGlnaHRseSBkaWZmZXIsIGV2ZW4g aWYKK3RoZXkgYXJl
IHNhaWQgdG8gaGF2ZSB0aGUgc2FtZSBhbW91bnQgb2Ygc3BhY2UuIENoYW5n aW5nIGFycmF5J3Mg
c2l6ZSB3aXRoIHRoZSAKKy5CICJcLVwtZ3JvdyBcLVwtc2l6ZT0iCitjb21t YW5kIGlzIG5vdCBz
dXBwb3J0ZWQgeWV0IGJ5IGV4dGVybmFsIG1ldGFkYXRhcyBzdWNoIGFzIERE RiBhbmQgSU1TTS4g
Q3JlYXRpbmcgUkFJRAorYXJyYXlzIHdpdGggdGhlCisuQiBcLXoKK29wdGlv biBpcyBhZHZpc2Vk
IHNvIHRoYXQgdGhlIGFycmF5J3Mgc2l6ZSBpcyBhIGJpdCBzbWFsbGVyIHRo YW4gdGhlIGFjdHVh
bCBtYXhpbXVtCithdmFpbGFibGUgZGF0YSBkaXNrJ3Mgc2l6ZS4gT3RoZXJ3 aXNlLCByZXBsYWNp
bmcgYSBkaXNrIGluIGFuIGFycmF5IHdpdGggdGhlICdzYW1lJworZGlzayBm cm9tIGEgZGlmZmVy
ZW50IG1hbnVmYWN0dXJlciBpcyBub3QgZ3VhcmFudGVlZCB0byBiZSBhbHdh eXMgcG9zc2libGUg
ZHVlIHRvCitkaWZmZXJlbmNlIGluIGRldmljZSBzaXplcy4gCiAKIC5UUAog LkJSIFwtWiAiLCAi
IFwtXC1hcnJheVwtc2l6ZT0KCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpJbnRlbCBUZWNobm9s b2d5IFBvbGFuZCBz
cC4geiBvLm8uCnogc2llZHppYmEgdyBHZGFuc2t1CnVsLiBTbG93YWNraWVn byAxNzMKODAtMjk4
IEdkYW5zawoKU2FkIFJlam9ub3d5IEdkYW5zayBQb2xub2MgdyBHZGFuc2t1 LCAKVklJIFd5ZHpp
YWwgR29zcG9kYXJjenkgS3Jham93ZWdvIFJlamVzdHJ1IFNhZG93ZWdvLCAK bnVtZXIgS1JTIDEw
MTg4MgoKTklQIDk1Ny0wNy01Mi0zMTYKS2FwaXRhbCB6YWtsYWRvd3kgMjAw LjAwMCB6bAoKVGhp
cyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgbWF0
ZXJpYWwgZm9yCnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50KHMpLiBBbnkg
cmV2aWV3IG9yIGRpc3RyaWJ1dGlvbgpieSBvdGhlcnMgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4g
SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCwgcGxlYXNl IGNvbnRhY3QgdGhl
IHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuCg==

--
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

Re: [PATCH] mdadm.8: Disk coercion with IMSM metadata.

On Wed, 13 Jul 2011 12:17:02 +0200 "maciej.naruszewicz"
wrote:

> From: maciej.naruszewicz
>
> Actual sizes of disks from different producers may vary,
> even though they are claimed to have the same amount of
> space

Are you sure about this?

It was my understanding that some industry association has arranged an
agreement so that this does not happen.

http://www.idema.org/wp-content/plugins/download-monitor/dow nload.php?id=1223

Do you have actual evidence that different drives from different
manufacturers have similar but not identical sizes?

NeilBrown




> Since creating arrays using IMSM metadata doesn't
> support resizing arrays yet, there might be problems when
> replacing a disk with a slightly smaller one.
>
> For the time being, disk coercion will not be implemented
> for IMSM, however it would be a good idea to inform the
> user how to deal with it. Our suggestion is to mention it
> in the manual page under the -z option and advise the user
> to create arrays using a little less space than the disks
> have.
>
> Additionally, the part 'This value can not be used
> with CONTAINER metadata such as DDF and IMSM.' was not
> clear and was replaced.
>
> Signed-off-by: maciej.naruszewicz
> ---
> mdadm.8.in | 13 ++++++++++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/mdadm.8.in b/mdadm.8.in
> index 7e8981e..2690e2d 100644
> --- a/mdadm.8.in
> +++ b/mdadm.8.in
> @@ -440,9 +440,16 @@ problems the array can be made bigger again with no loss with another
> .B "\-\-grow \-\-size="
> command.
>
> -This value can not be used with
> -.B CONTAINER
> -metadata such as DDF and IMSM.
> +Actual sizes of disks from different manufacturers may slightly differ, even if
> +they are said to have the same amount of space. Changing array's size with the
> +.B "\-\-grow \-\-size="
> +command is not supported yet by external metadatas such as DDF and IMSM. Creating RAID
> +arrays with the
> +.B \-z
> +option is advised so that the array's size is a bit smaller than the actual maximum
> +available data disk's size. Otherwise, replacing a disk in an array with the 'same'
> +disk from a different manufacturer is not guaranteed to be always possible due to
> +difference in device sizes.
>
> .TP
> .BR \-Z ", " \-\-array\-size=
>
> ------------------------------------------------------------ ---------
> Intel Technology Poland sp. z o.o.
> z siedziba w Gdansku
> ul. Slowackiego 173
> 80-298 Gdansk
>
> Sad Rejonowy Gdansk Polnoc w Gdansku,
> VII Wydzial Gospodarczy Krajowego Rejestru Sadowego,
> numer KRS 101882
>
> NIP 957-07-52-316
> Kapital zakladowy 200.000 zl
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

--
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

Re: [PATCH] mdadm.8: Disk coercion with IMSM metadata.

On Wed, Jul 13, 2011 at 7:26 PM, NeilBrown wrote:
> On Wed, 13 Jul 2011 12:17:02 +0200 "maciej.naruszewicz"
> wrote:
>
>> From: maciej.naruszewicz
>>
>> Actual sizes of disks from different producers may vary,
>> even though they are claimed to have the same amount of
>> space
>
> Are you sure about this?
>
> It was my understanding that some industry association has arranged an
> agreement so that this does not happen.
>
> http://www.idema.org/wp-content/plugins/download-monitor/dow nload.php?id=1223
>
> Do you have actual evidence that different drives from different
> manufacturers have similar but not identical sizes?
>

Hmm, seemed to be a case that needed handling when requirements were
being gathered, but perhaps recent drives don't do this any more?

Probably the more important part of this commit is that the man page
currently says that --size can not be used with container metadata...
but now that I have taken two seconds to think about it the light bulb
goes off...

--size is indeed irrelevant for:
mdadm --create /dev/md/imsm /dev/sd[a-d] -e imsm

but my first reading of comment was that:
mdadm --create /dev/md/vol0 /dev/md/imsm --size=$size
....is somehow not valid.

How about something like "For CONTAINER metadata --size is valid when
creating and growing subarrays, when creating a new container set
--size is irrelevant"

--
Dan
--
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

RE: [PATCH] mdadm.8: Disk coercion with IMSM metadata.

> -----Original Message-----
> From: dan.j.williams@gmail.com [mailto:dan.j.williams@gmail.com] On Behalf Of Dan Williams
> Sent: Saturday, July 16, 2011 3:10 AM
> To: NeilBrown
> Cc: Naruszewicz, Maciej; Neubauer, Wojciech; Kwolek, Adam; Wojcik, Krzysztof; Ciechanowski, Ed; linux-raid@vger.kernel.org
> Subject: Re: [PATCH] mdadm.8: Disk coercion with IMSM metadata.
>
> On Wed, Jul 13, 2011 at 7:26 PM, NeilBrown wrote:
>> On Wed, 13 Jul 2011 12:17:02 +0200 "maciej.naruszewicz"
>> wrote:
>>
>>> From: maciej.naruszewicz
>>>
>>> Actual sizes of disks from different producers may vary,
>>> even though they are claimed to have the same amount of
>>> space
>>
>> Are you sure about this?
>>
>> It was my understanding that some industry association has arranged an
>> agreement so that this does not happen.
>>
>> http://www.idema.org/wp-content/plugins/download-monitor/dow nload.php?id=1223
>>
>> Do you have actual evidence that different drives from different
>> manufacturers have similar but not identical sizes?
>>
>
> Hmm, seemed to be a case that needed handling when requirements were
> being gathered, but perhaps recent drives don't do this any more?
>
> Probably the more important part of this commit is that the man page
> currently says that --size can not be used with container metadata...
> but now that I have taken two seconds to think about it the light bulb
> goes off...
>
> --size is indeed irrelevant for:
> mdadm --create /dev/md/imsm /dev/sd[a-d] -e imsm
>
> but my first reading of comment was that:
> mdadm --create /dev/md/vol0 /dev/md/imsm --size=$size
> ...is somehow not valid.
>
> How about something like "For CONTAINER metadata --size is valid when
> creating and growing subarrays, when creating a new container set
> --size is irrelevant"
>
> --
> Dan


>
> Do you have actual evidence that different drives from different
> manufacturers have similar but not identical sizes?
>

I'm afraid I do... For instance I have two disks, first one from Western Digital (model WDC WD2500YS-01SHB1), the second one from Seagate (model ST3250410AS). Both are said to have 250 GB maximum data space- however, the OS doesn't agree. LBA count for WD is 490234752, while for ST it's 488397168- that makes 251000193024 against 250059350016 bytes, nearly 1GB of difference!

I'm not sure when those disks were produced- maybe newest disks are manufactured according to the IDEMA standard, but this example shows that there definitely are differences.

>
> How about something like "For CONTAINER metadata --size is valid when
> creating and growing subarrays, when creating a new container set
> --size is irrelevant"
>

Indeed, the --size option is irrelevant for containers and valid for subarrays in the container; however, the manpage stated: "This value cannot be used with .B CONTAINER metadata such as DDF and IMSM.". By "this", the author meant that "--grow --size" cannot be used, he / she didn't mean the "--size" alone. This sentence is deleted in the patch I sent earlier and explained more clearly in its description. Of course, we could add the information Dan mentioned to make it even more understandable.

Best wishes
Maciek

____________________________________________________________ ___________________

Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku,
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego,
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl
--
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

Re: [PATCH] mdadm.8: Disk coercion with IMSM metadata.

On Wed, 20 Jul 2011 13:54:17 +0100 "Naruszewicz, Maciej"
wrote:

> > -----Original Message-----
> > From: dan.j.williams@gmail.com [mailto:dan.j.williams@gmail.com] On Behalf Of Dan Williams
> > Sent: Saturday, July 16, 2011 3:10 AM
> > To: NeilBrown
> > Cc: Naruszewicz, Maciej; Neubauer, Wojciech; Kwolek, Adam; Wojcik, Krzysztof; Ciechanowski, Ed; linux-raid@vger.kernel.org
> > Subject: Re: [PATCH] mdadm.8: Disk coercion with IMSM metadata.
> >
> > On Wed, Jul 13, 2011 at 7:26 PM, NeilBrown wrote:
> >> On Wed, 13 Jul 2011 12:17:02 +0200 "maciej.naruszewicz"
> >> wrote:
> >>
> >>> From: maciej.naruszewicz
> >>>
> >>> Actual sizes of disks from different producers may vary,
> >>> even though they are claimed to have the same amount of
> >>> space
> >>
> >> Are you sure about this?
> >>
> >> It was my understanding that some industry association has arranged an
> >> agreement so that this does not happen.
> >>
> >> http://www.idema.org/wp-content/plugins/download-monitor/dow nload.php?id=1223
> >>
> >> Do you have actual evidence that different drives from different
> >> manufacturers have similar but not identical sizes?
> >>
> >
> > Hmm, seemed to be a case that needed handling when requirements were
> > being gathered, but perhaps recent drives don't do this any more?
> >
> > Probably the more important part of this commit is that the man page
> > currently says that --size can not be used with container metadata...
> > but now that I have taken two seconds to think about it the light bulb
> > goes off...
> >
> > --size is indeed irrelevant for:
> > mdadm --create /dev/md/imsm /dev/sd[a-d] -e imsm
> >
> > but my first reading of comment was that:
> > mdadm --create /dev/md/vol0 /dev/md/imsm --size=$size
> > ...is somehow not valid.
> >
> > How about something like "For CONTAINER metadata --size is valid when
> > creating and growing subarrays, when creating a new container set
> > --size is irrelevant"
> >
> > --
> > Dan
>
>
> >
> > Do you have actual evidence that different drives from different
> > manufacturers have similar but not identical sizes?
> >
>
> I'm afraid I do... For instance I have two disks, first one from Western Digital (model WDC WD2500YS-01SHB1), the second one from Seagate (model ST3250410AS). Both are said to have 250 GB maximum data space- however, the OS doesn't agree. LBA count for WD is 490234752, while for ST it's 488397168- that makes 251000193024 against 250059350016 bytes, nearly 1GB of difference!
>
> I'm not sure when those disks were produced- maybe newest disks are manufactured according to the IDEMA standard, but this example shows that there definitely are differences.
>
> >
> > How about something like "For CONTAINER metadata --size is valid when
> > creating and growing subarrays, when creating a new container set
> > --size is irrelevant"
> >
>
> Indeed, the --size option is irrelevant for containers and valid for subarrays in the container; however, the manpage stated: "This value cannot be used with .B CONTAINER metadata such as DDF and IMSM.". By "this", the author meant that "--grow --size" cannot be used, he / she didn't mean the "--size" alone. This sentence is deleted in the patch I sent earlier and explained more clearly in its description. Of course, we could add the information Dan mentioned to make it even more understandable.

I have applied the following. I hope it addresses all the issues.

NeilBrown


From 0e1ebe1ada6d7ad30a365443b2c80f64f0b23038 Mon Sep 17 00:00:00 2001
From: NeilBrown
Date: Tue, 26 Jul 2011 15:14:09 +1000
Subject: [PATCH] mdadm.8.in: clarify some issues with --size

- explain it's use in guarding against small replacements
- clarify relationship with containers.

Reported-by: maciej.naruszewicz
Signed-off-by: NeilBrown

diff --git a/mdadm.8.in b/mdadm.8.in
index 7e8981e..f7b2e9a 100644
--- a/mdadm.8.in
+++ b/mdadm.8.in
@@ -418,6 +418,14 @@ issued.
A suffix of 'M' or 'G' can be given to indicate Megabytes or
Gigabytes respectively.

+Sometimes a replacement drive can be a little smaller than the
+original drives though this should be minimised by IDEMA standards.
+Such a replacement drive will be rejected by
+.IR md .
+To guard against this it can be useful to set the initial size
+slightly smaller than the smaller device with the aim that it will
+still be larger than any replacement.
+
This value can be set with
.B \-\-grow
for RAID level 1/4/5/6. If the array was created with a size smaller
@@ -440,9 +448,10 @@ problems the array can be made bigger again with no loss with another
.B "\-\-grow \-\-size="
command.

-This value can not be used with
+This value can not be used when creating a
.B CONTAINER
-metadata such as DDF and IMSM.
+such as with DDF and IMSM metadata, though it perfectly valid when
+creating an array inside a container.

.TP
.BR \-Z ", " \-\-array\-size=

--
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