SoylentNews is people
SoylentNews
from the bazaar?-what-bazaar?-this-is-my-cathedral dept.
In the release notes for RedHat Enterprise Linux 7.4 we can see the following:
The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux.
The Btrfs file system did receive numerous updates from the upstream in Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise Linux 7 series. However, this is the last planned update to this feature.
Red Hat will continue to invest in future technologies to address the use cases of our customers, specifically those related to snapshots, compression, NVRAM, and ease of use. We encourage feedback through your Red Hat representative on features and requirements you have for file systems and storage technology.
Btrfs, originally developed by Oracle and now also by SUSE and others, seems to have lost Red Hat as supporter. So what is ahead? RH isn't very clear. ZFS had license issues since day one, and is currently under Oracle umbrella, making a change near impossible. Does this mean improving XFS? Some other FS to be announce soon? Will Red Hat push its weight around like in other cases? Will other distros hold their ground or bow? Unix wars all over again, this time in Linux and FOSS land.
Maybe time to update it to Corporate Open Source Software, COSS, you can look but forget about having a voice among the big guys. The bazaar is dead, long live the cathedral. Or time to fork them off.
(Score: 2) by bart9h on Wednesday August 02 2017, @04:03PM (37 children)
What are the disadvantages of Btrfs?
I started using it some time ago, and had no problems so far.
The snapshot feature is very handy.
(Score: 4, Interesting) by tekk on Wednesday August 02 2017, @04:20PM (14 children)
I think the problem is that in the approximately forever that it's been supported and even encouraged in distros like Fedora, it never quite got as fast or as stable as XFS, EXT4, or even ZFS.
It had nice features, but it never got to feature parity with ZFS despite (I think) BTRFS being in development longer. A quick glance at Wikipedia says yes: ZFS went from concept to inclusion in Solaris with a stable on-disk format in 5 years, BTRFS took 7 years for an on-disk format which didn't do everything ZFS did.
If I were cynical I might say that Oracle intentionally hamstrung BTRFS development to just be a token of "see, we support modern, advanced filesystems too" with no real intention to seriously support it. We'll see how Unbreakable Linux handles things when upstream drops btr.
(Score: 4, Informative) by KiloByte on Wednesday August 02 2017, @05:04PM (7 children)
I've got burned by ext4 several times in a row recently, there's no way I'm using a silentdatalossfs anytime soon.
On one hand, btrfs has crap fsync performance, and has some caveats (like the need to balance in some cases).
On the other, old-style filesystems fail to detect any data corruption the disk did not report. On ext4 or xfs, bad data will overwrite backups, and if you have tiered backups with adequate history, there's still no clue when a piece of data went bad. Btrfs on the other hand will tell you immediately on read, or on scrub for cold data (you do run scrub from a weekly cronjob, don't you?).
Another massive advantages of btrfs are local snapshots (so you can rollback with a single command, test upgrades, etc), and O(changes) backups. On spinning rust, when a single rsync run takes north of 30 mins just to stat everything, you can't run backups frequently enough. On btrfs? Do you want them every 3 hours? An hour?
Thus, your choice is between ridiculously non-KISS btrfs that provides data safety features and "stable" filesystems that don't.
Ceterum censeo systemd esse delendam.
(Score: 1, Informative) by Anonymous Coward on Wednesday August 02 2017, @06:01PM (1 child)
But ext2 could handle checksum metadata via its attribute/metadata format, although it AFAIK currently doesn't.
Personally I have lost multiple partitions due to ext4 and seagate drives, in situations that ext2 or 3 on the same drive wouldn't cause any corruption at all. As a result of this I've been sticking to kernels with the old ext3 driver included rather than updating and getting the new 'ext4' features.
(Score: 0) by Anonymous Coward on Wednesday August 02 2017, @09:31PM
Maybe it was this paper http://pages.cs.wisc.edu/~remzi/Classes/736/Spring2005/Projects/Brian-Chloe/ext2c.pdf [wisc.edu] the one you remember about ext2 and data checksums.
(Score: 4, Informative) by frojack on Wednesday August 02 2017, @06:55PM (1 child)
On the other hand, I find ext4 quite stable. I've never lost a byte. If you have, it was due to bad drives or bad power, which no file system can get around.
The only FS I have ever lost data on was BTRFS, on perfectly functioning drives with battery backed up power. Twice in 6 months, the second event was un-recoverable (required restore from backups after reformatting the drives).
After the second failure btrfs has been on my ban list, which means its on a five year timeout. Maybe if other distros are walking away I won't bother to re-evaluate.
It held out promises, with snapshots and roll backs and all sorts of volume management things. It was starting to become the systemd of file systems, (that is an insult to systemd, which is far more stable). You never knew just how much available space you actually had on a btrfs machine, it took a great deal of digging and calculating.
In short, I could never figure out what market this was aimed at. It has almost nothing Joe Hacker needs, and nothing Small Business could trust. And Big Business has a lot more reliable systems to choose from.
No, you are mistaken. I've always had this sig.
(Score: 2) by KiloByte on Wednesday August 02 2017, @09:16PM
But if I lose data to a bad drive (and there's no such thing as a "good" drive in the long run), I do want to know when and what I lost. With btrfs, I take it from nightly backup (single or raid0) or the filesystem itself takes it from the other copy automatically (redundant¹ raid). With ext4, I have no clue, and the loss is likely to cause actual damage rather than at most a short downtime.
And ext4 is on mine. Despite years of heavy use of btrfs, I have yet to lose data to it (hardware failures and test systems with intentional mucking around obviously excluded). I'm no btrfs dev yet I try to help them — you can come too if you wish.
WHAT THE FUCKING FUCK?!? Now this was uncalled for. Not even fat is that bad!!!
inode limit on ext{2,3,4} anyone?
[¹]. Yeah, "redundant raid" sounds redundant, but someone had the bright idea of naming raid0 thusly.
Ceterum censeo systemd esse delendam.
(Score: 0) by Anonymous Coward on Wednesday August 02 2017, @09:21PM (2 children)
you two are "on the cheese". ext4 doesn't lose data for shit.
(Score: 2) by Immerman on Thursday August 03 2017, @03:32PM (1 child)
Cosmic ray hits drive, flips a bit, data is lost (a real issue, especially on airplanes). Lot's of more pedestrian ways a bit can get flipped as well.
How long does it take you to notice?
The problem is not the data loss itself - that's completely unavoidable regardless of file system. The problem is if the filesystem doesn't detect and/or repair that damage. And very few of them do.
(Score: 0) by Anonymous Coward on Thursday August 03 2017, @05:40PM
If it's a bit flip like that, the disk will detect and correct it when you read the sector. It take multiple errors for it to be uncorrectable
(Score: 2) by TheRaven on Wednesday August 02 2017, @06:58PM (1 child)
Not even slightly. Btrfs design started in 2007, and was first shipped in 2009, ZFS shipped in 2005. Many people were using ZFS in production when Btrfs was still a design doc and some proof of concept code. ZFS was ported to FreeBSD in 2007 and shipped in FreeBSD 7.0 and was pretty stable in FreeBSD 8 (2010). ZFS was ported to Linux as a proof-of-concept in 2008 and vaguely usable in 2011.
Btrfs was originally started by Oracle because they couldn't use ZFS with Linux because of the GPL and they wanted something equivalent. When Oracle bought Sun, they largely stopped caring about Btrfs. RedHat picked up some of the developers, but it never got the amount of testing required for a production filesystem.
sudo mod me up
(Score: 2) by tekk on Thursday August 03 2017, @03:30AM
Sorry, that's not what I meant by in development longer. I mean that ZFS was shipping, as I understand it more or less as ZFS is today, 4 years after its inception (2001). It took btrfs 7 years just to decide what its on-disk format should be permanently with zfs to draw inspiration from.
(Score: 2) by driverless on Thursday August 03 2017, @10:29AM (3 children)
The problem with ZFS is that it's designed for big iron, don't even think about running that on anything less than serious server-grade hardware. With BTRFS gone that leaves ext2^H3^H4, which is sort of the FAT32 of Unix filesystems, it's the hacked-over fallback system that you use if nothing better is available, with its main selling feature being that at least it's not FAT16.
Maybe it's time to revive murdersYourWifeFS?
(Score: 2) by TheRaven on Thursday August 03 2017, @10:41AM (2 children)
sudo mod me up
(Score: 2) by driverless on Thursday August 03 2017, @10:58AM (1 child)
My Raspberry Pi, my mom's Core i3 desktop, and my niece's school laptop are all very happy for your 16GB laptop with 2TB of SSD that can run ZFS.
(Score: 2) by TheRaven on Thursday August 03 2017, @03:03PM
sudo mod me up
(Score: 4, Insightful) by loic on Wednesday August 02 2017, @04:23PM (11 children)
The raid code is known to be flaky (https://btrfs.wiki.kernel.org/index.php/RAID56 [kernel.org]). I heard about compression issues too, though I had only minor issues with it (zlib CPU usage on old hardware, lzo did the trick). I read other complains about snapshot performance issues, though I have not noticed over 2 years (on small servers and around 80 snapshots, though). BTRFS is known to be factually slower when writing and reading compared to xfs and ext4.
So in a nutshell, if you use your average mdadm powered raid and have moderate performance requirements, you probably will not notice a thing.
But the real story is that Red Hat is pushing its own premium products:
- http://permabit.com/products-overview/albireo-virtual-data-optimizer-vdo/ [permabit.com]
- and https://www.redhat.com/en/about/press-releases/red-hat-acquires-permabit-assets-eases-barriers-cloud-portability-data-deduplication-technology [redhat.com]
(Score: 3, Interesting) by KiloByte on Wednesday August 02 2017, @04:53PM
RAID5/6 has never been declared stable. Unlike mirror RAID, parity RAID is in the "here be dragons" land, together with qgroups, and if you use them despite the warnings, kiss your data goodbye.
The only problem here is that the warnings are nowhere big enough. Sadly, my patch to make them appropriate [spinics.net] hasn't been taken. I've put a slightly less in-the-face warning into Debian 4.9 kernels, though.
4.12 has a bunch of drastic improvements here, and RAID5/6 data (ie, -draid5 -mraid1) should be good enough for adventurous users on non-production machines, on 64-bit machines only. Unlike MD, btrfs can have a different level for data and metadata, and a write hole issue results with a single corrupted file (data) or likely total filesystem loss (metadata) -- but with metadata usually taking around 2% space, no one cares you get only 1/2 capacity (raid1) instead of 2/3 (raid5) for it.
Ceterum censeo systemd esse delendam.
(Score: 5, Interesting) by sjames on Wednesday August 02 2017, @05:29PM (9 children)
It's not really surprising that BTRFS isn't as fast as XFS (SGI's filesystem back in the '90s when file I/O was barely fast enough for video) or even ext4 since neither have to do COW to support an advanced feature set.
ZFS and BTRFS are the most interesting next filesystems on offer. ZFS disqualifies itself by not having a compatible license and so requires a number of workarounds. While that may be OK for some users who want ZFS on a data volume, it simply won't do as a default root filesystem.
That leaves BTRFS. It actually works quite well as long as you avoid raid5/6. In some ways it is actually superior to ZFS. For example, it's handling of raid1. While ZFS really wants devices kept in pairs, BTRFS doesn't care about that, it just makes sure there are 2 copies of everything and they are on different devices. Add or remove devices as necessary. BTRFS doesn't insist on snapshots being special things that aren't cloned filesystems. ZFS can have better performance, but only if you throw a metric assload of memory at it.
Really, I think it's time to declare RH to be not actually Linux and leave them to disappear up their own backsides. They can take systemd and freedesktop with them.
(Score: 2) by kaszz on Wednesday August 02 2017, @06:13PM
I think you are on to something..
Always experienced them as something odd in practical interactions. Linux way, BSD way... and the RedHat not anything else way.
(Score: 1, Flamebait) by Grishnakh on Wednesday August 02 2017, @07:03PM (3 children)
Really, I think it's time to declare RH to be not actually Linux and leave them to disappear up their own backsides. They can take systemd and freedesktop with them.
If you're going to do that, then we need a good replacement for systemd (and no, the old sysvinit isn't a good replacement), just like a Chevy Corvair (after the fix) is not a good replacement for any modern vehicle).
However, if you can get Red Hat to keep Gnome3 to themselves, I'm in hearty agreement.
(Score: 0) by Anonymous Coward on Wednesday August 02 2017, @07:54PM (1 child)
They're are many alternative init systems. Many /most of the good ones also handle process management... If you think the choice is systemd or medieval bs, you're driving the koolaid.
(Score: 3, Touché) by kazzie on Thursday August 03 2017, @10:08AM
Don't drink and drive!
(Score: 2) by sjames on Thursday August 03 2017, @12:31AM
There are many to choose from. Most don't try to wedge themselves into the system like systemd does.
(Score: 3, Informative) by pendorbound on Wednesday August 02 2017, @07:04PM (1 child)
Root on ZFS is extremely do-able. It's easier if you have a /boot partition on something like ext2, but recent GRUB can read your kernel and initrd directly from a zfs /boot or single root containing /boot.
You need an initrd with the ZFS module in it, but that's really the only requirement different from using an in-tree driver for root. The distro-level support scripts for it are quite solid. There's no licensing issue with using it in initrd in this fashion.
I've been using root on ZFS with Gentoo for about 8 years now. Initially I used ext2 for /boot. I moved to some custom patched versions of GRUB, and now using generally available GRUB with no more separate /boot.
(Score: 2) by sjames on Friday August 04 2017, @12:09AM
Good to know! :-)
(Score: 3, Insightful) by VLM on Wednesday August 02 2017, @08:39PM (1 child)
Not bad, but a unix-like might be an even better phrase. And FreeBSD is freaking awesome and works great. No licensing problems, "just works". Has a sane and easy/fast to debug init system, totally non-windows/redhat-alike in general.
Don't dedupe which is cool but both not terribly useful and eats memory, or if you're spending an inordinate amount of money on drive space, budget perhaps $100 of ram for every $1000 of spinning rust. If you're building SSD and you have enough storage for a "normal" amount of ram to be a problem, then you must have a very large budget indeed and a couple gigs here and there will be OK.
(Score: 2) by sjames on Wednesday August 02 2017, @09:48PM
Perhaps so. No slight to FreeBSD intended.
(Score: 4, Informative) by WillR on Wednesday August 02 2017, @04:55PM (1 child)
porn and pirated musictotally legitimate Linux ISO collection more times than reiser4 did.(Score: 2) by sjames on Friday August 04 2017, @12:22AM
Other than using raid > 1, what have you seen cause a problem?
(Score: 3, Funny) by Bot on Wednesday August 02 2017, @07:21PM (2 children)
> What are the disadvantages of Btrfs?
for one, it is reportedly being called butterFS.
Account abandoned.
(Score: 1, Informative) by Anonymous Coward on Wednesday August 02 2017, @09:23PM (1 child)
uhh, it's pronounced "Butt R"!
(Score: 1, Informative) by Anonymous Coward on Friday August 04 2017, @07:24PM
Not sure how they got butterfs out of btrfs, it's clearly bitterfs.
(Score: 2) by chromas on Wednesday August 02 2017, @11:36PM
Until late last year, I was using btrfs on two luks-encrypted disks (no RAID or anything). It worked fine most of the time, but any time there was much disk activity firefox would freeze up, or when doing something even more I/O-ier like moving a big file, the whole desktop would lock up.
But I gave up on it when trying to rip a CD caused one of the disks to disappear (bad optical drive?) and btrfs absolutely refused to do anything with the disk after that. Trying to mount it, it would just tell me it wasn't a btrfs volume and the offline restore tool would just segfault. I've since put XFS and EXT4 on those same disks (still encrypted) and have no problems. Also tossed the optical drive since it threw errors during POST.
(Score: 2) by Entropy on Thursday August 03 2017, @12:25AM (3 children)
BTRFS is an inferior version of ZFS, basically. The interface is awful in comparison, and it has many silly requirements(why exactly would I want snapshots mounted all the time or read-write? Kinda defeats the point.) Also why is a snapshot command like a copy command?
btrfs subvolume snapshot /mnt/data /mnt/data_mysnap
vs
zfs create mnt/data@mysnap
Which is more intuitive? A snapshot isn't a COPY. It never was a copy. It's a set of pointers moved around. In BTRFS I furthermore have to worry about some program bumbling into my snapshot and changing something because it's both obviously mounted, and writeable. BTRFS to my knowledge has never had volume support(like devices).
Keep in mind with ZFS's volume support comes snapshot of volumes(think virtual machines) and block-level replication of those virtual machines.
(Score: 2) by sjames on Friday August 04 2017, @01:13AM (2 children)
You can mark the snapshot read only if you like. the fs doesn't treat it as distinct from a COW duplicate because it has no need to. You may make it read only and treat it as special if you want, it's an administrative policy.
The snapshot/copy isn't really mounted all the time, think of the root volume of a btrfs as the administrative interface. You can unmount that when not operating on the filesystem, or put it where only root can see it. use the subvolid option to mount to directly mount the subvolumes without exposing the root volume with the snapshots in it.
You are correct about volume support. It would be nice for BTRFS to get that at some point.
(Score: 2) by Entropy on Friday August 04 2017, @01:19AM (1 child)
You can work around it... It's just always felt more clumsy to me than ZFS. Seeing as ZFS came first, and has wide enterprise support I wish they just stole the interface. As to not mounted all the time, I think if you find / ...it'll list all the files. Can you truly make it not mounted as in it isn't in the directory tree anywhere?
(Score: 2) by sjames on Friday August 04 2017, @01:54AM
Yes. By convention, you create a subvolume called @ and mount it to /. You may also create things like @home or (depending on need, @username) and mount it all up using the subvolid option.
I typically ALSO choose to mount the root as /btrfs with root owning the mount point and only root granted access, but that is purely optional and a matter of taste. This means that /btrfs/@ is the same as /. Skip that and it's not in the tree.