Hello all. Just a quick note regarding our progress on this front
As of yesterday (7th March 2024) Leap 15.6 reaches their beta phase
As a result, we have now added this target to our rpmbuild backend and I’ve just published our first rpms (in the testing channel) for this pending Leap version. They are versioned to 5.0.8-0, as per our latest tagged release, and available for both amd64 & arm64 architectures.
The Minimal-VM images we use as native build hosts had, however, not yet been updated. But a quick zypper dup brought the Feburary Alpha images that were available up to this first Beta release. Once the final Leap 15.6 is out I will switch these build hosts out for out-of-the-box 15.6 images: just in case.
Another quick note on our 15.6 progress. In a few days openSUSE Leap 15.6 will reach it’s RC status. As a result we have begun the process of adding 15.6 installer profiles. Initial tests look good in the following, currently draft, pull request:
All 3 of the tested profiles to-date, x86_64 installer, ARM64EFI raw image, ARM64EFI qcow2 image, look to be just dandy. So I’m hoping to add these profiles to our installer master branch shortly. We then have a little maintenance work re moving our semi-automated installer builder to the newer V10 variant of Kiwi-NG and we are then all set to begin releasing installers again. Currently these new RC installer profiles are awaiting Tailscale releasing dedicated 15.6 repos, so I’ve popped in their 15.5 repos as place-holder for the time being.
I’ve now merged these new Leap 15.6 profiles, all still using Tailscales 15.5 repos for now however.
See:
N.B. the only profile that has yet to be tested (by me) is the Leap15.6.RaspberryPi4. If you have an interest in this profile then please test and report/fix appropriately. Otherwise it will of course be removed if found to be broken and no community assistance/interest was received.
With which Rockstor/Leap version does the “Share size enforcement” come back into play?
From what I remember, the BTRFS disk quotas are automatically supported from some kernel version on. 5.15+ maybe?
The reason I am asking is, because some of my shares are using up more data, than what was set initially in V4.6.0.0, and I don’t want this “Share size enforcement” to be suddenly enabled and be possibly causing unforeseen troubles.
For this reason I have now explicitly disabled the “Quotas” in the Pool menu. I hope that I have disabled Share size enforcement?
I will probably also never enable it again, since I currently don’t see any benefits from it. Apart from limiting a specific share from going wild and eating the whole array of disks?
We have yet to remove this fence. Quotas have been getting better over the last few years and the plan was to re-introduce them as enforced in our comming testing channel - as they were a show stopper - performance and reliability wise when we last this this - but that was a few years ago now. Likely once 15.6 is our - with the consequent kernel jump we will be in a better position to take advantage of the improvements made upstream.
Good point: you are OK for the time being, and we will announce this change, like all others, in our changelog visible within the Web-UI update. As it will be abstracted out into it’s own issue mostly likely. And again we will probably do this in the next testing phase, given we are now nearing the end of the current testing phase as we are on RC4 now (5.0.9-0).
Yes that should follow - without quotas enabled stuff is generally faster and there can be no quota enforcement without them being enabled.
Quotas are a more advanced option and extraneous to many folks use. But clever and capable in the right use setting. We were essentially forced to abandon their use re enforcement as at the time they introduced too many bugs in general use. Note however that when they are disabled you also use share usage info. There is now a light share option: I’ve not investigated this yet; but it does not exist as a half-way option between no quotas and full qoutas with enablement. We can look to adding this as an option when it is considered mature enough and we have the human recources to investigate and implement this. But we have some front-end development simplifications to do before we will be tending to that.