Btrfs File-System Updates For Linux 4.6

[phoronix]

Phoronix: Btrfs File-System Updates For Linux 4.6

The Btrfs file-system updates for Linux 4.6 are not particularly exciting this round...

http://www.phoronix.com/scan.php?pag...trfs-Linux-4.6

[aksdb]

"not particularly exciting"? The fact that there are not many changes IS exciting. Because that begins to show stability.

[Ericg]

"not particularly exciting"? The fact that there are not many changes IS exciting. Because that begins to show stability.

It also means no FS-level encryption and no dedup work. Both of which are features that a lot of people are looking forward to.

[darkbasic]

"not particularly exciting"? The fact that there are not many changes IS exciting. Because that begins to show stability.

No it's not exciting: I would like proper RAID 5 without write hole

[waxhead]

It also means no FS-level encryption and no dedup work. Both of which are features that a lot of people are looking forward to.

True, but I think more people are looking forward to having something a bit more stable soon. BTRFS have been a "playground" for almost a 10 years now, and while horror stories about dataloss for single disk filesystem and raid1 are starting to get rare there are still a few weird ones on the mailing list.

People who are mildly paranoid about the integrity of their data are naturally drawn to filesystems like BTRFS. I do have a 16 terrabyte ext4 filesystem running on mdadm6 and for that reason alone I don't subscribe to either the ext4 or mdadm mailinglists

I do subscribe to the BTRFS mailing list tough and from what I have seen so far, including my own tests raid5/6 is in a pretty horrific state. I have tested on a 10x 8GB USB memory stick RAID and with mdadm I have not been able to destroy any raid5 or raid6 array. I Have corrupted data, but never lost an array. With BTRFS I did easily corrupt data AND destroyed the array in minutes (only tested on kernel 4.2 and below)

So at least for me a non-exciting change log for the kernel means less features, more fixes, and I feel pretty confident that I think the priorities for BTRFS now should be prioritized something like this:

1. Array recovery and reconstruction
2. Filesystem recovery and reconstruction
3. Data recovery and reconstruction
4. Raid1
5. Raid5/6
6. "Raid" with n parity devices
7. Performance
8. "online" deduplication
9. encryption
10. other features

For the BTRFS devs it should also be benficial to get the basics as stable as possible. Why? because if raid1 for example is declared stable more people will use it. When more people use it you get a broader user base. When the users stop yelling at "stable" features the devs can start add other fancy stuff. As they add stuff, the broader the use base will be and the more people will test new things and yell if they don't work... when all the yelling is reduced to a single person clearing his throat I think we have a pretty stable filesystem.

And yes, I am aware that btrfs is basically developed like that.... reliability should always come first in my opinion.

[CrystalGamma]

And yes, I am aware that btrfs is basically developed like that...

Well Linux in general is developed like this, not just btrfs … but because unlike e. g. graphics, filesystems are persistent, people have especially high expectations of stability.

[SyXbiT]

BTRFS have been a "playground" for almost a 10 years now,

Exactly. Developed for nearly 10 years, and most people still wouldn't trust it with their data. I've been hoping for a ZFS competitor for years.
BTRFS is to ZFS what HURD is to Linux. A research project that aims to be better than the stuff we all use in production, but don't.

[dweigert]

I have something over 5000 instances of BTRFS running as the root filesystem on SLES11 and 12 - on multiple architectures (x86_64 and s390x). Weirdest issues I've seen is people filling it up and wondering what happened...

[jacob]

Exactly. Developed for nearly 10 years, and most people still wouldn't trust it with their data. I've been hoping for a ZFS competitor for years.
BTRFS is to ZFS what HURD is to Linux. A research project that aims to be better than the stuff we all use in production, but don't.

It seems Facebook, at least, does trust it with their data. The BTRFS development process has been a huge fiasco, no question about that, but it still puzzles me that people who dismiss it altogether usually look up to ZFS, which has been stable... on solaris (not to mention its less than stellar design).

[numasan]

I have something over 5000 instances of BTRFS running as the root filesystem on SLES11 and 12 - on multiple architectures (x86_64 and s390x). Weirdest issues I've seen is people filling it up and wondering what happened...

I'm curious, what is the advantage of using BTRFS over EXT4 or XFS on the root filesystem? Or is it just because BTRFS is default for SLES?