# Any compelling reason to get ready to upgrade to 13?



## decuser (Feb 14, 2021)

I have been reading the FreeBSD 13 release notes and trying to glom what new features are going to be in the release and I’m having a difficult go of it. Bhyve seems to be about the biggest recipient of changes, and my favorite calculator, bc, but I’m wondering if anyone knows of any compelling reason to prep to move to this release?


----------



## ShelLuser (Feb 14, 2021)

Well, one compelling reason would be that support for 12.2 (and 11.4) will eventually come to an end.


----------



## decuser (Feb 14, 2021)

Well, sure. Not quite was I was looking for, but yes, that's compelling, at least down the road. Any other reasons of a more immediate nature?


----------



## Beastie7 (Feb 14, 2021)

I would make a decision after the actual release and full release notes are shipped.


----------



## the3ajm (Feb 14, 2021)

For me, since I'm running older GPU hardware and currently experiencing gpu hangs, I've heard there's been some fixes for i915 in the next release so I want to try it out.


----------



## decuser (Feb 14, 2021)

Beastie7, so are you suggesting that all of the new features aren't necessarily reflected at this point (Beta 2)? I was wondering, cuz it sounded an awful lot like a bunch of small fixes outside of the bhyve stuff.


----------



## decuser (Feb 14, 2021)

Oh yeah, and wasn't OpenZFS supposed to be the default in 13?


----------



## Deleted member 66267 (Feb 14, 2021)

ShelLuser said:


> Well, one compelling reason would be that support for 12.2 (and 11.4) will eventually come to an end.


It's long for them to actually EOL. I'm not preparing to upgrade anytime soon. When 11.4 EOL, there is still 12.x.


----------



## Deleted member 66267 (Feb 14, 2021)

decuser said:


> Oh yeah, and wasn't OpenZFS supposed to be the default in 13?


So it's better to see if it works for other people or not before we actually try. I think I'm lucky because my 11.4-p5 is still uses Forth based loader, so I don't have to suffer from the new Lua based loader. It's perhaps the mind set I got from my Windows days, upgrading is costly (it costs real money!), waiting until your system is actually unsupported or if M$ offers good plan to upgrade so you could save the cost. Remember they allowed upgrading for free from Windows 7 to Windows 10 for a while, this time I was trapped, I upgraded to Windows 10 and shortly later I'm on Linux


----------



## richardtoohey2 (Feb 14, 2021)

There's talk of performance improvements but YMMV.  I think it's early days yet.  The new boot loader is pretty.  

For me one of the benefits of trying out the next version - on test machines! - is that if there are any issues I can raise them and improve the quality of the release and also help myself because then the release will work on my hardware.

Also on these forums you see people on EOL versions getting stuck because they discover the new version (that they didn't help test) has issues and now they are in trouble - they can't stay on the EOL version but they can't go to the newer version either.

Obviously not everyone can test, not everyone has got enough hardware, even if you do test on a spare machine that might have different hardware that your main machine or favourite laptop, and so on.

But the more you put in, the more you get out.

And you might also find something new in 13 that floats your boat, just from trying the BETA/RC.

I wouldn't try the BETA or RC versions on anything but spare machines, just in case you hit any major issues.


----------



## rootbert (Feb 14, 2021)

some other things we collected: https://forums.freebsd.org/threads/freebsd-13-features.78114/


----------



## Yze (Feb 14, 2021)

biggest boomer to us: ZFS with encryption support - no more embedding zpool's in GELI containers.
biggest challenge so far to us: gnugrep is now replaced with bsdgrep (commit) by default.

While doing our first test with 13-STABLE we stumbled immediately on some of our scripts do not work anymore which did spawn 'grep'. In a nutshell most where easy to fix - but it's scary how much else might fail in the future. I would recommend to throughly test your stuff before and after upgrading.


----------



## SirDice (Feb 14, 2021)

decuser said:


> but I’m wondering if anyone knows of any compelling reason to prep to move to this release?


graphics/drm-fbsd13-kmod is a major reason for some desktop users.


----------



## scottro (Feb 14, 2021)

For me, so far, I've found that I need 13 for my T495, with Ryzen and an AMD dedicated GPU. X wouldn't work on 12.x.  ZFS will be using version 2, which seems to have several advantages. However, upgrading, vs a clean install, will require some work. (There is a thread about it somewhere on the forums). 

I'm running it on a laptop where I don't do that much. As for my main machine, I probably won't upgrade till I see what problems people have with it. 
So, short answer seems to be the ZFS improvements and performance improvements. Depending upon your use case, this may or not be noticeable.


----------



## decuser (Feb 14, 2021)

I usually export my zfs stuff and do a clean install for major versions. I don't mind doing:

freebsd-update fetch
pkg update; pkg upgrade

for minor versions, but I've been bitten in the past by upgrading majors and having them work fine for a year, but when I went to do a clean install, finding out that something was missing from the new version that the old version had... better to find out early what's missing.


----------



## SirDice (Feb 14, 2021)

Make use of bectl(8) or beadm(1) before doing major version upgrades.


----------



## decuser (Feb 15, 2021)

+1 bectl - only way to fly on updates!


----------



## Deleted member 66267 (Feb 15, 2021)

SirDice said:


> Make use of bectl(8) or beadm(1) before doing major version upgrades.


I always have this question but never asked on this forums. What if the upgrade break ZFS compatibility itself? e.g: new ZFS features and zpool upgraded. Then the boot environments (snapshots in fact) are useless, because reverting to the old BE, the old ZFS doesn't compatible with the upgraded pool, and the final consequence could be the pool mounted as read-only or it's just not able to boot at all! Please correct me if I'm wrong. I created and make use of BEs as other people but I don't really trust them that much if it's about dealing with upgrades!


----------



## rootbert (Feb 15, 2021)

failure said:


> I always have this question but never asked on this forums. What if the upgrade break ZFS compatibility itself? e.g: new ZFS features and zpool upgraded. Then the boot environments (snapshots in fact) are useless, because reverting to the old BE, the old ZFS doesn't compatible with the upgraded pool, and the final consequence could be the pool mounted as read-only or it's just not able to boot at all! Please correct me if I'm wrong. I created and make use of BEs as other people but I don't really trust them that much if it's about dealing with upgrades!


there are still zfs checkpoints (not snapshots!) if you worry


----------



## SirDice (Feb 15, 2021)

failure said:


> I always have this question but never asked on this forums. What if the upgrade break ZFS compatibility itself? e.g: new ZFS features and zpool upgraded. Then the boot environments (snapshots in fact) are useless, because reverting to the old BE, the old ZFS doesn't compatible with the upgraded pool, and the final consequence could be the pool mounted as read-only or it's just not able to boot at all! Please correct me if I'm wrong. I created and make use of BEs as other people but I don't really trust them that much if it's about dealing with upgrades!


Don't upgrade your pool until you're absolutely sure things are working properly.


----------



## olli@ (Feb 15, 2021)

decuser said:


> I have been reading the FreeBSD 13 release notes and trying to glom what new features are going to be in the release and I’m having a difficult go of it. Bhyve seems to be about the biggest recipient of changes, and my favorite calculator, bc, but I’m wondering if anyone knows of any compelling reason to prep to move to this release?


Compelling reason? How about up to 2× performance boost?

There have been some performance-related improvements that are really noticeable, especially on multi-core (multi-thread) CPUs. From the top of my head: better optimizations in LLVM/clang, improved NUMA support, better thread / memory locality (thus CPU caches are more effective, and less overhead for context switches), improved P-state support, new lock-less kernel structures. I probably forgot some.

Together, these improvements give a 2× performance improvement in some benchmarks. For example, see this article at Phoronix. Yeah, I know, Phoronix often writes nonsense, but in this case they’re not too far off.


----------



## Yze (Feb 15, 2021)

time will prove if there is a large performance boots. I am curious to see stability.


----------



## richardtoohey2 (Feb 15, 2021)

The newer jemalloc _seems_ to have stopped MySQL 5.7 rampaging through RAM and straight into swap (until the OOM killer strikes). But I'm doing more testing to make sure I'm looking at the right things. And this is just my one test case of importing data, not an all-round MySQL 5.7 on FreeBSD test.


----------



## usdmatt (Feb 16, 2021)

Honestly, OpenZFS has become a big reason for me *not* to upgrade (at least for a while)

I installed a 13 snapshot to try out encryption but had a few worrying issues so moved back to 12 and everything was fine. I did report these on the mailing list but had nothing back. I use ZFS for a lot of important systems and can’t risk any big regressions.

The 2 issues I had were

1) after sending snapshots of my live data to this system, I noticed the “used” space for my just-sent snapshots was growing even though the system was a backup and all data was untouched. Some were reporting several 100MB of usage in a snapshot with absolutely 0 changes to any data.

2) a scrub slowed to an absolute crawl at 19% - taking half an hour to go 0.01%. before speeding up again several hours later, then crawled again at about 60% until I eventually stopped it 20 hours after starting - never really getting past that second crawl. On a new pool on 12.2 with the same data (approx 300gb Iirc) the scrub completed in just under an hour.

Edit: This was my thread on the mailing list -


			ZFS issues on 13-current snapshot


----------



## wolffnx (Feb 16, 2021)

usdmatt said:


> Honestly, OpenZFS has become a big reason for me *not* to upgrade (at least for a while)
> 
> I installed a 13 snapshot to try out encryption but had a few worrying issues so moved back to 12 and everything was fine. I did report these on the mailing list but had nothing back. I use ZFS for a lot of important systems and can’t risk any big regressions.
> 
> ...


thanks to share your experience,I install from scrach 13.0-BETA2 in one of my machines
I will try to replicate the 2 problems


----------



## wolffnx (Feb 16, 2021)

For the scrub issue, for my is normal
my setup is 2 SDD  disks of 120gb in mirror mode for the main system
and 2 HDD of 1TB in mirror mode too for files data(music,etc)
8GB  ddr4 ram
and a intel corei3

the SSD disk took 1:50 to complete at 269M/s
the HDD disk took 1:56:00 to complete at 90.2M/s (starting little slow at 4K,20K..etc, to reach the
max speed)

and the system response fine during the scrub
installing packages, using chromium to watch youtube, pcmanfm to file operations(copy,delete,rename)

so,the speed of the scrub consider the type of disk and speed limitations is fine
and the system response was fine too


----------



## Deleted member 66267 (Feb 17, 2021)

rootbert said:


> there are still zfs checkpoints (not snapshots!) if you worry


And this is ZoL/ZoF only which our previous ZFS doesn't support. It doesn't help in the situation I described at all.


----------



## rootbert (Feb 17, 2021)

failure said:


> And this is ZoL/ZoF only which our previous ZFS doesn't support. It doesn't help in the situation I described at all.


zfs checkpoints are supported in current FreeBSD versions and were created to revert to a known good status of the filesystem (version) in case we upgrade a zpool. In your case I would first checkpoint the filesystem, then upgrade to FreeBSD 13 and assert that everything went fine. Then you should upgrade the pool to the new version of ZFS. In case you encounter an error with ZFS you can use a livesystem and then revert to the checkpoint, meaning everything undone until then (also snapshots etc.) ... the reason zfs checkpoints were created was mainly for upgrading pools to newer ZFS versions.


----------



## wolffnx (Feb 18, 2021)

I dont know is relevant now, but I made a 644Gb send/receive with another machine and everything runs just fine from one HDD 1TB disk to another HDD 1TB disk at max speed (100mb/ps)
trought one crossover patchcore from card to card


----------

