From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jA4Nb-0005Gm-Uw for mharc-grub-devel@gnu.org; Thu, 05 Mar 2020 23:14:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45040) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jA4NY-000596-I9 for grub-devel@gnu.org; Thu, 05 Mar 2020 23:14:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jA4NW-0000UD-W4 for grub-devel@gnu.org; Thu, 05 Mar 2020 23:14:28 -0500 Received: from m9a0014g.houston.softwaregrp.com ([15.124.64.90]:40986) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jA4NW-0000I2-P8 for grub-devel@gnu.org; Thu, 05 Mar 2020 23:14:26 -0500 Received: FROM m9a0014g.houston.softwaregrp.com (15.121.0.190) BY m9a0014g.houston.softwaregrp.com WITH ESMTP; Fri, 6 Mar 2020 04:13:37 +0000 Received: from M9W0068.microfocus.com (2002:f79:bf::f79:bf) by M9W0067.microfocus.com (2002:f79:be::f79:be) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 6 Mar 2020 04:13:42 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (15.124.72.13) by M9W0068.microfocus.com (15.121.0.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10 via Frontend Transport; Fri, 6 Mar 2020 04:13:43 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oRp84ruGSQvqJpK4vs8tokO3R5C6Og+F/tOtmjuXiApJyY8qS3iqj9d4rf+T3Gi3k0MBN6GpS7TPACE2pLTO7XV1awYQ093pPB9y7wQ0+DL3aKWObJsvwriA7dL2CUnnc60UVXmuyE7DXAo5KZnilw+aZhPzmcdxon2bIjWc21s6JsRx/vT8bT6ArGG6Au3eQaG2O4YL1H63rDNZ3BZ2/KN3wnpDn4zapTUa3um6rqlLOzmRgnFtxHhp2Rbt+fhVA1nAr8Pm/DuYsosTVje5Kf5p5Yy4plEMin6ATwr3+flFFGRqGl4nvxohnPtBTi8JLb2UrQRPyg4caUvHU2h96A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/EeGd3AEADwRgjaTmfkUV7VCkxTqgRwOP9RBqPl4Hjg=; b=Wd7fkxLTC74hxp1EeM0b9bthJfsVJkdszd0zR+tQpr04YiaSz7rgbhpOg6csEmOAvZrHLLAwlWQzAVzX5U7/o1zGrYchn31FbQiZLxgLRnjgp6ZaVx8rhn2Z3j0JFQDNj0kL8+r4b/8FRlJFuNrC6TYqxMACdKoccDn8cQv3tF9tSVzzvSr29YeB7ZIMLmMt4OqU++5jj5DQ8Chwnie3ldoEY1I5dU6QMSVpt3h/F4wfXYns11td1dPA9INGJB87jyw1MMHrLqwnYIpXoPs+MXYqT8y92XLmfDjOc9tNym+b+YdBm54UVi4wq67gSYVtr7Prh5/OzlE1O7+dH4fZEw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=MChang@suse.com; Received: from BY5PR18MB3188.namprd18.prod.outlook.com (2603:10b6:a03:1ac::18) by BY5PR18MB3347.namprd18.prod.outlook.com (2603:10b6:a03:1ac::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.18; Fri, 6 Mar 2020 04:13:42 +0000 Received: from BY5PR18MB3188.namprd18.prod.outlook.com ([fe80::28ac:20e6:d692:e83]) by BY5PR18MB3188.namprd18.prod.outlook.com ([fe80::28ac:20e6:d692:e83%5]) with mapi id 15.20.2772.019; Fri, 6 Mar 2020 04:13:42 +0000 Date: Fri, 6 Mar 2020 12:13:34 +0800 From: Michael Chang To: The development of GNU GRUB CC: Daniel Kiper Subject: Re: [PATCH] docs: Update for stopping small mbr gap support Message-ID: <20200306041334.GB3353@mercury> References: <20200305104001.GA32361@mercury> <20200305143820.qikcgpl3iabn4h6j@tomti.i.net-space.pl> <22e38978-29cf-e902-2a7f-c3a92c5d6426@ulukai.org> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <22e38978-29cf-e902-2a7f-c3a92c5d6426@ulukai.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-ClientProxiedBy: HK2PR03CA0061.apcprd03.prod.outlook.com (2603:1096:202:17::31) To BY5PR18MB3188.namprd18.prod.outlook.com (2603:10b6:a03:1ac::18) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from mercury (36.229.19.35) by HK2PR03CA0061.apcprd03.prod.outlook.com (2603:1096:202:17::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.6 via Frontend Transport; Fri, 6 Mar 2020 04:13:41 +0000 X-Originating-IP: [36.229.19.35] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 980cf20d-868a-43e9-4482-08d7c184c135 X-MS-TrafficTypeDiagnostic: BY5PR18MB3347: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4125; X-Forefront-PRVS: 0334223192 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(366004)(136003)(346002)(39860400002)(396003)(189003)(199004)(52116002)(6496006)(81166006)(8936002)(6916009)(9576002)(81156014)(2906002)(8676002)(1076003)(33656002)(4326008)(66946007)(33716001)(6666004)(9686003)(55016002)(5660300002)(66476007)(66556008)(478600001)(26005)(16526019)(186003)(966005)(316002)(956004)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR18MB3347; H:BY5PR18MB3188.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: suse.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bywkw/I4CZuY76EvdY3Ct4NzT+JYwcUmjZE8yMj/Wk/Lwy3U6JA5QVi7yOKqyWWxH6Zw4QWkvLZPrg+03fa/WUA3+a6E5uY6ioCuzDK1fspLjwRLIzXe5RDdVN2QOF5z7AORr0tdzfWHi6nntuDkGSE9xcARNXLWM/bpCLTYcLoQzaFIvdBxce2KbLQZZ72b6bnfV+h6F5/C8GvaOOzWCdCxFHRyUio/6gYsVu4WLo/cSC0TR5wUI6vlKQil0qLHy3yn3kLLBR21f+IRPGuDPoWn3c5iYyOwv4dsVzT5yYjBm1Sssvc6TPaQI+EixMd4DMDScfnvvlzSlRBkp9WQt7mHvxbcJg5NF/Pw9VOnndcl7q32/Vw47s/rudV8NEMuuwQ31zDNqqoZHCOCaz79BYFwDyzC3atVaAaTmHqPIzEOf6k6LOA+O64sS0D4Vn0GnP5bT+BNgFv+XMKQqRQJyLwEXvP8bRpMIBb+jHPvGtZPkoh4NdCTrXDhABeA6EfTLE77+bMjia2quUXz2va5tw== X-MS-Exchange-AntiSpam-MessageData: +pokmJKYjRnVDU+ikEvUyk5WMBykpfqZJZWGe8Dk+m1pYHTUjnGxIaj356tXTR3jC5YKPNFfDQ7WeQZpFqSuWGr2L0f6jUOLsi2uo452KzXNftc9jLLZH7J86wLO31663j5XXwTo+xG7Xs/0femjbw== X-MS-Exchange-CrossTenant-Network-Message-Id: 980cf20d-868a-43e9-4482-08d7c184c135 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2020 04:13:41.9750 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 856b813c-16e5-49a5-85ec-6f081e13b527 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: NXaMXoOKkP+bYaYH+Os/Pbp8+nUiGdVkpke6ydfyZBdgghc9m26cLybWHwM3XzjO X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3347 X-OriginatorOrg: suse.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 15.124.64.90 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 04:14:30 -0000 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 > >> --- > >> 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