[PATCH] docs: Update for stopping small mbr gap support

[PATCH] docs: Update for stopping small mbr gap support

[Michael Chang]

Further to the discussion about disabling btrfs zstd support for
i386-pc[1], this paragraph in manual about mbr gap size doesn't seem to
hold true any longer.

"You must ensure that the first partition starts at least 31 KiB (63
sectors) from the start of the disk"

As in many occasions we inevitablely have to provide core image size
that goes beyond 31 KiB, this statement becomes a true liability as
people would be misguided and think it is still fine to use small MBR
gap, that has always been a headache in distribution's upgrade path as
growing new feature would render the size requirement bigger but no way
for the user to relocate their partitions.

The patch tries to correct the paragraph with a more practical size that
works for grub and also for modern computer systems in general.

[1] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00025.html

Signed-off-by: Michael Chang <mchang@suse.com>
---
 docs/grub.texi | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index 83979af38..651468268 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -845,12 +845,20 @@ only be used if the @file{/boot} filesystem is on the same disk that the
 BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
 numbers.
 
-The GRUB development team generally recommends embedding GRUB before the
-first partition, unless you have special requirements.  You must ensure that
-the first partition starts at least 31 KiB (63 sectors) from the start of
-the disk; on modern disks, it is often a performance advantage to align
-partitions on larger boundaries anyway, so the first partition might start 1
-MiB from the start of the disk.
+The GRUB development team generally recommends embedding GRUB before the first
+partition, unless you have special requirements. You must ensure that the first
+partition starts at least 1 MiB from the start of the disk; on modern disks, it
+is often a performance advantage to align partitions on larger boundaries and 1
+MiB is the least common multiple of many used alignment sizes. For SSD, it
+became crucial to have the partition correctly aligned to avoid excessive
+read-modify-write cycles and thus modern tools set to use 1 MiB as a stardard
+practice.
+
+In case legacy systems that cannot boot if first partition not on the cylinder
+boundary, the fallback blocklist install method should remain working for them
+if the core image growing too much someday. Here we just can't advertise that
+31 KiB (63 sectors) is a sensible size any longer as that would pose great
+constraint to include new features as time goes by.
 
 @heading GPT
 
-- 
2.16.4

Re: [PATCH] docs: Update for stopping small mbr gap support

[Daniel Kiper]

On Thu, Mar 05, 2020 at 06:40:01PM +0800, Michael Chang wrote:
> Further to the discussion about disabling btrfs zstd support for
> i386-pc[1], this paragraph in manual about mbr gap size doesn't seem to
> hold true any longer.
>
> "You must ensure that the first partition starts at least 31 KiB (63
> sectors) from the start of the disk"
>
> As in many occasions we inevitablely have to provide core image size
> that goes beyond 31 KiB, this statement becomes a true liability as
> people would be misguided and think it is still fine to use small MBR
> gap, that has always been a headache in distribution's upgrade path as
> growing new feature would render the size requirement bigger but no way
> for the user to relocate their partitions.

Could you split this paragraph into a few sentences? Now it does not
read very well...

> The patch tries to correct the paragraph with a more practical size that
> works for grub and also for modern computer systems in general.
>
> [1] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00025.html
>
> Signed-off-by: Michael Chang <mchang@suse.com>
> ---
>  docs/grub.texi | 20 ++++++++++++++------
>  1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 83979af38..651468268 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -845,12 +845,20 @@ only be used if the @file{/boot} filesystem is on the same disk that the
>  BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
>  numbers.
>
> -The GRUB development team generally recommends embedding GRUB before the
> -first partition, unless you have special requirements.  You must ensure that
> -the first partition starts at least 31 KiB (63 sectors) from the start of
> -the disk; on modern disks, it is often a performance advantage to align
> -partitions on larger boundaries anyway, so the first partition might start 1
> -MiB from the start of the disk.
> +The GRUB development team generally recommends embedding GRUB before the first
> +partition, unless you have special requirements. You must ensure that the first
> +partition starts at least 1 MiB from the start of the disk; on modern disks, it

s/; on modern disks, it/. Additionally, on modern disks it/

> +is often a performance advantage to align partitions on larger boundaries and 1
> +MiB is the least common multiple of many used alignment sizes. For SSD, it

s/For SSD, it/E.g. SSD, it/

> +became crucial to have the partition correctly aligned to avoid excessive
> +read-modify-write cycles and thus modern tools set to use 1 MiB as a stardard
> +practice.
> +
> +In case legacy systems that cannot boot if first partition not on the cylinder

s/In case legacy/In case of legacy/
s/partition not/partition is not/

> +boundary, the fallback blocklist install method should remain working for them
> +if the core image growing too much someday. Here we just can't advertise that
> +31 KiB (63 sectors) is a sensible size any longer as that would pose great
> +constraint to include new features as time goes by.

Daniel

Re: [PATCH] docs: Update for stopping small mbr gap support

[C. Masloch]

Two small suggestions inlined in the quoted part.

Regards,
ecm


On at 2020-03-05 15:38 +0100, Daniel Kiper wrote:
> On Thu, Mar 05, 2020 at 06:40:01PM +0800, Michael Chang wrote:
>> Further to the discussion about disabling btrfs zstd support for
>> i386-pc[1], this paragraph in manual about mbr gap size doesn't seem to
>> hold true any longer.
>>
>> "You must ensure that the first partition starts at least 31 KiB (63
>> sectors) from the start of the disk"
>>
>> As in many occasions we inevitablely have to provide core image size
>> that goes beyond 31 KiB, this statement becomes a true liability as
>> people would be misguided and think it is still fine to use small MBR
>> gap, that has always been a headache in distribution's upgrade path as
>> growing new feature would render the size requirement bigger but no way
>> for the user to relocate their partitions.
> 
> Could you split this paragraph into a few sentences? Now it does not
> read very well...
> 
>> The patch tries to correct the paragraph with a more practical size that
>> works for grub and also for modern computer systems in general.
>>
>> [1] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00025.html
>>
>> Signed-off-by: Michael Chang <mchang@suse.com>
>> ---
>>  docs/grub.texi | 20 ++++++++++++++------
>>  1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/docs/grub.texi b/docs/grub.texi
>> index 83979af38..651468268 100644
>> --- a/docs/grub.texi
>> +++ b/docs/grub.texi
>> @@ -845,12 +845,20 @@ only be used if the @file{/boot} filesystem is on the same disk that the
>>  BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
>>  numbers.
>>
>> -The GRUB development team generally recommends embedding GRUB before the
>> -first partition, unless you have special requirements.  You must ensure that
>> -the first partition starts at least 31 KiB (63 sectors) from the start of
>> -the disk; on modern disks, it is often a performance advantage to align
>> -partitions on larger boundaries anyway, so the first partition might start 1
>> -MiB from the start of the disk.
>> +The GRUB development team generally recommends embedding GRUB before the first
>> +partition, unless you have special requirements. You must ensure that the first
>> +partition starts at least 1 MiB from the start of the disk; on modern disks, it
> 
> s/; on modern disks, it/. Additionally, on modern disks it/
> 
>> +is often a performance advantage to align partitions on larger boundaries and 1
>> +MiB is the least common multiple of many used alignment sizes. For SSD, it
> 
> s/For SSD, it/E.g. SSD, it/
> 
>> +became crucial to have the partition correctly aligned to avoid excessive
>> +read-modify-write cycles and thus modern tools set to use 1 MiB as a stardard
>> +practice.

s/stardard/standard

>> +
>> +In case legacy systems that cannot boot if first partition not on the cylinder
> 
> s/In case legacy/In case of legacy/
> s/partition not/partition is not/
> 
>> +boundary, the fallback blocklist install method should remain working for them
>> +if the core image growing too much someday. Here we just can't advertise that

s/growing/grows/

>> +31 KiB (63 sectors) is a sensible size any longer as that would pose great
>> +constraint to include new features as time goes by.
> 
> Daniel

Re: [PATCH] docs: Update for stopping small mbr gap support

[Michael Chang]

On Thu, Mar 05, 2020 at 05:00:11PM +0100, C. Masloch wrote:
> Two small suggestions inlined in the quoted part.
> 
> Regards,
> ecm
> 
> 
> On at 2020-03-05 15:38 +0100, Daniel Kiper wrote:
> > On Thu, Mar 05, 2020 at 06:40:01PM +0800, Michael Chang wrote:
> >> Further to the discussion about disabling btrfs zstd support for
> >> i386-pc[1], this paragraph in manual about mbr gap size doesn't seem to
> >> hold true any longer.
> >>
> >> "You must ensure that the first partition starts at least 31 KiB (63
> >> sectors) from the start of the disk"
> >>
> >> As in many occasions we inevitablely have to provide core image size
> >> that goes beyond 31 KiB, this statement becomes a true liability as
> >> people would be misguided and think it is still fine to use small MBR
> >> gap, that has always been a headache in distribution's upgrade path as
> >> growing new feature would render the size requirement bigger but no way
> >> for the user to relocate their partitions.
> > 
> > Could you split this paragraph into a few sentences? Now it does not
> > read very well...
> > 
> >> The patch tries to correct the paragraph with a more practical size that
> >> works for grub and also for modern computer systems in general.
> >>
> >> [1] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00025.html
> >>
> >> Signed-off-by: Michael Chang <mchang@suse.com>
> >> ---
> >>  docs/grub.texi | 20 ++++++++++++++------
> >>  1 file changed, 14 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/docs/grub.texi b/docs/grub.texi
> >> index 83979af38..651468268 100644
> >> --- a/docs/grub.texi
> >> +++ b/docs/grub.texi
> >> @@ -845,12 +845,20 @@ only be used if the @file{/boot} filesystem is on the same disk that the
> >>  BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
> >>  numbers.
> >>
> >> -The GRUB development team generally recommends embedding GRUB before the
> >> -first partition, unless you have special requirements.  You must ensure that
> >> -the first partition starts at least 31 KiB (63 sectors) from the start of
> >> -the disk; on modern disks, it is often a performance advantage to align
> >> -partitions on larger boundaries anyway, so the first partition might start 1
> >> -MiB from the start of the disk.
> >> +The GRUB development team generally recommends embedding GRUB before the first
> >> +partition, unless you have special requirements. You must ensure that the first
> >> +partition starts at least 1 MiB from the start of the disk; on modern disks, it
> > 
> > s/; on modern disks, it/. Additionally, on modern disks it/
> > 
> >> +is often a performance advantage to align partitions on larger boundaries and 1
> >> +MiB is the least common multiple of many used alignment sizes. For SSD, it
> > 
> > s/For SSD, it/E.g. SSD, it/
> > 
> >> +became crucial to have the partition correctly aligned to avoid excessive
> >> +read-modify-write cycles and thus modern tools set to use 1 MiB as a stardard
> >> +practice.
> 
> s/stardard/standard

OK.

> 
> >> +
> >> +In case legacy systems that cannot boot if first partition not on the cylinder
> > 
> > s/In case legacy/In case of legacy/
> > s/partition not/partition is not/
> > 
> >> +boundary, the fallback blocklist install method should remain working for them
> >> +if the core image growing too much someday. Here we just can't advertise that
> 
> s/growing/grows/

OK.

Many thanks for the review. :)

Regards,
Michael

> 
> >> +31 KiB (63 sectors) is a sensible size any longer as that would pose great
> >> +constraint to include new features as time goes by.
> > 
> > Daniel
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] docs: Update for stopping small mbr gap support

[Michael Chang]

On Thu, Mar 05, 2020 at 03:38:20PM +0100, Daniel Kiper wrote:
> On Thu, Mar 05, 2020 at 06:40:01PM +0800, Michael Chang wrote:
> > Further to the discussion about disabling btrfs zstd support for
> > i386-pc[1], this paragraph in manual about mbr gap size doesn't seem to
> > hold true any longer.
> >
> > "You must ensure that the first partition starts at least 31 KiB (63
> > sectors) from the start of the disk"
> >
> > As in many occasions we inevitablely have to provide core image size
> > that goes beyond 31 KiB, this statement becomes a true liability as
> > people would be misguided and think it is still fine to use small MBR
> > gap, that has always been a headache in distribution's upgrade path as
> > growing new feature would render the size requirement bigger but no way
> > for the user to relocate their partitions.
> 
> Could you split this paragraph into a few sentences? Now it does not
> read very well...

OK. I'll come up with a better expression next version.

> 
> > The patch tries to correct the paragraph with a more practical size that
> > works for grub and also for modern computer systems in general.
> >
> > [1] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00025.html
> >
> > Signed-off-by: Michael Chang <mchang@suse.com>
> > ---
> >  docs/grub.texi | 20 ++++++++++++++------
> >  1 file changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/docs/grub.texi b/docs/grub.texi
> > index 83979af38..651468268 100644
> > --- a/docs/grub.texi
> > +++ b/docs/grub.texi
> > @@ -845,12 +845,20 @@ only be used if the @file{/boot} filesystem is on the same disk that the
> >  BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive
> >  numbers.
> >
> > -The GRUB development team generally recommends embedding GRUB before the
> > -first partition, unless you have special requirements.  You must ensure that
> > -the first partition starts at least 31 KiB (63 sectors) from the start of
> > -the disk; on modern disks, it is often a performance advantage to align
> > -partitions on larger boundaries anyway, so the first partition might start 1
> > -MiB from the start of the disk.
> > +The GRUB development team generally recommends embedding GRUB before the first
> > +partition, unless you have special requirements. You must ensure that the first
> > +partition starts at least 1 MiB from the start of the disk; on modern disks, it
> 
> s/; on modern disks, it/. Additionally, on modern disks it/

OK.

> 
> > +is often a performance advantage to align partitions on larger boundaries and 1
> > +MiB is the least common multiple of many used alignment sizes. For SSD, it
> 
> s/For SSD, it/E.g. SSD, it/

OK.

> 
> > +became crucial to have the partition correctly aligned to avoid excessive
> > +read-modify-write cycles and thus modern tools set to use 1 MiB as a stardard
> > +practice.
> > +
> > +In case legacy systems that cannot boot if first partition not on the cylinder
> 
> s/In case legacy/In case of legacy/
> s/partition not/partition is not/

OK.

> 
> > +boundary, the fallback blocklist install method should remain working for them
> > +if the core image growing too much someday. Here we just can't advertise that
> > +31 KiB (63 sectors) is a sensible size any longer as that would pose great
> > +constraint to include new features as time goes by.

Thanks a lot for taking time to review.

Regards,
Michael

> 
> Daniel
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel