Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Netflix has been using ZFS in production for many years now. Unnamed research companies are using ZFS moving PB's of data. NetApp is FreeBSD based and was on the forefront of what we now call ZFS. I'm totally biased, designed many production critical systems with ZFS at it's core in one way or another. The power of ZFS send and receive function is tremendous to say the least, it beats any file based synchronizing methods.


>Netflix has been using ZFS in production

User of freebsd myself but that is BS, Netflix uses freebsd and UFS2 on the openconnect device.

https://openconnect.netflix.com/en/

You watch youtube about netflix they state clearly that they use ufs.

I "think" it's that one

https://www.youtube.com/watch?v=veQwkG0WdN8

Microservice-backend is linux/aws


We UFS for content serving, and a mix of UFS and ZFS for boot/log/config filesystems.

We use UFS for content because we rely on zero-copy async sendfile for our high performance video serving data path. When using ZFS, sendfile is not async, and because ZFS uses ARC rather than the page cache, it requires a copy from ARC to network with ZFS, so its yet ready for our high performance workload.

We don't use RAID at all.


>ZFS for boot/log/config filesystems.

Thanks for clarification, so can i assume that bectl/adm is in full swing?


Send/Recv and snapshots by far my favorite features, I keep snapshots of my root drive on my NAS so if my main m2 drive dies in my desktop, i can just boot a live cd and send/recv to my new drive and reboot and i'm back where i left off.

I also keep a clean copy of an installed debian install snapshot on my NAS so i can just send it to new machines rather than run through the whole setup. works great.


Snapshots & send-receive are my favorite BTRFS features too! I too love snapshotting Debian installs & send'ing them to new machines for atomic updates, or to build live usb images. I've been using Pottering's "Revisiting How We Put Together Linux Systems" naming system for my subvolumes, and that's worked fairly well[1]. I even did some fiddling around with enhancing Debian-live to load btrfs into ram a while back, so I could atomic update, de-mount the boot drive, &c[2].

Oh you are talking about ZFS, aren't you. ;)

Playing the "who came up with it first" game doesn't particularly interest me. Again, it feels like a spirit of competition when to me, that seems like a bad spirit: we should be cooperative & boosting each other. We're both open source, we're both trying to make civilization possible & to share greatnesses.

[1] http://0pointer.net/blog/revisiting-how-we-put-together-linu...

[2] https://github.com/rektide/debian-live-boot


>we should be cooperative & boosting each other.

Is that why you sound like a sour apple?


I'm sour because it feels like zfs folks in particular have it in for btrfs and it's very tiring. there's so many OSes which default to btrfs that there's be some real modern evidence if there were problems but we are constantly dogged by massive negativity.


>OSes which default to btrfs

No just two Gnu/Linux distributions:

openSUSE/SLES and Fedora

And SUSE (SLES) tells you (strong recommendation) to use btrfs just for the OS (for data XFS, just like RHEL) and just in a mirror configuration.

Look i work since ~forever with SLES, and if you operate it in mirror mode (just os), don't touch it and just make snapshots i never had problems. But i HAD complete data-loss with btrf many times when i did for example a defrag and re-compress, those are native btrfs-tools, and that is not acceptable to me. The Filesystems is THE place in a OS where errors like that are not acceptable (to me).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: