Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Alexey Dokuchaev]

On Tue, Jan 21, 2020 at 12:33:11AM +0700, Eugene Grosbein wrote:
> 21.01.2020 0:22, Alexey Dokuchaev wrote:
> > On Fri, Jan 17, 2020 at 08:17:11PM +0700, Eugene Grosbein wrote:
> >> ...
> >> It was fine before clang-[78]. Buy nowadays, yes, I'm forced to use
> >> multiple knobs for src.conf
> >>
> >> WITHOUT_LLVM_TARGET_ALL=
> >> WITH_LLVM_TARGET_X86=
> >> WITHOUT_CLANG_FULL=
> > 
> > Thanks, I've added them (with =yes part) to my /etc/src.conf as well.
> > I've noticed I also have WITHOUT_CLANG_EXTRAS=yes there, is this one
> > still needed/does any good?
> 
> Take a look at src/usr.bin/clang/Makefile, it seems WITH_CLANG_EXTRAS
> enables building multiple utilities like llvm versions of ar, as, nm,
> objcopy, objdump etc.

Hmm, I do have those (under /usr/bin) and they don't seem like being
*extras* but rather essential part of the toolchain.  I'll take a closer
look, perhaps I've added WITHOUT_CLANG_EXTRAS=yes *after* my last build
of the world, thanks.

./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Eugene Grosbein]

21.01.2020 0:22, Alexey Dokuchaev wrote:
> On Fri, Jan 17, 2020 at 08:17:11PM +0700, Eugene Grosbein wrote:
>> ...
>> It was fine before clang-[78]. Buy nowadays, yes, I'm forced to use
>> multiple knobs for src.conf
>>
>> WITHOUT_LLVM_TARGET_ALL=
>> WITH_LLVM_TARGET_X86=
>> WITHOUT_CLANG_FULL=
> 
> Thanks, I've added them (with =yes part) to my /etc/src.conf as well.
> I've noticed I also have WITHOUT_CLANG_EXTRAS=yes there, is this one
> still needed/does any good?

Take a look at src/usr.bin/clang/Makefile, it seems WITH_CLANG_EXTRAS
enables building multiple utilities like llvm versions of ar, as, nm, objcopy, 
objdump etc.


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

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Alexey Dokuchaev]

On Fri, Jan 17, 2020 at 08:17:11PM +0700, Eugene Grosbein wrote:
> ...
> It was fine before clang-[78]. Buy nowadays, yes, I'm forced to use
> multiple knobs for src.conf
> 
> WITHOUT_LLVM_TARGET_ALL=
> WITH_LLVM_TARGET_X86=
> WITHOUT_CLANG_FULL=

Thanks, I've added them (with =yes part) to my /etc/src.conf as well.
I've noticed I also have WITHOUT_CLANG_EXTRAS=yes there, is this one
still needed/does any good?

./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Eugene Grosbein]

17.01.2020 21:08, Slawa Olhovchenkov wrote:

> I am cleary understund you provide expirence from satble/10 to
> current/13?
> w/ different clang, kernel, etc?

No, I'm talking about production and recent stable/11.

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

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Slawa Olhovchenkov]

On Fri, Jan 17, 2020 at 08:17:11PM +0700, Eugene Grosbein wrote:

>  Considering /usr/ports, /usr/src and /usr/obj and amount of RAM
>  needed to keep metadata in ZFS ARC
> >>>
> >>> /usr/ports, /usr/src and /usr/obj don't need be exist on low-RAM
> >>> install -- use poudriere and release build on dedicated build host and
> >>> applay binary update.
> >>
> >> Poudriere itself has its disadvantages. It's heavy and it's unable to 
> >> produce minimal set of target packages
> >> suitable for "pkg install -U *.txz" command without build-only 
> >> dependencies.
> > 
> > Can you do it by /usr/ports way? No. And what you point?
> 
> I can and I do, with my own scripts.
> 
> >> I'd like to stick with poudriere but could not. Its supposed work-style 
> >> does not worth it.
> >>
> >> Real Work (TM) sometimes presents the need to apply patches, so
> >> /usr/src and /usr/obj may become are unavoidable.
> > 
> > I am do w/ dedicated builhost, produce custom build of
> > base.txz/kernel.txz/kernel.CUSTOM.txz and applay binary updates w/ BE.
> > What you point?
> 
> The virtual guest is stand-alone including upgrades, does not depend on build 
> host nor its existance.
> 
> >> 1GB-RAM UFS system runs just fine with such trees being stand-alone and 
> >> does not require extra build system and nor its overhead.
> > 
> > clang very hard to compile in 1GB RAM.
> 
> It was fine before clang-[78]. Buy nowadays, yes, I'm forced to use multiple 
> knobs for src.conf
> 
> WITHOUT_LLVM_TARGET_ALL=
> WITH_LLVM_TARGET_X86=
> WITHOUT_CLANG_FULL=
> 
> And using WITH_META_MODE not cleaning obj directory.
> 
> > Anyway, my 1GB ZFS system run just fine.
> 
> During life-time of stable/10 and early stable/11 (and not so-early)
> ZFS required hard tuning for 1GB i386 system to be stable because it's 
> KVM-hog.

I am cleary understund you provide expirence from satble/10 to
current/13?
w/ different clang, kernel, etc?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Eugene Grosbein]

17.01.2020 19:58, Slawa Olhovchenkov wrote:

 Considering /usr/ports, /usr/src and /usr/obj and amount of RAM
 needed to keep metadata in ZFS ARC
>>>
>>> /usr/ports, /usr/src and /usr/obj don't need be exist on low-RAM
>>> install -- use poudriere and release build on dedicated build host and
>>> applay binary update.
>>
>> Poudriere itself has its disadvantages. It's heavy and it's unable to 
>> produce minimal set of target packages
>> suitable for "pkg install -U *.txz" command without build-only dependencies.
> 
> Can you do it by /usr/ports way? No. And what you point?

I can and I do, with my own scripts.

>> I'd like to stick with poudriere but could not. Its supposed work-style does 
>> not worth it.
>>
>> Real Work (TM) sometimes presents the need to apply patches, so
>> /usr/src and /usr/obj may become are unavoidable.
> 
> I am do w/ dedicated builhost, produce custom build of
> base.txz/kernel.txz/kernel.CUSTOM.txz and applay binary updates w/ BE.
> What you point?

The virtual guest is stand-alone including upgrades, does not depend on build 
host nor its existance.

>> 1GB-RAM UFS system runs just fine with such trees being stand-alone and does 
>> not require extra build system and nor its overhead.
> 
> clang very hard to compile in 1GB RAM.

It was fine before clang-[78]. Buy nowadays, yes, I'm forced to use multiple 
knobs for src.conf

WITHOUT_LLVM_TARGET_ALL=
WITH_LLVM_TARGET_X86=
WITHOUT_CLANG_FULL=

And using WITH_META_MODE not cleaning obj directory.

> Anyway, my 1GB ZFS system run just fine.

During life-time of stable/10 and early stable/11 (and not so-early)
ZFS required hard tuning for 1GB i386 system to be stable because it's KVM-hog.


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

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Slawa Olhovchenkov]

On Fri, Jan 17, 2020 at 07:35:02PM +0700, Eugene Grosbein wrote:

> 17.01.2020 18:21, Slawa Olhovchenkov wrote:
> 
> >> Considering /usr/ports, /usr/src and /usr/obj and amount of RAM
> >> needed to keep metadata in ZFS ARC
> > 
> > /usr/ports, /usr/src and /usr/obj don't need be exist on low-RAM
> > install -- use poudriere and release build on dedicated build host and
> > applay binary update.
> 
> Poudriere itself has its disadvantages. It's heavy and it's unable to produce 
> minimal set of target packages
> suitable for "pkg install -U *.txz" command without build-only dependencies.

Can you do it by /usr/ports way? No. And what you point?

> I'd like to stick with poudriere but could not. Its supposed work-style does 
> not worth it.
> 
> Real Work (TM) sometimes presents the need to apply patches, so
> /usr/src and /usr/obj may become are unavoidable.

I am do w/ dedicated builhost, produce custom build of
base.txz/kernel.txz/kernel.CUSTOM.txz and applay binary updates w/ BE.
What you point?

> 1GB-RAM UFS system runs just fine with such trees being stand-alone and does 
> not require extra build system and nor its overhead.

clang very hard to compile in 1GB RAM.
Anyway, my 1GB ZFS system run just fine.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Eugene Grosbein]

17.01.2020 18:21, Slawa Olhovchenkov wrote:

>> Considering /usr/ports, /usr/src and /usr/obj and amount of RAM
>> needed to keep metadata in ZFS ARC
> 
> /usr/ports, /usr/src and /usr/obj don't need be exist on low-RAM
> install -- use poudriere and release build on dedicated build host and
> applay binary update.

Poudriere itself has its disadvantages. It's heavy and it's unable to produce 
minimal set of target packages
suitable for "pkg install -U *.txz" command without build-only dependencies.
I'd like to stick with poudriere but could not. Its supposed work-style does 
not worth it.

Real Work (TM) sometimes presents the need to apply patches, so /usr/src and 
/usr/obj may become are unavoidable.
1GB-RAM UFS system runs just fine with such trees being stand-alone and does 
not require extra build system and nor its overhead.

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

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Slawa Olhovchenkov]

On Thu, Jan 16, 2020 at 04:19:52PM -0800, Devin Teske wrote:

> 
> 
> > On Jan 16, 2020, at 16:03, Slawa Olhovchenkov  wrote:
> > 
> > On Thu, Jan 16, 2020 at 02:43:37PM +0700, Eugene Grosbein wrote:
> > 
> >> 16.01.2020 4:41, Ed Maste wrote:
> >> 
> >>> On Wed, 15 Jan 2020 at 16:10, Eugene Grosbein  wrote:
>  
>  There are multiple scenarios there ZFS may be sub-optimal at least: 
>  small i386 virtual guests
>  or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems 
>  with bhyve and multiple guests
>  that need lots of memory and should not fight with ZFS for RAM etc.
> >>> 
> >>> That may well be the case, but our defaults should represent the
> >>> configuration that's desirable to the largest set of users, and IMO
> >>> that's ZFS in most cases today.
> >>> 
> >>> It might be that we should default to UFS on i386 and ZFS on amd64?
> >> 
> >> UFS may be better for any virtual guest having RAM less or equal to 4GB.
> > 
> > Why?
> 
> ZFS does not do any auto-tuning in that situation and you’ll quickly
> find you’ll have a dozen or more tunables in loader.conf tailored to
> your workload. Even moderate workloads require tuning in i386 and/or
> <=4GB environments with ZFS.

This (auto-tuning) can be fixed, I am do this.

> It is also highly inadvisable to mix UFS and ZFS — memory pressure from ARC 
> can cause UFS cache evictions and vice-versa.

May be, don't test
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Slawa Olhovchenkov]

On Fri, Jan 17, 2020 at 12:12:22PM +0700, Eugene Grosbein wrote:

> 17.01.2020 7:03, Slawa Olhovchenkov write:
> 
>  There are multiple scenarios there ZFS may be sub-optimal at least: 
>  small i386 virtual guests
>  or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems 
>  with bhyve and multiple guests
>  that need lots of memory and should not fight with ZFS for RAM etc.
> >>>
> >>> That may well be the case, but our defaults should represent the
> >>> configuration that's desirable to the largest set of users, and IMO
> >>> that's ZFS in most cases today.
> >>>
> >>> It might be that we should default to UFS on i386 and ZFS on amd64?
> >>
> >> UFS may be better for any virtual guest having RAM less or equal to 4GB.
> > 
> > Why?
> 
> Considering /usr/ports, /usr/src and /usr/obj and amount of RAM
> needed to keep metadata in ZFS ARC

/usr/ports, /usr/src and /usr/obj don't need be exist on low-RAM
install -- use poudriere and release build on dedicated build host and
applay binary update.

> plus standard daily periodic scripts traveling filesystems, low-RAM virtual 
> machine utilizing its RAM to full amount
> can work reliably with UFS and hang at nights due to extra ZFS overhead in 
> default install (not tuned).

Just need fix ZFS ARC pressure and UMA zone reclaim.
ZFS ARC overhead about 10-20MB (IMHO) on low-RAM install. This is
negligible from 512MB.

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

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Eugene Grosbein]

17.01.2020 7:03, Slawa Olhovchenkov write:

 There are multiple scenarios there ZFS may be sub-optimal at least: small 
 i386 virtual guests
 or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems with 
 bhyve and multiple guests
 that need lots of memory and should not fight with ZFS for RAM etc.
>>>
>>> That may well be the case, but our defaults should represent the
>>> configuration that's desirable to the largest set of users, and IMO
>>> that's ZFS in most cases today.
>>>
>>> It might be that we should default to UFS on i386 and ZFS on amd64?
>>
>> UFS may be better for any virtual guest having RAM less or equal to 4GB.
> 
> Why?

Considering /usr/ports, /usr/src and /usr/obj and amount of RAM needed to keep 
metadata in ZFS ARC
plus standard daily periodic scripts traveling filesystems, low-RAM virtual 
machine utilizing its RAM to full amount
can work reliably with UFS and hang at nights due to extra ZFS overhead in 
default install (not tuned).

Been there, seen that.

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

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Slawa Olhovchenkov]

On Thu, Jan 16, 2020 at 02:43:37PM +0700, Eugene Grosbein wrote:

> 16.01.2020 4:41, Ed Maste wrote:
> 
> > On Wed, 15 Jan 2020 at 16:10, Eugene Grosbein  wrote:
> >>
> >> There are multiple scenarios there ZFS may be sub-optimal at least: small 
> >> i386 virtual guests
> >> or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems with 
> >> bhyve and multiple guests
> >> that need lots of memory and should not fight with ZFS for RAM etc.
> > 
> > That may well be the case, but our defaults should represent the
> > configuration that's desirable to the largest set of users, and IMO
> > that's ZFS in most cases today.
> > 
> > It might be that we should default to UFS on i386 and ZFS on amd64?
> 
> UFS may be better for any virtual guest having RAM less or equal to 4GB.

Why?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Devin Teske]

> On Jan 16, 2020, at 01:01, Kubilay Kocak  wrote:
> 
> On 16/01/2020 7:27 pm, Colin Percival wrote:
>> On 2020-01-15 21:07, Philip Paeps wrote:
>>> On 2020-01-16 04:57:28 (+1000), Oliver Pinter wrote:
 On Wednesday, January 15, 2020, Ben Woods  wrote:
>   bsdinstall: Change "default" (first) Partitioning method to ZFS
>>> 
 Plus I miss from here the relontes tag.
>>> 
>>> I'm not sure if this merits a release notes entry but ... sure.
>>> 
>>> There is not actually a functional change here.  It's just a defaults 
>>> change.
>> I'd say that a change in defaults is far more deserving of being mentioned
>> in the release notes than, say, adding a new feature.  Nobody will trip over
>> new features by mistake, but there's probably someone out there who is used
>> to holding down the Enter key in the installer and expects to get UFS.
> 
> +1 on changing the default. This doesn't preclude UFS systems or reduce 
> choice (we value choice).
> 
> +0 on tweaking it or setting exceptions if and where necessary, as long as it 
> doesn't result in more than minimal fragmentation between 
> versions/archs/install types: this is also a POLA issue. I don't oin its own 
> consider "4gb systems" as necessary.
> 
> +1 RELNOTES, we value POLA.
> 

-1 on (mentioned somewhere in the thread) dynamic menu items that change based 
on hardware. Muscle memory is not bad.
— 
Devin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Kubilay Kocak]

On 16/01/2020 7:27 pm, Colin Percival wrote:

On 2020-01-15 21:07, Philip Paeps wrote:

On 2020-01-16 04:57:28 (+1000), Oliver Pinter wrote:

On Wednesday, January 15, 2020, Ben Woods  wrote:

   bsdinstall: Change "default" (first) Partitioning method to ZFS



Plus I miss from here the relontes tag.


I'm not sure if this merits a release notes entry but ... sure.

There is not actually a functional change here.  It's just a defaults change.


I'd say that a change in defaults is far more deserving of being mentioned
in the release notes than, say, adding a new feature.  Nobody will trip over
new features by mistake, but there's probably someone out there who is used
to holding down the Enter key in the installer and expects to get UFS.



+1 on changing the default. This doesn't preclude UFS systems or reduce 
choice (we value choice).


+0 on tweaking it or setting exceptions if and where necessary, as long 
as it doesn't result in more than minimal fragmentation between 
versions/archs/install types: this is also a POLA issue. I don't oin its 
own consider "4gb systems" as necessary.


+1 RELNOTES, we value POLA.

More things in RELNOTES not less
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Colin Percival]

On 2020-01-15 21:07, Philip Paeps wrote:
> On 2020-01-16 04:57:28 (+1000), Oliver Pinter wrote:
>> On Wednesday, January 15, 2020, Ben Woods  wrote:
>>>   bsdinstall: Change "default" (first) Partitioning method to ZFS
> 
>> Plus I miss from here the relontes tag.
> 
> I'm not sure if this merits a release notes entry but ... sure.
> 
> There is not actually a functional change here.  It's just a defaults change.

I'd say that a change in defaults is far more deserving of being mentioned
in the release notes than, say, adding a new feature.  Nobody will trip over
new features by mistake, but there's probably someone out there who is used
to holding down the Enter key in the installer and expects to get UFS.

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Eugene Grosbein]

16.01.2020 4:41, Ed Maste wrote:

> On Wed, 15 Jan 2020 at 16:10, Eugene Grosbein  wrote:
>>
>> There are multiple scenarios there ZFS may be sub-optimal at least: small 
>> i386 virtual guests
>> or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems with 
>> bhyve and multiple guests
>> that need lots of memory and should not fight with ZFS for RAM etc.
> 
> That may well be the case, but our defaults should represent the
> configuration that's desirable to the largest set of users, and IMO
> that's ZFS in most cases today.
> 
> It might be that we should default to UFS on i386 and ZFS on amd64?

Also, size of the media should be considered as ZFS is not feasible for small 
media.
That is, ZFS has its minimum system requirements that should not be ignored by 
installer.

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

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Eugene Grosbein]

16.01.2020 4:41, Ed Maste wrote:

> On Wed, 15 Jan 2020 at 16:10, Eugene Grosbein  wrote:
>>
>> There are multiple scenarios there ZFS may be sub-optimal at least: small 
>> i386 virtual guests
>> or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems with 
>> bhyve and multiple guests
>> that need lots of memory and should not fight with ZFS for RAM etc.
> 
> That may well be the case, but our defaults should represent the
> configuration that's desirable to the largest set of users, and IMO
> that's ZFS in most cases today.
> 
> It might be that we should default to UFS on i386 and ZFS on amd64?

UFS may be better for any virtual guest having RAM less or equal to 4GB.

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

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Philip Paeps]

On 2020-01-16 04:57:28 (+1000), Oliver Pinter wrote:
On Wednesday, January 15, 2020, Ben Woods  
wrote:

Author: woodsb02 (ports committer)
Date: Wed Jan 15 07:47:52 2020
New Revision: 356758
URL: https://svnweb.freebsd.org/changeset/base/356758

Log:
  bsdinstall: Change "default" (first) Partitioning method to ZFS

  Reported by:  Ruben Schade (during his talk at linux.conf.au)
  Approved by:  philip
  Differential Revision:https://reviews.freebsd.org/D23173


What's the justification behind this change?


This came up during the Q&A after my ZFS talk at Linux.conf.au earlier 
this week.  Someone pointed out that if you install FreeBSD without 
engaging your brain and "just press enter a few times", you'll get a UFS 
system.  In the vast majority of cases where you install FreeBSD like 
that, you really actually want a ZFS system.


As Ed wrote elsewhere in this thread, the installer "defaults" should be 
what most people actually want.


Note that Ben's patch doesn't actually make it any more difficult to get 
a UFS system if anyone wants that.  The only thing it does is move ZFS 
to the top of the list of options so "enter enter enter" gets you a ZFS 
system instead of a UFS system.



Plus I miss from here the relontes tag.


I'm not sure if this merits a release notes entry but ... sure.

There is not actually a functional change here.  It's just a defaults 
change.


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Pedro Giffuni]

On 15/01/2020 16:41, Ed Maste wrote:

On Wed, 15 Jan 2020 at 16:10, Eugene Grosbein  wrote:

There are multiple scenarios there ZFS may be sub-optimal at least: small i386 
virtual guests
or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems with 
bhyve and multiple guests
that need lots of memory and should not fight with ZFS for RAM etc.

That may well be the case, but our defaults should represent the
configuration that's desirable to the largest set of users, and IMO
that's ZFS in most cases today.


There is also the policy of not making copyleft code mandatory 
(technically, CDDL is weak copyleft).


If ZFS is disabled in the build, the installer should gracefully disable 
it too.




It might be that we should default to UFS on i386 and ZFS on amd64?


FWIW, I still use ZFS for root, because of the older MBR and the need to 
multiboot.


Pedro.

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

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Ed Maste]

On Wed, 15 Jan 2020 at 16:10, Eugene Grosbein  wrote:
>
> There are multiple scenarios there ZFS may be sub-optimal at least: small 
> i386 virtual guests
> or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems with 
> bhyve and multiple guests
> that need lots of memory and should not fight with ZFS for RAM etc.

That may well be the case, but our defaults should represent the
configuration that's desirable to the largest set of users, and IMO
that's ZFS in most cases today.

It might be that we should default to UFS on i386 and ZFS on amd64?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Eugene Grosbein]

16.01.2020 3:32, Warner Losh wrote:

> unless your work load hits the fairly narrow range where ZFS isn't so good.
> 
> [*] Netflix uses UFS because of sendfile efficiencies

There are multiple scenarios there ZFS may be sub-optimal at least: small i386 
virtual guests
or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems with 
bhyve and multiple guests
that need lots of memory and should not fight with ZFS for RAM etc.

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

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Warner Losh]

On Wed, Jan 15, 2020 at 12:10 PM Nathan Whitehorn 
wrote:

> I agree -- this seems like a really big change, especially with no
> discussion.
>

I agree this is the right thing to do. ZFS is the best fit for most people
(there are exceptions, and they can install UFS and if ZFS isn't right for
you, you're likely well aware of it[*]). ZFS is a huge asset to FreeBSD,
and we should lead with strength. And the UFS option is there for people
that don't want ZFS. Nothing changes there...

In an ideal world, it likely should have been socialized first on arch@
(it's likely still good to chat about it there). It would likely be good to
kick off a discussion there, but honestly, this should be a fairly boring,
bland change for most people in our core, target market. There's little
compelling reason to not use ZFS, unless your work load hits the fairly
narrow range where ZFS isn't so good.

Warner

[*] Netflix uses UFS because of sendfile efficiencies, but we don't use the
installer to install our systems: we have our own custom one our system
integrators use since it has a lot of extra specific checks we need, but
that aren't relevant to others. And my personal systems are almost all ZFS
(the ones that aren't date from a time that ZFS wasn't in the system, or
too new for me to trust it).


> -Nathan
>
> On 2020-01-15 10:57, Oliver Pinter wrote:
> >
> >
> > On Wednesday, January 15, 2020, Ben Woods  > > wrote:
> >
> > Author: woodsb02 (ports committer)
> > Date: Wed Jan 15 07:47:52 2020
> > New Revision: 356758
> > URL: https://svnweb.freebsd.org/changeset/base/356758
> > 
> >
> > Log:
> >   bsdinstall: Change "default" (first) Partitioning method to ZFS
> >
> >   Reported by:  Ruben Schade (during his talk at linux.conf.au
> > )
> >   Approved by:  philip
> >   Differential Revision:https://reviews.freebsd.org/D23173
> > 
> >
> >
> > What's the justification behind this change?
> > Plus I miss from here the relontes tag.
> >
> >
> >
> >
> > Modified:
> >   head/usr.sbin/bsdinstall/bsdinstall.8
> >   head/usr.sbin/bsdinstall/scripts/auto
> >
> > Modified: head/usr.sbin/bsdinstall/bsdinstall.8
> >
>  
> ==
> > --- head/usr.sbin/bsdinstall/bsdinstall.8   Wed Jan 15
> > 06:18:32 2020(r356757)
> > +++ head/usr.sbin/bsdinstall/bsdinstall.8   Wed Jan 15
> > 07:47:52 2020(r356758)
> > @@ -119,7 +119,7 @@ Provides the installer's interactive guided
> > disk parti
> >  installations.
> >  Defaults to UFS.
> >  .It Cm zfsboot
> > -Provides an alternative ZFS-only automatic interactive disk
> > partitioner.
> > +Provides a ZFS-only automatic interactive disk partitioner.
> >  Creates a single
> >  .Ic zpool
> >  with separate datasets for
> >
> > Modified: head/usr.sbin/bsdinstall/scripts/auto
> >
>  
> ==
> > --- head/usr.sbin/bsdinstall/scripts/auto   Wed Jan 15
> > 06:18:32 2020(r356757)
> > +++ head/usr.sbin/bsdinstall/scripts/auto   Wed Jan 15
> > 07:47:52 2020(r356758)
> > @@ -289,7 +289,7 @@ Shell \"Open a shell and partition by hand\""
> >  CURARCH=$( uname -m )
> >  case $CURARCH in
> > amd64|arm64|i386)   # Booting ZFS Supported
> > -   PMODES="$PMODES \"Auto (ZFS)\" \"Guided
> Root-on-ZFS\""
> > +   PMODES="\"Auto (ZFS)\" \"Guided Root-on-ZFS\"
> $PMODES"
> > ;;
> > *)  # Booting ZFS Unspported
> > ;;
> > @@ -303,6 +303,10 @@ PARTMODE=`echo $PMODES | xargs dialog
> > --backtitle "Fre
> >  exec 3>&-
> >
> >  case "$PARTMODE" in
> > +"Auto (ZFS)")  # ZFS
> > +   bsdinstall zfsboot || error "ZFS setup failed"
> > +   bsdinstall mount || error "Failed to mount filesystem"
> > +   ;;
> >  "Auto (UFS)")  # Guided
> > bsdinstall autopart || error "Partitioning error"
> > bsdinstall mount || error "Failed to mount filesystem"
> > @@ -319,10 +323,6 @@ case "$PARTMODE" in
> > else
> > bsdinstall partedit || error "Partitioning error"
> > fi
> > -   bsdinstall mount || error "Failed to mount filesystem"
> > -   ;;
> > -"Auto (ZFS)")  # ZFS
> > -   bsdinstall zfsboot || error "ZFS setup failed"
> > bsdinstall mount || error "Failed to mount filesystem"
> > ;;
> >  *)
> > ___
> > svn-src-h...@freebsd.org  mailing
> > list
> > https://lists.freebsd.org/mailman/list

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Nathan Whitehorn]

I agree -- this seems like a really big change, especially with no
discussion.
-Nathan

On 2020-01-15 10:57, Oliver Pinter wrote:
>
>
> On Wednesday, January 15, 2020, Ben Woods  > wrote:
>
> Author: woodsb02 (ports committer)
> Date: Wed Jan 15 07:47:52 2020
> New Revision: 356758
> URL: https://svnweb.freebsd.org/changeset/base/356758
> 
>
> Log:
>   bsdinstall: Change "default" (first) Partitioning method to ZFS
>
>   Reported by:  Ruben Schade (during his talk at linux.conf.au
> )
>   Approved by:  philip
>   Differential Revision:        https://reviews.freebsd.org/D23173
> 
>
>
> What's the justification behind this change? 
> Plus I miss from here the relontes tag. 
>
>  
>
>
> Modified:
>   head/usr.sbin/bsdinstall/bsdinstall.8
>   head/usr.sbin/bsdinstall/scripts/auto
>
> Modified: head/usr.sbin/bsdinstall/bsdinstall.8
> 
> ==
> --- head/usr.sbin/bsdinstall/bsdinstall.8       Wed Jan 15
> 06:18:32 2020        (r356757)
> +++ head/usr.sbin/bsdinstall/bsdinstall.8       Wed Jan 15
> 07:47:52 2020        (r356758)
> @@ -119,7 +119,7 @@ Provides the installer's interactive guided
> disk parti
>  installations.
>  Defaults to UFS.
>  .It Cm zfsboot
> -Provides an alternative ZFS-only automatic interactive disk
> partitioner.
> +Provides a ZFS-only automatic interactive disk partitioner.
>  Creates a single
>  .Ic zpool
>  with separate datasets for
>
> Modified: head/usr.sbin/bsdinstall/scripts/auto
> 
> ==
> --- head/usr.sbin/bsdinstall/scripts/auto       Wed Jan 15
> 06:18:32 2020        (r356757)
> +++ head/usr.sbin/bsdinstall/scripts/auto       Wed Jan 15
> 07:47:52 2020        (r356758)
> @@ -289,7 +289,7 @@ Shell \"Open a shell and partition by hand\""
>  CURARCH=$( uname -m )
>  case $CURARCH in
>         amd64|arm64|i386)       # Booting ZFS Supported
> -               PMODES="$PMODES \"Auto (ZFS)\" \"Guided Root-on-ZFS\""
> +               PMODES="\"Auto (ZFS)\" \"Guided Root-on-ZFS\" $PMODES"
>                 ;;
>         *)              # Booting ZFS Unspported
>                 ;;
> @@ -303,6 +303,10 @@ PARTMODE=`echo $PMODES | xargs dialog
> --backtitle "Fre
>  exec 3>&-
>
>  case "$PARTMODE" in
> +"Auto (ZFS)")  # ZFS
> +       bsdinstall zfsboot || error "ZFS setup failed"
> +       bsdinstall mount || error "Failed to mount filesystem"
> +       ;;
>  "Auto (UFS)")  # Guided
>         bsdinstall autopart || error "Partitioning error"
>         bsdinstall mount || error "Failed to mount filesystem"
> @@ -319,10 +323,6 @@ case "$PARTMODE" in
>         else
>                 bsdinstall partedit || error "Partitioning error"
>         fi
> -       bsdinstall mount || error "Failed to mount filesystem"
> -       ;;
> -"Auto (ZFS)")  # ZFS
> -       bsdinstall zfsboot || error "ZFS setup failed"
>         bsdinstall mount || error "Failed to mount filesystem"
>         ;;
>  *)
> ___
> svn-src-h...@freebsd.org  mailing
> list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> 
> To unsubscribe, send any mail to
> "svn-src-head-unsubscr...@freebsd.org
> "
>

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

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Oliver Pinter]

On Wednesday, January 15, 2020, Ben Woods  wrote:

> Author: woodsb02 (ports committer)
> Date: Wed Jan 15 07:47:52 2020
> New Revision: 356758
> URL: https://svnweb.freebsd.org/changeset/base/356758
>
> Log:
>   bsdinstall: Change "default" (first) Partitioning method to ZFS
>
>   Reported by:  Ruben Schade (during his talk at linux.conf.au)
>   Approved by:  philip
>   Differential Revision:https://reviews.freebsd.org/D23173


What's the justification behind this change?
Plus I miss from here the relontes tag.



>
> Modified:
>   head/usr.sbin/bsdinstall/bsdinstall.8
>   head/usr.sbin/bsdinstall/scripts/auto
>
> Modified: head/usr.sbin/bsdinstall/bsdinstall.8
> 
> ==
> --- head/usr.sbin/bsdinstall/bsdinstall.8   Wed Jan 15 06:18:32 2020
>   (r356757)
> +++ head/usr.sbin/bsdinstall/bsdinstall.8   Wed Jan 15 07:47:52 2020
>   (r356758)
> @@ -119,7 +119,7 @@ Provides the installer's interactive guided disk parti
>  installations.
>  Defaults to UFS.
>  .It Cm zfsboot
> -Provides an alternative ZFS-only automatic interactive disk partitioner.
> +Provides a ZFS-only automatic interactive disk partitioner.
>  Creates a single
>  .Ic zpool
>  with separate datasets for
>
> Modified: head/usr.sbin/bsdinstall/scripts/auto
> 
> ==
> --- head/usr.sbin/bsdinstall/scripts/auto   Wed Jan 15 06:18:32 2020
>   (r356757)
> +++ head/usr.sbin/bsdinstall/scripts/auto   Wed Jan 15 07:47:52 2020
>   (r356758)
> @@ -289,7 +289,7 @@ Shell \"Open a shell and partition by hand\""
>  CURARCH=$( uname -m )
>  case $CURARCH in
> amd64|arm64|i386)   # Booting ZFS Supported
> -   PMODES="$PMODES \"Auto (ZFS)\" \"Guided Root-on-ZFS\""
> +   PMODES="\"Auto (ZFS)\" \"Guided Root-on-ZFS\" $PMODES"
> ;;
> *)  # Booting ZFS Unspported
> ;;
> @@ -303,6 +303,10 @@ PARTMODE=`echo $PMODES | xargs dialog --backtitle "Fre
>  exec 3>&-
>
>  case "$PARTMODE" in
> +"Auto (ZFS)")  # ZFS
> +   bsdinstall zfsboot || error "ZFS setup failed"
> +   bsdinstall mount || error "Failed to mount filesystem"
> +   ;;
>  "Auto (UFS)")  # Guided
> bsdinstall autopart || error "Partitioning error"
> bsdinstall mount || error "Failed to mount filesystem"
> @@ -319,10 +323,6 @@ case "$PARTMODE" in
> else
> bsdinstall partedit || error "Partitioning error"
> fi
> -   bsdinstall mount || error "Failed to mount filesystem"
> -   ;;
> -"Auto (ZFS)")  # ZFS
> -   bsdinstall zfsboot || error "ZFS setup failed"
> bsdinstall mount || error "Failed to mount filesystem"
> ;;
>  *)
> ___
> svn-src-h...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"