Wow.... Dragonfish is taking me to new places

TrueNAS General
, , ,
1

I did a little side-jump from CORE to SCALE on my two systems to see what the grass was like on the other side. After all, this process is supposed to be simple and reversible, as long as the pool isn’t upgraded, etc. My main impetus was the restart-able SCALE replication service, which CORE lacks.

Basically, if CORE is interrupted while going through a replication, it has to start transferring the interrupted snapshot from scratch. SCALE keeps track of the replication, if it is interrupted, it can pick up from where the last transfer was interrupted - a huge improvement over CORE that sadly will not be back-ported.

Now, the side-grade process was relatively painless EXCEPT for SMB auxiliary parameters in CORE borking the SMB service once they got applied in SCALE. Hence a suggestion to the SCALE team: - as part of a side-grade, start with fresh SCALE SMB auxiliary parameters while informing the CORE user that they have to start over in SCALE. That way, settings that worked in CORE can be preserved if the user decides to return to CORE. Meanwhile, settings that are incompatible with SCALE won’t prevent SMB from launching.

Another quibble: it is not useful to discuss the ability to modify SMB auxiliary parameters in the SCALE GUI documentation when there is no access to the parameters via the GUI (see here). Could the team at iXsystems (@awalkerix, @Captain_Morgan , etc.) please consider correcting the documentation, perhaps drop some hints re: using CLI and service smb update smb_options="" in the shell to nuke all auxiliary parameters and then restart the SMB service?

That editorial / suggestion aside, I decided to have a little fun and see what happens re: regular file transfers. I thought I had already entered the millenium falcon with my SVDEV / record size upgrade, but SCALE takes file transfers from my laptop to the NAS to a new level. Instead of ~400 MB/s sustained transfers, Dragonfish SCALE allows large file transfers at between 600-1,000MB/s (there is some downtime between large files, see below).
Screenshot 2024-06-07 at 16.36.13

I have a feeling that I’m hitting the limits of the activity monitor on the Mac since 1080MB/s is unlikely to be possible.

BTW, the shell in SCALE is simply beautiful. Being able to cut and paste reliably is so nice. Another huge improvement: Being able to apply for SSL certificates using cloudflare and a bunch of other certificate authorities via the GUI. I thought this was coming to CORE 13.3 also? Between the faster transfers, better SSL certificate support, and the restartable replication tasks, I may stay with SCALE even if I consider the GUI menu a bit less intuitive than the CORE one…

Hyper
Hyper1920×1094 221 KB

3 Likes
2

I thought so too, but it doesn’t look like even Cloudflare made it.

3

Thanks for the detailed review. Its really helpful to other users.

The performance downtime between files is probably due to a flush operation which requires all SMB data in DRAM to be flushed to disk before proceeding. Its the average speed that counts.

As for this issue, can you report it as a bug and share the NAS ticket. As you can imagine the number of aux parameter permutations is high and we may have missed something.

1 Like
4

I have created a ticket with a limited amount of information. The Jira bot is asking for a debug file that I am happy to send, but that auto-privates my Jira entry, no?

Would you like me to submit a debug file even if the service is now running because I ran the CLI command followed by nuking the SMB auxiliary parameter entries?

5

There is an upload link thing. That doesn’t make the bug private, but the upload is private.

1 Like
6

OK, done and thanks for the advice!

Have you noticed any differences re: remote replication task speeds also? My SSH+NetCAT replication task is running at 3x the speed it used to, i.e. 8-10MB/s vs. 3 MB/s or less via the VPN to the remote NAS.

7

Sorry, my uplink is 40mbps, and I get 4MB/s via ssh+netcat across the OpenVPN encrypted link between the two sites. And was in core too.

But I recently completed a 4+TB single snapshot replication across many disconnects :slight_smile:

As the replication resumability has improved I’ve been able to offsite replicate more of the entire datasets. Think it’s 100% now :slight_smile:

1 Like
8

Yes, thanks for reporting. At a minimum, its a documentation bug. We can’t assume everyone has your skills.

1 Like
9

LOL. No skills here. Just fumbling my way through the day. Lots of giants around here to help short folk like me. For example, via google I stumbled across @awalkerix answering a very similar question in March of this year over in the old forum.

That’s how I learned about CLI and using the service command that flushes the auxiliary commands down the bitbucket. Has anyone put together a comprehensive resource re: side-grading that covers these kinds of issues?

Leave jails / docker / apps / whatever aside, I’m just talking the basic NAS file server functionality. Has anyone done a write-up that I missed? The little things like AFP is gone in Scale, etc?

10

Unless you have an old CPU without certain features, that almost makes no sense (unless there was a previous bug/issue that hindered speed before?).

I run a couple of them with low dual cpus, and I can max the cpu(s) when doing replication, over vpn, doing the max ISP upload speed (40 Mbit), but they did transfer at full speed before the last update, so I cannot answer yes/no, but if there was no TCP stack changes and no ssh/cypher changes, there should be no changes in your transfer speeds.

(Was there any cypher that was marked as obsolete, or allowed?).

Now, yes, it maxes the cpu(s), understandable, but once you introduce extra variables like vpns, we need details:

Which specific vpn?
Docker?
Jail?

1 Like
11

I found it surprising as well. The Wireguard VPN is run between two MikroTik routers so the VPN setup hasn’t changed. It’s also still so slow that the CPUs on my ends are loafing along at sub-5% utilization.

Alternatively, Comcast made some changes to the network speeds or my son was using 5MB/s of upload capacity via background processes in Minecraft. Of the two, Comcast taking steps to remotely match claimed vs. actual network speeds seems like a more likely explanation.

12

One of the less happy transitions from CORE to Dragonfish (and which may have me going back at least once) is dropping jail support. I have been deploying certificates via ACME to various network devices around here via @dan’s excellent scripts and that capability now has to be rebuilt from scratch.

Sadly, the /config directory that stored all that stuff didn’t transition to SCALE like the rest of the /root files. Question is, do I attempt to deploy certificates via an App or use Jailmaker to make a jail that may survive the ongoing development wars in SCALE?

The beautiful fan script from @stux also needs to be reinstalled as the current tmux session is less than happy even as it sort of seems to be working?

13

I don’t think I’d be planning to do much of anything via an app until 24.10 is out and stable, as iX are introducing drastic changes in the app ecosystem. Otherwise, TrueCharts’ Cert-Manager/Clusterissuer works very well for that purpose–though even then, I don’t know how well it would do at deploying those certs to other devices/services.

A sandbox using Jailmaker, or a small VM, would be your best bet.

1 Like
14

I use my script in a tmux. Just have to use it post-init.

I use a pfSense virtual machine to do my haproxy l5 routing, and acme.

This is a bit more like a datacentre, where it doesn’t matter which IP or Port is hosting a service, there is a single point of ingress which is responisble for SSL and ingress redirection, and that is not inside the cluster/docker etc… with split horizon dns

Although it is on the TrueNAS in the VM.

I have a script that I run on truenas that distributes cert updates. I might publish that one day :wink:

1 Like
15

I will have to look into reinstalling your scripts then… is there a way to access all the config files inside the CORE /config folder short of switching the OS train back to CORE, copying the config and SSH data to a external stick for reimportation into a new jail? That was a lot of work to set up and troubleshoot… the data should still be floating around the iocage data folders, no?

16

Which “config” are you referring to?

The config that lives in a database file (which is used to export/import your TrueNAS settings)?

Or do you mean an actual folder that lives in a user’s home directory?

Or did you mean a folder your created in an old jail?

1 Like
17

Inside the letsencrypt jail, there were various config files that contained the config data for @dan’s script to transfer SSL certificates to the various mikrotik and Unifi switches / gateways / controllers around here. The jail is still sitting in iocage, but I presume it’s designed for FreeBSD, not Linux.

So presumably, I have to create a new jail, re-install @dan excellent script work, then add the various config files so it can do it’s magic. Or, are there alternatives I should be aware of re: pulling and distributing certificates via SSH on Linux, Windows, or even MacOS?

BTW, I did some don’t click clicks. Great suggestion.

1 Like
18

@dan would be better to answer this, but I don’t see why “config” files would be FreeBSD-specific, except if they reference particular directory paths that differ between Linux and FreeBSD?

1 Like
19

Semi off-topic: I am going to maybe write up a proposed idea on how to make it work seamlessly with the GUI, which I think will benefit all users of TrueNAS.

1 Like
20

I could work around all that. But first I have to access them. I presume this can only be done if the system is running FreeBSD, not Linux? I.e. I cannot access filesystem data inside the CORE jail from SCALE, correct?

Thus, I will have to boot back into CORE at some point, extract the files stored in /config , SSL, etc. to an external storage device, then import all that into a working jail on SCALE?