[riku_iki]

> but as you may guess we did not use btrfs ever again.

there are scenarious where btrfs is currently can't be replaced: high performance + data compression.

[theamk]

Sure, I can believe this. Does not change the fact that some people encounter compete data loss with it.

Sadly, there are people (and distributions) which recommend btrfs for general-purpose root filesystem, even for the cases where reliability matters much more than performance. I think that part is a mistake,

[riku_iki]

I would recommend btrfs as general purpose root filesystem. Any FS will have people encountering data loss. I can believe btrfs has N times higher chance of data loss because its packed with features and need to maintain various complicated indexes which are easier to corrupt, but I also believe that one should be ready that his disk will fail any minute regardless of FS, and do backup/replication accordingly.

[sandreas]

While I did that and lost near to nothing, I still think that this should not be the default approach of developing a filesystem... it should be ready to restore as much as possible in case of hardware failure or data corruption.

[riku_iki]

there is standard approach: you setup raid, and FS will restore as much as possible and likely everything. Adding extra complexity to cover some edge cases maybe is too overkill.

[mdedetrich]

OpenZFS does a better job here, at least if you can deal with an out of tree filesystem.

[riku_iki]

actually, my personal benchmarks and multiple accounts in internet say it is much slower than btrfs under the load.

[mdedetrich]

For smaller disk setups possibly but with large enough scale ZFS ends up beating out btrfs.

[riku_iki]

I test on 2TB datasets. Do you have any specific pointers which would support your claim?

[mdedetrich]

I have 100+TB datasets and with a large enough SSD/RAM for L1/L2 arc ZFS edges out.

Hell even the compression algorithm that ZFS has uses/has access to (LZ4) is faster than what btrfs uses and with enough IO that matters.

[riku_iki]

> I have 100+TB datasets and with a large enough SSD/RAM for L1/L2 arc ZFS edges out.

and your claim is that you tested it against btrfs on the same workload? Maybe you could post some specific numbers from running command from this thread? https://www.reddit.com/r/zfs/comments/1i3yjpt/very_poor_perf...

> Hell even the compression algorithm that ZFS has uses/has access to (LZ4) is faster than what btrfs uses and with enough IO that matters.

lz4 compression rate was 2x vs 7x for zstd on my data (bunch of numbers), so I didn't see point of uzing lz4 compression at all because benefits are not large enough.