Damn Time travelers, fixing mistakes and stuff…
2 Likes
danger will robinson, danger!
Running timed tests, while seems straight-forward is not. I’m not saying you cant get a good “feel for how things are/are not” but I’m saying that writing a timed test on a function or operation(s) isn’t as simple as:
start clock()
do processes()
do more processes()
stop clock()
Because if we break this down to a simple single-threaded measurement case; we are sometimes falsely assuming that the processor has not received any interupts inbetween/durring each of the calls (computers are busy). Because of this, I built in a “virtural timer” into my unit tester header (although still not perfect, it’s a bit “better than”). …And in this case you have the added layer of the network (and all the components within).
However, I’m sure you’ve run enough tests to at least get a taste for how things are (seems legit enough). I believe the latest versions are running the same version of smbd so sounds like iX gave a lot of love to samba in SCALE (they maybe just didn’t reciprocate the same love towards CORE).
1 Like
Sure. This test is very much a quick Saturday afternoon see how things look and I’d encourage anyone else interested to construct their own tests. However the results are compelling enough for me to take a completely different look at this subject.
1 Like
Sure, but from how I read your test: both are still very, very, very fast. how many seconds–or more accurately said: nanoseconds–per file is the worst case scenario? …0.0006 per file? Not bad. I would still look and investigate all your options but I would keep in mind, we are talking very, very small numbers.
For me, there are larger issues I’d focus on other than a few seconds for file transfer.
1 Like
My primary concern around upgrading to SCALE has been this issue. It’s not about performance but instead keeping the same functionality as CORE ensuring users only see files and folders they have access to. However it seems that in order to achieve this an extra step needs to be taken that some suggested would in turn have performance implications hence the worry and testing. Based on my own testing this afternoon I have concluded that this is largely if not completely a non-issue other that needing to add the SMB global parameter. Naturally until things are in production you never know but I’m feeling better about SCALE now if I’m being honest.
1 Like
Fantastic to see and thanks for finding the “hidden” command and the quick test!
So, what was a bug is now SCALE is 3X faster. This deserves a “solution tick”.
If you’d like to make the enabling command more obvious in the UI, please make it a Feature request and we’ll see how common the need is. We should put it in the documentation as a minimum. Maybe there’s an argument to make it the default behaviour??
1 Like
And if that’s your concern that’s great (choose what makes you happy and lets you do less). But one of my major concerns is “trust based”. I 1. no longer trust iX to do what is right for me and my wants/needs (i.e. I don’t like changing operations/methods every so often for a file storage appliance). If you think about it, SCALE will be back to the same operational methodology to CORE in the spring (that was a lot of jumping around to get back to more or less the same point). 2. I trust BSD development more than I do Linux development (-e.g. I prefer BSDs choices, more often than not, to use ‘sane defaults’ vs ‘cutting edge’ or ‘widget x just for the sake of abc which negates qrs’).
I am also looking at automation; while probably the better opportunities exist on Linux, some of those “not sane choices” could end up making me change my methodology if a new bug/feature/etc. is discovered. …I also have multiple BSD’s behind me and I can for the most part cherry pick the mythologies that suite my needs (I can use components or mythology from NetBSD, OpenBSD, FreeBSD, GhostBSD, or DragonflyBSD because the underlying system is very similar).
1 Like