Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-31 Thread Mark Martinec

2017-01-27 01:09, Allan Jude wrote:

Yeah, most of the size is from the GELI support, not Skein, so that is
your best starting place.


On a tangential ... does the gptzfsboot really support skein checksums
in 11.0?  If so, then why does zfs not allow setting skein on a root 
pool?


  # zfs set checksum=skein xxx
  cannot set property for 'xxx': property setting is not allowed on root 
pools



Mark
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-31 Thread Volodymyr Kostyrko

Shawn Webb wrote:

On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:

On 2017-01-27 12:05, Warner Losh wrote:

On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome  wrote:



On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya)  
wrote:

Hi,
  I tried upgrading one of my workstations and unfortunately the 
freebsd-boot partition is too small (I follow manpage directions, exactly, and 
those seem to be too small as of 10.3-RELEASE timeframe), and I don???t have 
enough space or ability to resize the partition and make it bigger. So, I???m 
in need of a build knob to control the bloat, and/or having an alternative boot 
loader without geli/skein/crypto support compiled in. Would you be opposed to 
the work?
Thanks,
-Ngie



I do agree that since the geli knob is already there, it may do. Of course we 
also can think of additional knobs, but there is an issue - it wont help just 
to exclude some files, the additional features also do sit in the code, so the 
replacement stubs will be needed, also testing them all over will take some 
time. And the preprocessor spaghetti really is nasty thing to deal with;)

And then there is another issue (partly why I did the feature support in first 
place) - as the kernel does not block user from enabling the features, the user 
can end up facing non-bootable setup which is also not good, as user is using 
perfectly legal options, and still the whole thing is just rendered unusable???


I'm curious why you can't find the space for a bigger partition?
Almost all drives these days are partitioned with a little wasted
space, and that wasted space should be more than enough to cover us
here. Also, most drives have a swap partition that can be shrunk a
trivial amount to get space for this...

Warner



I need to do some testing to make a recipe that works for it, but the
other option is to use the ZFS bootcode area.

ZFS it self, reserves something like 3.5 mb of space in the ZFS
partition, for boot code. This is how we boot ZFS on MBR.

It should be possible to use this on GPT as well, we just don't.


In the future, maybe it'd be a good idea for the installer to leave
more space (a few MB, perhaps?) between the freebsd-boot and
freebsd-swap partitions? At least, for ZFS installs.


This would do anything. If you have swap after the boot partition you 
always can drop the swap, make larger boot and create the swap back on 
the free space.


--
Sphinx of black quartz judge my vow.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"