Reliable self-healing file system: Btrfs, OpenZFS, or something else?

This SO says no change in writes done.

It does point out that if there is compression can amplify writes, but you asked about encryption.

You are correct! Thank you.

Is it worth turning off compression in Btrfs or ZFS? Maybe additional wear is compensated by lower amount of data written?

If you are a normal desktop user I very much doubt it matters.

I did turn off recording atime on all on file systems as that does cause metadata to written frequently.
And I do not care about atime, so no loss of features for my work loads.

Thank you for your opinion, Barry. I can live without atime too. :grin:

My sincere thanks to all participants in the discussion! :smile:
I have received satisfactory answers to my questions. :smile:

Special thanks to: dalto, Gregory Lee Bartholomew, and Barry A Scott! :clap:

Let me briefly summarize my questions and responses received:

My goals:
1. automatic (on read) or semi-automatic (periodic scans) data corruption detection - both, Btrfs and OpenZFS can detect data corruption automatically and on demand;
2. backups and folder synchronization - not built in in file systems - need to be done by other tools (eg rsync);
3. Support for encryption

4. Mechanism for easy file repair - files can be automatically fixed based on copy from other drive in RAID configuration, otherwise uncorrupted copy of file need to be copied from other source;
5. easy snapshots for more periodic local backups and file versioning - snapshots can be created in Btrfs and OpenZFS;
6. deduplication to eliminate duplicated data on the same disk - OpenZFS consume a lot of resources during deduplication, in case of Btrfs I am not sure how many resources it really consume. Maybe someone will explain in few words Btrfs deduplication safety and efficiency?

Main questions:
1. Btrfs, despite promising, seems to be not mature enough to store important files or use it on system drive. Am I right? Any thoughts?

2. I found many positive opinions related to ZFS. (
) Any known constraints or drawbacks? Can mitigate potential problems if not using ECC RAM?

3. bcachefs - reasonable alternative to Btrfs and OpenZFS, or not yet?

4. How to set encrypted OpenZFS partition? Will option for LUKS appear when OpenZFS is installed?

Additional questions:
How can I repair file(s) based on copies from
 - in case of Btrfs as well as OpenZFS files are automatically restored only in RAID configuration. Manually it is necessary to copy uncorrupted copy of file from different source (eg by rsync).

Worth to mention:
1. Memory usage by ZFS is tunable

2. ZFS does support dynamic disk pool expansion - see details in post #3 (above) written by Gregory Lee Bartholomew;
3. How ZFS’s self healing works (link from Gregory Lee Bartholomew):

4. OpenZFS tool recommended by dalto: ZnapZend.

1 Like

[Off topic] I had a lot of questions in this topic, so there is no only one answer to all of them. Can I choose multiple answers as a solution? If not, I will choose my previous post with summary and gratitude to the authors of most helpful responses.

3 Likes

You can’t, the forum software does not allow that. In this here case, I would either not set a Solution or mark your summary post as Solution


Thank you for your structured summary. I haven’t looked deeply enough into the two file systems to be able to give you any advice. But I would like to comment on a few points.

You can argue about that. ZFS vs BTRFS is sometimes a religious war in the Linux world.
Personally, I think BTRFS is mature as long as you use the main features. The project page provides information on which features are stable. SuSE uses BTRFS as default. Even Synology uses BTRFS in its mass customer business. It can therefore not be described as immature. The fact that Redhat has removed BTRFS has more to do with company policy than with the stability of BTRFS.

So now you know that you can limit the RAM usage of ZFS, but you don’t yet know what the limitations are. (Spoiler: I don’t know either). ‘you can set it to whatever you want’ doesn’t sound sensible to me. Reading this, seems to support my suspicion:

Allocating enough memory for the ARC is crucial for IO performance, so reduce it with caution. As a general rule of thumb, allocate at least 2 GiB Base + 1 GiB/TiB-Storage.

(Cited from here)

backups and folder synchronization - not built in in file systems - need to be done by other tools
You may have a look at BTRFS send/receive. I haven’t tested it yet, but it sounds like an integrated backup solution to me. You create a snapshot and can send it to another drive.

So I think you should compare ZFS with BTRFS again to find the best option for you.

Thank you for additional considerations! Especially regarding Btrfs maturity. :grinning:

Unfortunately I cannot add part of your comment to my summary, which I want to mark as a solution (created by all discussion participants).