grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: C. Masloch
Subject: Re: [PATCH] docs: Update for stopping small mbr gap support
Date: Thu, 5 Mar 2020 17:00:11 +0100

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]