writing to disk, or not writing to disk, which is quicker? /hamlet
So if I am understanding this correctly this will be the future upgrade path for Electric Eel user as well?
Is docker still going to remain the native app container like it is in Electric EeL, or are apps going to change when upgrading to Fangtooth?
Fast, relative to what it used to be.
That’s a long way from essentially always better to have enabled in all cases, like compression.
Dedup eats RAM, among other things, defaulting it to enabled would be terrible for an incredible number of people.
Docker still remains in Fangtooth, that upgrade for Apps should be pretty boring in the best possible way.
2 Likes
Docker should be here to stay—and at the very leasts stays as it is in Fangtooth.
Fangtooth, however, gets a new trick with Incus in addition to docker (NOT “in place of”).
What are these jails? If these are apps for which suitable docker containers exist, it may be easier to set up a test Electric Eel machine (in Virtual Box on your desktop if it has to be), see whether you can set up equivalent containers in there, and then move your storage to SCALE 
and deploy the apps anew.
If, conversely, these are applications which require a jail, or a full VM, rather than a light-weight application container, you may want to hold until Fangtooth is out.
The general theme being: Do not migrate, recreate anew.
1 Like
If you want little downtime when upgrading to scale, i would (and did) migrate my services into a vm.
Then I upgraded to scale… and the vm worked with very little reconfiguring. Then in my own time I migrated my apps/services out of the vm
I shared datasets into the VM using NFS.
In the VM I took the opportunity to learn docker compose… and ported my services to docker too.
Electric Eel supports docker compose, so the services can be easily run directly on EE.
I would suggest that you not wait for Fangtooth if you’re going to do this because the Core VM won’t work on FT
1 Like
Thanks for your comments. The jails are the Unifi Controller (from which I don’t want to lose service for any length of time) and Plex (no sensitivity there!).
I have two systems on line 24/7, main has the jails, other does not - it’s the backup machine, target of replication from the main, also used for testing. I’m not yet sure how best to use that box in the migration process of both to Scale, hence the questions.
Thank you very much for the pointers - see my comments to @etorix - following yours I’ll look at a VM on the backup machine to migrate the jails I suppose.
More later as I internalize - wife is waiting to be taken out to dinner…
1 Like
“Should be”.
How long would be long enough, in your opinion?
Given that nothing is permanent.
Realistically, I think Docker will be around for a while. Kubernetes didn’t last long, so I think I’d be justified in doubting that, but I expect it (or a drop-in replacement) will be around for the foreseeable future. I don’t have any such confidence in the apps catalog, though.
1 Like
I can only imagine it being replaced with something like podman one day if that takes over the zeitgeist
the bsd tree was eol the instant the scale was released…it was inevitable.
This is not a Fangtooth feature and not planned. The diversity in jails is probably too large to even consider.
If someone thinks its possible, I’d love to see a script.
For Dedup- Electric Eel is experimental
- we used it to test, so can anyone else. It generally works, but we don’t yet support it for paying customers.
For Fangtooth – Dedup can be used and we will support some well engineered systems for customers. The code is solid, but it only works well if the system is engineered for it. It requires more CPU and RAM and more storage IO for the Dedup table.
Dedup will never be the default. I’d suggest using it when:
- You expect the data to be dedupable at 3:1 or more
- You understand it well enough to know your system is sized well.
- The savings in media costs are significant to you
We appreciate the Community testing the new capability, but we can’t create RAM or CPU with bug fixes… I guess that’s why we didn’t call it “Magic Dedup”.
2 Likes
Did I understand you correctly in last Friday’s video that all exisitng VMs will have to be rebuilt from scratch in Fangtooth?
That depends on what you mean by rebuilt.
According to a previous T3 you will be able to import your existing VM disks (zvol, etc), but you will need go through the VM wizard again, assigning CPU, RAM, and so on.
3 Likes
Correct. Disk images will import just fine. You have to go through and setup your CPU / RAM size, VNC and similar config information again. Figure 30 seconds or so for most VMs. I did my windows VM’s here in < 15 seconds, it’s literally one form.
3 Likes
Just imagine your motherboard broke and you have to put your SSD with OS into another.
1 Like