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 <mch...@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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
