6 ms·

If this means we're going to have to continue the next decade with btrfs I may scream. I already use ZFS everywhere, but it's ease of use has been distro depend

If this means we're going to have to continue the next decade with btrfs I may scream. I already use ZFS everywhere, but it's ease of use has been distro dependent. Linus looks like he's back to his old ways. I should take a closer look at illumos.

KaiserPro 3y ago
whats this got to do with ZFS?
- fmajid 3y ago
  Given bcachefs' cheeky strapline "The COW filesystem for Linux that won't eat your data" (clearly referring to btrfs' spotty record of reliability and data loss), it's understandable the btrfs people are feeling triggered, that doesn't excuse the passive-aggressive obstacles those who are gatekeepers for kernel FS code have been using to stall adoption of bcachefs in the kernel. ZFS is the only other alternative to bcachefs (a rock-solid one, albeit not license-compatible), which is why it's mentioned.
  - KaiserPro 3y ago
    Ah right, I hadn't really looked at bcachefs since about 2016 when it was still a specialist object store
  - panick21_ 3y ago
    Omg how after all this time are people still fucking repeating this 'not license-compatible' nonsense. This is one of this myths that at some point has infected the OpenSource community and its so totally wrong and damaging. Its not license incompatible, many, many, many organizations have shipped ZFS as part of the distribution and absolutely nobody ever sued or even threatened sue over the license. Linus didn't want to merge it because of some vague fear of Oracle and how they sued over Java, but that was about API not license. What Linus should have done is to simple upstream it. If some big company (IBM or whoever) wants to not 'risk' ZFS then they should damn well do their own work and remove it. There is no reason that the waste majority of the Linux community should be denied great features (ZFS, DTrace and friends) over some vague fear of Oracle.
    - bcantrill 3y ago
      I obviously share your frustration! I have long viewed these bogus licensing claims as the open source variant of NIH syndrome,[0] complete with the conjuring of both fear and grievance that always makes for particularly virulent thinking among the orthodox. [0] https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here
      - fmajid 3y ago
        Hi Bryan! Yes, NIH is the most likely explanation, since btrfs was accepted depite originating from deepest, darkest Oracle (and I happen to share your dim opinion of them).
      - arp242 3y ago
        But the license claims aren't bogus – or at least not all of them? For example the CDDL states that you can't add additional restrictions, but if you combine it with the GPL then the GPL also applies, so that's an "additional restriction", no? Of course, all of this is highly legalistic and in spirit the CDDL and GPL are essentially identical, and from that perspective any lawsuit would be complete bollocks, but ... bollocks lawsuits do happen. There's lots of claims about GPL and CDDL compatibility floating around and much of it sounds at least plausible and it's all a bit controversial. Clearing up this sort of confusion is exactly the sort of scenario where courts come in to play. So it seems to me that fears of a lawsuit are not entirely unreasonable. Do you want to put all your money and the future development of Linux at risk? The nature of lawsuits in the US means that as soon as the lawsuit is filed you've lost already, and the ruling just decides if you've lost even harder. Not denying Linux can have its share of NIH, but I see this mostly as a matter of risk management. e.g. Canonical has decided to take that risk, which is fair and reasonable, but Linus decided to not take that risk, which is also fair and reasonable. Of course the entire situation is ridiculous; btrfs is partly sponsored by Oracle, and Oracle is also sitting on a perfectly functional filesystem they can just relicense like they did with dtrace. I don't know what's preventing Oracle from doing that.
        fmajid 3y ago
- lproven 3y ago
  ZFS is the far more solid big sibling of Btrfs, but its license is not compatible with the GPL so most distros won't use it. This licensing issue is the reason bcachefs exists.
chippiewill 3y ago
Linus isn't behaving greatly here, but having a read through of the whole mailing list thread I'm actually fairly understanding of his reaction for once. Here's this big project that Kent's been wanting to merge for ages and very basic steps that any Kernel developer would be aware of (like sending it to linux-next first) have not been done.
- yukkuri 3y ago
  Linus is the king of not behaving well, and his position of "owning" the most popular kernel allows him to get away with it. Yes Kent isn't following the right process but he made a more fundamental mistake: getting involved with Linux development at all.
jcalvinowens 3y ago
What's wrong with btrfs? I've been using it for a decade, both as a daily driver and on a NAS. I think it's great. I hate building external modules, ZFS has never seemed worth the trouble to me. Why do you care so much?
- lproven 3y ago
  How long have you got? https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/ https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu... I have had Btrfs collapse and corrupt itself more in the last half a decade than all other Linux filesystems put together this century. If you fill the volume, it will fail, and its own repair tools do not work and will damage it further. I would not and do not trust it.
  - jcalvinowens 3y ago
    I don't care about the raid features personally, that's irrelevant to me. I care about snapshotting and send streams more than anything else. Your anecdotal evidence about data loss is meaningless. I can counter with my own anecdote: I've had zero data loss with btrfs running pre-release RC kernels on my laptops for over a decade. I fill up disks a lot.
    - lproven 3y ago
      Good for you. One failure report is worth 1,000 success reports. Add as many orders of magnitude as you wish, and the statement remains true. This is not merely an axiom of reviewing and assessment, it's a joke: https://xkcd.com/937/ https://xkcd.com/937/ I've been reviewing tech for a living for nearly 30 years now, and evaluating tech for a living -- as well as using it and fixing it and deploying it -- since the decade before that. The point of tech assessment and tech reviewing is to balance the good features against the bad features. Too many people get dazzled by the good stuff so that they don't notice the bad stuff. As the late great Douglas Adams put it: « In other words - and this is the rock-solid principle on which the whole of the Corporation's Galaxywide success is founded - their fundamental design flaws are completely hidden by their superficial design flaws.” » I don't care how good the features of a filesystem are if I can't trust it. Either it needs to be very solid, and have good documented battle-tested tools for fixing it and repairing it, such as XFS or JFS... which probably means it is also conservative on the features. Or, alternatively, absolutely blasted bulletproof, to the extend that a multi-billion-dollar corporation sees fit to launch it without a repair tool because it doesn't need one. There is one such system, and it is ZFS. Btrfs is neither. It is loaded with features, some half implemented if that, it is fragile, and it does not have good repair features. If I had seen it fail once, I would be dubious and sceptical. If I had seen it fail twice, I would no longer trust it. But I have not. I have seen it fail half a dozen times in 4 years. And it is not just me. Here is the documentation on the repair tool: « Warning Do not use `--repair` unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. E.g. some other software or hardware bugs can fatally damage a volume. » Source: https://btrfs.readthedocs.io/en/latest/btrfs-check.html https://btrfs.readthedocs.io/en/latest/btrfs-check.html Here is #1 corporate user SUSE's: « WARNING: Using '--repair' can further damage a filesystem instead of helping if it can't fix your particular issue. » Source: https://www.suse.com/support/kb/doc/?id=000018769 https://www.suse.com/support/kb/doc/?id=000018769 In corporate terms, this is an admission. This tool cannot be trusted and that it is present means that the FS cannot be relied upon. This is a giant red flashing light and eardrum-bashing warning siren. It doesn't matter how many people like it and have had no problems. THERE ARE PROBLEMS. It doesn't matter how many corporates use it. A broken tool may still be usable. Meta may deploy Btrfs across racks of kit but they don't care about the data on those racks and it can be replaced. Fedora doesn't use snapshot support because it's bodged that functionality into OStree so it doesn't care if it's dangerous. It just wants to describe how horrendously inefficient Flatpak is.
yukkuri 3y ago
You can sometimes get a narcissist to behave superficially like a person without a personality disorder by pushing them hard, but they always relapse.

KaiserPro 3y ago

whats this got to do with ZFS?

fmajid 3y ago
Given bcachefs' cheeky strapline "The COW filesystem for Linux that won't eat your data" (clearly referring to btrfs' spotty record of reliability and data loss), it's understandable the btrfs people are feeling triggered, that doesn't excuse the passive-aggressive obstacles those who are gatekeepers for kernel FS code have been using to stall adoption of bcachefs in the kernel. ZFS is the only other alternative to bcachefs (a rock-solid one, albeit not license-compatible), which is why it's mentioned.
- KaiserPro 3y ago
  Ah right, I hadn't really looked at bcachefs since about 2016 when it was still a specialist object store
- panick21_ 3y ago
  Omg how after all this time are people still fucking repeating this 'not license-compatible' nonsense. This is one of this myths that at some point has infected the OpenSource community and its so totally wrong and damaging. Its not license incompatible, many, many, many organizations have shipped ZFS as part of the distribution and absolutely nobody ever sued or even threatened sue over the license. Linus didn't want to merge it because of some vague fear of Oracle and how they sued over Java, but that was about API not license. What Linus should have done is to simple upstream it. If some big company (IBM or whoever) wants to not 'risk' ZFS then they should damn well do their own work and remove it. There is no reason that the waste majority of the Linux community should be denied great features (ZFS, DTrace and friends) over some vague fear of Oracle.
  - bcantrill 3y ago
    I obviously share your frustration! I have long viewed these bogus licensing claims as the open source variant of NIH syndrome,[0] complete with the conjuring of both fear and grievance that always makes for particularly virulent thinking among the orthodox. [0] https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here
    - fmajid 3y ago
      Hi Bryan! Yes, NIH is the most likely explanation, since btrfs was accepted depite originating from deepest, darkest Oracle (and I happen to share your dim opinion of them).
    - arp242 3y ago
      But the license claims aren't bogus – or at least not all of them? For example the CDDL states that you can't add additional restrictions, but if you combine it with the GPL then the GPL also applies, so that's an "additional restriction", no? Of course, all of this is highly legalistic and in spirit the CDDL and GPL are essentially identical, and from that perspective any lawsuit would be complete bollocks, but ... bollocks lawsuits do happen. There's lots of claims about GPL and CDDL compatibility floating around and much of it sounds at least plausible and it's all a bit controversial. Clearing up this sort of confusion is exactly the sort of scenario where courts come in to play. So it seems to me that fears of a lawsuit are not entirely unreasonable. Do you want to put all your money and the future development of Linux at risk? The nature of lawsuits in the US means that as soon as the lawsuit is filed you've lost already, and the ruling just decides if you've lost even harder. Not denying Linux can have its share of NIH, but I see this mostly as a matter of risk management. e.g. Canonical has decided to take that risk, which is fair and reasonable, but Linus decided to not take that risk, which is also fair and reasonable. Of course the entire situation is ridiculous; btrfs is partly sponsored by Oracle, and Oracle is also sitting on a perfectly functional filesystem they can just relicense like they did with dtrace. I don't know what's preventing Oracle from doing that.
      - fmajid 3y ago
lproven 3y ago
ZFS is the far more solid big sibling of Btrfs, but its license is not compatible with the GPL so most distros won't use it. This licensing issue is the reason bcachefs exists.

chippiewill 3y ago

Linus isn't behaving greatly here, but having a read through of the whole mailing list thread I'm actually fairly understanding of his reaction for once. Here's this big project that Kent's been wanting to merge for ages and very basic steps that any Kernel developer would be aware of (like sending it to linux-next first) have not been done.

yukkuri 3y ago
Linus is the king of not behaving well, and his position of "owning" the most popular kernel allows him to get away with it. Yes Kent isn't following the right process but he made a more fundamental mistake: getting involved with Linux development at all.

jcalvinowens 3y ago

What's wrong with btrfs? I've been using it for a decade, both as a daily driver and on a NAS. I think it's great. I hate building external modules, ZFS has never seemed worth the trouble to me. Why do you care so much?

lproven 3y ago
How long have you got? https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/ https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu... I have had Btrfs collapse and corrupt itself more in the last half a decade than all other Linux filesystems put together this century. If you fill the volume, it will fail, and its own repair tools do not work and will damage it further. I would not and do not trust it.
- jcalvinowens 3y ago
  I don't care about the raid features personally, that's irrelevant to me. I care about snapshotting and send streams more than anything else. Your anecdotal evidence about data loss is meaningless. I can counter with my own anecdote: I've had zero data loss with btrfs running pre-release RC kernels on my laptops for over a decade. I fill up disks a lot.
  - lproven 3y ago
    Good for you. One failure report is worth 1,000 success reports. Add as many orders of magnitude as you wish, and the statement remains true. This is not merely an axiom of reviewing and assessment, it's a joke: https://xkcd.com/937/ https://xkcd.com/937/ I've been reviewing tech for a living for nearly 30 years now, and evaluating tech for a living -- as well as using it and fixing it and deploying it -- since the decade before that. The point of tech assessment and tech reviewing is to balance the good features against the bad features. Too many people get dazzled by the good stuff so that they don't notice the bad stuff. As the late great Douglas Adams put it: « In other words - and this is the rock-solid principle on which the whole of the Corporation's Galaxywide success is founded - their fundamental design flaws are completely hidden by their superficial design flaws.” » I don't care how good the features of a filesystem are if I can't trust it. Either it needs to be very solid, and have good documented battle-tested tools for fixing it and repairing it, such as XFS or JFS... which probably means it is also conservative on the features. Or, alternatively, absolutely blasted bulletproof, to the extend that a multi-billion-dollar corporation sees fit to launch it without a repair tool because it doesn't need one. There is one such system, and it is ZFS. Btrfs is neither. It is loaded with features, some half implemented if that, it is fragile, and it does not have good repair features. If I had seen it fail once, I would be dubious and sceptical. If I had seen it fail twice, I would no longer trust it. But I have not. I have seen it fail half a dozen times in 4 years. And it is not just me. Here is the documentation on the repair tool: « Warning Do not use `--repair` unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. E.g. some other software or hardware bugs can fatally damage a volume. » Source: https://btrfs.readthedocs.io/en/latest/btrfs-check.html https://btrfs.readthedocs.io/en/latest/btrfs-check.html Here is #1 corporate user SUSE's: « WARNING: Using '--repair' can further damage a filesystem instead of helping if it can't fix your particular issue. » Source: https://www.suse.com/support/kb/doc/?id=000018769 https://www.suse.com/support/kb/doc/?id=000018769 In corporate terms, this is an admission. This tool cannot be trusted and that it is present means that the FS cannot be relied upon. This is a giant red flashing light and eardrum-bashing warning siren. It doesn't matter how many people like it and have had no problems. THERE ARE PROBLEMS. It doesn't matter how many corporates use it. A broken tool may still be usable. Meta may deploy Btrfs across racks of kit but they don't care about the data on those racks and it can be replaced. Fedora doesn't use snapshot support because it's bodged that functionality into OStree so it doesn't care if it's dangerous. It just wants to describe how horrendously inefficient Flatpak is.

yukkuri 3y ago

You can sometimes get a narcissist to behave superficially like a person without a personality disorder by pushing them hard, but they always relapse.