What about defult Btrfs on elementary luna ?

Btrfs seems to be the new hotness, but production issues aside, it's for servers. elementaryos is about the common user. However, if a user wants Btrfs, they have all the power to implement it that exists in Ubuntu.

Hey Emre, I felt guilty about my short answer so I've come back to explain a bit more detail.

As different as elementaryos is, we try to keep as much in common with upstream Ubuntu as we can. This avoids adding more hassle to our already limited and stressed out integrator(s).

That's not to say that we don't deviate from Ubuntu all the time, but the more we do the harder it is to keep up with what we have changed considering the limited amount of team members with expertise to do so we have. So we have to make every change count.

In the case of switching the default file system from upstream, we would have to apply the same logic Ubuntu has in choosing theirs and find a different answer. Btrfs taxes the operating system more than what's considered reasonable when only a small percentage of users (less than 1%?) would see the benefit.

That's not to say Btrfs will never become the default file system. Ubuntu could switch to it tomorrow, but they have far more resources than us to determine that it's a good decision.

Please don't be discouraged, keep your ideas flowing. Satisfying users is why we do what we do, but in this case the needs of the many outweigh the needs of the few.

I've watched that vid too, and I'm quite enthusiastic about BTRFS. However, there are still several blockers to using BTRFS by default in elementary OS:
- Even in the latest version it's still slower than ext4 on most workloads (http://www.phoronix.com/scan.php?page=article&item=linux_33_btrfs&num=1), not to mention the situation in 3.2 kernel which is used in Precise (http://www.phoronix.com/scan.php?page=article&item=linux_32_nilfs2&num=1)
- It's not small-disk-friendly (that's mentioned in the video above). On a 4Gb SSD it can gobble up a whole gigabyte just for storing metadata. This means we'll have to implement a graceful fallback to ext4 if the expected installation size is little. We don't have the manpower to test and debug that, and that's not our area of expertise. Such changes really should be done in Ubuntu.
- Nobody has created GUIs to the features exposed by BTRFS (except SuSE in YaST, but we can't really use that), left alone integrating those features with the whole user experience.

I agree with Cody - right now BTRFS is for servers. Features like snapshots, transparent compression and multi-root support are not easy to present to the user in a convenient way. E.g. NTFS snapshots are a miserable fail design-wise, + we're moving away from exposing the filesystem to the user anyway.

The way I'd like BTRFS to work (and the only condition when we might consider deviating from Ubuntu in such a core component) is if BTRFS gets per-file time machine features.
When using a time machine, I usually don't care what the file looked like a month ago. I want to know how the file looked 1 hour ago, 2 hours ago, or yesterday, and I want to see ALL revisions which were there, not play a russian roulette with file history. NILFS2 is moving in that direction, but it still doesn't have per-file history, and it's too slow for real use at the moment.
But according to Avi's presentation, BTRFS already uses something like that internally for data recovery. If they'd just create a library with basic functions like listing available versions of a given file and accessing them, we could handle the rest.

By the way, would you be so kind to post this idea to BTRFS mailing list? It could move the idea closer to implementation ;)

Hello again. thanks for the answers.

i disagree with the idea that BTRFS is for servers. if you noticed, %90 of people who are actively testing, want it for their daily use. but i agreed the rest of it. its hard to support it with limited human power.

and Sergey, time machine per file is a great idea. i sended to Btrfs mail list. i hope they consider this.

Umm, Why?