Btrfs stability and production-readiness
Btrfs stability and production-readiness
Posted Feb 23, 2016 10:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)In reply to: Btrfs stability and production-readiness by rleigh
Parent article: Kirkland: ZFS licensing and Linux
Yet btrfs manages dedup without gobbling up all of the RAM.
> It's a high-end filesystem, so if I'm running a fileserver, then who cares if it's using lots of RAM?
I certainly do. I prefer my memory to be used for something that's relevant, rather than letting it sit as a deadweight. And I'm using btrfs on my private machine for easy snapshots (+send/receive for backups) and on our Docker farm (for obvious reasons).
Dedicated file servers? That's sooo last millennium.
> The performance is still better than Btrfs though, which is generally abysmal, but Btrfs has to pay the same price here, which is then compounded by design mistakes and implementation problems.
Actually, btrfs has a much more thought out design. ZFS is already hobbled by its reliance on the fixed block sizes that later had to retrofitted for compression.
BTRFS suffers from the same problems as ZFS during its first 10 years or so.
> The thing is though, that ZFS *scales* up where other filesystems can't.
And this is just a marketing bullshit. Linux LVM can use SSDs for metadata devices, BTRFS supports that natively as well.
About the only missing piece is RAID-Z, and that's being worked on. Regular mirroring/striping already works perfectly fine.
Posted Feb 24, 2016 12:42 UTC (Wed)
by nye (subscriber, #51576)
[Link]
Only in the sense that it doesn't do it, but provides an interface for some other utility to dedupe by creating block references, thus making it Somebody Else's Problem. Despite considerable opposition, there is some work on in-line dedupe, but it's experimental (not sure if it's in-tree yet) and ... requires tonnes of RAM.
>I certainly do. I prefer my memory to be used for something that's relevant,
What's more relevant to a fileserver than fileserving?
>rather than letting it sit as a deadweight
You might find https://en.wikipedia.org/wiki/Cache_(computing) to be a useful educational resource.
>Actually, btrfs has a much more thought out design. ZFS is already hobbled by its reliance on the fixed block sizes that later had to retrofitted for compression.
One of ZFS's main headline features is (and has always been) variable block sizes
>BTRFS suffers from the same problems as ZFS during its first 10 years or so.
This is so nonsensical that, as the saying goes, it isn't even wrong.
>And this is just a marketing bullshit. Linux LVM can use SSDs for metadata devices, BTRFS supports that natively as well
That is completely unrelated to the point you were replying to.
>About the only missing piece is RAID-Z, and that's being worked on
We've been hearing that it's technically possible for longer than it took for ZFS to go from an idea to wide production use, and still no indication that it will ever actually be done.
Btrfs stability and production-readiness