Google Admin Encourages Trying Btrfs, Not ZFS On Linux

[Linuxhippy]

From a license perspective, I don't have an issue installing and loading a CDDL module from source code into my kernels...

Sure, however it pretty much rules ZoL out of being the Linux' next mainstream FS following ext4.
From this point of view I am quite happy with how btrfs evolves (even if it took a lot longer than initially anticipated).

Br

[Ardje]

Hmm...

Checking it out, he admitted openly that ZFS is just better and more stable, he just had issues with the license, and then he also said the license incompatibility is not a problem for end users, only for distributions.

About the memory usage ... just buy more memory .

I once was doing a fsck.btrfs on a 12GB machine of 256GB of metadata on 4TB of data.
After a week of fsck the swapspace of 32GB was full, and the fsck bailed out on OOM.
So I added 400GB of swapspace.
After 6 months of running I am not sure anymore if it bailed out with not enough memory, or if it just said "this filesystem needs to be repaired".
This was a backup system, that was turned old iron due to the btrfs bugs.
Another system was run in with the same setup, and only since 3.16 it doesn't need to be regularly run in from scratch.

So if btrfs trashes itself, you better not try to repair it, just start new, and hope that your backup hasn't trashed itself yet.
In this case it was a secondary backup of a primary backup.

btrfs rocks when it comes to create and delete snapshot. The backups are just rsyncs, and the snapshot delete is pretty fast.
Doing rsync with hardlinks and then removing old backups on ext4 takes ages. (on each file decrease reference count, and then sync metadata)

[rdnetto]

Checking it out, he admitted openly that ZFS is just better and more stable, he just had issues with the license, and then he also said the license incompatibility is not a problem for end users, only for distributions.

License incompatibility does have implications for end users though, since it means that ZoL will never make it into the mainline kernel, which substantially reduces the support it gets. In my experience, the vast majority of kernel-related problems I've had have been caused by non-mainline kernel modules.

I once was doing a fsck.btrfs on a 12GB machine of 256GB of metadata on 4TB of data.

On most distros, fsck.btrfs is symlinked to /bin/true, so I assume you mean (what's now called) btrfs check.

So if btrfs trashes itself, you better not try to repair it, just start new, and hope that your backup hasn't trashed itself yet.

The official stance on the mailing list is that you should never run 'btrfs check --repair' unless you're certain that your problem will be fixed by it, because certain problems will be made substantially worse by doing so. (This is why --repair is not the default.)

As much as I love btrfs, btrfs-check could really use some work...

[jeffm]

SUSE Linux Enterprise 12 installs on Btrfs by default

Aside from openSUSE beginning to ship with Btrfs by default, most Linux distributions still tend to be EXT4/XFS based and leaving Btrfs as just an experimental install-time option.

In addition to openSUSE, SUSE Linux Enterprise 12 has shipped using Btrfs as the default OS file system. We use it to enable features like full system snapshot/rollback, with subvolumes set up appropriately to avoid problems with log integrity and compliance. We limit the scope of our Btrfs implementation to mature features (e.g. RAID5/6 and send/receive are disabled) and aggressively fix issues as they come up and improve usability through direct development and the backporting of community patches. Our development and use of the Snapper snapshotting tool provides automatic snapshots on a time basis and a configuration event basis. Automatic cleanup by count and age is built-in, with cleanup based on available free space coming. We've gotten very good feedback from our users. In fact, even though we only recommend it for use as a system disk (for now, due to XFS being a better choice when performance is a major consideration), we've had customers asking about using it more broadly.

SLE12 Release Notes segment on Btrfs: https://www.suse.com/releasenotes/x8...2/#fate-317221

--
Jeff Mahoney
SUSE Labs, Team Lead, File Systems and Storage

[devsk]

To be fair, memory management on ZoL is pretty broken, but there are some patches that look like they may land in the next few months to sort this out considerably. Source: been running ZoL for some years now.

Even with the memory reconciliation issues with Linux VM, I would rate ZoL much higher than BTRFS. It has never failed me. While BTRFS fails me every time I try it. *EVERY* freaking time. I still keep trying it every year religiously to see if I can use it instead for the rootfs.

ZoL on the other hand, has been running on my home server since the first piece of code was published by Brian.

[jsky]

Which FS is Google using?

Google is not listed in any of contributor or user list of btrfs.
Which FS is it using and why google admin is recommending btrfs while his company isn't using it?

[SystemCrasher]

I gave a try to btrfs and it seems to be quite interesting to my taste. Its quite featured and offers snapshots. Yet I can't see major slowdowns compared to EXT4. It can even offer read/write speed improvements on slow devices thanks to LZO data compression. It haven't broken apart on few installation I've got, some are about 6 months in use. Yet, looking on kernel changelogs, recent kernels are must. Say 3.19 got some quite important fixes. Same goes for btrfs-progs.

As for ZFS and somesuch... messing with "out of tree" modules is road which leads to nowhere. Especially when they have got weird license, which means no major distros would supply it by default. And total inability to mount filesystem with stock OS live or install image? Okay, it's not how I want things to happen. Sounds like major pitfall for many use cases.

[blackiwid]

Linux is fast moving and changing, that is one of its major strength. But it has been getting out of hand lately.
A lot of new code is being pushed that is not tried and tested for years, or a few smart people
like the new tech and push it hard. Systemd and btrfs are prime examples. I am not against either of them,
but they are being pushed way to hard into production when they are not ready, in my opinion.

My experience with ZFS has been amazing on freebsd, on linux it was not stable for me, but after a few months of
work it is looking really good. In the same amount of time btrfs, has improved but its still rough in a lot of places.
I am not against using it, but for stability RIGHT NOW, ZFS is the way to go.

Where did btrfs got pushed hard into production? Opensuse is the only distro that uses it by default? So its only a option for people that really want it, should it be denied to have this option?

So because of that the mixing together systemd with that was just a excuse to bitch about systemd too because you dont like both projects. btrfs may be not fit everybody needs, and they push it to less in my opinion, they should finaly fix df to show right numbers for btrfs as example, how long do they need for that 100 years?

To systemd, I switched to fedora to FC19 and also played around with archlinux, not because of systemd but because Ubuntu totaly gone cracy with preinstalled adware and stuff like that. And then I saw how great this distros are in comparsion to ubuntu, it was not only systemd whats better on them, but its a big part of it. Its way better than upstart + logfiles or older init systems.

it has great tools very similar to what I was used in gentoo to enable services etc. it goes just even further and is even better. I just purely love no searching around for log messages which fuckin file is how do I need to grep it just a simple command from any place and its tehre, userbased initfiles love it, the initfiles distribution-independend, you can in most cases just steal the service files from archlinux and use it in fedora.

From a practical standpoint 99% its a improvement over all other things, except maybe some religious unix people or stuff like that may hate on it, but is that really reasonable to care about some bsd-admins that have to learn new stuff when they are forced to administrate linux boxes? I dont think that should be the messure point.

And another thing most problems with btrfs happen, because the distros make retarded tools to snapshot the hole system / AND /home when you make a update, of course your system gets fast full and if df tells wrong numbers to that too, you kind of run into a trap, that was the only problems I had with btrfs so far.

[Ericg]

Where did btrfs got pushed hard into production? Opensuse is the only distro that uses it by default? So its only a option for people that really want it, should it be denied to have this option?

So because of that the mixing together systemd with that was just a excuse to bitch about systemd too because you dont like both projects. btrfs may be not fit everybody needs, and they push it to less in my opinion, they should finaly fix df to show right numbers for btrfs as example, how long do they need for that 100 years?

To systemd, I switched to fedora to FC19 and also played around with archlinux, not because of systemd but because Ubuntu totaly gone cracy with preinstalled adware and stuff like that. And then I saw how great this distros are in comparsion to ubuntu, it was not only systemd whats better on them, but its a big part of it. Its way better than upstart + logfiles or older init systems.

it has great tools very similar to what I was used in gentoo to enable services etc. it goes just even further and is even better. I just purely love no searching around for log messages which fuckin file is how do I need to grep it just a simple command from any place and its tehre, userbased initfiles love it, the initfiles distribution-independend, you can in most cases just steal the service files from archlinux and use it in fedora.

From a practical standpoint 99% its a improvement over all other things, except maybe some religious unix people or stuff like that may hate on it, but is that really reasonable to care about some bsd-admins that have to learn new stuff when they are forced to administrate linux boxes? I dont think that should be the messure point.

And another thing most problems with btrfs happen, because the distros make retarded tools to snapshot the hole system / AND /home when you make a update, of course your system gets fast full and if df tells wrong numbers to that too, you kind of run into a trap, that was the only problems I had with btrfs so far.

Wow, Black, cool it. Soup's post was pretty reasonable and well sounded, but yours is coming off more like an attack against him for not thinking btrfs / systemd is stable right now.

[blackiwid]

Wow, Black, cool it. Soup's post was pretty reasonable and well sounded, but yours is coming off more like an attack against him for not thinking btrfs / systemd is stable right now.

like I said he tried to mix this 2 up, even they have nothing in common except they got public in around the same years but not even that accurate, systemd is used for very long as default for several distros, btrfs is not used at all except suse NOW.

So it just made no sense, you may feel something different, I just dont care to much about feelings of something, but more about facts.

Btw, systemd is perfektly stable, any sources that its not? please if you or Soup has anything to mention here. you either like it because you like new features or you hate it because its not unixish enough in your understanding, good for you but I did not even hear from any systemdcritics any claims that systemd is not stable.