13 ms·

A straight talk about btrfs

204 points by cyphar 9y ago

btilly 9y ago
For those who wonder who deprecated it, Red Hat did in the release notes for 7.4. Search for brtfs in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... for details.
- lemoncucumber 9y ago
  As has been discussed in other threads, RHEL's kernels are ancient compared to mainline and so they probably decided it's just too much work to continually backport btrfs changes onto increasingly dated kernels. The sky is not (necessarily) falling.
  - jameskegel 9y ago
    What put t in perspective for me was that here's a company who was a product and they make their money giving those products the utmost attention to things like compatibility and stability, and that means helping when these things break. This is not them making a political move or a line in the sand, this is them saying they can not afford to put the same 110% into this project so they're not going to carry it forward. It's the circle of life and I appreciate them for the rest of their works even if it can be mildly inconvenient in some cases.
  - danieldk 9y ago
    But if they thought that btrfs was the future, they would definitely have put in the manpower to maintain and backport btrfs. Red Hat probably believes that XFS + LVM et al. can provide the necessary functionality for enterprise setups on a more reliable basis.
    - catdog 9y ago
      They were never heavily invested in btrfs and they simply already employ a lot of XFS developers. I also don't think it's that easy to put more manpower into it. People with expertise in such such a rather complex niche field don't grow on trees.
      - 72deluxe 9y ago
        But do they grow on btrees? Filesystem joke, hilarious I know
  - greglindahl 9y ago
    Uh, the entire value proposition of RHEL is that Red Hat will backport such patches, supporting customers who don't want to change anything until they move up to the next major release.
    - djsumdog 9y ago
      That just feels tragic and silly. Probably many of the same types of shops that won't build the automated dev/ops infrastructures and end-to-end integration tests that let people move up stacks and updates rapidly. I haven't worked at a place that used RHEL in a long time. Unless you use one of their enterprise products like their directory or identity management system, there's no real reason to not use CentOS .. or really anything else for that matter.
      - kijin 9y ago
        Well... a very large portion of the value proposition of CentOS is that Red Hat will backport patches, and that CentOS users will get those patches for free, in case they don't want to change anything until they move up to the next major release.
      - jlgaddis 9y ago
        Not every company is a development shop. Some of us don't need -- or want -- the latest and greatest. I want servers that (other than installing updates) just work and don't have to be constantly maintained.
  - djsumdog 9y ago
    Looks like they're running 3.10 on RHEL7.4, which is a pretty old long term release. I mean there are long term 4.x branches now.
    - vbezhenar 9y ago
      It's not 3.10 from kernel.org. There are many backported patches adding support for selected new features, new hardware, etc. It doesn't make much sense to just compare numbers.
      - wtallis 9y ago
        Comparing the version numbers gives a good impression of how much of a maintenance burden RedHat is taking upon themselves. You can't simply presume that RedHat's 3.10 fork is missing any particular feature or fix from future upstream versions, but it's quite obvious that RedHat's fork has to be missing something by now, and probably a lot of somethings.
        xfs 9y ago
        Enterprise customers care much more about stability than features. Backporting features is always easy, if you consider the amount of work needed to have enterprise level guarantee on their quality. Weeding out bugs in features is much, much harder.
        jlgaddis 9y ago
        I've got machines that have been running 7 since very shortly after GA and I can't say that I'm missing out on anything that I need.
j_koreth 9y ago
Is there any reason why Oracle contributes so much to Btrfs while maintaining ZFS? Or am I mistaken in Oracle's relationships with ZFS
- riffraff 9y ago
  oracle has its own linux which it is interested in moving forward, but its version of ZFS is restricted to Solaris.
- Elv13 9y ago
  Oracle sells Oracle Linux, a RedHat clone. ZFS on Linux (ZoL) isn't controlled by Oracle, it is a fork of OpenSolaris version of ZFS. The ZFS sold by Oracle on Solaris isn't the same product and doesn't support Linux. Oracle doesn't want to support it on Linux because it would fragment one of the remaining cash cow they got from Sun. And anyway, they probably can't support ZoL even if they wanted to without putting themselves into self induced legal gray water. Apparently, they intend to move Solaris into a rolling model like Windows 10, but focused on legacy. They can sell ZFS there without affecting their Linux operations. There is also a rumor of a deal with NetApp not to support ZFS on Linux. All combined, BTRFS is a better suited tech for them to support.
  - rehemiau 9y ago
    I was wondering, how does Illumos fit into all this? Is their ZFS the Oracle-controlled one?
    - cyphar 9y ago
      illumos is the repo of record for OpenZFS[1], which is the community fork of OpenSolaris' ZFS (which is now proprietary). Most of the really cool new features are in OpenZFS because it has far more developer involvement (from FreeBSD, illumos, etc). [1]: http://open-zfs.org/wiki/Main_Page http://open-zfs.org/wiki/Main_Page
    - boomboomsubban 9y ago
      No, they split when Oracle bought Sun. The only part of OpenZFS, which everything but Solaris uses, that involves Oracle is a number of patents that the CDDL grants permission to use.
giis 9y ago
Recent Redhat decision may also be related to their investment in Storage products Ceph (~175 million in 2014) and GlusterFS (~125million in 2011) not just about stability of btrfs. As someone who previously experienced with distributed storage like emc-Isilon and also fuse-based glusterfs, btrfs has huge potential for enterprise storage. It does also need more effort on testing front at this moment. hoping that soon btrfs will become default fs for most Linux distros.
- ghaff 9y ago
  What do distributed software-defined storage/distributed filesystem projects have to do with a CoW filesystem? Alternatives to btrfs are things like XFS and ext4.
- jle17 9y ago
  I read somewhere (probably on HN) that it could be related to their acquisition of Permabit, a company which seems to be producing Linux software for deduplication, compression and thin-provisionning. This seems more in-line with what btrfs has to offer.
danieldk 9y ago
If Brazil, one of the world biggest producers of beef, would announce to stop producing fish: would you wonder, whether Peru, one of the world biggest producers of fish, would stop producing fish? I find this quite weak argumentation coming from SUSE. Novell/SUSE was also (by far) the largest contributor to AppArmor at some point. And SUSE used it as the MAC framework in their consumer and enterprise distributions. Then seemingly out of nothing they fired the AppArmor team.
- jabl 9y ago
  Oh? What are they using now then? SELinux?
  - sp332 9y ago
    AppArmor is configured to run by default on any fresh installation of SUSE Linux Enterprise Server. https://www.suse.com/documentation/sles11/book_security/data/sec_aaintro_enable.html https://www.suse.com/documentation/sles11/book_security/data... All the drama was back in 2007. https://web.archive.org/web/20160410165126/http://www.cnet.com/news/novell-lays-off-apparmor-programmers/ https://web.archive.org/web/20160410165126/http://www.cnet.c... Looks like it blew over by 2008 https://news.opensuse.org/2008/08/20/opensuse-to-add-selinux-basic-enablement-in-111/ https://news.opensuse.org/2008/08/20/opensuse-to-add-selinux...
  - cyphar 9y ago
    Both openSUSE and SLE use AppArmor by default. I believe we provide some support for SELinux if you want to use it, but AppArmor is the default LSM.
- appleflaxen 9y ago
  that's an important fact about the sustainability of any corporate contributor, but it's not relevant to the thesis of the article (which is that any corporate contributor makes decisions independently than others).
rodgerd 9y ago
That's gotta be the weasel-wordiest straight talk I've seen in a wee while. Here's a fact: the upstream's official statement is that RAID 1 isn't production-ready.
- cyphar 9y ago
  That's not accurate. Upstream btrfs doesn't support RAID56[1]. However, neither their multiple devices page[2] nor their gotchas page[3] mention that raid0, raid1 or raid10 are not recommended for production. Do you have a citation for your claim? [1]: https://btrfs.wiki.kernel.org/index.php/RAID56 https://btrfs.wiki.kernel.org/index.php/RAID56 [2]: https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Mul... [3]: https://btrfs.wiki.kernel.org/index.php/Gotchas https://btrfs.wiki.kernel.org/index.php/Gotchas
  - rodgerd 9y ago
    https://btrfs.wiki.kernel.org/index.php/Status https://btrfs.wiki.kernel.org/index.php/Status "RAID1 mostly OK Can get stuck in irreversible read-only mode if only one device is present." Which is an especially toxic combination with things like: "Device replace mostly OK" It's 30 seconds to find the status page if you're actually trying.
    - colde 9y ago
      In that same page however, they also define "mostly OK" as: > mostly OK: safe for general use, there are some known problems This would seem to suggest they are saying it is okay for production use. Otherwise, what do they mean by "safe for general use"
      - danparsonson 9y ago
        Call me conservative but "Can get stuck in irreversible read-only mode if only one device is present" doesn't equate to "okay for production use" when I'm considering deploying a filesystem; likewise "device replace" being "mostly OK".
jacknews 9y ago
A data-point of one, and I only have a few TB spread over a handful of disks, but I lost an entire 1TB btrfs volume recently because of a single disk sector gone bad (of course, I have backups, but it's a pain to restore 1TB, not to mention racking of the nerves (will the backup drive fail with sudden heavy use?) It's the only FS I've ever been unable to recover data from, at all, (I've had quite a few disks with errors before going back 25 years), and so it's no longer on my list of filesystems-I-trust.
- andrewstuart2 9y ago
  I've experienced data loss twice in 15 years of using Linux and trying different file systems. Both were on btrfs. I didn't use any advanced features, though I had plans to before this happened. But at that point, I cut my losses and converted all my disks back to ext4. The features are great, but data availability/integrity is the fundamental thing I want from a filesystem. If I write some bytes, they should be there tomorrow. Everything else is secondary.
  - cyphar 9y ago
    If you're interested in a more featureful filesystem that isn't btrfs and has a very solid track record, I would recommend looking at XFS. It's a very old filesystem but has a lot of quite modern features (and it performs better than ext4 for several workloads).
    - kogepathic 9y ago
      > I would recommend looking at XFS. It's a very old filesystem but has a lot of quite modern features (and it performs better than ext4 for several workloads). I would second this. XFS is great. A few years ago I moved from JFS to XFS for bulk data storage because JFS is pretty abandoned these days. No issues at all with XFS, and never lost any data. Just make sure it's right for you before you use it (e.g. you cannot shrink XFS volumes as you can ext4)
    - arjie 9y ago
      Funnily enough, XFS is the only file system on Linux where I've lost data. Back in the day, the wisdom was to stay away from it if you were in an iffy power situation because it would serve zeroes if there was a write to a file near a power loss (I.e. you wouldn't get old file or new file but something else) Having had that happen to me I always used some extN and didn't lose any existing files. Of course that's a decade or more ago and I may be misremembering but a cursory Google looks like other people encountered something like it too.
willtim 9y ago
I'm really confused by the choice of development process for BTRFS. First they write huge amounts of experimental/buggy code and then spend years trying to fix it. Reliability was obviously not the primary goal and I doubt they will be able to retrofit it.
kingwill101 9y ago
2 days ago I shutdown my laptop and all was working out great at that point. Now yesterday I turned back on to get some work done and couldn't pass maintenance mode because my home partition got corrupted somehow. Took me all day literally to get it working. I have since changed that partition back to ext4 leaving only / as btrfs
unixhero 9y ago
I use BTRFS for non critical data, like scratch data and second backup archives. This is because I can stretch it out over many old harddrives I have laying around. The memory footprint is also very low. And it comes with compression! But for everything else, I have rammed up, manned up, and use ZFS.
memracom 9y ago
This is a bad move. More than ever we need Linux standards and this goes in the opposite direction. It would be OK for SUSE to support btrfs as a first class choice of filesystem but the extfs family should be the standard one. And ZFS works just fine on Linux. If people want to use it, then the distros should not put roadblocks in their way and that means, ZFS should also be supported as a first class choice for servers. Note that "support" is different from licensing and from "included in our install repo". It is OK to have different licensing for things like this and to install it from a non-distro repo. Look at PostgreSQL for an example of how you can install a mission critical tool from a distro-compatible repo that is run by the upstream project, in this case, PostgreSQL. But even though it comes from a different repo, it should be "supported" by the distro to the extent that they make a best effort to help people resolve problems. It doesn't mean that you need to be experts in every nuance of the tool and the best way to do that is to maintain a good working relationship with these upstream projects. Something like ZFS or PostgreSQL are mission critical tools that use Linux as the interface to the hardware, My comments do not apply to any random app or utility that someone wrote for Linux. Perhaps btrfs belongs in this class but I personally don't know since I have not used it.
- deleted 9y ago
  [deleted]
- gens 9y ago
  Linux has lately gotten a lot of bad standards.
  - iso-8859-1 9y ago
    Such as?
    - gens 9y ago
      Most of the things by freedesktop.org in the last.. idk 5-10 years. Console-kit/logind, AppData, dbus being used for the lower parts of user-space, and probably many more that i don't recall now. Oh, and pulseaudio. EDIT: How could i forget polkit.
gbrown_ 9y ago
TL;DR - Don't be dissuaded by marketing, here's some more marketing.
Elrac 9y ago
When a CEO/CTO uses the words "straight talk" I prepare for a copious load of meaningless waffling. Was not disappointed!
- appleflaxen 9y ago
  huh. i found it to be coherent and not-particularly-heavy on techno-doublespeak. while it wasn't particularly edgy/straight, it certainly wasn't "meaningless waffling". i got the impression the title came from wanting to use the german idiomatic expression for "straight talk" in order to work in the butter-cow pun.
hyperfekt 9y ago
I've taken a long look at COW filesystems in these past days as part of me wanting to set up a new workstation, and it appears that while btrfs is not a viable long-term solution for its quality issues and lack of development, ZFS does not have the pretense of being a filesystem for the general usecase, as exemplified by the lack of offline deduplication, defragmentation, the possibility to easily change disk configurations, and much more. Maybe we should consider accelerating the development of bcachefs as the future of reliable and feature-rich filesystems on Linux, which appears both more modern and holistic, but still has quite some ways to go. A new filesystem is necessary because many things we should demand from them are not modularly composable without massive disadvantages. Implementing compression as a layer, for example, demands basically creating another filesystem to manage the space, with great overhead in all dimensions. Similar things go for the consistency guarantees provided by COW or the deduplication and snapshotting that depends on it.

204 points by cyphar 9y ago

For those who wonder who deprecated it, Red Hat did in the release notes for 7.4. Search for brtfs in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... for details.

lemoncucumber 9y ago
As has been discussed in other threads, RHEL's kernels are ancient compared to mainline and so they probably decided it's just too much work to continually backport btrfs changes onto increasingly dated kernels. The sky is not (necessarily) falling.
- jameskegel 9y ago
  What put t in perspective for me was that here's a company who was a product and they make their money giving those products the utmost attention to things like compatibility and stability, and that means helping when these things break. This is not them making a political move or a line in the sand, this is them saying they can not afford to put the same 110% into this project so they're not going to carry it forward. It's the circle of life and I appreciate them for the rest of their works even if it can be mildly inconvenient in some cases.
- danieldk 9y ago
  But if they thought that btrfs was the future, they would definitely have put in the manpower to maintain and backport btrfs. Red Hat probably believes that XFS + LVM et al. can provide the necessary functionality for enterprise setups on a more reliable basis.
  - catdog 9y ago
    They were never heavily invested in btrfs and they simply already employ a lot of XFS developers. I also don't think it's that easy to put more manpower into it. People with expertise in such such a rather complex niche field don't grow on trees.
    - 72deluxe 9y ago
      But do they grow on btrees? Filesystem joke, hilarious I know
- greglindahl 9y ago
  Uh, the entire value proposition of RHEL is that Red Hat will backport such patches, supporting customers who don't want to change anything until they move up to the next major release.
  - djsumdog 9y ago
    That just feels tragic and silly. Probably many of the same types of shops that won't build the automated dev/ops infrastructures and end-to-end integration tests that let people move up stacks and updates rapidly. I haven't worked at a place that used RHEL in a long time. Unless you use one of their enterprise products like their directory or identity management system, there's no real reason to not use CentOS .. or really anything else for that matter.
    - kijin 9y ago
      Well... a very large portion of the value proposition of CentOS is that Red Hat will backport patches, and that CentOS users will get those patches for free, in case they don't want to change anything until they move up to the next major release.
    - jlgaddis 9y ago
      Not every company is a development shop. Some of us don't need -- or want -- the latest and greatest. I want servers that (other than installing updates) just work and don't have to be constantly maintained.
- djsumdog 9y ago
  Looks like they're running 3.10 on RHEL7.4, which is a pretty old long term release. I mean there are long term 4.x branches now.
  - vbezhenar 9y ago
    It's not 3.10 from kernel.org. There are many backported patches adding support for selected new features, new hardware, etc. It doesn't make much sense to just compare numbers.
    - wtallis 9y ago
      Comparing the version numbers gives a good impression of how much of a maintenance burden RedHat is taking upon themselves. You can't simply presume that RedHat's 3.10 fork is missing any particular feature or fix from future upstream versions, but it's quite obvious that RedHat's fork has to be missing something by now, and probably a lot of somethings.
      - xfs 9y ago
        Enterprise customers care much more about stability than features. Backporting features is always easy, if you consider the amount of work needed to have enterprise level guarantee on their quality. Weeding out bugs in features is much, much harder.
      - jlgaddis 9y ago
        I've got machines that have been running 7 since very shortly after GA and I can't say that I'm missing out on anything that I need.

j_koreth 9y ago

Is there any reason why Oracle contributes so much to Btrfs while maintaining ZFS? Or am I mistaken in Oracle's relationships with ZFS

riffraff 9y ago
oracle has its own linux which it is interested in moving forward, but its version of ZFS is restricted to Solaris.
Elv13 9y ago
Oracle sells Oracle Linux, a RedHat clone. ZFS on Linux (ZoL) isn't controlled by Oracle, it is a fork of OpenSolaris version of ZFS. The ZFS sold by Oracle on Solaris isn't the same product and doesn't support Linux. Oracle doesn't want to support it on Linux because it would fragment one of the remaining cash cow they got from Sun. And anyway, they probably can't support ZoL even if they wanted to without putting themselves into self induced legal gray water. Apparently, they intend to move Solaris into a rolling model like Windows 10, but focused on legacy. They can sell ZFS there without affecting their Linux operations. There is also a rumor of a deal with NetApp not to support ZFS on Linux. All combined, BTRFS is a better suited tech for them to support.
- rehemiau 9y ago
  I was wondering, how does Illumos fit into all this? Is their ZFS the Oracle-controlled one?
  - cyphar 9y ago
    illumos is the repo of record for OpenZFS[1], which is the community fork of OpenSolaris' ZFS (which is now proprietary). Most of the really cool new features are in OpenZFS because it has far more developer involvement (from FreeBSD, illumos, etc). [1]: http://open-zfs.org/wiki/Main_Page http://open-zfs.org/wiki/Main_Page
  - boomboomsubban 9y ago
    No, they split when Oracle bought Sun. The only part of OpenZFS, which everything but Solaris uses, that involves Oracle is a number of patents that the CDDL grants permission to use.

giis 9y ago

Recent Redhat decision may also be related to their investment in Storage products Ceph (~175 million in 2014) and GlusterFS (~125million in 2011) not just about stability of btrfs. As someone who previously experienced with distributed storage like emc-Isilon and also fuse-based glusterfs, btrfs has huge potential for enterprise storage. It does also need more effort on testing front at this moment. hoping that soon btrfs will become default fs for most Linux distros.

ghaff 9y ago
What do distributed software-defined storage/distributed filesystem projects have to do with a CoW filesystem? Alternatives to btrfs are things like XFS and ext4.
jle17 9y ago
I read somewhere (probably on HN) that it could be related to their acquisition of Permabit, a company which seems to be producing Linux software for deduplication, compression and thin-provisionning. This seems more in-line with what btrfs has to offer.

danieldk 9y ago

If Brazil, one of the world biggest producers of beef, would announce to stop producing fish: would you wonder, whether Peru, one of the world biggest producers of fish, would stop producing fish? I find this quite weak argumentation coming from SUSE. Novell/SUSE was also (by far) the largest contributor to AppArmor at some point. And SUSE used it as the MAC framework in their consumer and enterprise distributions. Then seemingly out of nothing they fired the AppArmor team.

jabl 9y ago
Oh? What are they using now then? SELinux?
- sp332 9y ago
  AppArmor is configured to run by default on any fresh installation of SUSE Linux Enterprise Server. https://www.suse.com/documentation/sles11/book_security/data/sec_aaintro_enable.html https://www.suse.com/documentation/sles11/book_security/data... All the drama was back in 2007. https://web.archive.org/web/20160410165126/http://www.cnet.com/news/novell-lays-off-apparmor-programmers/ https://web.archive.org/web/20160410165126/http://www.cnet.c... Looks like it blew over by 2008 https://news.opensuse.org/2008/08/20/opensuse-to-add-selinux-basic-enablement-in-111/ https://news.opensuse.org/2008/08/20/opensuse-to-add-selinux...
- cyphar 9y ago
  Both openSUSE and SLE use AppArmor by default. I believe we provide some support for SELinux if you want to use it, but AppArmor is the default LSM.
appleflaxen 9y ago
that's an important fact about the sustainability of any corporate contributor, but it's not relevant to the thesis of the article (which is that any corporate contributor makes decisions independently than others).

rodgerd 9y ago

That's gotta be the weasel-wordiest straight talk I've seen in a wee while. Here's a fact: the upstream's official statement is that RAID 1 isn't production-ready.

cyphar 9y ago
That's not accurate. Upstream btrfs doesn't support RAID56[1]. However, neither their multiple devices page[2] nor their gotchas page[3] mention that raid0, raid1 or raid10 are not recommended for production. Do you have a citation for your claim? [1]: https://btrfs.wiki.kernel.org/index.php/RAID56 https://btrfs.wiki.kernel.org/index.php/RAID56 [2]: https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Mul... [3]: https://btrfs.wiki.kernel.org/index.php/Gotchas https://btrfs.wiki.kernel.org/index.php/Gotchas
- rodgerd 9y ago
  https://btrfs.wiki.kernel.org/index.php/Status https://btrfs.wiki.kernel.org/index.php/Status "RAID1 mostly OK Can get stuck in irreversible read-only mode if only one device is present." Which is an especially toxic combination with things like: "Device replace mostly OK" It's 30 seconds to find the status page if you're actually trying.
  - colde 9y ago
    In that same page however, they also define "mostly OK" as: > mostly OK: safe for general use, there are some known problems This would seem to suggest they are saying it is okay for production use. Otherwise, what do they mean by "safe for general use"
    - danparsonson 9y ago
      Call me conservative but "Can get stuck in irreversible read-only mode if only one device is present" doesn't equate to "okay for production use" when I'm considering deploying a filesystem; likewise "device replace" being "mostly OK".

jacknews 9y ago

A data-point of one, and I only have a few TB spread over a handful of disks, but I lost an entire 1TB btrfs volume recently because of a single disk sector gone bad (of course, I have backups, but it's a pain to restore 1TB, not to mention racking of the nerves (will the backup drive fail with sudden heavy use?) It's the only FS I've ever been unable to recover data from, at all, (I've had quite a few disks with errors before going back 25 years), and so it's no longer on my list of filesystems-I-trust.

andrewstuart2 9y ago
I've experienced data loss twice in 15 years of using Linux and trying different file systems. Both were on btrfs. I didn't use any advanced features, though I had plans to before this happened. But at that point, I cut my losses and converted all my disks back to ext4. The features are great, but data availability/integrity is the fundamental thing I want from a filesystem. If I write some bytes, they should be there tomorrow. Everything else is secondary.
- cyphar 9y ago
  If you're interested in a more featureful filesystem that isn't btrfs and has a very solid track record, I would recommend looking at XFS. It's a very old filesystem but has a lot of quite modern features (and it performs better than ext4 for several workloads).
  - kogepathic 9y ago
    > I would recommend looking at XFS. It's a very old filesystem but has a lot of quite modern features (and it performs better than ext4 for several workloads). I would second this. XFS is great. A few years ago I moved from JFS to XFS for bulk data storage because JFS is pretty abandoned these days. No issues at all with XFS, and never lost any data. Just make sure it's right for you before you use it (e.g. you cannot shrink XFS volumes as you can ext4)
  - arjie 9y ago
    Funnily enough, XFS is the only file system on Linux where I've lost data. Back in the day, the wisdom was to stay away from it if you were in an iffy power situation because it would serve zeroes if there was a write to a file near a power loss (I.e. you wouldn't get old file or new file but something else) Having had that happen to me I always used some extN and didn't lose any existing files. Of course that's a decade or more ago and I may be misremembering but a cursory Google looks like other people encountered something like it too.

willtim 9y ago

I'm really confused by the choice of development process for BTRFS. First they write huge amounts of experimental/buggy code and then spend years trying to fix it. Reliability was obviously not the primary goal and I doubt they will be able to retrofit it.

kingwill101 9y ago

2 days ago I shutdown my laptop and all was working out great at that point. Now yesterday I turned back on to get some work done and couldn't pass maintenance mode because my home partition got corrupted somehow. Took me all day literally to get it working. I have since changed that partition back to ext4 leaving only / as btrfs

unixhero 9y ago

I use BTRFS for non critical data, like scratch data and second backup archives. This is because I can stretch it out over many old harddrives I have laying around. The memory footprint is also very low. And it comes with compression! But for everything else, I have rammed up, manned up, and use ZFS.

memracom 9y ago

This is a bad move. More than ever we need Linux standards and this goes in the opposite direction. It would be OK for SUSE to support btrfs as a first class choice of filesystem but the extfs family should be the standard one. And ZFS works just fine on Linux. If people want to use it, then the distros should not put roadblocks in their way and that means, ZFS should also be supported as a first class choice for servers. Note that "support" is different from licensing and from "included in our install repo". It is OK to have different licensing for things like this and to install it from a non-distro repo. Look at PostgreSQL for an example of how you can install a mission critical tool from a distro-compatible repo that is run by the upstream project, in this case, PostgreSQL. But even though it comes from a different repo, it should be "supported" by the distro to the extent that they make a best effort to help people resolve problems. It doesn't mean that you need to be experts in every nuance of the tool and the best way to do that is to maintain a good working relationship with these upstream projects. Something like ZFS or PostgreSQL are mission critical tools that use Linux as the interface to the hardware, My comments do not apply to any random app or utility that someone wrote for Linux. Perhaps btrfs belongs in this class but I personally don't know since I have not used it.

deleted 9y ago
[deleted]
gens 9y ago
Linux has lately gotten a lot of bad standards.
- iso-8859-1 9y ago
  Such as?
  - gens 9y ago
    Most of the things by freedesktop.org in the last.. idk 5-10 years. Console-kit/logind, AppData, dbus being used for the lower parts of user-space, and probably many more that i don't recall now. Oh, and pulseaudio. EDIT: How could i forget polkit.

gbrown_ 9y ago

TL;DR - Don't be dissuaded by marketing, here's some more marketing.

Elrac 9y ago

When a CEO/CTO uses the words "straight talk" I prepare for a copious load of meaningless waffling. Was not disappointed!

appleflaxen 9y ago
huh. i found it to be coherent and not-particularly-heavy on techno-doublespeak. while it wasn't particularly edgy/straight, it certainly wasn't "meaningless waffling". i got the impression the title came from wanting to use the german idiomatic expression for "straight talk" in order to work in the butter-cow pun.

hyperfekt 9y ago

I've taken a long look at COW filesystems in these past days as part of me wanting to set up a new workstation, and it appears that while btrfs is not a viable long-term solution for its quality issues and lack of development, ZFS does not have the pretense of being a filesystem for the general usecase, as exemplified by the lack of offline deduplication, defragmentation, the possibility to easily change disk configurations, and much more. Maybe we should consider accelerating the development of bcachefs as the future of reliable and feature-rich filesystems on Linux, which appears both more modern and holistic, but still has quite some ways to go. A new filesystem is necessary because many things we should demand from them are not modularly composable without massive disadvantages. Implementing compression as a layer, for example, demands basically creating another filesystem to manage the space, with great overhead in all dimensions. Similar things go for the consistency guarantees provided by COW or the deduplication and snapshotting that depends on it.