Is it just me or is it absolutely insane that zfs and btrfs are the only common filesystems out there that do data checksumming? I don't want or need the extra complexity of either of them in a lot of cases, but I'd sure as hell like to know if my data is corrupt...
I've been burned by Btrfs enough times to avoid it.<p>I had a VM running OpenSuse Tumbleweed - I know, rolling release, don't expect stability, etc - and it would consistently freeze after being up and unused for a few days. Rebuilt the VM but used XFS instead of Btrfs, it was rock solid. This happened within the last four months.<p>At work, we have a number of machines using Btrfs. At some point they get into a state where the weekly Btrfs scrub process hangs the machine for hours at a time. The solution in every case was to move that filesystem onto a non-Btrfs volume. This is an ongoing issue, but I'm not in the team responsible so I don't know what they're doing with this. Anecdotally, this seems to be a problem when there is a lot of writing going on with the volumes. Machines that use Btrfs root but do most of their work on NFS volumes don't seem to experience this issue.<p>I also have a laptop running OpenSuse Tumbleweed with Btrfs. One day it somehow got itself into a state where it would hang when mounting the filesystem read/write, but it would be fine if it was mounted read-only. I can't recall exactly what happened to cause it, but I'm pretty sure I didn't do anything exceptional with the computer - I think I rebooted it from the GUI while it was doing a scrub in the background, but that's just a guess. I think this happened about a year ago.<p>This is all disappointing because some of the things Btrfs enables are awesome. In particular, OpenSuse's snapper has saved me countless hour of work. I haven't played with the send/receive stuff, but it seems like a great solution for backups.<p>In the meantime, I'm using ZFS on a variety of FreeBSD boxes with a variety of workloads (including one running more VMs than its RAM should support) and it's been rock solid.<p>At this point it will be a long time before I give Btrfs another look. It has the potential to be really good, and I want it to be good, but I don't believe it's there yet.
HAMMER2/DragonFly is already looking great with cow/snaphots, compression, live dedup etc and one of its design goals is to work great on low memory systems. Once it is feature complete with clustering support it'll be a great choice to have.<p>Although looks like it'll be DragonFly only.
It's a travesty that so few people care about moving to more reliable filesystems. A decade later and we're still stuck with ext4 and now btrfs, which I do use nowadays but I'm absolutely aware of the high risk of data corruption because the underlying code is terrible.<p>Windows is even worse with NTFS, which is a complete pile of garbage. I've fixed hundreds of computers with NTFS corruption over my lifetime and it's mind-boggling that Microsoft is fine with this shit.
I was always hoping for more adoption of NILFS [0] - a log structured FS with continuous snapshots. In theory it should never lose data and that's a reasoning behind it not having fsck. I've seen a blog post that was debating this choice and presenting a few situations when fsck would be necessary, but I can't find it.<p>It would be great for /home for many normal users - they could always go back. That could also be a problem when one wants to make sure that a sensitive file is really removed. It could be also used at least for some kind of archive. Possibly also for development.<p>[0] <a href="https://en.wikipedia.org/wiki/NILFS" rel="nofollow">https://en.wikipedia.org/wiki/NILFS</a>
bcachefs is a really interesting FS in the linux space.<p>Checkout some of the writing about it here:
<a href="https://www.patreon.com/bcachefs" rel="nofollow">https://www.patreon.com/bcachefs</a>
ZoL and Btrfs are the only two filesystems that I've ever had rendered unmountable without any reported disk error. In both cases, ECC ram was in use, and mirrors were used.<p>Btrfs was a known bug, and the kind folks on #btrfs were able to help me recover (though it was a quite involved process).<p>For ZFS, the consensus in #zfs and #zfsonlinux was that with the error message I was getting "I hope you have backups."[1]<p>I see XFS mentioned here, but in the admittedly unusaly use-case of editing a file that when compiled and modprobed may hang the kernel, I found that vim was insufficiently fsync-ing to ensure I had valid data (either old or new copy would have been acceptible).<p>I don't know what my point was with this comment except "All filesystems are buggy, so backup your data"<p>1: It should be noted that in the case of ZFS, I was on vacation and it was my laptop that had no critical data, but I absolutely needed it working for other things, so I only spent a couple hours trying to recover; The btrfs issue happened at home where I had plenty other systems to use and where I was more motivated to recover the data.
Quick note on btrfs: unless you've been dealing with the latest kernels in the last few months, reserve judgement. Facebook has put a truly ridiculous number of hours on that filesystem in the last year or so and fixed a concomitant number of issues.
I'm not sure I agree with the idea that having a single open source project to rule them all is an inherently bad thing. In proprietary software, if Banana corp says that the next version of their Cavendish OS drops x86 support, you might find yourself doomed. But if Debian decides to drop x86 tomorrow, you go "Cool, good luck, I'll just fork." The project itself is never a single point of failure.
I've been super happy with ZFS for over a decade. All the pain I've had with it has been related to deduplication requiring massive amounts of RAM. When you don't have the RAM, it tends to be flaky. But I've never run into data loss with it, despite my best attempts.<p>My current backup server would need ~50GB of RAM just for the in-RAM deduplication tables.<p>I've been thinking of trying btrfs for the backup server, but the deduplication story is not something that's obvious, it all seems to be third-party, which makes me skeptical. But it worth trying. I might just try a test Dragonfly setup, because my simple testing of HAMMER seemed very promising, years ago.<p>I've had pretty bad experiences with btrfs in the distant past. Around a decade ago I had all my company laptops using btrfs and it worked great, as long as we didn't get >80% usage or something. It worked well for around a year. But then the reliability of btrfs dropped, and we had repeated data loss and switched back to ext.
On that note, are there any fancy file systems that have acceptable Windows/Mac support? Or are we all doomed to using NTFS or exfat for USB drives that need to work on Linux/Mac/Windows?
anecdotal report: Im running a medium sized MariaDB database of appointments and invoice backups on a 4 disk BTRFS filesystem with deduplication. snapshots work, its stable, and it performs well.<p>I feel like so much of BTRFS though was death by committee. It was trying to do every single thing ZFS did, regardless of whether or not the specific feature from ZFS was mediocre to begin with.<p>focusing on a release cycle and communicating would have helped it alot instead of vague things like "it is ready enough" and "some features arent ready"
I get it during the Sun years, but why the hell does Oracle continue developing Btrfs when they can just release ZFS under a GPL-compatible license and be done with it? It reallys seems like they are working against their own interests here.
Is btrfs still a thing? Reading other people's experiences, atleast a couple distros dropping it as a default, and my personal experience of it crashing completely. I'm surprised anyone would even consider it as an option. It simply isn't a reliable file system.
Is ZFS worth considering at this point? Btrfs seems to be quite featureful and stable, with a plethora of grocers and retailers all over the world using it. Wal-Mart, Kroger (and subsidiaries), all of IBM's old point of sale customers (now Toshiba SuperPOS iirc) all use it on things as small as deli scales all the way to running their point of sale systems and backends.
The challenge here is that ZFS is dominate by Oracle right now, and if anyone thinks that Oracle is going to act in the best interest of the community, rather then killing the golden goose to peel the meat off it's bones, take a look at what Oracle has done with Java recently. Or what they did with Solaris. Or what they do with Oracle Cloud.<p>in addition, we know that there are patent landmines out there because NetApp and Oracle have a (undisclosed) settlement on the issue. Using ZFS is a probably good way to get a visit from your legendary friendly Oracle sales agent and auditor. Oracle could fix all of this with a quick re-license or patent indemnification, but they haven't and almost certainly won't.<p>My Synology (and all modern Synologies) uses BTRFS, and it seems pretty solid so far. I would have preferred that ZFS had matured and been dominate in FS, but there are some really risky things that come with ZFS.
Opinions are good, bad and ugly. Sometimes all at once.<p>Thanks for letting us know one nerd's take on openzfs.<p>The only thing standing in zfs way (to 1st tier Linux support) is a company springing up and heading the charge. 75 percent sure this will happen eventually with ZoL at some point in a decade's time.<p>However, another point of measure is money. Synology is huge and seems to think btrfs is good enough for business. They compete with ixsystems directly. We could go all day and into 2020 with points and counter points. The licensing issue is weak but will eventually be moot with enough money and time behind the right project. I'm not in any position to judge that last point for sure just offering my IT pro/business take on it.<p>To be fair bsd-ish-ness has a role to play on the backend and is bullet proof and battle tested for the right mission. But the same can be said for Linux too. The last point I'll make is that today, I can run the Linux kernel from my msft windows 10 machine natively. No one here would have saw that in 2000. Does bsd, zfs have a similar anecdotal Hero Epic like this; where the enemy capitulated so thoroughly?
ZFS is not suitable for desktop computers. as for example that one anecdote in the comments of the article shows, ZFS doesn't work well on a single disk. the author of the comment is confused by the behavior, and doesn't even consider that this might be by design.<p>another point that shows that ZFS is unsuitable for the desktop is it's reliance on EEC RAM: <a href="https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/" rel="nofollow">https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-...</a><p>i considered getting EEC RAM for my machine just because of ZFS, but i could not find any 16GB strips to fill my board.<p>that's two strikes against desktop use, and enough to let me prefer btrfs.<p>EDIT: i am very happy to see so many replies proving me wrong. when i last researched this topic i was not able to find any counter arguments to needing EEC.<p>greetings, eMBee.