There were some pretty huge btrfs fixes in kernel 4.12 and btrfs-progs 4.12. When can we expect them to hit the stable branch? I’m really looking forward to the work Qu Wenruo put into this release.
I would still caution against using raid 5/6, which is the biggest motivation for kernel 4.12. It is still listed as unstable on their status page:
https://btrfs.wiki.kernel.org/index.php?title=Status
What has been improved upon is the scrubs with 5/6, but the actual filesystem is not yet safe.
Completely agree. But I’d still love to see it get pushed out for those who are running raid5/6. Because there are a lot of people still using it and still losing their arrays due to the experimental status. Personally I’m running raid10, but 4.12 is still a good kernel to get us all on to.
In looking into it a bit more, I’m now inclined to agree. 4.12 has raid 5/6 as unstable because the parity data is not checksum’d, which is the current state if mdraid 5/6 as well. so, really, assuming that nothing surprising is broken… btrfs is going to be equivalent to the mdraid alternative. That’s good news.
Would these be safe to follow?
edit: doesn’t seem like it.
[root@rockstor ~]# yum install kernel-ml
Package kernel-ml-4.10.6-1.el7.elrepo.x86_64 already installed and latest version
Nothing to do
The guideline sounds reasonable, but I don’t have any clue either why the new kernel is not recognized by yum install 
i would think you need to manually download the kernel packages and install with rpm commands to test it
I’ve checked today manually yum update and the following epel-release.noarch 0:7-10 package was available…I don’t know what it is or if it makes a difference to the upgrade process described above (I’ve not tried so far)
In case anyone comes across this post, 4.12 is included in the testing release currently.
3.9.1-4
And they are looking to implement a journaling system for the parity data in a future patch.
https://lwn.net/Articles/729569/
So if one is using raid56 now, upgrading to the 4.12 kernel is a good idea. If anyone is thinking to actually try out raid56, please wait until this is included at a minimum.
Time to go back to trying Raid5/6 then 
The Journal hole isn’t major unless I’m understanding it wrong, i.e if you had a crash you’d possibly corrupt whatever was in flight but you’d still be able to mount the array.
Again lack of checksum on the parity data is a bit more of an issue but still depends what the machine is for after all RAID is not a backup, it’s to protect against a disk failing. If it corrupts a file oh well, if it renders the whole array useless then that’s more of a problem.
Depends what the data is also, Important stuff should be replicated/backed up to multiple locations but at least in my case the home NAS is mostly stuff that if I lose it then whoops oh well.
Let us know how it goes =)
In my array I’m more worried about data integrity than I am about backups. It’s more important to me that my media not become corrupt, so the bitrot protection is more important, and why I don’t run btrfs over raid6. I need to wait till they enable checksum on parity, if they even plan to do so.
I personally will be holding off on going back to raid56 even after 4.12. It did fix a ton of bugs, but I am asking for it merely as a harm reduction task for those who are still running raid56.