On 03/29/2017 17:55, Warner Losh wrote: > On Wed, Mar 29, 2017 at 3:36 PM, Poul-Henning Kamp <p...@phk.freebsd.dk> > wrote: >> -------- >> In message <7448826.asyms2t...@ralph.baldwin.cx>, John Baldwin writes: >>> On Wednesday, March 29, 2017 09:30:03 AM Ngie Cooper wrote: >> >>>> Log: >>>> Parameterize out 7680 (15 * 512) as BOOT2SIZE, similar to >>>> sys/boot/i386/zfsboot/... >>>> >>>> This is being done to make it easier to change in the future--this >>>> action might be >>>> needed sooner rather than later because of gcc 6.3.0 bailing, stating >>>> that there >>>> is negative free space left (deficit) in the boot2 bootloader. >>>> >>>> MFC after: 2 months >>>> Sponsored by: Dell EMC Isilon >>> >>> This can't be changed. It's baked into the BSD disklabel format. >> >> No it is not, it is baked into FFS, and for UFS2 0, 8, 64 and 256K works. > > Technically, this is correct. Practically, I'm not sure we can ever > really change it. There are too many tools, scripts, etc that just > know it's 8k, even though most UFS2 systems start 64k into the volume. > UFS1 systems are still around, and there the limit is a hard limit. > And if we grow it, we run the risk of corrupting data beyond the 8k > area we've traditionally used for this. > > So the constants are easy enough to change and it seems like it might > be OK. However, doing it in a safe, anti-foot-shooting way will be the > real elbow grease should someone seriously contemplate the change, > especially since the foot-shooting involved has the potential for > filesystem corruption... > > But gcc 6.3 likely just needs a little TLC experimenting with its > different code generation flags...
Interestingly, we had the same discussion eons ago. http://docs.freebsd.org/cgi/mid.cgi?200509081418.47794.jkim FYI... Jung-uk Kim
signature.asc
Description: OpenPGP digital signature