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 <address@hidden>
> >> ---
> >>  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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel