File Systems – ZFS vs. XFS
linuxhint.com
linuxhint.com
I wish I could downvote this article, just for this one point alone. I wonder what kind of benchmarking the author did to come to the conclusion of "searching and fetching the data much faster" and how much the B+ tree of xfs contributed to it. Speed depends on a lot of factors (copy on write, compression, journaling, crash recovery, etc.) and I wonder how the author narrowed it down to the B+ tree of XFS. Also, there could be variants of various B family trees even within a same filesystem. So I am not really sure, what the author means by "XFS has B+ tree implementation".
If you are a RedHat shop and deploy linux extensively already, then xfs may be a better option, if you are not looking for most zfs features like volume management, etc. Also, installation, support etc. would be much easier.
This article is shallow in many ways technically, but arrives at conclusions strongly. It just seems like a paid article to promote zfs.
May be an article on LWN would be more meaningful and technically competent to make a comparison than this.
What should i take away in this sentence? "XFS is optimized for huge files and for parallel I/O this makes it the easier choice for use cases like NASA Advanced Supercomputing Division." The whole post sounds like "ZFS is the superior technology with much more bells and whistles and XFS is old tech but XFS is what you choose if you're the NASA..".
Having interest in XFS/ZFS/BTRFS and what to choose on my machines, i was hoping for some more substantial and objective facts.
MySQL performance bench suite against ZFS vs XFS
https://www.percona.com/blog/2018/05/15/about-zfs-performanc...
I moved the opposite direction (btrfs->zfs) because I had issues with my main btrfs rootfs constantly degrading to read-only mode, causing my system to crash and require rebooting.
With ZFS I’ve had no such issues. ZFS uses noticeably much more RAM though.
The initial install is a bit involved (live-cd, manual partitioning + debootstrap) but everything just works (tm) after that, including booting into specific snapshots from grub.
There’s a good guide on github:
https://github.com/zfsonlinux/zfs/wiki/Ubuntu-18.04-Root-on-...
I've had two major and one minor BTRFS-related issues that have scared me away from it.
1) One of my computers got its BTRFS filesystem into a state where it would hang when trying to mount read/write. What I suspect is that there was some filesystem thing happening in the background when I rebooted the machine. I rebooted via the GUI and there was no sign that something was happening in the background, so this was really a normal thing that a user would do. No amount of fixing was able to get it back, but I was able to boot from the installation media, mount it read-only, and copy the data elsewhere.
2) Virtually all of the Linux servers at work will randomly hang for between minutes and hours. This was eventually traced to a BTRFS-scrub process that the OS vendor schedules to run weekly. The length and impact of the hang seemed to be based on how much write activity happens - servers where all the heavy activity happens on NFS mounts saw no impact, but servers that write a lot of logs to the local filesystem would get severely crippled on a weekly basis. We've moved a bunch of our write-heavy filesystems to non-BTRFS options as a result of this.
3) This is a more minor issue, but still speaks to my experience. I had a VM that was basically a remote desktop for me to use. Generally speaking it would hang hard after a few days of uptime with no actual usage. When I reinstalled it on a non-BTRFS (sorry, can't remember which filesystem I used) filesystem it was rock solid. I have no proof that this had anything to do with BTRFS.
All of these were things that happened around a year ago, they may not be a true representation of the current state of BTRFS. But they've burned me badly, so now any use of BTRFS will be evaluated very carefully.
In contrast, I've been running ZFS on a couple of FreeBSD servers, with fairly write-heavy loads, and have had no issues that were filesystem-related. Even under severe space and memory constraints ZFS has been rock solid.
Use of the present tense regarding IRIX here made me chuckle. The last version of IRIX is 6.5.30, released in August 2006.
They are both useful, and the ultimate solution, for different cases. BTRFS has no future, and ext4 is purely a legacy solution (also ironic, given XFS is older than ext4).
The mailing list gives interesting insights on what the developers are working on.
Its XFS which never had a future because it lacks features which modern filesystems have. Adding these features would be akin to making a new filesystem (which could contain the acronym XFS).
The only real (integrity) issue BTRFS currently has is write hole in RAID5/6. Its a long standing issue...
I want it to be stable and safe already, but realistically, we still need to wait.
There are of course environments where XFS is fine but it's failure cases are pretty bad. I accidentally (wasn't paying attention) used XFS at home once on a NUC that was my UniFi controller and Pi-Hole; any time it lost power it'd hose the partition and make it unmountable. I'd have to go find a monitor and a keyboard and boot it single-user to recover.
My fault (we were selling the house and buyers love throwing breakers) but still not awesome. I run boot drives as ext4 exclusively now and I definitely pay more attention during setup.
An admittedly extreme example: if you're in a data center with ineffective/insufficient remote hands, you probably very much want the server to come up so you can deal with your problems faster and better. That they could come through, on some timetable, and slap a new OS on there/restore a boot volume from the backup you hope you have is nice, but it isn't the same thing as being able to SSH in and rescue yourself.
This is FUD.
Btrfs is actively developed and its problems and limitations are acknowledged by upstream in an honest way. Many people DO use it with no more problems than they have with XFS or OpenZFS.
The only people who say "Btrfs is dead" are those who don't use it. It's a bit like people who snigger at the whole "Perl looks like line noise" trope without ever having writting a line of Perl in their lives.
In every report that I have seen of Btrfs doing something bad is when somebody (myself included) has done something incorrectly, not read the docs, not consulted an expert before doing something complicated, not taken the time to understand how it works, using a suboptimal or flakey hardware/software stack underlying it.
Have you seen how strict the FreeNAS community is about using proper, server-grade hardware and configuring the system properly to prevent data loss? This is a very good line to stick to.
Unfortunately Btrfs doesn't have the same consistent message but if it did then there would be fewer problems.
I regularly use Btrfs at home and so far I haven't had any problems. I would not use it in production when other people's data is on it YET.
One reason is technical, and it's too much of a cognitive burden these days when combined with other people's data.
The other reason is because of customer expectations, i.e., because of FUD that people like you are spreading. If there was some data loss, the customer would be angry at me for choosing Btrfs because "everybody knows" that it's unstable /s. If I am using ZFS then there's less of a chance that customers think I make bad decisions and there is a small chance they will be more forgiving.
Mdadm + LVM + XFS is an excellent alternative. The only reason that I don't use this more often is because snapshotting requires twice as much disk space as you plan to use. Otherwise I probably would be using this stack exclusively.
Getting back to the original "Btrfs has no future" nonsense, the only reason this is true is if people make it true. Therefore, one important reason I use Btrfs is that I want to see it succeed. That can only happen when people actually use it and advocate for it in a positive and honest way.
Please do not put your words in other people's mouths.
There are many people who did try btrfs and lost their data. And it was not because they did not read the docs or used flaky hardware -- for example, our org lost the data after the sudden power failure. Maybe this was our fault, be we switched to XFS on the very same hardware and did not lose any more data, despite having more power failures.
If your point is to have people use btrfs, you are not helping it by saying things like "it is user's fault every time". Nor does it help to dismiss people's experiences as FUD. Acknowledging its limitations, and saying "yes, it was bad, but as of 20XX it got much better" would be much more effective.
I've had to import an pool from FreeBSD but can only mount the volume as readonly because of a feature flag enabled that isn't in v7 but is currently in the RC versions of 8. I'm a little nervous about running the RC versions because this is a "production" pool (albeit just a home server).
Just curious: what are the differences between [Oracle] ZFS and OpenZFS?
XFS gains the XFS Copy-On-Write Data Extents feature in RHEL 8 which can speed things up and save space.