Devices Page Mockup

[dszidi]

DEVICES PAGE

Users can think of the Devices page as a merger of the current Status and Disks pages. Please note that we will not be removing the Disks page. However, we did think that since the focus here is on device management and the tree table already shows all the disks in that pool, it makes sense to provide disk related information in the details cards

LAYOUT

The main layout consists of two areas

1. Tree Table
2. Details Cards

The tree table on the left is filled with high level information and the cards on the right shows details about the selected row. The tree table rows can be expanded, collapsed or selected. To select a row, simply click on it. The row selection updates the contents of the details cards. By default, the first row is selected on page load.

TREE TABLE

The tree table contains information about the following.

• Rows for VDEVs and Disks similar to current Status page
• Rows grouped by VDEV type since page is pool specific
• Status
• Capacity
• Total ZFS Errors

All rows are collapsed by default. Rows that contain devices with problems are automatically promoted to the top and expanded. In the status column, cells with a value other than ONLINE are highlighted with an appropriate color.

To show activity on the device the UI shows a spinner with the number of tasks in progress. Hovering over this spinner provides a popup with a breakdown of the running tasks. The type of tasks shown here are:

• S.M.A.R.T. tests
• Resilver
• Scrub

DETAILS CARDS

The details cards are where we show information about the following topics

• ZFS Info (available on both VDEV and Disk rows)
• S.M.A.R.T. info (Disk rows only)
• Hardware Disk Encryption/SED (Disk rows only)
• Disk Info (Disk rows only)
• Enclosure (only available on systems with enclosure support)

These cards provide sufficient separation and organize the datapoints with the related actions. We also made a point to help the users get to any related pages. If the card presents a datapoint, we try to provide a path to the page that allows the user to make adjustments.

With all this said, we're not perfect and we've tried our best to cover all the bases. If you feel there is anything that can be improved with this Device Page design, please leave your constructive feedback by responding to this thread. Thank you!

[a5tra3a]

I know that being able to use the full enclosure feature required specific hardware, but would there be a possibility to allow users not using that hardware to make use of the same display widget but have a section in the configuration somewhere that you could specify which drive was in what slot and also specify how your slots are laid out.

For example, I have one server running in a Norco chassis that is 6 rows and 4 columns for a total of 24 drives. So if under storage there is the enclosure widget and you selected "View Enclouse". You would be presented with the details and a settings cog would be in the top right corner that you could specify that you want to use "Manual Enclourse Management" which would be a checkbox or similar.

This would then let you specify either front only, front and back or top-load add the rows and or columns for each configuration. You would then be able to add the appropriate information and associate it to a disk on the system. Ideally, once this is done it would provide some of the enclosure functionality that is used on the supported hardware but at the very least would give administrators a way to document and reference what drive is in what slot should they need to manipulate a drive or drives in and out of the system.

There is defiantly more to this than just making some pages and a table but I wanted to try and express the idea in more detail, though I don't know if this is able to be done or if it would be a feature most people that do not use enclosure hardware would want.

[dszidi]

Hi there. First of all, thank you for contributing feedback. With regards to your suggestion, these designs are meant to reorganize current functionality and we don't currently support enclosure management features on generic hardware. While such requests are out of the scope of this discussion, we do take into consideration feature requests made on our jira. I recommend you create a ticket there and mark it as a suggestion so other users can add their support through voting.

[a5tra3a]

I will make an account there and make the suggestion. I look forward to seeing the layout(s) progress and will add my input and feedback where I can.

[Sophist-UK]

Can you post the JIRA URL for the suggestion please.

[stavros-k]

Looks beautiful! One thing I would change, is the status colors.
I think it would look better if there wasn't the background filling, but instead have a colored icon next to the FAULTED or OFFLINE
Like an ❌ and ⚠️ respectively.

[robloh]

Yes, please use standard colors!

[AlexHunterCodes]

Agree, I mentioned this in the storage dashboard discussion: #6767 (reply in thread)

Purple just isn't a colour anybody associates with status. The entire industry has standardised on ✅⚠️❌ℹ️ colours and symbols for a reason: they're clear, unambiguous, and universally recognised. They're what users expect.

I'd also expect whatever system you use to be internally consisent within TrueNAS. The proposed storage dashboard in the other discussion used coloured symbols (including the weird purple triangle) with tooltips, while this:

• uses white text labels instead of symbols (which is less glanceable)
• indicates status by changing the label's background colour
  • normal is grey/uncoloured, which makes sense because that's the assumed default, but poses problems later
  • error is red, which also makes sense
  • degraded is grey/uncoloured (the same as normal?) because you can't use yellow/amber because the white text would be totally unreadable. "I guess a degraded mirror vdev with a faulted disk is fine and I don't need to fix anything?"
  • offline is purple, because you can't use grey to indicate disabled or missing because the entire UI is grey.
• uses zfs terms (online, degraded, faulted, offline) while other screens use generic terms (ready, warning, error, information, "unoptimal"), so the colours confusingly change meanings. "Does purple mean unoptimal or offline? Does grey mean normal, or abnormal but still okay (informational), or degraded? If something is degraded, doesn't that mean it's not optimal? I'd expect it to be amber but maybe it should actually be purple? Why is it grey?"
• Thin white text against bright high saturation background colours is ugly, borderline unreadable, a colourblindness fail, and means you can't use yellow/amber to indicate warning states (which are the 2nd worst state and absolutely must be just as obvious as errors).

Colours and symbols intuitively translate varied terminology across varied UIs into one universal language: good, kinda bad, very bad, FYI and disabled/irrelevant. Use that everywhere please.

[dak180]

How does this work in a window sized to less than half a of a laptop screen?

[AlexHunterCodes]

If it's like the proposed datasets screen, it's not a priority...

#6768 (reply in thread)

[robloh]

Love the tree view. Not a huge fan of the word "devices". Should I expect my GPU to show up there? My UPS? My USB bluetooth dongle?

I'd much prefer to use a name like disks, drives, storage, etc.

[AlexHunterCodes]

ZFS calls them devices (because they might not actually be disks), but I agree that they should probably just call them disks because the current UI already does.

[Sophist-UK]

Does ZFS call the physical disks devices, or does ZFS mean vDevs when it talks about devices?

[AlexHunterCodes]

It would be handy if the disk info card displayed the disk's WWN in addition to the model and serial.

[AlexHunterCodes]

It would be really helpful if data fields like the drive's model/serial/WWN (and similar fields throughout the UI) had copy to clipboard buttons for pasting into cli's/scripts/documentation.

[GoingTime]

The SMART data of the hard disk is very important. A record table of SMART parameters can provide reference about the hard disk status, and a line graph showing the trend of SMART parameters can provide more information.

[Sophist-UK]

I would concur with this. What we need in Devices is both logical and physical status - what is the redundancy / scrub state of the vdev / physical disks and what is the physical state e.g. smart data.

[zmweske]

The JIRA feature request was closed and requested to be moved to the new TrueNAS forums. I created a request (https://forums.truenas.com/t/view-enclosure-screen-for-non-ix-hardware/12874 )- feel free to vote on it if you are interested in seeing this possibly become a reality.

[Sophist-UK]

That URL does not work because it has a trailing ")-" - please edit the comment to correct the URL.