Hacker News Reader

Comment by DiabloD3 | Hacker News Reader

Brtfs only exists as Oracle's "replacement" for ZFS, to hedge their bets in case they couldn't buy Sun. Oracle bought sun in 2010, that has been 12 years.

They merged the Btrfs and ZFS teams, they then worked on ZFS entirely with no Btrfs work, and then basically reassigned, fired, or otherwise dissolved the ZFS team when it became clear that OpenZFS (Sun's chosen steward for ZFS) could not be swayed.

Btrfs has had no real work done on it since then, and anyone that is actually serious about data storage has moved to ZFS, or has left POSIX filesystems entirely.

View on HN

>Btrfs has had no real work done on it since then

changelog seems to refute this point entirely.

https://btrfs.wiki.kernel.org/index.php/Changelog

>anyone that is actually serious about data storage has moved to ZFS

sometimes data storage doesnt have to scale, and thats okay. there are still plenty of use cases for lvm/xfs/mdadm in environments that dont need Google levels of service. im "serious" about data storage and run raid10 btrfs.

>or has left POSIX filesystems entirely.

oh get off the cross. redhat intentionally threw backing into XFS to make it functional with Ceph. just because BTRFS has issues with RAID5 (arguably the worst RAID) doesnt mean the whole of POSIX storage has been relegated to the ash heap.

> redhat intentionally threw backing into XFS to make it functional with Ceph.

Can you elaborate on that? Is the about pre-bluestore backing of Ceph or... something else?

This is one of the most laughably ignorant posts I've ever seen on the internet.

> Btrfs has had no real work done on it since then, and anyone that is actually serious about data storage has moved to ZFS, or has left POSIX filesystems entirely

Btrfs is the most actively developed filesystem in the kernel, both by LOC changed and the number of contributors. Facebook publicly stated that they run BTRFS on every webserver years ago.

ZFS is an antiquated joke. It is wed to the memory allocator in Solaris, and requires that you permanently reserve 1GB of RAM per 1TB of disk space, which is an impractical constraint in the modern world. ZFS is also full of cute little wasteful "innovations" like 128-bit file size support.

I don't know what planet you're from, but it's not mine :)

Please correct me if I'm wrong, but the "1GB ram per TB" is for the de-duplication table.

ZFS' memory cache (ARC) by default uses up to 50% of system ram and frees this under pressure. You can also set it lower.

Yes, this is what I'm talking about. With respect to ARC, it gets along very poorly with the native page cache and memory allocator.

I would add that BTRFS has no such requirements for deduplication.

That’s because the btrfs deduplicator is quite a different animal. You could just as easily run fdupes or something similar. Meanwhile ZFS is doing something much more ambitious.

In any case, I don’t think that either of them are worth using in most cases. Deduplication is just too expensive to be worth it.

> You could just as easily run fdupes or something similar.

If you only deduplicate whole files and soft links or hard links are suitable for your situation.

That’s not the aspect of the deduplication process that I was referring to.

Btrfs only supports offline deduplication, where you periodically run a process that searches for duplicate blocks and combines them.

Meanwhile ZFS supports online deduplication, where every block written is checked against an index to see if it is a duplicate of some existing block.

That index is what takes up the memory that jcalvinowens complained about. When deduplication is turned on, ZFS keeps that whole index in memory all of the time. Meanwhile btrfs only needs that index to be loaded while the deduplicator is running, so it doesn’t show up most of the time.

Personally I don’t think that either is really worth the cost; the benefit is so small that the cost isn’t worth paying.

I know the ZFS deduplicator accomplishes more, I'm just pointing out that that if you want offline deduplication on ZFS, you can't have it.

What are they changing all the LOCs for if not to fix the existing massive data loss bugs?

You’re not correct on a number of fronts here.

ZFS is not tied to the memory allocator in Solaris, I’m very unclear how you could have made that mistake.

128bits might feel wasteful, but you’re likely never going to have the problems FAT32 has had- it’s designed for the next 100 years- which has drawbacks but prevent the kinds of ugly hacks that NTFS has gone through to maintain forward compatibility (rolling on disk upgrade).

And yes, the 1G per TB is for the in memory block map, which is a requirement for deduplucation on the default block size.

> ZFS is not tied to the memory allocator in Solaris, I’m very unclear how you could have made that mistake

> And yes, the 1G per TB is for the in memory block map, which is a requirement for deduplucation on the default block size.

You actually answered your own question: it's antiquated because of the assumption it is possible to get contiguous RAM for that mapping. On modern Linux, that is only possible if you reserve it pre-boot.

The Solaris memory allocator is not contiguous either though

This is a whole rabbit hole... but essentially, Linux uses a naive buddy allocator for physical RAM, and Solaris was more interesting.

> it's antiquated because of the assumption it is possible to get contiguous RAM for that mapping.

source on that? (and even if that's the case, wouldn't that be an implementation detail? E.g. implementations can spill it to L2ARC, but somehow not to different memory locations?)

My memory is that this mapping does have to be contiguous, but I'll dig it up in the code and link it here either way.

still planning on linking that code?

Look you can’t start your post with

> This is one of the most laughably ignorant posts I've ever seen on the internet.

And say

> requires that you permanently reserve 1GB of RAM per 1TB of disk

If you want people to take you seriously. There are ways to debate on HN, this isn’t it.

> Btrfs has had no real work done on it since then, and anyone that is actually serious about data storage has moved to ZFS, or has left POSIX filesystems entirely.

I'm not very familiar with this space, but if this were true why would Fedora use Btrfs by default?

Also on Fedora wiki [0] -- Btrfs is a mature, well-understood, and battle-tested file system, used on both desktop/container and server/cloud use-cases -- which seems to contradict what you said.

[0] https://fedoraproject.org/wiki/Changes/BtrfsByDefault

Apparently it used at facebook a lot too.

https://lwn.net/Articles/824855/

Reply on news.ycombinator.com