All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH mdadm] super1: report truncated device
@ 2022-07-12  1:00 NeilBrown
       [not found] ` <cff69e79-d681-c9d6-c719-8b10999a558a@molgen.mpg.de>
  0 siblings, 1 reply; 13+ messages in thread
From: NeilBrown @ 2022-07-12  1:00 UTC (permalink / raw)
  To: Jes Sorensen; +Cc: linux-raid


When the metadata is at the start of the device, it is possible that it
describes a device large than the one it is actually stored on.  When
this happens, report it loudly in --examine.

Also report in --assemble so that the failure which the kernel will
report will be explained.

Signed-off-by: NeilBrown <neilb@suse.de>
---
 super1.c | 34 +++++++++++++++++++++++++++-------
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/super1.c b/super1.c
index 71af860c0e3e..4d8dba8a5a44 100644
--- a/super1.c
+++ b/super1.c
@@ -406,12 +406,18 @@ static void examine_super1(struct supertype *st, char *homehost)
 
 	st->ss->getinfo_super(st, &info, NULL);
 	if (info.space_after != 1 &&
-	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET))
-		printf("   Unused Space : before=%llu sectors, after=%llu sectors\n",
-		       info.space_before, info.space_after);
-
-	printf("          State : %s\n",
-	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean");
+	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET)) {
+		printf("   Unused Space : before=%llu sectors, ",
+		       info.space_before);
+		if (info.space_after < INT64_MAX)
+			printf("after=%llu sectors\n", info.space_after);
+		else
+			printf("after=-%llu sectors DEVICE TOO SMALL\n",
+			       UINT64_MAX - info.space_after);
+	}
+	printf("          State : %s%s\n",
+	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean",
+	       info.space_after > INT64_MAX ? " TRUNCATED DEVICE" : "");
 	printf("    Device UUID : ");
 	for (i=0; i<16; i++) {
 		if ((i&3)==0 && i != 0)
@@ -2206,6 +2212,7 @@ static int load_super1(struct supertype *st, int fd, char *devname)
 		tst.ss = &super1;
 		for (tst.minor_version = 0; tst.minor_version <= 2;
 		     tst.minor_version++) {
+			tst.ignore_hw_compat = st->ignore_hw_compat;
 			switch(load_super1(&tst, fd, devname)) {
 			case 0: super = tst.sb;
 				if (bestvers == -1 ||
@@ -2312,7 +2319,6 @@ static int load_super1(struct supertype *st, int fd, char *devname)
 		free(super);
 		return 2;
 	}
-	st->sb = super;
 
 	bsb = (struct bitmap_super_s *)(((char*)super)+MAX_SB_SIZE);
 
@@ -2322,6 +2328,20 @@ static int load_super1(struct supertype *st, int fd, char *devname)
 	if (st->data_offset == INVALID_SECTORS)
 		st->data_offset = __le64_to_cpu(super->data_offset);
 
+	if (st->minor_version >= 1 &&
+	    st->ignore_hw_compat == 0 &&
+	    (__le64_to_cpu(super->data_offset) +
+	     __le64_to_cpu(super->size) > dsize ||
+	     __le64_to_cpu(super->data_offset) +
+	     __le64_to_cpu(super->data_size) > dsize)) {
+		if (devname)
+			pr_err("Device %s is not large enough for data described in superblock\n",
+			       devname);
+		free(super);
+		return 2;
+	}
+	st->sb = super;
+
 	/* Now check on the bitmap superblock */
 	if ((__le32_to_cpu(super->feature_map)&MD_FEATURE_BITMAP_OFFSET) == 0)
 		return 0;
-- 
2.36.1


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH mdadm v2] super1: report truncated device
       [not found] ` <cff69e79-d681-c9d6-c719-8b10999a558a@molgen.mpg.de>
@ 2022-07-13  3:48   ` NeilBrown
  2022-07-21  8:19     ` Mariusz Tkaczyk
  0 siblings, 1 reply; 13+ messages in thread
From: NeilBrown @ 2022-07-13  3:48 UTC (permalink / raw)
  To: Paul Menzel, Jes Sorensen; +Cc: linux-raid


When the metadata is at the start of the device, it is possible that it
describes a device large than the one it is actually stored on.  When
this happens, report it loudly in --examine.

....
   Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
          State : clean TRUNCATED DEVICE
....

Also report in --assemble so that the failure which the kernel will
report will be explained.

mdadm: Device /dev/sdb is not large enough for data described in superblock
mdadm: no RAID superblock on /dev/sdb
mdadm: /dev/sdb has no superblock - assembly aborted

Scenario can be demonstrated as follows:

mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md/test started.
mdadm: stopped /dev/md/test
   Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
          State : clean TRUNCATED DEVICE
   Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
          State : clean TRUNCATED DEVICE

Signed-off-by: NeilBrown <neilb@suse.de>
---
 super1.c | 34 +++++++++++++++++++++++++++-------
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/super1.c b/super1.c
index 71af860c0e3e..4d8dba8a5a44 100644
--- a/super1.c
+++ b/super1.c
@@ -406,12 +406,18 @@ static void examine_super1(struct supertype *st, char *homehost)
 
 	st->ss->getinfo_super(st, &info, NULL);
 	if (info.space_after != 1 &&
-	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET))
-		printf("   Unused Space : before=%llu sectors, after=%llu sectors\n",
-		       info.space_before, info.space_after);
-
-	printf("          State : %s\n",
-	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean");
+	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET)) {
+		printf("   Unused Space : before=%llu sectors, ",
+		       info.space_before);
+		if (info.space_after < INT64_MAX)
+			printf("after=%llu sectors\n", info.space_after);
+		else
+			printf("after=-%llu sectors DEVICE TOO SMALL\n",
+			       UINT64_MAX - info.space_after);
+	}
+	printf("          State : %s%s\n",
+	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean",
+	       info.space_after > INT64_MAX ? " TRUNCATED DEVICE" : "");
 	printf("    Device UUID : ");
 	for (i=0; i<16; i++) {
 		if ((i&3)==0 && i != 0)
@@ -2206,6 +2212,7 @@ static int load_super1(struct supertype *st, int fd, char *devname)
 		tst.ss = &super1;
 		for (tst.minor_version = 0; tst.minor_version <= 2;
 		     tst.minor_version++) {
+			tst.ignore_hw_compat = st->ignore_hw_compat;
 			switch(load_super1(&tst, fd, devname)) {
 			case 0: super = tst.sb;
 				if (bestvers == -1 ||
@@ -2312,7 +2319,6 @@ static int load_super1(struct supertype *st, int fd, char *devname)
 		free(super);
 		return 2;
 	}
-	st->sb = super;
 
 	bsb = (struct bitmap_super_s *)(((char*)super)+MAX_SB_SIZE);
 
@@ -2322,6 +2328,20 @@ static int load_super1(struct supertype *st, int fd, char *devname)
 	if (st->data_offset == INVALID_SECTORS)
 		st->data_offset = __le64_to_cpu(super->data_offset);
 
+	if (st->minor_version >= 1 &&
+	    st->ignore_hw_compat == 0 &&
+	    (__le64_to_cpu(super->data_offset) +
+	     __le64_to_cpu(super->size) > dsize ||
+	     __le64_to_cpu(super->data_offset) +
+	     __le64_to_cpu(super->data_size) > dsize)) {
+		if (devname)
+			pr_err("Device %s is not large enough for data described in superblock\n",
+			       devname);
+		free(super);
+		return 2;
+	}
+	st->sb = super;
+
 	/* Now check on the bitmap superblock */
 	if ((__le32_to_cpu(super->feature_map)&MD_FEATURE_BITMAP_OFFSET) == 0)
 		return 0;
-- 
2.36.1


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH mdadm v2] super1: report truncated device
  2022-07-13  3:48   ` [PATCH mdadm v2] " NeilBrown
@ 2022-07-21  8:19     ` Mariusz Tkaczyk
  2022-07-21 16:21       ` Ternary Operator (was: [PATCH mdadm v2] super1: report truncated device) Paul Menzel
  2022-07-23  4:37       ` [PATCH mdadm v2] super1: report truncated device NeilBrown
  0 siblings, 2 replies; 13+ messages in thread
From: Mariusz Tkaczyk @ 2022-07-21  8:19 UTC (permalink / raw)
  To: NeilBrown; +Cc: Paul Menzel, Jes Sorensen, linux-raid

Hi Neil,

On Wed, 13 Jul 2022 13:48:11 +1000
"NeilBrown" <neilb@suse.de> wrote:

> When the metadata is at the start of the device, it is possible that it
> describes a device large than the one it is actually stored on.  When
> this happens, report it loudly in --examine.
> 
> ....
>    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
>           State : clean TRUNCATED DEVICE
> ....

State : clean TRUNCATED DEVICE is enough. "DEVICE TOO SMALL" seems to be
redundant.
> 
> Also report in --assemble so that the failure which the kernel will
> report will be explained.

Understand but you've added it in load_super1() so it affects all load_super()
calls, is it indented? I assume yes but please confirm. 
> 
> mdadm: Device /dev/sdb is not large enough for data described in superblock
> mdadm: no RAID superblock on /dev/sdb
> mdadm: /dev/sdb has no superblock - assembly aborted
> 
> Scenario can be demonstrated as follows:
> 
> mdadm: Note: this array has metadata at the start and
>     may not be suitable as a boot device.  If you plan to
>     store '/boot' on this device please ensure that
>     your boot-loader understands md/v1.x metadata, or use
>     --metadata=0.90
> mdadm: Defaulting to version 1.2 metadata
> mdadm: array /dev/md/test started.
> mdadm: stopped /dev/md/test
>    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
>           State : clean TRUNCATED DEVICE
>    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
>           State : clean TRUNCATED DEVICE
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
>  super1.c | 34 +++++++++++++++++++++++++++-------
>  1 file changed, 27 insertions(+), 7 deletions(-)
> 
> diff --git a/super1.c b/super1.c
> index 71af860c0e3e..4d8dba8a5a44 100644
> --- a/super1.c
> +++ b/super1.c
> @@ -406,12 +406,18 @@ static void examine_super1(struct supertype *st, char
> *homehost) 
>  	st->ss->getinfo_super(st, &info, NULL);
>  	if (info.space_after != 1 &&
> -	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET))
> -		printf("   Unused Space : before=%llu sectors, after=%llu
> sectors\n",
> -		       info.space_before, info.space_after);
> -
> -	printf("          State : %s\n",
> -	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean");
> +	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET)) {
> +		printf("   Unused Space : before=%llu sectors, ",
> +		       info.space_before);
> +		if (info.space_after < INT64_MAX)
> +			printf("after=%llu sectors\n", info.space_after);
> +		else
> +			printf("after=-%llu sectors DEVICE TOO SMALL\n",
> +			       UINT64_MAX - info.space_after);
As above, for me this else here is not necessary.

> +	}
> +	printf("          State : %s%s\n",
> +	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean",
> +	       info.space_after > INT64_MAX ? " TRUNCATED DEVICE" : "");

Could you use standard if instruction to make the code more readable? We are
avoiding ternary operators if possible now.

>  	printf("    Device UUID : ");
>  	for (i=0; i<16; i++) {
>  		if ((i&3)==0 && i != 0)
> @@ -2206,6 +2212,7 @@ static int load_super1(struct supertype *st, int fd,
> char *devname) tst.ss = &super1;
>  		for (tst.minor_version = 0; tst.minor_version <= 2;
>  		     tst.minor_version++) {
> +			tst.ignore_hw_compat = st->ignore_hw_compat;
>  			switch(load_super1(&tst, fd, devname)) {
>  			case 0: super = tst.sb;
>  				if (bestvers == -1 ||
> @@ -2312,7 +2319,6 @@ static int load_super1(struct supertype *st, int fd,
> char *devname) free(super);
>  		return 2;
>  	}
> -	st->sb = super;
>  
>  	bsb = (struct bitmap_super_s *)(((char*)super)+MAX_SB_SIZE);
>  
> @@ -2322,6 +2328,20 @@ static int load_super1(struct supertype *st, int fd,
> char *devname) if (st->data_offset == INVALID_SECTORS)
>  		st->data_offset = __le64_to_cpu(super->data_offset);
>  
> +	if (st->minor_version >= 1 &&
> +	    st->ignore_hw_compat == 0 &&
> +	    (__le64_to_cpu(super->data_offset) +
> +	     __le64_to_cpu(super->size) > dsize ||
> +	     __le64_to_cpu(super->data_offset) +
> +	     __le64_to_cpu(super->data_size) > dsize)) {
> +		if (devname)
> +			pr_err("Device %s is not large enough for data
> described in superblock\n",
> +			       devname);

why not just:
if (__le64_to_cpu(super->data_offset) + __le64_to_cpu(super->data_size) > dsize)
from my understanding, only this check matters.

Thanks,
Mariusz


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Ternary Operator (was: [PATCH mdadm v2] super1: report truncated device)
  2022-07-21  8:19     ` Mariusz Tkaczyk
@ 2022-07-21 16:21       ` Paul Menzel
  2022-07-22  6:55         ` Mariusz Tkaczyk
  2022-07-23  4:37       ` [PATCH mdadm v2] super1: report truncated device NeilBrown
  1 sibling, 1 reply; 13+ messages in thread
From: Paul Menzel @ 2022-07-21 16:21 UTC (permalink / raw)
  To: Mariusz Tkaczyk; +Cc: Neil Brown, Jes Sorensen, linux-raid

Dear Mariusz,


Am 21.07.22 um 10:19 schrieb Mariusz Tkaczyk:

> On Wed, 13 Jul 2022 13:48:11 +1000 NeilBrown wrote:

[…]

>> +	}
>> +	printf("          State : %s%s\n",
>> +	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean",
>> +	       info.space_after > INT64_MAX ? " TRUNCATED DEVICE" : "");
> 
> Could you use standard if instruction to make the code more readable? We are
> avoiding ternary operators if possible now.

That’s news to me. Where is that documented? If find the operator quite 
useful in situations like this.


Kind regards,

Paul

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Ternary Operator (was: [PATCH mdadm v2] super1: report truncated device)
  2022-07-21 16:21       ` Ternary Operator (was: [PATCH mdadm v2] super1: report truncated device) Paul Menzel
@ 2022-07-22  6:55         ` Mariusz Tkaczyk
  0 siblings, 0 replies; 13+ messages in thread
From: Mariusz Tkaczyk @ 2022-07-22  6:55 UTC (permalink / raw)
  To: Paul Menzel; +Cc: Neil Brown, Jes Sorensen, linux-raid

On Thu, 21 Jul 2022 18:21:46 +0200
Paul Menzel <pmenzel@molgen.mpg.de> wrote:

> Dear Mariusz,
> 
> 
> Am 21.07.22 um 10:19 schrieb Mariusz Tkaczyk:
> 
> > On Wed, 13 Jul 2022 13:48:11 +1000 NeilBrown wrote:  
> 
> […]
> 
> >> +	}
> >> +	printf("          State : %s%s\n",
> >> +	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean",
> >> +	       info.space_after > INT64_MAX ? " TRUNCATED DEVICE" : "");  
> > 
> > Could you use standard if instruction to make the code more readable? We are
> > avoiding ternary operators if possible now.  
> 
> That’s news to me. Where is that documented? If find the operator quite 
> useful in situations like this.
> 
> 
Hi Paul,
It was Jes's preference, however I don't remember exactly when and where he
pointed that (and I cannot find it now).

To clarify - I meant inline\ternary if only.

Jes, could you look?

As you said, in this case ternary is useful, so I give it to Neil to decide
if it can be easily replaced. If not- I'm fine with current approach.

Thanks,
Mariusz

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH mdadm v2] super1: report truncated device
  2022-07-21  8:19     ` Mariusz Tkaczyk
  2022-07-21 16:21       ` Ternary Operator (was: [PATCH mdadm v2] super1: report truncated device) Paul Menzel
@ 2022-07-23  4:37       ` NeilBrown
  2022-07-25  7:42         ` Mariusz Tkaczyk
  1 sibling, 1 reply; 13+ messages in thread
From: NeilBrown @ 2022-07-23  4:37 UTC (permalink / raw)
  To: Mariusz Tkaczyk; +Cc: Paul Menzel, Jes Sorensen, linux-raid

On Thu, 21 Jul 2022, Mariusz Tkaczyk wrote:
> Hi Neil,
> 
> On Wed, 13 Jul 2022 13:48:11 +1000
> "NeilBrown" <neilb@suse.de> wrote:
> 
> > When the metadata is at the start of the device, it is possible that it
> > describes a device large than the one it is actually stored on.  When
> > this happens, report it loudly in --examine.
> > 
> > ....
> >    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
> >           State : clean TRUNCATED DEVICE
> > ....
> 
> State : clean TRUNCATED DEVICE is enough. "DEVICE TOO SMALL" seems to be
> redundant.

I needed to change the "Unused Space" line because before the patch the
"after=" value is close to 2^64.  I needed to make it negative.  But having
a negative value there is strange so I thought it would be good to
highlight it and explain why.

> > 
> > Also report in --assemble so that the failure which the kernel will
> > report will be explained.
> 
> Understand but you've added it in load_super1() so it affects all load_super()
> calls, is it indented? I assume yes but please confirm. 

Yes, it is intended for all calls to ->load_super() on v1 metadata.
The test is gated on ->ignore_hw_compat so that it does still look like
v1.x metadata (so --examine can report on it), but an error results for
any attempt to use the metadata in an active array.

->ignore_hw_compat isn't a perfect fit for the concept, but it is a
perfect fit for the desired behaviour.  Maybe we should rethink the name
for that field.

> > 
> > mdadm: Device /dev/sdb is not large enough for data described in superblock
> > mdadm: no RAID superblock on /dev/sdb
> > mdadm: /dev/sdb has no superblock - assembly aborted
> > 
> > Scenario can be demonstrated as follows:
> > 
> > mdadm: Note: this array has metadata at the start and
> >     may not be suitable as a boot device.  If you plan to
> >     store '/boot' on this device please ensure that
> >     your boot-loader understands md/v1.x metadata, or use
> >     --metadata=0.90
> > mdadm: Defaulting to version 1.2 metadata
> > mdadm: array /dev/md/test started.
> > mdadm: stopped /dev/md/test
> >    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
> >           State : clean TRUNCATED DEVICE
> >    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
> >           State : clean TRUNCATED DEVICE
> > 
> > Signed-off-by: NeilBrown <neilb@suse.de>
> > ---
> >  super1.c | 34 +++++++++++++++++++++++++++-------
> >  1 file changed, 27 insertions(+), 7 deletions(-)
> > 
> > diff --git a/super1.c b/super1.c
> > index 71af860c0e3e..4d8dba8a5a44 100644
> > --- a/super1.c
> > +++ b/super1.c
> > @@ -406,12 +406,18 @@ static void examine_super1(struct supertype *st, char
> > *homehost) 
> >  	st->ss->getinfo_super(st, &info, NULL);
> >  	if (info.space_after != 1 &&
> > -	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET))
> > -		printf("   Unused Space : before=%llu sectors, after=%llu
> > sectors\n",
> > -		       info.space_before, info.space_after);
> > -
> > -	printf("          State : %s\n",
> > -	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean");
> > +	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET)) {
> > +		printf("   Unused Space : before=%llu sectors, ",
> > +		       info.space_before);
> > +		if (info.space_after < INT64_MAX)
> > +			printf("after=%llu sectors\n", info.space_after);
> > +		else
> > +			printf("after=-%llu sectors DEVICE TOO SMALL\n",
> > +			       UINT64_MAX - info.space_after);
> As above, for me this else here is not necessary.

The change to report a negative is necessary.

> 
> > +	}
> > +	printf("          State : %s%s\n",
> > +	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean",
> > +	       info.space_after > INT64_MAX ? " TRUNCATED DEVICE" : "");
> 
> Could you use standard if instruction to make the code more readable? We are
> avoiding ternary operators if possible now.

I could.  I don't want to.
I think the code is quite readable.  Putting a space before the first
'?' would help, as might lining up the two '?'.

> 
> >  	printf("    Device UUID : ");
> >  	for (i=0; i<16; i++) {
> >  		if ((i&3)==0 && i != 0)
> > @@ -2206,6 +2212,7 @@ static int load_super1(struct supertype *st, int fd,
> > char *devname) tst.ss = &super1;
> >  		for (tst.minor_version = 0; tst.minor_version <= 2;
> >  		     tst.minor_version++) {
> > +			tst.ignore_hw_compat = st->ignore_hw_compat;
> >  			switch(load_super1(&tst, fd, devname)) {
> >  			case 0: super = tst.sb;
> >  				if (bestvers == -1 ||
> > @@ -2312,7 +2319,6 @@ static int load_super1(struct supertype *st, int fd,
> > char *devname) free(super);
> >  		return 2;
> >  	}
> > -	st->sb = super;
> >  
> >  	bsb = (struct bitmap_super_s *)(((char*)super)+MAX_SB_SIZE);
> >  
> > @@ -2322,6 +2328,20 @@ static int load_super1(struct supertype *st, int fd,
> > char *devname) if (st->data_offset == INVALID_SECTORS)
> >  		st->data_offset = __le64_to_cpu(super->data_offset);
> >  
> > +	if (st->minor_version >= 1 &&
> > +	    st->ignore_hw_compat == 0 &&
> > +	    (__le64_to_cpu(super->data_offset) +
> > +	     __le64_to_cpu(super->size) > dsize ||
> > +	     __le64_to_cpu(super->data_offset) +
> > +	     __le64_to_cpu(super->data_size) > dsize)) {
> > +		if (devname)
> > +			pr_err("Device %s is not large enough for data
> > described in superblock\n",
> > +			       devname);
> 
> why not just:
> if (__le64_to_cpu(super->data_offset) + __le64_to_cpu(super->data_size) > dsize)
> from my understanding, only this check matters.

It seemed safest to test both.  I don't remember the difference between
->size and ->data_size.  In getinfo_super1() we have

	if (info->array.level <= 0)
		data_size = __le64_to_cpu(sb->data_size);
	else
		data_size = __le64_to_cpu(sb->size);

which suggests that either could be relevant.
I guess ->size should always be less than ->data_size.  But
load_super1() doesn't check that, so it isn't safe to assume it.

Thanks,
NeilBrown


> 
> Thanks,
> Mariusz
> 
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH mdadm v2] super1: report truncated device
  2022-07-23  4:37       ` [PATCH mdadm v2] super1: report truncated device NeilBrown
@ 2022-07-25  7:42         ` Mariusz Tkaczyk
  2022-08-24 15:58           ` Jes Sorensen
  0 siblings, 1 reply; 13+ messages in thread
From: Mariusz Tkaczyk @ 2022-07-25  7:42 UTC (permalink / raw)
  To: NeilBrown; +Cc: Paul Menzel, Jes Sorensen, linux-raid

On Sat, 23 Jul 2022 14:37:11 +1000
"NeilBrown" <neilb@suse.de> wrote:

> On Thu, 21 Jul 2022, Mariusz Tkaczyk wrote:
> > Hi Neil,
> > 
> > On Wed, 13 Jul 2022 13:48:11 +1000
> > "NeilBrown" <neilb@suse.de> wrote:
> >   
> > > When the metadata is at the start of the device, it is possible that it
> > > describes a device large than the one it is actually stored on.  When
> > > this happens, report it loudly in --examine.
> > > 
> > > ....
> > >    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO
> > > SMALL State : clean TRUNCATED DEVICE
> > > ....  
> > 
> > State : clean TRUNCATED DEVICE is enough. "DEVICE TOO SMALL" seems to be
> > redundant.  
> 
> I needed to change the "Unused Space" line because before the patch the
> "after=" value is close to 2^64.  I needed to make it negative.  But having
> a negative value there is strange so I thought it would be good to
> highlight it and explain why.

Got it, thanks.

> 
> > > 
> > > Also report in --assemble so that the failure which the kernel will
> > > report will be explained.  
> > 
> > Understand but you've added it in load_super1() so it affects all
> > load_super() calls, is it indented? I assume yes but please confirm.   
> 
> Yes, it is intended for all calls to ->load_super() on v1 metadata.
> The test is gated on ->ignore_hw_compat so that it does still look like
> v1.x metadata (so --examine can report on it), but an error results for
> any attempt to use the metadata in an active array.
> 
> ->ignore_hw_compat isn't a perfect fit for the concept, but it is a  
> perfect fit for the desired behaviour.  Maybe we should rethink the name
> for that field.
> 
> > > 
> > > mdadm: Device /dev/sdb is not large enough for data described in
> > > superblock mdadm: no RAID superblock on /dev/sdb
> > > mdadm: /dev/sdb has no superblock - assembly aborted
> > > 
> > > Scenario can be demonstrated as follows:
> > > 
> > > mdadm: Note: this array has metadata at the start and
> > >     may not be suitable as a boot device.  If you plan to
> > >     store '/boot' on this device please ensure that
> > >     your boot-loader understands md/v1.x metadata, or use
> > >     --metadata=0.90
> > > mdadm: Defaulting to version 1.2 metadata
> > > mdadm: array /dev/md/test started.
> > > mdadm: stopped /dev/md/test
> > >    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO
> > > SMALL State : clean TRUNCATED DEVICE
> > >    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO
> > > SMALL State : clean TRUNCATED DEVICE
> > > 
> > > Signed-off-by: NeilBrown <neilb@suse.de>
> > > ---
> > >  super1.c | 34 +++++++++++++++++++++++++++-------
> > >  1 file changed, 27 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/super1.c b/super1.c
> > > index 71af860c0e3e..4d8dba8a5a44 100644
> > > --- a/super1.c
> > > +++ b/super1.c
> > > @@ -406,12 +406,18 @@ static void examine_super1(struct supertype *st,
> > > char *homehost) 
> > >  	st->ss->getinfo_super(st, &info, NULL);
> > >  	if (info.space_after != 1 &&
> > > -	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET))
> > > -		printf("   Unused Space : before=%llu sectors, after=%llu
> > > sectors\n",
> > > -		       info.space_before, info.space_after);
> > > -
> > > -	printf("          State : %s\n",
> > > -	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean");
> > > +	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET)) {
> > > +		printf("   Unused Space : before=%llu sectors, ",
> > > +		       info.space_before);
> > > +		if (info.space_after < INT64_MAX)
> > > +			printf("after=%llu sectors\n", info.space_after);
> > > +		else
> > > +			printf("after=-%llu sectors DEVICE TOO SMALL\n",
> > > +			       UINT64_MAX - info.space_after);  
> > As above, for me this else here is not necessary.  
> 
> The change to report a negative is necessary.
> 
> >   
> > > +	}
> > > +	printf("          State : %s%s\n",
> > > +	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean",

Please add space before '?' and between and after ':' (same as below).
> > > +	       info.space_after > INT64_MAX ? " TRUNCATED DEVICE" : "");
> > >  
> > 
> > Could you use standard if instruction to make the code more readable? We are
> > avoiding ternary operators if possible now.  
> 
> I could.  I don't want to.
> I think the code is quite readable.  Putting a space before the first
> '?' would help, as might lining up the two '?'.

Please fix formatting and I'm fine with that. In this case ternary if is
reasonable.
> 
> >   
> > >  	printf("    Device UUID : ");
> > >  	for (i=0; i<16; i++) {
> > >  		if ((i&3)==0 && i != 0)
> > > @@ -2206,6 +2212,7 @@ static int load_super1(struct supertype *st, int fd,
> > > char *devname) tst.ss = &super1;
> > >  		for (tst.minor_version = 0; tst.minor_version <= 2;
> > >  		     tst.minor_version++) {
> > > +			tst.ignore_hw_compat = st->ignore_hw_compat;
> > >  			switch(load_super1(&tst, fd, devname)) {
> > >  			case 0: super = tst.sb;
> > >  				if (bestvers == -1 ||
> > > @@ -2312,7 +2319,6 @@ static int load_super1(struct supertype *st, int fd,
> > > char *devname) free(super);
> > >  		return 2;
> > >  	}
> > > -	st->sb = super;
> > >  
> > >  	bsb = (struct bitmap_super_s *)(((char*)super)+MAX_SB_SIZE);
> > >  
> > > @@ -2322,6 +2328,20 @@ static int load_super1(struct supertype *st, int
> > > fd, char *devname) if (st->data_offset == INVALID_SECTORS)
> > >  		st->data_offset = __le64_to_cpu(super->data_offset);
> > >  
> > > +	if (st->minor_version >= 1 &&
> > > +	    st->ignore_hw_compat == 0 &&
> > > +	    (__le64_to_cpu(super->data_offset) +
> > > +	     __le64_to_cpu(super->size) > dsize ||
> > > +	     __le64_to_cpu(super->data_offset) +
> > > +	     __le64_to_cpu(super->data_size) > dsize)) {
> > > +		if (devname)
> > > +			pr_err("Device %s is not large enough for data
> > > described in superblock\n",
> > > +			       devname);  
> > 
> > why not just:
> > if (__le64_to_cpu(super->data_offset) + __le64_to_cpu(super->data_size) >
> > dsize) from my understanding, only this check matters.  
> 
> It seemed safest to test both.  I don't remember the difference between
> ->size and ->data_size.  In getinfo_super1() we have  
> 
> 	if (info->array.level <= 0)
> 		data_size = __le64_to_cpu(sb->data_size);
> 	else
> 		data_size = __le64_to_cpu(sb->size);
> 
> which suggests that either could be relevant.
> I guess ->size should always be less than ->data_size.  But
> load_super1() doesn't check that, so it isn't safe to assume it.

Honestly, I don't understand why but I didn't realize that you are checking two
different fields (size and data_size). I focused on understanding what is going
on  here, and didn't catch difference in variables (because data_offset and
data_size have similar prefix).
For me, something like:

unsigned long long _size;
if (st->minor_version >= 1 && st->ignore_hw_compat == 0)
    _size= __le64_to_cpu(super->size);
else
    _size= __le64_to_cpu(super->data_size);

if (__le64_to_cpu(super->data_offset) + _size > dsize)
{....}

is more readable because I don't need to analyze complex if to get the
difference. Also, I removed doubled __le64_to_cpu(super->data_offset).
Could you refactor this part?

Thanks,
Mariusz

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH mdadm v2] super1: report truncated device
  2022-07-25  7:42         ` Mariusz Tkaczyk
@ 2022-08-24 15:58           ` Jes Sorensen
  2022-08-25  0:24             ` NeilBrown
  0 siblings, 1 reply; 13+ messages in thread
From: Jes Sorensen @ 2022-08-24 15:58 UTC (permalink / raw)
  To: Mariusz Tkaczyk, NeilBrown; +Cc: Paul Menzel, linux-raid

On 7/25/22 03:42, Mariusz Tkaczyk wrote:
> On Sat, 23 Jul 2022 14:37:11 +1000
> "NeilBrown" <neilb@suse.de> wrote:
> 
>> On Thu, 21 Jul 2022, Mariusz Tkaczyk wrote:
>>> Hi Neil,
>>>
>>> On Wed, 13 Jul 2022 13:48:11 +1000
>>> "NeilBrown" <neilb@suse.de> wrote:
....
>>> why not just:
>>> if (__le64_to_cpu(super->data_offset) + __le64_to_cpu(super->data_size) >
>>> dsize) from my understanding, only this check matters.  
>>
>> It seemed safest to test both.  I don't remember the difference between
>> ->size and ->data_size.  In getinfo_super1() we have  
>>
>> 	if (info->array.level <= 0)
>> 		data_size = __le64_to_cpu(sb->data_size);
>> 	else
>> 		data_size = __le64_to_cpu(sb->size);
>>
>> which suggests that either could be relevant.
>> I guess ->size should always be less than ->data_size.  But
>> load_super1() doesn't check that, so it isn't safe to assume it.
> 
> Honestly, I don't understand why but I didn't realize that you are checking two
> different fields (size and data_size). I focused on understanding what is going
> on  here, and didn't catch difference in variables (because data_offset and
> data_size have similar prefix).
> For me, something like:
> 
> unsigned long long _size;
> if (st->minor_version >= 1 && st->ignore_hw_compat == 0)
>     _size= __le64_to_cpu(super->size);
> else
>     _size= __le64_to_cpu(super->data_size);
> 
> if (__le64_to_cpu(super->data_offset) + _size > dsize)
> {....}
> 
> is more readable because I don't need to analyze complex if to get the
> difference. Also, I removed doubled __le64_to_cpu(super->data_offset).
> Could you refactor this part?

What is the consensus on this discussion? I see Coly pulled this into
his tree, but I don't see Mariusz's last concern being addressed.

Thanks,
Jes



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH mdadm v2] super1: report truncated device
  2022-08-24 15:58           ` Jes Sorensen
@ 2022-08-25  0:24             ` NeilBrown
  2022-08-25  7:59               ` Mariusz Tkaczyk
  0 siblings, 1 reply; 13+ messages in thread
From: NeilBrown @ 2022-08-25  0:24 UTC (permalink / raw)
  To: Jes Sorensen; +Cc: Mariusz Tkaczyk, Paul Menzel, linux-raid

On Thu, 25 Aug 2022, Jes Sorensen wrote:
> On 7/25/22 03:42, Mariusz Tkaczyk wrote:
> > On Sat, 23 Jul 2022 14:37:11 +1000
> > "NeilBrown" <neilb@suse.de> wrote:
> > 
> >> On Thu, 21 Jul 2022, Mariusz Tkaczyk wrote:
> >>> Hi Neil,
> >>>
> >>> On Wed, 13 Jul 2022 13:48:11 +1000
> >>> "NeilBrown" <neilb@suse.de> wrote:
> ....
> >>> why not just:
> >>> if (__le64_to_cpu(super->data_offset) + __le64_to_cpu(super->data_size) >
> >>> dsize) from my understanding, only this check matters.  
> >>
> >> It seemed safest to test both.  I don't remember the difference between
> >> ->size and ->data_size.  In getinfo_super1() we have  
> >>
> >> 	if (info->array.level <= 0)
> >> 		data_size = __le64_to_cpu(sb->data_size);
> >> 	else
> >> 		data_size = __le64_to_cpu(sb->size);
> >>
> >> which suggests that either could be relevant.
> >> I guess ->size should always be less than ->data_size.  But
> >> load_super1() doesn't check that, so it isn't safe to assume it.
> > 
> > Honestly, I don't understand why but I didn't realize that you are checking two
> > different fields (size and data_size). I focused on understanding what is going
> > on  here, and didn't catch difference in variables (because data_offset and
> > data_size have similar prefix).
> > For me, something like:
> > 
> > unsigned long long _size;
> > if (st->minor_version >= 1 && st->ignore_hw_compat == 0)
> >     _size= __le64_to_cpu(super->size);
> > else
> >     _size= __le64_to_cpu(super->data_size);
> > 
> > if (__le64_to_cpu(super->data_offset) + _size > dsize)
> > {....}
> > 
> > is more readable because I don't need to analyze complex if to get the
> > difference. Also, I removed doubled __le64_to_cpu(super->data_offset).
> > Could you refactor this part?
> 
> What is the consensus on this discussion? I see Coly pulled this into
> his tree, but I don't see Mariusz's last concern being addressed.

I don't think we reached a consensus.  I probably got distracted.
I don't like that suggestion from Mariusz as it makes assumptions that I
didn't want to make.  I think it is safest to always test dsize against
bother ->size and ->data_size without baking in assumptions about when
either is meaningful.

NeilBrown

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH mdadm v2] super1: report truncated device
  2022-08-25  0:24             ` NeilBrown
@ 2022-08-25  7:59               ` Mariusz Tkaczyk
  2022-08-25 13:42                 ` Jes Sorensen
  0 siblings, 1 reply; 13+ messages in thread
From: Mariusz Tkaczyk @ 2022-08-25  7:59 UTC (permalink / raw)
  To: NeilBrown; +Cc: Jes Sorensen, Paul Menzel, linux-raid

On Thu, 25 Aug 2022 10:24:21 +1000
"NeilBrown" <neilb@suse.de> wrote:

> On Thu, 25 Aug 2022, Jes Sorensen wrote:
> > On 7/25/22 03:42, Mariusz Tkaczyk wrote:  
> > > On Sat, 23 Jul 2022 14:37:11 +1000
> > > "NeilBrown" <neilb@suse.de> wrote:
> > >   
> > >> On Thu, 21 Jul 2022, Mariusz Tkaczyk wrote:  
> > >>> Hi Neil,
> > >>>
> > >>> On Wed, 13 Jul 2022 13:48:11 +1000
> > >>> "NeilBrown" <neilb@suse.de> wrote:  
> > ....  
> > >>> why not just:
> > >>> if (__le64_to_cpu(super->data_offset) + __le64_to_cpu(super->data_size)
> > >>> > dsize) from my understanding, only this check matters.    
> > >>
> > >> It seemed safest to test both.  I don't remember the difference between  
> > >> ->size and ->data_size.  In getinfo_super1() we have    
> > >>
> > >> 	if (info->array.level <= 0)
> > >> 		data_size = __le64_to_cpu(sb->data_size);
> > >> 	else
> > >> 		data_size = __le64_to_cpu(sb->size);
> > >>
> > >> which suggests that either could be relevant.
> > >> I guess ->size should always be less than ->data_size.  But
> > >> load_super1() doesn't check that, so it isn't safe to assume it.  
> > > 
> > > Honestly, I don't understand why but I didn't realize that you are
> > > checking two different fields (size and data_size). I focused on
> > > understanding what is going on  here, and didn't catch difference in
> > > variables (because data_offset and data_size have similar prefix).
> > > For me, something like:
> > > 
> > > unsigned long long _size;
> > > if (st->minor_version >= 1 && st->ignore_hw_compat == 0)
> > >     _size= __le64_to_cpu(super->size);
> > > else
> > >     _size= __le64_to_cpu(super->data_size);
> > > 
> > > if (__le64_to_cpu(super->data_offset) + _size > dsize)
> > > {....}
> > > 
> > > is more readable because I don't need to analyze complex if to get the
> > > difference. Also, I removed doubled __le64_to_cpu(super->data_offset).
> > > Could you refactor this part?  
> > 
> > What is the consensus on this discussion? I see Coly pulled this into
> > his tree, but I don't see Mariusz's last concern being addressed.  
> 
> I don't think we reached a consensus.  I probably got distracted.
> I don't like that suggestion from Mariusz as it makes assumptions that I
> didn't want to make.  I think it is safest to always test dsize against
> bother ->size and ->data_size without baking in assumptions about when
> either is meaningful.
> 
Hi Neil,
It seems that I failed to understand it again. You are right, you approach is
safer. Please fix stylistic issues then and I'm fine with the change.

Sorry for confusing you,
Mariusz


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH mdadm v2] super1: report truncated device
  2022-08-25  7:59               ` Mariusz Tkaczyk
@ 2022-08-25 13:42                 ` Jes Sorensen
  2022-08-25 22:55                   ` [PATCH v3] " NeilBrown
  0 siblings, 1 reply; 13+ messages in thread
From: Jes Sorensen @ 2022-08-25 13:42 UTC (permalink / raw)
  To: Mariusz Tkaczyk, NeilBrown; +Cc: Paul Menzel, linux-raid

On 8/25/22 03:59, Mariusz Tkaczyk wrote:
> On Thu, 25 Aug 2022 10:24:21 +1000
> "NeilBrown" <neilb@suse.de> wrote:
>>> What is the consensus on this discussion? I see Coly pulled this into
>>> his tree, but I don't see Mariusz's last concern being addressed.  
>>
>> I don't think we reached a consensus.  I probably got distracted.
>> I don't like that suggestion from Mariusz as it makes assumptions that I
>> didn't want to make.  I think it is safest to always test dsize against
>> bother ->size and ->data_size without baking in assumptions about when
>> either is meaningful.

No worries, distraction is my middle name these days :)

> Hi Neil,
> It seems that I failed to understand it again. You are right, you approach is
> safer. Please fix stylistic issues then and I'm fine with the change.

Thanks Mariusz

Jes


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH v3] super1: report truncated device
  2022-08-25 13:42                 ` Jes Sorensen
@ 2022-08-25 22:55                   ` NeilBrown
  2022-08-29 15:46                     ` Jes Sorensen
  0 siblings, 1 reply; 13+ messages in thread
From: NeilBrown @ 2022-08-25 22:55 UTC (permalink / raw)
  To: Jes Sorensen; +Cc: Mariusz Tkaczyk, Paul Menzel, linux-raid


When the metadata is at the start of the device, it is possible that it
describes a device large than the one it is actually stored on.  When
this happens, report it loudly in --examine.

....
   Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
          State : clean TRUNCATED DEVICE
....

Also report in --assemble so that the failure which the kernel will
report will be explained.

mdadm: Device /dev/sdb is not large enough for data described in superblock
mdadm: no RAID superblock on /dev/sdb
mdadm: /dev/sdb has no superblock - assembly aborted

Scenario can be demonstrated as follows:

mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md/test started.
mdadm: stopped /dev/md/test
   Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
          State : clean TRUNCATED DEVICE
   Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
          State : clean TRUNCATED DEVICE

Signed-off-by: NeilBrown <neilb@suse.de>
---
 super1.c | 35 ++++++++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/super1.c b/super1.c
index 71af860c0e3e..58345e68b97c 100644
--- a/super1.c
+++ b/super1.c
@@ -406,12 +406,18 @@ static void examine_super1(struct supertype *st, char *homehost)
 
 	st->ss->getinfo_super(st, &info, NULL);
 	if (info.space_after != 1 &&
-	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET))
-		printf("   Unused Space : before=%llu sectors, after=%llu sectors\n",
-		       info.space_before, info.space_after);
-
-	printf("          State : %s\n",
-	       (__le64_to_cpu(sb->resync_offset)+1)? "active":"clean");
+	    !(__le32_to_cpu(sb->feature_map) & MD_FEATURE_NEW_OFFSET)) {
+		printf("   Unused Space : before=%llu sectors, ",
+		       info.space_before);
+		if (info.space_after < INT64_MAX)
+			printf("after=%llu sectors\n", info.space_after);
+		else
+			printf("after=-%llu sectors DEVICE TOO SMALL\n",
+			       UINT64_MAX - info.space_after);
+	}
+	printf("          State : %s%s\n",
+	       (__le64_to_cpu(sb->resync_offset)+1) ? "active":"clean",
+	       (info.space_after > INT64_MAX)       ? " TRUNCATED DEVICE" : "");
 	printf("    Device UUID : ");
 	for (i=0; i<16; i++) {
 		if ((i&3)==0 && i != 0)
@@ -2206,6 +2212,7 @@ static int load_super1(struct supertype *st, int fd, char *devname)
 		tst.ss = &super1;
 		for (tst.minor_version = 0; tst.minor_version <= 2;
 		     tst.minor_version++) {
+			tst.ignore_hw_compat = st->ignore_hw_compat;
 			switch(load_super1(&tst, fd, devname)) {
 			case 0: super = tst.sb;
 				if (bestvers == -1 ||
@@ -2312,7 +2319,6 @@ static int load_super1(struct supertype *st, int fd, char *devname)
 		free(super);
 		return 2;
 	}
-	st->sb = super;
 
 	bsb = (struct bitmap_super_s *)(((char*)super)+MAX_SB_SIZE);
 
@@ -2322,6 +2328,21 @@ static int load_super1(struct supertype *st, int fd, char *devname)
 	if (st->data_offset == INVALID_SECTORS)
 		st->data_offset = __le64_to_cpu(super->data_offset);
 
+	if (st->minor_version >= 1 &&
+	    st->ignore_hw_compat == 0 &&
+	    (dsize < (__le64_to_cpu(super->data_offset) +
+		      __le64_to_cpu(super->size))
+	     ||
+	     dsize < (__le64_to_cpu(super->data_offset) +
+		      __le64_to_cpu(super->data_size)))) {
+		if (devname)
+			pr_err("Device %s is not large enough for data described in superblock\n",
+			       devname);
+		free(super);
+		return 2;
+	}
+	st->sb = super;
+
 	/* Now check on the bitmap superblock */
 	if ((__le32_to_cpu(super->feature_map)&MD_FEATURE_BITMAP_OFFSET) == 0)
 		return 0;
-- 
2.37.1


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH v3] super1: report truncated device
  2022-08-25 22:55                   ` [PATCH v3] " NeilBrown
@ 2022-08-29 15:46                     ` Jes Sorensen
  0 siblings, 0 replies; 13+ messages in thread
From: Jes Sorensen @ 2022-08-29 15:46 UTC (permalink / raw)
  To: NeilBrown; +Cc: Mariusz Tkaczyk, Paul Menzel, linux-raid

On 8/25/22 18:55, NeilBrown wrote:
> 
> When the metadata is at the start of the device, it is possible that it
> describes a device large than the one it is actually stored on.  When
> this happens, report it loudly in --examine.
> 
> ....
>    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
>           State : clean TRUNCATED DEVICE
> ....
> 
> Also report in --assemble so that the failure which the kernel will
> report will be explained.
> 
> mdadm: Device /dev/sdb is not large enough for data described in superblock
> mdadm: no RAID superblock on /dev/sdb
> mdadm: /dev/sdb has no superblock - assembly aborted
> 
> Scenario can be demonstrated as follows:
> 
> mdadm: Note: this array has metadata at the start and
>     may not be suitable as a boot device.  If you plan to
>     store '/boot' on this device please ensure that
>     your boot-loader understands md/v1.x metadata, or use
>     --metadata=0.90
> mdadm: Defaulting to version 1.2 metadata
> mdadm: array /dev/md/test started.
> mdadm: stopped /dev/md/test
>    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
>           State : clean TRUNCATED DEVICE
>    Unused Space : before=1968 sectors, after=-2047 sectors DEVICE TOO SMALL
>           State : clean TRUNCATED DEVICE
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---

Applied!

Thanks Neil!

Jes



^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2022-08-29 15:46 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-12  1:00 [PATCH mdadm] super1: report truncated device NeilBrown
     [not found] ` <cff69e79-d681-c9d6-c719-8b10999a558a@molgen.mpg.de>
2022-07-13  3:48   ` [PATCH mdadm v2] " NeilBrown
2022-07-21  8:19     ` Mariusz Tkaczyk
2022-07-21 16:21       ` Ternary Operator (was: [PATCH mdadm v2] super1: report truncated device) Paul Menzel
2022-07-22  6:55         ` Mariusz Tkaczyk
2022-07-23  4:37       ` [PATCH mdadm v2] super1: report truncated device NeilBrown
2022-07-25  7:42         ` Mariusz Tkaczyk
2022-08-24 15:58           ` Jes Sorensen
2022-08-25  0:24             ` NeilBrown
2022-08-25  7:59               ` Mariusz Tkaczyk
2022-08-25 13:42                 ` Jes Sorensen
2022-08-25 22:55                   ` [PATCH v3] " NeilBrown
2022-08-29 15:46                     ` Jes Sorensen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.