since BTRFS raid 5/6 is broken, and also for RAID 10 there is a risk of loosing data if 2 drives fail at the same time. I suggest to add ZFS as a data storage.
For Rockstor install, yes BTRFS is good with all bells and whistles, but I currently do not trust BTRFS for storage of my personal data with all bugs etc.
Since ZFS is available as an addin for Centos 7, and included in ELrepo, would it be possible for the time-beeing to allow ZFS as optional filesystem for datastorage?
I could do this as a Shell install, but I do prefer to use GUI, and also have overview of status of the filesystem in web.
Perhaps you ask why to include when I can use Freenas or OMV? I like Rockstor GUI much better, There is a quicker development of Rockstor which greatly benefits my homenetwork, e.g. SMB3 is now available for Samba 4 which is only available for Rockstor. And I can configure my server better to my needs, OMV is all fixed GUI, Freenas is just scary (*BSD) for a linux user. And at last: a great community around the NAS OS where I can get help and also feel I can contribute, which is the most important for me.
Hi @bug11,
you’re right about Btrfs raid 5/6 matters vs ZFS, but adding it would require different min. requirements ( that’s why I love Btrfs over ZFS ) and make us deal with a “not at all” free license (GPL vs CDDL, google latest news about ZFS over Ubuntu)
It is an addition already in EL-repo, which can be installed after boot up. Imagine: go to services, enable ZFS storage, then everything will be installed.
This does not as far as I know violate GPL-CDDL.
For implementing, I have a GUI layout in mind, but I am good enough for coding.
I imagine that the layout can be identical to current, but background codes will swich from BTRFS to ZFS when you enable ZFS service. Thus, for datastorage, one can use only BTRFS or ZFS to begin with.
Let me know if this is feasible or if I am whishing for utopia.
Hi @bug11 personally I think everything is feasible so your is not an utopia,
but except for licensing (@suman has really to care about that), Rockstor is well known like an open source Btrfs nas, so having it mixing Btrfs & ZFS will make it a kind of ratatouille - my personal opinion.
I know Rockstor is known as a BTRFS NAS, that is how I found this gem.
However, with the recent set-backs of BTRFS stability, I do question if it is suitable for a NAS. I would like nothing more than using BTRFS, but due to cases where one can loose the whole raid if just scrubbing is not acceptable for me. And without a timeframe of when the situation is fixed, I look for alternatives.
That is why I open the suggestion for also using ZFS. ZFS as implemented in Centos/ELrepo will be similar to BTRFS, nothing that Rockstor are spending time on.
I have moved away from Rockstor and BTRFS until either BTRFS is fixed or alternative ZFS/Ceph are implemented. I chose BTRFS as I wanted a flexible filesystem for a NAS which can also protect my data. Current BTRFS status does not allow this.
This doesn’t help with the legal issues with using ZFS on rockstor but I did do a quick how-to that solves most of the issues that people are having with raid 5/6 in BTRFS. It’s not perfect but is works.
@bug11 - problem is that if it does violate license it’s not your wallet layers will try to reach. I understand guys in charge of rockstor - I would not want to risk that my self.
@aehinson - please stop misleading more people, I’ve explained in your thread that you solution does not solve anything, it actually adds more issues to the mix (not to mention a tremendous performance penalty) . Broken btrfs5&6 is still better than btrfs on top of dmraid raid 5&6.
@Tomasz_Kusmierz: I understand the whole licensing issue. However, Ubuntu seems to have this covered for their 16.04+ distributions. I do not know what will be the outcome, as there is several views on the topic. Some states that ZFS shipped with ubuntu is illegal, others states that it is OK since it is not included in kernel but shipped as module. And also since Ubuntu does not perform any modifications, it is OK. https://insights.ubuntu.com/2016/02/18/zfs-licensing-and-linux/
Then again, if Btrfs raid 56 does prove to be fixed within a reasonable time, then for a SMB/Homegeek setup which I believe is Rockstor’s customertarget. I am not sure if adding a separate new filesystem make any sense.
Not sure what I want with this post, just try to clear my mind perhaps?
@bug11 Problem here is that Ubuntu (canonical) has a legal department … rockstor doesn’t. If push comes to shove, canonical will have to defend their position in court and ZFS people will fight really hard to make sure that zfs is not that easily ported to linux. WE all have to remember that this is bussines that is driven by bottom line - less reasons to buy their systems will make more people migrate to linux (cost), and there are very good enterprise options for linux ecosystem (redhat, oracle to name the few).
Rockstor on other hand, has not legal department. If pressure will apply, Rockstor will fold. I would prefer to wait and see how this situation unfolds but don’t hold your breath because legally zfs people got 15 years to sue canonical (yes one five, fifteen !!!).
Rockstor could provide an option to download a zfs module through a packaging system (yum) and this is legaly better option because you don’t ship with it, but even canonical had some pressure from Fraunhofer people over that trick.
Anyway, in terms of legalities and reality - for very long time (up to windows 8 for sure) it was considered illegal in terms of user agreement to migrate your windows (certain types like OEM etc) installation from one disk to another. Yes you heard right, if your disk died or you wanted to go for faster hard drive, you were on your own … microsoft would turn a blind eye on it because they don’t want a bad press and for xp there was a limit of 3 reactivations but if you did that you again could say bye bye to your support … messy as !@$%$@#%. Generally if there is nothing innovative going on people will use legal stuff to keep them self in the market.
Anyway I would like to see more file systems supported on Rockstor. I would now really benefit from xfs. I’ve got to setup a cctv recording and I have an option 1) btrfs and manually setup a cron task to reclaim a lost space due to COW or run NOCOW, 2) create xfs my self and somehow crowbar it in.
Imho to keep the btrfs backend there schould be an option to set up an MD-Raid with a single btrfs (without quota save to use) on top, so we keep the nice btrfs features and have the kernel raid stability.
Imho the better (and easier to implement) temporary solution than zfs.
This is also what i did on one of my home NAS with OMV 3.x, cause it has no usable btrfs support. Had to use OMV cause Rockstor wasnt installable at this time. But personally i prefer Rockstor over OMV (unstable and ugly web-if, slow development [always 2 years behind stable imho they should develop on testing, not stable], but i prefer debian over centos in most other cases)
@khanh
And it provides zero extra stability because kernel raid has same write whole and inability to tell whenever parity or actual data got corrupted.
Sorry to say but kernel raid has no write hole as of k4.10 or k4.11…so it indeed has more stability.
and in professional environments you will always have battery backup for your important machines, so the write hole should be no problem even on non battery backuped controllers. this was always a design flaw and well known, so not really a problem if taken care about. but anyway its now fixed by implementing a journal for kernel raid.
on the other hand are serious unknown implementation/coding bugs a real problem.
And I will grant you that … btrfs is not for production and somehow people miss that. Original argument was not to blend to different architectures because it bring more errors and instabilities, which is stupidder ( more stupid )
Which is not 100% true, because you need to use a separate drive that acts as a journal (they use ssd for that, HA !) which is plagued with it’s own problems … they store checksum for a whole stripe, not individual parts so if something fails you just don’t write a specific stripe to a drive … all fun and games but if you decide to modify a large file, this will get sucked in -> modified -> stored into journal -> sector in journal fails -> you write n-1 sectors -> your old file pointer might even point to old sector, which was no overwritten (depending on FS this might happen), while btrfs will give you IO error … because you had crc per leaf error.
I can point you to a very long thread that discusses that problem and list software (very short list) that only modifies affected parts relying on operating system / FS - rather than -> read in full -> modify in ram -> dump whole lot with possible relink.
Not jumping down on you, but imagine you give this advice (btrfs on linux raid) to somebody like me where I’ve got cctv pumping ~1TB / day nowadays into storage and there might be a problem with journal drive that causes a single stripe not to be written -> coincidently this stripe is a b-tree -> which btrfs has an exact clone in 3 different places -> which any self respecting SSD cache algorithm (linux raid journal drive) will deduplicate before a write -> which due to sudden power loss is now all corrupt and I go with an axe after you :*
btrfs has mechanism to avoid that, but can’t properly use it if it doesn’t know how many drives it has.
Again, point here is that people try crazy stuff that brings zero gain, while they could run btrfs raid0 with a well managed offsite backup and be 10000000 times more happy with 0.00000001 down time in case of total crash.
RAID5/6 won’t protect against fire\theft\flooding. I use RAID0 and backup (btrfs send) to a second offsite rockstor. Performance benefits of RAID 5/6 with superior resilience. ZFS is bloatware in comparison. This is probably why the leading NAS vendor, Synology, supports btrfs and not zfs.
FYI Liu Bo is working on adding a journal to btrfs to eliminate the write hole problem. Atm its still RFC but heavily (& positivly) discussed on the list. Maybe we will see this very soon on for-next…
I’m not certain how journal fixes write hole
btrfs with journal - it’s blend of worsts of two worlds
since I was involved with btrfs for 4 years it’s status did not change - it’s still 2 years away from being ready and always will be
I’ve stop following btrfs mailing list …
I’m ceph all the way for data that I love
imho they should develop on testing, not stable], but i prefer debian over centos in most other cases)
)
