Any compelling reason to get ready to upgrade to 13?

decuser

decuser

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?
 
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?
 
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.
 
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 said:
Oh yeah, and wasn't OpenZFS supposed to be the default in 13?
Click to expand...
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 :)
 
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.
 
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.
 
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.
 
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 said:
Make use of bectl(8) or beadm(1) before doing major version upgrades.
Click to expand...
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!
 
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!
Click to expand...
there are still zfs checkpoints (not snapshots!) if you worry
 
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!
Click to expand...
Don't upgrade your pool until you're absolutely sure things are working properly.
 
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?
Click to expand...
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. ;)
 
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.
 
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

lists.freebsd.org
 
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.

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.
Click to expand...
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
 
You must log in or register to reply here.
Back
Top