Other XFS on BSD

Note : UFS is very usefull on systems low on memory where ZFS is not an option.

I do not have anything against UFS as I stated here - it still has its uses - https://is.gd/bsdstg - but You have to be REALLY low on memory to not use ZFS :)

For example I have run 2 x 2TB ZFS mirror with 512 MB RAM along with running other services for years and it was stable as rock.

People forget that ZFS without RAM is just as fast as the storage devices below it - with RAM its just faster thanks to ZFS ARC cache.
 
"white paper"
I don't know why a white paper would be an appropriate source of evidence. They are not peer reviewed compared to actual papers and could be biased.

That said, the closest I could find of a traditional UNIX FS was this one (FFS, not UFS). It does discuss some issues with UFS (that said there are loads of different "species" of UFS).

I am interested in reading papers on modern filesytems though. My knowledge of them is fairly basic!
 
If Oko was still around he would call you all idiots and tell you how great HAMMER2 is.

HAMMER2 is a decent filesystem, but it's not portable to other architectures. It appears, like btrfs, to tie certain data structures to the underlying architecture. This is okay for DFBSD, I suppose, not for anything else.

Even supposing I'm wrong, DFBSD in general has anchored itself down to the x86 architecture to the point that separating it will be a pain. You would also need to port the volume management solutions from DFBSD.

OpenBSD and DFBSD are neat OSes, and I don't dislike them. I think they're really really narrowed in scope however.
 
If Oko was still around he would call you all idiots and tell you how great HAMMER2is.
Oko got me hooked on OpenBSD, but I've never understood the HAMMER2 argument. Some reference:
But If I have/can to choose between the two -- HAMMER2 or ZFS, I'll go with HAMMER2. FFS2 works for me, but ZFS is a big no no.

OpenBSD and DFBSD are neat OSes, and I don't dislike them. I think they're really really narrowed in scope however.
Well, OpenBSD has stated that they won't support journaling filesystems. I have to search their mailing-lists to find out what's the rationale behind that. There must be something, which I'm not aware of.
 
OpenBSD claims journaled filesystems are not as performant as soft-updates. This is utter horse crap.

HAMMER2 is VERY unportable based on what I've read, but Matt or someone else working on it can correct me. The last I checked, it links things to system page size, which would break it on anything not x64. As ARM is tier 1, that'd be unacceptable. changing that would break compatibility.
 
kpedersen
It all depends on the goal of the white paper. Over the years I've written for work, a bunch of "white papers". Why? Customer Support/QA would run into issues in the bits of software that I was responsible for, I would walk them through getting the basic information needed to start debugging, your normal "good developer" stuff. After the 5th time repeating the process with different people because they wouldn't talk to each other, I would write up a white paper basically "How feature XYZ works according to the code. A guide to debugging". The focus would be on figuring out "is this a problem" and getting all the information I would need if they had to ask.
The strategy worked. They (CS/QA) started talking to each other more, they started passing the paper to others, they were able to debug 90% of what they ran into and when they got me for help, the conversations were a lot more useful.
So I think the focus of a white paper is important as much as it being peer reviewed (if needed).

DragonFlyBSD: wasn't one of the original FreeBSD notions/charters "Be the best performing on commericial PC hardware"? NetBSD was about "run on anything", OpenBSD was "Secure by default". DFBSD was/is a fork of FreeBSD back in the 4.x/5.0 days (strong feelings about how to increase SMP performance was a major reason if I recall), so I don't think DFBSD lack of ARM support is such a big deal, simply because it's not in their charter. Given that, it's not a fault that HAMMER2 is tied closer to the hardware (my opinion).
 
Journaling vs. Soft Updates, a Usenix 2000 paper by god himself, so M. Kirk McKusick:

Interesting paper. In 2000 the performance of the two approaches was essentially the same:
Our asynchronous journaling and Soft Updates systems perform comparably in most cases. While Soft Updates excels in some meta-data intensive microbenchmarks, the macrobenchmark results are more ambiguous. In three cases Soft Updates and journaling are comparable. In a file intensive news workload, journaling prevails, and in a small ISP workload, Soft Updates prevails.
They did not test against an established journaling filesystem. They tested FFS with soft updates vs. FFS with a couple of different journaling implementations. While the knowledge and credentials of the authors is impressive, I have to wonder if the results would've been different had they compared FFS with soft updates vs a mature journaling FS like XFS.
The contributions of this work are: the design and evaluation of two journaling file systems, both FFS-compatible (i.e., they have the same on-disk structure); a novel journaling architecture where the log is implemented as a stand-alone file system whose services may be used by other file systems or applications apart from the file system; and a quantitative comparison between
Soft Updates and journaling.
They conclude with
Journaling file systems have been in widespread use in the commercial sector for many years (Veritas, IBM’s JFS, Compaq’s AdvFS, HP’s HPFS10, Irix’s XFS), while Soft Updates systems are only beginning to make an appearance. If vendors are to make informed decisions concerning the future of their file systems, analyses such as those presented here are crucial to provide the data from which to make such decisions.
The facts are that 20 years later journaling filesystems dominate the landscape, and soft updates lives in a tiny niche. I'm not one to necessarily follow the herd, but I find it difficult to believe soft updates would've gone neglected for this long if it really had the potential to dramatically improve filesystem performance.
 
reiserfs was awesome but his failings as a human tarnished his work forever.
Ignoring Hans Reiser's personal life ...

ReiserFS was relatively "fast", in particular when used with large systems. I should really say "efficient", since ideally, the file system code itself should not be a bottleneck, instead it should get out of the way between the application and the disk drive. ReiserFS in particular handled the somewhat unusual workloads that occur in scientific computing (supercomputers) pretty well, for example mixes of lots of small files and some humongous files, and unusual layout of directory structures. There are several reasons for that: It used a database-inspired B-tree for much of the metadata (making directory operations relatively efficient when the size of the metadata is unusual), and it the combination of large blocks and suballocation that helps small files (small compared to the block size) be stored efficiently. It has this in common with for example BtrFS (another B-tree based system), and extent-based file systems (which includes XFS, but also ext4, and many short-lived or research systems, extents was hip and cool in the 90s and early 2000s). So far, so good.

The problems with ReiserFS were many. First, while it was efficient in handling partial blocks, that could lead to fragmentation for certain workloads, in particular those with unlucky combinations of file sizes. The stories I kept hearing was that while ReiserFS was pretty fast in many cases, in some cases it was awfully slow. And that is not acceptable to customers; in most cases, it's better to have predictable and reliable mediocre performance, rather than great performance much of the time with awful performance sometimes. Second, even in the bug-free case, it had some out-of-order semantics for metadata operations, which leads users to experience what they think is corruption or data loss (it really isn't, but if a customer thinks their data is scrambled, the customer is right, even if the fault really isn't with the file system). And it had bugs, which sometimes would lead to loss of the B-tree, which even fsck and manual recovery can't fix. Again, just like with performance, key to having happy customers is avoiding the worst case. This led to the jokes about the file system "no only murdering your wife, but also losing your files".

And I started by saying "Ignoring Hans Reiser's personal life". But in reality, you can't ignore it. The development of the file system was completely tied to Hans' way of doing business: he was an egomaniac, thinking of himself as god's gift to software development, with little regard for others. And while some of the ideas he used in his work were indeed good, they were not unique, and the same ideas were used by other developers at the same time. He then built a company by hiring inexpensive coders in the FSU, which is also where he hired women for his enjoyment, including his wife. This style of using coders who didn't have access to the "grand master plan" and were doing piecework fell apart after the center piece of the organization was removed to jail.

Now contrast this with other file systems: Many of then have an identifiable "central father figure" (say Ted Ts'o, Kirk McKusick, Chris Mason, Sage Weil, ...), but they also have a deep bench of people who understand the "why" and the design. This makes their development process scalable.
 
Benchmarks. Wonderfully useless or Wonderfully useful. I don't care what you are benchmarking, it can be cheated. Lots of information available about say benchmarking compilers :)

Personally, my opinion, take it for what you've paid for it, the only useful benchmark is how something performs under your workload.
You care about filesystem consistency under all conditions like sudden power loss? Well it may benchmark slower in normal operations, but it NEVER loses data.
Or you care about some obscure corner case of usage? Well benchmarking that well may cost other places.

Ok. Now we get to my personal opinions :)
A filesystem should ensure consistency of data on the device to the best it can. That means maybe sometimes under specific loads it may be "slow" but on average it's "fast enough".
UFS, softupdates, journaling may have issues on modern devices if you simply pull power, but is that a corner case or normal operation?

I don't know anymore. I like ZFS because of boot environments, I like UFS (2 or whatever you want to call it) because they both work for me, and getting to the root of it, "working for me" is all that really matters.
 
UFS, softupdates, journaling may have issues on modern devices if you simply pull power, but is that a corner case or normal operation?
All this stuff is there to ensure the integrity of meta data only, not the data itself. If you really do care about file loss on power outage, you either should turn off write caches which will give a huge performance loss on most scenarios or use an UPS.
 
OpenBSD claims journaled filesystems are not as performant as soft-updates. This is utter horse crap.

HAMMER2 is VERY unportable based on what I've read, but Matt or someone else working on it can correct me. The last I checked, it links things to system page size, which would break it on anything not x64. As ARM is tier 1, that'd be unacceptable. changing that would break compatibility.
Check this out. Most ARM architectures are actually 32-bit. The only ARM architecture that is actually supported by FreeBSD in Tier 1 is ARMv8, because it is in fact a 64-bit architecture.
 
x64 is the 64-bit version of x86. It doesn't include ARMv8.

If you want 32-bit x86, PowerPC, etc. to have it, you're SOL. Nobody in their right mind would port a filesystem usable by an architecture in terminal decline.
 
x64 is the 64-bit version of x86. It doesn't include ARMv8.

If you want 32-bit x86, PowerPC, etc. to have it, you're SOL. Nobody in their right mind would port a filesystem usable by an architecture in terminal decline.
I think you're mis-reading something... ARMv8 is a 64-bit arch (aarch64), but it's not the same thing as x64.
1638326429225.png

There's still plenty of life left in the 32-bit architecture. Upper bounds on computational limitations can come in quite handy in some applications - but which ones? that's left to the reader as an exercise :p
 
Benchmarks. Wonderfully useless or Wonderfully useful. I don't care what you are benchmarking, it can be cheated. Lots of information available about say benchmarking compilers :)
I'm compelled to uncork two of my favourite W. Edwards Deming quotes:
Without data, you're just another person with an opinion.
And:
In God we trust; All others bring data.

But yeah, benchmarks can, and usually are gamed to produce outcomes that suit the authors' biases. This doesn't render them completely useless if you make some guesses about where those biases lie, however.

Take the McKusick benchmark. Clearly he favors UFS and soft updates since they're both his invention. However, he's an honest person and admits up front that the performance and safety of journaling approaches are comparable to soft updates. This gives us a lower bound for the characteristics of journaling filesystems. Worst case, they're roughly equal to FFS + soft updates.

Larabel is a known Linux fanboi and is either ignorant of or uninterested in the BSDs. This means we can safely ignore anything he says about the BSDs in general and UFS in particular. His benchmarks where he compares Linux to Linux are not useless, though. For example this one where he compares the performance of various filesystems under Linux. I do not detect any pro-XFS bias in his writings. Therefore I conclude that the performance of that filesystem is likely to be impressive.
 
Larabel is a known Linux fanboi and is either ignorant of or uninterested in the BSDs. This means we can safely ignore anything he says about the BSDs in general and UFS in particular. His benchmarks where he compares Linux to Linux are not useless, though. For example this one where he compares the performance of various filesystems under Linux. I do not detect any pro-XFS bias in his writings. Therefore I conclude that the performance of that filesystem is likely to be impressive.
If Phoronix' guy were actually 'ignorant or uninterested in the BSDs', then Phoronix wouldn't have the 'BSD' tag even there. BSD-related news are not a very frequent occurrence at Phoronix, true. But then again, I have yet to see another site that is not a blog, and keeps up with BSD's at a similar (or faster) pace. I do agree that some benchmarking articles are not that well-written, and I sometimes have to make personal mental adjustments as I read through them.
 


sysutils/fusefs-lkl/ Full-featured Linux BTRFS, Ext4, XFS as a FUSE module

<https://cgit.freebsd.org/ports/comm...e?id=eda13277d8a19403893b67dc79512872a9f3832f> in 2015 was sponsored by EMC / Isilon Storage Division.

In addition, from Meet the 2021 FreeBSD Google Summer of Code Students | FreeBSD Foundation:

… aims to make a port of XFS that runs in userland, not the kernel, through the FUSE kernel interface to run on FreeBSD. …
 
FUSE isn't really the point of what I was after. FUSE is neat if you need to read a volume from another system -- it's not a replacement for a proper in-kernel FS and is decidedly off-topic IMHO.

I don't really care either way about FreeBSD's future due to events of the last 2 or so years that have piled up. This attitude of bleeding edge that's not getting backported to a RELEASE kernel, for instance (especially graphics improvements, which should be backported if they fix bugs), the fact the OS has slid further and further away from self-sufficiency, the fact it waited years to add POWERel support, and the fact that half the community wants to fight on the superiority of UFS (which is freaking dumb. There's not a single statistic beyond anecdotes that can back it up), another quarter thinks ZFS ZFS ZFS is the answer, and the last quarter think XFS is ill-suited pr wants to tell people how to spend their time and ability shows how poor the community's priorities are.

I'm not writing this as a ragequit post. But anyone who comes across this thread, perhaps it sheds some light on FreeBSD's utter community dysfunction. This extends to the Discord, IRC, mailing lists etc. I'm going to be stuck on the FreeBSD project until 12.x is thoroughly unusable likely, for better or worse.

The attitudes of several users here and in the foundation thread is simply the wrong mindset... the fact some of them even praise OpenBSD, which is run by a narcissist (I like it when Theo takes apart idiots, sure, but his attitude is in the line of Torvalds -- utterly out of touch with things. I see some of myself in Torvalds and Theo, fwiw, so I'm self-aware) and has made dozens of questionable at best decisions underlines the way in which FOSS discussions often derail from facts, and into cult/religious musings.
 
Notably where the switch from svn to git where developers where checking in code in git and the handbook referred to svn.
The upgrade where you could have sendmail problems if you did not followed the right "etcupdate" order.
Bhyve still has a few sharp edges.
The communication around the increase in size for UEFI booting (it has to be big enough...)
Zpool version upgrades where to loader can have a lower version then base.
 
The attitudes of several users here and in the foundation thread is simply the wrong mindset... the fact some of them even praise OpenBSD, which is run by a narcissist (I like it when Theo takes apart idiots, sure, but his attitude is in the line of Torvalds -- utterly out of touch with things. I see some of myself in Torvalds and Theo, fwiw, so I'm self-aware) and has made dozens of questionable at best decisions underlines the way in which FOSS discussions often derail from facts, and into cult/religious musings.

More rhetorics ...

Richard Stallman was king of rhetorics. He used to jazz around and target projects -- those were refusing to kiss the ring of King Nothing of FSF. Then in 2007, he made the capital mistake of showing up in the OpenBSD mailing-lists, trolling the project and taking dump on BSD in general. They taught him a lesson; Beautifully.

 
Back
Top