5 ms·

Some of the highlights: * OpenSSL has been updated to version 1.1.1a (LTS). * Unbound has been updated to version 1.8.1, and DANE-TA has been

Some of the highlights: * OpenSSL has been updated to version 1.1.1a (LTS). * Unbound has been updated to version 1.8.1, and DANE-TA has been enabled by default. * OpenSSH has been updated to version 7.8p1. * Additonal capsicum(4) support has been added to sshd(8). * Clang, LLVM, LLD, LLDB, compiler-rt and libc++ has been updated to version 6.0.1. * The vt(4) Terminus BSD Console font has been update to version 4.46. * The bsdinstall(8) utility now supports UEFI+GELI as an installation option. * The VIMAGE kernel configuration option has been enabled by default. * The NUMA option has been enabled by default in the amd64 GENERIC and MINIMAL kernel configurations. * The netdump(4) driver has been added, providing a facility through which kernel crash dumps can be transmitted to a remote host after a system panic. * The vt(4) driver has been updated with performance improvements, drawing text at rates ranging from 2- to 6-times faster. * Various improvements to graphics support for current generation hardware. * Support for capsicum(4) has been enabled on armv6 and armv7 by default. * The UFS/FFS filesystem has been updated to consolidate TRIM/BIO_DELETE commands, reducing read/write requests due to fewer TRIM messages being sent simultaneously. * The NFS version 4.1 server has been updated to include pNFS server support. * The pf(4) packet filter is now usable within a jail(8) using vnet(9). * The bhyve(8) utility has been updated to add NVMe device emulation. * The bhyve(8) utility is now able to be run withing a jail(8). * Various Lua loader(8) improvements. * KDE has been updated to version 5.12.5.

amaccuish 8y ago
The url that was posted shows that perfectly well.
floatboth 8y ago
And the biggest highlight that wasn't mentioned anywhere in the release notes for some reason… (drum roll) 64-bit inodes!!
- rsync 8y ago
  I assume that is 64-bit inodes for UFS2 ? I would be concerned about the ability to fsck a UFS2 filesystem with enough inodes in it to require 64-bit inodes... As late as 2010/2011 fsck would fail to allocate enough memory to successfully repair a filesystem with <200M inodes ... I have it on good authority (the author of UFS) that there is no reason to use UFS instead of ZFS unless you are severely memory constrained. Perhaps I misunderstand the new feature you are highlighting ?
  - markjdb 8y ago
    No, various kernel entry points have been modified to be able to handle 64-bit inode numbers. UFS itself still uses 32-bit inode numbers.
  - loeg 8y ago
    > I assume that is 64-bit inodes for UFS2 ? No, it's a kernel ABI change such that all of the stat(2), getdirents(2), etc, ABIs take and pass a 64-bit value instead of a 32-bit one. This enables: (1) 64-bit NFS fileservers (2) Direct-pointer "inode" numbers for FUSE filesystems or cd9660/UDF (3) Probably other uses I'm forgetting Additionally, other ABI enhancements were committed as part of the ino64 work: https://svnweb.freebsd.org/base?view=revision&revision=318736 https://svnweb.freebsd.org/base?view=revision&revision=31873... In particular, I'd point you at d_namlen bumping to 16 bits, MNAMELEN to 1024 bytes (from the anemic 88), and nlink_t from 16 bits to 64 bits. None of these are necessarily used in any particular filesystem, yet, but the generic ABI support is now present. > there is no reason to use UFS instead of ZFS unless you are severely memory constrained. Eh, that's an oversimplification. Here a few reasons: (1) Addressing the "severely" in the above: ZFS memory usage is astronomical, and it is sort of designed to be a filer — it thinks all of the RAM is for its use. It eats all of memory for cache (which is fine, that's what any filesystem cache does) but is slow to release memory under pressure. Also, it requires significantly larger caches than most other filesystems to perform acceptably. (2) Database and similar workload performance — ZFS is a CoW filesystem. That has all of the same problems for databases and similar workloads as any other CoW filesystem. Namely, overwritten blocks will be reallocated to a completely different part of disk and you lose any physical contiguity you might have had. This matters on spinning media and is a factor in why ZFS requires large caches to perform acceptably. (3) Journaling. ZFS intent log essentially duplicates the number of bytes written to media. This definitely has benefits (powerfail consistency) but also is an obvious cost. (Also, that same UFS author continues to work on adding UFS features, because Netflix pays him to. Netflix isn't a charity; they've pretty clearly determined that UFS provides better value to them than ZFS. And they have a phenomenal engineering organization, so I'd tend to trust them on that. YMMV, of course; unless you run a CDN, your workload likely isn't anything like Netflix's.)
loeg 8y ago
You've just copy-pasted the first page of the linked article.

amaccuish 8y ago

The url that was posted shows that perfectly well.

floatboth 8y ago

And the biggest highlight that wasn't mentioned anywhere in the release notes for some reason… (drum roll) 64-bit inodes!!

rsync 8y ago
I assume that is 64-bit inodes for UFS2 ? I would be concerned about the ability to fsck a UFS2 filesystem with enough inodes in it to require 64-bit inodes... As late as 2010/2011 fsck would fail to allocate enough memory to successfully repair a filesystem with <200M inodes ... I have it on good authority (the author of UFS) that there is no reason to use UFS instead of ZFS unless you are severely memory constrained. Perhaps I misunderstand the new feature you are highlighting ?
- markjdb 8y ago
  No, various kernel entry points have been modified to be able to handle 64-bit inode numbers. UFS itself still uses 32-bit inode numbers.
- loeg 8y ago
  > I assume that is 64-bit inodes for UFS2 ? No, it's a kernel ABI change such that all of the stat(2), getdirents(2), etc, ABIs take and pass a 64-bit value instead of a 32-bit one. This enables: (1) 64-bit NFS fileservers (2) Direct-pointer "inode" numbers for FUSE filesystems or cd9660/UDF (3) Probably other uses I'm forgetting Additionally, other ABI enhancements were committed as part of the ino64 work: https://svnweb.freebsd.org/base?view=revision&revision=318736 https://svnweb.freebsd.org/base?view=revision&revision=31873... In particular, I'd point you at d_namlen bumping to 16 bits, MNAMELEN to 1024 bytes (from the anemic 88), and nlink_t from 16 bits to 64 bits. None of these are necessarily used in any particular filesystem, yet, but the generic ABI support is now present. > there is no reason to use UFS instead of ZFS unless you are severely memory constrained. Eh, that's an oversimplification. Here a few reasons: (1) Addressing the "severely" in the above: ZFS memory usage is astronomical, and it is sort of designed to be a filer — it thinks all of the RAM is for its use. It eats all of memory for cache (which is fine, that's what any filesystem cache does) but is slow to release memory under pressure. Also, it requires significantly larger caches than most other filesystems to perform acceptably. (2) Database and similar workload performance — ZFS is a CoW filesystem. That has all of the same problems for databases and similar workloads as any other CoW filesystem. Namely, overwritten blocks will be reallocated to a completely different part of disk and you lose any physical contiguity you might have had. This matters on spinning media and is a factor in why ZFS requires large caches to perform acceptably. (3) Journaling. ZFS intent log essentially duplicates the number of bytes written to media. This definitely has benefits (powerfail consistency) but also is an obvious cost. (Also, that same UFS author continues to work on adding UFS features, because Netflix pays him to. Netflix isn't a charity; they've pretty clearly determined that UFS provides better value to them than ZFS. And they have a phenomenal engineering organization, so I'd tend to trust them on that. YMMV, of course; unless you run a CDN, your workload likely isn't anything like Netflix's.)

loeg 8y ago

You've just copy-pasted the first page of the linked article.