Hello we did check 2 years ago rockstor. At this time we where stuck in perfomance Issues with lets say 2.5 TB Data with 25.000.000 small files, e-mails. So here is our question, will rockstor support now ISCSI?
If not ist there any plan to implemet the feature soon?
kind regards Andreas
@akoelsch Welcome to the Rockstor community.
As per 2 years ago performance, our Stable release was still then based on the even then dated CentOS btrfs. Since then and quite recently (1.5 months ago) we now have our first v4 āBuilt on openSUSEā stable release out.
And our newly updated website has installers based on this release:
https://rockstor.com/
Downloads page: Downloads
And for more extreme uses, such as yours may be, we have documented adding to an existing install the official openSUSE backport of the latest Stable kernel here:
https://rockstor.com/docs/howtos/stable_kernel_backport.html
Depending on your drive count and desired btrfs raid level this may be an advisable option. But note that adding this backported kernel to our v4.1 release (the new installers) should be done before creating a pool as you then get the significantly faster space_cache_v2 āstuffā than can help with some prior performance issues. That is due to the newer backported kernels using this by default now. One can convert a pool in place however, but better if you are starting out to go with this on a kernel that has it as itās default. Our default upstream kernel in our v4 āBuilt on openSUSEā (Leap 15.3 currently) is still years newer than our older CentOS elrepo kernel however and openSUSE, being very active in btrfs development themselves (where as RedHad laid off their single btrfs developer), also actively backports btrfs improvements to their default kernel given they use btrfs by default in their install for their system disks. And as of Leap 15.3 we now have the benefits, post jump effort, of Leap 15.3 being binary compatible with SLES in many areas. They now use some of the same repositories.
You might want to given an indication of you anticipated or actual Pool (btrfs volume) disk count for this setup. 2.5 TB is not much actual data these days but many small files, such as you indicate, can present their own challenges. A btrfs raid10 is often a good choice for potential performance improvements over raid1. But if you are running a larger disk count and so need 2 disk failure then you are looking at btrfs raid 6 data with raid1c4 metadata. Something that can be done with the backported kernels but you will have to avoid the Web-UI for subsequent ReRaids and balances as they will revert you metadata raid to it default for the given data raid level. And you will have to command line create the pool (or do a command line metadata balance post Web-UI pool create to move it to the as yet unsupported by Rockstor Web-UI mixed data/metadata arrangement).
Having said all that, my may be just find with our out-of-the-box offering on the performance front now. Plus we do hope to add the very minor capability of showing the metadata raid level. Currently we only every show the data raid level. Btrfs raid can have independent data and metadata raid levels to match work load / required capabilities.
Not currently, although our underlying OS does, so it may work. But we definitely canāt do multi-path yet. It ends up confusing Rockstorās Web-UI currently.
It may be worth a try and reports would be of interest but:
Not really unfortunately. In my tenure as Rockstorās current maintainer, My prior aim was to move us to a btrfs supported OS. This has now been done. My current aim is to move us to a modern āfootingā to help encourage more developers. Stable subscriptions and testing reports all help this. Along the way in the OS move we have debugged a tone of stuff, and this obviously continues. Especially as our current task, in the next testing channel run to begin very shortly, is to update our entire code base and all itās dependencies. However this task is best done with minimal feature changes. The iscsi capability counts as a feature addition. And so is not likely in the near term. However it is likely and desirable in the mid term, just post our next testing channel run completion. This will also line us up to be ready for openSUSE Leap 15.4 (just coming out in beta now) which will require us to address some of our older code dependencies. We also have some issues to address in our build system, so all in we are not in a position, with the current developer count / backing, to add features that are potentially quite far reaching such as iscsi.
Hope that helps and do let us know if you end up experimenting with our new v4 stable offering as the scope for improvement now is far greater than we had previously given our now completed OS move. Our prior CentOS offering is now legacy and unsupported as we have been unable, for library version reasons, to build on that OS for some time now.
As an aside, it is important to reply via the forum website. Email notifications from the forum have a currently dis-functional link in them that I need to see to when I get the time. Email replies end up with me only and there is far greater knowledge and ability to respond in a timely manner here on the forum.