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:
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.
And they are looking to implement a journaling system for the parity data in a future patch.
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.