Well personally this is enough to stop me from upgrading atm Difference in SMB Share Behaviour Between CORE and SCALE
I need to do some serious thinking/testing about how I could use SCALE going forward. I’d be shocked if I’m the only person in this boat especially in the Enterprise realm.
I’m not sure…I responded to your post. with some questions. The issue seems to be what is the real performance impact and what would it cost to fix?
Do you have a target time for a directory listing?
Given that time, what is the maximum directory size in CORE and then Fangtooth?
From what I’ve seen, having an Apple client has a much bigger impact on directory listing times and hence directory sizes.
No real target time for listing just normal common sense being users don’t want to have to wait more than a few seconds to traverse and list a directory structure. I need to do some more testing tbh to see the impact when applying the fix to the responsiveness just been a bit busy. Key thing was to try and get it on your radar so thanks for engaging.
SMB is inefficient with small transactions, including metadata. Users can also be messy and throw thousand of files into a single directory. If that’s the case, you may have to either reset users’ expectations (good luck with that!) or throw some more resources at the issue (RAM, (metadata) L2ARC, special vdev).
True. I generally find my arc hit ratio sits above 98-99% most of which is metadata so can’t see special vdev being of much help. Having said that, that’s on CORE. Given that SCALE would need the hide unreadable = yes to get the same behaviour as was default on CORE that would potentially slow directory listings down so will need to test and reevaluate everything now. My main concern is how this scales (forgive the pun) longer term.
Just linking this for those that are interested.
This being setable in the GUi, plus LXC being something iX sticks with would give me obly mental/philosophical opposition to change.
I’d likely do it sooner than July this year if they automated the conversion of BSD jails to a VM on Fangtooth so the switch would be more seemless while I figure out how to transition the jails into LXC containers without losing things.
The ability to have each LXC container have its own IP and share resources like BSD jails was a big sticking point for me.
Otherwise, I’m so far failing to find something Fangtooth won’t do that I require from CORE. However, still reserve the ability to say I was wrong after my first
Seems like it was removed because it’s not exactly a recommended practice to set things at a global level like that (if I’m reading the thread correctly) so I doubt it’ll be added back.
While this might be a good idea, its not part of the plan. Fangtooth BETA is about to start. You can create a FreeBSD VM and run jails in that, but it would be a manual process to connect in the App storage.
Well, unless you actually need something that is only available in SCALE that you can’t already do in CORE right now, no reason to change really. CORE will still get security updates (the ones that really matter) for probably a while. I haven’t yet seen an End of Life announcement on 13.3 unless I missed it somewhere. If someone could prove me wrong, please check me here.
Of course, Core’s BSD kernel itself is EOL by upstream.
FreeBSD 13.3-RELEASE, will reach its End of Life at December 31, 2024
Well, doesn’t stop ix from supporting it beyond what upstream does hint hint to ixSystems to step in and chime in here and clear the air.
Yea, we know upstream is EOL, but that is kernel only, we obviously support a far larger stack of items, Samba, rsync, etc etc. That is still being supported with major CVE updates and we’ve not put a end date on it yet.
That said, now that 13.3-RELEASE is deprecated, I expect some jails to start breaking down in the near future as well. You can in theory run 13.4-RELEASE jails with ABI compat, but we’ve see many times in the past that it isn’t exactly foolproof and may break at some random time.
Could you clarify this? Does the CVE support include the kernel or is it just the userland?
It typically includes kernel as well. Extreme circumstances notwithstanding of course, but those are pretty rare.
That’s awesome! Thanks for chiming in, highly appreciate it!
I’ll jump down into the bilge and start bucketing the water out with you! I keep my tools dedicated to their strong suits.
The present instructions for converting core 13.0.x to scale seem to suggest that it should be done using some version of 24.04.x When 25.04 is released, will direct upgrading from core to this be recommended? At the moment, can I use 24.10.x?
The exact words are:
24.10 is only at update 1, but that’s been very good.
It will become the stable version after 24.10.2…
We do it this way because its easy to upgrade and easy to revert. Downgrading is difficult.
OK, thanks, I see what it means now!
