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: 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