… There is a thread …
Well, I think a new file system generally, and porting XFS specifically are very much on-topic.For those here, I did not mean to make things go OT -- I simply was replying to someone's chatter on my comments. It got outta hand fast.
I'm out. Good luck guys.
That port was in the tree for less than 24 hours before it was removed in what has been described as a rage commit. Mr. Certner had added it specifically to work around the Python 2 dependency in the Palemoon build. He even went to the trouble of getting the obstreperous Palemoon upstream to agree they were ok with this workaround. He got treated very poorly for his trouble.It's already a port, or do you mean changing all python2 references/uses to use this port? (I know nothing about Tauthon).
… my understanding ZFS does not play nice …
… According to the well known Postgres consultant company 2nd Quadrant ZFS and Postgres do perform really well with ZFS' COW features being turned on. So snaphots and all the advanced stuff. …
… starting to plan wrap up for the chromium/src Py3 migration, actually, we are targeting to stop supporting Py2 by EO2022Q1, but we cannot do that until all test systems are done. …
I get the feeling there are contentious discussions about the Chromium port in particular and the Python 2 build dependency in general that are being conducted behind closed doors. All we see is the fallout …
recordsize 8K checksum skein compression lz4 atime off primarycache all logbias throughput
When SGI open sourced XFS, they put it under GPL so it won’t become part of any BSD licensed OS.Well, I think a new file system generally, and porting XFS specifically are very much on-topic.
Those are generic ZFS + Postgresql howtos. There are significant problems with ZFS (and other COW filesystems) in write-intensive applications. See slide 39 here:PostgreSQL
July 2021, with reference to a 2017 article:
Also from 2017: PostgreSQL + ZFS – Best Practices and Standard Procedures (thanks to Eric A. Borisch for the pointer).
XFS is licensed GPL-2 and is in the Linux kernel so it will likely not ever change to GPL-3. The latter is incompatible with the BSD license, but the former is not. Witness the large chunks of Linux kernel source in graphics/drm-kmod.When SGI open sourced XFS, they put it under GPL so it won’t become part of any BSD licensed OS.
… a lot of the benchmarks out there are suspect because they use ZFS without tuning it for Postgresql's idiosyncrasies. …
I don't get why this is still in ports. Just get rid of this old junk. All ports which depend on it can go too.
… www/qt5-webengine …
There is (only) read-write userspace xfs via fusefs-lklXFS can at best be a port but who will do the work? I suspect the foundation will prioritize funding work that directly goes into FreeBSD. The work is likely to be fairly involved but may be if interested people can raise enough money to support it, it can happen!
When SGI open sourced XFS, they put it under GPL so it won’t become part of any BSD licensed OS.
What should be done, but is likely very difficult, is a better integration of zfs code and virtual memory and caching so that extra copies are avoided.
XFS can at best be a port but who will do the work? I suspect the foundation will prioritize funding work that directly goes into FreeBSD. The work is likely to be fairly involved but may be if interested people can raise enough money to support it, it can happen!
I said it's pretty "ehh' at best. doesn't mean terrible.
The bones of it are good... ish. But the soft-updates system has failed. Soft-updates lost out to journaling and nowadays I/O performance from more modern filesystems is better. We don't need to force everyone who wants decent performance onto ZFS.
In particular, though, I can name three entrenched issues:
1. It's based on 1970s-era technology with all the same deficiencies and short-sighted aspects of it. UFS had a benefit years ago when all the BSDs were relatively speaking the same dialect. Nowadays, none of them really understand each other as each has gone in a different, incompatible direction. The 1970s were nearly 50 years ago, and documentation for the FS is not as good as some better ones.
2. XFS in particular is extremely well documented, enough that making an independent reimplementation of directory structure v2 era XFS is basically quite possible and then merging newer changes in shouldn't be terrible.
3. The amount of work to correctly document UFS2, get it speaking even the OpenBSD dialect (impossible mostly because OpenBSD's is a pure-soft updates version) and get it up to modern performance standards is more work than porting a new filesystem.
4. Even if you did all that it would lack many of the better aspects of say XFS, Reiser4 or other filesystems.
ZFS is bloated. I like it, I use it, but it's bloated and not suitable for all workloads.This says absolutely nothing. Exactly how, and what areas of storage management is UFS lacking in? I'd like to see technical details and benchmarks too. Are you familiar with the GEOM framework in FreeBSD? UFS has been trailing, if not, exceeding Linux's options. (mainly due to GEOM). If your main use case is the desktop or embedded, UFS is perfectly fine. If it's enterprise storage; ZFS is second to none obviously.
fsync= synchronous_commit= wal_sync_method=
… OpenCL would be nice, …
Clean up KDE upgrading in ports, as opposed to pkg.