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

[PATCH v2] 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 with the
size that goes beyond 31 KiB. For instance, diskfilter and crypto
modules which are needed by root disk formatted with btrfs, lvm, mdadm
and so on would add quite a lot space to the image.

So this misinformation would have people misguided and thought that it
is still fine to use small MBR gap utill some point of time the update
has grown the size too much that the grub-install can no longer embed
the image to the mbr gap. In this case changing the partition layout is
required but it is never easy to do so.

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

Changes since v2:
 * Rework a paragraph in commit message and also some places in manual
   to be more clear to read
 * Correct some typos

 docs/grub.texi | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index 83979af38..4614a2ee1 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; 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.
+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
+standard practice.
+
+In case of legacy systems that cannot boot if first partition is not on the
+cylinder boundary, the fallback blocklist install method should remain working
+for them if the core image grows 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 v2] docs: Update for stopping small mbr gap support

[Javier Martinez Canillas]

Hello Michael,

On 3/6/20 7:53 AM, 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 with the
> size that goes beyond 31 KiB. For instance, diskfilter and crypto
> modules which are needed by root disk formatted with btrfs, lvm, mdadm
> and so on would add quite a lot space to the image.
> 
> So this misinformation would have people misguided and thought that it
> is still fine to use small MBR gap utill some point of time the update
> has grown the size too much that the grub-install can no longer embed
> the image to the mbr gap. In this case changing the partition layout is
> required but it is never easy to do so.
> 
> 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>
> ---
>

Agreed with the patch.

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
 
> Changes since v2:
>  * Rework a paragraph in commit message and also some places in manual
>    to be more clear to read
>  * Correct some typos
> 
>  docs/grub.texi | 20 ++++++++++++++------
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 83979af38..4614a2ee1 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; 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.
> +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
> +standard practice.
> +
> +In case of legacy systems that cannot boot if first partition is not on the
> +cylinder boundary, the fallback blocklist install method should remain working
> +for them if the core image grows 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.
>

I think is also worth mentioning that most partition tools these days default to
the optimal alignment for the disk. But could be done as a follow-up patch if you
agree that adding this information would be useful.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

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

[Daniel Kiper]

On Fri, Mar 06, 2020 at 11:38:49AM +0100, Javier Martinez Canillas wrote:
> Hello Michael,
>
> On 3/6/20 7:53 AM, 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 with the
> > size that goes beyond 31 KiB. For instance, diskfilter and crypto
> > modules which are needed by root disk formatted with btrfs, lvm, mdadm
> > and so on would add quite a lot space to the image.
> >
> > So this misinformation would have people misguided and thought that it
> > is still fine to use small MBR gap utill some point of time the update
> > has grown the size too much that the grub-install can no longer embed
> > the image to the mbr gap. In this case changing the partition layout is
> > required but it is never easy to do so.
> >
> > 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>
> > ---
> >
>
> Agreed with the patch.
>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

...except some nitpicks which I fix before commiting the patch...

> > Changes since v2:
> >  * Rework a paragraph in commit message and also some places in manual
> >    to be more clear to read
> >  * Correct some typos
> >
> >  docs/grub.texi | 20 ++++++++++++++------
> >  1 file changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/docs/grub.texi b/docs/grub.texi
> > index 83979af38..4614a2ee1 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; 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.
> > +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
> > +standard practice.
> > +
> > +In case of legacy systems that cannot boot if first partition is not on the
> > +cylinder boundary, the fallback blocklist install method should remain working
> > +for them if the core image grows 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.
>
> I think is also worth mentioning that most partition tools these days default to
> the optimal alignment for the disk. But could be done as a follow-up patch if you
> agree that adding this information would be useful.

This is not a must. However, if you think it makes sense please send a patch.

Daniel