Originally posted by numasan
View Post
Announcement
Collapse
No announcement yet.
Btrfs File-System Updates For Linux 4.6
Collapse
X
-
How much has Btrfs matured the past year(s)?
How does Btrfs compare against ZFS nowadays?
Leave a comment:
-
Originally posted by dweigert View PostI 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...
Leave a comment:
-
Originally posted by SyXbiT View PostExactly. 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.
- Likes 1
Leave a comment:
-
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...
- Likes 2
Leave a comment:
-
Originally posted by waxhead View PostBTRFS have been a "playground" for almost a 10 years now,
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.
Leave a comment:
-
Originally posted by waxhead View PostAnd yes, I am aware that btrfs is basically developed like that...
Leave a comment:
-
Originally posted by Ericg View Post
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.
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.
- Likes 2
Leave a comment:
Leave a comment: