Btrfs In Linux 4.4 Has Many Improvements/Fixes

[cynic]

Yes, but the question is can you trust a Btrfs filesystem with your data in the same way you trust ext4? Given the continued shaky state of ZFS on linux, I'm more than ready for someone to answer that question with a yes (but haven't heard it yet).

Well, even ext4 and XFS still have bugs after decades of developement and usage!

That said, is very hard to tell when and for what a filesystem is ready / suitable. I've been using BTRFS for years now, and the latest release have become quite stable.
Do I trust BTRFS as ext4 or XFS? actually not, but I trust it enough to use it on every workstation I use every day. I just backup often (as I do with all the other FS, btw)

[drSeehas]

... FreeNAS box. If you truly value your data, I think it's the only viable (open) option right now.

What about NAS4Free?

[darkbasic]

The RAID write hole phenomenon is not specific to RAID 5.

AFAIK this is not a problem for btrfs raid 1, only raid 5 and 6. At least that says the wiki.

[Lltp]

While you've given yourself a nice out with your phrasing, I'd counter with sel4.

Sel4 is only followed by 9 contributors and "watched" by a hundred+ of people. It started only a bit more than a year ago and I can read stuff like:

> Handle spurious IRQs correctly on the PIC

or

> Fix missing include

or

> Fix directory listing

and there are plenty of other ones (not all containing "fix" in the name, but looking at the code it is just crystal clear that these are not just feature additions).

Just look at their github commit history: having no issues listed means that no one bothered to create one, you supposed this is because the code is bug-free but the history of commits shows this is wrong.

While there is no theoretical proof that ANY code will contain bug, there are empirical evidences that this is the case.

[Lltp]

As a complement:

http://programmers.stackexchange.com/questions/195571/is-it-possible-to-reach-absolute-zero-bug-state-for-large-scale-software

The only way to be perfectly sure is to prove your program (mathematically). But remember that even if you do that, that's assuming that the OS, the linked libs and the hardware are bug-free... Your program can work perfectly well taking ASCII strings as an input, but the day a bitflip occurs, your program crashes.

[pal666]

The only way to be perfectly sure is to prove your program (mathematically). But remember that even if you do that, that's assuming that the OS, the linked libs and the hardware are bug-free...

and assuming that your proof is bugfree

[liam]

Sel4 is only followed by 9 contributors and "watched" by a hundred+ of people. It started only a bit more than a year ago and I can read stuff like:

> Handle spurious IRQs correctly on the PIC

or

> Fix missing include

or

> Fix directory listing

and there are plenty of other ones (not all containing "fix" in the name, but looking at the code it is just crystal clear that these are not just feature additions).

Just look at their github commit history: having no issues listed means that no one bothered to create one, you supposed this is because the code is bug-free but the history of commits shows this is wrong.

While there is no theoretical proof that ANY code will contain bug, there are empirical evidences that this is the case.

I was referring to this: https://sel4.systems/Info/FAQ/#l4vv
So, for the kernel does what it was intended to do: a specification was created that was proven to "enforce integrity and confidentiality " and the implementation was verified to adhere to the specification. In that sense, it is bugfree.

[SystemCrasher]

Yeah. I'll be more excited when I read an article saying "Btrfs In Linux X.Y Has One Small RFE and No Fixes, Cut It's All Stable And Shit Now"

I wonder if FAT16 is okay for you already . Feel free to use MS-DOS: it would never get fixes anymore. So it so damn stable, etc...

And while code quality could vary a bit from person to person, code size and complexity matters. And you see, we do not want to stick to dead simple FAT16. Sure, it much easier to implement. But it also lacks features and comes with shitload of shortcomings. Say, good luck to put 50 000 files in single dir. And have fun trying to browse it on designs similar to fat. That's where we get first serious complication: we need directory indexing. I.e. b-tree or hash table. With rather harsh requirements on all aspects of operation. And this makes design far more complicated in one shot. But it also improves performance quite a lot. Then we can get idea extents are much better than bitmaps or lists in terms of performance in typical use cases. Then we could want snapshots. Or data compression. Or checksums. Or options to manage storage capacity without shuffling 20Tb of data each and every time we want to change something, because moving 20Tb of data assumes you have another storage of same size, and takes considerable time. So we do not want to manage 20Tb storages in MS-DOS-aged ways anymore.

Btrfs comes with far more advanced features. And so there're more code. Whether it's quality of code is worse than that of other software is highly debatable. I do not know, probably nobody attempted to measure it with such granularity so far. But Linux kernel as whole is known to have lower average error rate per KLOC compared to other software. In fact, Linux kernel is huge but still surprisingly stable, even in -RC branches. Good luck to do it better. It is 2015 and only few persons would agree to stick to DOS and FAT16.

[horizonbrave]

What is not ready are the distros: how many adopted btrfs by default? Come on...

[SystemCrasher]

So, for the kernel does what it was intended to do: a specification was created that was proven to "enforce integrity and confidentiality " and the implementation was verified to adhere to the specification. In that sense, it is bugfree.

Sure thing. Feel free to use it instead of Linux, Windows, MacOS, etc. There is one small catch though: this kernel is nearly useless on its own. And when you'll add all hardware drivers, code to deal with advanced filesystems and all sorts of gooies people expect from modern operating system, you will suddenly figure out system haves so many possible states and formal specification is so long and complex that you can't prove anything about it and it ends up full of bugs. SEL4 guys just cheated a bit and avoided all hard parts, because it is microkernel.

Sure thing, even mediocre student can code more or less bug-free task switcher which isn't far from SEL4 in terms of features and bugs. But I wish you luck to implement all features Linux haves today, but without bugs. I've also heard stories it should be easier to write drivers for microkernel OSes. I've heard it for something like 20+ years or even more. And now.... where is Minix? Where is Hurd? And where is Linux? So, it seems it wasn't easier when it comes to practice. I bet same thing happens to bugs as well.