OpenSUSE Looks To Switch To Btrfs For Next Release

[HeavensRevenge]

Valerie Aurora said, in the mentioned lwn article, that that is why, in the past, btrees and COW were thought to be ill wed to one another. That's why they aren't using btrees, but modified btrees (according to ohad rodeh's paper "B-trees, shadowing and clone") to avoid this problem.

Well, of course it's something I thought they would have avoided but there's countless reports of people saying their BTRFS installations slow to grinding haults ~4 months after installation and simply migrating to EXT4 makes them feel magnitudes faster. Also there was a nice presentation of a dev showing a scatter-plot of disk access times and how BTRFS exponentially degraded over a 22 hour test of hardcore usage and stressing the FS for metadata-intensive workloads.
http://opensuse.14.x6.nabble.com/Btr...td4994291.html is a good record of many people confirming this exact problem manifesting and that they did NOT get this right.

You clearly have never used Btrfs.

Of course I have, but always only for testing and I never used it long term beyond 2 weeks or so. You're all bigger men than I am to trust my root to BTRFS that's all I've got to say, and I experiment with some pretty crazy stuff like distcc distributed compiles lol, but no way would I ever trust my data to BTRFS at this moment of it's lifetime.

[Luke_Wolf]

13.1 comes after this one, 12.3. So does 13.2. It doesn't come before 12.3.

Did you read the dictionary definition I linked to you? If you don't like Merriam-Webster here's Oxford

http://oxforddictionaries.com/us/definition/american_english/next?q=next

next
Syllabification: (next)
Pronunciation: /nekst/
adjective

1(of a time or season) coming immediately after the time of writing or speaking:we’ll go next year next week’s parade
(of a day of the week) nearest (or the nearest but one) after the present:not this Wednesday, next Wednesday [postpositive]n Monday next
(of an event or occasion) occurring directly in time after the present or most recent one, without anything of the same kind intervening:the next election next time I’ll bring a hat

2coming immediately after the present one in order, rank, or space:the woman in the next room the next chapter building materials were next in importance

adverb

on the first or soonest occasion after the present; immediately afterward:wondering what would happen next next, I heard the sound of voices
[with superlative] following in the specified order:Joe was the next oldest after Martin

noun

the next person or thing : one moment he wasn’t there, the next he was the week after next

preposition
archaic

next to:he plodded along next him

As we can quite clearly see from both Merriam-Webster and Oxford "Next" is NOT a general future term but a very very specific one. In the context we're speaking of (definition 2 under adjective): the one immediately after the current. Now it is possible to make it refer to a range and even a vague range but that requires more words.
I.E. "openSUSE is looks to switch to Btrfs at some point over the next few releases" instead of "openSUSE looks to switch to Btrfs for next release".

As a result when we say "the next release of openSUSE" we are only referring to 13.1, and until the release of 13.1 it will never mean 13.2, at which point it will not include 13.3 and so on.

Also note that even with the meaning of being a single one after the current one, 13.2 is the next development version.

Do you see anywhere in his article that is indicating he's talking about the next development version? Does the number 13.2 or the term "development version" even come up once? The answer to these is no, infact

ftfa:

In today's openSUSE 13.1 Beta announcement, it was revealed about making Btrfs "the default on the next openSUSE."

In order to promote testing of Btrfs, the openSUSE 13.1 Beta today is encouraging users of new installs to test the file-system over EXT4 by having a "want to test Btrfs?" pop-up dialog during the new installs -- but that will be dropped for the final 13.1 release.

OpenSUSE would be looking at shipping Btrfs as the default for the next openSUSE release with enabling only safe file-system options by default [...] as posted in the 13.1 Beta 1 announcement.

all of these rather clearly indicate that he's talking about 13.1, and the only line you could potentially even argue in his favour is this one

It looks like in 2014 we may finally see Btrfs entering the spotlight as being the production-ready next-generation Linux file-system.

Except that 13.1 will be released in late November thus with the understanding that 13.1 would make Btrfs the default would set up for 2014 to be the year it enters the spotlight. Sure you can absolutely argue that it's referring to 13.2 but you can't argue that it could not also be referring to 13.1

[liam]

Well, of course it's something I thought they would have avoided but there's countless reports of people saying their BTRFS installations slow to grinding haults ~4 months after installation and simply migrating to EXT4 makes them feel magnitudes faster. Also there was a nice presentation of a dev showing a scatter-plot of disk access times and how BTRFS exponentially degraded over a 22 hour test of hardcore usage and stressing the FS for metadata-intensive workloads.
http://opensuse.14.x6.nabble.com/Btr...td4994291.html is a good record of many people confirming this exact problem manifesting and that they did NOT get this right.

Btrfs gives you many options as to how to do things. For instance, you CAN store your data and metadata in the same nodes for greater locality/space-efficiency but the docs say you should do this only for small filesystems (under 1G, iirc). If someone used that option, for instance, for a larger fs then that could lead to serious performance issues. My point is that the data from that link wasn't giving us much detail. There are many issues with btrfs that are WELL documented but I'd not look to that thread for them (i.e., we don't know what version of btrfs-progs they used, what option they used for volume creation---that is hugely important).
Do you have a link to that dev's data where he was stressing the fs? Was it on the btrfs ml?

Of course I have, but always only for testing and I never used it long term beyond 2 weeks or so. You're all bigger men than I am to trust my root to BTRFS that's all I've got to say, and I experiment with some pretty crazy stuff like distcc distributed compiles lol, but no way would I ever trust my data to BTRFS at this moment of it's lifetime.

I've used btrfs a few different times (currently I've had it as my root partition for ~one year and haven't had any real issues, iirc. I performed a scrub last night for the first time, and it came back with everything perfect (only took around two minutes). To prevent issues with filling up the disk, I mount it with autodefrag and that seems to give available and free space very similar values.
While I don't mind running it on root, I'm not quite to the point where I've trust it with my home data, at least until I get complete backups. Fixing root problems isn't that hard, even if that includes wiping it and imaging from a known good root with a live distro. However, my understanding is that it is quite unusual for btrfs to get to that state (i.e., the tools for recovery at least A root node are quite good).

Mason isn't stupid. He's an experienced fs developer so I'd trust him. Obviously there are problems, and I think that the whole filesystem development community should change practices to, as another poster has said in another thread, first, using verification tools to make sure the core ideas of the fs make sense. To THEN move to implementation through a fuse/kernel fs. Something like a fs really needs to be used with tools like alloy, but oss hasn't really embraced such practices yet.

[ryao]

I think that the whole filesystem development community should change practices to, as another poster has said in another thread, first, using verification tools to make sure the core ideas of the fs make sense. To THEN move to implementation through a fuse/kernel fs. Something like a fs really needs to be used with tools like alloy, but oss hasn't really embraced such practices yet.

ZFS already does this. The entire filesystem is compiled for userland and is exercised with a tool called ztest. It is able to rapidly simulate random failures in userland. So far, I am not aware of any other filesystem that does this.

[liam]

ZFS already does this. The entire filesystem is compiled for userland and is exercised with a tool called ztest. It is able to rapidly simulate random failures in userland. So far, I am not aware of any other filesystem that does this.

You missed the formal verification part (hence the use of alloy).
What you've described provides no such guarantees.

[ryao]

You missed the formal verification part (hence the use of alloy).
What you've described provides no such guarantees.

The largest piece of formally verified kernel software that is seL4, which is roughly 10,000 lines:

http://www.ertos.nicta.com.au/research/sel4/

Filesystems often have 100,000 lines and are not isolated components. Formal verification of the filesystem code would require formal verification of the rest of the kernel. At that point, the amount of code that requires formal verification is on the order of 10 million lines. It is infeasible with current techniques.

With that said, you said verification, not formal verification. The two are different. One can be done with rigorous testing. The other is currently a pipe dream.

[liam]

The largest piece of formally verified kernel software that is seL4, which is roughly 10,000 lines:

http://www.ertos.nicta.com.au/research/sel4/

Filesystems often have 100,000 lines and are not isolated components. Formal verification of the filesystem code would require formal verification of the rest of the kernel. At that point, the amount of code that requires formal verification is on the order of 10 million lines. It is infeasible with current techniques.

With that said, you said verification, not formal verification. The two are different. One can be done with rigorous testing. The other is currently a pipe dream.

I said verification, I then said using a tool like alloy. I don't feel like pointing out yet another aspect of my post that you missed. Since you care more about scoring petty points than listening to another person I'm not responding to this thread any further.

[kernelOfTruth]

hm,

btrfs makes great progress & it survived 1-2 hardcrashes for me (where in the past I would get data corruption or lost files), that even on /home


at least after the following (and some other most recent ones) patch it should be somewhat good to go in the data integrity department: http://marc.info/?l=linux-btrfs&m=137993254917058&w=2

I actually expected it to do that already from the beginning or for some time

but apparently I was proven wrong


not sure how this couldn't have been detected earlier
(was a shocking discovery, in a negative way, for me at first - but it can only get better, can't it ?)

great work by Filipe David Borba Manana

[ryao]

I said verification, I then said using a tool like alloy. I don't feel like pointing out yet another aspect of my post that you missed. Since you care more about scoring petty points than listening to another person I'm not responding to this thread any further.

liam, telling others how to do things will always end in failure because you are the only person in the world competent enough to implement your vision. If you want things to get done, you will need to spend your time doing them yourself instead of posting on forums in the vain hope that one of the incompetent masses will somehow manage to do what you want.

With that said, I look forward to seeing the results of your work.

[ryao]

hm,

btrfs makes great progress & it survived 1-2 hardcrashes for me (where in the past I would get data corruption or lost files), that even on /home


at least after the following (and some other most recent ones) patch it should be somewhat good to go in the data integrity department: http://marc.info/?l=linux-btrfs&m=137993254917058&w=2

I actually expected it to do that already from the beginning or for some time

but apparently I was proven wrong


not sure how this couldn't have been detected earlier
(was a shocking discovery, in a negative way, for me at first - but it can only get better, can't it ?)

great work by Filipe David Borba Manana

If btrfs had an analog to ZFS' ztest tool, this would have been caught a long time ago.

With that said, I just passed on the link to the Gentoo kernel team. Thanks for posting it.