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