What’s the plan for btrfs now that redhat have announced its’ deprecation on RHEL?
Randall.
@Randall_Crook Welcome to the Rockstor community.
Pretty sure it’s only ever been a technology preview on RHEL so we haven’t really lost anything. Rockstor has always used much newer kernels (elrepo-ml) and compiled newer upstream btrfs versions for itself (for the user land components), given those ‘as standard’ in CentOS have always been too old to be viable. So no change for us really. And Suse Linux Enterprise Server / Open Suse is still going strong on their default install of btrfs and Facebook are steadily increasing their use of btrfs from a recent value of 20% of fleet. A more interesting question is what are RHEL going to do to supply the facilities that currently only btrfs can provide, ie those coming from block pointer rewrite etc. Especially for the smaller type installs. Apparently they are asking the community for suggestions. If throwing out the current best fit because it’s not quite there yet was adopted by science then we would have non.
All things take time and although I’m a huge RedHat fan I don’t think they are making the right decision on this one, but then they have been more about Ceph and larger storage offerings. Although I’m hoping to follow their and Facebook’s example more on the Glusterfs side of things; when time and resources permit.
3 Likes
My 2 cents for all:
RH deprecating btrfs? Yep, but we don’t care about it 
Why is Rh abandoning btrfs? -> STRATIS is thier new fs
M.
hurray for Science! and your comment @phillxnet. I do hear from our users about their frustrations with waiting for BTRFS to get there. At this point, I am seriously considering adding ZFS support in this release itself.
2 Likes
Zfs support would definitely be welcome. I would probably have used it if it were available when making the switch from FreeNAS to Rockstor, as I was unlikely to expand beyond my 6 disk raidz2 at the time. My new case can support 8 drives so… You never know I do appreciate the flexibility that btrfs has to change the raid level and number of devices, so once raid6 is stable I will more than likely make the switch to it, since it is so easy to do.
The biggest complaint I’ve heard about it is that when the kernel is upgraded openzfs doesn’t always recompile successfully and requires manual intervention. Would that be solved by how you plan to do it? or more accurately, can this be solved?
The issue as I understand it is that you can’t include openzfs in the kernel, so it must be compiled separately outside of the kernel it is run against. Since Rockstor is a distro could this happen further up in the chain so that OpenZFS is prepared ahead of time, but distributed separately, or would that still violate the license issues?
I’ve been looking at btrfs status page.
Raid 1 is mostly ok.
Raid 5/6 is still unstable.
Till now, I’m using btrfs on top of a md device (mdadm+btrfs).
Last year I’ve been playing with redundancy also on lvm and I found some issue I wasn’t able to work around.
I haven’t been testing zfs yet.
I searched for a page similar to btrfs status page and found zfs status page.
I can’t see raid status.
This is just to discuss about redundancy manged by tool other than mdadm.
Anyway, btrfs is a great tool.
It’s clear what is ready for production and what is not, so IMHO it can be used it it matches your needs.
PS: I haven’t tried rockstor yet 
I look forward to find some time to test it.
We would make sure to roll out kernel updates only after validating that it works.
A straight forward distribution model I can think of(that doesn’t violate gpl) is to rebuild zfs module via dkms following a kernel install. This would be part of one of the rockstor services. I’ve tested this myself and currently playing with 4.12 kernel. preliminary results are good actually.
2 Likes
Hi folks,
I am taking the time to point out some more or less interesting stuff that some users do not take into consideration. This is from a users point of view. I have been a product manager for an open source product for some years and I can tell that the way we are discussing the topic is very bad for the product named Rockstor.
Personally I have found Rockstor as an alternative to FreeNAS with a user (not company) driven programmers base. I were interested in the feature set of BTRFS for a long time and have it running without RAID on my desktop starting with the early 3.x kernels. Since I were able to operate BTRFS as well as CIFS without GUI I gave Rockstor a shot.
If you were to add ZFS at this point, you’d have no unique selling point for Rockstor any more. Even worse, you’d rival the most widely spread storage system. I know from my own experience how much effort all of you have put into this. This is just not the way for us to get where they already are.
From my product management experience I can tell, that BTRS / Rockstor is in need of a qualified GUI to spread BTRFS even more into the paid area. Part of the income could be used to pay a BTRFS developer to fix RAID56, as well as performance optimization.
Rockstor seems take the direction of getting ‘feature complete’ with a very limited amount of developers. You cannot keep up in this race when you run Rockstor like this.
It even came to my mind to restart the other way around:
- Fork the FreeNAS Corral GUI (nearly bug free and very well designed)
- Set it up to run on Linux
- Replace ZFS with BTRFS
- Set up the ‘most viable product’
- Strip down GUI to MVP
- Create a release plan and publish it, so that users can rely on it
- Target the MVP at users who do not need RAID5/6, but BTRFS sync or other BTRFS features
The rest is up on how you do your company / foundation setup to get money in and finally have RAID5/6 fixed. At this point of time you will be the only one offering direct FS sync, as well as only capacity expansion without the mess of ZFS.
Cheers to all of you who develop Rockstor. I love using it!
But please focus on where you come from and where you want to go.
Just my two cents
Christian
3 Likes
I think you’ve all described why red hat is pursuing stratis. ZFS has licensing concerns for Red Hat and it’s also the reason many products/projects aren’t all over it (not for the technology) - https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/
While that may not seem like a big deal, it is huge for a public company, maybe less so for a community project. However, adopting ZFS is going to take the community out of the open-source GPL camp unless something changed.