Google Admin Encourages Trying Btrfs, Not ZFS On Linux

[Vamp898]

Since i heard about ZFS and played around with it, the amounts of productive FreeBSD Servers increased immense.

pf and ZFS are both superiour to everything which exists in the Linux world.

There are tons of unfinished hacker projects like btrfs and nftables, but it seems like they always overdo themself.

I just tried btrfs today (with the most recent kernel and tools) and there are still missing so many features.

ZFS is there, right now, ready to do the job. And its awesome.

zpool create storage raidz2 da{0..11} raidz2 da{12..23}

thats it, LVM, RAID, partitioning and formatting all in one command. After this single command, i can cd /storage and work with the system. Two raid6 combined to one large device, something btrfs cant do!

zfs set compression=gzip storage
zfs set dedup=on storage

thats it.

I can manage RAIDs with 96 Disks with exaktly 3 commands and ZFS getting faster with ever disk i add!

For large storages (and i have to deal with them) ZFS is so much better in every aspects and so often saved my live.

Want to add 24 Disks to an pool which is build of 2 RAID6 with each 12 disks (so enlarge 24 disks with 24 disks)

zpool add storage raidz2 da{24..35} raidz2 da{36..47}

thats it. Done. 0% downtime, ready to use. Just instant.

And subvolumes on ZFS even can have their own FS. I can create and subvol and format it using FAT32 or NTFS.

ZFS is their, right now, and the best thing you can get. btrfs might be there, at some point in the next 5 years, but i have to do my job now!

Thats reason enough to use FreeBSD on the machines where ZFS is needed to do the job.

And, different to linux, there is even an proper documentation

https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/zfs.html

I never ever handle again big storages without ZFS, after working with LVM, mdadm and ext3/4 for years and now btrfs, ZFS is the first time i have something which just works absolutely 100% the way it was designed.

[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.

[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]

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.

[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.

[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?

[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.

[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

[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...

[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)