Remove quota support from Netatalk 3

[ghost]

No longer needed as storage capacity is not an issue on current SSD's and HDD's

[rdmark]

A thought: When adding or removing "major" features, we might want to consider a minor version bump of this software. I.e. 3.2.0

The other major thing in the pipeline is the whole WolfSSL thing to get DHX working again.

Thoughts? Any other features (adding or removing) on the roadmap that you had in mind?

[rdmark]

Also, I think we should ask on the mailing lists if anyone in the current install base are relying on this feature.

[rdmark]

Asked the community on the admins mailing list. Let's see if anyone raises concerns.

[cdevers-es]

This would have been a big problem for us a couple years ago.

At my employer, we make heavy use of the quota feature for shared storage solutions, where different user groups get different space allocations. If quota support wasn’t available for AFP mounts, then this would have led to a lot of unexpected behavior & tech support calls with convoluted workarounds, because the quota limits would still be enforced at the server’s filesystem layer, but anyone using AFP would falsely be led to believe that each of their mounts has access to the full capacity of the overall system. We’d basically have to tell AFP users to ignore what Finder is telling them, and to instead look in other interfaces to understand their space allocation & availability information.

For better or worse, the proposed change won’t matter to us nowadays …but that’s because we deprecated & removed Netatalk/AFP from our product, so our customers aren't using it anymore. When Apple started downplaying AFP support in modern Mac versions, our customers started switching to alternatives, so by the time we removed Netatalk, few if any of our customers were still using AFP anyway.

(If Samba were to drop quota support, that would be a bigger headache for us. But that's a discussion for elsewhere.)

There may well be other shared-storage products out there that are still making similar use of quotas, and might be caught out by this change. It certainly seems worth putting in something more than a dot-dot-patch release where people would normally only expect minor bug fixes, not the removal of a once-significant feature. Hopefully, any affected users/companies see this discussion before the September 25th deadline (three days from now) and can weigh in if this is going to be a problem for them.

I certainly understand the desire to pay down technical debt, and phase out support for features that aren't widely used anymore, in order to make the slimmed-down software easier to support & extend. Hopefully it's true that the population of people using quotas with Netatalk is small enough now that this is the right course of action. Good luck!

[Michael-Wohlstadter]

I have used quotas in the past in an edge case; home server quotas for undisciplined offspring. In the most recent server migration, while I continue to use Netatalk, quotas are no longer enforced. There might be other edge cases, but I suspect that overall the feature is approaching vestigial status. And even in my case, I continue to use AFP more out of stubbornness than practicality.

That's a little facetious, so to be clear, if it helps to streamline the continued development process, I vote to drop support for quotas. The continued support is far more valuable than this one feature.

One question that does occur to me is for the vintage community. Are there use cases where supporting older hardware and Apple operating systems in an environment with a current server might be impacted?

[rdmark]

@cdevers-es @Michael-Wohlstadter Thank you for sharing your perspectives! The main usecase for netatalk today, in my mind, is to support networked pre-Mavericks Macs. Samba gives you better performance on SMB-native macOS versions.

And yes we're talking about potentially bumping the minor version dot release for this to signal changes in capabilities: e.g. 3.2.0

Anyhow, I got busy with an international move myself so the 9/25 deadline came and went. I will go ahead and merge this now.

[rdmark]

One question that does occur to me is for the vintage community. Are there use cases where supporting older hardware and Apple operating systems in an environment with a current server might be impacted?

@Michael-Wohlstadter So what you're saying, is that someone may be running a network of vintage Macs with a configuration that relies on Quota?

One thing to call out here is that we aren't deprecating Quota in the netatalk2 branch (yet). If you are running a network with Classic Mac OS Macs or Apple II's, netatalk2 is arguably the better choice, for the AppleTalk and older AFP version support.

[Michael-Wohlstadter]

@rdmark agreed.

Mostly I was playing devil's advocate. I do have vintage Macintoshes and did implement quotas in the past. However, the vintage computers are mostly only turned on for reminiscing and the quota support is no longer relevant for me. As devil's advocate, I was raising the question in case it prompted a more legitimate use case from someone else.

Thank you again for taking on this work and I greatly appreciate your time.

[rdmark]

For posterity: This change was reverted in #1034 and quota code is back in the upcoming 3.2.0 release.