Is the production environment using FreeBSD 13.2 or FreeBSD 14.0？

A

Alucn

Is the production environment using FreeBSD 13.2 or FreeBSD 14.0？
The application environment is Nginx, PHP 8.2, MYSQL 8.0.33
Planned to go live around December。
 
What's "the production environment"?

FreeBSD 14.0-RELEASE is not released yet, but expected soon, see https://www.freebsd.org/releases/14.0R/schedule/

By then, both 13.2 and 14.0 will be production releases, so, you decide. And indeed, a ".0" version is slightly more likely to have issues not discovered/fixed during BETA/RC phase, simply because it's the first release to include the majority of changes done on the main branch since the previous major version. Therefore some people prefer to only upgrade their critical machines once the ".1" is released.
 
Potential ZFS data corruption issue

Also, somebody commented:

The overriding, and surprising, issue for me after the last week is that no one developing ZFS appears to know how it works. And this is the exact same problem I observed with the BTRFS developers.
I just switched to ZFS a few months ago because after browsing through the BTRFS developer bug threads I was shocked at their haphazard approach to development and bug detection and correction. Everyone was just guessing, and no one was referring to overall architectural documents, flow charts, or any of the common organizational project structures that were mandatory in my day.
But it now appears that ZFS suffers the exact same disorganization. Everyone, literally, is just guessing. And then running scripts to evaluate the odds that things are actually working correctly. [...]
Click to expand...
 
grahamperrin said:
Alternatively,
Click to expand...

Unfortunately unquoteable.

zirias@ said:
By then, both 13.2 and 14.0 will be production releases, so, you decide. And indeed, a ".0" version is slightly more likely to have issues not discovered/fixed during BETA/RC phase, simply because it's the first release to include the majority of changes done on the main branch since the previous major version. Therefore some people prefer to only upgrade their critical machines once the ".1" is released.
Click to expand...

As long as there's no push to downgrade or deprecate earlier documentation, people can make up their own minds on their own experiences.

I'm excessively overcautious on major upgrades, but there seem already enough issues emerging to suggest caution on this .0 (p0) release for production systems, just yet.
 
grahamperrin said:
IMHO (agreeing with a privately-made suggestion):
  • after 14.0-RELEASE is announced, 14.0 should be the default for new installations.
Click to expand...
Not a good idea for production machines that presumably perform some critical function(s) for the organization (or person). New installations will likely use newer model machines for which FreeBSD support often lags behind so they may run into even more problems. Best to try out a new major (i.e. M.0) release on test machines first as SirDice suggests. This is less of a concern for a minor release but even there you can run into problems.

A new FreeBSD user, installing a major release on a new model machine will often end up getting frustrated and not trying FreeBSD again. If you are an experienced FreeBSD user, you will at least be able to fall back to a previous working version. Now if you are a FreeBSD developer, you should certainly "eat your own dog food"!
 
smithi said:
… there seem already enough issues emerging to suggest caution on this .0 (p0) release for production systems, just yet. …
Click to expand...

From <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275308#c32>

… 14.0, 13.2, and 12.4. …
Click to expand...

The dependency tree for 14.0-erratas:
bakul said:
… A new FreeBSD user, installing a major release on a new model machine will often end up getting frustrated …
Click to expand...

Frustration is more likely with 13.2-RELEASE⋯ than with 14.0-RELEASE-p1.
 
Attempt to upgrade a pristine 14.0 on UFS hangs:

Code: 
root@freebsd14:~# freebsd-update fetch
...
Applying patches... ^C^C^C^C^C^C

Processes seem to hang at waitrunningbufspace():

Code: 
root@freebsd14:~# ps auxww | egrep '[0-9] +D[a-zA-Z+ ]'
root  5805   0.0 25.2 204288 123632  0  DLC+ 14:18    0:01.58 bspatch OLD NEW 09227ac6f9f7a38e513a61f294c033d7111bc79841c0eebe490be593e593b8fc-f53e01e8b7859963beb32b1dca2c76dc7ce6a1f17383d525259b83848e913586
root  6381   0.0  2.0  24976  10052  1  D    14:36    0:00.09 pkg install htop
root  6520   0.0  1.8  24232   8608  1  D    14:39    0:00.01 pkg install htop

root@freebsd14:~# procstat -kk 6520 6381 5805
  PID    TID COMM                TDNAME              KSTACK                       
 6520 100213 pkg                 -                   mi_switch+0xbb sleeplk+0xfa lockmgr_slock_hard+0x393 ffs_lock+0x7d _vn_lock+0x47 vget_finish+0x21 cache_fplookup_final_child+0x49 cache_fplookup+0x4f1 namei+0x112 kern_statat+0xee sys_fstatat+0x27 amd64_syscall+0x109 fast_syscall_common+0xf8 
 6381 100132 pkg                 -                   mi_switch+0xbb _sleep+0x1f0 waitrunningbufspace+0x76 bufwrite+0x24a vfs_bio_awrite+0x35d ffs_syncvnode+0x3ce kern_fsync+0x1ac amd64_syscall+0x109 fast_syscall_common+0xf8 
 5805 100098 bspatch             -                   mi_switch+0xbb _sleep+0x1f0 waitrunningbufspace+0x76 bufwrite+0x24a softdep_process_journal+0x728 softdep_disk_io_initiation+0x78a ffs_geom_strategy+0x1f0 ufs_strategy+0x83 bufstrategy+0x36 bufwrite+0x1da cluster_wbuild+0x723 cluster_write+0x122 ffs_write+0x3cf VOP_WRITE_APV+0x99 vn_write+0x282 vn_io_fault_doio+0x45 vn_io_fault1+0x167 vn_io_fault+0x14e
 
Matlib said:
Attempt to upgrade a pristine 14.0 on UFS hangs:

Code: 
root@freebsd14:~# freebsd-update fetch
...
Applying patches... ^C^C^C^C^C^C

Processes seem to hang at waitrunningbufspace():

Code: 
root@freebsd14:~# ps auxww | egrep '[0-9] +D[a-zA-Z+ ]'
root  5805   0.0 25.2 204288 123632  0  DLC+ 14:18    0:01.58 bspatch OLD NEW 09227ac6f9f7a38e513a61f294c033d7111bc79841c0eebe490be593e593b8fc-f53e01e8b7859963beb32b1dca2c76dc7ce6a1f17383d525259b83848e913586
root  6381   0.0  2.0  24976  10052  1  D    14:36    0:00.09 pkg install htop
root  6520   0.0  1.8  24232   8608  1  D    14:39    0:00.01 pkg install htop

root@freebsd14:~# procstat -kk 6520 6381 5805
  PID    TID COMM                TDNAME              KSTACK                      
 6520 100213 pkg                 -                   mi_switch+0xbb sleeplk+0xfa lockmgr_slock_hard+0x393 ffs_lock+0x7d _vn_lock+0x47 vget_finish+0x21 cache_fplookup_final_child+0x49 cache_fplookup+0x4f1 namei+0x112 kern_statat+0xee sys_fstatat+0x27 amd64_syscall+0x109 fast_syscall_common+0xf8
 6381 100132 pkg                 -                   mi_switch+0xbb _sleep+0x1f0 waitrunningbufspace+0x76 bufwrite+0x24a vfs_bio_awrite+0x35d ffs_syncvnode+0x3ce kern_fsync+0x1ac amd64_syscall+0x109 fast_syscall_common+0xf8
 5805 100098 bspatch             -                   mi_switch+0xbb _sleep+0x1f0 waitrunningbufspace+0x76 bufwrite+0x24a softdep_process_journal+0x728 softdep_disk_io_initiation+0x78a ffs_geom_strategy+0x1f0 ufs_strategy+0x83 bufstrategy+0x36 bufwrite+0x1da cluster_wbuild+0x723 cluster_write+0x122 ffs_write+0x3cf VOP_WRITE_APV+0x99 vn_write+0x282 vn_io_fault_doio+0x45 vn_io_fault1+0x167 vn_io_fault+0x14e
Click to expand...
My experience with moving to 14.0-RELEASE is the upgrade was very, very slow. It worked but took a long time. Subsequent freebsd-update fetch/install sessions were much faster.
 
Just for your info.
Sakura Internet in Japan switched their shared rental servers for old (and paid) service from 12 to 14 last december. I have no trouble with this switch until now.
 
Do these servers experience a lot of I/O activity?

Pkg repository for 12.4 has already vanished without trace :)

---
Edit: indeed the installer hangs after rebooting to kernel 14.0:
Code: 
$ shutdown -r now
$ freebsd-update install    # (Stuck here)
Click to expand...
and those happened on ZFS too.
 
You must log in or register to reply here.
Back
Top