On 2016-03-18 17:48, Freddie Cash wrote:

On Fri, Mar 18, 2016 at 2:45 PM, Allan Jude <allanj...@freebsd.org
<mailto:allanj...@freebsd.org>> wrote:

    On 2016-03-18 17:41, Freddie Cash wrote:

        On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer <c...@freebsd.org
        <mailto:c...@freebsd.org <mailto:c...@freebsd.org>>> wrote:

             On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude
        <allanj...@freebsd.org <mailto:allanj...@freebsd.org>
        <mailto:allanj...@freebsd.org>>> wrote:
              > On 2016-03-18 12:33, Guido Falsi wrote:
              >> Hi,
              >> I have just update one of my machines and noticed the
              >> got quite fat in the last few days, some by a big margin.
              >> on an updated machine(r296993):
              >> -r--r--r--  1 root  wheel   85794 Mar 18 16:47
              >> from a machine I still have not updated(r296719):
              >> -r--r--r--  1 root  wheel   16059 Mar 13 21:01

             So the loader grew 70 kB.  How big are your disks?

              >> I noticed because mu gpt boot partition is 64K and
        gptzfsboot just
              >> passed 100K.
              > This is a side effect of the loader gaining the ability
        to boot
             from GELI
              > encrypted partitions.
              > ...
              > Maybe we should be putting the GELI enabled boot blocks in a
              > filename? I generally wanted to avoid creating a new
        version of each
              > bootcode with GELI support.

             I think we should just suggest that boot partitions be much
             than 64kB (1MB is still <0.1% of any disk sold today) and
        not worry
             about it too much.  Embedded applications can disable GELI
             support to save a few bytes.

        ​The boot partition doesn't necessarily need ​
        ​to be 1 MB (and can't due to some issues with the assembler
        used right
        now, or something like that).  We just need to make sure people have
        slack space in their partition table to expand into in the future.

        Using "-a 1M" in your gpart command to create your first data
        gives you that slack space.

        gpart create -s gpt ada0
        gpart add -t freebsd-boot -s 256K -l boot ada0
        gpart add -t freebsd-ufs  -s 10G  -l root -a 1M ada0

        That leaves ~756 KB of free space between the end of the boot
        and the start of the first data partition.  Increasing the size
        of the
        boot partition in the future is as easy as (no formatting of disks

        gpart delete -i 1 ada0
        gpart add -t freebsd-boot -s 512K -l boot ada0
        gpart bootcode -b ... -p ... ada0

        It's a handy pattern I've gotten used to over the years, ever
        since the
        first 4K sector harddrives were advertised (as alignment of
        was/is *very* important)​.

        Even on disks that will be used solely for ZFS I've taken to
        GPT partitions starting at 1 MB.  And it's saved me from having to
        reformat disks when moving from a separate root filesystem (no USB
        sticks) to root-on-ZFS as there was 1 MB of free space at the
        start of
        every disk for creating boot partitions.  :)

        Freddie Cash
        fjwc...@gmail.com <mailto:fjwc...@gmail.com>
        <mailto:fjwc...@gmail.com <mailto:fjwc...@gmail.com>>

    This also has the handy side effect of allowing you to switch to
    booting with UEFI, which currently uses an 800kb fat file system

​And I'm pretty sure I read somewhere that the 10.x installer defaults
to using "-a 1M" when partitioning new disks, although I haven't installed ​
​any 10.x systems from scratch yet (just upgrades from 9.x).​

Freddie Cash
fjwc...@gmail.com <mailto:fjwc...@gmail.com>

Yes, when I built the 10.x 'ZFS' installer mode, I set it to do the right thing. I'll have to look into making sure UFS via 'sade' does the right thing though

Allan Jude
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to