SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
Posted Aug 24, 2017 13:53 UTC (Thu) by moltonel (guest, #45207)Parent article: SUSE reaffirms support for Btrfs
Posted Aug 24, 2017 15:06 UTC (Thu)
by cjcox (guest, #60378)
[Link] (41 responses)
While I hate to bring up reiserfs (the "Trump" of filesystems, that is, hated "just because"), SuSE dominated the enterprise space because they had a journaling filesystem that worked well with LVM and didn't have the limitations of ext2 based filesystems. Of course, that was "then" and Red Hat adopted xfs as their "enterprise" answer nowadays (and of course the "bought" LVM). But there for the longest time, SuSE was pretty much the only enterprise worthy distribution, even though the alt-filesystem groups disagreed with some of their choices. But again, that was "then". Not sure if this strategy will work for SuSE now with regards to Btfs.
Posted Aug 24, 2017 15:44 UTC (Thu)
by SEJeff (guest, #51588)
[Link] (6 responses)
reiserfs was hated because it wasn't very crash safe, and while very fast, was extremely buggy. The journaling didn't work that wonderfully and it would require long fsck to recover if you were lucky when a box was powered off unexpectedly. To be fair, xfs had the same limitation at the time, but had a much smaller featureset compared to reiserfs at the time. The reason reiserfs went out of fashion was because reiser4 was too ambitious, and there was that little thing where Hans Reiser was convicted of murdering his wife. Reiser Systems went out of business and the filesystems were not well maintained after the downfall of Hans. The reason reiserfs (and reiser4) went out of fashion was because they weren't maintained very well compared to competing filesystems.
Redhat and SUSE work together plenty, look no further than SUSE's libsolv (https://en.wikipedia.org/wiki/DNF_(software)#libsolv ), which is the package dependency resolution aspect of dnf, Redhat's new shiney package manager to replace yum. Redhat AND SUSE worked together on btrfs for a long time, but Redhat sees the tech as still too immature for enterprise adoption. This isn't really that different years ago when SUSE was the first enterprise distro to officially support Xen, long before Redhat said Xen was ready for enterprise adoption. When I got to look at it, the SUSE forked Xen had a lot of limitations and omissions that made it "enterprise ready" for very specific and niche use cases. A few years later, Redhat officially supported Xen when it was actually enterprise ready. Then Avi posted KVM to LKML. Avi and his company, Qumranet, did virtualization on Linux better than Xen, and so Redhat bought them + ditched Xen, a legacy that SUSE is still sort of stuck with.
What do you even mean by Redhat "buying LVM"? Are you referring to Sistina? Sistina open sourced LVM and sent patches to Linux around Linux 2.2 (1999ish). Redhat bought them in 2003, so your argument still doesn't hold water.
Posted Aug 24, 2017 23:49 UTC (Thu)
by ThinkRob (guest, #64513)
[Link] (5 responses)
I think that from a business standpoint, Redhat wants to make sure that they're never at the mercy of a competitor. So for some tech, that means sponsoring or even "buying" the project (although the latter is probably only useful if they have a CLA).
Really I think it's about Redhat not wanting to build a bunch of stuff on something, only to have Oracle or IBM or whomever swing by five years into a release and buy the project out from under them, then turn around and demand money from Redhat for continued access to patches/source/whatever-other-vital-asset. That would be the nightmare scenario: if Redhat added a major feature into RHEL, had customers build things that depend on it, and then half way through the support period Redhat had to choose between paying royalties to a hostile third party or eating the cost of maintenance of the project. At least "buying" the various projects gives them some budgetary freedom, since presumably there's already a community doing a lot of the heavy lifting. That frees up RH to scale its involvement as it wants, from leadership positions (ala CentOS) to "just fix the things that affect the version we shipped in RHEL."
Posted Aug 26, 2017 4:09 UTC (Sat)
by gdt (subscriber, #6284)
[Link]
When you buy a open-source software company you also get the people. Often the ability to direct the future work of the software team is more important than the software as-is (which, after all, you can ship and modify for free). Moreover, if you are a vendor offering long-term support of Linux for enterprises you might want to be able to direct the team's urgent attention to a five-year old bug, fixed for years, but which is nevertheless preventing a bank from doing its thing. The ‘community’ in this case is not useful, as their answer is “upgrade”. These occasions are rare, but it is an important capability which allows the software vendor to charge high prices to such enterprises.
Posted Aug 28, 2017 15:52 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (1 responses)
I'm not sure what you mean by this, when Redhat "buys" a project that just means hiring the most productive members of the community, the ones working full-time on the project, so by definition then Redhat is doing the heavy lifting as the majority of the hours put in by the community.
> or whomever swing by five years into a release and buy the project out from under them, then turn around and demand money from Redhat ...
If they hire the developers of the project then they are by definition eating the nearly full costs of maintenance for a project, I don't think there is any scenario where Redhat pays royalties as opposed to hiring staff to continue maintenance as they don't ship anything they don't have a clear source license to. I doubt that Redhat ships anything where the bulk of development hours are currently paid for by someone else that they don't have a plan to full development resources on it should the maintainers stop for whatever reason.
Posted Sep 1, 2017 0:55 UTC (Fri)
by ThinkRob (guest, #64513)
[Link]
Well yeah, but they also benefit from the long tail of contributions.
> If they hire the developers of the project then they are by definition eating the nearly full costs of maintenance for a project, I don't think there is any scenario where Redhat pays royalties as opposed to hiring staff to continue maintenance as they don't ship anything they don't have a clear source license to.
That's true. I suspect I should have been clearer. I think they deliberately try to make sure they *don't* wind up in a position where they'd have to do that, and that this is one way of ensuring it.
Posted Aug 28, 2017 19:08 UTC (Mon)
by flussence (guest, #85566)
[Link]
Outside the bubble this isn't a hypothetical scenario: people already invest a lot of effort, money and time to defend the wider Linux community against becoming wholly dependent on Redhat projects (including under the fd.o umbrella).
Posted Mar 28, 2018 17:32 UTC (Wed)
by ceplm (subscriber, #41334)
[Link]
Posted Aug 24, 2017 15:49 UTC (Thu)
by drag (guest, #31333)
[Link] (30 responses)
'Tech Preview' means that support for btrfs is integrated into the OS, but it's not a supported configuration by Redhat. This is very common for Redhat to do this because it allows customers that are interested in the technology to have a easy way to test it and provide feedback. It's also something that has been integrated into Fedora and has been used 'in the wild' by a wide number of people, myself included.
Redhat didn't state why they dropped btrfs and are not going to use it going forward. The easy thing to assume is that customer feedback was rather negative and Redhat decided it was not a good direction to go.
Evidence is stacking up that BTRFS is broken unless they are willing to make significant changes to the on-disk format, which would essentially necessitate a 'btrfsv2' since that is a dramatic thing. Hopefully this is not the case, but time will tell.
Meanwhile it would be nice if somebody picked up the currently-seeking-employment developer of Bcachefs, Kent Overstreet, and help him get his project up to the point where it can be made ready for inclusion into the kernel. It has a lot of promise.
Posted Aug 24, 2017 22:25 UTC (Thu)
by rahvin (guest, #16953)
[Link] (2 responses)
Posted Aug 25, 2017 1:03 UTC (Fri)
by drag (guest, #31333)
[Link]
I, too, have been using Btrfs for a while. I've used it on different systems and have had data being eaten and volumes filling up unexpectedly and such things that commonly affect btrfs users. I like it a lot due to it's online compression support and such things.
I have grown from being optimistic to cautiously hopeful to 'lets see what other options are out there'.
Posted Aug 26, 2017 10:46 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Higher-level raid (in other words anything above 0 or 1) is still very experimental.
I think the rebalancing problem has been fixed (which would iirc cause a system to apparently hang and in the past also trashed file-systems).
Btrfs is perfectly safe IF you stay within its known limits, ie don't use higher raid, and don't fill the disk up ...
Cheers,
Posted Aug 24, 2017 22:49 UTC (Thu)
by BillyBob (guest, #118071)
[Link] (5 responses)
While I don't disagree that bcachefs shows promise the fact that the project's sole developer decided to take something like two and a half months off to go backpacking doesn't exactly inspire a ton of confidence. It was only in the last 24 hours that the project's git repo has shown any sign of life since 2017-06-13.
Also, bcachefs, while promising hasn't reached anything anywhere near feature parity with Btrfs. As things stand now bcachefs still lacks properly implemented compression, replication, functional checksum scrubing, and any sign of snapshotting. The lack of snapshot support is what I find most troubling as Kent himself even states:
> snapshots are by far the most complex of the remaining features to implement - it's
I'm not trying to bash Kent or bcachefs; I'm simply trying to point out that as a Btrfs competitor it has a long way to go and for the last few months it's been a ship without a captain.
Posted Aug 25, 2017 1:06 UTC (Fri)
by drag (guest, #31333)
[Link] (1 responses)
Would you rather have a developer that has no balance in his life and burns out and drops out of supporting the file system altogether when something else new and shiny comes along?
Posted Aug 25, 2017 2:37 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link]
I think what BillyBob would prefer is multiple core developers, so that one of them can take a few months off without stopping all support and progress on the project.
Posted Aug 25, 2017 12:50 UTC (Fri)
by jond (subscriber, #37669)
[Link] (1 responses)
Developing filesystems takes a long time. It's a marathon, not a sprint. Taking 2 months off is insignificant really, in terms of the time it takes for a filesystem to reach some sense of maturity, and is a much better idea than burning out. Especially if we are talking about one single developer.
> Also, bcachefs, while promising hasn't reached anything anywhere near feature parity with Btrfs.
Btrfs is already 10 years old. I couldn't quickly figure out how old bcachefs is but it would appear no more than a year or two? That's quite a time advantage, and Btrfs has enjoyed corporate sponsorship and multiple developers for much of that 10 years. It's way too early to try to compare them.
10 years, and some say still not ready for mainstream use.
Posted Aug 27, 2017 5:58 UTC (Sun)
by kmeyer (subscriber, #50720)
[Link]
Posted Aug 26, 2017 10:18 UTC (Sat)
by bluss (guest, #47454)
[Link]
Posted Aug 24, 2017 23:10 UTC (Thu)
by ttelford (guest, #44176)
[Link]
Posted Aug 24, 2017 23:25 UTC (Thu)
by jhoblitt (subscriber, #77733)
[Link] (19 responses)
I'm honestly not sure why desktop users seem to be so enthusiastic about btrfs and/or zfs. Block level checksuming is a "nice to have" but a data integrity scheme, even for a laptop, it does not make. Software raid, other than raid1, is unimpressive and/or dangerous for many workloads without a battery backed write cache. Many desktop users, myself included, have been using lvm+dmraid since the early 2000s.
At the large end of the storage spectrum, parallel filesystems (GPFS, ceph, etc.) are widely used and there is a strong move towards object storage with very un-posix like semantics.
Posted Aug 25, 2017 1:28 UTC (Fri)
by drag (guest, #31333)
[Link] (14 responses)
Btrfs is now over 8 years old and Oracle was declaring it 'production ready' about 5 years ago.
It's had a long time and lots of testers.
I have used btrfs on many systems. I have tried to use it conjunction with ceph, which was a disaster. I have tried to use it provide backing storage virtual machines, which was really painful. I have used it's online compression to conserve disk space on small SSDs which for the most part was a very good decision. I have used it on my desktop and ran into issues with it running out of disk space, but I never lost me data. I also have used it on my own file servers and back up servers and took full advantage of the ability to use checksums to scrub and correct data, especially when I was losing drives due to a flaky SATA controller and it was completely awesome in that regards.
I have had mixed, but largely positive results in my own usage with it.
> I'm honestly not sure why desktop users seem to be so enthusiastic about btrfs and/or zfs.
Most of these desktop users have file servers they like to store lots of their personal data in. They use cheap consumer-grade hardware that sucks badly.
Having a file system that is robust and safe and able to add significant value to cheap hardware is something that everybody is looking for... All the way from Enterprise, public cloud provideres, to home gamers. It's a massive win for pretty much everybody.
> Software raid, other than raid1, is unimpressive and/or dangerous for many workloads without a battery backed write cache.
Software raid doesn't have a cache to need a battery back up, generally speaking. RAID 5 is obsolete, but RAID 1, RAID 10, and RAID 6 are very robust and useful software raid styles.
'RAID10' mode for BTRFS has always been more then enough for me and I never understood why RAID5 was so valuable to so many people. For the cost of a extra drive RAID10 is more then worth it.
I would of been quite happy if the btrfs developers simply told the world that if they want to have replicated data they need to do it in RAID1 or RAID10. But they didn't do that and promised people their RAID5-like features and so far it has caused quite a bit of pain for btrfs adopters. Hopefully they have this fixed.
Posted Aug 25, 2017 2:14 UTC (Fri)
by ttelford (guest, #44176)
[Link] (13 responses)
If your array has 3 drives, you have a point. There's only one more drive needed to go RAID 10.
However, RAID10 gets prohibitively expensive as the number of disks grows.
And of course, there's the issue of being able to find an individual users sweet spot between storage space, reliability, and the physical space to mount disks in a chassis.
Posted Aug 25, 2017 3:24 UTC (Fri)
by drag (guest, #31333)
[Link] (12 responses)
With 4TB drives being less then 100 dollars now you get 8TB for less then $400 or 16TB for less then $800. The per-drive expense of storage like that is far less of a concern then it used to be and other factors tend to matter more. If you are trying to get work done on a system rebuilding a array then the time to recover can easily stretch out to multiple days.
If somebody has their heart set on RAID5 then that's fine, but I still consider it ill-advised.
Posted Aug 25, 2017 19:17 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link] (2 responses)
Posted Aug 28, 2017 15:07 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
Cheers,
Posted Aug 28, 2017 17:26 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link]
Right, I was writing from the perspective of 'nested' RAID10, not the 'complex' version. With 'complex' RAID10 you would have guaranteed partial data loss on failure of any two drives, since the data stripes are distributed across the drives and—for an array of four uniformly-sized disks, as we've been discussing, which doesn't really need to be 'complex'—the two failed drives would be the sole mirrors for approximately one-twelfth of the stripes.
Whether a guaranteed 8% data loss (given a second drive failure) is better or worse than a 1/3 chance of losing 50% of the data will, I suppose, depend on your use case. However, do consider that if the 8% includes critical metadata (and it probably will) then the remainder, while still technically "present", may still be unrecoverable in practice.
Posted Aug 26, 2017 3:14 UTC (Sat)
by ttelford (guest, #44176)
[Link]
Not all applications are terribly sensitive to performance. A lot of the classical file servers have files that are effectively static - with occasional updates.
A home media server is another example: you can record multiple channels of 1080 video (Using ATSC / MPEG-2), and playback multiple recordings simultaneously, without skipping. Why target performance (which you don't need), and sacrifice storage space (which you do need).
Ther is simply no one size fits all solution; it's all a compromise. I personally use RAID6 when performance isn't a problem.
Posted Aug 26, 2017 8:20 UTC (Sat)
by Otus (subscriber, #67685)
[Link] (7 responses)
Really? Recovery is something that needs to be done rarely. As long as it can be done in the background without interruption I cannot see the problem, even if it takes days.
I also don't see why RAID 1 recovery should be significantly faster. Whenever you lose one disk you need to rewrite one disk, in any RAID mode. With RAID 5 you need to read double the data, but does that really make that much of a difference in practice?
(Finally, with 4 disks instead of 3 in an array, you will get a drive failure about a third more often.)
Posted Aug 26, 2017 12:43 UTC (Sat)
by SampsonF (guest, #118216)
[Link] (6 responses)
When one drive failed, and once it started to rebuild, it created high volume of disk read/write activities for long duration of time. Thus surge of disk activities in turn increase the likelyhood of failure in the remaining disks.
That is why sometimes Mirroring or RAID1 is feasible for some usage case.
Posted Aug 26, 2017 16:30 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (3 responses)
So why do we regularly get stories about arrays falling over? Maybe because home users (and bean counters) don't think checking the health of the system is important?
Cheers,
Posted Aug 30, 2017 12:28 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Aug 30, 2017 22:47 UTC (Wed)
by jwarnica (subscriber, #27492)
[Link] (1 responses)
"Enterprise" hardware, and software should not catastrophically fail without warning that comes out of the box, and for sure not fail totally before shipping kicks in.
Posted Aug 31, 2017 13:33 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
But a company I know of bought a commercial raid-6 array. Cue a massive panic a couple of years down the line when an operator suddenly noticed two red lights indicating a double drive failure. Nobody'd been checking the raid.
So they had people who were supposed to be looking after it. So it did try to tell them something was wrong. And still they just dodged a catastrophic failure by pure luck rather than judgement.
Cheers,
Posted Aug 26, 2017 21:14 UTC (Sat)
by zlynx (guest, #2285)
[Link] (1 responses)
Posted Aug 28, 2017 15:10 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Aug 25, 2017 1:39 UTC (Fri)
by ttelford (guest, #44176)
[Link]
Snapshots are highly useful for everyone. Most "new" users start with a Linux desktop, and snapshots are useful for those little "oops" moments that come with learning.
Posted Aug 25, 2017 4:21 UTC (Fri)
by raegis (subscriber, #19594)
[Link]
* snapshots for the usual stuff
Posted Aug 28, 2017 11:55 UTC (Mon)
by Hanno (guest, #41730)
[Link] (1 responses)
I really want to see a really really simple and painless way to have multiple generations of snapshot backups on my desktop. I haven't used btrfs yet, but was under the impression that this is its promise to desktop users.
Posted Sep 1, 2017 7:35 UTC (Fri)
by niner (subscriber, #26151)
[Link]
Posted Aug 24, 2017 20:30 UTC (Thu)
by Depereo (guest, #104565)
[Link] (1 responses)
Don't bring your support of Trump into LWN, please.
Posted Aug 25, 2017 7:57 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Posted Aug 25, 2017 8:00 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
That's what the muppets at SCO and Oracle (and a lot of Debianists unfortunately) never understood. They think free software = gratis software, RHEL is expensive, RHEL is a scam.
Meanwhile the market stayed largely clear of their cheaper-than-RedHat-with-no-demonstrated-ability-to-fix-things alternatives.
Posted Aug 24, 2017 15:35 UTC (Thu)
by SEJeff (guest, #51588)
[Link] (8 responses)
https://access.redhat.com/documentation/en-US/Red_Hat_Ent...
From a feature perspective, I think bcachefs is the new hotness in place of btrfs: http://bcachefs.org/
Posted Aug 24, 2017 16:16 UTC (Thu)
by drag (guest, #31333)
[Link] (6 responses)
I don't have any experience with his previous project, bcache, but it seems to have been successful.
Posted Aug 24, 2017 22:52 UTC (Thu)
by vstinner (subscriber, #42675)
[Link] (5 responses)
I am a happy user of btrfs. I like snapshots to recover files if I make a mistake l already lost and recovered from a snapshot photos of a travel to Japan). I recently enabled raid1 (plug a second disk) with 400 GB of data. It's done in two trivial commands in 2 hours (likely maximum write speed of my HDD). I love data checksum to check if my photos are still there! I never lost any file. I never had any major issue with btrfs in 3 years. No idea why some people speak about data loss? It's common that I turn off this server by holding the power button 4 seconds :-) btrfs has a fsck tool, no? (I didn't check since I had never any issue.)
Posted Aug 28, 2017 9:45 UTC (Mon)
by anton (subscriber, #25547)
[Link]
Posted Aug 29, 2017 3:59 UTC (Tue)
by thoughtpolice (subscriber, #87455)
[Link] (3 responses)
Also, bcachefs is as much a clone of btrfs as btrfs is of ZFS -- they're all "next-gen" filesystems, but naturally they all have different points in the design space. For example, it features very efficient metadata overhead, in some cases leaving to order-of-magnitude improvements over others (because metadata can effectively fit in your L2 cache -- a user on IRC once reported bcachefs vs <anything else> was something like 500,000 files/s vs < 70,000 files/s, in a directory with a few hundred thousand files.) bcachefs also has very good tail latency compared to most systems because it doesn't block necessarily.[1]
Finally, one of the biggest features is bcachefs is it is portable by design. It already builds in userspace on Linux (the same code that is built into the kernel module) and Kent is working on FUSE bindings. It seems likely at some point bcachefs will likely end up on other operating systems quite easily (even Windows or OS X.) This feature also dovetails nicely with e.g. out-of-the-box encryption (no dm-crypt), meaning any system will have native encryption support.
I'm much more excited for bcachefs than I was for btrfs, if it can fix some of its flaws like the above.
Posted Aug 29, 2017 5:40 UTC (Tue)
by kreijack (guest, #43513)
[Link] (2 responses)
Due to the fact that the snapshot feature is missing, it is normal that bcachefs has better performance. The snapshot capability has a big impact on the performance (e.g. each block have a reference counter which has to be update, when a block is created, changed or deleted). I think that we could discuss about the bcachefs performance after it has a comparable set of feature.
Posted Aug 30, 2017 0:33 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link] (1 responses)
Anyways, snapshots aren't the only feature users care about. At this rate, bcachefs is going to have proper working RAID before btrfs.
Posted Aug 30, 2017 16:59 UTC (Wed)
by kreijack (guest, #43513)
[Link]
You are right when you say that I don't know the bcachefs internal, however it still not correct to compare the speed of filesystems when the features aren't comparable.
Anyway I am curious how the snapshot are implemented in bcachefs. Could you share with us more details ? How is scalable the bcachefs solution (btrfs behave well with ~100 snapshots, and with some limits is tolerant with 1000 snapshots)
> Anyways, snapshots aren't the only feature users care about.
I can't comment about prediction. I hope that bcachefs will be a good filesystem.
Posted Aug 25, 2017 11:34 UTC (Fri)
by walex (guest, #69836)
[Link]
The author of 'bcachefs' has written his impression in a previous comment on LWN.net:
https://lwn.net/Articles/656004/>
> How does bcachefs beat btrfs?
Posted Aug 25, 2017 6:36 UTC (Fri)
by richard77 (guest, #117898)
[Link]
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
> choose between paying royalties to a hostile third party or eating the cost of maintenance of the project.
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
>Evidence is stacking up that BTRFS is broken unless they are willing to make significant changes to the on-disk format, which would essentially necessitate a 'btrfsv2' since that is a dramatic thing. SUSE reaffirms support for Btrfs
Do you have backup for this statement, I would be very interested in reading it. I've been using btrfs on a backup server for about 2 years and have had no issues.
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
Wol
SUSE reaffirms support for Btrfs
> currently-seeking-employment developer of Bcachefs, Kent Overstreet, and
> help him get his project up to the point where it can be made ready for
> inclusion into the kernel. It has a lot of promise.
> going to be quite awhile before I can dedicate enough time to finishing them, but
> I'm very much looking forward to showing off what it'll be able to do."
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
Evidence is stacking up that BTRFS is broken unless they are willing to make significant changes to the on-disk format, which would essentially necessitate a 'btrfsv2' since that is a dramatic thing. Hopefully this is not the case, but time will tell. SUSE reaffirms support for Btrfs
I definitely don't know enough to say whether the on-disk format is broken, but there are other issues.
Software RAID with BTRFS was known to be broken - RAID 5/6 was supposedly re-introduced with kernel 4.12. It'll take a lot more than an announcement that they fixed it to convince me btrfs won't eat my disks this time around.
Running out of space on BTRFS is frequently fatal - doubly so if you don't recognize that you've run out of space before trying something else.
It's very non-obvious when you've run out of space with BTRFS - I have yet to see the typical "filesystem out of space" errors, and other programs are similarly confused - instead of being told the filesystem is out of space, programs receive no warning at all, instead simply waiting until there's a write timeout.
I've spent a few long days & nights recovering a btrfs filesystem that went south for no apparent reason (failure was not due to the usual suspects: RAID 5/6, a power failure, running out of space, and so on). A sane person would have just created a new filesystem and restored from backup, but I decided I wanted to learn to recover BTRFS. The good news is that there were viable snapshots (yay COW!), and I was actually able to recover all of the data from the snapshot, and its checksums were valid. (The filesystem was still horked, of course -- I had to copy the data to a working filesystem, and then delete & re-create the horked btrfs)
I've been more than a little forgiving of BTRFS, and have been testing and using it for years at this point. BTRFS has promise, I want it to succeed... but it's dissapointed me enough that I have no reservations saying BTRFS should only be used with great caution
For anything mission-critical, I use ZFS (and give the system gobs of RAM).
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
Wol
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
> [...]
> If you are trying to get work done on a system rebuilding a array then the time to recover can easily stretch out to multiple days.
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
Wol
SUSE reaffirms support for Btrfs
A sysadmin will do scrubs, will monitor SMART etc, and won't be surprised by a disk failure...
Your assumption that scrubbing and SMART will reliably detect disk failures is not very accurate. There are sudden failures, for starters, where the drive works until it suddenly doesn't: but also SMART is not terribly reliable at the best of times, and scrubbing is more to guard against slow magnetic degradation than to discern whether the drive is on its way out.
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
Wol
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
Wol
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
* snapshots for lxc: I create base containers with btrfs storage and clone to make
several more--saves a tremendous amount of disk space
* btrfs send/receive for cheap incremental backups (the KILLER feature, IMO)
* Upgrade from Debian Jessie to Debian Stretch: debootstrap into a new subvolume and set it as the default for the root filesystem (btrfs subvol set-default ...) I think this is cool.
* Encrypted device-backed loop: I've experienced no issues with power loss using btrfs. In my experience, ext4 was not as robust.
* and more!
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
A properly done journaling or COW file system does not need an fsck to recover from a power outage or kernel crash. The value of an fsck in other circumstances is also dubious; nevertheless, there is "btrfs check", although there are other options you should try first.
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
> points in the design space. For example, it features very efficient metadata overhead, in some cases leaving to order-of-magnitude
> improvements over others (because metadata can effectively fit in your L2 cache -- a user on IRC once reported bcachefs vs
> <anything else> was something like 500,000 files/s vs < 70,000 files/s, in a directory with a few hundred thousand files.) bcachefs also
> has very good tail latency compared to most systems because it doesn't block necessarily.[1]
SUSE reaffirms support for Btrfs
SUSE reaffirms support for Btrfs
> how they're going to be implemented in bcachefs.
> At this rate, bcachefs is going to have proper working RAID before btrfs.
Anyway on of the biggest problem in BTRFS is the huge number of features and their combinations. The most difficult thing is verify that BTRFS behave "not so bad" in every combination.
SUSE reaffirms support for Btrfs
Compression used to be quite buggy until recently, and defrag and dedupe seem to work mostly but they have very unpleasant (and unavoidable) corner cases.
"Multidevice" support I think was fundamentally misdesigned as evidenced by a long history of bugs and very odd and common "corner cases", and I suspect it will never be properly fixed short of rewriting. The RAID10 mode is the best of the bunch.
My impression is that the Btrfs authors though that a Microsoft-like marketing strategy, that is lots of feature, even if buggy, was the best approach. I suspect that works for applications, but not for critical bits of infrastructure.
> Posted Aug 28, 2015 16:48 UTC (Fri) by koverstreet (subscriber, #4296) [Link]
> "large log structured b+ tree nodes over regular b+ tree nodes" - that's
> a large part of it. But really it mostly comes from working slowly, focusing
> on the design of the lower layers, keeping things clean and simple. It's been
> over 5 years to get to this point.
> Btrfs tried to do too much (in LOC) too quickly; they've got way too much
> code now and too many bad design decisions are baked in.
SUSE reaffirms support for Btrfs
Redhat stated they will open source Permabit technology.