storage: Unified storage redesign

[garrett]

@mvollmer: We've talked about the idea of redesigning the storage page and having a unified design for a while now, but I haven't delivered designs for the concept (except perhaps on a whiteboard years ago).

Here's a very rough sketch of how it could work to have devices, network storage, and partitions in one view. I'm sure some assumption is probably wrong or I'm forgetting something, but I wanted to share the concept:

(The different types would be listed in some order, something possibly like: physical, groups (RAID), network and each type could have an icon at the beginning to help distinguish it from others (more than just type).)

🠟 storage-unified-list.excalidraw.zip

It's a tree concept, but I think we probably shouldn't make it collapsable. There could possibly be levels below this too, if it makes sense (which it might for btrfs?)

There would probably have to be additional changes and I'd have to mock up a lot more, like the kebab menus and subpages. But I wanted to share the idea in a place where we could start to discuss it and explore the idea.

This shouldn't impact anything we're working on right now, this would be a longer-term goal after Stratis and Btrfs work lands.

Details page:

What do you think?

Edit: Updated list to shrink usage bars quite a bit and added first pass at details page, focusing on physical disk first.

[garrett]

Note: I goofed up the alignment of the usage bars. They should all be the same width and aligned relative to each other. We kind of have this issue in production sometimes already; I don't want us to carry it over. 😆

Also, I did switch up the unit type between storage, but it's consistent within each source (device or network source). We might want to fix everything to GiB though? Not sure. It could get absurd in some larger data centers though?

[mvollmer]

What do you think?

I like it! :-) #16518 does a little bit of this, but doesn't change the overall layout.

[garrett]

Encryption throws a wrench into things. @mvollmer and I explored this a bit and tried a bunch of things, and we're coming back to expanders for encryption, perhaps... But then if we need to add other things, then we're back to tabs in expanders. 😢

[Kennobbi]

This design was a little unusual for me, because I just started to understand RAID levels and types. But I consider this design solution unique.

[garrett]

Good point. We should describe RAID levels in plain text, in multiple places:

• When creating a RAID, describe where the RAID level is selected; this can be in the selection or outside; TBD
• When displaying existing RAID, have a (i) and a popover with the description

---

My understanding of RAID follows.

RAID levels

0. 2 or more disks: Striping; filesystem split between multiple disks (dangerous to data as if either disk fails, you lose data; but fast)
1. 2 or more disks: Mirrored; data redundancy (can withstand a failure of a single disk)
2. (no longer used)
3. (not really used)
4. (not really used)
5. 3 to 16 disks: Striping, mirroring, and parity checksums; complex and rebuilding after a failed disk takes a long time (can withstand disk failure). Shouldn't be used any longer with large disks, as the failure rate is too high; it's quite likely that you'll have data loss when rebuilding the RAID. Lots of write overhead, so performance is not great.
6. 3 to 16 disks: Similar to RAID 5, but with double the parity. It does use more space to store the extra parity (which means you have less space for data), but RAID6 more robust than RAID5. Still problematic with large disks for the same reasons as RAID5, but a bit safer. Also has lots of write overhead.

Other common raids

• "RAID 01" / 0+1: Hybrid of 0 and 1. Does striping first, then mirror. (Fragile as raid 0. Shouldn't really be used.)
• "RAID 10" / 1+0: Hybrid of 1 and 1. Does mirroring first, then striping on top. (Resiliant, as it can withstand multiple drives as long as no mirror loses all its drives). Faster than RAID 5 and RAID 6.
• JBOD: "Just a bunch of disks". Multi-disk raid controllers can expose the disks to the OS, where software-based RAID can be used instead of the hardware RAID controller.
• btrfs raid1: Similar to RAID1, but supports 2 or more disks of varying sizes. btrfs supports other raid levels too, but most people stick with "raid1" and add additional disk failover by using raid1c3 or raid1c4 (or just use raid1 with multiple disks for 1 disk failover). This is native "raid" to btrfs, where the filesystem handles raid-ing disks itself. Of course, btrfs can be used on top of mdraid just like any other filesystem, but then that's traditional RAID 1 instead of btrfs raid1.

Notes

• Generally, RAID 0, 1, and 10 are the ones to use. 2 - 4 are legacy and should not be used. 5 and 6 are extremely problematic with large capacity drives and should generally not be used. RAID 01 is also problematic and should not be used. When someone considers 5 and 6, they really should use 10 instead.
• btrfs raid is different from standard RAID in various ways. Similar concept for two disks, but it's still different. It's fine for btrfs raid0, raid1, raid1c3, raid1c4. But avoid for btrfs raid5, raid6; instead opt for mdraid for btrfs + RAID5, RAID6. (Except RAID5 in all forms really should be avoided these days with huge disks.)
• btrfs and ZFS always checksums and can self-heal some data issues (such as bitflips) during scrubs in various scenarios. Other filesystems on Linux, including XFS, do not have this feature and requires something like RAID6 and RAID10.
• Even with RAID, you still want backups. This is why RAID0 is sometimes used, in conjunction with backups. (However, there's still the issue of bitflips and other data errors during read/write that can hit RAID0. Both btrfs and ZFS can still detect these errors, but even these filesystems cannot fix them unless more disks are used, such as with RAID1, 6, or 10. Other filesystems silently hide the data corruption.)
• People pick the scheme for their data based on how important the data is and how replaceable it is. If it's for temporary data, caching, or otherwise not so important data, RAID0 (with any filesystem) might be good enough for their needs. Otherwise, the other RAID levels of RAID 1 (especially when paired with btrfs or ZFS), RAID 6 (which is problematic with larger drives) or RAID 10 are better. But still keep backups. 😉

Links

• "RAID5 stops working in 2009": https://www.zdnet.com/article/why-raid-5-stops-working-in-2009/
• the follow-up article, " Has RAID5 stopped working?": https://www.zdnet.com/article/has-raid5-stopped-working/
• "Re-Evaluating RAID-5 and RAID-6 for slower larger drives": https://www.ibm.com/support/pages/re-evaluating-raid-5-and-raid-6-slower-larger-drives
  • It's a good article; here's a quick summary comparing RAID 5 and RAID 6 (and why you shouldn't use RAID 5 with larger disks):

    Drive type	RAID-5 rebuild failure (percent)	RAID-6 rebuild failure (percent)
    600GB 15K rpm	0.397	0.0000861
    6 TB 7200rpm	4.12	0.0163

• interactive btrfs disk usage calculator (mainly focusing on raid setups) https://www.carfax.org.uk/btrfs-usage/
• https://www.gigacalculator.com/calculators/raid-calculator.php
• https://www.synology.com/en-us/support/RAID_calculator

This is a lot of text. We'd need to distill it to communicate it more effectively in the UI.

[garrett]

BTW: I was using RAID6 with 4 disks @ 8 TB on my NAS for several years and had to rebuild the array a few times due to failed disks. During one rebuild of the array, a second disk failed during the rebuild process and I was super nervous for the next few days (as the RAID rebuilt). RAID6 (and RAID5) are slow, especially for rebuilds.

I have since switched from that dedicated NAS to an ARM board running btrfs raid1 with 2 8TB disks for a simpler, much faster setup.