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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to