4 ms·

>That's not really very surprising: back in ~2016 when Synology started using btrfs, these features were still somewhat nascent even though other parts of the f

>That's not really very surprising: back in ~2016 when Synology started using btrfs, these features were still somewhat nascent even though other parts of the filesystem were starting to become more mature. btrfs was seven years old at that point and declared "stable" three years before that. ZFS is an example of amazingly written code by awesome engineers. It's simple to manage, scales well, and easy to grok. btrfs sadly will go the wayside once bcachefs reaches maturity. I wouldn't trust btrfs for important data, and neither should you. If you experience data loss on a Synology box, the answer you'll get from them is "tough shit, hope you have backups, and here's a coupon for a new Synology unit."

jchw 2y ago
> btrfs was seven years old at that point and declared "stable" three years before that. The on-disk format was declared stable in 2013[1]. That just meant that barring an act of God, they were not going to break the on-disk format, e.g. a filesystem created at that point would continue to be mountable for the foreseeable future. It was not a declaration that the filesystem was itself now stable necessarily, but especially was not suggesting that all of the features were stable. (As far as I know, many features still carried warning labels.) Furthermore, the "it's been X years!" thing referring to open source projects has to stop. This is the same non-sense that happens with every other thing that is developed in the open. Who cares? What matters isn't how long it took to get here. What matters is where it's at. I know there's going to be some attempt at rationalizing this bit, but it's wasted on me because I'm tired of hearing this. > ZFS is an example of amazingly written code by awesome engineers. It's simple to manage, scales well, and easy to grok. Agreed. But ZFS was written by developers at Sun Microsystems for their commercial UNIX. We should all be gracious to live in a world where Sun Microsystems existed. We should also accept that Sun Microsystems is not the standard any more than Bell Labs was the standard, they are extreme outliers. If we measure everything based on whether it's as good as what Sun Microsystems was doing in the 2000s, we're going to have a bad time. As an example, DTrace is still better than LTTng is right now. I hope that sinks in for everyone. However, OpenZFS is not backed by Sun Microsystems, because Sun Microsystems is dead. Thankfully and graciously at that, it has been maintained for many years by volunteers, including at least one person who worked on ZFS at Sun. (Probably more, but I only know of one.) Now if OpenZFS eats your data, there is no big entity to go to anymore than there is for btrfs. As far as I know, there's no big entity funding development, improvements, or maintenance. That's fine, that's how many filesystems are. But still, that's not what propelled ZFS to where it stood when Sun was murdered. > btrfs sadly will go the wayside once bcachefs reaches maturity. I doubt it will disappear quickly: it will probably continue to see ongoing development. Open Source is generally pretty good at keeping things alive in a zombie state. That's pretty important since it is typically non-trivial to do online conversion of filesystems. (Of course, we're in a thread about a tool that does seamless offline conversion of filesystems, which is pretty awesome and impressive in and of itself.) But for what it's worth, I am fine with bcachefs supplanting btrfs eventually. It seems like it had a better start, it benchmarks faster, and it's maturing nicely. Is it safer today? Depends on who you ask. But it's hard to deny that it doesn't seem like the point at which bcachefs will be considered stable by most will take more than a year or two tops, assuming kernel drama doesn't hold back upstream. Should users trust bcachefs with their data? I think you probably can right now with decent safety, if you're using mainline kernels, but bcachefs is still pretty new. Not aware of anyone using it in production yet. It really could use a bit more time before recommending people jump over to it. > I wouldn't trust btrfs for important data, and neither should you. I stand by my statement: you should always ensure you have sufficient backups for important data, but most users should absolutely fear hardware failures more than btrfs bugs. Hardware failures are an if, not a when. Hardware will always fail eventually. Data-eating btrfs bugs have certainly existed, but it's not like they just appear left and right. When such a bug appears, it is often newsworthy, and usually has to do with some unforeseen case that you are not so likely to run into by accident. Rather than lose data, btrfs is instead more likely to just piss you off by being weird. There are known quirks that probably won't lose you any data, but that are horribly annoying. It is still possible, to my knowledge, to get stuck in a state where the filesystem is too full to delete files and the only way out is in recovery. This is pretty stupid. It's also not particularly fast, so if someone isn't looking for a feature-rich CoW filesystem with checksums, I strongly recommend just going with XFS instead. But if you run Linux and you do want that, btrfs is the only mainline game in town. ZFS is out-of-tree and holds back your kernel version, not to mention you can never really ship products using it (with Linux) because of silly licensing issues. > If you experience data loss on a Synology box, the answer you'll get from them is "tough shit, hope you have backups, and here's a coupon for a new Synology unit." That suggests that their brand image somewhat depends on the rarity of btrfs bugs in their implementation, but Synology has a somewhat good reputation actually. If anything really hurts their reputation, it's mainly the usual stuff (enshittification.) The fact that DSM defaults to using btrfs is one of the more boring things at this point. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4204617d142c0887e45fda2562cb5c58097b918e https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- anonfordays 2y ago
  This is clearly gish gallop, but I'll reply. >The on-disk format was declared stable in 2013 And the mkfs.btrfs tool was labeled stable, and the experimental tag was removed from mkfs.btrfs warnings. It was also mainlined into the stable branch at that point. It wasn't just the on-disk format that was declared stable in 2013. >It was not a declaration that the filesystem was itself now stable necessarily, Yes it was, as explained above. >Furthermore, the "it's been X years!" thing referring to open source projects has to stop. This isn't some "open source project," this is the operating system that underpins modern computing. It's developed by full time engineers paid by megacorps. It's not some solo developer's side project, not in the slightest. >If we measure everything based on whether it's as good as what Sun Microsystems was doing in the 2000s, we're going to have a bad time. Not at all, we're going to have a great time. Great engineering stands the test of time. >As an example, DTrace is still better than LTTng is right now. I hope that sinks in for everyone. Did you get ChatGPT to write this? It's clear you have zero experience in the tracing and observability space. eBPF is the next evolution, not LTTng. It's never been and LTTng, LTTng has minuscule usage. I hope you're ignorance is clear for everyone reading this. >However, OpenZFS is not backed by Sun Microsystems, because Sun Microsystems is dead. No, it's maintained by dozens of engineers from multiple different companies and governmental orgaizations. >Now if OpenZFS eats your data, there is no big entity to go to anymore than there is for btrfs. Wrong, Canonical supports ZFS. >As far as I know, there's no big entity funding development, improvements, or maintenance. LLNL (the US government), among others, are funding the development of OpenZFS. >That suggests that their brand image somewhat depends on the rarity of btrfs bugs in their implementation, but Synology has a somewhat good reputation actually. No, Synology has a terrible reputation. They removed btrfs functionality from budget models and left customers in the dust: https://news.ycombinator.com/item?id=26800062 https://news.ycombinator.com/item?id=26800062

jchw 2y ago

> btrfs was seven years old at that point and declared "stable" three years before that. The on-disk format was declared stable in 2013[1]. That just meant that barring an act of God, they were not going to break the on-disk format, e.g. a filesystem created at that point would continue to be mountable for the foreseeable future. It was not a declaration that the filesystem was itself now stable necessarily, but especially was not suggesting that all of the features were stable. (As far as I know, many features still carried warning labels.) Furthermore, the "it's been X years!" thing referring to open source projects has to stop. This is the same non-sense that happens with every other thing that is developed in the open. Who cares? What matters isn't how long it took to get here. What matters is where it's at. I know there's going to be some attempt at rationalizing this bit, but it's wasted on me because I'm tired of hearing this. > ZFS is an example of amazingly written code by awesome engineers. It's simple to manage, scales well, and easy to grok. Agreed. But ZFS was written by developers at Sun Microsystems for their commercial UNIX. We should all be gracious to live in a world where Sun Microsystems existed. We should also accept that Sun Microsystems is not the standard any more than Bell Labs was the standard, they are extreme outliers. If we measure everything based on whether it's as good as what Sun Microsystems was doing in the 2000s, we're going to have a bad time. As an example, DTrace is still better than LTTng is right now. I hope that sinks in for everyone. However, OpenZFS is not backed by Sun Microsystems, because Sun Microsystems is dead. Thankfully and graciously at that, it has been maintained for many years by volunteers, including at least one person who worked on ZFS at Sun. (Probably more, but I only know of one.) Now if OpenZFS eats your data, there is no big entity to go to anymore than there is for btrfs. As far as I know, there's no big entity funding development, improvements, or maintenance. That's fine, that's how many filesystems are. But still, that's not what propelled ZFS to where it stood when Sun was murdered. > btrfs sadly will go the wayside once bcachefs reaches maturity. I doubt it will disappear quickly: it will probably continue to see ongoing development. Open Source is generally pretty good at keeping things alive in a zombie state. That's pretty important since it is typically non-trivial to do online conversion of filesystems. (Of course, we're in a thread about a tool that does seamless offline conversion of filesystems, which is pretty awesome and impressive in and of itself.) But for what it's worth, I am fine with bcachefs supplanting btrfs eventually. It seems like it had a better start, it benchmarks faster, and it's maturing nicely. Is it safer today? Depends on who you ask. But it's hard to deny that it doesn't seem like the point at which bcachefs will be considered stable by most will take more than a year or two tops, assuming kernel drama doesn't hold back upstream. Should users trust bcachefs with their data? I think you probably can right now with decent safety, if you're using mainline kernels, but bcachefs is still pretty new. Not aware of anyone using it in production yet. It really could use a bit more time before recommending people jump over to it. > I wouldn't trust btrfs for important data, and neither should you. I stand by my statement: you should always ensure you have sufficient backups for important data, but most users should absolutely fear hardware failures more than btrfs bugs. Hardware failures are an if, not a when. Hardware will always fail eventually. Data-eating btrfs bugs have certainly existed, but it's not like they just appear left and right. When such a bug appears, it is often newsworthy, and usually has to do with some unforeseen case that you are not so likely to run into by accident. Rather than lose data, btrfs is instead more likely to just piss you off by being weird. There are known quirks that probably won't lose you any data, but that are horribly annoying. It is still possible, to my knowledge, to get stuck in a state where the filesystem is too full to delete files and the only way out is in recovery. This is pretty stupid. It's also not particularly fast, so if someone isn't looking for a feature-rich CoW filesystem with checksums, I strongly recommend just going with XFS instead. But if you run Linux and you do want that, btrfs is the only mainline game in town. ZFS is out-of-tree and holds back your kernel version, not to mention you can never really ship products using it (with Linux) because of silly licensing issues. > If you experience data loss on a Synology box, the answer you'll get from them is "tough shit, hope you have backups, and here's a coupon for a new Synology unit." That suggests that their brand image somewhat depends on the rarity of btrfs bugs in their implementation, but Synology has a somewhat good reputation actually. If anything really hurts their reputation, it's mainly the usual stuff (enshittification.) The fact that DSM defaults to using btrfs is one of the more boring things at this point. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4204617d142c0887e45fda2562cb5c58097b918e https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

anonfordays 2y ago
This is clearly gish gallop, but I'll reply. >The on-disk format was declared stable in 2013 And the mkfs.btrfs tool was labeled stable, and the experimental tag was removed from mkfs.btrfs warnings. It was also mainlined into the stable branch at that point. It wasn't just the on-disk format that was declared stable in 2013. >It was not a declaration that the filesystem was itself now stable necessarily, Yes it was, as explained above. >Furthermore, the "it's been X years!" thing referring to open source projects has to stop. This isn't some "open source project," this is the operating system that underpins modern computing. It's developed by full time engineers paid by megacorps. It's not some solo developer's side project, not in the slightest. >If we measure everything based on whether it's as good as what Sun Microsystems was doing in the 2000s, we're going to have a bad time. Not at all, we're going to have a great time. Great engineering stands the test of time. >As an example, DTrace is still better than LTTng is right now. I hope that sinks in for everyone. Did you get ChatGPT to write this? It's clear you have zero experience in the tracing and observability space. eBPF is the next evolution, not LTTng. It's never been and LTTng, LTTng has minuscule usage. I hope you're ignorance is clear for everyone reading this. >However, OpenZFS is not backed by Sun Microsystems, because Sun Microsystems is dead. No, it's maintained by dozens of engineers from multiple different companies and governmental orgaizations. >Now if OpenZFS eats your data, there is no big entity to go to anymore than there is for btrfs. Wrong, Canonical supports ZFS. >As far as I know, there's no big entity funding development, improvements, or maintenance. LLNL (the US government), among others, are funding the development of OpenZFS. >That suggests that their brand image somewhat depends on the rarity of btrfs bugs in their implementation, but Synology has a somewhat good reputation actually. No, Synology has a terrible reputation. They removed btrfs functionality from budget models and left customers in the dust: https://news.ycombinator.com/item?id=26800062 https://news.ycombinator.com/item?id=26800062