Thanks for the reply. All the info really helps. Sorry again for the million questions.
No problem mate,
when I started with btrfs I’ve butchered 4 file systems, lost lots of data … just all fun and game … i did learnt the hard way why ECC matters … why decent PSU matters …
Hey, watch Avi Miller video on basics of btrfs,
Then watch Dave Chinner rip btrfs a new one:
Fun part is that those skeletons are still in the the corner
zfs is not without issues it self, if you ever run into problem and need to “resilver” your system will grind to a halt frenas guys always blame it one everything else, but even they admit that ionice as btrfs has would be a life saver !
Also sorry for jumping on you, your idea was very bad, but at least you did some effort and showed some initiative.
And seriously consider per folder raid levels - it might just solve your problem! Also at 3 disks btrfs raid1 vs raid5 will give you 11% capacity difference. On ZFS you can’t have a 3 disk raid1. on ZFS you can’t change from raid 5 to raid 6 … you need to take your data somewhere else and rebuild whole pool. Always consider that your time sacrificed in the future = time you could spend earning money for more disk OR more time you could spend on the beach relaxing !
Thank you for the interesting thread.
I have tried Rockstor for 8-9 month now and I like the distro.
But it is let down by it’s underlying filesystem.
As stated in the thread, BTRFS is focusing on Enterprise features(like ZFS) and I would argue some features will maybe never come ->like Raid 5/6.
I was looking for a software raid solution/distro to take over for my hardware Raid setup that I use today(12TB Raid 5).
I tried different solutions like OMV, FreeNAS, NAS4Free and Rockstor.
All of the have nice features and some have a large community that support it well.
But non of them has the features that make it easy expandable with new disks and Raid 1/10 in the meanwhile is not really an option->Raid 5/6 on BTRFS may be 2 month away or 5 years.
So this makes me wonder where Rockstor wants to be in the future.
As I understood it was created to provide a Linux NAS distro that uses all the nice features of BTRFS.
But with BTRFS failing to provide home user features, I see Rockstor failing to become that.
What is the developers thoughts about this?
I have read all the Raid 5/6 threads in the Rockstor forum, but there is really no answer where Rockstor wants to end up.
I have only made a few small contributions so far, so not much of a “the developer” . However, full filesystem RAID support is an awesome feature that like everyone I would love to have available immediately. Unfortunately though, we can’t add features btrfs doesn’t have other than by contributing kernel code, which is certainly far above my programming skill. All that can be done otherwise is keeping the kernel and btrfs-progs up to date and hoping for things to be fixed, making the future of RAID5/6 in particular depend on that project.
As a home user though, I am fine with the current capabilities. My storage is still relatively small (~2 TB, no RAID) and contains mostly unimportant data, such as a media library. Backups of important data are also stored on it, but I also keep duplicates elsewhere obviously.
Guys I know your frustration, I would like to spend less on storage my self and use raid 6 … but it’s a bit unfair to say that btrfs concentrates on enterprise features … bugs being squashed now are thing like “die while unmounting on trimm” - something anyone with laptop with ssd can experience. Or silent fs corruption with kernel memory leak. Yes some developers are paid money to develop qpgroups (or stuff like that), so be it. It will benefit us all in future, but there is a major hunt for bugs that make this fs occasionally eat your data.
Ups is supported in rockstor and @phillxnet is our man on that feature. Having a battery backup, even for a short time to properly shutdown the server is helpful.
But that still wouldn’t solve any of the other problems that @Tomasz_Kusmierz mentioned in point number 8 would it?
Really good question, something I think about frequently myself. We’ve been patiently following btrfs development and sometimes get a bit frustrated that it’s taking longer than we like. I’m those times zol seems like a good thing to add. But we’ve refrained from doing so because 1) there are many nice features of btrfs that are overlooked that are not available in zfs and further more, may not be possible. So we can’t provide feature parity and before we realize, rockstor will become clunky trying to support both filesystems. And 2) there’s more than enough work in our queue that compliments btrfs features in some cases and completely independent of fs in others. As we improve rockstor, raid 56 shall stabilize, hopefully. Having said all this, it won’t be too hard to add zol support if we need to.
It will surely help !
Additional thing I’ve forgot to ask is when btrfs hit’s an error in file system it tends to call “kernel error” which usually leads to up - this results in module reload … your shiny raid 5 & 6 mid way write goes to hell. It’s fun to read on btrfs mailing list justification to why one would ops on corupt data
I’ve actually migrated a comapny server to rockstor (it was just file sharing server + owncloud). Right now I’m trying to build a back up server based on rockstor and CCTV system based on rockstor But I’m early adapter with not much budget on hand.
While some discussion is going on in these forums, as to whether we should find other ways around the RAID 56 bug, it does seem that right now some active development is going into fixing these bugs.
In the BTRFS mailing list some post are made where they are trying to fix it. At first in btrfs-progs, and when these fixes are known to work, it will be fixed in kernel.
I have no doubt that this is difficult and delicate work, to get done right, so we will have to be patient.
But at least it seems there is some progress now, and I’m hoping to see these fixes in Rockstor soon
@KarstenV is right, here you are:
And something moving with in-band deduplication too :
Hmm looks promising and it would be nice to get raid5/6 support back.
Hmmm, promising news!
Is it already possible to test this?
I think a number of these more recent patches have been submitted for kernel 4.9, while 4.8 and new btrfs-progs have just been released:
I have been following the Btrfs mail list some more.
And even though work is being done, it seems that production ready RAID56 still needs a lot of work.
Especially this thread has a lot of information about the challenges, and the complexity of fixing this problem. Its a long thread with a lot of technical talk.
Basically the current way Btrfs and CoW works is not well suited for RAID56, but some very knowledgeable people are discussing solutions, and it seems possible to fix the problems.
But I think a lot of work and testing needs to be done.
The current implementation is very buggy.
Described this way by one of the people discussing the problems:
“The current btrfs raid5 implementation is a thin layer of bugs on top of code that is still missing critical pieces.”
This means for raid5/6, go with ZFS for the time beeing if i am to read this correctly
I dont think ZFS in Rockstor is going to happen.
Even though ZFS is more mature in some ways, it lacks the flexibility and the low system memory requirements that BTRFS has.
And Rockstor is build being a BTRFS centric system.
But for people wanting to run RAID5/6, a ZFS based NAS solution such as Freenas would be the better option.
Flexibility I agree with you @KarstenV, for memory, there is this missconception that one will need 1GB Ram per TB data, which is true if you use De-Duplication.
For a regular homeNAS, nah, go with as much as possible (same as for Rockstor) and be happy.
According to this http://louwrentius.com/things-you-should-consider-when-building-a-zfs-nas.html
Freenas requires 4GB (ideally 8) to work, as Freenas lives in memory.
From the link (Raidz with 5 drives):
For maximum performance, you should have enough memory to hold 5 seconds worth of maximum write throughput ( 5 x 400MB/s = 2GB ) and leave sufficient headroom for other ZFS RAM requirements. In the example, 4 GB RAM could be sufficient.
The licensing issue has been discussed and also Rockstor beeing built as a BTRFS centric system is a valid point. I love Rockstor, but as the BTRFS Raid 5/6 is so unstable, I have had to look other places, but I dont feel like home as I do with Rockstor.
I have run a Freenas setup in 4Gb with little or no trouble except an occasional slowdown (as I remember it, it used its swap partition a lot?), so I agree to some degree that it is not that memory dependant.
But my current rockstor system, with 7,8TB storage and a plex media server running, shows memory usage at about 1Gb, with the rest being free / buffer/cache. No swap-space used.
So my Rockstor setup could probably live happily in 2Gb ram, with little to no performance hit (perhaps a small amount of swapping).
I would not have been happy running my Freenas on that kind of setup.
But ram is relatively cheap, so this is no major hurdle.
I agree that Rockstor has a lot of positives going for it. So I really hope that these RAID56 issues get resolved as quick as possible as it would really be good for Rockstor as a Freenas alternative.
So do I, it’s very unfortunate that we have to make do with an incomplete filesystem. On the other hand, there is time to polish our support of btrfs features to perfection before the mobs come running to Rockstor for being a mature btrfs system.