24 ms·

⁠Btrfs has been deprecated in RHEL

368 points by alrs 9y ago

drawnwren 9y ago
I know this says redhat.com, but title is still a bit misleading. Btrfs has been deprecated on RHEL, but it is still under active development on its own.
- em3rgent0rdr 9y ago
  HN has a problem of users posting misleading titles.
josteink 9y ago
Deprecated? In favour of what? Will Redhat too (like Ubuntu) start shipping ZFS?
- tbrock 9y ago
  XFS is the default FS on RHEL now, so likely that.
  - vacri 9y ago
    Do you know if XFS can shrink volumes yet? As far as I'm aware, that's the only limitation it has compared to other filesystems of that era.
    - pferde 9y ago
      Nope, still can't. Not online, not offline.
    - rwmj 9y ago
      It can't, but you're probably better off using trim/discard/virt-sparsify rather than shrinking filesystems. Even on filesystems like ext4 that support it, shrinking can cause strange fs performance problems.
- mjevans 9y ago
  I supposed their upgrade path is... * Make fresh backups * Verify the backups * Re-install and use the backups
  - paulie_a 9y ago
    Basically. Those steps should be done regardless of FS. I heard this on a podcast recently but if you are not doing that you end up with "schrodinger backups"
- paulie_a 9y ago
  The following will sound snarky but I would personally prefer ext2 if the other choice is btrfs. "ButterFs because your data melts away"
- riffraff 9y ago
  I am curious as to the same. The document says > 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. but it's unclear what this means exactly.
  - pinewurst 9y ago
    Like their Permabit acquisition: https://www.redhat.com/en/about/press-releases/red-hat-acquires-permabit-assets-eases-barriers-cloud-portability-data-deduplication-technology?sc_cid=7016000000127NJAAY https://www.redhat.com/en/about/press-releases/red-hat-acqui...
- dman 9y ago
  XFS - the workhorse that keeps on running.
- pinewurst 9y ago
  My best guess is XFS coupled with Permabit (which they just bought and will open source) compression and dedupe services. Probably layered on an enhanced mdraid too. I'm guessing that the ZFS licensing hairball is a bridge too far for even Red Hat, so they'll cobble together equivalent-ish functionality - even if it's not anywhere near as elegant as ZFS's integral data production and reduction.
- silly-silly 9y ago
  Red Hat will never ship ZFS, because its an entity that exists in the US and a probable target for lawsuits / license violation if ZFS is included.
  - cookiecaper 9y ago
    What's the risk involved for Red Hat in shipping ZFS? OpenZFS and ZFS-on-Linux are under the CDDL, a legitimate open-source license that some feel may be GPL-incompatible. Red Hat distributes non-GPL programs as a matter of routine, and I'm sure this includes other CDDL programs, especially considering Red Hat's enthusiastic involvement in the Java ecosystem. The only potential risk is that the GPL is so virulently infectious that any driver is automatically GPL'd by virtue of its own existence as a compiled kernel module, but that possibility seems fairly remote, and it hasn't seemed to affect the distribution of other purportedly-non-GPL kernel modules. I'm not a lawyer so maybe I'm missing something.
    - cryptonector 9y ago
      The risk is FUDdy, but not entirely imaginary. In particular there's the thread of a threat of patent lawsuits from a variety of players in the industry. Of course, that's always the case in this industry, so I don't buy it. But RH might, and that's their call. My guess too is that if Canonical manages to go a few years without a lawsuit from kernel copyright holders then we might see more of what it is doing. But RH would -I guess!- still suffer from patent FUD and so stay away from ZFS. That's all fine by me. The better for RH's competition. More competition, mo' betta.
JoshTriplett 9y ago
Has anyone here tried bcachefs (http://bcachefs.org/ http://bcachefs.org/) for some of the same use cases as btrfs? What do people think of its current state?
- lathiat 9y ago
  You'd need to read up on it but the TL;DR i got from previous comments was that previously it was being funded by a company that wasn't 100% aware of the entire situation around it (they used it in their commercial product, management didn't fully understand it was being released as open source, though I also understand they didn't own the rights to the entire code base so basically that was necessary effectively). The person developing it left that company and is seeking his own funding for it but that generally the development was significantly stunted as a result. It seems a bit here-say-ish though, so please don't assume I'm entirely correct on all fronts there and I'd encourage you to research it further!
  - riffraff 9y ago
    OT, but I think you meant "hearsay-ish"
  - joecool1029 9y ago
    >I'd encourage you to research it further! On that note, their Patreon is a better primer than the website is: https://www.patreon.com/bcachefs https://www.patreon.com/bcachefs
    - lathiat 9y ago
      Happy to see his Patreon is looking "healthier". I mean $1500/m isn't really that much but I'm sure last I looked it was much lower. In other news.. consider supporting the people that support you! Personally, I spent over $100/month on Patreon. Most of those are creators rather than open source people but there are a couple of open source ones such as Ondřej Surý who works on PHP packaging in Debian/Ubuntu
lathiat 9y ago
This is specific to RHEL7, notably that they won't backport any further kernel updates and won't move it from Technology Preview to release. Red Hat wasn't really driving btrfs development at all from what I am aware of. ⁠Btrfs has been deprecated 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.
jmspring 9y ago
It's OT but how many people actually use RHEL? Or CentOS (more likely). I'm not a fan of systemd, but have really loathed CentOS/RHEL compared to Debian/* for years.
- esaym 9y ago
  >It's OT but how many people actually use RHEL? Hopefully a lot because, like it or not, RHEL puts a ton of work into the linux kernel and other userland linux tools. We need them to stick around.
  - jmspring 9y ago
    As do others and they were one of the main systemd backers. Still doesn't answer the question. If I'd left out my preference, probably would have had fewer downvotes.
- myrandomcomment 9y ago
  As a general rule if the end customer was finance/bank their Linux flavor was RedHat (someone to yell at when it broke). Other tech companies / web types it was Ubuntu. This was my experience in over 4 startups where these were are end customers. Your mileage may vary.
  - jsmthrowaway 9y ago
    CentOS is extremely popular among startups. It lets you directly use RPMs, which many software publishers distribute on their own (not the case for debs, often), and gives you an upgrade path to buy RHEL when you want someone to yell at and not throw away all your automation. I’m not trying to start a flame war here (honest), but among most “usual web” ops folks I know, the opposite of what you’re suggesting seems to hold and Debian/Ubuntu are looked at as an odd choice. It’s probably hire #1 going with what they know, more than anything, and it could very well be selection bias regarding the people I know. I’d love to see stats. I’ve been working with CentOS or OEL in my own roles for several years now, and I’ve never chosen it. (Not saying I wouldn’t, just that it’s been there when I get there.)
louwrentius 9y ago
Sounds to me that Btrfs is done for long-term. So now what?
- cyphar 9y ago
  Facebook, Fujitsu and SUSE all contribute to btrfs and it is still being actively developed (it's the default filesystem for SUSE Linux Enterprise). Red Hat stopped contributing a while ago since most of their btrfs developers moved to Facebook. "Done for the long-term" is a major overstatement IMO.
  - tjoff 9y ago
    Well, for those of us that have been waiting on btrfs for a frigging decade I get the feeling that it is never going to be ready. If I wait another decade, will btrfs have matured? Will there be ANY half-modern filesystem for linux? I'm not convinced. Currently bcachefs seems more appealing but well, long way to go there as well.
    - osandov 9y ago
      What problems have you had with Btrfs recently?
      - tjoff 9y ago
        That, exact, question is the question you get, and has got for years and years, when questioning btrfs maturity. It seems as if btrfs always "just yesterday" got mature just when that last thing was fixed. Sorry, but I don't believe enough in btrfs to try it out for real (and don't have time to play with it just for fun). Especially when playing with more advanced features, the status page does not inspire confidence. The paragraph on btrfs in https://www.patreon.com/bcachefs https://www.patreon.com/bcachefs seems spot on and exactly the feeling you get after spending a decade of hope on btrfs. And that kind of review is exactly what you don't want on the brand new finally-we-can-store-data-properly-on-linux solution.
0xFFC 9y ago
Wow, I thought their long term plan was to switch to Btrfs. Now it is deprecated? What happened there?
- lathiat 9y ago
  I think you might be confusing with SuSE? Generally though sadly btrfs just isn't getting the man hours from any commercial sponsor it seems :(
  - cyphar 9y ago
    Facebook, Fujitsu and SUSE are all actively contributing to btrfs. The idea it isn't getting "the man hours from any commercial sponsor" is ludicrous.
    - jeltz 9y ago
      And this is what makes me worried about the design of btrfs. If after all these man hours Redhat thinks it still is not stable enough I worry if it ever will be.
      - cyphar 9y ago
        Why are you shifting the goal posts? Also, Red Hat has not been a significant contributor to btrfs for a while (they've mostly been working on XFS and lvm/devicemapper) so them dropping it is hardly a surprise -- Red Hat is not the arbiter of what is a good technology, and there are many other parties that work on Linux.
        jeltz 9y ago
        Are you confusing me with someone else? Because I have never claimed that Redhat has been a major contributor behind Btrfs nor have I claimed that Btrfs development is lacking in contributors. And to me this is just another voice which is septical of the current state of Btrfs. And while Redhat is not the only voice, it is an important voice.
justin66 9y ago
I am as happy as anyone that XFS is finally getting the position of honor it deserves on enterprise Linux (something like 15 years later than it should have, grumble grumble) but it doesn't really take the place of what btrfs was trying to do. Only ZFS is in a position to do that. I wonder if there are any plans for supporting the native port on RHEL.
- mrweasel 9y ago
  Redhat hasn't been on the best of terms with Oracle, so I suspect that they want to stay clear of ZFS. It does however leave Redhat without a more modern feature rich filesystem. Perhaps Redhat could help to develop snapshots on XFS. It's not the only feature XFS is missing, but it's a start.
  - cyphar 9y ago
    > Perhaps Redhat could help to develop snapshots on XFS. It's not the only feature XFS is missing, but it's a start. Upstream has been working on adding more btrfs-like features to XFS, but I believe that RHEL encourages using devicemapper snapshots (which you then format with XFS).
    - 2ion 9y ago
      > Upstream has been working on adding more btrfs-like features to XFS, but I believe that RHEL encourages using devicemapper snapshots (which you then format with XFS). Exactly, mountable and mergable snapshots have been supported by a LVM/devicemapper stack for a long time.
      - rbanffy 9y ago
        It's still a bit more involved than the transparent snapshots ZFS and, to a lesser degree, BtrFS offer. I'm not happy with this and sincerely hope this position changes in the future.
  - boomboomsubban 9y ago
sparky_ 9y ago
That's too bad. The subvolume [0] features were an interesting paradigm. Kind of let you have a virtual filesystem-within-a-filesystem. [0] https://en.wikipedia.org/wiki/Btrfs#Subvolumes_and_snapshots https://en.wikipedia.org/wiki/Btrfs#Subvolumes_and_snapshots
- rleigh 9y ago
  It's certainly interesting, but if you look at the ZFS design they were inspired by, they got a lot wrong. Some points to consider: With ZFS, you have a hierarchy of datasets. These inherit properties from their parents, and while the mountpoints can also mimic this hierarchy, the mountpoint property can be set independently. Btrfs couples the two concepts, forcing subvolumes to be in a specific place in the actual filesystem; zfs datasets in comparison are purely metadata and are for organisation and administration, not direct use in the filesystem hierarchy. ZFS snapshots are read-only, and clones of these snapshots are datasets in the hierarchy. Btrfs snapshots are read-write by default, which in some ways defeats the point of a point-in-time snapshot. You can also make changes to a ZFS clone and later promote it to replace the original dataset. Likewise rollbacks. Btrfs makes no provision for doing either; you have to delete the original and then rename the snapshot, which isn't atomic. ZFS' metadata preserves all relations between datasets, snapshots and clones. The ZFS way of doing things makes things safe and accessible for system administration. There's no way to confuse the origin of a snapshot because it's tied to a parent dataset. Likewise clones of snapshots, unless you deliberately choose to break the link. The Btrfs way looks superficially nicer, but in practice is much less flexible, and potentially more dangerous since you don't have the ability to audit what came from where and when. Btrfs snapshot performance is also abysmal. ZFS handles snapshots simply by recording the transaction ID, which makes them really lightweight (and it also provides "bookmarks" which are even lighter weight). ZFS keeps the referenced blocks in deadlists, and its performance is excellent (compare how fast snapshot deletion is between the two). ZFS also allows delegating permissions to perform snapshot, clone, rollback etc. to normal users; I'm unware of Btrfs allowing such delegation--some operations can be performed like snapshotting, but not deletion, while ZFS permits this all to be configured transparently.
  - 9y ago
kodfodrasz 9y ago
I wonder if this is a response to Oracle's Java9/Jigsaw push, where RedHat was forced to give up its position.
bedros 9y ago
I think this is a political move disguised as technical move oracle pays the developers of btrfs [0] redhat hates the guts of oracle, since oracle released oracle linux, which is a clone of redhat enterprise (based on centos) so, redhat wants to cripple btrfs and hurt oracle. However, btrfs is my favorite FS, been using it on my home computer and backup drives for at least 6 years, before it was included in the kernel, love the subvolumes, snapshots, and compression; never had issues with it . [0] https://oss.oracle.com/~mason/ https://oss.oracle.com/~mason/ [Update] Chris mason no longer at Oracle since 2012
- cleech 9y ago
  Chris Mason left Oracle for Fusion-io back in 2012 and then from there to Facebook in 2013
- skrause 9y ago
  Chris Mason, the principal Btrfs author, left Oracle over 5 years ago: https://en.wikipedia.org/wiki/Btrfs#History https://en.wikipedia.org/wiki/Btrfs#History "In June 2012, Chris Mason left Oracle for Fusion-io, which he left a year later with Josef Bacik to join Facebook; while at both companies, Mason continued his work on Btrfs."
- sargun 9y ago
  Oracle still has a couple developers on their payroll that do BtrFS development: * Liu Bo * Anand Jain
- newscracker 9y ago
  > However, btrfs is my favorite FS, been using it on my home computer and backup drives for at least 6 years, before it was included in the kernel, love the subvolumes, snapshots, and compression; never had issues with it . Slightly off topic. I chose btrfs as my main filesystem recently on a system running Ubuntu/Xubuntu. I have done some research on backing up (with the advantage of snapshots) but it looks like there aren't (m)any graphical tools (this gets a little more confusing with /@ and /@home subvolumes on the same partition being treated separately for snapshots, AFAIK). Do you manage it all from the command line and/or do you have any suggestions for graphical tools to do "as-is clones of entire partitions" (and also incremental backups) to local external drives (not over the network)? Or if you could point to any great documentation or blog posts on this topic, that'd be helpful too (I have read some bits of the btrfs wiki and the btrfs parts in the Arch wiki). Currently I'm doing a plain rsync using Grsync, and not really taking advantage of btrfs features like snapshots. The main reason I'm looking at avoiding the command line is to make it easier for others around me to use it.
pmontra 9y ago
Offtopic, but if anybody from RedHat and especially Mozilla read this, go to that page with an Android phone, possibly with a small screen: To RedHat: do something for that menu at the left. It stays in the way when scrolling and zooming. The X to close it is not immediately visible on a small screen. Expected behavior: the menu scrolls away with the page and doesn't stay fixed in the way of the reader. To Mozilla: open the page with Opera and copy what you see there. Tldr: autofit the text in the screen width. Maybe Chrome does the same. Btw, reader mode doesn't kick in.
- tyfon 9y ago
  Worse, I browse without javascript and their page has no text. It's utterly terribly designed to be an open source information page.
  - creshal 9y ago
    Even as paying customer I wouldn't want to put up with that shit.
    - lunchables 9y ago
      You mean ESPECIALLY as a paying customer! You paid for the right to bitch, and you should.
  - jwilk 9y ago
    The text is there, just invisible. Disable CSS and it'll show up.
- icebraining 9y ago
  Re: Mozilla, they are aware, and there are a couple of about:config flags to enable text reflow on page load and on tap-to-zoom, but they're disabled by default "due to a number of reasons (mainly performance)".
  - pmontra 9y ago
headlands 9y ago
The default file system for the root partition of SUSE Enterprise Linux is Btrfs. So RHEL have stopped supporting it. It is the only filesystem that implements many of the features found in ZFS.
- fundabulousrIII 9y ago
  It's also buggy as hell and though I've used SuSE for 17 years I almost stopped this year due to btrfs. Terrible decision from SuSE: but they aren't the company they used to be.
vbezhenar 9y ago
I don't think this matters much. If you want btrfs, you'll likely be able to get kernel module from EPEL even if they'll stop shipping it. It's like deprecated and unsupported LXC which could be used just fine and which doesn't have usable replacements.
- tylerjd 9y ago
  > deprecated and unsupported LXC Where did you hear this? This is news to me. https://linuxcontainers.org/ https://linuxcontainers.org/ and https://github.com/lxc/lxc https://github.com/lxc/lxc both seem active and supported by Canonical to me. The only deprecated project by them is listed to be CGManager.
  - vbezhenar 9y ago
    LXC is unsupported by RHEL. They chosen Docker as a primary container solution. LXC as project is fine, of course.
kureikain 9y ago
I have used Btrfs in production and I would say it's great. It's super easy to just add an extra EBS volume and attach to a Btrfs volume and now you have more disk space. Performance is good enough for me as well, I used it as storage for InfluxDB and Docker. Luckily this is only Redhat, not Btrfs itself.
- beedogs 9y ago
  Unfortunately, RedHat tends to be the trendsetter in the Linux world. Once it's gone from RHEL, it'll be gone from most other RPM based distros soon enough. It's kind of a shame that one company has grown to dominate the Linux software ecosystem, often to the detriment of all involved.
  - gcp 9y ago
    Red Hat has a lot of core Linux contributors on their payroll. Their status is, AFAIK, not undeserved.
  - smarnach 9y ago
    RPM-based distros make up maybe 10 % of the Linux installations these days, so we should not overstate RedHat's influence.
    - rantanplan 9y ago
      RHEL makes up maybe 99.9% of the Linux enterprise installations these days, so we can't overstate RedHat's influence.
      - cyphar 9y ago
        I don't think that number is even close to accurate. SLE almost certainly makes up more than 15% of the market alone. And that's ignoring all of the other enterprise distributions. I believe that 2015 estimates from the IDC[1] had RHEL at ~60%, SLE at ~20%, Oracle Linux at ~12% and "Other" at ~8%. But I can't access the document at the moment. [1]: http://www.idc.com/getdoc.jsp?containerId=US41360517 http://www.idc.com/getdoc.jsp?containerId=US41360517
X-Istence 9y ago
More importantly Red Hat has deprecated FCoE in RHEL, which is big news, because at a previous $JOB they went all in on FCoE because it was supposed to be the future.
- B1FF_PSUVM 9y ago
  https://en.wikipedia.org/wiki/Fibre_Channel_over_Ethernet https://en.wikipedia.org/wiki/Fibre_Channel_over_Ethernet
- KaiserPro 9y ago
  FCoE died a death <2013. Expensive hardware, with little gain sadly. It was a nice idea, however at its very core is a fairly large problem: converged network adaptors are problematic. Unless you have lots of bandwidth in said adaptor (ie 56gig inifiband) you are going to get contention between network and disk IO.
  - X-Istence 9y ago
    I agree, not only that, but at least with Cisco gear FCoE was a real pain in the behind to manage and configure. So much duplication in configuration and settings across a lot of gear, and it never was as smooth as they made it out to be.
- jabl 9y ago
  Ouch? What's the replacement then? ISCSI, or going back to FC? Or is everything cloud something these days? :)
  - lunchables 9y ago
    Yeah iSCSI and NFS. Also affecting this is the huge growth in "Hyperconverged Infrastructure" (HCI).
    - X-Istence 9y ago
      Hyperconverged Infrastructure is definitely eating a lot of the traditional storage vendors lunches. Using Ubuntu with JuJu/Ceph/OpenStack all on the same servers provides plenty of power while reducing costs. Even VMWare has come on board with vSAN which pushes out vendors like EMC/NetApp because you no longer need them when you can just create it against your existing hypervisors. Sure you can run one or two less VM's on it, but you have less cost overall.
cmurf 9y ago
Unsurprising. Red Hat has not hired upstream Btrfs developers for years, where SUSE has hired bunches. Meanwhile Red Hat has upstream ext4, XFS and LVM developers. If you're going to support a code base for ~10 years, you're going to need upstream people to support it. And realistically Red Hat's comfortable putting their eggs all in the device-mapper, LVM, and XFS basket. But, there's more: https://github.com/stratis-storage/stratisd https://github.com/stratis-storage/stratisd Btrfs has no licensing issues, but after many years of work it still has significant technical issues that may never be resolved. page 4 Stratis version 3.0 Rough ZFS feature parity. New DM features needed. Page 22 https://stratis-storage.github.io/StratisSoftwareDesign.pdf https://stratis-storage.github.io/StratisSoftwareDesign.pdf Both of those are unqualified statements, so fair or unfair my inclination is to take the project with a grain of salt.
- gcp 9y ago
  As for the significant technical issues, one thing is the core decision to make it a CoW system, which has fundamental performance issues with many workloads that are exactly those used in the server space. You can disable CoW, but you lose many reasons to use btrfs in the first place if you do. When I gave up on it there were also fundamental issues with metadata vs data balancing, not-really-working RAID support, and so on...
  - pgaddict 9y ago
    I find the suggestion that the technical issues are caused by the CoW design a bit strange. Sure, making the filesystem CoW-based means there are some inherent costs, but it allows the filesystem to implement some interesting features (e.g. snapshots) in a more efficient way. For example if you want to do snapshots with ext4/xfs, you'll probably do that using LVM (which you can see as turning the stack into a CoW). In my experience the performance impact of creating a snapshot on ext4/LVM is about 50%, so you cut the performance in half. While on ZFS the impact is mostly negligible, due to the filesystem is designed as CoW in the first place. And thanks to ZFS we know that it's possible to implement a CoW filesystem that provides extremely stable and balanced performance. I've done a number of database-related tests (which is the workload that I do care about) and it did ~70-80% TPS compared to ext4/xfs (without snapshots). And once you create a snapshot on ext4/xfs, the performance tanks, while ZFS works just like before, thanks to the CoW design. Unfortunately, BTRFS so far hasn't reached this level of maturity and stable performance (at least not in the workloads that I personally care about). But that has nothing to do with the filesystem being CoW, except perhaps that CoW maybe makes the design more complicated.
buserror 9y ago
Well I used btrfs as a root filesystem for quite a while, until I realized it was pig slow for sync() -- I mean, it would take AGES to do and apt-get upgrade for example. I ended up having to do some tasks using 'eatmydata' [0] to make it all better, risking filesystem corruption in trade for speed. Also, at the time, there was no functioning fsck. So I moved back safely to ext4 and never looked back! [0]: https://www.flamingspork.com/projects/libeatmydata/ https://www.flamingspork.com/projects/libeatmydata/
- buster 9y ago
  Over the recent years on every new laptop install i switched between filesystems, so i had ext3/4, btrfs and (currently) xfs on my system. I have to say, btrfs had the most glitches (a few years back), although it worked ok'ish (no data loss). Nowadays, i must say that i very much prefer a stable filesystem with as little complicated logic as possible. I actually never use snapshots or subtrees! I never put another disk in my laptop (where would that go?!) so i don't need to do dynamic resizing (while online of course!). All this makes the filesystems a lot more complex then it has to be. I've also run into problems using ZFS on Solaris some years back which took ~2 weeks in dtracing what the hell is going on. Of course it was related to CoW. My lessons learned: Check your requirements. Will you really need and use subtrees/snapshots/XYZ on your system? Will you really need to do online-resizing? If not, just use a stable, simple filesystem. There are perfect usecases for ZFS or btrfs. But not everyone needs the advanced features.
  - viraptor 9y ago
    > Will you really need and use subtrees/snapshots/XYZ on your system? It's a valid question, but not the best one. Almost nobody needs snapshots. But they make things easier. You most likely don't need a journaled fs in your laptop either (battery level notification should take care of the issues). But it does make life better. "Need" is not the threshold I'm interested in. Most features, I'd like. One feature I think I do need most is scrubbing, which is still absent from most filesystems :(
    - 9y ago
shmerl 9y ago
That's weird. What do they have against btrfs?
- nul_byte 9y ago
  They don't see it as stable enough to move beyond tech preview.
  - rurban 9y ago
    It is also extremely slow. And the known RAID problems didn't get better.
seesomesense 9y ago
Not surprised. I have been using BTRFS for years. Unfortunately, one gets the feeling that not too much development has been going into it.
- horusthecat 9y ago
  Having been using BTRFS at home for years, i get the exact opposite impression... I've had bugs (kernel panics) that just disappear on the next update. I'm happy with the RAID1 ease of use. But even there, like some have said, manual scrub/balance--which is still nice to have--indicates a design flaw. If I was in ops I would not use btrfs on anything but lab experiments... if i can get hardware RAID, then I can blame the vendor and the equipment
alexdowad 9y ago
I tried btrfs and got bitten by bugs; not doing that again. Judging from this move by RH, it looks like I wasn't the only one.
- lucb1e 9y ago
  What bugs? I recently setup a software mirroring raid with btrfs and I'm loving features like checksumming. It makes me feel my data is quite safe and can't bit rot anymore. So far it is working fine.
  - rodgerd 9y ago
    Hi. Did you notice that the official description of RAID-1 is "Mostly working"? Are you aware if one of your drive fails, you have one chance to re-mirror it, before the remaining drive can no longer be mounted read-write and you need to dump the filesystem and re-create from scratch?
    - andrewstuart2 9y ago
      RAID1 meaning you get one chance. Just move to RAID10 if you're worried. (/s)
      - Elhana 9y ago
        It has exactly the same bug with RAID10.
    - viraptor 9y ago
      That's just how raid mirroring works. Now sure why you mention it specifically for btrfs?
      - rodgerd 9y ago
        No, it isn't. You can run a ZFS VDEV or a Linux mdraid as a single-disk RAID 1 unit until the remaining disk fails. You have an arbitary number of reboots/remounts to fix the problem.
erikb 9y ago
Why is there no explanation for this? It seems weird to deprecate something that most people haven't even started using yet.
snakeanus 9y ago
Still waiting for bcachefs. It's like btrfs except it does not suck. It also has proper encryption.
- betaby 9y ago
  How many developers involved in bcachefs full time? What I've heard it's a one man show.
pmlnr 9y ago
Great... So can I please have something that can do transparent compression? That is my sole reason for using btrfs. (My personal stack is on ZFS with Debian and I'm never going to look back from that, even if I sometimes have speed issues due to SATA instead of SAS system underneath it; ZFS compression and snapshots are incredibly powerful.)
Mobizone_Ng 9y ago
Twitter Introduces Turn Off Notification From The Strangers. — [SEE HOW...http://mobizone.ng/twitter-introduces-turn-off-notification-strangers/ http://mobizone.ng/twitter-introduces-turn-off-notification-...
parasubvert 9y ago
Concourse (which is a CI/CD system that orchestrates Docker containers) recently switched from btrfs to overlay to fix performance and stability issues. For those with morbid curiosity on the many stability issues with btrfs as a container file system, this is chronicled in Github: https://github.com/concourse/concourse/issues/1045 https://github.com/concourse/concourse/issues/1045
stargrazer 9y ago
Considering the size of disks now-a-days, the chance of bit rot is high. And (I don't have the original source) on SSD, bit rots probability is higher still. So... ZFS and BTRF have meta-data as well as data checksumming. From what I've read, XFS may have metadata checksumming, but not on the data side of things. I consider checksumming important. Do others? What is the solution? What other file systems offer that sort of capability? Snapshotting is a second go-to function. Particularly when it is integrated into the LXC container creation process. (There was a comment elsewhere here which said LXC is on it's way out.... huh? what?)
- legulere 9y ago
  > on SSD, bit rots probability is higher still Do you have a source for this? So far I believed that bit-rot rates are pretty similar.
  - stargrazer 9y ago
    A google search turns up a number of sources. Another concept which could use justification is whether SSDs bit rot more over long term than do spinning disks. I heard that somewhere as well.
    - legulere 9y ago
      Using google was the first thing I did. I couldn't find something substantial.
- ars 9y ago
  Use mirror raid and have mdadm do a full disk compare/check every month (this is the default on Debian). Additionally use smartmontools and configure it to do a short self test each night, and a long self test (i.e. full disk read) each week. This will catch/flag errors early, which mdadm will then detect.
  - Wicher 9y ago
    Disk A and disk B both contain file SomeFile. On disk B this file has rotted. When reading the file SomeFile into memory, the read will be distributed among the disks (for performance reasons) (and it will probby need to span a multiple of the stripe size). Ok, file is read into memory, including the bitrotted part from disk B. Now we write the file blocks back - as one does. Voila! Both disks now contain the bitrot. And mdadm will not complain - disk A and B are identical for the area of file SomeFile.
RX14 9y ago
I've done many bad things to BTRFS, used it on multiple drives of differing sises, used it on drives connected over the cheapest USB to SATA adapters I could find, used it on disks with consistent corruption for over a year, and it's handled it gracefully. I've also been using btrfs as the backend to docker for a long time on my desktop PC and never noticed any problems. BTRFS has been rock solid for me. I don't doubt it is more unstable than other filesystems, however it seems i haven't been unlucky enough to experience any issues. When using BTRFS, i've always stuck to the latest kernel releases, and run a scrub + balance every month. This is the advice I heard from people who used btrfs, and I wonder how many of the people who complain about data corruption do these steps. Perhaps their corruption bugs are solved in a newer kernel version. I've had multiple scrubs pick up data corruption, which other filesystems wouldn't have found. The only time btrfs corrupted my data was when I used the ext4 to btrfs conversion tool, it created an unmountable FS and then I just migrated my data manually.
- rleigh 9y ago
  You shouldn't have to do these steps. Manual balancing is a workaround for a critical flaw in the implementation. In my last major use of Btrfs, whole archive rebuilds of Debian, it would take less than 48 hours to completely unbalance a brand new Btrfs filesystem. ~25k snapshots continuously created and deleted over the period in 20 parallel jobs absolutely toasted the filesystem, even though it was 1% utilised for the most part, 10% at peak usage. The point I want to make is that a Btrfs filesystem can become unbalanced at some indeterminate point in the future, which makes it impossible to rely on if you want to guarantee continued service. I've also suffered from a number of dataloss incidents which likely are fixed now, but despite lots of bugfixing, there are still major flaws to address.
- cookiecaper 9y ago
  btrfs requires far too much maintenance to be a good general-purpose FS, and it absolutely crumbles under certain not-too-uncommon use cases (specifically, databases and VMs). I really wanted to like btrfs and used it extensively over the last couple of years, but I've finally given up and moved on to ZFS, and I'm grateful that I did. Give it a try.
jorrizza 9y ago
Strange decision, as systemd-nspawn[1] specifically mentions and supports btrfs as a CoW filesystem for its containers. And as far as I understand, systemd is primarily developed by Red Hat employees. So either they'll add support for CoW alternatives, or they'll remove btrfs support from systemd-nspawn all together. [1]: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html https://www.freedesktop.org/software/systemd/man/systemd-nsp...
- amorphid 9y ago
  There's nothing which prevents you from creating an empty block device file, putting btrfs on that, and mounting it.
- Torgo 9y ago
  nspawn uses btrfs snapshotting natively for its templating and no other FS (ZFS was explicitly rejected by Mr. Poettering because "it's not in the kernel") so yeah either they are going to have to do something about this or there will be a significant step down in functionality for nspawn. I can't see how this isn't really bad news for nspawn. I guess one option is to pull btrfs tree into Systemd :-)
josefbacik 9y ago
People are making a bigger deal of this than it is. Since I left Red Hat in 2012 there hasn't been another engineer to pick up the work, and it is _a lot_ of work. For RHEL you are stuck on one kernel for an entire release. Every fix has to be backported from upstream, and the further from upstream you get the harder it is to do that work. Btrfs has to be rebased _every_ release. If moves too fast and there is so much work being done that you can't just cherry pick individual fixes. This makes it a huge pain in the ass. Then you have RHEL's "if we ship it we support it" mantra. Every release you have something that is more Frankenstein-y than it was before, and you run more of a risk of shit going horribly wrong. That's a huge liability for an engineering team that has 0 upstream btrfs contributors. The entire local file system group are xfs developers. Nobody has done serious btrfs work at Red Hat since I left (with a slight exception with Zach Brown for a little while.) Suse uses it as their default and has a lot of inhouse expertise. We use it in a variety of ways inside Facebook. It's getting faster and more stable, admittedly slower than I'd like, but we are getting there. This announcement from Red Hat is purely a reflection of Red Hat's engineering expertise and the way they ship kernels, and not an indictment of Btrfs itself.
- appleflaxen 9y ago
  thanks for this context; i read this thread previously and had no idea of the "why" behind the news item. great comment to understand better.
- nailer 9y ago
  Thanks. Any indication why RH didn't hire btrfs devs? It looks like a decision was made that it wasn't strategic (obviously xfs on Linux has a much longer history).
  - josefbacik 9y ago
    They brought on Zach right before I left specifically to help with the effort, but he left as well. I can't really speak to Red Hat's overall strategic decisions, but really they have a large local file system team, and a lot of them are xfs developers. You aren't going to convince Dave Chinner he should go work on Btrfs instead of XFS. Unless there's somebody internally that actually wants to work on Btrfs the work simply isn't going to get done. All of the other Btrfs developers work for other companies, and none of them are interested in working for Red Hat.
ericfrederich 9y ago
I ran Fedora some years ago when btrfs support was added. I thought the idea to be able to roll back after a yum update messes things up was cool... in practice, it's a lot more complicated than hitting some "rollback" button in the system update gui.
snvzz 9y ago
On a non-totally unrelated note, Matt Dillon recently updated the HAMMER2 design document. https://www.dragonflybsd.org/hammer/ https://www.dragonflybsd.org/hammer/
- kzrdude 9y ago
  Any notable changes, or what do you take note of?
deleted 9y ago
[deleted]
mhd 9y ago
Is JFS still a thing in the Linux world? I remember using it for some partitions not because it was particularly high performant, but because it was supposed to have very few worst case scenarios…
sargun 9y ago
This is disheartening to hear. We recently (<3 months ago), introduced Btrfs into part of our fleet. This probably made us one of the larger Btrfs users. If Btrfs falls out of general favour, I'm afraid it may impede our ability to keep using it. Given our use-case, multi-tenant containers, there weren't many choices which had sane snapshotting support, as well as quotas and some level of subtrees. ZFS on Linux has its own share of issues. I won't say that Btrfs was without issues -- there is still a lot of performance work that needs to be done, especially in a multi-tenant workload, but it looked like there were solutions available. XFS is an excellent filesystem, and it may work well for our usecase in the near future. It's exciting to see new XFS features landing, like reflinks, and collapsing ranges. Hopefully, folks like Redhat continue trying to bring XFS to the future.
beagle3 9y ago
Btrfs brings IMO too little to the table, considering that ZoL is quite mature; It always seemed to me like it's the "we can't have ZFS so..." solution, but unlike Gnome (being the "can't have KDE" solution), it does not yet deliver, after a long long time. The next fs to make a difference, post ZFS, is likely HAMMER2[0] - it's supposedly already stable for single node use (the ZFS / XFS / ext4 use case), and is advancing towards the multinode-at-the-underlying-fs-level, a first. [0] https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/sys/vfs/hammer2/DESIGN https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEA...
deleted 9y ago
[deleted]

368 points by alrs 9y ago

I know this says redhat.com, but title is still a bit misleading. Btrfs has been deprecated on RHEL, but it is still under active development on its own.

em3rgent0rdr 9y ago
HN has a problem of users posting misleading titles.

josteink 9y ago

Deprecated? In favour of what? Will Redhat too (like Ubuntu) start shipping ZFS?

tbrock 9y ago
XFS is the default FS on RHEL now, so likely that.
- vacri 9y ago
  Do you know if XFS can shrink volumes yet? As far as I'm aware, that's the only limitation it has compared to other filesystems of that era.
  - pferde 9y ago
    Nope, still can't. Not online, not offline.
  - rwmj 9y ago
    It can't, but you're probably better off using trim/discard/virt-sparsify rather than shrinking filesystems. Even on filesystems like ext4 that support it, shrinking can cause strange fs performance problems.
mjevans 9y ago
I supposed their upgrade path is... * Make fresh backups * Verify the backups * Re-install and use the backups
- paulie_a 9y ago
  Basically. Those steps should be done regardless of FS. I heard this on a podcast recently but if you are not doing that you end up with "schrodinger backups"
paulie_a 9y ago
The following will sound snarky but I would personally prefer ext2 if the other choice is btrfs. "ButterFs because your data melts away"
riffraff 9y ago
I am curious as to the same. The document says > 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. but it's unclear what this means exactly.
- pinewurst 9y ago
  Like their Permabit acquisition: https://www.redhat.com/en/about/press-releases/red-hat-acquires-permabit-assets-eases-barriers-cloud-portability-data-deduplication-technology?sc_cid=7016000000127NJAAY https://www.redhat.com/en/about/press-releases/red-hat-acqui...
dman 9y ago
XFS - the workhorse that keeps on running.
pinewurst 9y ago
My best guess is XFS coupled with Permabit (which they just bought and will open source) compression and dedupe services. Probably layered on an enhanced mdraid too. I'm guessing that the ZFS licensing hairball is a bridge too far for even Red Hat, so they'll cobble together equivalent-ish functionality - even if it's not anywhere near as elegant as ZFS's integral data production and reduction.
silly-silly 9y ago
Red Hat will never ship ZFS, because its an entity that exists in the US and a probable target for lawsuits / license violation if ZFS is included.
- cookiecaper 9y ago
  What's the risk involved for Red Hat in shipping ZFS? OpenZFS and ZFS-on-Linux are under the CDDL, a legitimate open-source license that some feel may be GPL-incompatible. Red Hat distributes non-GPL programs as a matter of routine, and I'm sure this includes other CDDL programs, especially considering Red Hat's enthusiastic involvement in the Java ecosystem. The only potential risk is that the GPL is so virulently infectious that any driver is automatically GPL'd by virtue of its own existence as a compiled kernel module, but that possibility seems fairly remote, and it hasn't seemed to affect the distribution of other purportedly-non-GPL kernel modules. I'm not a lawyer so maybe I'm missing something.
  - cryptonector 9y ago
    The risk is FUDdy, but not entirely imaginary. In particular there's the thread of a threat of patent lawsuits from a variety of players in the industry. Of course, that's always the case in this industry, so I don't buy it. But RH might, and that's their call. My guess too is that if Canonical manages to go a few years without a lawsuit from kernel copyright holders then we might see more of what it is doing. But RH would -I guess!- still suffer from patent FUD and so stay away from ZFS. That's all fine by me. The better for RH's competition. More competition, mo' betta.

JoshTriplett 9y ago

Has anyone here tried bcachefs (http://bcachefs.org/ http://bcachefs.org/) for some of the same use cases as btrfs? What do people think of its current state?

lathiat 9y ago
You'd need to read up on it but the TL;DR i got from previous comments was that previously it was being funded by a company that wasn't 100% aware of the entire situation around it (they used it in their commercial product, management didn't fully understand it was being released as open source, though I also understand they didn't own the rights to the entire code base so basically that was necessary effectively). The person developing it left that company and is seeking his own funding for it but that generally the development was significantly stunted as a result. It seems a bit here-say-ish though, so please don't assume I'm entirely correct on all fronts there and I'd encourage you to research it further!
- riffraff 9y ago
  OT, but I think you meant "hearsay-ish"
- joecool1029 9y ago
  >I'd encourage you to research it further! On that note, their Patreon is a better primer than the website is: https://www.patreon.com/bcachefs https://www.patreon.com/bcachefs
  - lathiat 9y ago
    Happy to see his Patreon is looking "healthier". I mean $1500/m isn't really that much but I'm sure last I looked it was much lower. In other news.. consider supporting the people that support you! Personally, I spent over $100/month on Patreon. Most of those are creators rather than open source people but there are a couple of open source ones such as Ondřej Surý who works on PHP packaging in Debian/Ubuntu

lathiat 9y ago

This is specific to RHEL7, notably that they won't backport any further kernel updates and won't move it from Technology Preview to release. Red Hat wasn't really driving btrfs development at all from what I am aware of. ⁠Btrfs has been deprecated 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.

jmspring 9y ago

It's OT but how many people actually use RHEL? Or CentOS (more likely). I'm not a fan of systemd, but have really loathed CentOS/RHEL compared to Debian/* for years.

esaym 9y ago
>It's OT but how many people actually use RHEL? Hopefully a lot because, like it or not, RHEL puts a ton of work into the linux kernel and other userland linux tools. We need them to stick around.
- jmspring 9y ago
  As do others and they were one of the main systemd backers. Still doesn't answer the question. If I'd left out my preference, probably would have had fewer downvotes.
myrandomcomment 9y ago
As a general rule if the end customer was finance/bank their Linux flavor was RedHat (someone to yell at when it broke). Other tech companies / web types it was Ubuntu. This was my experience in over 4 startups where these were are end customers. Your mileage may vary.
- jsmthrowaway 9y ago
  CentOS is extremely popular among startups. It lets you directly use RPMs, which many software publishers distribute on their own (not the case for debs, often), and gives you an upgrade path to buy RHEL when you want someone to yell at and not throw away all your automation. I’m not trying to start a flame war here (honest), but among most “usual web” ops folks I know, the opposite of what you’re suggesting seems to hold and Debian/Ubuntu are looked at as an odd choice. It’s probably hire #1 going with what they know, more than anything, and it could very well be selection bias regarding the people I know. I’d love to see stats. I’ve been working with CentOS or OEL in my own roles for several years now, and I’ve never chosen it. (Not saying I wouldn’t, just that it’s been there when I get there.)

louwrentius 9y ago

Sounds to me that Btrfs is done for long-term. So now what?

cyphar 9y ago
Facebook, Fujitsu and SUSE all contribute to btrfs and it is still being actively developed (it's the default filesystem for SUSE Linux Enterprise). Red Hat stopped contributing a while ago since most of their btrfs developers moved to Facebook. "Done for the long-term" is a major overstatement IMO.
- tjoff 9y ago
  Well, for those of us that have been waiting on btrfs for a frigging decade I get the feeling that it is never going to be ready. If I wait another decade, will btrfs have matured? Will there be ANY half-modern filesystem for linux? I'm not convinced. Currently bcachefs seems more appealing but well, long way to go there as well.
  - osandov 9y ago
    What problems have you had with Btrfs recently?
    - tjoff 9y ago
      That, exact, question is the question you get, and has got for years and years, when questioning btrfs maturity. It seems as if btrfs always "just yesterday" got mature just when that last thing was fixed. Sorry, but I don't believe enough in btrfs to try it out for real (and don't have time to play with it just for fun). Especially when playing with more advanced features, the status page does not inspire confidence. The paragraph on btrfs in https://www.patreon.com/bcachefs https://www.patreon.com/bcachefs seems spot on and exactly the feeling you get after spending a decade of hope on btrfs. And that kind of review is exactly what you don't want on the brand new finally-we-can-store-data-properly-on-linux solution.

0xFFC 9y ago

Wow, I thought their long term plan was to switch to Btrfs. Now it is deprecated? What happened there?

lathiat 9y ago
I think you might be confusing with SuSE? Generally though sadly btrfs just isn't getting the man hours from any commercial sponsor it seems :(
- cyphar 9y ago
  Facebook, Fujitsu and SUSE are all actively contributing to btrfs. The idea it isn't getting "the man hours from any commercial sponsor" is ludicrous.
  - jeltz 9y ago
    And this is what makes me worried about the design of btrfs. If after all these man hours Redhat thinks it still is not stable enough I worry if it ever will be.
    - cyphar 9y ago
      Why are you shifting the goal posts? Also, Red Hat has not been a significant contributor to btrfs for a while (they've mostly been working on XFS and lvm/devicemapper) so them dropping it is hardly a surprise -- Red Hat is not the arbiter of what is a good technology, and there are many other parties that work on Linux.
      - jeltz 9y ago
        Are you confusing me with someone else? Because I have never claimed that Redhat has been a major contributor behind Btrfs nor have I claimed that Btrfs development is lacking in contributors. And to me this is just another voice which is septical of the current state of Btrfs. And while Redhat is not the only voice, it is an important voice.

justin66 9y ago

I am as happy as anyone that XFS is finally getting the position of honor it deserves on enterprise Linux (something like 15 years later than it should have, grumble grumble) but it doesn't really take the place of what btrfs was trying to do. Only ZFS is in a position to do that. I wonder if there are any plans for supporting the native port on RHEL.

mrweasel 9y ago
Redhat hasn't been on the best of terms with Oracle, so I suspect that they want to stay clear of ZFS. It does however leave Redhat without a more modern feature rich filesystem. Perhaps Redhat could help to develop snapshots on XFS. It's not the only feature XFS is missing, but it's a start.
- cyphar 9y ago
  > Perhaps Redhat could help to develop snapshots on XFS. It's not the only feature XFS is missing, but it's a start. Upstream has been working on adding more btrfs-like features to XFS, but I believe that RHEL encourages using devicemapper snapshots (which you then format with XFS).
  - 2ion 9y ago
    > Upstream has been working on adding more btrfs-like features to XFS, but I believe that RHEL encourages using devicemapper snapshots (which you then format with XFS). Exactly, mountable and mergable snapshots have been supported by a LVM/devicemapper stack for a long time.
    - rbanffy 9y ago
      It's still a bit more involved than the transparent snapshots ZFS and, to a lesser degree, BtrFS offer. I'm not happy with this and sincerely hope this position changes in the future.
- boomboomsubban 9y ago

sparky_ 9y ago

That's too bad. The subvolume [0] features were an interesting paradigm. Kind of let you have a virtual filesystem-within-a-filesystem. [0] https://en.wikipedia.org/wiki/Btrfs#Subvolumes_and_snapshots https://en.wikipedia.org/wiki/Btrfs#Subvolumes_and_snapshots

rleigh 9y ago
It's certainly interesting, but if you look at the ZFS design they were inspired by, they got a lot wrong. Some points to consider: With ZFS, you have a hierarchy of datasets. These inherit properties from their parents, and while the mountpoints can also mimic this hierarchy, the mountpoint property can be set independently. Btrfs couples the two concepts, forcing subvolumes to be in a specific place in the actual filesystem; zfs datasets in comparison are purely metadata and are for organisation and administration, not direct use in the filesystem hierarchy. ZFS snapshots are read-only, and clones of these snapshots are datasets in the hierarchy. Btrfs snapshots are read-write by default, which in some ways defeats the point of a point-in-time snapshot. You can also make changes to a ZFS clone and later promote it to replace the original dataset. Likewise rollbacks. Btrfs makes no provision for doing either; you have to delete the original and then rename the snapshot, which isn't atomic. ZFS' metadata preserves all relations between datasets, snapshots and clones. The ZFS way of doing things makes things safe and accessible for system administration. There's no way to confuse the origin of a snapshot because it's tied to a parent dataset. Likewise clones of snapshots, unless you deliberately choose to break the link. The Btrfs way looks superficially nicer, but in practice is much less flexible, and potentially more dangerous since you don't have the ability to audit what came from where and when. Btrfs snapshot performance is also abysmal. ZFS handles snapshots simply by recording the transaction ID, which makes them really lightweight (and it also provides "bookmarks" which are even lighter weight). ZFS keeps the referenced blocks in deadlists, and its performance is excellent (compare how fast snapshot deletion is between the two). ZFS also allows delegating permissions to perform snapshot, clone, rollback etc. to normal users; I'm unware of Btrfs allowing such delegation--some operations can be performed like snapshotting, but not deletion, while ZFS permits this all to be configured transparently.
- 9y ago

kodfodrasz 9y ago

I wonder if this is a response to Oracle's Java9/Jigsaw push, where RedHat was forced to give up its position.

bedros 9y ago

I think this is a political move disguised as technical move oracle pays the developers of btrfs [0] redhat hates the guts of oracle, since oracle released oracle linux, which is a clone of redhat enterprise (based on centos) so, redhat wants to cripple btrfs and hurt oracle. However, btrfs is my favorite FS, been using it on my home computer and backup drives for at least 6 years, before it was included in the kernel, love the subvolumes, snapshots, and compression; never had issues with it . [0] https://oss.oracle.com/~mason/ https://oss.oracle.com/~mason/ [Update] Chris mason no longer at Oracle since 2012

cleech 9y ago
Chris Mason left Oracle for Fusion-io back in 2012 and then from there to Facebook in 2013
skrause 9y ago
Chris Mason, the principal Btrfs author, left Oracle over 5 years ago: https://en.wikipedia.org/wiki/Btrfs#History https://en.wikipedia.org/wiki/Btrfs#History "In June 2012, Chris Mason left Oracle for Fusion-io, which he left a year later with Josef Bacik to join Facebook; while at both companies, Mason continued his work on Btrfs."
sargun 9y ago
Oracle still has a couple developers on their payroll that do BtrFS development: * Liu Bo * Anand Jain
newscracker 9y ago
> However, btrfs is my favorite FS, been using it on my home computer and backup drives for at least 6 years, before it was included in the kernel, love the subvolumes, snapshots, and compression; never had issues with it . Slightly off topic. I chose btrfs as my main filesystem recently on a system running Ubuntu/Xubuntu. I have done some research on backing up (with the advantage of snapshots) but it looks like there aren't (m)any graphical tools (this gets a little more confusing with /@ and /@home subvolumes on the same partition being treated separately for snapshots, AFAIK). Do you manage it all from the command line and/or do you have any suggestions for graphical tools to do "as-is clones of entire partitions" (and also incremental backups) to local external drives (not over the network)? Or if you could point to any great documentation or blog posts on this topic, that'd be helpful too (I have read some bits of the btrfs wiki and the btrfs parts in the Arch wiki). Currently I'm doing a plain rsync using Grsync, and not really taking advantage of btrfs features like snapshots. The main reason I'm looking at avoiding the command line is to make it easier for others around me to use it.

pmontra 9y ago

Offtopic, but if anybody from RedHat and especially Mozilla read this, go to that page with an Android phone, possibly with a small screen: To RedHat: do something for that menu at the left. It stays in the way when scrolling and zooming. The X to close it is not immediately visible on a small screen. Expected behavior: the menu scrolls away with the page and doesn't stay fixed in the way of the reader. To Mozilla: open the page with Opera and copy what you see there. Tldr: autofit the text in the screen width. Maybe Chrome does the same. Btw, reader mode doesn't kick in.

tyfon 9y ago
Worse, I browse without javascript and their page has no text. It's utterly terribly designed to be an open source information page.
- creshal 9y ago
  Even as paying customer I wouldn't want to put up with that shit.
  - lunchables 9y ago
    You mean ESPECIALLY as a paying customer! You paid for the right to bitch, and you should.
- jwilk 9y ago
  The text is there, just invisible. Disable CSS and it'll show up.
icebraining 9y ago
Re: Mozilla, they are aware, and there are a couple of about:config flags to enable text reflow on page load and on tap-to-zoom, but they're disabled by default "due to a number of reasons (mainly performance)".
- pmontra 9y ago

headlands 9y ago

The default file system for the root partition of SUSE Enterprise Linux is Btrfs. So RHEL have stopped supporting it. It is the only filesystem that implements many of the features found in ZFS.

fundabulousrIII 9y ago
It's also buggy as hell and though I've used SuSE for 17 years I almost stopped this year due to btrfs. Terrible decision from SuSE: but they aren't the company they used to be.

vbezhenar 9y ago

I don't think this matters much. If you want btrfs, you'll likely be able to get kernel module from EPEL even if they'll stop shipping it. It's like deprecated and unsupported LXC which could be used just fine and which doesn't have usable replacements.

tylerjd 9y ago
> deprecated and unsupported LXC Where did you hear this? This is news to me. https://linuxcontainers.org/ https://linuxcontainers.org/ and https://github.com/lxc/lxc https://github.com/lxc/lxc both seem active and supported by Canonical to me. The only deprecated project by them is listed to be CGManager.
- vbezhenar 9y ago
  LXC is unsupported by RHEL. They chosen Docker as a primary container solution. LXC as project is fine, of course.

kureikain 9y ago

I have used Btrfs in production and I would say it's great. It's super easy to just add an extra EBS volume and attach to a Btrfs volume and now you have more disk space. Performance is good enough for me as well, I used it as storage for InfluxDB and Docker. Luckily this is only Redhat, not Btrfs itself.

beedogs 9y ago
Unfortunately, RedHat tends to be the trendsetter in the Linux world. Once it's gone from RHEL, it'll be gone from most other RPM based distros soon enough. It's kind of a shame that one company has grown to dominate the Linux software ecosystem, often to the detriment of all involved.
- gcp 9y ago
  Red Hat has a lot of core Linux contributors on their payroll. Their status is, AFAIK, not undeserved.
- smarnach 9y ago
  RPM-based distros make up maybe 10 % of the Linux installations these days, so we should not overstate RedHat's influence.
  - rantanplan 9y ago
    RHEL makes up maybe 99.9% of the Linux enterprise installations these days, so we can't overstate RedHat's influence.
    - cyphar 9y ago
      I don't think that number is even close to accurate. SLE almost certainly makes up more than 15% of the market alone. And that's ignoring all of the other enterprise distributions. I believe that 2015 estimates from the IDC[1] had RHEL at ~60%, SLE at ~20%, Oracle Linux at ~12% and "Other" at ~8%. But I can't access the document at the moment. [1]: http://www.idc.com/getdoc.jsp?containerId=US41360517 http://www.idc.com/getdoc.jsp?containerId=US41360517

X-Istence 9y ago

More importantly Red Hat has deprecated FCoE in RHEL, which is big news, because at a previous $JOB they went all in on FCoE because it was supposed to be the future.

B1FF_PSUVM 9y ago
https://en.wikipedia.org/wiki/Fibre_Channel_over_Ethernet https://en.wikipedia.org/wiki/Fibre_Channel_over_Ethernet
KaiserPro 9y ago
FCoE died a death <2013. Expensive hardware, with little gain sadly. It was a nice idea, however at its very core is a fairly large problem: converged network adaptors are problematic. Unless you have lots of bandwidth in said adaptor (ie 56gig inifiband) you are going to get contention between network and disk IO.
- X-Istence 9y ago
  I agree, not only that, but at least with Cisco gear FCoE was a real pain in the behind to manage and configure. So much duplication in configuration and settings across a lot of gear, and it never was as smooth as they made it out to be.
jabl 9y ago
Ouch? What's the replacement then? ISCSI, or going back to FC? Or is everything cloud something these days? :)
- lunchables 9y ago
  Yeah iSCSI and NFS. Also affecting this is the huge growth in "Hyperconverged Infrastructure" (HCI).
  - X-Istence 9y ago
    Hyperconverged Infrastructure is definitely eating a lot of the traditional storage vendors lunches. Using Ubuntu with JuJu/Ceph/OpenStack all on the same servers provides plenty of power while reducing costs. Even VMWare has come on board with vSAN which pushes out vendors like EMC/NetApp because you no longer need them when you can just create it against your existing hypervisors. Sure you can run one or two less VM's on it, but you have less cost overall.

cmurf 9y ago

Unsurprising. Red Hat has not hired upstream Btrfs developers for years, where SUSE has hired bunches. Meanwhile Red Hat has upstream ext4, XFS and LVM developers. If you're going to support a code base for ~10 years, you're going to need upstream people to support it. And realistically Red Hat's comfortable putting their eggs all in the device-mapper, LVM, and XFS basket. But, there's more: https://github.com/stratis-storage/stratisd https://github.com/stratis-storage/stratisd Btrfs has no licensing issues, but after many years of work it still has significant technical issues that may never be resolved. page 4 Stratis version 3.0 Rough ZFS feature parity. New DM features needed. Page 22 https://stratis-storage.github.io/StratisSoftwareDesign.pdf https://stratis-storage.github.io/StratisSoftwareDesign.pdf Both of those are unqualified statements, so fair or unfair my inclination is to take the project with a grain of salt.

gcp 9y ago
As for the significant technical issues, one thing is the core decision to make it a CoW system, which has fundamental performance issues with many workloads that are exactly those used in the server space. You can disable CoW, but you lose many reasons to use btrfs in the first place if you do. When I gave up on it there were also fundamental issues with metadata vs data balancing, not-really-working RAID support, and so on...
- pgaddict 9y ago
  I find the suggestion that the technical issues are caused by the CoW design a bit strange. Sure, making the filesystem CoW-based means there are some inherent costs, but it allows the filesystem to implement some interesting features (e.g. snapshots) in a more efficient way. For example if you want to do snapshots with ext4/xfs, you'll probably do that using LVM (which you can see as turning the stack into a CoW). In my experience the performance impact of creating a snapshot on ext4/LVM is about 50%, so you cut the performance in half. While on ZFS the impact is mostly negligible, due to the filesystem is designed as CoW in the first place. And thanks to ZFS we know that it's possible to implement a CoW filesystem that provides extremely stable and balanced performance. I've done a number of database-related tests (which is the workload that I do care about) and it did ~70-80% TPS compared to ext4/xfs (without snapshots). And once you create a snapshot on ext4/xfs, the performance tanks, while ZFS works just like before, thanks to the CoW design. Unfortunately, BTRFS so far hasn't reached this level of maturity and stable performance (at least not in the workloads that I personally care about). But that has nothing to do with the filesystem being CoW, except perhaps that CoW maybe makes the design more complicated.

buserror 9y ago

Well I used btrfs as a root filesystem for quite a while, until I realized it was pig slow for sync() -- I mean, it would take AGES to do and apt-get upgrade for example. I ended up having to do some tasks using 'eatmydata' [0] to make it all better, risking filesystem corruption in trade for speed. Also, at the time, there was no functioning fsck. So I moved back safely to ext4 and never looked back! [0]: https://www.flamingspork.com/projects/libeatmydata/ https://www.flamingspork.com/projects/libeatmydata/

buster 9y ago
Over the recent years on every new laptop install i switched between filesystems, so i had ext3/4, btrfs and (currently) xfs on my system. I have to say, btrfs had the most glitches (a few years back), although it worked ok'ish (no data loss). Nowadays, i must say that i very much prefer a stable filesystem with as little complicated logic as possible. I actually never use snapshots or subtrees! I never put another disk in my laptop (where would that go?!) so i don't need to do dynamic resizing (while online of course!). All this makes the filesystems a lot more complex then it has to be. I've also run into problems using ZFS on Solaris some years back which took ~2 weeks in dtracing what the hell is going on. Of course it was related to CoW. My lessons learned: Check your requirements. Will you really need and use subtrees/snapshots/XYZ on your system? Will you really need to do online-resizing? If not, just use a stable, simple filesystem. There are perfect usecases for ZFS or btrfs. But not everyone needs the advanced features.
- viraptor 9y ago
  > Will you really need and use subtrees/snapshots/XYZ on your system? It's a valid question, but not the best one. Almost nobody needs snapshots. But they make things easier. You most likely don't need a journaled fs in your laptop either (battery level notification should take care of the issues). But it does make life better. "Need" is not the threshold I'm interested in. Most features, I'd like. One feature I think I do need most is scrubbing, which is still absent from most filesystems :(
  - 9y ago

shmerl 9y ago

That's weird. What do they have against btrfs?

nul_byte 9y ago
They don't see it as stable enough to move beyond tech preview.
- rurban 9y ago
  It is also extremely slow. And the known RAID problems didn't get better.

seesomesense 9y ago

Not surprised. I have been using BTRFS for years. Unfortunately, one gets the feeling that not too much development has been going into it.

horusthecat 9y ago
Having been using BTRFS at home for years, i get the exact opposite impression... I've had bugs (kernel panics) that just disappear on the next update. I'm happy with the RAID1 ease of use. But even there, like some have said, manual scrub/balance--which is still nice to have--indicates a design flaw. If I was in ops I would not use btrfs on anything but lab experiments... if i can get hardware RAID, then I can blame the vendor and the equipment

alexdowad 9y ago

I tried btrfs and got bitten by bugs; not doing that again. Judging from this move by RH, it looks like I wasn't the only one.

lucb1e 9y ago
What bugs? I recently setup a software mirroring raid with btrfs and I'm loving features like checksumming. It makes me feel my data is quite safe and can't bit rot anymore. So far it is working fine.
- rodgerd 9y ago
  Hi. Did you notice that the official description of RAID-1 is "Mostly working"? Are you aware if one of your drive fails, you have one chance to re-mirror it, before the remaining drive can no longer be mounted read-write and you need to dump the filesystem and re-create from scratch?
  - andrewstuart2 9y ago
    RAID1 meaning you get one chance. Just move to RAID10 if you're worried. (/s)
    - Elhana 9y ago
      It has exactly the same bug with RAID10.
  - viraptor 9y ago
    That's just how raid mirroring works. Now sure why you mention it specifically for btrfs?
    - rodgerd 9y ago
      No, it isn't. You can run a ZFS VDEV or a Linux mdraid as a single-disk RAID 1 unit until the remaining disk fails. You have an arbitary number of reboots/remounts to fix the problem.

erikb 9y ago

Why is there no explanation for this? It seems weird to deprecate something that most people haven't even started using yet.

snakeanus 9y ago

Still waiting for bcachefs. It's like btrfs except it does not suck. It also has proper encryption.

betaby 9y ago
How many developers involved in bcachefs full time? What I've heard it's a one man show.

pmlnr 9y ago

Great... So can I please have something that can do transparent compression? That is my sole reason for using btrfs. (My personal stack is on ZFS with Debian and I'm never going to look back from that, even if I sometimes have speed issues due to SATA instead of SAS system underneath it; ZFS compression and snapshots are incredibly powerful.)

Mobizone_Ng 9y ago

Twitter Introduces Turn Off Notification From The Strangers. — [SEE HOW...http://mobizone.ng/twitter-introduces-turn-off-notification-strangers/ http://mobizone.ng/twitter-introduces-turn-off-notification-...

parasubvert 9y ago

Concourse (which is a CI/CD system that orchestrates Docker containers) recently switched from btrfs to overlay to fix performance and stability issues. For those with morbid curiosity on the many stability issues with btrfs as a container file system, this is chronicled in Github: https://github.com/concourse/concourse/issues/1045 https://github.com/concourse/concourse/issues/1045

stargrazer 9y ago

Considering the size of disks now-a-days, the chance of bit rot is high. And (I don't have the original source) on SSD, bit rots probability is higher still. So... ZFS and BTRF have meta-data as well as data checksumming. From what I've read, XFS may have metadata checksumming, but not on the data side of things. I consider checksumming important. Do others? What is the solution? What other file systems offer that sort of capability? Snapshotting is a second go-to function. Particularly when it is integrated into the LXC container creation process. (There was a comment elsewhere here which said LXC is on it's way out.... huh? what?)

legulere 9y ago
> on SSD, bit rots probability is higher still Do you have a source for this? So far I believed that bit-rot rates are pretty similar.
- stargrazer 9y ago
  A google search turns up a number of sources. Another concept which could use justification is whether SSDs bit rot more over long term than do spinning disks. I heard that somewhere as well.
  - legulere 9y ago
    Using google was the first thing I did. I couldn't find something substantial.
ars 9y ago
Use mirror raid and have mdadm do a full disk compare/check every month (this is the default on Debian). Additionally use smartmontools and configure it to do a short self test each night, and a long self test (i.e. full disk read) each week. This will catch/flag errors early, which mdadm will then detect.
- Wicher 9y ago
  Disk A and disk B both contain file SomeFile. On disk B this file has rotted. When reading the file SomeFile into memory, the read will be distributed among the disks (for performance reasons) (and it will probby need to span a multiple of the stripe size). Ok, file is read into memory, including the bitrotted part from disk B. Now we write the file blocks back - as one does. Voila! Both disks now contain the bitrot. And mdadm will not complain - disk A and B are identical for the area of file SomeFile.

RX14 9y ago

I've done many bad things to BTRFS, used it on multiple drives of differing sises, used it on drives connected over the cheapest USB to SATA adapters I could find, used it on disks with consistent corruption for over a year, and it's handled it gracefully. I've also been using btrfs as the backend to docker for a long time on my desktop PC and never noticed any problems. BTRFS has been rock solid for me. I don't doubt it is more unstable than other filesystems, however it seems i haven't been unlucky enough to experience any issues. When using BTRFS, i've always stuck to the latest kernel releases, and run a scrub + balance every month. This is the advice I heard from people who used btrfs, and I wonder how many of the people who complain about data corruption do these steps. Perhaps their corruption bugs are solved in a newer kernel version. I've had multiple scrubs pick up data corruption, which other filesystems wouldn't have found. The only time btrfs corrupted my data was when I used the ext4 to btrfs conversion tool, it created an unmountable FS and then I just migrated my data manually.

rleigh 9y ago
You shouldn't have to do these steps. Manual balancing is a workaround for a critical flaw in the implementation. In my last major use of Btrfs, whole archive rebuilds of Debian, it would take less than 48 hours to completely unbalance a brand new Btrfs filesystem. ~25k snapshots continuously created and deleted over the period in 20 parallel jobs absolutely toasted the filesystem, even though it was 1% utilised for the most part, 10% at peak usage. The point I want to make is that a Btrfs filesystem can become unbalanced at some indeterminate point in the future, which makes it impossible to rely on if you want to guarantee continued service. I've also suffered from a number of dataloss incidents which likely are fixed now, but despite lots of bugfixing, there are still major flaws to address.
cookiecaper 9y ago
btrfs requires far too much maintenance to be a good general-purpose FS, and it absolutely crumbles under certain not-too-uncommon use cases (specifically, databases and VMs). I really wanted to like btrfs and used it extensively over the last couple of years, but I've finally given up and moved on to ZFS, and I'm grateful that I did. Give it a try.

jorrizza 9y ago

Strange decision, as systemd-nspawn[1] specifically mentions and supports btrfs as a CoW filesystem for its containers. And as far as I understand, systemd is primarily developed by Red Hat employees. So either they'll add support for CoW alternatives, or they'll remove btrfs support from systemd-nspawn all together. [1]: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html https://www.freedesktop.org/software/systemd/man/systemd-nsp...

amorphid 9y ago
There's nothing which prevents you from creating an empty block device file, putting btrfs on that, and mounting it.
Torgo 9y ago
nspawn uses btrfs snapshotting natively for its templating and no other FS (ZFS was explicitly rejected by Mr. Poettering because "it's not in the kernel") so yeah either they are going to have to do something about this or there will be a significant step down in functionality for nspawn. I can't see how this isn't really bad news for nspawn. I guess one option is to pull btrfs tree into Systemd :-)

josefbacik 9y ago

People are making a bigger deal of this than it is. Since I left Red Hat in 2012 there hasn't been another engineer to pick up the work, and it is _a lot_ of work. For RHEL you are stuck on one kernel for an entire release. Every fix has to be backported from upstream, and the further from upstream you get the harder it is to do that work. Btrfs has to be rebased _every_ release. If moves too fast and there is so much work being done that you can't just cherry pick individual fixes. This makes it a huge pain in the ass. Then you have RHEL's "if we ship it we support it" mantra. Every release you have something that is more Frankenstein-y than it was before, and you run more of a risk of shit going horribly wrong. That's a huge liability for an engineering team that has 0 upstream btrfs contributors. The entire local file system group are xfs developers. Nobody has done serious btrfs work at Red Hat since I left (with a slight exception with Zach Brown for a little while.) Suse uses it as their default and has a lot of inhouse expertise. We use it in a variety of ways inside Facebook. It's getting faster and more stable, admittedly slower than I'd like, but we are getting there. This announcement from Red Hat is purely a reflection of Red Hat's engineering expertise and the way they ship kernels, and not an indictment of Btrfs itself.

appleflaxen 9y ago
thanks for this context; i read this thread previously and had no idea of the "why" behind the news item. great comment to understand better.
nailer 9y ago
Thanks. Any indication why RH didn't hire btrfs devs? It looks like a decision was made that it wasn't strategic (obviously xfs on Linux has a much longer history).
- josefbacik 9y ago
  They brought on Zach right before I left specifically to help with the effort, but he left as well. I can't really speak to Red Hat's overall strategic decisions, but really they have a large local file system team, and a lot of them are xfs developers. You aren't going to convince Dave Chinner he should go work on Btrfs instead of XFS. Unless there's somebody internally that actually wants to work on Btrfs the work simply isn't going to get done. All of the other Btrfs developers work for other companies, and none of them are interested in working for Red Hat.

ericfrederich 9y ago

I ran Fedora some years ago when btrfs support was added. I thought the idea to be able to roll back after a yum update messes things up was cool... in practice, it's a lot more complicated than hitting some "rollback" button in the system update gui.

snvzz 9y ago

On a non-totally unrelated note, Matt Dillon recently updated the HAMMER2 design document. https://www.dragonflybsd.org/hammer/ https://www.dragonflybsd.org/hammer/

kzrdude 9y ago
Any notable changes, or what do you take note of?

deleted 9y ago

[deleted]

mhd 9y ago

Is JFS still a thing in the Linux world? I remember using it for some partitions not because it was particularly high performant, but because it was supposed to have very few worst case scenarios…

sargun 9y ago

This is disheartening to hear. We recently (<3 months ago), introduced Btrfs into part of our fleet. This probably made us one of the larger Btrfs users. If Btrfs falls out of general favour, I'm afraid it may impede our ability to keep using it. Given our use-case, multi-tenant containers, there weren't many choices which had sane snapshotting support, as well as quotas and some level of subtrees. ZFS on Linux has its own share of issues. I won't say that Btrfs was without issues -- there is still a lot of performance work that needs to be done, especially in a multi-tenant workload, but it looked like there were solutions available. XFS is an excellent filesystem, and it may work well for our usecase in the near future. It's exciting to see new XFS features landing, like reflinks, and collapsing ranges. Hopefully, folks like Redhat continue trying to bring XFS to the future.

beagle3 9y ago

Btrfs brings IMO too little to the table, considering that ZoL is quite mature; It always seemed to me like it's the "we can't have ZFS so..." solution, but unlike Gnome (being the "can't have KDE" solution), it does not yet deliver, after a long long time. The next fs to make a difference, post ZFS, is likely HAMMER2[0] - it's supposedly already stable for single node use (the ZFS / XFS / ext4 use case), and is advancing towards the multinode-at-the-underlying-fs-level, a first. [0] https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/sys/vfs/hammer2/DESIGN https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEA...

deleted 9y ago

[deleted]