Read the steps again. You’ll see that the issue is not with the ZFS command or API. The issue is that the GUI fails to redraw the correct information in the expanded (non-collapsed) visible entry. (It’s actually showing the “stuck” information of the deleted snapshot.) That’s why forcing a redraw (such as typing something into the filter text field) will show the correct information, such as DATE, USED, and REFERENCED.[1]
Another way to force a redraw is to collapse and re-expand the same entry. It’s like a magician pulling a rabbit out of a hat. Seriously. Try it. It’s sort of funny in its own endearing way.
This same glitchiness of the GUI was also seen elsewhere, such as in the Rsync Modules page. (Which has been fixed, thankfully.)
EDIT: What might be related to this bug:
You filter a list of snapshots (say by typing into “auto”), and the items are all collapsed.
You “expand” one of the items and click the DELETE button.
For no reason… all the items will expand.
If a snapshot named “XYZ” is showing the information for a deleted snapshot named “ABC”, this is a bug in the GUI. Especially if simply collapsing and re-expanding the item suddenly shows the correct information for “XYZ”. In other words, you “unstuck” the old information from the GUI by forcing a “redraw”. ↩︎
See last entry in that link which references “A commit in branch stable/13” & the link also contains reference to a proposed patch which I believe was adopted.
But as @victor pointed out, is the problem with mouse control in bhyve or vnc in bhyve, or an interaction between the two?
If the bug won’ be fixed, just as some other bugs will not be, then I guess the bug won’t be fixed in CORE. It doesn’t exist in SCALE, as far as I know, because SCALE got a UI rehaul. [1]
But this is why I’m not motivated to file bug reports on Jira. With all due respect, I don’t understand the pushback for clearly obvious bugs. I don’t understand the “after-the-fact” reasoning to try to explain away or dismiss glitchy behavior.
Let’s apply this question to Microsoft’s Windows File Explorer:
Microsoft Dev: “How long after deleting a file should Windows File Explorer refresh?”
I think the better question for such behavior would be: “Why does Windows File Explorer make me think I deleted the wrong file by putting another file in its place on the GUI… until I minimize and restore the window, in which it will show me the correct contents?”
Could you imagine if Microsoft just shrugged their shoulders and dismissed this issue of deleting a file with Windows File Explorer?
Could you imagine that deleting a bookmark from Google Chrome would show you the deleted bookmark taking the place of a bookmark that was previously underneath it in the list… until you closed and re-opened the bookmarks pane, in which you’ll now see the true (not deleted) bookmark correctly displayed?
Maybe it does still exist in SCALE. I haven’t personally tested it myself. ↩︎
…which still has massive caching problems. You should never need to force-reload a UI page to get correct information, but you have to do it in SCALE all the time.
The SCALE UI is being actively developed, the CORE UI not so much (That is obvious I think to all).
If there are pages still not refreshing automatically on the SCALE UI we’ll need to fix those. Each major release it seems like we fix a handful of reported instances, but there are probably some additional ones to be addressed still.
Its an assumption, but you would have to validate it on SCALE first. Both CORE and SCALE WebUI UIs rely on the REST API and the underlying ZFS information.
Sometimes there are behaviors that are undesirable, but the fix may be worse. We don’t want the WebUI to poll the ZFS system for changes. Its a request which may require a lot of metadata lookups and may impact system performance. This gets particularly bad on a 1000+ HDD system.
Your example is deleting a small 1GB snapshot, but the TrueNAS system has to support deleting a 1PB snapshot… which may take a lot more time. The secret to ZFS scalability is that many of these tasks run asynchronously in the background.
You can call it a “bug”… but it might be an annoying artifact of scalability. In some cases there is a deliberate trade-off being made. The UI is not guaranteeing that all information is updated immediately and is instead trying to minimize its impact on system performance.
Maybe there’s a clever solution in SCALE, but I’m not aware of it. (The engineers don’t tell me everything good they do).
If you have two or more snapshots viewable in the list, but you only “expand” one entry, then deleting that one entry will trigger (for no good reason) all the other entries to expand as well. It’s such a quirky behavior, and it makes no sense.
So I think this bug manifests because the GUI “pushes” the information of a neighboring snapshot into another snapshot’s view.
I really doubt this was deliberate, in the same light that the Rsync Modules bug was not deliberate. Why would anyone think it’s acceptable to present to the user wrong information until they interact with an element in the GUI?
(I also doubt it’s deliberate to have all snapshot entries expand without your desire… because you deleted one snapshot.)
It doesn’t even “update” on its own after some time. Not one second later. Not several seconds later. Not even five minutes later. It will only show the correct information if you fiddle with elements in the GUI or refresh the page.
Apply this to anything else. Let’s say this quirk existed with datasets?
“I have before me two datasets: archives and playground. I will now click “DELETE” for the playground dataset. It almost appears as if I deleted the wrong dataset, but I’m not worried! I know if I refresh the page or fiddle with some elements in the GUI, it will then show me the correct information.”
Given this it would seem to me that means the correct solution would be to not remove the item from the WebUI but instead badge it as (in this case) a deletion in progress. Polling is then not required and the WebUI can properly reflect the actions of the user in a maner both timely and unambiguously.
It would be a very different webUI. The current model is that all logic resides in the middleware and the webui just uses the standard REST API. API-1st is the current architecture because its much more maintainable and testable. In particular, its better at handling multiple admins working at the same time on a single system.
The code is Open Source and open for detailed review and contributions.
UPDATE: Some elements in the WebUI do “poll” to get updated information without a refresh. However, some elements like zfs stats are too “expensive” to poll and may impact system performance. In SCALE there is a more dynamic experience with more updates, but even there, ZFS stats are not polled.
After aplying Patrick’s workaround, “novnc” will work but colour order is swapped from RGB to BGR. No problem with normal vnc clients connecting to VM.
I need to double check, but the “wait for vnc connection” vm option was causing a vm to hang on startup after applying the workaround.
Starting a VM with a VNC device with the “web interface” option off still creates an associated websockify novnc process. TBH, I wonder if this has always been true.
@Krisbee I just now checked again - you are right. Web VNC in the UI does work - with colour coordinates switched, but it does work.
In my first tests I could not get a connection, so I thought Web VNC would not work at all. I cannot reproduce what went wrong, so now we need to find out what’s up with this vncserver extension to bhyve.
